Mailing-List: contact user-help@uima.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@uima.apache.org
Received-SPF: pass (nike.apache.org: domain of holmberg2066@comcast.net
 designates 76.96.30.16 as permitted sender)
Date: Tue, 12 Feb 2013 09:21:56 +0000 (UTC)
From: Greg Holmberg <holmberg2066@comcast.net>
To: Tommaso Teofili <tommaso.teofili@gmail.com>
Cc: uima user <user@uima.apache.org>
Message-ID: 
 <712917503.1118859.1360660916591.JavaMail.root@sz0143a.emeryville.ca.mail.comcast.net>
In-Reply-To: 
 <CAGnSx06RHvQHGpofVG2MgOxGfVrmub6yjMddvPDXeVk6zUUmtQ@mail.gmail.com>
Subject: Re: Clerezza and UIMA
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_1118858_47829583.1360660916591"

------=_Part_1118858_47829583.1360660916591
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Hi Tom maso-- 


Regarding the classloader, the purpose is to make the UIMAClassLoader the default for the thread. The UIMAClassLoader has all the classes in the AE Pear (which the boot classloader doesn't have--i.e. they weren't on the command-line -cp). Without it being the default for the thread, some dynamically loaded classes can't be found. For example, when using the Clerezza libs, if I leave out the line that says thread.setContextClassLoader(uimaClassLoader), then I get: 

org.apache.clerezza.rdf.core.serializedform.UnsupportedSerializationFormatException: No serializer available for application/rdf+xml 
at org.apache.clerezza.rdf.core.serializedform.Serializer.serialize(Serializer.java:142) 

I'm guessing that the serializers (implementations of an interface) ARE loaded dynamically, and can be found in the org.apache.clerezza.rdf.jena.serializer Jar, which is in the Pear file, but not on the command line classpath. Somehow, when the above method, called from my annotator's process() method somewhere below AnalysisEngine.process(), tries to load those classes, it doesn't use the UIMA classloader, but rather the thread's context classloader, which falls back to the boot loader, which can't find them. 

On the other hand, if I do set the thread's context classloader to the UIMA classloader, then I get the LinkageError for Xerces: 

Exception in thread "TAService Worker 0" java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method "org.apache.xerces.dom.ElementImpl.getSchemaTypeInfo()Lorg/w3c/dom/TypeInfo;" the class loader (instance of org/apache/uima/internal/util/UIMAClassLoader) of the current class, org/apache/xerces/dom/ElementImpl, and the class loader (instance of <bootloader>) for interface org/w3c/dom/Element have different Class objects for the type m/TypeInfo; used in the signature 

So it seems I'm damn if I do, damned it I don't. How do I get out of this catch-22? 

By the way, I'm using Oracle JDK 1.7.0_10, in case that matters. I'll also try going back to 1.6.0 tomorrow to see if that makes any difference. 


Thanks, 

Greg 


----- Original Message -----
From: "Tommaso Teofili" <tommaso.teofili@gmail.com> 
To: "Greg Holmberg" <holmberg2066@comcast.net> 
Cc: "uima user" <user@uima.apache.org> 
Sent: Monday, February 11, 2013 12:35:56 AM 
Subject: Re: Clerezza and UIMA 


H Greg, 


the code you're referring to [1] is used essentially for OSGi deployments, where each bundle (the package jars) have their own Classloader and essentially that would create issues when trying to instantiate AEs whose classes are in different bundles than the one which "contains" the UIMA framework. 
The way it works is just that each bundle which needs to use UIMA has to declare its UIMA components into an OSGi activator extending the UIMABundleActivator and thus implementing the #classRegistered method, see an example: 


@Override
  protected void classRegistered() {
    classLoaderRepository.registerComponent(SomeAnnotator.class);
  } 


In the code you've shown it seems you're redefining the Classloader instance to be used by UIMAFramework and also forcing it into the current thread, as far as I have seen this is often done in OSGi deployments but I wonder if that's your scenario or not, and if not which container are you trying to instantiate UIMA into so that we can better understand what's the linkage problem coming from. 


Regards, 
Tommas 


[1] : http://svn.apache.org/repos/asf/incubator/clerezza/trunk/uima/uima.utils/ 


2013/2/7 Greg Holmberg < holmberg2066@comcast.net > 


Hi Tommaso-- 


Sorry for the direct email, but you seem to be the expert on combining UIMA and Clerezza. 

I'm trying to generate RDF from my UIMA AE. I started with the code in RDFCASConsumer.java and modified it to change the directory and file to which the RDF is written. 

I put this in my AE and deployed it in UIMA, running in my own container. This container does this: 

AnalysisEngine engine = UIMAFramework.produceAnalysisEngine(...); 
ClassLoader uimaClassLoader = engine.getResourceManager().getExtensionClassLoader(); 
Thread thread = Thread.currentThread(); 
thread.setContextClassLoader(uimaClassLoader); 
engine.process(cas); 

When I run I get: 

Exception in thread "TAService Worker 0" java.lang.LinkageError: loader constraint violation in interface itable initialization: when resolving method "org.apache.xerces.dom.ElementImpl.getSchemaTypeInfo()Lorg/w3c/dom/TypeInfo;" the class loader (instance of org/apache/uima/internal/util/UIMAClassLoader) of the current class, org/apache/xerces/dom/ElementImpl, and the class loader (instance of <bootloader>) for interface org/w3c/dom/Element have different Class objects for the type m/TypeInfo; used in the signature 


I see several issues in Clerezza about UIMA and classloaders, which you have resolved. There's even a method that gets the classloader to be used for XML parsing. 

So it seems like you've probably solved this problem related to Xerces and classloaders. However, I can't find any documentation about how to use your fix. 

Can you tell me what I need to do when creating my analysis engine and setting the classloader in order to avoid this LinkageError? 

Thanks, 


Greg Holmberg 


------=_Part_1118858_47829583.1360660916591--