If I build this project to war and deploy it on WebLogic, it works well, but if I run on server using Eclipse, i got this error:
Caused By: Bean type class com.opensymphony.xwork2.ObjectFactory
with the name xwork has already been loaded by bean -
zip:D:/Documents%20and%20Settings/admini/.m2/repository/org/apache/struts/struts2-core/2.3.12/struts2-core-2.3.12.jar!/struts-default.xml:29:72 - bean -
zip:H:/runtime/weblogic1033/user_projects/domains/crmFrameworkDomain/servers/AdminServer/tmp/_WL_user/_auto_generated_ear_/nefp93/war/WEB-INF/lib/struts2-core-2.3.12.jar!/struts-default.xml:29:72
stackTrace
<2013/4/20 下午06時59分34秒 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:H:/runtime/weblogic1033/user_projects/domains/crmFrameworkDomain/servers/AdminServer/tmp/_WL_user/_auto_generated_ear_/nefp93/war/WEB-INF/lib/struts2-core-2.3.12.jar!/struts-default.xml:29:72
at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:485)
at org.apache.struts2.dispatcher.ng.InitOperations.initDispatcher(InitOperations.java:74)
at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.init(StrutsPrepareAndExecuteFilter.java:51)
at weblogic.servlet.internal.FilterManager$FilterInitAction.run(FilterManager.java:332)
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:H:/runtime/weblogic1033/user_projects/domains/crmFrameworkDomain/servers/AdminServer/tmp/_WL_user/_auto_generated_ear_/nefp93/war/WEB-INF/lib/struts2-core-2.3.12.jar!/struts-default.xml:29:72
at com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:70)
at org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:429)
at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:473)
at org.apache.struts2.dispatcher.ng.InitOperations.initDispatcher(InitOperations.java:74)
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:H:/runtime/weblogic1033/user_projects/domains/crmFrameworkDomain/servers/AdminServer/tmp/_WL_user/_auto_generated_ear_/nefp93/war/WEB-INF/lib/struts2-core-2.3.12.jar!/struts-default.xml:29:72
at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.register(XmlConfigurationProvider.java:245)
at org.apache.struts2.config.StrutsXmlConfigurationProvider.register(StrutsXmlConfigurationProvider.java:102)
at com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:226)
at com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:67)
at org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:429)
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:D:/Documents%20and%20Settings/admini/.m2/repository/org/apache/struts/struts2-core/2.3.12/struts2-core-2.3.12.jar!/struts-default.xml:29:72 - bean - zip:H:/runtime/weblogic1033/user_projects/domains/crmFrameworkDomain/servers/AdminServer/tmp/_WL_user/_auto_generated_ear_/nefp93/war/WEB-INF/lib/struts2-core-2.3.12.jar!/struts-default.xml:29:72
at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.register(XmlConfigurationProvider.java:229)
at org.apache.struts2.config.StrutsXmlConfigurationProvider.register(StrutsXmlConfigurationProvider.java:102)
at com.opensymphony.xwork2.config.impl.DefaultConfiguration.reloadContainer(DefaultConfiguration.java:226)
at com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:67)
at org.apache.struts2.dispatcher.Dispatcher.init_PreloadConfiguration(Dispatcher.java:429)
Truncated. see log file for complete stacktrace
I don't know why there's another struts2-core.2.3.12.jar in _auto_generated_ear
Is there any configuration of plugins should i change?
weblogic 10.3.3
jdk 1.6
eclipse juno
maven 3.0.5
and here is my eclipse project archive:
Loki.zip
I also faced the same issue.
In my case the one or more action classes configured in the struts.xml not defined on the package.
Once i defined the missing classes it worked fine.
please ensure all the action classes configured in struts.xml were defined in correct location.
struts.xml
<action name="welcome" class="com.vk.translate.action.DummyAction">
<result name="success">/login.jsp</result>
</action>
DummyAction is not defined in above code.
Once i defined it worked.
Related
Ojdbc8, ons, ucp jars are upgraded to 21.1.0.0 version. When trying to start the app on tomcat server, it's throwing Nosuchmethod exception. Logged in the Tomcat's localhost.log file. Application tries to establish DB connection during startup itself.
01-Jun-2021 15:59:56.641 INFO [localhost-startStop-1] org.apache.catalina.core.ApplicationContext.log 3 Spring WebApplication Initializers detected on classpath
01-Jun-2021 16:00:05.365 INFO localhost-startStop-1 org.apache.catalina.core.ApplicationContext.log Initializing Spring embedded WebApplicationContext
01-Jun-2021 16:00:19.397 SEVERE localhost-startStop-1 org.apache.catalina.core.StandardContext.listenerStart Error configuring application listener of class [oracle.ucp.jdbc.UCPServletContextListener]
java.lang.NoSuchMethodException: oracle.ucp.jdbc.UCPServletContextListener.init
at java.lang.class.getConstructor(Unknown Source)
This is a known issue with ucp.jar in 21.1. It will be fixed in 21.3 when it's released. In the meantime, you can remove this class from the ucp.jar:
oracle/ucp/jdbc/UCPServletContextListener.class
From my experience, if you put jdbc/ucp jars to Tomcat's lib (which is recommended for productive system) and set provided scope for them in Maven, the problem will disappear.
Another option could be setting metadata-complete="true" in web.xml (read more here and here)
if you are using spring boot then you can use
<dependency>
<groupId>com.oracle.ojdbc</groupId>
<artifactId>ojdbc8</artifactId>
<version>19.3.0.0</version>
</dependency>
this dependency or update your maven project.
We are migrating a few old systems written in Java 5, 6 and 7 to Java 8 and from JBoss 7 to Wildfly 14.
After the migration, I get all the time this kind of error:
WELD-001408: Unsatisfied dependencies for type InterfaceTypeConverterProvider with qualifiers #Named
I understand that from CDI 1.2 things changed and the #Inject don't work as it used to be and it need some refactoring.
I got many errors like this, some of them are classes in my own project that try to Inject other classes also inside my project, those ones I can fix.
The problem is: My project loads some classes that tries to inject other classes from outside, that are jar dependencies that I have no control over it and I can't change the code on those jars.
For example:
11:15:54,552 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."myApp-war-9.2-JAVA8-SNAPSHOT.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."myApp-war-9.2-JAVA8-SNAPSHOT.war".WeldStartService: Failed to start service at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1728)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
Caused by: org.jboss.weld.exceptions.DeploymentException: Exception List with 46 exceptions:
Exception 0 :
org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type InterfaceTypeConverterProvider with qualifiers #Named
at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedMethod] #Inject public thirdPartJar.converter.context.AbstractConverter.setTypeConverterProvider(#Named InterfaceTypeConverterProvider)
at thirdPartJar.converter.context.AbstractConverter.setTypeConverterProvider(AbstractConverter.java:0)
WELD-001475: The following beans match by type, but none have matching qualifiers:
- Managed Bean [class thirdPartJar.converter.context.TypeConverterProvider] with qualifiers [#Any #Default]
The error shows the problem in the class thirdPartJar.converter.context.AbstractConverter and I can't touch the code on that one... so, what should I do ?
Is it possible to downgrade Wildfly Weld or force it to use an older version of CDI ?
This is my beans.xml with the discover all but it still can't find the implementations.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"
version="1.2" bean-discovery-mode="all">
</beans>
The beans.xml always only applies to the archive it's in (be it jar or war). So you're setting the bean-discovery-mode only for your own archive, not for the 3rd party one.
Easiest option: Repackage the 3rd party jar and include a fitting beans.xml.
Non-intrusive option: Write a producer that supplies the expected beans. Normally, this can be a simple method:
#Produces
#Named
public InterfaceTypeConverterProvider createInterfaceTypeConverterProvider() {
return new InterfaceTypeConverterProvider();
}
I take it that there is no injection within the class. Otherwise it should already have been cdi enabled.
I'm trying to run JPA servlet on Tomcat 8.
From my servlet I call method of a class named QueryDB.class located in another Eclipse project (JPA project, not WEB project).
But tomcat throws
SEVERE: Servlet.service() for servlet [MyRESTService] in context with path [/AutomationWeb] threw exception [org.glassfish.jersey.server.ContainerException: java.lang.NoClassDefFoundError: javax/persistence/Persistence] with root cause
java.lang.ClassNotFoundException: javax.persistence.Persistence
at java.net.URLClassLoader$1.run(Unknown Source)
...
Exception is thrown at line EntityManagerFactory emf = Persistence.createEntityManagerFactory( "AutomationDB_JPA" ); in QueryDB.class
I'm using Eclipse Mars with Maven. I have EclipseLink in my pom.xml defined:
<dependency>
<groupId>org.eclipse.persistence</groupId>
<artifactId>eclipselink</artifactId>
<version>2.6.1</version>
</dependency>
I have following jars in my Application's WEB-INF/lib:
eclipselink-2.6.1.jar
javax.persistence-2.1.0.jar , it has javax/persistence/Persistence.class inside
There is no other SEVERE messages in the tomcat log.
What's wrong with this setup?
I also tried adding the persistence jar to apache-tomcat-8.0.28\lib , but got the same error.
Update: I moved Persistence.createEntityManagerFactory call to the servlet itself and got no classloader exception. So the question changes: why classloader used for QueryDB.class is different from servlet's classloader? Also, why classloader used in QueryDB.class does not see the Persistence.class, which is seen by the servlet's classloader?
Ok I've found a solution.
Excluded my JPA project from tomcat VM classpath
Converted my JPA project to the Utility project
Modified Deployment Assembly in my Web project properties so that it
will accept JPA project as .jar archive into WEB-INF/lib
I have no classloader exception anymore.
We are trying to create a functional example with Hibernate, JBoss7, Beans and Servlets using Eclipse as an IDE.
In other example project we were able to make functional Servlets, and we were able to use Hibernate.
We created two eclipse projects:
A Dynamic web project, an Enterprise Java Beans (EJB) project and a EAR project connecting both.
Running a simple test.java file which uses hibernate (and worked on other projects), we the get errors:
Initial SessionFactory creation failed.org.hibernate.cfg.beanvalidation.IntegrationException: Error activating Bean Validation integration
Exception in thread "main" java.lang.ExceptionInInitializerError
at exercicio.SessionFactoryUtil.<clinit>(SessionFactoryUtil.java:20)
at exercicio.DataBaseInterface.<init>(DataBaseInterface.java:17)
at exercicio.Test.main(Test.java:9)
Caused by: org.hibernate.cfg.beanvalidation.IntegrationException: Error activating Bean Validation integration
at org.hibernate.cfg.beanvalidation.BeanValidationIntegrator.integrate(BeanValidationIntegrator.java:156)
at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:303)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1750)
at exercicio.SessionFactoryUtil.configureSessionFactory(SessionFactoryUtil.java:32)
at exercicio.SessionFactoryUtil.<clinit>(SessionFactoryUtil.java:17)
... 2 more
Caused by: java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at org.hibernate.validator.util.LoggerFactory.make(LoggerFactory.java:29)
at org.hibernate.validator.util.Version.<clinit>(Version.java:24)
at org.hibernate.validator.engine.ConfigurationImpl.<clinit>(ConfigurationImpl.java:59)
at org.hibernate.validator.HibernateValidator.createGenericConfiguration(HibernateValidator.java:41)
at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:269)
at javax.validation.Validation.buildDefaultValidatorFactory(Validation.java:111)
at org.hibernate.cfg.beanvalidation.TypeSafeActivator.getValidatorFactory(TypeSafeActivator.java:445)
at org.hibernate.cfg.beanvalidation.TypeSafeActivator.activate(TypeSafeActivator.java:96)
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 org.hibernate.cfg.beanvalidation.BeanValidationIntegrator.integrate(BeanValidationIntegrator.java:150)
... 6 more
Caused by: java.lang.ClassNotFoundException: org.slf4j.LoggerFactory
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)
... 19 more
The problem now seems to be around the jars that we included using project Properties > Java Build Path > Add External Jars for the EJB project:
We added the slf4j-jdk14-1.7.5.jar and hibernate jars but the exception log appears to be indicating that we are still missing some jar.
If we remove the jars from the Java Build Path, the exception log is the same. So we think that the jars are not being deployed correctly, or some extra configuration is required... even thought they appear in the /lib folder inside the EJB project deployment folder.
Is there any procedure we are missing, or any probable causes to investigate? I'll add more info if needed. Thanks.
When using JBoss7 not all Jars are available to the application by default (for example slf4j). You have to specify which modules should be included in the classpath of the application by putting this information into a file in your application.
I always do it by adding jboss-deployment-structure.xml into my application (the EAR in your case).
Here's how https://docs.jboss.org/author/display/AS7/Class+Loading+in+AS7.
(The name of the module in your case would be org.slf4j)
Throwing slf4j jar in the libs folder can create a conflict with the slf4j module already included in JB7 by default... you have to add the dependency to your jboss-deployment-structure.xml
But if your hibernate jars are in the libs folder, they could fail resolve the dependency as well too... the way to go in JB7 would be to make a module for Hibernate too, the Nightie builds of JB7 already include an hibernate module, you could just copy the module from there, then add it to your jboss-deployment-structure.xml
Hi I am deploying my web application created in Gwt on the jetty.
I have used mongodb as my database.After starting the server it starts deploying the weapp.war
and gives following error -
694 [main] INFO org.mortbay.log - Extract /usr/share/jetty/webapps/myapp.war to /tmp/Jetty_0_0_0_0_8090_myapp.war__myapp__n6yltk/webapp
3567 [main] WARN org.mortbay.log - failed Startup: java.lang.LinkageError: loader constraint violation: loader (instance of org/mortbay/jetty/webapp/WebAppClassLoader) previously initiated loading for a different type with name "javax/management/MBeanServer"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:634)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:392)
at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:363)
at com.mongodb.DBPortPool$Holder.get(DBPortPool.java:58)
at com.mongodb.DBTCPConnector._set(DBTCPConnector.java:458)
at com.mongodb.DBTCPConnector.<init>(DBTCPConnector.java:46)
at com.mongodb.Mongo.<init>(Mongo.java:137)
at com.mongodb.Mongo.<init>(Mongo.java:123)
one of the jar in your classpath contains javax/management/MBeanServer. That is why you have got this exception. For example jboss-jmx.jar contains this class, if this jar is included in your classpath,you should remove it.
That is a class loading issue between the web class loader and the system class loader.
You might want to check this great speech about ClassLoader out.
http://www.zeroturnaround.com/blog/video-do-you-really-get-class-loaders-a-jazoon-talk-by-jevgeni-kabanov/
Check if you have log4j dependency in your pom.xml. The log4j has a dependency to jmxri which needs to be excluded.
Once you exclude this, the error gets resolved