2

I'm trying to specialize an EJB. I have

package com.foo.core; 
@Stateless
public class MyFacade { }

and

package com.foo.extension;    
@Specializes
@Stateless
public class MyFacade extends com.foo.core.MyFacade { }

In my opinion, this should work, because the meaning of @Specializes is, that CDI should forget about the core-class and instead use the specialized class. I also found this bug https://issues.jboss.org/browse/WELD-1451 which indicates, that it is possible to specialize an EJB.

But if i try to deploy my application (I'm using Weblogic 12.1.3), I always get

weblogic.utils.ErrorCollectionException: There are 1 nested errors: weblogic.j2ee.dd.xml.AnnotationProcessException: Duplicate ejb name 'MyFacade' found: annotation 'Stateless' on bean class com.foo.core.MyFacade and annoation 'Stateless' on bean class com.foo.extension.MyFacade

Am I doing anything wrong?

Thanks!

Ben
  • 447
  • 4
  • 13
  • The CDI spec doesn't define how the EJB spec works. Even though the defect you mention was resolved, the pull request associated to it was declined so I'm not sure anything was actually fixed for it. If you want specialize, I would recommend using pure CDI beans. – John Ament Jun 04 '15 at 13:18
  • I considered changing my EJB's to pure CDI beans. But i need the declarative transaction control. I could us @Transactional, but this is part of JEE7 and therefore not available in Weblogic 12.1.3. – Ben Jun 04 '15 at 13:29
  • As JohnAment said, @Specializes is a CDI feature and its spec, doesn't define how to work with EJB. I use weblogic and i recommend you that if you''ll wait for this situation be fix in weblogic, it can take a lot of time. So, try to find another approach using only CDI spec. – Adam M. Gamboa G. Jun 04 '15 at 19:53
  • John and Adam, have you guys actually read the CDI spec before announcing to the world what it says? I think not because you are completely wrong. The CDI spec has made it clear that it is fully possible to specialize EJB:s session beans since 1.0. Furthermore, it even requires the CDI container to perform the dependency injection for `@EJB` annotated injection points. However, most Java EE containers/servers out there has extremely sucky code bases. Which is kind of expected to be honest since the specifications themselves are pretty sucky. The EJB spec should be removed altogether. – Martin Andersson Jan 26 '17 at 16:55
  • Ben, there is no provider-independent way to figure out what went wrong by examining an `EJBException`. Hence, "container-managed transaction demarcation" is completely useless because a serious application will always need to figure out what went wrong and how to handle it. There are numerous issues with EJB:s and you are most likely best off forgetting everything about it. – Martin Andersson Jan 26 '17 at 16:59

1 Answers1

2

The exception message you quoted is caused by a name conflict, which is not directly related to CDI at all: each EJB can be addressed by a number of different JNDI names, and some of them (e.g. java:module/MyFacade) only include the simple class name, not the package name. So you cannot have two EJBs with the same name in different packages.

Adding CDI and @Specializes may prevent the specialized EJB from showing up in the CDI container, but it is still an EJB.

You can try to rename your derived class - this should solve the duplicate name issue, but I'm not sure it will solve your overall problem.

Harald Wellmann
  • 12,615
  • 4
  • 41
  • 63