2 Replies Latest reply on Feb 19, 2009 8:47 AM by horstl

Deployment EJB3 5.0 GA migration

horstl Feb 19, 2009 5:25 AM

hello all,

i have a question about migration from jboss 4.2.3GA to 5.0.0GA with EJB3.0 (about 300 EJB's)
my ear was working under 4.2.3GA without problems in 5.0.0GA i always get a Stackoverflow
the xml deployment descriptors
application.xml, jboss-app.xml, persistence.xml
are all fixed and corrected to the new version, the EJB3 is only annotated

the standard setup of my EJB beans is

Entity Bean (@Entity) / Entity Bean IF (no annotations)

EntityManager (as Stateless Session bean/ includes @PersistenceContext)
EntityManagerIF (only @Local)

ManagerBean (@Stateless with the business logic)
ManagerBeanIF (only @Remote)

now the question: how can i check where the problem is ?

2009-02-19 11:12:20,624 INFO [org.jboss.ejb3.EJBContainer] (HDScanner) STARTED EJB: at.test.persistence.xyzEM ejbName: xyzEM
2009-02-19 11:12:20,627 INFO [org.jboss.ejb3.session.SessionSpecContainer] (HDScanner) Stopping jboss.j2ee:ear=test.ear,jar=test.jar,name=xyzEM,service=EJB3
2009-02-19 11:12:20,628 INFO [org.jboss.ejb3.EJBContainer] (HDScanner) STOPPED EJB: at.test.persistence.xyzEM ejbName: xyzEM
2009-02-19 11:12:20,629 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] (HDScanner) Error installing to Start: name=jboss.j2ee:ear=test.ear,jar=test.jar,name=xyzEM,service=EJB3 state=Create java.lang.StackOverflowError
 at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:69)
 at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150)
 at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66)
 at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)

in the old version of jboss there was always an info when an ear was deployed this is also missing now

br horst

PS: the overflow is not coming up on the same position of the deployment

1. Re: Deployment EJB3 5.0 GA migration

jaikiran Feb 19, 2009 5:40 AM (in response to horstl)

One other user too had reported this, a few days back. We have a JIRA for this https://jira.jboss.org/jira/browse/EJBTHREE-1724. However, i haven't been able to reproduce this because of lack of an application which shows this issue.

If it's possible, could you please attach an application which reproduces this, to that JIRA?
Actions
2. Re: Deployment EJB3 5.0 GA migration

horstl Feb 19, 2009 8:47 AM (in response to horstl)

hi jaikiran,

first thanx for response :-)
yes bug seem to be the same, problem the ear has a size about 20Mb and is my work of the last year:-) therefore i don't want to upload it anywhere...
i have a smaller test application (same style of implementation) but with this one the failure is not reproduceable, it seems only with a lot of beans the problem is coming up...

but can you tell me how the loading and registration is running of the entity beans and the sessionbeans, then i will help to resolve this problem

as i have seen there are this steps

1) checking dependencies of the beans
(JBossASKernel) Created KernelDeployment: installs SLSB with dependencies

2) register all beans without dep on persistence unit
(SessionSpecContainer) Starting bean only Facade (managerbean/remote if)
(EJBContainer) info about started
(JndiSessionRegistrarBase) registering for binding global jndi (managerbean with @remote)

3) database (what is this?: WARN [org.hibernate.ejb.Ejb3Configuration] (main) Persistence provider caller does not implement the EJB3 spec correctly.PersistenceUnitInfo.getNewTempClassLoader() is null)
(Ejb3Configuration) db handling schema/table generation etc
(SessionSpecContainer/EJBContainer) starting the EJB3 beans

4) register beans with persistence unit dep
(SessionSpecContainer) Starting bean only PeristenceContext (entitymanager)
(EJBContainer) info about started
(JndiSessionRegistrarBase) registering for binding global jndi (entitymanager with @local)

FAILURE always in this setp

but it seems that the failure is in a step afterwards and only the logging is to slow...
whats coming up next ?

br horst
Actions

Go to original post