|
From: <dar...@hs...> - 2003-08-12 11:15:59
|
Not sure if I'm missing something here, but WebSphere 4.0x and 5.0 both
exhibit the following behaviour..
A JDBC source is set up in WebSphere and given the name "jdbc/ds1".
In applicationContext.xml, the following bean is defined:
<bean id="portalDataStoreBean" singleton="true" class
="com.interface21.jndi.JndiObjectFactoryBean">
<property name="jndiName"><value>jdbc/ds1</value></property>
</bean>
When the framework executes, a NamingException occurs which I think is due
to the default way WebSphere implements InitialContext. From what I can
see, the default (no properties) instantiation of InitialContext is set to
expect that names will NOT include the container prefix. This is however
guesswork based on the evidence since I don't have the WebSphere source
code. AbstractJndiLocator.afterPropertiesSet() always prefixes the
jndiName with "java:comp/env/" if it is not supplied and the lookup
subsequently fails with the message;
javax.naming.NameNotFoundException: Name comp/env/jdbc not found in context
"java:"
If AbstractJndiLocator is prevented from prefixing the jndiName with the
container prefix then the JNDI lookup succeeds and the DataSource can be
accessed in application code. Tests against the DataSource config in
WebSphere work, and the DS can also be accessed from a servlet using the
following code which operates without error:
Context ctx;
DataSource ds = null;
Connection con = null;
try {
ctx = new InitialContext();
ds = (DataSource) ctx.lookup("jdbc/ds1");
con = ds.getConnection();
System.out.println( con.toString() );
} catch (Throwable t) {
t.printStackTrace();
}
I've scoured the WebSphere classpath for any jndi.properties file that it
may be loading at startup which may have had an effect, but none exists and
therefore I'm assuming that this is simply what WebSphere does unless you
tell it otherwise by supplying a java.naming.provider.url property for the
InitialContext constructor. I even tried setting the name of the data
source explicitly to "java:comp/env/jdbc/ds1" in the server config, but as
expected, this failed when the server tried to bind it at startup.
I don't know enough to know whether WebSphere is violating some JNDI API
contract with this behaviour so if anyone can confirm that it *is* in fact
doing so, and point to the relevant docs, I'll have a word with IBM.
Let me know if there are further tests you think may be helpful that I can
run on the WebSphere servers?
Darren Davison
CIBM Intranet Team
int> 799 19431
ext> +44 (0)20 7991 9431
_____________________________________________________
This transmission has been issued by a member of the HSBC Group
"HSBC" for the information of the addressee only and should not be
reproduced and / or distributed to any other person. Each page attached
hereto must be read in conjunction with any disclaimer which forms part
of it. Unless otherwise stated, this transmission is neither an offer nor the
solicitation of an offer to sell or purchase any investment. Its contents are
based on information obtained from sources believed to be reliable but
HSBC makes no representation and accepts no responsibility or liability as
to its completeness or accuracy.
|