Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000273 [Resin] minor always 06-20-05 00:00 11-30-05 14:42
Reporter quotemedia View Status public  
Assigned To
Priority urgent Resolution fixed  
Status closed   Product Version 3.0.12
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
Additional Information Linux, Sun JDK 1.5.0_02, postgres 7.1, resin 3.0.12
Attached Files

- Relationships

- Notes
(0000302)
quotemedia
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)
quotemedia
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)
quotemedia
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.
 

- Issue History
Date Modified Username Field Change
06-20-05 00:00 quotemedia New Issue
11-30-05 00:00 administrator Fixed in Version  => 3.0.15
11-30-05 14:42 ferg Status resolved => closed


Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
33 total queries executed.
31 unique queries executed.
Powered by Mantis Bugtracker