There seems to be a bit of confusion as to exactly what the ApplicationMetaData
change that I committed is and what its impact will be. I'll describe the current
problem and then suggest an integration of the patch into the 2.2.1 release that
won't break any code or jboss.xml descriptors but will allow one to work
around the current problem if desired.
The current problem is that resources that are bound under a context
other than java:/ cannot be accessed from the standard ENC namespace.
For example, here are standard ENC names for accessing a javax.sql.DataSource,
a javax.mail.Session, and a javax.jms.QueueConnectionFactory:
Context env = new InitialContext();
javax.sql.DataSource ds = (javax.sql.DataSource)
env.lookup("java:comp/env/jdbc/DefaultDS");
javax.mail.Session s = (javax.mail.Session)
env.lookup("java:comp/env/mail/DefaultSession");
javax.jms.QueueConnectionFactory:qcf = (javax.jms.QueueConnectionFactory:)
env.lookup("java:comp/env/jms/DefaultQueueFactory");
As it stands now in 2.2, a mapping from the ENC name used by a developer to the
deployed
resource JNDI name can only be made if the deployed resource is located under the
java:/ context in the JBoss JNDI namespace. This is the default for some resources,
but the JMS resources managed by the JBossMQ module don't happen to use this
convention.
The restriction that a resource must be deployed under the java:/ context is hard coded
into the ApplicationMetaData and this does not allow a deployer to create a mapping
from a developer's "java:comp/env/jms/DefaultQueueFactory" name to the
"QueueConnectionFactory" name under which JBossMQ binds its
javax.jms.QueueConnectionFactory:
There is no reason why resources must be bound under the java:/ context and so the
hard coded check has been removed from the org.jboss.metadata.ApplicationMetaData
class.
Under no circumstances can this change require a change to the JNDI name used
to lookup a resource. The JNDI name used by a developer must either be
the ENC style name or the deployed JNDI name of the resource.
This change will break a jboss.xml deployment descriptor that is relying on a
java:/ prefix to be added to a res-jndi-name when the prefix is not specified.
For example, under 2.2 this jboss.xml fragment:
<resource-managers>
<resource-manager res-class="">
<res-name>DefaultDS</res-name>
<res-jndi-name>DefaultDS</res-jndi-name>
</resource-manager>
</resource-managers>
is really treated as:
<resource-managers>
<resource-manager res-class="">
<res-name>DefaultDS</res-name>
<res-jndi-name>java:/DefaultDS</res-jndi-name>
</resource-manager>
</resource-managers>
With the change to ApplicationMetaData the res-jndi-name value is no longer
forced to be relative to java:/ and so the first form will now fail.
I would like to make it possible to access any resource using the suggested ENC
naming convention in the 2.2.1 release, but since its not clear how many people
are using broken jboss.xml descriptors I'm proposing the following change.
The ApplicationMetaData will look for a
org.jboss.metadata.ApplicationMetaData.assumeJavaPrefix
property that will indicate whether the old behavior of assuming that all res-jndi-name
values that do not begin with a java:/ prefix should. The default value for this
property
will be true so that the current 2.2 behavior is the default. Anytime a res-jndi-name
seen that is not prefixed with java:/ when the property is true a warning msg will
be logged. If you don't want the 2.2 behavior you can set the assumeJavaPrefix
property to false on the command line or the jboss.properties file.
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
