> It would be much nicer if there was one version of license(s) in > project and > each source file had a small pointer to them.
well, I guess you are right... but on the other hand I am using this really slick ide IDEA by intellij (http://www.intellij.com) that automatically shows me the beginning of the source code whenever I open a java file... BTW: I am not affiliated with intellij, but IDEA is the best ide I have seen in a loooong time :-) > yep. There would still need to be support inside jo! though as it > has to make > sure that it is mapped per-war. Phoenix could map it per-sar but > that still > needs to be reworked a bit for jo! > > > The way it works with JBoss is that while deploying a WAR, the > DOM tree and > > the webapps ContextClassLoader are handed to JBoss, which in > turn creates a > > "env" subcontext for "java:comp" which is specific for a > particular webapp. > > Of course that could be easily done by jo! as long as proper JNDI is > > present. > > kool. > > > How much is actually provided by the standard JNDI RI that > comes with the > > JDK. Does it have "java:comp" contexts built in? If so, it should be a > > piece of cake. If not, how difficult can that be? > > Actually JNDI is one API where you are required to write tons of > code to get > it up and running gracefully. However I mostly have this done and > it can be > grabbed from the excalibur project in the package > > org.apache.avalon.excalibur.naming.* > > You will want to create a MemoryContext per web application and > populate it > with all the things appropriate. Then you will have to create an > InitialContextFactory. This factory would get the base context for the > current web application (usually stored in a ThreadLocal variable). After > that it *should* work ;) OK - I did a bit of reading today and my understanding of the matter is the following: o To support the url "java:" a javaURLContextFactory needs to be written. see section 3.2.2 of the current spec (jndispi.pdf) o To support different environments per war (this is a necessity), the context "comp" needs to have an ObjectFactory that returns different subcontexts depending on the contextclassloader of the calling thread. This is necessary because different wars are executed by a set of threads. There is no war-to-thread one-to-one relationship. This also means that ThreadLocal does not work. However a war has always a distinct Classloader that can be used to identify the calling war. o The comp context needs to be bound at some point. When? I have never used JNDI a lot and certainly not implemented it... so just think of the things mentioned above as suggestions. but I do think they should be taken care of on the JNDI side. cheers, -hendrik -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
