Re: getResourceAsStream vs JNDI
On 2009-03-14 22:40:17 -0400, Arne Vajh?j <arne@vajhoej.dk> said:
Clive wrote:
I was wondering what is the use of getting the resource from jndi
context vs resource stream. If it is not an enterprise applicaiton and
you control the deploy then the getResourceAsStream seems better and
not to get in complication of jndi, esp when you are not using any app
container? is it correct, is there any benefit of jndi lookup when it
is a web application.
getResourceAsStream gets a stream which is a stream of bytes
from something in classpath.
JNDI lookup gives you a Java object.
I can not really see any substitution between the two.
The first is typical used to load graphics or property files.
The last is typical used to get access to EJB's, message queues etc..
.... and environment entries, which are limited to the kinds of
information you'd store in a configuration file and could load from a
stream just as easily.
The justification in the EE architecture is that classpath resources
are set once, at compile time, whereas configuration can change at
every deployment and should not be "baked into" the JARs, WARs, and
EARs. I tend to agree, but I find JNDI rather clunky - unless you're
using something like Spring or the EE 5 injection targets, code quickly
becomes overgrown with JNDI lookups - which are hard to test.
The strongest motivator, for me, for not baking configuration into the
deployed artifacts is that I want to deploy identical artifacts for
testing and for the final production system. Having to re-package
software just to change the database name and so on introduces a chance
for unintended changes to sneak into the binaries.
There's an unfortunate tropism towards in-JAR configuration in the EE
and servlet worlds, though, because it's the simplest thing that could
work: the mechanism for configuring EE apps' JNDI entries from the
outside is not standardised, so you get to compare Tomcat's context XML
configuration (which surprisingly few Java *webapp* developers actually
understand) to JBoss' to WebSphere's to Glassfish's and discover
there's almost zero knowledge portability beyond "the app uses JNDI to
pick this up."
Welcome to the future, I guess.
-o