Re: ACTION-29 Write up a proposal to differentiate JNDI connection properties in the URI and WSDL

Hi Derek,

Excellent.  A few comments:

Rokicki, Derek wrote:
> I am writing this proposal in response to the issue raised with
> Action-22:
> http://lists.w3.org/Archives/Public/public-soap-jms/2008Aug/0039.html
>   
> I suggest we add two new sections to the JMS URI Scheme 1.0
> specification:
> 
> 4.2.1.4.  Additional JNDI Parameters
> 
>    It is possible that connecting to a JNDI provider requires additional
> 
>    parameters.  These parameters can be passed in as custom parameters 
>    (see Section 4.4).  To identify a custom parameter as JNDI specific, 
>    the parameter name must start with the prefix "jndiProperty.".

In the interest of keeping URIs shorter, my personal preference would be 
for "jndi-" as the prefix.  Definitely not a strong preference.

If we prefer to keep something more explicit, isn't it really 
"jndiParameter" (or even more verbose, "jndiContextParameter")?

> 
>    For example, if the JNDI provider requires a parameter named 
>    com.sun.jndi.someParameter, you can supply the parameter in the URI 
>    as: jndiProperty.com.sun.jndi.someParameter=someValue
>    

Based on what little I can find on the net, to be pedantic, the Java 
APIs for initial context allow for the use of non-String objects.  In 
practice, it doesn't look like any context values are defined that way.

Should we say here that only String values are supported?

> 4.2.2.1  Performing a JNDI Look-up with Custom Parameters
>   
>    Any custom parameters with a prefix of "jndiProperty." in the URI 
>    should be used when establishing a connection to the JNDI provider.
>    Before passing the custom parameter to the JNDI provider, remove the 
>    "jndiProperty." prefix as the prefix is for identifying the custom 
>    parameter in the URI only.
> 
>    For example, this JMS URI...
>    
>    jms:jndi:REQ_QUEUE?jndiURL=file:/C:/JMSAdmin
>    &jndiInitialContextFactory=com.sun.jndi.fscontext.RefFSContextFactory
>    &jndiConnectionFactoryName=CONNFACT  
>    &jndiProperty.com.sun.jndi.someParameter=someValue
>    
>    ...instructs the consumer to use the following properties to connect 
>    to the JNDI provider:
> 
>    java.naming.provider.url=file:/C:/JMSAdmin
>  
> java.naming.factory.initial=com.sun.jndi.fscontext.RefFSContextFactory
>    com.sun.jndi.someParameter=someValue   
>    
> 
> I also suggest the following changes to the SOAP over JMS 1.0
> specification:
> 
> + Add a new definition to section 2.2.1
> 
> [Definition: soapjms:jndiProperty ] (xsd:string)

The XML Schema types we put at the end of each line indicate the type of 
element.  Technically, this is a custom type, so we should define a 
different type and use it here.  That is:

  [Definition: soapjms:jndiProperty ] (soapjms:jndiPropertyType)

This highlights an oversight.  Nowhere in our document do we actually 
have an XML Schema that defines all of the elements we defined, nor this 
new type.

SUGGESTION: Insert new Appendix B with the XML Schema representation of 
all the elements and types referenced in the text of the specification.

-Eric.

Received on Tuesday, 23 September 2008 05:02:57 UTC