getResourceAsStream vs JNDI

Discussion in 'Java' started by Clive, Mar 14, 2009.

  1. Clive

    Clive Guest

    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.
    Clive, Mar 14, 2009
    #1
    1. Advertising

  2. Clive

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Mar 15, 2009
    #2
    1. Advertising

  3. On 2009-03-14 22:40:17 -0400, Arne Vajhøj <> 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
    Owen Jacobson, Mar 15, 2009
    #3
  4. Clive

    Clive Guest

    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 <> 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, Mar 15, 2009
    #4
  5. Clive

    Clive Guest

    On Mar 14, 10:48 pm, Owen Jacobson <> wrote:
    > On 2009-03-14 22:40:17 -0400, Arne Vajhøj <> 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.
    Clive, Mar 15, 2009
    #5
  6. Clive

    Tom Anderson Guest

    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.
    Tom Anderson, Mar 15, 2009
    #6
  7. Clive

    Lew Guest

    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
    Lew, Mar 15, 2009
    #7
  8. On 2009-03-15 04:14:19 -0400, Clive <> said:

    > On Mar 14, 10:48 pm, Owen Jacobson <> wrote:
    >> On 2009-03-14 22:40:17 -0400, Arne Vajhøj <> 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
    Owen Jacobson, Mar 16, 2009
    #8
  9. Clive

    Clive Guest

    On Mar 15, 9:56 pm, Owen Jacobson <> wrote:
    > On 2009-03-15 04:14:19 -0400, Clive <> said:
    >
    >
    >
    > > On Mar 14, 10:48 pm, Owen Jacobson <> wrote:
    > >> On 2009-03-14 22:40:17 -0400, Arne Vajhøj <> 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
    Clive, Mar 19, 2009
    #9
  10. Clive

    Lew Guest

    Clive wrote:
    > [citation of every message in full]


    Please trim your posts.

    --
    Lew
    Lew, Mar 19, 2009
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. iksrazal
    Replies:
    1
    Views:
    607
  2. Digby
    Replies:
    3
    Views:
    12,997
    Jon Skeet
    Oct 15, 2003
  3. Mike S
    Replies:
    0
    Views:
    23,000
    Mike S
    Sep 16, 2004
  4. Mick
    Replies:
    2
    Views:
    9,524
    Marcin Grunwald
    Feb 23, 2005
  5. Clive

    getResourceAsStream vs JNDI

    Clive, Mar 14, 2009, in forum: Java
    Replies:
    0
    Views:
    347
    Clive
    Mar 14, 2009
Loading...

Share This Page