Develop Reference

Unable to deploy war in tomcat 9 server getting error java.lang.IllegalStateException: Error starting child

2022-07-05 14:40:46,411 [Catalina-utility-2] INFO org.apache.catalina.core.ContainerBase.[Catalina].[site].[/bk]- 2 Spring WebApplicationInitializers detected on classpath
2022-07-05 14:40:46,614 [Catalina-utility-2] ERROR org.apache.catalina.startup.HostConfig- Error deploying web application archive [/home/user/tomcat/webapps/site/bk.war]
java.lang.IllegalStateException: Error starting child
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:716) ~[catalina.jar:9.0.16]
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:690) ~[catalina.jar:9.0.16]
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:695) ~[catalina.jar:9.0.16]
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:978) [catalina.jar:9.0.16]
at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1850) [catalina.jar:9.0.16]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75) [tomcat-util.jar:9.0.16]
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118) [?:?]
at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:773) [catalina.jar:9.0.16]
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:427) [catalina.jar:9.0.16]
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1621) [catalina.jar:9.0.16]
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:305) [catalina.jar:9.0.16]
at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) [catalina.jar:9.0.16]
at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1144) [catalina.jar:9.0.16]
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1346) [catalina.jar:9.0.16]
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1350) [catalina.jar:9.0.16]
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1328) [catalina.jar:9.0.16]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-util.jar:9.0.16]
at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[site].StandardContext[/bk]]
at org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:441) ~[catalina.jar:9.0.16]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198) ~[catalina.jar:9.0.16]
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:713) ~[catalina.jar:9.0.16]
... 24 more

Implying that you didn't move anything else in the configuration:
From the Tomcat 9.0 documentation (Emphasis mine)
Copy unpacked directory hierarchy into a subdirectory in directory $CATALINA_BASE/webapps/. Tomcat will assign a context path to your application based on the subdirectory name you choose. We will use this technique in the build.xml file that we construct, because it is the quickest and easiest approach during development. Be sure to restart Tomcat after installing or updating your application.
Copy the web application archive file into directory $CATALINA_BASE/webapps/. When Tomcat is started, it will automatically expand the web application archive file into its unpacked form, and execute the application that way. This approach would typically be used to install an additional application, provided by a third party vendor or by your internal development staff, into an existing Tomcat installation. NOTE - If you use this approach, and wish to update your application later, you must both replace the web application archive file AND delete the expanded directory that Tomcat created, and then restart Tomcat, in order to reflect your changes.
From the trace, you have your .war file in /home/user/tomcat/webapps/site/. In other words, you are mixing the options Tomcat gives you.
Either
Move your .war file to /home/user/tomcat/webapps/
Move the .war content into /home/user/tomcat/webapps/site/
Note that you for (1) you will need to access your app as http://localhost:8080/bk/ but for (2) it would be http://localhost:8080/site/.

Javassist version upgrade does not solve java.lang.VerifyError:

