Re: getResourceAsStream vs JNDI
On 2009-03-15 04:14:19 -0400, Clive <sakcee@gmail.com> said:
On Mar 14, 10:48?pm, Owen Jacobson <angrybald...@gmail.com> wrote:
On 2009-03-14 22:40:17 -0400, Arne Vajh?j <a...@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 an
d
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
Thanks for the detailed information, This is certainly true for the EE
deployed app
which can be inside an app container, which has to connect to existing
enterprise infra. but
dont you think for a consumer oriented webapps or even small ee apps
its kinda overkill.
No, I don't.
I've implemented my own configuration management on top of resources
and properties files for webapps designed to be deployed by people
without access to the container configuration. It's noticably more
complicated than using JNDI, in the long run; the only advantage is
that you-the-developer now control the entire configuration lifecycle,
whereas with JNDI you have to rely on container configuration to
override your default values.
Actually *using* the configuration values is about equally complex
either way. The only advice I have is to use a tool like Spring; it may
look heavyweight, but (in combination with injection-friendly
techniques, which are both simple and correct by inspection) it will
save you a lot of suffering in the long run. As an added bonus, you'll
be able to use either JNDI or resource configuration fairly
interchangably, as long as your classes expect to be configured by
injection rather than expecting to go find the configuration themselves.
The only time JNDI is wholely inappropriate is in contexts where it's
not available, like standalone applications and applets. In those
cases, the java.util.Preferences system is usually available. JNDI (and
to a lesser extend Preferences) may be somewhat overgrown and
underspecified configuration tools, but they're vastly preferable to
every developer deciding they know better.
yes the jndi can replace in jar config, but there are not many cases
in which a custom app is deplyed many times
Ideally, every single EE app (where JNDI is relevant) should be
deployed to at least two environments: your own, for development and
light testing, and the final production system, for live use. Ideally
there's also a dedicated test environment, even if it's just a separate
VM on your dev machine. I can't imagine working on even a simple webapp
in *any* language without the ability to deploy it locally while I
tinker with it.
it still needs a lot of custom tweaking/config to get it working even
with jndi(months of deployment projects etc). so it might be easier to
just use resrouces.
Ultimately, it does boil down to figuring which approach is going to be
cheaper to build *and maintain*. There are many things that are easy to
build that are not easy to maintain in the long run.
I'm also strongly dubious of the "oh, it'll take a while to learn, I'll
just do $THING_I_KNOW" attitude. I can't tell whether you're doing that
or not, but it's a depressingly common trait and it leads to a lot of
completely inappropriate or unnecessary tool choices. I do think
"months of deployment projects" is completely out of line; if that's a
realistic assessment of your environment, then I'm sorry.
It seems to me that the EE tends to be very configurable for all and
every type of enterprise arch but at the cost of much complexity,
performance and maintenance/upgrade cost. At the end I would rather
get to the domain problem faster.
EE on its own is an incredibly difficult tool, agreed. That's why I
keep mentioning Spring: while it does look like Yet Another Big Scary
Tool, it's built around a very simple premise, and in execution it's so
useful I even use it for standalone apps now. It does a lot to turn the
big complex tools in Java EE into straightforward pieces. A practical
example:
Let's assume you have a configuration parameter. Right now it's in a
properties file (stored as a resource). In your Spring configuration:
<beans ...>
<!-- ... -->
<util:properties location="classpath:/config.properties" />
<bean ... class="some.configurable.Service">
<property name="loggingHost" value="${logging.host}" />
<!-- ... -->
</bean>
</beans>
In your properties file,
logging.host: 127.0.0.1
The class itself needs to have a writeable bean property named
databaseUrl, exposed as public void setLoggingHost (InetAddress) or
similar, which is pretty straightforward.
To switch the logging host to a JNDI environment entry, no code changes
are required. Delete the properties file, and adjust the Spring
configuration:
<beans ...>
<!-- ... -->
<bean ... class="some.configurable.Service">
<property name="loggingHost">
<jee:jndi-lokup jndi-name="conf/logging-host" />
</property>
<!-- ... -->
</bean>
</beans>
In this kind of context, the choice of "configuration file" vs "JNDI"
becomes less about which is easier to develop with and more about which
is a better fit for your deployment environment. The only reason I
wrote my own configuration logic in the app I mentioned earlier was to
support users deploying to cheap shared hosting, where they may not
have access to the servlet container's configuration to set JNDI
entries up.
There's one last edge case, where "configuration" is so complex it's
effectively a form of application state. This tends to be a poor fit
for either configuration mechanism; the only reliable way to set up
sufficiently-complex configuration is to store it in some easily-parsed
form, like relational tables or XML, and access *that* through the
basic configuration mechanism.
-o