Session beans not bound to JNDI and Singleton bean not injected.

[zds]

Hello!

We are in process of migrating from JBoss AS 6.1.0 to AS 7.1.1. I have changed the packaging to match that of JBoss 7 and the .ear deploys without errors, but session beans (stateless and singleton) do not get bound to JNDI _and_ singleton bean does not get injected to session bean referring to it. When I look at the JBoss Management console, none of the 40 or so session beans on the same jar show on JNDI; if I put couple of the session beans to different jar they show on JNDI. Another problem, possibly related, is that a session bean that gets injected throws NPE on creation because the singleton bean that should have been injected by @EJB clause is null.

So, for example, my @Singleton @Startup beans runs fine, and on the @PostConstruct method all the referenced session beans are injected a-ok and work. _But_ they are not bound to JNDI.

Now: where do I start debugging this? I have run the JBoss on log level trace, but it reports no errors or warnings; it behaves like everything went OK, but then fails to work

[jaikiran]

What does your packaging look like?

[nickarls]

Isn't there a listing of JNDI names for each EJB when you deploy? Can you show the log?

[zds]

The packaging looks like this:

-ear

   -jar containing all session beans and business logic, depending on the five jars containing the entity beans

   -jar containing entities for datasource 1

   -jar containing entities for datasource 2

   -jar containing entities for datasource 3

   -jar containing entities for datasource 4

   -jar containing EJB 2.1 entity beans for datasource 1

   -jar containing few utility classes needed by several of the entity bean packages

We have some 45 session beans in total and they cross-reference each other a lot. I did some deduction search and found that removing set of the session beans helped and I started seeing the JNDI entries bound as they should. But, it was not that simple. I now have three pairs of jars, versions of the first one on the list, that differ only by 1 session bean each, and on each pair problem exhibits on one but not on the other. _And_ the session bean is different on each of them. This implies the problematic part is not any single session bean, but some combination of them. Or at least the problem exists in several of the beans.

Here's all annotations and some context around them for _one_ of the three session beans that seem problematic:

@Stateless

@TransactionAttribute(TransactionAttributeType.REQUIRED)

