WFLYEE0040: A component named '...' is already defined in this module

Question

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?

Cheadle

Please try a clean build, also check if exists a class in another package with the same name? – Felicita

I'll add it to the question, of course I tried clean building. No other class with that name exists.... as I said, checking out the same source on another machine and it runs. – Cheadle

Have a look @ #31834204 and the accepted answer i.e. server clean... – Epiphragm

Thanks mkane, unfortunately we already tried that many times and it doesn't help. Will add it to the question. – Cheadle

How are you packaging up your code? Is there any chance you might be duplicating this? E.g having two WARs with depenency to same artifact? – Confetti

@WillT Not really. We are producing WARs that get deployed to Wildfly. But in the test environment, only a single WAR gets deployed. And as I said: the same source code, checked freshly out of Git, built and deployed, runs fine on 2 machines, and gives that error on 2 other machines... – Cheadle

If you clean the data and tmp directory while the server is stopped, does it help at all? – Confetti

Thanks for your ongoing concern @WillT :) but I no longer have access to that machine. We simply continued on the machine where it worked and never resolved this issue. May it not happen again! Not the solution I was hoping for, but alas. – Cheadle

Answer 1

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 ;-)

Eldreeda

Thanks for the answer. That project is long over... thank god :) and I hope to never having to deal with this again. But I clearly remember we cleaned that deployments-folder like 10000x, reinstalled Wildfly several times... all to no avail. Not sure about cleaning a tmp folder though. The unpredictable nature of the error suggests something like you say, some concurrency issue that for some reason only happens on some machines and not others... we never fixed this error. But I hope that maybe the answers here will help the next guy. – Cheadle

This didn't completely solve the issue for me; I had one more step. In the Eclipse/Code-Ready project directory .../.settings, I had to modify this file: org.eclipse.wst.common.component There was a line: <wb-resource deploy-path="/WEB-INF/classes" source-path="/" /> It needed to be: <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/java"/> This caused Eclipse to include the .../target directory, which had a copy of the JAR, which it nested as another project. That was actually the give-away, under the Eclipse Server tab when I'd load the project. – Edgewise

Answer 2

mvn clean install This did the trick for me

Blodgett

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Donaugh

Answer 3

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

Arela

Answer 4

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.

Advertisement

That sounds interesting, but I do not have a "Maven 2 Tools" menu entry... – Cheadle

Answer 5

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!

Asperity

Thanks DennisMe, I read a similar solution somewhere with a classpath entry of "./", but it doesn't apply to my problem, as far as I can see. As I said, the problem does not occur on every machine, just some. – Cheadle

Answer 6

I got the same error WFLYEE0040 but in my case it wasn't related to Widlfy nor Eclipse. It doesn't answer the original question but I'll leave this here for whoever needs it.

In my case the sources of sibling modules from a parent project, which the module I needed to deploy depended on, also ended up in the WEB-INF/classes directory of my war.

The cause was a project misconfiguration in IntelliJ. I don't recall changing my configuration but one day, it suddenly it didn't work anymore. In Project settings > Modules the Compiler Output was set to the parent project instead of the module's.

In my case the parent project was my-prj, the module I needed to deploy was my-prj-webservice which was dependending on my-prj-dao and my-prj-service modules. The compiler output was set to D:\my-prj\my-prj\target\classes for each module while it should have been respectively: D:\my-prj\my-prj-webservice\target\classes, D:\my-prj\my-prj-dao\target\classes and D:\my-prj\my-prj-service\target\classes.

Nutcracker