Hey Conor, I believe it is definitely worth the effort. I think the biggest issue that will arise as a result of this change will be the erroneous use of the affected tasks by basic users. No matter how well it is documented, in the end it will require some knowledge of class loaders on the part of even the basic user. If the system/ejbc class loaders are initiated with overlapping class data, knowledge of class loaders will be necessary in order to figure out the bad parameters passed to the task. But, like I said originally, this is a necessary change and these eventualities will just have to be dealt with.
john -----Original Message----- From: Conor MacNeill [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 09, 2000 9:27 AM To: Ant-Dev Apache. Subject: Classloader improvements for EJBC Hi, This is a long (and pretty technical) message. I am attaching updated versions of the AntClassLoader and the EJBC classes rather than committing the changes since this change may be a little controversial in it use of Java's classloading facilities. Before I get into that let me give the benefits of this change. This change allows the ejbc helper class and weblogic's ejbc compiler to be run within the ant VM. The helper class now has access to the ant Project object and uses that to determine if Jikes is bieng used for the compiler. If so it is also used for ejbc operations. The problem is with the work the code has to do to ensure the right classes end up in the right class loader. It is a little messy. There is a tricky problem with classloaders when the classpaths of the classloader and the system class loader overlap. That is a class file exists in both the system class path and the classpath defined for the class loader. This overlap can have undesirable side effects as follows: 1. A class, loaded through different loaders is not considered to be the same class. This means that an instance cannot be assigned to a reference even if it is the same underlying class. Attempts to do so will generate a ClassCastException. This issue is pretty well known. 2. Any classes which are subsequently loaded by a class use the same class loader as was actually used to load the class. For those of you familiar with the terms, a class uses its defining class loader and not its initiating class loader. If the next class to be loaded only exists in the classpath of the other class loader, the class will not be found, even if that other class loader is the initiating class loader. Classes to be loaded fall into three categories. Those which only exist in the system classpath, those which only exist in the loader's classpath and those which exist in both classpaths. In the first two cases the loader to use is obvious. The tricky issue is to handle the loading of classes which exist on the classpath of both loaders. The behaviour described in the classloader documentation is to always try and load from the system classpath first. This approach guarantees that classes loaded will always be compatible with references in the system classpath. The drawback comes when those loaded classes attempt to load other classes which are in the loader's classpath but not in the system classpath. These subsequent classes will not be found. In the situation of the ejbc task, I wanted to communicate from the ejbc task to the helper task through an interface (rather than reflection). The ejbc task and the interface are thus loaded on the system class loader. Since I want the helper to access classes not on the classpath, I want it loaded into the customer class loader, even though it exists on the system classpath. The helper class loads weblogic.ejbc, which may or may not exist on the classpath, depending on each user's setup. Finally weblogic.ejbc deserialises a deployment descriptor which will depend on classes which will most likely not exist on the system classpath, since they are part of the project being built by ant. So, we have the interface and ant classes loaded on the system loader. The helper class and weblogic.ejbc must be loaded on the custom class loader even though they may be available in the system class path. I have added facilities to the AntClassLoader to allow you to control the class loading to meet these needs. Firstly the behaviour of loading from the system classpath first can be reversed. The loader can be configured to consult its own classpath first and then the system loader. That change is not sufficient since it would try to load ant classes onto the ant loader and not the system loader. Therefore I also allow pareticular package roots to be designated as system package roots. All classes, whose package begins with that root will load from the system class first. Ejbc does the following loader.addSystemPackageRoot("org.apache.tools.ant"); loader.addSystemPackageRoot("javax"); Javax is required as a system package root because weblogic supplies its own javax.swing and javax.accessibility classes. If these are loaded in place of the standard system classes, Linkage errors can result (violation of loader constraints). The javax packages which are not present in the system classpath (javax.ejb) will be loaded in the ant loader. If you got this far, I'd like your opinions on whether all this mucking around with class loaders is worth the convenience it gives. Can the Jikes support be provided over the current parameter based interface, even if it is a bit klunky. Conor
