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