- From: Eric Johnson <eric@tibco.com>
- Date: Mon, 22 Sep 2008 22:02:20 -0700
- To: "Rokicki, Derek" <Derek.Rokicki@softwareag.com>
- CC: public-soap-jms@w3.org
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