Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

CreateException in SLSB's ejbCreate()

 
Alec Lee
Ranch Hand
Posts: 569
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just wonder what would happen if I throw CreateException in a stateless session bean's (slsb) ejbCreate(). Recall that slsb's ejbCreate() is called by container when it creates bean pool and has nothing to do with the client calling create().

The problem is, according to the spec, the container should propagate the CreateException - which is considered just an application exception - back to the client. But which client should the container received it? There could no client at all when the ejbCreate() throw this exception!!!

The same problem applies to RemoveException in ejbRemove() too.

Appreciate any advice.
 
Valentin Crettaz
Gold Digger
Sheriff
Posts: 7610
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My wild guess would be that the container catches them and swallows them silently since it doesn't have any client to report the exception to anyway... It doesn't matter since no client is involved in these operations.

That's a good question because the spec is pretty much silent about this issue...
[ July 16, 2004: Message edited by: Valentin Crettaz ]
 
Alec Lee
Ranch Hand
Posts: 569
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The spec actually gives some contradictory information. Table 15 of p375 does require ALL session beans (stateful & stateless) and entity bean should rethrow appli exception to the client. But slsb just has no client during ejbCreate()!
 
Nathaniel Stoddard
Ranch Hand
Posts: 1258
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Furthermore, checked exceptions are considered "normal processing", so the EJB container probably "expects" a CreateException and considers it a non-lethal issue, and then proceeds to place it in the pool and go on as normal. (I would imagine ......) It's not like a CreateException causes a transaction to be rolled back [by the container], so why would the container freak out, right?
 
Valentin Crettaz
Gold Digger
Sheriff
Posts: 7610
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The spec actually gives some contradictory information
This is what I meant by silent

Actually, the container is in charge of intercepting the exceptions thrown by the beans and then depending on how whether there is a client or not, the container might re-throw the exception.

In such a case the best thing to do is to create a stateless session bean with an ejbCreate method that does nothing else but throws a CreateException and to deploy it and see what happens. On Weblogic 7 I get the following stack trace:

javax.ejb.CreateException
at com.company.SomeSessionBean.ejbCreate(SomeSessionBean.java:82)
at com.company.SomeSessionBean_5q4wi8_Impl.ejbCreate(SomeSessionBean_5q4wi8_Impl.java:122)
at java.lang.reflect.Method.invoke(Native Method)
at weblogic.ejb20.pool.StatelessSessionPool.createBean(StatelessSessionPool.java:151)
at weblogic.ejb20.pool.StatelessSessionPool.getBean(StatelessSessionPool.java:101)
at weblogic.ejb20.manager.StatelessManager.preInvoke(StatelessManager.java:142)
at weblogic.ejb20.internal.BaseEJBObject.preInvoke(BaseEJBObject.java:127)
at weblogic.ejb20.internal.StatelessEJBObject.preInvoke(StatelessEJBObject.java:61)
at com.company.SomeSessionBean_5q4wi8_EOImpl.getAll(SomeSessionBean_5q4wi8_EOImpl.java:83)
at com.company.SomeSessionBean_5q4wi8_EOImpl_WLSkel.invoke(Unknown Source)
at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:362)
at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:114)
at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:313)
at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:821)
at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:308)
at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)


... which doesn't show much except that the session bean is created only when the client requests one, and if something bad happens then the exception is propagated to the client. A good thing would be to make the container instantiate some beans at start-up and then see what happens. But I guess that there will be a server-side stack trace or something will be logged somewhere. I don't have time to investigate this further, I'll let you do that as homework
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic