I'm trying to use Hibernate-Search in one of my JavaEE projects and seem to run into the exact same problem as described by Rallenaldo:
My Maven-project is using
Java JDK 1.8.0_73
Hibernate 5.0.6.Final
Hibernate-Search 5.5.2.Final (which uses Lucene 5.3.1)
and try to deploy on a Glassfish 4.1.1 application server (with just minimal changes to the standard configuration).
When deploying my application the deployment process ends in the following ClassCastException, when Lucene tries to load codecs from the package lucene-backward-codecs (version 5.3.1):
java.lang.ClassCastException: class org.apache.lucene.codecs.lucene40.Lucene40PostingsFormat
at java.lang.Class.asSubclass(Class.java:3404)
at org.apache.lucene.util.SPIClassIterator.next(SPIClassIterator.java:141)
at org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:65)
at org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:47)
at org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:37)
at org.apache.lucene.codecs.PostingsFormat$Holder.<clinit>(PostingsFormat.java:49)
at org.apache.lucene.codecs.PostingsFormat.forName(PostingsFormat.java:112)
at org.apache.lucene.codecs.lucene40.Lucene40Codec.<init>(Lucene40Codec.java:115)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at java.lang.Class.newInstance(Class.java:442)
at org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:67)
at org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:45)
at org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:37)
at org.apache.lucene.codecs.Codec$Holder.<clinit>(Codec.java:47)
at org.apache.lucene.codecs.Codec.forName(Codec.java:113)
at org.apache.lucene.index.SegmentInfos.readCodec(SegmentInfos.java:469)
...
As has been elsewhere suggested, I have already verified that on my computer there is no other version of Lucene nor Hibernate-Search.
If I exclude the lucene-backward-codecs dependecy from the Maven-project, I get a similar ClassCastException at the exact same location in the Lucene-code:
java.lang.ClassCastException: class org.apache.lucene.codecs.lucene50.Lucene50PostingsFormat
at java.lang.Class.asSubclass(Class.java:3404)
at org.apache.lucene.util.SPIClassIterator.next(SPIClassIterator.java:141)
at org.apache.lucene.util.NamedSPILoader.reload(NamedSPILoader.java:65)
at org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:47)
at org.apache.lucene.util.NamedSPILoader.<init>(NamedSPILoader.java:37)
at org.apache.lucene.codecs.PostingsFormat$Holder.<clinit>(PostingsFormat.java:49)
at org.apache.lucene.codecs.PostingsFormat.forName(PostingsFormat.java:112)
at org.apache.lucene.codecs.lucene53.Lucene53Codec.<init>(Lucene53Codec.java:160)
at org.apache.lucene.codecs.lucene53.Lucene53Codec.<init>(Lucene53Codec.java:80)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
...
I was not able to find a solution to this problem. And I am aware that Rallenaldo's question is actally also still open. Does someone know what causes this problem? Is this a Glassfish 4.1.1 problem?
Edit: I want to add the following observation to my original post: part of my project generates an standalone application packed as a self executable jar-file with the identical hibernate and lucene related dependencies, where I also use an entity manager with essentially the same configuration for the presistence context. In this case I do not have the above problem with hibernate-search. It starts without any problem and I can see it generate the expected index files. Here are the relevant lines from the persistence.xml:
<persistence-unit name="puName" transaction-type="RESOURCE_LOCAL">
<provider>org.hibernate.jpa.HibernatePersistenceProvider</provider>
<properties>
...
<property name="hibernate.search.default.directory_provider" value="filesystem"/>
<property name="hibernate.search.default.indexBase" value="/path/to/lucene/indexes"/>
...
</properties>
</persistence-unit>
Ok. Here is better answer. The solution (workaround) for us was to put lucene-analyzers-common-5.3.1.jar and lucene-core-5.3.1.jar directly into domain lib folder. After debugging I have found that class Lucene40PostingsFormat is being loaded by two classloaders and then instantiated from first classloader as a subclass of another (it gives class cast exception). I assume there is one unnecessary loading but I do not know why and how to change it with configuration only.
Related
I am trying to redirect Java Util Logging logs to Log4j 2.1 using the birdge provided log4j-jul-2.1, but stuck with classpath problems. I have all the log4j jars in the domains lib directory and used the following JVM parameter as mentioned in log4j documentation:
-Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager
The problem is that the bridge LogManager provided by log4j is not available in Glassfish AppClassLoader during startup and it causes the exception below. I can fix that by modifying server main classpath (provided by -cp argument), but this is bad. Is there any other/better looking way to achieve that? Simply putting it into server main lib directory does not also work as its again not AppClassLoader.
Could not load Logmanager "org.apache.logging.log4j.jul.LogManager"
java.lang.ClassNotFoundException: org.apache.logging.log4j.jul.LogManager
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.util.logging.LogManager$1.run(LogManager.java:167)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.logging.LogManager.<clinit>(LogManager.java:157)
at java.util.logging.Logger.getLogger(Logger.java:287)
at com.sun.enterprise.glassfish.bootstrap.ASMainHelper.<clinit>(ASMainHelper.java:67)
at com.sun.enterprise.glassfish.bootstrap.ASMain.main(ASMain.java:54)
I finally decided to use SLF4J and its SLF4JBridgeHandler for handling Java Util Logging calls. The main benefit of it is that it can be initialized at some later point when all the classes are loaded and after all required static initializations.
SLF4JBridgeHandler.removeHandlersForRootLogger();
SLF4JBridgeHandler.install();
I also switched to Logback as a backend as with this solution Log4j encounters performance problems for disable JUL loggers.
I created a web-service app based on Apache CXF (2.7.5), deployed it on a Glassfish 3.0.1 and it works fine till I turn on WS-Sec support. Then I get the following exception when I try to do a web-service request:
Caused by: javax.xml.crypto.NoSuchMechanismException: class configured for XMLSignatureFactory(provider: ApacheXMLDSig)cannot be found.
at javax.xml.crypto.dsig.XMLDSigSecurity.doGetImpl(Unknown Source) ~[webservices-osgi.jar:1.0]
at javax.xml.crypto.dsig.XMLDSigSecurity.getImpl(Unknown Source) ~[webservices-osgi.jar:1.0]
at javax.xml.crypto.dsig.XMLDSigSecurity.getImpl(Unknown Source) ~[webservices-osgi.jar:1.0]
at javax.xml.crypto.dsig.XMLSignatureFactory.findInstance(Unknown Source) ~[webservices-osgi.jar:1.0]
at javax.xml.crypto.dsig.XMLSignatureFactory.getInstance(Unknown Source) ~[webservices-osgi.jar:1.0]
at org.apache.ws.security.message.WSSecSignature.init(WSSecSignature.java:127) ~[wss4j-1.6.10.jar:1.6.10]
at org.apache.ws.security.message.WSSecSignature.<init>(WSSecSignature.java:120) ~[wss4j-1.6.10.jar:1.6.10]
at org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.getSignatureBuilder(AbstractBindingBuilder.java:1730) ~[cxf-rt-ws-security-2.7.5.jar:2.7.5]
at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignature(AsymmetricBindingHandler.java:546) ~[cxf-rt-ws-security-2.7.5.jar:2.7.5]
at org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:147) ~[cxf-rt-ws-security-2.7.5.jar:2.7.5]
... 273 common frames omitted
Caused by: java.lang.ClassNotFoundException: org.apache.jcp.xml.dsig.internal.dom.DOMXMLSignatureFactory
at org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:744) ~[felix.jar:na]
at org.apache.felix.framework.ModuleImpl.access$100(ModuleImpl.java:61) ~[felix.jar:na]
at org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1656) ~[felix.jar:na]
at java.lang.ClassLoader.loadClass(ClassLoader.java:247) ~[na:1.6.0_43]
It seems that CXF invokes the XMLSignatureFactory class contained by Glassfish's default webservice provider implementation instead of invoking it's own one (it's in the xmlsec.jar file). All CXF files are packed into my war file and also have the <class-loader delegate="false" /> set in sun-web.xml.
Can someone help me why the Glassfish classloader works this way and how could I fix this?
I managed to find out that Glassfish (at least the 3.0.1 version) modifies the default class loading behavior to "protect" some packages (mostly javax. packages) in it's classpath. That's the reason why it finds and uses classes in it's modules directory instead of the one in my war's lib.
To solve this a JVM option should be added to the domain.xml:
<jvm-options>-Dcom.sun.enterprise.overrideablejavaxpackages=javax.xml.crypto,javax.xml.crypto.dsig</jvm-options>
With this Glassfish will allow to use your libs in your war file. But even with this setting it's problematic to use CXF with WS-Securityy along with Metro. The better solution is to use a Glassfish with only Web Profile not Full Profile as Web Profile doesn't have Metro included.
I'm using spring's Jaxb2Marshaller (without web services) to unmarshal some xml. The xml code is code-gen via maven-jaxb-plugin, and I instantiate the Jaxb2Marshaller in spring via:
<bean id="unmarshaller" class="...Jaxb2Marshaller" p:contextPath="my.package.path" />
Then start with:
mvn clean package
mvn tomcat:run
The first unmarshaller is created fine, the second throws with org.springframework.oxm.jaxb.JaxbSystemException because it can't find ObjectFactory (which is generated by the maven-jaxb-plugin, and I've verified is in fact present in the jar, in the correct package).
I actually have two unmarshallers, (although I've tried with one unmarshaller and contextPath with colon separated package paths, with same results).
I don't think this is generally a problem with spring or my configuration, because if I deploy into a full tomcat container it works fine. I did notice that maven puts tomcat in my project/target/tomcat folder and there are some differences, such as there is no lib directory. I actually don't know what all the differences are between embedded tomcat and a regular installation.
Can someone explain:
1) exactly how embedded tomcat differs from a regular installation
2) if there are known limitations
3) if it can be configured to work properly in this situtation
Full stack trace:
SEVERE: Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'unmarshaller' defined in class path resource [spring.xml]: Invocation of init method failed; nested exception is org.springframework.oxm.jaxb.JaxbSystemException: "my.package.path" doesnt contain ObjectFactory.class or jaxb.index; nested exception is javax.xml.bind.JAXBException: "my.package.path" doesnt contain ObjectFactory.class or jaxb.index
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1338)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:473)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:409)
at java.security.AccessController.doPrivileged(Native Method)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:380)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:264)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:261)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:185)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:164)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:429)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:728)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:380)
at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4135)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4630)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:785)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:445)
at org.apache.catalina.startup.Embedded.start(Embedded.java:825)
at org.codehaus.mojo.tomcat.AbstractRunMojo.startContainer(AbstractRunMojo.java:558)
at org.codehaus.mojo.tomcat.AbstractRunMojo.execute(AbstractRunMojo.java:255)
For anyone else who runs across this, I eventually solved the problem by using classesToBeBound property instead of contextPath. The reason I had initially avoided classesToBeBound was that I thought I had to specify every single class in the model in the classesToBeBound list, which isn't the case. You simply specify the class that has the #XmlRootElement annotation.
I'm creating a basic Struts2, Maven webApp and getting this error when I deploy to Tomcat 6 or Jetty. Has anyone seen this?
2010-07-29 15:33:38.801::WARN: failed struts2
Unable to load bean: type: class:com.opensymphony.xwork2.ObjectFactory - bean - jar:file:/C:/workspaces/test/test/target/work/webapp/WEB-INF/lib/struts2-core-2.1.8.1.jar!/struts-default.xml:29:72
at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.register(XmlConfigurationProvider.java:208)
at org.apache.struts2.config.StrutsXmlConfigurationProvider.register(StrutsXmlConfigurationProvider.java:101)
at com.opensymphony.xwork2.config.impl.DefaultConfiguration.reload(DefaultConfiguration.java:131)
at com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:52)
at org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:395)
at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:452)
at org.apache.struts2.dispatcher.ng.InitOperations.initDispatcher(InitOperations.java:69)
at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.init(StrutsPrepareAndExecuteFilter.java:51)
at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:589)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:139)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1220)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:510)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448)
at org.mortbay.jetty.plugin.Jetty6PluginWebAppContext.doStart(Jetty6PluginWebAppContext.java:110)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:156)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:152)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.plugin.Jetty6PluginServer.start(Jetty6PluginServer.java:132)
at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:357)
at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:293)
at org.mortbay.jetty.plugin.Jetty6RunWar.execute(Jetty6RunWar.java:67)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: Bean type class com.opensymphony.xwork2.ObjectFactory with the name xwork has already been loaded by bean - jar:file:/C:/workspaces/ulearn/ulearn/target/work/webapp/WEB-INF/lib/struts2-core-2.0.11.2.jar!/struts-default.xml:30:72 - bean - jar:file:/C:/workspaces/ulearn/ulearn/target/work/webapp/WEB-INF/lib/struts2-core-2.1.8.1.jar!/struts-default.xml:29:72
at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.register(XmlConfigurationProvider.java:193)
... 47 more
Using Maven...
<dependency>
<groupId>org.apache.struts</groupId>
<artifactId>struts2-core</artifactId>
<version>2.1.8.1</version>
</dependency>
web.xml
<filter>
<filter-name>struts2</filter-name>
<filter-class>org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>struts2</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
Look's pretty straight forward, I don't understand why it won't load. I followed the basic tutorial. I googled for this error message, and was unable to find anything relevant.
Your problem is actually quite clear if you read the stack trace:
Caused by: Bean type class com.opensymphony.xwork2.ObjectFactory with the
name xwork has already been loaded by bean -
jar:file:/C:/workspaces/ulearn/ulearn/target/work/webapp/WEB-INF/lib/struts2-core-2.0.11.2.jar!/struts-default.xml:30:72
- bean -
jar:file:/C:/workspaces/ulearn/ulearn/target/work/webapp/WEB-INF/lib/struts2-core-2.1.8.1.jar!/struts-default.xml:29:72
You have a copy of struts2-core-2.0.11.2.jar and a copy of struts2-core-2.1.8.1.jar in your WEB-INF/lib directories. I think you should only have one of them. Do some cleanup (running a mvn clean might be enough).
PS: I have no idea why you also have stuff coming from C:/workspace/test as show be the first line:
jar:file:/C:/workspaces/test/test/target/work/webapp/WEB-INF/lib/struts2-core-2.1.8.1.jar!/struts-default.xml:29:72
There is definitely something weird and messy with your classpath. I don't have any explanation beyond the one I gave above though.
Agree with the above answer
Check your library and classpath for the above jars and fix them
Sometimes even if the jars are not seen in the IDE, they are present int the build files, So a fix of the classpath and a CLEAN AND BUILD should resolve the problem.
I think struts2-core-2.1.8.1.jar copy or you have included this jar file some where in your webapplication so remove it and continue
Problem: The conflict occurred as 2 files of different versions are being loaded by the web container
Solution: Just go to path
C:/workspaces/ulearn/ulearn/target/work/webapp/WEB-INF/lib/ of your computer and delete the struts2-core-2.0.11.2.jar file and only keep the latest one. If this type of conflict also occurs with some other file then delete that file also
After this no exception will be there.
I have also encountered this problem recently. Clean the cache and rebuild the project is not valid for my error.
I tried to delete the conflicting struts-default.xml file, but I didn't find it and the struts-default.xml file is a read-only file so I can't to modify it.
My final solution is to remove the extra Web* under Project Structure--Modules--MyFirstProject (project name), leaving only one Web and modifying Web Resource Directories as WebRoot.
It works for me! Hope I can help others.
here
As part of our application we are using apache's xerces jaxp parser. When we deploy the application on weblogic 9.2, we are getting the following error.
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cxf.wsdl.WSDLManager' defined in class path resource [META-INF/cxf/cxf.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.wsdl11.WSDLManagerImpl]: Constructor threw exception; nested exception is java.lang.ClassCastException: org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
As per our analysis, weblogic is trying to to load its own DocumentBuilderFactoryImpl which is present in weblogic.jar instead of apache's xerces.
We tried the following to force the weblogic to load DocumentBuilderFactoryImpl from xerces
i) we have added the following tag into weblogic.xml
<prefer-web-inf-classes>true</prefer-web-inf-classes>
ii) we have put latest versions of xalan in jre/lib/endorced folder. this didn't resolve our problem.
ii) we have added entries in weblogic-application.xml
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90">
<application-param>
<param-name>webapp.encoding.default</param-name>
<param-value>UTF-8</param-value>
</application-param>
<prefer-application-packages>
<package-name>javax.jws.*</package-name>
<package-name>org.apache.xerces.*</package-name>
<package-name>org.apache.xerces.jaxp.*</package-name>
</prefer-application-packages>
</weblogic-application>
ii)Added the following entry in weblogic-application.xml
<xml>
<parser-factory>
<saxparser-factory>org.apache.xerces.jaxp.SAXParserFactoryImpl</saxparser-factory>
<document-builder-factory>org.apache.xerces.jaxp.DocumentBuilderFactoryImpl</document-builder-factory>
<transformer-factory>org.apache.xalan.processor.TransformerFactoryImpl</transformer-factory>
</parser-factory>
</xml>
iii) Added jaxp.properties to load DocumentBuilderFactoryImpl from xerces to the jre/lib and started the server.In this case, the weblogic didnt start.
iv) Then we started the server first and then copied the jaxp.properties file during the run time when server starts.But no success
None of the above worked for us.
Any help is highly appreciated.
You did so many things that I don't understand the exact status. My advice would be to strictly follow the Application Server Specific Configuration Guide for WebLogic that I've successfully used in the past with WLS 9.2.
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90">
<application-param>
<param-name>webapp.encoding.default</param-name>
<param-value>UTF-8</param-value>
</application-param>
<prefer-application-packages>
<package-name>javax.jws.*</package-name>
</prefer-application-packages>
</weblogic-application>
You'll certainly have to add more packages under prefer-application-packages to setup Weblogic ClassLoader filtering but in the current state of the question, it's impossible to provide a precise answer.
Just in case, you can maybe try to blindly use the weblogic-application.xml from this thread:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90">
<xml>
<parser-factory>
<saxparser-factory>
org.apache.xerces.jaxp.SAXParserFactoryImpl
</saxparser-factory>
<document-builder-factory>
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
</document-builder-factory>
<transformer-factory>
org.apache.xalan.processor.TransformerFactoryImpl
</transformer-factory>
</parser-factory>
</xml>
<application-param>
<param-name>webapp.encoding.default</param-name>
<param-value>UTF-8</param-value>
</application-param>
<prefer-application-packages>
<package-name>javax.jws.*</package-name>
<package-name>org.apache.xerces.*</package-name>
<package-name>org.apache.xalan.*</package-name>
</prefer-application-packages>
</weblogic-application>
But this is a shot in the dark.
You could try forcing the use of the specified document builder factory as a command line option:
-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
This is assuming that you have the required Xerces builder factory class in your classpath.
In general, you shouldn't use a separate xerces.jar anymore, unless required by some legacy code. The Xerces parser classes come with the JRE, the package names just start with com.sun.org.apache instead of org.apache. You could try also
-Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl
and remove xerces.jar from your classpath altogether (this is what we did on WLS 10.3 and Java 1.6).
I managed to resolve the issue DocumentBuilderFactory not found with simple solution.
Try to copy xercesImpl.jar to the domain specific lib directory on weblogic MyDomain\servers\MyServer\lib.
In my case the problem was that i made a dependency on commons-digester which in turn used another version of xerces (that caused the conflict). So you can review your dependencies in case some other version of xerces was transitively included.