We have 2 different OSGI bundles.
In first bundle exist class which parses JSON string to MyClass.MyClass annotated by Gson annotations.MyClass located in Second bundle. I have a lot of problem with it. Eventually in debug mode I have noticed that
MyClass.class.getDeclaredField("fieldName").getAnnotation(AnnotationType.class)
returns null.
Hence CQ5 somewhere losed the annotations.
I created absolutely new project, copy parser class and MyClass to this. This code really works normally.
Eventually we have understood that 'MyClass' and Gson was loaded by different classloaders and after we began load Gson same classloader and problem has been fixed. But it is very clumsy solution.
What do you think about it?
How does it fix it more elegant?
There are two places from which your bundles can import the GSON dependency:
it can be put into the OSGi container as a standalone bundle,
it can be embedded.
In order to find out which is true in your case, open the bundle in Apache Felix console and look for com.google.gson in the Imported Packages section. If it looks like this:
com.google.gson,version=2.2.4 from com.google.gson (343)
it means that your bundle imports GSON from standalone bundle 343 (case 1). On the other hand, if there is no such entry, but you can find GSON jar name:
gson-2.2.4.jar
in the Bundle Classpath, it means that you are embedding GSON into your bundle (case 2).
You found out that the cause of the problem is that GSON library in bundle1 and bundle2 is loaded by different class loaders. It means that at least one bundle uses the embedded version of the library (case 2) rather than the standalone (case 1). In order to fix this, you need to review <Embed-Depdency> directive of maven-bundle-plugin in pom.xml and remove gson from there. You may also try changing the scope of gson in your <dependencies> section to provided.
Related
I'm currently using hibernate-4.1.4 and jersey-2.22. These have javassist-3.15 and javassist-3.18 respectively.
I included both hibernate and jersey in my project and to my surprise, there were no dependency conflicts between the said javassists.
I was wondering how Java tells hibernate to use 3.15 and how it tell jersey to use 3.18 since both are in the build path. Is one javassist not being used?
Follow up question: Let's say that javassist-3.15 and javassist-3.18 have a conflict with each other. How do I resolve this? Do I disable both javassists and include one externally?
EDIT: My app is a web app that runs on Tomcat 7. We don't use Maven/Gradle. We just configure the dependencies by putting the jars in the build path using Eclipse.
JAVA loads classes through ClassLoaders ... Many applications servers, as Tomcat or Wildfly, implement and use their own class loaders (not the regular ones of the common JDK) ... So you must check the Tomcat documentation to read about its classloading behaviour...
After saying that, is very likely that Tomcat is loading libraries in alphabetical order. I Explain...
Suppose that you use a class named: Dummy, and this class is contained at the libraries: dummy-1.0.jar and dummy-1.1.jar ... when the class Dummy is requested, the Tomcat ClassLoader search for that class definition, looking first at dummy-1.0.jar and later at dummy-1.1.jar ... given that dummy-1.0.jar contains that class, Tomcat stops looking a returns that class version ... If dummy-1.0.jar would not have the target class, the dummy-1.1.jar class version would be returned instead...
(I suggest to try this to validate the container behaivour, it's not so hard to implement)...
And yes, if javassist-3.15 and javassist-3.18 conflicts with each other, you should remove them and pick the javassist JAR more
suitable for both libraries (jersey and hibernate).
As thumb rule, I tend to pick the newest library (the one with greater version), but this scheme not always work...
I use package-info.java to specify #XmlAccessorType(XmlAccessType.NONE) and some xml java adapters using #XmlJavaTypeAdapters. Model objects (with JAXB annotations) are placed in separate maven module shared by other modules. The configuration in package-info.java is not discovered if model objects are in separate maven module. If I move for testing purposes model objects to same maven module everything is OK. I think separate maven module can be considered equivalent to 3rd party lib from JAXBContext point of view. I use JDK1.7 JAXB reference implementation. Any ideas how configuration may differ?
I also encounter this problem, in my case qualified/unqualified property from package-info.java was ignored. I managed to find two way to workaround this:
like Pavla wrote, copy all JAXB classes with package-info.java locally
include module as a dependency with compile scope (which gives similar result that classes are in module. In my case I created separate jar lib with JAXB classes)
I also spotted that it do not work only in case of creating WebServices (creating object and sending to WS works fine in different modules).
I am using Jbossas7.1.1 and cxf 2.4.6. In the time of registering service Jboss created wsdl from JAXB (in my case path /opt/jboss/jboss-as-7.1.1.Final/standalone/data/wsdl/module.war/SubmitMessage.wsdl). In local setting file is generated properly.
Any ideas why creating WS behaves like this?
I hit this issue recently and the actual problem (with Java 8, i.e. no Java modules involved) was that I had on the classpath two *.jar files which both contained the same package - in one JAR, there was package-info.class with JAXB annotations and in the other one, there wasn't.
In that case, I guess that if package-info.class file is discovered depends on the classpath ordering (which is very brittle and only semi-deterministic).
I am using Apache Felix to create an embedded OSGi host application. I am using the following code to expose the packages I want to expose:
List<String> extra = new ArrayList<>();
extra.add("some.example.packag.to.expose.1");
extra.add("some.example.packag.to.expose.2");
extra.add("some.example.packag.to.expose.3");
config.put(Constants.FRAMEWORK_SYSTEMPACKAGES_EXTRA, extra.toString().replace("[","").replace("]", ""));
Everything works great and these packages are exposed. However, I need the bundles to have access to ALL the host project declared dependencies. So for example the parent application has Jackson, Apache (various), etc. declared and I need the bundles to have access to these.
I tried adding the packages explicitly but that does not seem to do the trick when they are dependencies. So for example in the bundle I want to use Jacksons com.fasterxml.jackson.core.type.TypeReference; so I added com.fasterxml.jackson.core.type to the above EXTRA list but it does not appear to solve the problem, the package still doesn't get exposed.
In a perfect work I just want to make ALL the host dependencies available without having to explicitly state each one.
You will have to configure each package. In OSGi you would normally install the dependencies as bundles. So the settings do not suppot to mass export system packages.
I want to use Apache POI in OSGi to write an Excel workbook with the streaming, OOXML API (SXSSF). The streaming API is available since POI 3.9.
As the latest Apache POI 3.11 jars are not bundles: What's the best way to get POI working in OSGi?
I tried two approaches:
embed the jars directly in the only bundle which will be using them
use POI jars prewrapped as bundles
I am despairing in getting all dependencies together.
First about embedding the POI jar in my bundle: my bndtools file contains
-buildpath: \
...
libs/dom4j-1.6.1.jar;version=file,\
libs/poi-3.11.jar;version=file,\
libs/poi-ooxml-3.11.jar;version=file,\
libs/poi-ooxml-schemas-3.11.jar;version=file
Private-Package: \
...
org.openxmlformats.schemas.*,\
org.apache.poi.*,\
org.dom4j.*,\
com.microsoft.schemas.office.x2006.*,\
schemaorg_apache_xmlbeans.*,\
schemasMicrosoftComOfficeExcel.*,\
schemasMicrosoftComOfficeOffice.*,\
schemasMicrosoftComVml.*
This results in a bundle which imports many, many things like for example org.bouncycastle.asn1.x509 and org.junit. I don't plan to encrypt or test in my application - so these two are probably somehow "optional". How can I specify this? Is there a good way of collecting all these dependencies?
Note: at least org.apache.commons.codec and com.sun.msv.datatype.xsd.lib are additionally required, but they are already bundles.
Using prewrapped jars, I tried using org.apache.servicemix.bundles.poi 3.9_2. This also requires dom4j so I used the prewrapped org.apache.servicemix.bundles.dom4j but that requires at least version 1.0 of javax.xml.stream which my JVM/Felix OSGi advertises as "only" version 0.0.0.1_007_JavaSE. I fixed this by hand (ugly), but then got stuck on another dependency.
What's the good way?
We use Gradle with bnd-platform to build OSGi bundles for our applications based on Maven dependencies.
No sure if this is "the good way", but this is how we build the target platform for our OSGi based applications, Apache POI being part of that. It's especially useful in cases where you have to do adaptions to bundles (e.g. make JUnit optional) or merge JARs (e.g. due to classloading issues in OSGi) to make them work.
I set up an example build with an Apache POI bundle (and implicitly, its POM-defined dependencies) on GitHub. You can clone it (sample-poi branch) and try it running ./gradlew clean bundles. Created bundles will be in build/plugins.
Please note that any optional Maven dependencies will not be included by default and have to be added manually to the build, if you need them (due to limitations in Gradle).
I don't have a working example of this work around but this bit of documentation may be helpful to you.
Can POI be used with OSGI?
Starting with POI 3.16 there's a workaround for OSGIs context
classloader handling, i.e. it replaces the threads current context
classloader with an implementation of limited class view. This will
lead to IllegalStateExceptions, as xmlbeans can't find the xml schema
definitions in this reduced view. The workaround is to initialize the
classloader delegate of POIXMLTypeLoader , which defaults to the
current thread context classloader. The initialization should take
place before any other OOXML related calls. The class in the example
could be any class, which is part of the poi-ooxml-schema or
ooxml-schema:
POIXMLTypeLoader.setClassLoader(CTTable.class.getClassLoader());
I have updated our projects (Java EE based running on Websphere 8.5) to use a new release of a company internal framework (and Ejb 3.x deployment descriptors rather than the 2.x ones). Since then my integration Tests fail with the following exception:
[java.lang.ClassNotFoundException: com.ibm.xml.xlxp2.jaxb.JAXBContextFactory]
I can build the application with the previous framework release and everything works fine.
While debugging i noticed that within the ContextFinder (javax.xml.bind) there are two different behaviours:
Previous Version (Everything works just fine): None of the different places brings up a factory class so the default factory class gets loaded which is com.sun.xml.internal.bind.v2.ContextFactory (defined as String constant within the class).
Upgraded Version (ClassNotFound): There is a resource "META-INF/services/javax.xml.bind.JAXBContext" beeing loaded successfully and the first line read makes the ContextFinder attempt to load "com.ibm.xml.xlxp2.jaxb.JAXBContextFactory" which causes the error.
I now have two questions:
What sort is that resource? Because inside our EAR there is two WARs and none of those two contains a folder services in its
META-INF directory.
Where could that value be from otherwise? Because a filediff showed me no new or changed properties files.
No need to say i am going to read all about the JAXB configuration possibilities but if you have first insights on what could have gone wrong or help me out with that resource (is it a real file i have to look for?) id appreciate a lot. Many Thanks!
EDIT (according to comments Input/Questions):
Out of curiosity, does your framework include JAXB JARs? Did the old version of your framework include jaxb.properties?
Indeed (i am a bit surprised) the framework has a customized eclipselink-2.4.1-.jar inside the EAR that includes both a JAXB implementation and a jaxb.properties file that shows the following entry in both versions (the one that finds the factory as well as in the one that throws the exception):
javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory
I think this is has nothing to do with the current issue since the jar stayed exactly the same in both EARs (the one that runs/ the one with the expection)
It's also not clear to me why the old version of the framework was ever selecting the com.sun implementation
There is a class javax.xml.bind.ContextFinder which is responsible for initializing the JAXBContextFactory. This class searches various placess for the existance of a jaxb.properties file or a "javax.xml.bind.JAXBContext" resource. If ALL of those places dont show up which Context Factory to use there is a deault factory loaded which is hardcoded in the class itself:
private static final String PLATFORM_DEFAULT_FACTORY_CLASS = "com.sun.xml.internal.bind.v2.ContextFactory";
Now back to my problem:
Building with the previous version of the framework (and EJB 2.x deployment descriptors) everything works fine). While debugging i can see that there is no configuration found and thatfore above mentioned default factory is loaded.
Building with the new version of the framework (and EJB 3.x deployment descriptors so i can deploy) ONLY A TESTCASE fails but the rest of the functionality works (like i can send requests to our webservice and they dont trigger any errors). While debugging i can see that there is a configuration found. This resource is named "META-INF/services/javax.xml.bind.JAXBContext". Here are the most important lines of how this resource leads to the attempt to load 'com.ibm.xml.xlxp2.jaxb.JAXBContextFactory' which then throws the ClassNotFoundException. This is simplified source of the mentioned javax.xml.bind.ContextFinder class:
URL resourceURL = ClassLoader.getSystemResource("META-INF/services/javax.xml.bind.JAXBContext");
BufferedReader r = new BufferedReader(new InputStreamReader(resourceURL.openStream(), "UTF-8"));
String factoryClassName = r.readLine().trim();
The field factoryClassName now has the value 'com.ibm.xml.xlxp2.jaxb.JAXBContextFactory'
Because this has become a super lager question i will also add a bounty :)
I will work the entire day on this and let you know if there is any news.
Update/ Solution
This question has been solved. The original problem has occured because misconfiguration of complexly build multi model maven projects which one dependency used a updated version of a customized eclipse link jar that contained a definition for a JAXBFactory not available in the component where the error occured. Setting the JAXB context factory in most cases is configured with a jaxb.propertie file or JAXBContext file that contains the same definition. Detailed loading process of the appropriate JAXBContextFactory happens in javax.xml.bind.ContextFinder.
The error has not yet been solved (during the fact over 4 major EE/SE Applications lead to the error) and there is no general answer but that defined JAXBContextFactorys must exist in your classpath (wow what a wonder...) so you either have a that ClassNotFound Error because youre missing resources (well thats the acctual cause) or because you have a wrong JAXBContextFactory defined in any of the above mentioned propertie files which contain a definition according to the below answer.
Very many thanks for your great comments and support, i realy appreciate!
You can include a jaxb.properties file in the same package as your domain model to specify the JAXB (JSR-222) implementation you wish to use. For example it would look like the following to specify EclipseLink MOXy as your JAXB provider.
javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory
For More Information
http://blog.bdoughan.com/2011/05/specifying-eclipselink-moxy-as-your.html
Another quick and dirty solution (a workaround, really) that worked for me is to explicitly include a JAXB implementation to the maven build. For example
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.2.7</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.2.7</version>
</dependency>
Note that this adds a somehow unnecessary dependency to your build, as JAXB obviously already is part of each JRE >= version 6.
Most likely this will only work when the WAS classloader is set to parent last.