From: "Conor MacNeill" <[EMAIL PROTECTED]> > Jose Alberto Fernandez wrote: > > > Hi, > > > > I really cannot understand the current behavior of > > <classpath> within <weblogic> when also defining > > <wlclasspath>. Can someone please explain to me how it > > is supposed to work? > > > Ok. It is in some respects a function of backward compatability and evolution. > > Prior to 1.4, there was just the classpath. It was used both when loading > classes for super class checking and also when running weblogic.ejbc. > > In 1.4, with weblogic 6, weblogic started to complain about classes being in > the > jars and also being in the classpath. The classpath was still needed for the > superclass check, but it was desirable to use a separate classpath when > running > weblogic.ejbc. Backwar compatability required the standard classpath be used > if > the weblogic classpath was not set. > > Classes which are in the generated jars should not appear in the weblogic > classpath but may be required for the superclass check. > > In Ant 1.5, this is still undergoing development. The superclass check which > previously was performed by reflection, will now be preformed by BCEL. This > does > not require a complete classpath to examine the classes. The classpath > attribute > will have become redundant. > > For weblogic, the wlclasspath is used to invoke weblogic.ejbc unless it is > not > provided, in which case classpath is used. > > > > > > It seems to be ignored, which would be a bug, but > > maybe I am misunderstanding its use. This is the > > behavior I am experiencing at the moment. > > > Using 1.5 alpha?
Yes, since this is the only one supporting EJB 2.0. BTW, is there any vendor still supporting EJB1.1 only? I think ejbjar should move on to support EJB2.0 which is the current standard and let EJB1.1 be supported as much as possible as long as it does not mess up 2.0 support. > > > > > > If the EJB has dependencies on things in the > > <classpath> I get errors from EJBC about classes not > > found. If I put them in <wlclasspath> they work > > but I may get warnings about things in the CLASSPATH > > that should not be there. > > > Early versions of the 1.1 EJB spec stated that all dependent classes must be > contained in the jar. Indeed, Weblogic hot deploy did not work if there were > dependencies outside the EJB jar. <ejbjar> went halfway toward this by adding > in > super interfaces and super classes. <support> was added for other cases. It > wasn't perfect. > I really do not care about EJB 1.1, the current standard is 2.0 and in the case of Weblogic it has been out for quite a while. I see no reason for us trying to support 1.1 beter than 2.0. Still with that in mind, I still need <support> because not all classes needed in my jars can be found by reflection. Some parts of my application need to be loaded based on configuration and therefore use loadClass(String). So I still need <support> to specify those. How do I make sure that resources get packaged correctly? Maybe we need a <resources> element as well. > The current 2.0 spec says the jar must include all classes used by the bean > unless the jar provides those classes by class-path references in its > manifest. > This is fine in the spec and I am using it (I even pass that info in the "manifest" provided for <ejbjar>). I am nor sure <ejbjar> needs to enforce such things because there may be issues with respect to the order in which jars are build. You just need to be able to say "resolve any additional classes for this classpath but do not package them". <ejbjar> I think is doin this correctly today, at least I see less classes in the jars when I set thigs properly. > In some respects this is a transition in J2EE from beans to ears as the unit > of > deployment. > EARs are my unit of deployment. But I still need to build the EJB jars. > > If I put them in "srcdir" > > then it works as expected but it puts this classes as > > part of the EJBjar whch I do not want (they are > > supposed to be picked up from the jar Class-Path. > > > You may have noticed a recent bit of refactoring in the ejbjar code. The goal > of > this was to do a few things > > 1. Decouple ejbjar from BCEL. If you don't want to add in additional classes, > you won't need BCEL. > > 2. Specify which additional classes are to be added to the jar. "None" will > be > an option, as will "super" and "full". The latter two require BCEL. > How about classes used as parameters and such, you need to be able to say that. > 3. Specify where you want the additional classes to end up. The options being > in > the ejbjar itself or added to some support jar, which you would then > reference > in the Class-Path. This would include any <support> files added. > > I've done step 1, Step 2 should be easy. Step 3 require a bit more work. > I think you are over designing a bit. I would argue that you are already 90% there and this options just complicate instead of help. Let me tell you how I see it since I am now using your stuff regularly. "srcdir": while constructing the jar only put classes found here. ejbjar/classpath: used by BCEL for any classes not in "srcdir" but do not add classes from here. ejbjar/support: try to put things in here on the jar (and use BCEL with the same rules as for classpath). Is this smart enough as to understand the difference between .class files and other resources one may want added in the jar? ejbjar/weblogic/wlclasspath: the CLASSPATH for the JVM running weblogic. ejbjar/weblogic/classpath: path for EJBC -classpath option. Which I hope it makes available correctly so that EJBC is happy while inspecting the jar. Additionally, what would be nice is a way to ask <ejbjar> to create a clientjar with all the classes needed by clients. Maybe this should be a separate <task>. In any case, if you look at the list above, the current <ejbjar> does most of it, it is just a little extra that is needed. > If you want to help test it out, that would be cool. > Sure, with as much time as I can manage (that is my problem these days). Jose Alberto -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
