Using Mule IDE version 3.2.3 to invoke JAX-WS web service. In the "Import WSDL" dialogue after entering the WSDL URL and package name the JAX-WS client generation fails with error message
Error generating from WSDL: Thrown by JAXB : A class/interface with same name is already in use. Use a class customization to resolve this conflict.
How do I specify jaxb customization in Mule IDE?
What you are covering with the black colour is key to resolve this issue. Are you sure you are not using a reserved class, or a package name already taken?
Just try with org.example.helloWorld and let us know if it still fails.
Related
I’m trying to use JAXB 2.2.11 in an osgi environment (Liferay DXP). I am having issues creating a JAXBContext. Based on some other sources found while researching like this and this, I have determined that in an osgi container I need to provide the correct classloader for JAXB to instantiate the context. So I have code like this:
ClassLoader cl package.with.jaxb.objects.ObjectFactory.class.getClassLoader();
JAXBContext jc = JAXBContext.newInstance("package.with.jaxb.objects ", cl);
This code causes a null pointer exception with the following stack trace:
Caused by: java.lang.NullPointerException
at javax.xml.bind.ContextFinder.handleClassCastException(ContextFinder.java:129)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:201)
at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:146)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:371)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:446)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:409)
Looking at the source for ContextFinder I can see that context must be null on line 129:
throw handleClassCastException(context.getClass(), JAXBContext.class);
I thought perhaps the problem was that my module has a dependency on jaxb-api 2.2.11 but the jaxb-impl classes are provided by rt.jar at runtime and are probably newer than 2.2.11 because Liferay DXP runs on JDK 1.8. To get around this issue, I have tried including jaxb-impl.jar 2.2.11 as a dependency in my osgi module, thinking then the jaxb-api & jaxb-impl versions would match. After that, trying to create a JAXBContent using the same code as above results in the following error:
ClassCastException: attempting to cast jar:file:/C:/Program%20Files/Java/jdk1.8.0_144/jre/lib/rt.jar!/javax/xml/bind/JAXBContext.class to bundleresource://623.fwk616113009:13/javax/xml/bind/JAXBContext.class. Please make sure that you are specifying the proper ClassLoader.
By the looks of this message, the JAXBContext that is getting instantiated is from the version of JAXBContext that is loaded via rt.jar. This is very confusing to me because I would expect the version of JAXBContext loaded by my module’s classloader to be used since I’ve included jaxb-impl.jar in my module and I’ve specified my module’s classloader is the one to be used in my call to JAXBContext.newInstance. Can anyone shed some light on how I can get jaxb 2.2.11 to work in an osgi container?
*Please note that I can’t upgrade the version of jaxb-api used by my module because the JAXB code is actually in a 3rd party jar that requires jaxb 2.2.11 (I have just eliminated the 3rd party jar from the equation for now by writing some test JAXB code).
After extensive research I found the following solution. Since it seemed like passing the bundle class loader as suggested by the accepted answer in this post had to be correct, I followed the path of figuring out why I was getting a NullPointerException when I tried that. After carefully looking over the source code for jaxb-api to follow the stack trace of the NullPointerException, I could see that the jaxb-api code does things like
classLoader.loadClass("com.sun.xml.internal.bind.v2.ContextFactory")
where classLoader is my bundle's class loader (since that's what I passed in) and ContextFactory is actually a class in jaxb-impl which is loaded by the bootstrap class loader. This is where the problem lies because my
bundle's classloader isn't going to be able to see classes loaded by the bootstrap class loader. This threw me for a while because I'm not used to how class loaders work in osgi. I incorrectly was thinking the classes loaded by the bootstrap class loader would be visible because I'm used to web app class loading where there is delegation. In osgi class loaders
are completely isolated from each other, things are only visible if they are exported. To get around the issue I found some helpful posts talking about similiar issues. It turns out there is a concept
called boot delegation in osgi where you can specify a list of classes/packages to always be loaded via the bootstrap classloader. So the end result is two steps:
1) Switch the thread's class loader to your bundle class loader before calling the code to get the JAXBContext:
ClassLoader currentClassLoader = Thread.currentThread().getContextClassLoader();
try {
// ObjectFactory here is in the same package as my classes to be marshalled
ClassLoader objectFactoryClassLoader = ObjectFactory.class.getClassLoader();
Thread.currentThread().setContextClassLoader(objectFactoryClassLoader);
// JAXB code goes here
} finally {
Thread.currentThread().setContextClassLoader(currentClassLoader);
}
2) Specify packages to be loaded using the boot delegation mechanism. This list needs to include the transitive dependencies of the classes you need loaded. In my case, I'm using Liferay so the list
is specific to Liferay and it goes in portal-ext.properties configuration file. Luckily I found this post where someone had done most of the work for me:
module.framework.properties.org.osgi.framework.bootdelegation=\
__redirected,\
com.liferay.aspectj,\
com.liferay.aspectj.*,\
com.liferay.portal.servlet.delegate,\
com.liferay.portal.servlet.delegate*,\
com.sun.ccpp,\
com.sun.ccpp.*,\
com.sun.crypto.*,\
com.sun.image.*,\
com.sun.jmx.*,\
com.sun.jna,\
com.sun.jndi.*,\
com.sun.mail.*,\
com.sun.management.*,\
com.sun.media.*,\
com.sun.msv.*,\
com.sun.org.*,\
com.sun.syndication,\
com.sun.tools.*,\
com.sun.xml.*,\
com.yourkit.*,\
org.eclipse.persistence.internal.jaxb,\
org.eclipse.persistence.internal.jaxb.*,\
javax.xml.*,\
sun.*
Helpful links:
Why can't JAXB find my jaxb.index when running inside Apache Felix?
What is the difference between bootdelegation and DynamicImport-Package in osgi
https://web.liferay.com/web/user.26526/blog/-/blogs/liferay-dxp-and-weblogic-
https://dev.liferay.com/develop/tutorials/-/knowledge_base/7-0/bundle-classloading-flow
http://apache-felix.18485.x6.nabble.com/Classloading-for-JAXB-td4834670.html
Here is the workaround that worked for me using JDK 11, Liferay DXP/7.2, OSGI, with a sample Jax-RS web service created from Dev Studio. The error I was getting was as follows when trying to access the web service:
JAXBException occurred : Implementation of JAXB-API has not been found
on module path or classpath..
com.sun.xml.internal.bind.v2.ContextFactory cannot be found by
org.apache.aries.jax.rs.whiteboard_1.0.4.
What worked for me was to define the context factory at the system level to override the predefined context factory. Add the following system variable to your system
javax.xml.bind.JAXBContextFactory=com.sun.xml.bind.v2.ContextFactory
For example you can add this in your setenv.sh/bat file in Tomcat, or in eclipse you can access your server Launch Configuration, Arguments tab, under VM arguments
-Djavax.xml.bind.JAXBContextFactory=com.sun.xml.bind.v2.ContextFactory
This worked without adding any extra libraries since Liferay already has those libraries included.
How does this work? Refer to the javadoc for JaxBContext and read the Discovery of JAXB implementation Section. Using the /META-INF/services/javax.xml.bind.JAXBContext file did not work for me.
I hope this helps someone.
One final note for DXP users, if you get a permission denied on your service then you need to read about Service Access Policies
The best place to see how it should be done is Apache Karaf. It doesn't install any JAXB-API bundle - instead it uses org.apache.servicemix.specs.jaxb-api-2.2-2.7.0.jar inside lib/endorsed directory.
This way you won't use JAXB-API provided by rt.jar.
For implementation - it's best to use ServiceMix version of JAXB bundles:
org.apache.servicemix.bundles:org.apache.servicemix.bundles.jaxb-impl:2.2.11_1
org.apache.servicemix.bundles:org.apache.servicemix.bundles.jaxb-xjc:2.2.11_1
How do I configure mule to use a class customization tool when generating the JAX-WS classes from a WSDL?
I cannot modify the WSDL and I get the following error in Mule Studio:
"A class/interface with the same name "xxx.xxx" is already in use. Use a class customization to resolve this conflict."
Any help will be greatly appreciated.
Run wsimport with the -B-XautoNameResolution (no spaces)
I'm using Oracles Service Bus (OSB) and I'm trying to use an XSD in my WSDL that has the following schemaLocation in its XSD import:
schemaLocation="http://docs.oasis-open.org/wsn/br-2.xsd"
My problem is that OSB is not able to resolve this dependency and gives me error :
"The dependency mapping is not configured in WSDL resource".
I'm able to do a work around by importing the XSD into the OSB project and use a relative path to the resource (schemaLocation="../myXSDs/br-2.xsd"), but I don't want relative paths, especially when I shouldn't need one.
So how can I use an URL directly as an XSD resource in OSB? and if not, why? Security reasons??
my software stack is as follows:
OSB (version 11.1.1.7.0)
OEPE (11.1.1.7.0) (inc. Weblogic Server 10.3.6.0)
Friendly regards from a service oriented developer :-)
For an java web application, I got this error when using JRE 1.6.0_22
java.lang.SecurityException: class "org.apache.log4j.Logger" does not match trust level of other classes in the same package
However, it works fine when using JRE 1.6.0_13.
I searched in Google, and find the there is a security enhancement since update 19.
And for this exception, it says,
The following two SecurityExceptions are thrown after mixed components had previously been detected and a decision was made to allow them to coexist. The exceptions indicate that a component name collision (resource name or class package name) was detected between trusted and untrusted components and the request to load the resource or class was denied.
Now the problem is, how could i find which classes (maybe org.apache.log4j.Logger?) have the collision and which packages they are in?
I find there is a similar question in Oracle forums
Interesting link. I didn't have the problem yet - but may it be that you have the jar with "org.apache..." in the JavaEE container classpath somewhere and in the web application.
Look for that and to test remove it from the web app
I'm developing a web application using JSF 2.0, NetBeans 6.9.1, GlassFish Server 3.1, mojarra 2.0.3, and JasperReports 3.7.6. Included in my project library is the jar file "xerces-2.8.0.jar". This file was imported as part of the JasperReports jar file library. Whenever I try to deploy, run, or debug my project through NetBeans, I receive this error:
java.lang.Exception: java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! DTD factory class org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl does not extend from DTDDVFactory.
After any change in my project my build fails, and I receive the above error, when I try to deploy, run, or debug it. I have to restart the server and run/debug a second time. I've searched the internet and cannot find a solution to this problem. I've looked at the jar file in question, and and DTDDVFactoryImpl does indeed extend from DTDDVFactory - I don't know why I'm receiving this error. While I can eventually get my project running, it would be much nicer if I wasn't receiving this error.
Can anyone please tell me how I can fix this? Do I need to remove this file from my project library? Do I need to update this file with a newer version/older version?
If you provide your own xerces.jar, you have to do that through the Endorsed Standards Override Mechanism (java -Djava.endorsed.dirs=/path/to/xerces.jar), you are not allowed to just add it on the classpath (and will sooner or later run into trouble if you do). Let me explain.
JAXP is the Java API for XML Processing. The creation of JAXP objects (like parsers, XSLT transfomers, DOM Documents) is done through the factory/factory-method pattern so you can plugin a new JAXP implementation (it has to be newer than the one provided in your JRE). Xerces provides (part of) a JAXP implementation and contains endorsed standards (an endorsed standard is a Java API defined through a standards process other than the Java Community Process, see the Endorsed Standards Override Mechanism). You'll run in all kinds of troubles if you don't use the ESOM.
I got this error when using Selenium with Glassfish. I got around it by copying XML jars (xerces-*, xalan-*, xml-apis*, serialize*) from selenium/libs/ to $AS_HOME/lib/endorsed (for Glassfish 2) or to $AS_HOME/glassfish/lib/endorsed for Glassfish 4.