Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Testing with JNDI

Ah, that clears a few things up for me. I forgot about that reference in the web.xml, and now I understand what it's there for. Thanks Jan, this has been very helpful!

On Tue, Sep 17, 2013 at 4:29 PM, Jan Bartel <janb@xxxxxxxxxxx> wrote:

Not sure I still understand what you are trying to do.  If you do new
Resource(_server, "jndiName", myobject) then you cannot reference it
inside your webapp inside of java:comp/env namespace unless you have a
web.xml <resource-ref> setup for it to bind it in there (that's using
the normal jetty WebAppContext and related classes).

If you're saying you want to do new Resource(_server, "jndiName",
myobject) and then reference it in other code as
java:comp/env/jndiName  and you don't want to use the usual
WebAppContext and related classes, then you should:

1. call Resource foo = new Resource(_server, "jndiName", myobject)
2. create a separate fake classloader and set that one up on the
ServletContextHandler or ContextHandler
3. set the fake classloader as the thread context classloader
4. call foo.bindtoENC("jndiName");
5. start your ServletContextHandler or ContextHandler

Steps 2-3 is only necessary if the ContextHandler or
ServletContextHandler creates its own classloader in doStart() if one
is not already set - I can't remember if it does or not (WebAppContext
certainly does), but you can check the code. You just want to make
sure that the classloader that you do the bind to java:comp/env with
is the one that you will be doing the lookup with.


On 18 September 2013 08:50, Benjamin Zuill-Smith <bzuillsmith@xxxxxxxxx> wrote:
> Thanks Jan, but I think I wasn't clear on a point in my question.
> I can create and bind what I need to JNDI without all the classloader stuff
> in that test you referenced. What I was hoping for is class similar to
> WebAppContext that would allow Jetty to handle all of that for me. For
> instance, if I created Jetty instance with an arbitrary WebAppContext, and
> also a resource in my server code with something like new Resource(_server,
> "jndiName", myobject) then I would expect to have access to it within the
> webapp context without any explicit binding on my part because Jetty handles
> it. But again, I don't want use WebAppContext because my files won't be
> organized correctly. I'd rather use something like ServletContextHandler.
> I saw that test you referenced before, but I didn't fully understand the
> ClassLoader stuff. I gather that creating a class loader is somehow creating
> an isolated java:comp space for working with JNDI contexts? It's good to
> know, but doesn't seem necessary here.
> Was just hoping to skip creating JNDI contexts in my tests, but I guess I
> could refactor it all out to a class and hope I never have to look at it
> again...
> On Tue, Sep 17, 2013 at 3:21 PM, Jan Bartel <janb@xxxxxxxxxxx> wrote:
>> Benjamin,
>> You can have a look at the junit tests for jetty-jndi, specifically
>> this one:
>> As long as you've got a Thread context classloader set, you can call
>> lookup on java:comp and if it doesn't exist it will create it. You can
>> then make your own env subcontext.
>> cheers
>> Jan
>> On 18 September 2013 04:05, Benjamin Zuill-Smith <bzuillsmith@xxxxxxxxx>
>> wrote:
>> > I want to run some JUnit tests that involve a JNDI Resource. This
>> > Resource
>> > is setup with server scope as the server starts in my test. However, I
>> > can't
>> > create a webapp-like context for Jetty to setup the JNDI subcontexts
>> > like
>> > java:comp/env. Is that only done when using a WebappContext? Are there
>> > other
>> > Context classes that can be used for testing to achieve this?
>> >
>> > I can't use WebappContext because my war is not created in the testing
>> > phase
>> > and I also would rather not have test web.xml and jetty-xml descriptors,
>> > etc.
>> >
>> > For now, I put into my tests an explicit Resource at the java:comp/env
>> > context but it I would like to be able to test with code as close to the
>> > production as possible and avoid painful tests down the road.
>> >
>> > Anyone have suggestions?
>> >
>> > --
>> > Benjamin Zuill-Smith
>> >
>> > _______________________________________________
>> > jetty-users mailing list
>> > jetty-users@xxxxxxxxxxx
>> >
>> >
>> --
>> Jan Bartel <janb@xxxxxxxxxxx>
>> 'Expert Jetty/CometD developer,production,operations advice'
>> _______________________________________________
>> jetty-users mailing list
>> jetty-users@xxxxxxxxxxx
> --
> Benjamin Zuill-Smith
> _______________________________________________
> jetty-users mailing list
> jetty-users@xxxxxxxxxxx

Jan Bartel <janb@xxxxxxxxxxx>
'Expert Jetty/CometD developer,production,operations advice'
jetty-users mailing list

Benjamin Zuill-Smith

Back to the top