We have an old project compiled with 1.7 and we want to change its runtime env to 1.8
(still will be compiled with 1.7).
After changing runtime env to 1.8, we got a lot of java.lang.VerifyError in logs.
For exp one of them:
ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to PostClassLoader: name=vfsfile:/opt/mss/mss-1.5.0.FINAL-jboss-jdk6-5.1.0.GA/XXX/ state=ClassLoader mode=Manual requiredState=PostClassLoader
org.jboss.deployers.spi.DeploymentException: Error during deploy: vfszip:/opt/mss/mss-1.5.0.FINAL-jboss-jdk6-5.1.0.GA/XXX/
at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:177)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1210)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1652)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:938)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:988)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:826)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:556)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1652)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:938)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:988)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:778)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:543)
at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:274)
at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:263)
at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
at org.jboss.Main.boot(Main.java:221)
at org.jboss.Main$1.run(Main.java:556)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.VerifyError: Expecting a stackmap frame at branch target 14
Exception Details:
Location:
classpath/ClassName.$javassist_read_YYY()Lcom/classpath/ClassName; #10: ifnonnull
Reason:
Expected stackmap frame at this location.
Bytecode:
0x0000000: 2ab4 0010 2ab9 04df 0100 c700 04b0 4c2a
0x0000010: b904 df01 002a 1305 462b b904 e604 00c0
0x0000020: 0548 b0
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
at java.lang.Class.getDeclaredMethods(Unknown Source)
at org.jboss.deployment.AnnotatedClassFilter.hasAnnotations(AnnotatedClassFilter.java:194)
at org.jboss.deployment.AnnotatedClassFilter.accepts(AnnotatedClassFilter.java:122)
at org.jboss.deployment.AnnotatedClassFilter.visit(AnnotatedClassFilter.java:102)
at org.jboss.virtual.plugins.vfs.helpers.WrappingVirtualFileHandlerVisitor.visit(WrappingVirtualFileHandlerVisitor.java:62)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:362)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:374)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:374)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:374)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:374)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:374)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:307)
at org.jboss.virtual.VFS.visit(VFS.java:468)
at org.jboss.virtual.VirtualFile.visit(VirtualFile.java:448)
at org.jboss.deployment.AnnotationMetaDataDeployer.getClasses(AnnotationMetaDataDeployer.java:225)
at org.jboss.deployment.ConvergedSipAnnotationMetaDataDeployer.processSipMetaData(ConvergedSipAnnotationMetaDataDeployer.java:103)
at org.jboss.deployment.ConvergedSipAnnotationMetaDataDeployer.deploy(ConvergedSipAnnotationMetaDataDeployer.java:90)
at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:93)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
... 30 more
At first I used -noverify, which solved the problem.
However I realized that using -noverify for production application is not a good idea.
As far as my investigation, it is suggested to upgrade javassist version. And since in stacktrace Javassist is mentioned (classpath/ClassName.$javassist_read_YYY()Lcom/classpath/ClassName; #10: ifnonnull) I decided to give it a try.
I almost tried with every Javassist version including 3.19 (build with jdk8)
and it does not work. Still verify error.
What is the solution for this? Or is there a workaround for this issue?
System info: JBoss 5.1.0.GA and Maven 2.2.1
Help is very much appreciated.

java.lang.ClassNotFoundException: org.eclipse.jetty.server.Request when starting with jetty:run-forked and connecting with ssl

I'm using jetty's pushbuilder to push some resources. As these resources are specified from inside the webapp, i can't use jetty's default pushCacheFilter.
When i start jetty embedded from my main java-class, it works well, i can connect to my page with https and also the push works fine.
But when i start via jetty:run-forked, it starts and gives this output:
**Started ServerConnector#45b4c3a9{SSL,[http/1.1, ssl, alpn, h2]}{0.0.0.0:8443}**
And then when accessing the page i get this error:
**java.lang.ClassNotFoundException: org.eclipse.jetty.server.Request
at org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:586)**
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.basex.http2.HTTP2Settings.push(HTTP2Settings.java:60)
at org.basex.http.HTTPConnection.initResponse(HTTPConnection.java:127)
at org.basex.http.restxq.RestXqResponse.serialize(RestXqResponse.java:209)
at org.basex.http.restxq.RestXqResponse.serialize(RestXqResponse.java:195)
at org.basex.http.restxq.RestXqResponse.create(RestXqResponse.java:97)
at org.basex.http.restxq.RestXqModule.process(RestXqModule.java:104)
at org.basex.http.restxq.RestXqFunction.process(RestXqFunction.java:109)
at org.basex.http.restxq.RestXqServlet.run(RestXqServlet.java:49)
at org.basex.http.BaseXServlet.service(BaseXServlet.java:59)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:833)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1650)
at org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:206)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1637)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:190)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1253)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1155)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
at org.eclipse.jetty.server.Server.handle(Server.java:564)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:317)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110)
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:289)
at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:149)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110)
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
at org.eclipse.jetty.util.thread.Invocable.invokePreferred(Invocable.java:128)
at org.eclipse.jetty.util.thread.Invocable$InvocableExecutor.invoke(Invocable.java:222)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:294)
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:199)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:673)
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:591)
at java.lang.Thread.run(Thread.java:748)
Maybe it's sth. with the maven classloading?
Edit
Another error occurs: Some of my latest Code-Changes seem to be missing after the maven-build. I've tried to just run "maven clean", but there are still missing fields and an exception is thrown.
These fields also are found, when starting jetty embedded.
Thx a lot!

