WildFly 8 CR1: Problem with calling methods from EJB inside ManagedBean (via @EJB)

[domen91]

Hello.

I have EAR application (WEB, JPA, EJB, EJB Client) which was worked great with WildFly 8 Beta 1.

Today I tested with WildFLy 8 CR1 and now I have problem with calling methods via annotation @EJB (inside ManagedBean). I attached configuration files for Beta 1 and CR1. I upload console error, too.

I have application:

• JSF file which call Managed Bean (@ManagedBean(name="loginBean") & @RequestScoped)
• Inside MB: @EJB UserPrincipalLocal userPrincipal;
• UserPrincipalLocal it is interface (local)
• Local interface is call in EJB context like:

@Stateless

@Local(UserPrincipalLocal.class)

@LocalBean

@PermitAll

public class UserPrincipalDecoder implements UserPrincipalLocal

• Inside this class is return all data, but when request get to the MB then get

INFO  [org.jboss.jca.core.connectionmanager.listener.TxConnectionListener] (default task-14) IJ000311: Throwable from unregister connection: java.lang.IllegalStateException: IJ000152: Trying to return an unknown connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@1f8109e

Is this a bug or I have something wrong in configuration?

Thanks for the help

-------

I am using Eclipse Kepler SR 1 with JBoss Tool 4.1.1.

Files:

• standalone-BETA1.xml : config file for WildFly 8 Beta 1
• standalone-CR1.xml: config file for WildFly 8 CR1
• console_error.txt: error
• config.txt: otehr config inside EAR

[domen91]

I have little edit config file nad set use-ccm to false. Restart AS and then i get no error such it is write in first post.

Why?

Second problem:

@EJB in Faces converter doesnt work in CR1 version (in Beta 1) it is working.

Code:

@FacesConverter(value = "unitConverter")

public class UnitConverter extends AbstractBean<UnitConverter> implements Converter {

    private static final long serialVersionUID = 1L;

    @EJB

    UnitLocal                 unitLocal; // In CR1 is is null, in Beta 1 its working.

    ...

}

Tnx.

[cfillot]

About your second problem, it seems that injection in JSF converters will only be possible with JSF 2.3+:

http://stackoverflow.com/questions/7665673/jsf2-can-i-use-ejb-to-inject-a-service-into-a-facesconverter

[domen91]

Too bad about injection in JSF converters & validators (I do not know why it worked in Beta 1 ).

Quick solution about injection:

add @ManagedBean and @ApplicationScoped above @FacesConverter (in JSF replace convertName => #{convertName}, in the validation stays JSF unchanged)

[daniell]

Have you found a solution for your first problem, the IllegalStateException complaining about an unknown connection?

I have the same issue (after porting from JBoss AS 7.1.1.Final without error to Wildfly 8.0.0.CR1) and invested a lot of time up to now to find out something useful. I do not even know the concrete source of the problem. Is it JTA, JPA or JCA?

I've only found the following pretty old forum-thread: https://community.jboss.org/thread/87186

When using this "solution" (flushing the session right before doing the UserTx.commit), the exception does not occur any more. Also when switching to CMT the exception is not raised any more.

But I would be very glad to know the reason why I'm getting this exception now and how to avoid it in the future...

[mandrosen]

I am having the same connection issue.  I can confirm that both solutions mentioned work:

1.changing use-ccm to false

2. flushing the session before the call

I am concerned that solution 1 will leave us open to connection leaks, but since we never open connections manually, this might not be an issue.  Solution 2 will require a lot of code changes and testing.

I have read that this isn't really a big deal -- one hint is that the exception is logged as INFO.

Is it really safe to ignore this exception and are there any other solutions?

[smarlow]

Could you enable trace logging for a few categories and reproduce the warning (with use-ccm=true).  Some instructions for enabling trace logging are here.

Please enable trace logging for:

• org.jboss.jca.core.api.connectionmanager.ccm
• com.arjuna
• org.jboss.as.jpa

I think that will get us a basic idea of what is going on.  It might also be helpful if someone can reproduce in a standalone deployment. 

[mandrosen]

Thank you for looking into this.  I attached the relevant section of our standalone.log with the trace logging enabled for the three categories you mentioned.

In our case, the sequence of events is the following:

In EbjA:

     @PersistenceContext

     private EntityManager em;

     @EJB

     private EjbBInt ejbB;

     public Thing getThing() {

          Thing thing = getThing();

          ejbB.doSomethingElse();

          return thing;

     }

In EjbB:

     @PersistenceContext

     private EntityManager em;

     public boolean doSomethingElse() {

          ...save something with EntityManager...

     }

The Exception is thrown in EjbB.doSomethingElse() when trying to use the EntityManager.

Here is the datasource config:

                <datasource jta="true" jndi-name="java:jboss/datasources/atDS" pool-name="MySqlDS" enabled="true" spy="true" use-ccm="true">

                    <connection-url>jdbc:mysql://devdb:3306/atdb</connection-url>

                    <driver-class>com.mysql.jdbc.Driver</driver-class>

                    <driver>mysql-connector-java-5.1.22-bin.jar</driver>

                    <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>

                    <pool>

                        <min-pool-size>0</min-pool-size>

                        <max-pool-size>10</max-pool-size>

                        <prefill>true</prefill>

                        <use-strict-min>true</use-strict-min>

                        <flush-strategy>IdleConnections</flush-strategy>

                    </pool>

                    <security>

                        <user-name>......</user-name>

                        <password>.......</password>

                    </security>

                </datasource>

[smarlow]

Domen,

Would be great to have TRACE output from you also as there might be some variation between the problems reported here.  When you have TRACE enabled, please recreate the reported problem and attach the output.

Scott

[smarlow]

Marc,

Your case looks a little different (according to the exception call stack) but could be related.

It looks like the connection "org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@4de27c01" was obtained from EjbA and is being released during the EjbB invocation.

2014-02-10 14:17:02,388 INFO  [org.jboss.jca.core.connectionmanager.listener.TxConnectionListener] (default task-5) IJ000311: Throwable from unregister connection: java.lang.IllegalStateException: IJ000152: Trying to return an unknown connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@4de27c01

        at org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.unregisterConnection(CachedConnectionManagerImpl.java:385)

        at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.connectionClosed(TxConnectionListener.java:587)

        at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:581)

        at org.jboss.jca.adapters.jdbc.WrappedConnection.close(WrappedConnection.java:265)

        at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.closeConnection(DatasourceConnectionProviderImpl.java:144) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]

        at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.releaseConnection(AbstractSessionImpl.java:391) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]

        at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.releaseConnection(LogicalConnectionImpl.java:255) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]

        at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterStatementExecution(JdbcCoordinatorImpl.java:279) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]

        at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.release(JdbcCoordinatorImpl.java:409) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]

        at org.hibernate.loader.Loader.doQuery(Loader.java:923) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]

        at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:354) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]

        at org.hibernate.loader.Loader.doList(Loader.java:2551) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]

        at org.hibernate.loader.Loader.doList(Loader.java:2537) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]

        at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2367) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]

        at org.hibernate.loader.Loader.list(Loader.java:2362) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]

        at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:496) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]

        at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:387) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]

        at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:229) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]

        at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1260) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]

        at org.hibernate.internal.QueryImpl.list(QueryImpl.java:103) [hibernate-core-4.3.0.Final.jar:4.3.0.Final]

        at com.at.hib.persistence.dao.UsersDAO.getEmployee(UsersDAO.java:42) [athib.jar:]

        at com.at.ejb.employee.EmployeeBean.getEmployee(EmployeeBean.java:183) [atbusiness.jar:]

While it is just an informational logged message, I think we should find the cause and verify correctness.  I pasted the call stack here for convenience.

Scott

[mandrosen]

That is correct, exactly what is happening.

[smarlow]

Marc,

Could also enable TRACE logging for org.hibernate and run again.  I can't tell from the exception call stack, which Hibernate transaction factory was used (could of been CMTTransactionFactory, JtaTransactionFactory or JdbcTransactionFactory). 

Scott

[mandrosen]

Our persistence.xml has the following:

<property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.JBossTransactionManagerLookup"/>

Do you need the full log?

[mandrosen]

Sorry, misread that.  Here is the log.  I tried to remove unnecessary entries for SQL, QueryPlans, Parameters, Entity Loading, etc.

[smarlow]

The full log would be fine, thanks.  Have you tried commenting out the "hibernate.transaction.manager_lookup_class"?