public class Session1Bean implements

        Session1Local, Session1Remote {

...

    @Resource

    private SessionContext sessionContext;

    @Resource

    private UserTransaction userTransaction;

    @PersistenceContext(unitName = PERSISTENCE_CONTEXT_OPERATIONAL_NAME)

    protected transient EntityManager entityManager;

...

--- Four methods all with @Overrive and no transaction:

    @Override

    @TransactionAttribute(TransactionAttributeType.NEVER)

    public int method1(final EActor eActor) {

...

--- And then two with REQUIRED.

    @Override

    @TransactionAttribute(TransactionAttributeType.REQUIRED)

    public boolean method5(Bar s, Date date) {

One thing to note is, however, that all three problem beans have remote interface; most others don't.

[zds]

Nicklas, here's log for one of the problematic beans:

23.01 15:52:26,000 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-3:) JNDI bindings for session bean named AddressResolverBean in deployment unit subdeployment "mpk-demo-us-k3-main.jar" of deployment "mpk-demo

-us.ear" are as follows:

        java:global/mpk-demo-us/mpk-demo-us-k3-main/AddressResolverBean!com.ecolane.mpk.util.interfaces.AddressResolverLocal

        java:app/mpk-demo-us-k3-main/AddressResolverBean!com.ecolane.mpk.util.interfaces.AddressResolverLocal

        java:module/AddressResolverBean!com.ecolane.mpk.util.interfaces.AddressResolverLocal

        java:global/mpk-demo-us/mpk-demo-us-k3-main/AddressResolverBean!com.ecolane.mpk.util.interfaces.AddressResolverRemote

        java:app/mpk-demo-us-k3-main/AddressResolverBean!com.ecolane.mpk.util.interfaces.AddressResolverRemote

        java:module/AddressResolverBean!com.ecolane.mpk.util.interfaces.AddressResolverRemote

        java:jboss/exported/mpk-demo-us/mpk-demo-us-k3-main/AddressResolverBean!com.ecolane.mpk.util.interfaces.AddressResolverRemote

As far as I can see, the JNDI names are _printed_ exactly right for all beans; the beans just are not bound sometimes. And the beans actually mostly work, even when not bound; injection works some 95% time even when the JNDI bindings are lacking.

[zds]

Testing further: Removing the @Remote annotations from the remote interfaces makes the whole project deploy fine. Of course the parts needing remote calls don't work then, but even a single session bean having remote interface annotated with @Remote seems to be enough to make JBoss silently skip binding any of the session beans to JNDI.

[zds]

OK, after one day of reduction work this is as simple as I can make it:

Bean class:

import javax.ejb.Stateless;

@Stateless

public class BugReproductionBean implements BugReproductionRemote {

    @Override

    public void method() {

        // Empty

    }

}

Remote interface:

import javax.ejb.Remote;

@Remote

public interface BugReproductionRemote {

    public void method() throws java.rmi.RemoteException;

}

application.xml on EAR level:

<?xml version="1.0" encoding="UTF-8"?>

<application xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  version="6" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_6.xsd">

  <display-name>Bug Demonstration app</display-name>

  <module>

    <ejb>bugrepro.jar</ejb>

  </module>

</application>

Inside bugrepro.jar, ejb-jar.xml:

<?xml version="1.0" encoding="UTF-8"?>

<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

                            http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"

    version="3.1">

   <description><![CDATA[No Description.]]></description>

    <display-name>Bug reproduction</display-name>

</ejb-jar>

And with these, I can see:

16:56:08,123 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "bugrepro.ear"

16:56:08,129 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "bugrepro.jar"

16:56:08,142 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-6) JNDI bindings for session bean named BugReproductionBean in deployment unit subdeployment "bugrepro.jar" of deployment "bugrepro.ear" are as follows:

          java:global/bugrepro/bugrepro/BugReproductionBean!BugReproductionRemote

          java:app/bugrepro/BugReproductionBean!BugReproductionRemote

          java:module/BugReproductionBean!BugReproductionRemote

          java:jboss/exported/bugrepro/bugrepro/BugReproductionBean!BugReproductionRemote

          java:global/bugrepro/bugrepro/BugReproductionBean

          java:app/bugrepro/BugReproductionBean

          java:module/BugReproductionBean

16:56:08,165 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018565: Replaced deployment "bugrepro.ear" with deployment "bugrepro.ear"

But no JNDI binding actually takes place. Now: Comment out the @Remote and the bean gets bound. The printout:

16:55:43,066 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015876: Starting deployment of "bugrepro.ear"

16:55:43,072 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015876: Starting deployment of "bugrepro.jar"

16:55:43,082 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-1) JNDI bindings for session bean named BugReproductionBean in deployment unit subdeployment "bugrepro.jar" of deployment "bugrepro.ear" are as follows:

          java:global/bugrepro/bugrepro/BugReproductionBean!BugReproductionRemote

          java:app/bugrepro/BugReproductionBean!BugReproductionRemote

          java:module/BugReproductionBean!BugReproductionRemote

          java:global/bugrepro/bugrepro/BugReproductionBean

          java:app/bugrepro/BugReproductionBean

          java:module/BugReproductionBean

16:55:43,104 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018565: Replaced deployment "bugrepro.ear" with deployment "bugrepro.ear"

What am I doing wrong here?

[zds]

Against 7.2.0ALPHA this particular problem does not manifest. I am disappointed on JBoss 7 - it's fine to have bugs, but failing silently in error cases is very, very bad for an application server. It feels like the 7 series had just wrapped all code to catch(Exception e) { // Do nothing }...

[nickarls]

Let's see if we can summon 1pcs of Jaikiran here to comment on the @Remote...

So if I'm understanding correctly

