I have been given a Java Spring application to containerize. I am using a Tomcat8/Java8 base image. When it boots, it fails to deploy with the following error:
Caused by: org.springframework.context.annotation.ConflictingBeanDefinitionException: Annotation-specified bean name 'controller3P' for bean class [com.******.******.brand3P.controller.Controller3P] conflicts with existing, non-compatible bean definition of same name and class [com.******.******.Brand3P.controller.Controller3P]
The problem here seems to that Spring is finding 2 conflicting classes, differentiated by "brand3P" and "Brand3P".
However, in the source code, I can find no reference to a class "Brand3P", only a class "brand3P".
Can anyone explain what Spring is doing here?
(Be nice, I'm Ops, not Dev)
Package name should be all lower cased, checkout here oracle doc
Package name is not included in spring definition name.
My guess is someone changed the package name in Git, because git is by default case insensitive, so you will run into this situation, if it is this case, remove the file and create it again will fix this problem.
Hi Ops, please work with Devs together ;)
Turns out it was an issue with the build in Jenkins. The code had changed (Brand3P -> brand3P) but the older class name was hanging around in the Jenkins workspace, and being bundled into the Docker image.
We deleted the workspace, re-ran the build, and all was fine.
Related
I get this error in a Java maven project. The weird thing is, it doesn't appear on every machine so I assume it has something to do with a configuration issue.
The class RoleKeyCacheImpl is a #Startup #Singleton:
#Startup
#Singleton
public class RoleKeyCacheImpl implements RoleKeyCache { ... }
That's the error Wildfly triggers when deploying the service.
Caused by: java.lang.IllegalArgumentException: WFLYEE0040: A component
named 'RoleKeyCacheImpl' is already defined in this module at
org.jboss.as.ee.component.EEModuleDescription.addComponent(EEModuleDescription.java:167)
at
org.jboss.as.ejb3.deployment.processors.EJBComponentDescriptionFactory.addComponent(EJBComponentDescriptionFactory.java:58)
I've tried:
installing a new Wildfly (V10, V13) on the same machine -> doesn't help
installing a completely new Eclipse on this machine -> doesn't help
cleaning & rebuilding all related projects
making sure the deployments-folder is empty and doesn't contain old versions of the same WAR
read the related question here which also didn't help (they use Spring): A component named 'XXX' is already defined in this module in JBoss 7.1.1
read and tried this q&a: Wrong dependencies with EJB in JBoss Wildfly (server-clean) -> doesn't help
deleted and rebuilt the local maven rep (".m2") -> no effect
checking out the same source on another computer -> does work on one machine, on another it gives the same error
I have absolutely no clue what the issue is or even could be. On one machine, we check it out and it runs without errors. On others, the exact same error happens.
Does anybody have an idea?
I had this same issue multiple times with EAP 7.1 and now again with WildFly 21.0.0. I know by experience this is an issue caused by Eclipse who tries to deploy automatically to a configured WildFly instance. During the deployment (or undeployment) some concurrent file issue arises and files who should be removed, are still on the filesystem, causing this error that a component is already defined.
In fact it is not already defined, it is just WildFly that is confused because it finds in his temporary directories some old files which shouldn't be there and reference your exact same component.
Solution: remove in the WildFly standalone directory the content in the 'deployments' directory and the 'tmp' directory. Rest assured, all what is there is okay to remove safely. Reboot and the error message will be gone ;-)
You should pay attention to not have two #Stateless EJB annotations on top of two classes with the same name - in the same module.
You may differentiate them by using the name attribute in the annotation and put different values in each class
Looks like the class already exists. Check if it does...you may have to rewrite that part of EEModuleDescription to use its own private methods (which would be what you would write) rather than overriding methods in RoleKeyCacheImpl. If the class actually does not exist then right-click on the project -> Maven 2 Tools -> Generate Eclipse Artifacts (Check for Updates). That will regenerate all of the dependencies that the project uses. Also please be sure that you have not added any new projects to the classpath by mistake as that may also cause this error.
I just ran into this today when a colleague added a maven dependency.
Turns out this dependency was a jar with a nasty classpath entry or "../" in the manifest.
I edited the jar's manifest.mf that was cached in my local maven repository using 7-zip and removed the "../" classpath entry.
Then re-packaged my war file (maven clean install) and bingo, it works!
In my case it was caused by org.libreoffice jurt version 5.4.2 (but other versions I checked also have the classpath nastiness).
Unfortunately I was lucky we pinpointed it to a dependency, YMMV!
Error in Console:-
Initial SessionFactory creation failed.java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/transaction/SystemException
Hello
I am building a standalone Java Application with Main Method which connects to the database using Hibernate and writes to a file on C drive as well.
I have added all the libraries to the class path using Java Build Path configuration and user libraries. But I keep getting this error ...I have also added the javaee jar from the glassfish server libraries but that has also not solved the problem. I also have the jboss-transaction-api_1.1_spec-1.0.0.Final.Jar added to my class path.
Please advise as I am not using Maven as yet ???
Here are the jars in my build path-
-antlr
-c3p0
-commons-collections
-commons-logging
-commong-logging-api
-dom4j
-hibernate-c3p0
-hibernate-commons-annotation
-hibernate-core
-hibernate-entitymanager
-hibernate-envers
-hibernate-jpa
-javaee-api-6.0jar
-javaassist
-jboss-logging
-jboss-transaction-api
-jms
-log4j
-lucene-core
-MySQL-connector
-slf4j
-javaee.jar
Any help would be truly appreciated .. I am just lost on what is going on ?
I am sure you have 2 different versions for the same class. check your jars.
I'm working on a java project with spring on eclipse using Maven, and running on a Tomcat server v6.0. Everything was working fine since yesterday morning.
Here his my problem : I'm building my project, I got a build success. Then I start my Tomcat server and got this error :
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Failed to import bean definitions from URL location [classpath:applicationContext- core.xml]
Offending resource: ServletContext resource [/WEB-INF/applicationContext.xml]; nested exception is org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from class path resource [applicationContext-core.xml]; nested exception is java.io.FileNotFoundException: class path resource [applicationContext-core.xml] cannot be opened because it does not exist
I found out similar problem on some website but none of them give me a solution that worked for me.
It seems that eclipse isn't able to find applicationContext-core.xml when I'm doing this :
<import resource="classpath:applicationContext-core.xml" />
However, I do have the needed jar file nad-core-0.0.1-SNAPSHOT.jar in WEB-INF/lib containing applicationContext-core.xml.
I even tried to add it manually to the classpath but I was still having the same problem.
I keep on looking for a solution, when suddendly it work again once after restarting Eclipse and building while Eclipse was still updating indexes and my project was having this strange status Hg status pending instead of default. Surprised by this result I decide to build again my project after restarting Eclipse and I got the error again and I enable to make it work again. It's quite annoying...
This looks to be a really random problem.
Thanks a lot for your help :)
As you've not specified you web application structure. I assume you've a simple web application at hand with the following structures
webapp
WEB-INF/classes/applicationContext.xml
WEB-INF/lib/nad-core-0.0.1-SNAPSHOT.jar/applicationContext-core.xml
Application context.xml refers to the applicationContext-core.xml file using the import tag. I did encounter a similar situation in my web application, here're the check lists that you should go through and may be one of them can apply to your situation.
Check the generated snapshot jar file for the applicationContext-core.xml file and make sure it is in the root directory of the jar. As silly as it sounds, this was the root cause of the issue I faced in my deployment.
Make sure your Maven Pom.xml file is configured to include this XML file from the resources folder. You can use the resource tags in the build phase of Maven to package them within the jar file itself.
You can try removing the import tag from application context.xml file and instead load both of them from Spring's webapplication context itself.
Add a context loader listener class from spring org.springframework.web.context.ContextLoaderListener
Add context-param contextConfigLocation with value classpath:applicationContext-core.xml,classpath:applicationContext.xml. Spring has the ability to dynamically sort out the dependencies before initiating the bean factory.
Hope this check list helps.
I get pretty much the same config, six years later, I got the same error.
I also restart Eclipse, and it solved the issue.
I'm asking this question just so I can answer it myself, because it's driven me nuts for two days and no one else should have to suffer as I have.
When deploying my ear, I get exceptions like this :
Exception while invoking class org.glassfish.appclient.server.core.AppClientServerApplication start method
org.jvnet.hk2.component.ComponentException: injection failed on org.glassfish.appclient.server.core.jws.JavaWebStartInfo.dch with class org.glassfish.appclient.server.core.jws.DeveloperContentHandler
at org.jvnet.hk2.component.InjectionManager.error_injectionException(InjectionManager.java:284)
at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:161)
at org.jvnet.hk2.component.InjectionManager.inject(InjectionManager.java:93)
.
.
Caused by: org.jvnet.hk2.component.ComponentException: Failed to create class org.glassfish.appclient.server.core.jws.DeveloperContentHandler
.
.
Caused by: java.lang.AbstractMethodError: javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V
.
.
or sometimes like this :
Exception while loading the app : injection failed on org.glassfish.appclient.server.core.jws.JavaWebStartInfo.dch with class org.glassfish.appclient.server.core.jws.DeveloperContentHandler
org.jvnet.hk2.component.ComponentException: Failed to create class org.glassfish.appclient.server.core.jws.DeveloperContentHandler
at com.sun.hk2.component.ConstructorCreator.create(ConstructorCreator.java:71)
at com.sun.hk2.component.AbstractCreatorImpl.get(AbstractCreatorImpl.java:80)
.
.
Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.glassfish.appclient.server.core.jws.DeveloperContentHandler
The bug is utterly baffling, because ear files that work perfectly well on one machine can fail to deploy on another, and a server can appear to become "infected" by the problem and refuse to deploy ears that previously worked perfectly well. Clearing out caches and generated files doesn't make it go away.
After hours and hours of fiddling with it I think I have the answer - the problem is caused by having a xerxes-impl jar file included in the ear lib folder. I suspect that through some class loading weirdness it is replacing the server's own xml parser. This accounts for the strange infection problem because the class path issues don't go away until the server is restarted. It's possible that the problem will manifest with any xml parser, but I haven't checked.
To solve the problem shut down glassfish, make sure the ear you're deploying doesn't have xerces in it, and then restart glassfish and deploy your new clean ear file. It should work. It did for me. Failing that, i think your only recourse is going to be blood sacrifice.
The JDK defines the javax.xml.parsers.DocumentBuilderFactory interface and provides an default implementation. Service providers can replace the implementation class by setting a system property "javax.xml.parsers.DocumentBuilderFactory". When you deployed xerces it used this property to provide it's own implementation.
Snippet from javax.xml.parsers.DocumentBuilderFactory:
public static DocumentBuilderFactory newInstance() {
try {
return (DocumentBuilderFactory) FactoryFinder.find(
/* The default property name according to the JAXP spec */
"javax.xml.parsers.DocumentBuilderFactory",
/* The fallback implementation class name */
"com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl");
} catch (FactoryFinder.ConfigurationError e) {
throw new FactoryConfigurationError(e.getException(),
e.getMessage());
}
}
All this applies as well to javax.xml.parsers.SAXParserFactory.
Choosing the Parser Implementation
If no other factory class is specified, the default SAXParserFactory class is used. To use a parser from a different manufacturer, you can change the value of the environment >variable that points to it. You can do that from the command line:
java -Djavax.xml.parsers.SAXParserFactory=yourFactoryHere [...]
The factory name you specify must be a fully qualified class name (all package prefixes >included). For more information, see the documentation in the newInstance() method of the >SAXParserFactory class.
http://docs.oracle.com/javase/tutorial/jaxp/sax/validation.html
I am new to EJB3 and working on an exisitng code.
We are using weblogic10.3 and the below code works fine
#Stateless(mappedName="ProcessIssacIncomingMessage")
#TransactionManagement(value=TransactionManagementType.CONTAINER)
#TransactionAttribute(value=TransactionAttributeType.REQUIRED)
#EjbRef(name="Database" jnod-name="Database")
public class IncomingMessageBean implements IncomingMessageRemote, IncomingMessageLocal {
...
#Ejb
private Database<Object> databaseBean;
in 10.3 weblogic.jar has the package weblogic.ejbgen.EjbRef
We now switching over to weblogic10.3.1 and weblogic.jar no longer comes with weblogic.ejbgen package.
So, I changed the code to this (not yet tested in 10.3.1)
#Stateless(mappedName="ProcessIssacIncomingMessage")
#TransactionManagement(value=TransactionManagementType.CONTAINER)
#TransactionAttribute(value=TransactionAttributeType.REQUIRED)
#EjbRef(name="Database" jnod-name="Database") --- removed this line
public class IncomingMessageBean implements IncomingMessageRemote, IncomingMessageLocal {
...
#Ejb(mappedName="Database") -- added the mapped name here.
private Database<Object> databaseBean;
For backward compatibility. After running the code in wl10.3 I get the error
Error is - javax.ejb.EJBTransactionRolledbackException: EJB Exception: : com.bea.core.repackaged.springframework.beans.factory.BeanCreationException: Dependency injection failure: can't find the bean definition about class interface javax.persistence.EntityManager; nested exception is com.bea.core.repackaged.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type [javax.persistence.EntityManager] is defined: No beans of type javax.persistence.EntityManager; owner=com.bea.core.repackaged.springframework.context.support.GenericApplicationContext: display name
Could anyone help, what / how I should refactor the code. OR what is missing here? Such that my code is compatible with both 10.3 and 10.3.1 without using #EjbRef
I figured that the source code was not for 10.3 but some earlier version of weblogic, where in EjbRef was provided by weblogic in weblogic.jar. But as it seems after some version probably 10.3.x onwards weblogic.ejbgen.EjbRef was refactored to a different jar other than weblogic.jar
I did a explode of all jars in server/lib folder and found that same package is available in wls-api.jar
My problem is resolved now. Before I could find this, I had already removed the dependency on the code from using any weblogic specific jar files.