Mantis - Resin
Viewing Issue Advanced Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
273 minor always 06-20-05 00:00 11-30-05 14:42
Reporter: user241 Platform:  
Assigned To: OS:  
Priority: urgent OS Version:  
Status: closed Product Version: 3.0.12  
Product Build: 3.0.12 Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 3.0.15  
Summary: 0000273: CLONE -NPE in AmberConnectionImpl - not fully resolved
Description: RSN-308
The aplication in the attached file generate this stack trace (in System.out):

Caused by: java.lang.NullPointerException
        at com.caucho.amber.connection.AmberConnectionImpl.getConnection(AmberConnectionImpl.java:630)
        at com.caucho.amber.connection.AmberConnectionImpl.prepareStatement(AmberConnectionImpl.java:660)
        at server.eb.UnaEntidad.__caucho_load_0(UnaEntidad.java:140)
        at server.eb.UnaEntidad.__caucho_retrieve(UnaEntidad.java:105)
        at com.caucho.amber.entity.AmberEntityHome.findEntityItem(AmberEntityHome.java:324)
        ...

The aplication use two "ejb-server":

- The first one contains a entity bean (and so use a datasource).
- The second ejb-server contains only a session bean and doesn't use any datasource.

When the session bean from the second ejb-server calls a session bean from the first, resin doesn't encounter the correct data-source.

Francois
Steps To Reproduce:
Additional Information: Linux, Sun JDK 1.5.0_02, postgres 7.1, resin 3.0.12
Relationships
Attached Files:

Notes
(0000302)
user241   
06-20-05 00:00   
the problems with mutiple ejb-servers was supposedly resolved in rsn-35. however, now what happens is that any ejb-ql or amber queries from beans in the second ejb-server fail with the exception

com.caucho.ejb.FinderExceptionWrapper: com.caucho.amber.query.QueryParseException: 'enduser' is an unknown entity.in "SELECT e FROM enduser e WHERE lower(e.userName) = lower(?1)"

resin seems to lose track of the schemas in the second ejb-server beans. if i switch the order of ejb-servers specified, this query works but those in the other ejb-server don't work anymore.

3.0.snap - Jun 15, 2005

christian
(0000303)
user241   
06-20-05 00:00   
forgot to add that the above example exception occurs from this query:

    <query>
      <query-method>
        <method-name>findByUserName</method-name>
      </query-method>
      <ejb-ql>SELECT OBJECT(e) FROM enduser e WHERE lower(e.userName) = lower(?1)</ejb-ql>
    </query>

It would be very nice to get this resolved as it's stopping us from migrating to resin 3 from resin 2.

cheers
christian
(0000304)
ferg   
06-20-05 00:00   
ejb/0g0b

The Amber/EJB contexts cannnot be shared across an environment. Each <ejb-server> needs its own distinct context.
(0000305)
user241   
06-20-05 00:00   
What does this mean? Maybe you are misunderstanding the problem. We are not sharing an ejb context across an environment - each of our ejb-servers is self-contained.

As per attached, we have the following portion from resin.conf:

     <!-- configures the root web-app -->
      <web-app id='/' document-directory='/Volumes/Users/case/Development/IdeaProjects/qmci/ROOT/exploded'>
      <work-dir>${resinHome}/work</work-dir>

      <ejb-server>
        <jndi-name>java:comp/env/cmp_hist</jndi-name>
        <data-source>jdbc/hist_rw</data-source>
        <config-directory>WEB-INF/classes/cmp/hist</config-directory>
        <create-database-schema>false</create-database-schema>
      </ejb-server>

      <ejb-server>
        <jndi-name>java:comp/env/cmp_user</jndi-name>
        <data-source>jdbc/log_rw</data-source>
        <config-directory>WEB-INF/classes/cmp/user</config-directory>
        <create-database-schema>false</create-database-schema>
      </ejb-server>

...

Each ejb server has it's own jndi source, config files, etc. What happens is that bean queries from the first ejb-server (cmp_hist) work fine, but ejb-ql or amber queries from the second server (cmp_user) fail with errors like

com.caucho.ejb.FinderExceptionWrapper: com.caucho.amber.query.QueryParseException: 'enduser' is an unknown entity.
in "SELECT e FROM enduser e WHERE lower(e.userName) = lower(?1)"

this comes from the following ejb-ql which is in the attached users.ejb file and is located in cmp/user (part of the cmp_user ejb server).

 <query>
      <query-method>
        <method-name>findByUserName</method-name>
      </query-method>
      <ejb-ql>SELECT OBJECT(e) FROM enduser e WHERE lower(e.userName) = lower(?1)</ejb-ql>
    </query>


Now, if I switch the order of the ejb-servers in the conf file, this and all other calls to the cmp_user ejb server will now work. but now similar calls to beans in the other ejb-server (cmp_hist) will fail. for example:

com.caucho.ejb.FinderExceptionWrapper: com.caucho.amber.query.QueryParseException: 'symbol' is an unknown entity.
in "SELECT s FROM symbol s WHERE s.symbol = ?1"

which comes from the following ejb-ql in the attached symbols.ejb and is part of the cmp_hist ejb server.

    <query>
      <query-method>
        <method-name>findBySymbol</method-name>
      </query-method>
      <ejb-ql>SELECT object(s) from symbol s where s.symbol=?1</ejb-ql>
    </query>



the order of the ejb servers dictates the problem - the first one works fine but the second doesn't. I don't think we are doing anything wrong and I am sure it is a bug, because previously to 3.0.14 and the supposed fixing of this original (or closely related) bug which was submitted by someone else (NPE in AmberConnectionImpl), it acted differently - calls from the second ejb server would use the jndi datasource of the first and then obviously fail. Additionally of course, this all works in resin 2.x but has never worked in resin 3.x.
(0000306)
ferg   
06-20-05 00:00   
<em>What does this mean?</em>

It's a description of the internal architecture problem with 3.0.14 resolved by the fix, not any comment on the use of separate <ejb-server> blocks. Using separate <ejb-server> is allowed.

The underlying difficulty was the global nature of the java:comp/EntityManager in EJB 3.0, which appeared to require some shared state between the <ejb-server> (which added to the complexity.) The change in this bug report mandates that each <ejb-server> block has its own java:comp/EntityManager, i.e. that any second <ejb-server> would need to store the EntityManager as a different name in JNDI.