[
https://issues.redhat.com/browse/WFLY-14254?page=com.atlassian.jira.plugi...
]
nimo stephan commented on WFLY-14254:
-------------------------------------
{code:java}
Basically, this is grey area between specs because they don't
exactly specify how EJB and CDI container interoperate..{code}
If I use for both classes
@javax.ejb.Singleton
then the same error occurs. I guess, it is because of the CDI-"@Inject" from the
constructor injection within the Singleton "Child".
I think, in JEE Containers, the ordering is the following:
# At first, EJB's are initialized.
# Afterwards, the CDI-Runtime starts (e.g., "@Inject")
However, looking at the error above, it seems that the CDI-Container does not
"recognize" that an instance of the Parent (which is indeed a Singleton) is
already created by the EJB-Container. Which container has the responsibility for this
"recognition" - the EJB-Container or the CDI-Container? I think Wildfly, because
CDI is not aware of EJB and vice versa.
WFLYEJB0132: @PostConstruct method of EJB singleton recursively
invoked
-----------------------------------------------------------------------
Key: WFLY-14254
URL:
https://issues.redhat.com/browse/WFLY-14254
Project: WildFly
Issue Type: Bug
Components: CDI / Weld, EE
Affects Versions: 21.0.1.Final
Reporter: nimo stephan
Assignee: Matěj Novotný
Priority: Major
I have following two classes:
The *Parent* class is a "javax.ejb.Singleton" and injects the other Singleton
*Child*:
{code:java}
import javax.annotation.PostConstruct;
import javax.inject.Inject;
@javax.ejb.Singleton
@javax.ejb.Startup
public class Parent {
@Inject
private Child child;
@PostConstruct
private void postConstruct() {
System.out.println("> Parent (" + getId() + ") created.");
child.sendMessage();
}
public Integer getId() {
return this.hashCode();
}
}
{code}
The *Child* class is a "javax.inject.Singleton" and injects the other Singleton
*Parent*:
{code:java}
import javax.annotation.PostConstruct;
import javax.inject.Inject;
@javax.inject.Singleton
//(a)javax.ejb.Singleton
public class Child {
private Parent parent;
// no-args constructor not needed for @javax.inject.Singleton
public Child() {
}
// the parent should be injected if already created by container
@Inject
public Child(Parent parent) {
this.parent = parent;
}
@PostConstruct
private void postConstruct() {
System.out.println("> Child (" + getId() + ") created.");
}
public void sendMessage() {
System.out.println("> Child called to parent: " + parent.getId());
}
public Integer getId() {
return this.hashCode();
}
}
{code}
As both are Singletons, the "postConstruct()" for those two classes should only
be called once. The Child uses a constructor with an injected Parent thus it should look
for it if this instance is already created. However, it seems that the container tries to
create the Parent-Instance twice, hence the following error:
{code:java}
Caused by: java.lang.IllegalStateException: WFLYEJB0132: @PostConstruct method of EJB
singleton Parent of type io.Parent has been recursively invoked
at
org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
at
org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:48)
at
org.jboss.invocation@1.6.0.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at
org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
at
org.jboss.invocation@1.6.0.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
at
org.jboss.as.ejb3@21.0.0.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:199)
... 101 more{code}
Of course, I can use "@Inject Parent parent" within the Singleton
"Child" instead of constructor injection, then no error is shown. However,
constructor injection should also work, or? Is this a bug or is this intended?
--
This message was sent by Atlassian Jira
(v8.13.1#813001)