getResourceAsStream vs JNDI

[Clive]

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.

 

[Arne Vajhøj]

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..

Arne

 

[Owen Jacobson]

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

 

[Clive]

But cant the property be read and class instantiated from it i.e. read
property and create instance of message queue , ejb etc. Thanks

 

[Clive]

... 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.
yes the jndi can replace in jar config, but there are not many cases
in which a custom app is deplyed many times
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.
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.

 

[Tom Anderson]

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. yes the jndi can
replace in jar config, but there are not many cases in which a custom
app is deplyed many times 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. 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.

I think you're about right. There are times when getting your information
through JNDI or some other external mechanism is a good idea, because it
gives you flexibility, but unless you have a reason to do it, just use a
resource, or even a constant in the code.

The problem is that you don't always know when you're writing the code
whether something needs to be flexible or not. You might write some code
with the assumption that the log server is always log.mycompany.com, but
if that then changes, you're in trouble.

tom

 

[Lew]

Sometimes it is, sometimes it isn't.

yes the jndi [sic] can replace in jar config, but there are not many cases
in which a custom app is deplyed many times it still needs a lot of
custom tweaking/config to get it working even with jndi [sic] (months of
deployment projects etc). so it might be easier to just use resrouces.
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.

"The EE" comprises a plethora of standards with a surfeit of implementations.
You don't need to build a mansion to house a dog, but you probably want
indoor plumbing in your house.

I think you're about right. There are times when getting your
information through JNDI or some other external mechanism is a good
idea, because it gives you flexibility, but unless you have a reason to
do it, just use a resource, or even a constant in the code.

Good advice. The issue is correct determination of what you need. As you say,

The problem is that you don't always know when you're writing the code
whether something needs to be flexible or not. You might write some code
with the assumption that the log server is always log.mycompany.com, but
if that then changes, you're in trouble.

Generally, when one writes an app one has a notion of its scope and scale.

If one is clever and interested in minimizing effort, one writes the app in a
way conducive to refactoring, so when JNDI becomes an advantage, or EJBs do,
you don't have to rewrite your entire plate of spaghetti to use them.

Such attitudes are astonishingly rare in job sites I've worked, and their
enactment even more so.

 

[Owen Jacobson]

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 ...>
<!-- ... -->
<utilroperties 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

 

[Clive]

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.


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.


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.


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 ...>
  <!-- ... -->
  <utilroperties 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

Thanks , I really appreciate all the info. helped me a lot

 

[Lew]

> [citation of every message in full]

Please trim your posts.