After reading the jetty-docs again i found the reason:
server-classes are hidden from the webapp if jetty is the servlet-container. So this was my fault, the exception had to be thrown!
(see the docs here: http://www.eclipse.org/jetty/documentation/9.4.x/jetty-classloading.html)
I think the other missing-field-exceptions were related to this "forbidden" import.
So i think my problem is another one:
How can the (jetty-specific) serverPush can be realized, when it's not sure, that my webapp is deployed in jetty??
Jetty's own solution (pushCacheFilter.java) doesn't fit my needs.
So i guess i have to check, if i can write a filter that works in the moment when jetty sends the response.

cannot run struts2 web application on weblogic [duplicate]

This question already has an answer here:
Exception starting filter struts2 Unable to load configuration. - bean
(1 answer)
Closed 5 years ago.
I have made the struts2 web application according to the web tutorials.
It will deploy to weblogic server 10.3.6. (JDK1.6) In my developer machine, I have added the server in eclipse. But when I run it, it shows below error. I have researched in the web and tried to fix. It should be no duplicate jars found. Please help.
ERROR org.apache.struts2.dispatcher.Dispatcher - Dispatcher initialization failed
com.opensymphony.xwork2.config.ConfigurationException: Unable to load configuration.
at com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:58)
at org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:374)
at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:418)
at org.apache.struts2.dispatcher.ng.InitOperations.initDispatcher(InitOperations.java:69)
at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.init(StrutsPrepareAndExecuteFilter.java:51)
at weblogic.servlet.internal.FilterManager$FilterInitAction.run(FilterManager.java:343)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at weblogic.servlet.internal.FilterManager.loadFilter(FilterManager.java:96)
at weblogic.servlet.internal.FilterManager.preloadFilters(FilterManager.java:57)
at weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1872)
at weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:3154)
at weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1518)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:484)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:425)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:119)
at weblogic.application.internal.flow.ScopedModuleDriver.start(ScopedModuleDriver.java:200)
at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:247)
at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:425)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:119)
at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:27)
at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:671)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:52)
at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:212)
at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:59)
at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:161)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:79)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:569)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:150)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:116)
at weblogic.deploy.internal.targetserver.operations.StartOperation.doCommit(StartOperation.java:149)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:323)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:844)
at weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1253)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:440)
at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:163)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:195)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:13)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:68)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:545)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)
Caused by: com.opensymphony.xwork2.config.ConfigurationException: Unable to load bean: type: class:com.opensymphony.xwork2.ObjectFactory
at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.register(XmlConfigurationProvider.java:221)
at org.apache.struts2.config.StrutsXmlConfigurationProvider.register(StrutsXmlConfigurationProvider.java:101)
at com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:169)
at com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:55)
... 43 common frames omitted
Caused by: com.opensymphony.xwork2.config.ConfigurationException: Bean type class com.opensymphony.xwork2.ObjectFactory with the name xwork has already been loaded by bean - zip:C:/Users/raymondchiu/.m2/repository/org/apache/struts/struts2-core/2.1.8/struts2-core-2.1.8.jar!/struts-default.xml:29:72
at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.register(XmlConfigurationProvider.java:205)
... 46 common frames omitted
<2017年6月9日 上午11時20分31秒 CST> <Error> <HTTP> <BEA-101165> <Could not load user defined filter in web.xml: org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.
Unable to load configuration. - bean - zip:C:/Oracle_Home/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_user/_auto_generated_ear_/3tqe0y/war/WEB-INF/lib/struts2-core-2.1.8.jar!/struts-default.xml:29:72
at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:431)
at org.apache.struts2.dispatcher.ng.InitOperations.initDispatcher(InitOperations.java:69)
at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.init(StrutsPrepareAndExecuteFilter.java:51)
at weblogic.servlet.internal.FilterManager$FilterInitAction.run(FilterManager.java:343)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
Truncated. see log file for complete stacktrace
Caused By: Unable to load configuration. - bean - zip:C:/Oracle_Home/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_user/_auto_generated_ear_/3tqe0y/war/WEB-INF/lib/struts2-core-2.1.8.jar!/struts-default.xml:29:72
at com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:58)
at org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:374)
at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:418)
at org.apache.struts2.dispatcher.ng.InitOperations.initDispatcher(InitOperations.java:69)
at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.init(StrutsPrepareAndExecuteFilter.java:51)
Truncated. see log file for complete stacktrace
Caused By: Unable to load bean: type: class:com.opensymphony.xwork2.ObjectFactory - bean - zip:C:/Oracle_Home/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_user/_auto_generated_ear_/3tqe0y/war/WEB-INF/lib/struts2-core-2.1.8.jar!/struts-default.xml:29:72
at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.register(XmlConfigurationProvider.java:221)
at org.apache.struts2.config.StrutsXmlConfigurationProvider.register(StrutsXmlConfigurationProvider.java:101)
at com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:169)
at com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:55)
at org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:374)
Truncated. see log file for complete stacktrace
Caused By: Bean type class com.opensymphony.xwork2.ObjectFactory with the name xwork has already been loaded by bean - zip:C:/Users/raymondchiu/.m2/repository/org/apache/struts/struts2-core/2.1.8/struts2-core-2.1.8.jar!/struts-default.xml:29:72 - bean - zip:C:/Oracle_Home/Middleware/user_projects/domains/base_domain/servers/AdminServer/tmp/_WL_user/_auto_generated_ear_/3tqe0y/war/WEB-INF/lib/struts2-core-2.1.8.jar!/struts-default.xml:29:72
at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.register(XmlConfigurationProvider.java:205)
at org.apache.struts2.config.StrutsXmlConfigurationProvider.register(StrutsXmlConfigurationProvider.java:101)
at com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:169)
at igurationManager.getConfiguration(ConfigurationManager.java:55)
at org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:374)
Truncated. see log file for complete stacktracecom.opensymphony.xwork2.config.Conf
>

