Hello when i am try deploy ear app in glassfish i have got many warning like that :
[#|2013-01-14T14:12:52.404+0100|WARNING|glassfish3.1.2|org.apache.jasper.runtime.TldScanner|_ThreadID=34;_ThreadName=Thread-2;|PWC6351: In TLD scanning, the supplied resource file:/usr/local/glassfish3/glassfish/domains/pi/applications/person-ear-1.0-SNAPSHOT-rnull/APP-INF/lib/jaxb-api-2.1.jar does not exist
java.io.FileNotFoundException: /usr/local/glassfish3/glassfish/domains/pi/applications/person-ear-1.0-SNAPSHOT-rnull/APP-INF/lib/jaxb-api-2.1.jar (Nie ma takiego pliku ani katalogu)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:214)
at java.util.zip.ZipFile.<init>(ZipFile.java:144)
at java.util.jar.JarFile.<init>(JarFile.java:152)
at java.util.jar.JarFile.<init>(JarFile.java:89)
[#|2013-01-14T14:12:52.407+0100|WARNING|glassfish3.1.2|org.apache.jasper.runtime.TldScanner|_ThreadID=34;_ThreadName=Thread-2;|PWC6351: In TLD scanning, the supplied resource file:/usr/local/glassfish3/glassfish/domains/pi/applications/person-ear-1.0-SNAPSHOT-rnull/APP-INF/lib/resolver-20050927.jar does not exist
java.io.FileNotFoundException: /usr/local/glassfish3/glassfish/domains/pi/applications/person-ear-1.0-SNAPSHOT-rnull/APP-INF/lib/resolver-20050927.jar (Nie ma takiego pliku ani katalogu)
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.<init>(ZipFile.java:214)
at java.util.zip.ZipFile.<init>(ZipFile.java:144)
at java.util.jar.JarFile.<init>(JarFile.java:152
And other .... Its seems for me that glassfish dont use his own classloader but i am not sure....
It is likely that misconfiguration in your pom.xml is causing this issue. The maven-war-plugin is likely to contain directives customising the class path for your MANIFEST.MF. In my case, I had:
<manifest>
<addClasspath>true</addClasspath>
</manifest>
You should be able to solve it by simply commenting out/removing the directive.
Related
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.
I'm stuck on deploying a war to a remote Jetty 9.
On the app-server side I've deployed the cargo-jetty-7-and-onwards-deployer (version 1.4.9). This component seems to be running correctly and responds with (as expected on a get request):
HTTP ERROR 400
Problem accessing /cargo-jetty-deployer/. Reason:
Command / is unknown Powered by Jetty://
To deploy I'm using the cargo-maven2-plugin (version 1.4.9) with this configuration:
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>${cargo.plugin.version}</version>
<configuration>
<container>
<containerId>jetty9x</containerId>
<type>remote</type>
</container>
<configuration>
<type>runtime</type>
<properties>
<cargo.servlet.port>80</cargo.servlet.port>
<cargo.hostname>ipgoeshere</cargo.hostname>
<cargo.protocol>http</cargo.protocol>
</properties>
</configuration>
<deployables>
<deployable>
<groupId>se.dn.nav</groupId>
<artifactId>nav-api</artifactId>
<type>war</type>
<properties>
<context>/api</context>
</properties>
</deployable>
</deployables>
</configuration>
</plugin>
When running: mvn cargo:deploy
this results in the following error message:
[ERROR] Failed to execute goal org.codehaus.cargo:cargo-maven2-plugin:1.4.9:deploy (default-cli) on project nav-api: Execution default-cli of goal org.codehaus.cargo:cargo-maven2-plugin:1.4.9:deploy failed: Failed to deploy [/var/lib/jenkins/jobs/Deploy-Stage/workspace/target/nav-api-1.2.war]: Response when calling http://ip:80/cargo-jetty-deployer/deploy?path=/api was: Error - Unexpected error when trying to start the webapp -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.cargo:cargo-maven2-plugin:1.4.9:deploy (default-cli) on project nav-api: Execution default-cli of goal org.codehaus.cargo:cargo-maven2-plugin:1.4.9:deploy failed: Failed to deploy [/var/lib/jenkins/jobs/Deploy-Stage/workspace/target/nav-api-1.2.war]
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-cli of goal org.codehaus.cargo:cargo-maven2-plugin:1.4.9:deploy failed: Failed to deploy [/var/lib/jenkins/jobs/Deploy-Stage/workspace/target/nav-api-1.2.war]
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:144)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: org.codehaus.cargo.container.ContainerException: Failed to deploy [/var/lib/jenkins/jobs/Deploy-Stage/workspace/target/nav-api-1.2.war]
at org.codehaus.cargo.container.jetty.JettyRemoteDeployer.deploy(JettyRemoteDeployer.java:126)
at org.codehaus.cargo.maven2.DeployerDeployMojo.performDeployerActionOnSingleDeployable(DeployerDeployMojo.java:56)
at org.codehaus.cargo.maven2.AbstractDeployerMojo.performDeployerActionOnAllDeployables(AbstractDeployerMojo.java:166)
at org.codehaus.cargo.maven2.AbstractDeployerMojo.doExecute(AbstractDeployerMojo.java:97)
at org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:432)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
... 20 more
Caused by: org.codehaus.cargo.container.ContainerException: Response when calling http://ip:80/cargo-jetty-deployer/deploy?path=/api was: Error - Unexpected error when trying to start the webapp
at org.codehaus.cargo.container.jetty.JettyRemoteDeployer.deploy(JettyRemoteDeployer.java:119)
... 25 more
[ERROR]
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
And after this the build and deployment fails.
I've checked the logs on the Jetty, I've also upped the logging level to DEBUG, but there's no indication what is going wrong on the server side.
Does anyone have a clue what I'm doing wrong?
Is there any way I can get a better error message to indicate whats going wrong?
Any help would be GREATLY appreciated! :)
P.s.
I've removed the ip int the log.
P.s.s.
The war I'm deploying is previously tested and runs fine on Jetty.
Seems like cargo-jetty-7-and-onwards-deployer is not compatible with Jetty 9+ (there were some lifecycle changes in Jetty 9 that cargo is likely not aware of)
Do this (to find out) ...
Start jetty with the following extra command line
java -jar /opt/jetty/start.jar -Dorg.LEVEL=DEBUG -Djetty.dump.start=true
Check the logs, there should be tons more information, including a server state dump.
If cargo-jetty-deployer is either not present or not labeled as STARTED then the deployer webapp itself failed to start.
If you feel like it, update your question with the dump and/or relevant webapp startup error logging events (not the entire log, as that is just far to noisy)
What worked for me is setting the config.home system property to the parent directory of the webapps directory of Jetty.
The deployer will copy the uploaded war to the webapps directory and let Jetty deploy it automatically.
If config.home is set then the deployer will use ${config.home}/webapps, if not then it will use ${jetty.home}/webapps as the target directory for the war file. For me the webapps directory is configured to be ${jetty.base}/webapps which is something different than ${jetty.home}/webapps. Setting ${config.home} equal to ${jetty.base} solved the issue.
I tried to deploy a sample activemq application into karaf.While deploying and starting the bundle i got this error.please help me to solve this.
I have installed all required activemq components into karaf.
still getting the following error.
karaf#root()> Exception in thread "SpringOsgiExtenderThread-7" org.springframework.beans.factory.CannotLoadBeanClassException: Can
not find class [org.apache.activemq.camel.component.ActiveMQComponent] for bean with name 'activemq' defined in URL [bundle://1171
.4:0/META-INF/spring/camel-context.xml]; nested exception is java.lang.ClassNotFoundException: org.apache.activemq.camel.component
.ActiveMQComponent not found from bundle [camel-activemq]
at org.springframework.beans.factory.support.AbstractBeanFactory.resolveBeanClass(AbstractBeanFactory.java:1275)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.predictBeanType(AbstractAutowireCapableBea
nFactory.java:575)
at org.springframework.beans.factory.support.AbstractBeanFactory.isFactoryBean(AbstractBeanFactory.java:1344)
at org.springframework.beans.factory.support.AbstractBeanFactory.isFactoryBean(AbstractBeanFactory.java:910)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactor
y.java:609)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationConte
xt.java:932)
at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$1600(AbstractDelegatedExec
utionApplicationContext.java:69)
at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionA
pplicationContext.java:355)
at org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegated
ExecutionApplicationContext.java:320)
at org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefr
eshTask.run(DependencyWaiterApplicationContextExecutor.java:132)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.ClassNotFoundException: org.apache.activemq.camel.component.ActiveMQComponent not found from bundle [camel-ac
tivemq]
at org.springframework.osgi.util.BundleDelegatingClassLoader.findClass(BundleDelegatingClassLoader.java:103)
at org.springframework.osgi.util.BundleDelegatingClassLoader.loadClass(BundleDelegatingClassLoader.java:156)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at org.springframework.util.ClassUtils.forName(ClassUtils.java:260)
at org.springframework.beans.factory.support.AbstractBeanDefinition.resolveBeanClass(AbstractBeanDefinition.java:416)
at org.springframework.beans.factory.support.AbstractBeanFactory.doResolveBeanClass(AbstractBeanFactory.java:1296)
at org.springframework.beans.factory.support.AbstractBeanFactory.resolveBeanClass(AbstractBeanFactory.java:1267)
... 11 more
Caused by: java.lang.ClassNotFoundException: org.apache.activemq.camel.component.ActiveMQComponent not found by camel-activemq [11
71]
at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1532)
at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75)
at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at org.apache.felix.framework.Felix.loadBundleClass(Felix.java:1844)
at org.apache.felix.framework.BundleImpl.loadClass(BundleImpl.java:937)
at org.springframework.osgi.util.BundleDelegatingClassLoader.findClass(BundleDelegatingClassLoader.java:99)
... 17 more
You miss the activemq-camel feature.
Log into karaf and issue the following commands:
For Karaf 2.3.x:
> features:chooseurl activemq
> features:install activemq-camel
For Karaf 3.0.x:
karaf#root()> feature:repo-add activemq
karaf#root()> feature:install activemq-camel
The activemq-camel feature will also install activemq-client & camel-jms.
You may need to provide a specific version number in the repository command depending on what versioning information is embedded in your bundle. E.g.:
karaf#root()> feature:repo-add activemq 5.10.0
This camel-activemq project is an upstream archetype you can use it for your quick starter of camel.
To use it in karaf, you need to add the bundle manifest.
first need to change the packing to bundle,
<packaging>bundle</packaging>
then add this part
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<version>2.3.7</version>
<extensions>true</extensions>
<configuration>
<instructions>
<Bundle-SymbolicName>camel-activemq</Bundle-SymbolicName>
<Import-Package>*,org.apache.activemq.camel.component</Import-Package>
</instructions>
</configuration>
</plugin>
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 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