7

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?

jackthehipster
  • 978
  • 8
  • 26
  • 2
    Please try a clean build, also check if exists a class in another package with the same name? – Rcordoval Dec 20 '18 at 08:16
  • 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. – jackthehipster Dec 20 '18 at 08:40
  • Have a look @ https://stackoverflow.com/questions/31833704/wrong-dependencies-with-ejb-in-jboss-wildfly and the accepted answer i.e. server clean... – mkane Dec 20 '18 at 10:18
  • Thanks mkane, unfortunately we already tried that many times and it doesn't help. Will add it to the question. – jackthehipster Dec 20 '18 at 13:34
  • 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? – Will Tatam Dec 20 '18 at 16:46
  • @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... – jackthehipster Dec 21 '18 at 09:20
  • If you clean the data and tmp directory while the server is stopped, does it help at all? – Will Tatam Mar 21 '19 at 07:56
  • 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. – jackthehipster Mar 22 '19 at 08:17

5 Answers5

4

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

onderbewustzijn
  • 935
  • 7
  • 32
  • 1
    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. – jackthehipster Nov 24 '20 at 11:54
  • 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: It needed to be: 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. – FederOnline Oct 10 '22 at 18:26
1

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

Iair Gielis
  • 11
  • 1
1

mvn clean install This did the trick for me

Asma
  • 11
  • 1
  • 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](/help/how-to-answer). – Community Aug 15 '23 at 07:36
0

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.

Zach Pedigo
  • 396
  • 2
  • 9
0

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!

DennisMe
  • 1
  • 2
  • 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. – jackthehipster Jan 04 '19 at 11:19