I have encountered this issue a few times, specifically when using WebLogic 10.3.x, Eclipse, and Maven.
The problem is that the WebLogic server plugin for Eclipse will add all dependencies to the classpath twice.
I have a workaround that may or may not work for you (depending on your application's architecture).
First, you must deploy the application as an exploded archive. You can find this setting under the WebLogic server properties in Eclipse (under the 'publishing' config node).
Second, you must deploy the application as a war project (as opposed to an ear).
Note that this is not an issue with newer versions of WebLogic. I deploy ear projects from within Eclipse all the time to WebLogic 12c without any issue. I only have the problem you describe when deploying to WebLogic 11g (10.3.x).

OpenSAML throws java.lang.NoClassDefFoundError only on weblogic

Im trying to implement a SAML SSO using the opensaml library. Ive managed to do so and successfully and deploy my simple authorization request on tomcat 7 but when i moved my application to weblogic server 10.3.5 it throws the following error:
java.lang.NoClassDefFoundError: Could not initialize class org.opensaml.xml.XMLConfigurator
Im using Gradle 1.12 to build the project, and im requesting the following dependencies:
dependencies {
compile 'org.apache.logging.log4j:log4j-core:2.2'
compile 'org.slf4j:slf4j-api:1.7.12'
compile 'org.slf4j:slf4j-log4j12:1.7.12'
compile group: 'org.opensaml', name: 'opensaml', version: '2.6.4'
compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
testCompile group: 'junit', name: 'junit', version: '4.+'
}
I was searching the web and found that some people solved this problem by telling weblogic to use their libs, but it didn't work for me.
My deployment file weblogic.xml has this:
<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-web-app xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-web-app" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd http://xmlns.oracle.com/weblogic/weblogic-web-app http://xmlns.oracle.com/weblogic/weblogic-web-app/1.7/weblogic-web-app.xsd">
<prefer-application-packages>
<package-name>org.opensaml.*</package-name>
</prefer-application-packages>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</wls:weblogic-web-app>
Weblogic console stacktrace:
java.lang.NoClassDefFoundError: Could not initialize class org.opensaml.xml.XMLConfigurator
at org.opensaml.DefaultBootstrap.initializeXMLTooling(DefaultBootstrap.java:220)
at org.opensaml.DefaultBootstrap.initializeXMLTooling(DefaultBootstrap.java:207)
at org.opensaml.DefaultBootstrap.bootstrap(DefaultBootstrap.java:100)
at com.saml.ServiceProvider.<init>(ServiceProvider.java:37)
at com.saml.WebServices.auth(WebServices.java:20)
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:597)
at weblogic.wsee.jaxws.WLSInstanceResolver$WLSInvoker.invoke(WLSInstanceResolver.java:92)
at weblogic.wsee.jaxws.WLSInstanceResolver$WLSInvoker.invoke(WLSInstanceResolver.java:74)
at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:151)
at com.sun.xml.ws.server.sei.EndpointMethodHandlerImpl.invoke(EndpointMethodHandlerImpl.java:268)
at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:100)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:866)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:815)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:778)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:680)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:403)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:532)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:253)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:140)
at weblogic.wsee.jaxws.WLSServletAdapter.handle(WLSServletAdapter.java:171)
at weblogic.wsee.jaxws.HttpServletAdapter$AuthorizedInvoke.run(HttpServletAdapter.java:708)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:146)
at weblogic.wsee.util.ServerSecurityHelper.authenticatedInvoke(ServerSecurityHelper.java:103)
at weblogic.wsee.jaxws.HttpServletAdapter$3.run(HttpServletAdapter.java:311)
at weblogic.wsee.jaxws.HttpServletAdapter.post(HttpServletAdapter.java:336)
at weblogic.wsee.jaxws.JAXWSServlet.doRequest(JAXWSServlet.java:95)
at weblogic.servlet.http.AbstractAsyncServlet.service(AbstractAsyncServlet.java:99)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:183)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3717)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
java.lang.NoClassDefFoundError: Could not initialize class org.opensaml.xml.XMLConfigurator
at org.opensaml.DefaultBootstrap.initializeXMLTooling(DefaultBootstrap.java:220)
at org.opensaml.DefaultBootstrap.initializeXMLTooling(DefaultBootstrap.java:207)
at org.opensaml.DefaultBootstrap.bootstrap(DefaultBootstrap.java:100)
at com.saml.ServiceProvider.<init>(ServiceProvider.java:37)
at com.saml.WebServices.auth(WebServices.java:20)
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:597)
at weblogic.wsee.jaxws.WLSInstanceResolver$WLSInvoker.invoke(WLSInstanceResolver.java:92)
at weblogic.wsee.jaxws.WLSInstanceResolver$WLSInvoker.invoke(WLSInstanceResolver.java:74)
at com.sun.xml.ws.server.InvokerTube$2.invoke(InvokerTube.java:151)
at com.sun.xml.ws.server.sei.EndpointMethodHandlerImpl.invoke(EndpointMethodHandlerImpl.java:268)
at com.sun.xml.ws.server.sei.SEIInvokerTube.processRequest(SEIInvokerTube.java:100)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:866)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:815)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:778)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:680)
at com.sun.xml.ws.server.WSEndpointImpl$2.process(WSEndpointImpl.java:403)
at com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit.handle(HttpAdapter.java:532)
at com.sun.xml.ws.transport.http.HttpAdapter.handle(HttpAdapter.java:253)
at com.sun.xml.ws.transport.http.servlet.ServletAdapter.handle(ServletAdapter.java:140)
at weblogic.wsee.jaxws.WLSServletAdapter.handle(WLSServletAdapter.java:171)
at weblogic.wsee.jaxws.HttpServletAdapter$AuthorizedInvoke.run(HttpServletAdapter.java:708)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:146)
at weblogic.wsee.util.ServerSecurityHelper.authenticatedInvoke(ServerSecurityHelper.java:103)
at weblogic.wsee.jaxws.HttpServletAdapter$3.run(HttpServletAdapter.java:311)
at weblogic.wsee.jaxws.HttpServletAdapter.post(HttpServletAdapter.java:336)
at weblogic.wsee.jaxws.JAXWSServlet.doRequest(JAXWSServlet.java:95)
at weblogic.servlet.http.AbstractAsyncServlet.service(AbstractAsyncServlet.java:99)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:183)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3717)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277)
at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183)
at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
Ive managed to overcome this problem by removing the libraries:
com.bea.core.bea.opensaml2_1.0.0.0_6-1-0-0
com.bea.core.bea.opensaml_1.0.0.0_6-1-0-0
Is it possible to disable the libraries instead of removing them?