On AS 7.1.1

  With @Remote, deployment bindings are ok (including exported name) but some of them did not work (even when referenced exactly as deployment output showed)

   Without @Remote, deployment bindings are ok (no exported name) and all of them worked

On AS 7.2.x

    Everything works (and the deploymen output for bindings are as in 7.1.1)

?

[jaikiran]

Jari Juslin wrote:

Against 7.2.0ALPHA this particular problem does not manifest. I am disappointed on JBoss 7 - it's fine to have bugs, but failing silently in error cases is very, very bad for an application server.

None of us like silent failures.

Jari Juslin wrote:

It feels like the 7 series had just wrapped all code to catch(Exception e) { // Do nothing }...

Really? We haven't yet figured out if there was an exception being thrown in first place. I haven't had the time to look into that deployment yet and I pushed it out for later since it appears to have been fixed in upstream (snapshot). I'll take a look at it over the weekend or next week.

Anyway, thank you for creating that JIRA.

[jaikiran]

I just commented on that JIRA https://issues.jboss.org/browse/AS7-6410#comment-12753011. I can't reproduce it against 7.1.1.Final either.

[zds]

Nicklas Karlsson wrote:

Let's see if we can summon 1pcs of Jaikiran here to comment on the @Remote...

So if I'm understanding correctly

On AS 7.1.1

  With @Remote, deployment bindings are ok (including exported name) but some of them did not work (even when referenced exactly as deployment output showed)

   Without @Remote, deployment bindings are ok (no exported name) and all of them worked

On AS 7.2.x

    Everything works (and the deploymen output for bindings are as in 7.1.1)

?

No. On 7.1.1 if there is a single interface with @Remote in the same jar, none of the session bean interfaces get bound to JNDI; ie. not just the @Remote interfaces are missing, but also all the @Local:s. If there are no @Remote interfaces, then @Local:s bind; otherwise not.7.2.x: Yes

On 7.2.x everything works and the actual JNDI bindings match the announced bindings. I cannot say to have tested *all* of them, but the ones I tested show up on JNDI browser and accessing them from there programmatically works.

@Jaikiran: I apologize for my unconstructive tone. I am aware that every software has bugs. The JBoss 6 -> JBoss 7 migration process was just so overtly annoying to do, that my frustration bled through too much.

[zds]

jaikiran pai wrote:

I just commented on that JIRA https://issues.jboss.org/browse/AS7-6410#comment-12753011. I can't reproduce it against 7.1.1.Final either.

Did you read my comment? You said you saw the JNDI bindings on the logs. They *always* print to logs, even when the bindings are not actually made. To see if the bug exists you need to look at the JNDI browser to see if they are _actually_ bound.e whole

This is one of the reasons why this bug is annoying: JBoss prints the bindings to the logs even when it does not actually bind anything.

[jaikiran]

Did you try looking it up from your application to make sure they aren't bound and it's not just a admin console problem (assuming that's what you use for the JNDI view)?

Anyway, like it was said in the JIRA, even if it was a bug in that release, it has been fixed upstream. There's nothing more that can be done to that JIRA.

[zds]

jaikiran pai wrote:

Did you try looking it up from your application to make sure they aren't bound and it's not just a admin console problem (assuming that's what you use for the JNDI view)?

Yes. They are not bound, so it's not just a console problem. I tested it by getting session bean local interface from JNDI - if there are any @Remote interfaces in the JAR, this fails. If not, it succeeds.

If they were only missing from console view, it would not be a real issue.

And yes, this being fixed upstream helps a bit, but.. We can't really migrate our production systems into ALPHA-level codebase. So people who use JBoss 6 on production and need remote access to session beans will need to wait for some later release before migrating. This is a slight problem, considering JBoss 6 does not run on Java 7 _and_ Java 6 went EoL last week, meaning Java 6 is becoming a security hole in production environments at very fast pace.

So a 7.1.2 or something that would fix this kind of clear bugs would be appreciated.