0000273: CLONE -NPE in AmberConnectionImpl - not fully resolved

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.

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

Relationships