Populating JNDI entirely in Java code

[Benson Margulies <be...@basistech.com>]

When embedding Tomcat, I'd like to create some objects purely from code --
I don't want to bother to express them as XML  -- and then pick them up
inside webapps. Now, calling enableNaming() on Tomcat sets up a bunch of
environment, but does not actually create and JNDI objects. If I call
enableNaming(), and then make JNDI calls before calling start(), should I
expect that to work?

Re: Populating JNDI entirely in Java code

[Benson Margulies <be...@basistech.com>]

After an hour or so of debugging, I've reached the conclusion that this is
more trouble that it is worth to me.

The problem is that the naming resources are setup in the middle of the
START process. So, there's no very good way to arrange for some code to run
after the JNDI structure is in place, but before other things from the
initialization process go to use it. It was easier to just setup the webapp
class loader to share some classes with the program that embeds tomcat and
just use singleton.



On Mon, Apr 1, 2013 at 3:10 PM, Konstantin Kolinko
<kn...@gmail.com>wrote:

> 2013/4/1 Benson Margulies <be...@basistech.com>:
> > When embedding Tomcat, I'd like to create some objects purely from code
> --
> > I don't want to bother to express them as XML  -- and then pick them up
> > inside webapps. Now, calling enableNaming() on Tomcat sets up a bunch of
> > environment, but does not actually create and JNDI objects. If I call
> > enableNaming(), and then make JNDI calls before calling start(), should I
> > expect that to work?
>
> 1. No,
>
> JNDI binds to TCCL (Thread.currentThread().getContextClassLoader()).
> Before you call start() the webapp classloader is not initialized and
> has not been started. So you cannot bind your JNDI to it.
>
> 2. The magic that translates XML into java calls is called Digester
> (http://commons.apache.org/digester)
> You may start a standalone Tomcat and try to debug it.
> https://wiki.apache.org/tomcat/FAQ/Developing#Debugging
>
> The place to look into is
> org.apache.catalina.core.NamingContextListener
> That is the component that translates configuration objects created
> when parsing context.xml into JNDI objects.
>
> 3. See thread "Register static JNDI env entry dynamically" from 2 weeks
> ago.
>
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: Populating JNDI entirely in Java code

[Konstantin Kolinko <kn...@gmail.com>]

2013/4/1 Benson Margulies <be...@basistech.com>:
> When embedding Tomcat, I'd like to create some objects purely from code --
> I don't want to bother to express them as XML  -- and then pick them up
> inside webapps. Now, calling enableNaming() on Tomcat sets up a bunch of
> environment, but does not actually create and JNDI objects. If I call
> enableNaming(), and then make JNDI calls before calling start(), should I
> expect that to work?

1. No,

JNDI binds to TCCL (Thread.currentThread().getContextClassLoader()).
Before you call start() the webapp classloader is not initialized and
has not been started. So you cannot bind your JNDI to it.

2. The magic that translates XML into java calls is called Digester
(http://commons.apache.org/digester)
You may start a standalone Tomcat and try to debug it.
https://wiki.apache.org/tomcat/FAQ/Developing#Debugging

The place to look into is
org.apache.catalina.core.NamingContextListener
That is the component that translates configuration objects created
when parsing context.xml into JNDI objects.

3. See thread "Register static JNDI env entry dynamically" from 2 weeks ago.


Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org