ACTION-22

Regarding ACTION-22, here is some further clarification.

 

Section 2.2 describes how the different properties affect the binding.
In this section the specification describes how to include connection
properties, message header properties, message properties, and other
properties.

 

With respect to the connection properties (in section 2.2.1), the
specification describes the most common JNDI properties (like
jndiConnectionFactoryName, jndiInitialContextFactory, and jndiURL), but
does not limit the users from adding additional properties.  In fact the
specification states "...it is not possible to enumerate all the ways
that connection information may be set."  This seems to imply that
additional JNDI properties can be included in the binding.  

 

For example, a JMS URI could include these common JNDI properties as
well as other JNDI properties not documented in the specification (both
standard properties and provider specific properties).

 

jms:jndi:news?targetService=current-affairs

   &jndiConnectionFactory=SOAPJMSFactory

   &jndiInitialContextFactory=com.sun.jndi.ldap.LdapCtxFactory

   &jndiURL=ldap://localhost:389/o=foo

   &java.naming.factory.control=bar

   &com.sun.jndi.ldap.netscape.someProperty=true

 

The specification also states (in section 2.2.5) that Other properties
can be included in the JMS URI, although these properties will not
affect processing.  The specification includes an example of this in
section B (see userprop=mystuff in the example below).

 

jms:jndi:news?targetService=current-affairs

   &jndiConnectionFactory=SOAPJMSFactory

   &deliveryMode=PERSISTENT

   &priority=8

   &replyToName=interested

   &userprop=mystuff

 

I am wondering how the consumer should differentiate between these
properties, specifically when it comes to JNDI.  I believe there is a
use case where the provider will need to specify a set of JNDI
properties (possibly via a JMS URI included in the WSDL) and expect the
consumer to use these properties to retrieve the correct administered
objects.  It is possible that this URI will include a JMS property that
is not included in the specification.  To be truly interoperable the
consumer should be able to interpret what properties belong to the
connection and act upon them without user intervention.  This does not
seem possible with the current approach.

 

Here is one last example to illustrate my point.

 

jms:jndi:news?targetService=current-affairs

   &jndiConnectionFactory=SOAPJMSFactory

   &jndiInitialContextFactory=com.sun.jndi.ldap.LdapCtxFactory

   &jndiURL=ldap://localhost:389/o=foo

   &com.sun.jndi.ldap.netscape.someProperty=true

   &my.user.prop=mystuff

 

How would the consumer know that com.sun.jndi.ldap.netscape.someProperty
is required when connecting to this particular JNDI provider?