Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Java (http://www.velocityreviews.com/forums/f30-java.html)
-   -   getResourceAsStream vs JNDI (http://www.velocityreviews.com/forums/t675663-getresourceasstream-vs-jndi.html)

Clive 03-14-2009 11:39 PM

getResourceAsStream vs JNDI
 
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 03-15-2009 02:40 AM

Re: getResourceAsStream vs JNDI
 
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..

Arne

Owen Jacobson 03-15-2009 05:48 AM

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


Clive 03-15-2009 08:03 AM

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


On Mar 14, 7:40*pm, Arne Vajh°j <a...@vajhoej.dk> wrote:
> 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..
>
> Arne



Clive 03-15-2009 08:14 AM

Re: getResourceAsStream vs JNDI
 
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 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


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 03-15-2009 02:39 PM

Re: getResourceAsStream vs JNDI
 
On Sun, 15 Mar 2009, Clive wrote:

> 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

--
Everyone in the world is doing something without me.

Lew 03-15-2009 05:05 PM

Re: getResourceAsStream vs JNDI
 
Clive wrote:
>> 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.


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.

Tom Anderson wrote:
> 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.

--
Lew

Owen Jacobson 03-16-2009 04:56 AM

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


Clive 03-19-2009 05:55 AM

Re: getResourceAsStream vs JNDI
 
On Mar 15, 9:56*pm, Owen Jacobson <angrybald...@gmail.com> wrote:
> On 2009-03-15 04:14:19 -0400, Clive <sak...@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


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

Lew 03-19-2009 01:07 PM

Re: getResourceAsStream vs JNDI
 
Clive wrote:
> [citation of every message in full]


Please trim your posts.

--
Lew


All times are GMT. The time now is 07:43 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.