yes you can change classloader priority, check this documentation :
https://docs.oracle.com/middleware/1213/wls/WLPRG/classloading.htm#WLPRG289
The idea is to skip using weblogic lib for you application, look at this part :prefer-web-inf-classes Element
Configuring a Filtering ClassLoader
To configure the FilteringClassLoader to specify that a certain package is loaded from an application, add a prefer-application-packages descriptor element to weblogic-application.xml which details the list of packages to be loaded from the application. The following example specifies that org.apache.log4j.* and antlr.* packages are loaded from the application, not the system classloader:
<prefer-application-packages>
<package-name>org.apache.log4j.*</package-name>
<package-name>antlr.*</package-name>
</prefer-application-packages>
The prefer-application-packages descriptor element can also be defined in weblogic.xml. For more information, see "prefer-application-packages".
You can specify that a certain package be loaded for a WAR file included within an EAR file by configuring the FilteringClassLoader in the weblogic.xml file of the WAR file.
For example, A.ear contains B.war. A.ear defines the FilteringClassLoader in weblogic-application.xml, and B.war defines a different FilteringClassLoader in weblogic.xml. When you deploy A.ear, B.war loads the package defined in the FilteringClassLoader in weblogic.xml. The WAR-level FilteringClassLoader has priority over the EAR-level FilteringClassLoader for this WAR file.
For aid in configuring filtering classloaders, see Using the Classloader Analysis Tool (CAT).