On 1/16/07, Adam Lally <[EMAIL PROTECTED]> wrote:
On 1/16/07, Lev Kozakov <[EMAIL PROTECTED]> wrote: > The PEAR validation code uses UIMA ResourceManager mechanism to add several > JARs to the classpath, but it does not override the default class loader. > Therefore, the 'extension' classes, which are specified in the component > classpath, are searched in the extended classpath, but still are loaded by > the default class loader - the same class loader that loads UIMA framework > classes. I'm not sure what you mean. The UIMA ResourceManager doesn't provide any ability to do this. The only way you can use the UIMA ResourceManager to add JARs to the classpath is to set the "extension class path" which results in the creation of a new ClassLoader.
You are right - UIMAClassLoader uses standard URLClassLoader for both loading and defining classes, so we may have conflicting UIMA classes (with different class loaders) in the same context.
I believe, the problem of including UIMA JARs in PEAR packages is, > most likely, related to possible mixture of different versions of the UIMA > code. In any case, PEAR packages should not include UIMA framework code. > I don't think just having two different versions of UIMA on the classpath could result in the report "Not an Annotator" exception. The only way I see that could happen is if the framework had loaded a different Annotator interface than the component, which can only happen if the extension class loader is in use. > My general opinion is - warn developers on possible conflicts, but let them > go their own way. > 1) I believe, PEAR Packager may post a warning that adding UIMA JARs to > a PEAR package may lead to conflicts, but it should not prevent developers > from doing this, because we cannot predict all possible uses of PEAR > packages. I believe we can make some decisions about what PEAR files can and can't be used for. The intention of the PEAR is to be able to deploy the component into a UIMA runtime container of some kind. This WILL (not may) lead to conflicts if the PEAR contains UIMA framework jars. So I think it's worthwhile to prevent the user from going wrong in this way.
PEAR files might be used for deploying any resources, including shareable libraries. In fact, PEAR file is somehow similar to WAR file. When you create WAR files in WSED, it does not check JARs in your lin folder.
2) The buildComponentClassPath() method may also warn that the CLASSPATH > contains duplicated entries, but it should not ignore them. The > buildComponentClassPath() method does not control the names of the JARs > added to the CLASSPATH, so I don't believe, it could discover UIMA JARs in > the component CLASSPATH, because developers are free to use any names for > their JARs. You're right that checking jar file names is not the right thing to do. However, instead it may be possible to attempt to load UIMA framework classes (such as org.apache.uima.analysis_component.AnalysisComponent) from the classpath that the user has specified for their PEAR. If the class is able to be loaded, you will know that the PEAR is not valid. -Adam
Yes, we can check something like this in the verification code. We also need to take into account that PEAR verification has limited power and does not guarantee that the code will run in a real application. Another important thing is that the verification is done in a context (environment), which might be different from the real application context. -- Lev
