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 <[email protected]> wrote: > Benjamin, > > 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. > > Jan > > On 18 September 2013 08:50, Benjamin Zuill-Smith <[email protected]> > 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 <[email protected]> wrote: > >> > >> Benjamin, > >> > >> You can have a look at the junit tests for jetty-jndi, specifically > >> this one: > >> > https://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-jndi/src/test/java/org/eclipse/jetty/jndi/java/TestJNDI.java > >> > >> 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 <[email protected] > > > >> 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 > >> > [email protected] > >> > https://dev.eclipse.org/mailman/listinfo/jetty-users > >> > > >> > >> > >> > >> -- > >> Jan Bartel <[email protected]> > >> www.webtide.com > >> 'Expert Jetty/CometD developer,production,operations advice' > >> _______________________________________________ > >> jetty-users mailing list > >> [email protected] > >> https://dev.eclipse.org/mailman/listinfo/jetty-users > > > > > > > > > > -- > > Benjamin Zuill-Smith > > > > _______________________________________________ > > jetty-users mailing list > > [email protected] > > https://dev.eclipse.org/mailman/listinfo/jetty-users > > > > > > -- > Jan Bartel <[email protected]> > www.webtide.com > 'Expert Jetty/CometD developer,production,operations advice' > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Benjamin Zuill-Smith
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
