oh I forgot to say...
I print the hashCode at every message of the testBean now (gee if you ask me
politely I might put it in) so that you can clearly see that the new
"setEntityContext" is on a NEW bean, that being if we have an exception with
commit TX.
fucked up.
I feel that I am one call away from the real bug now (the new bean being
taken out of the cache and all) but right now I am too drunk and I am
cooking steak, yeah big N.Y Steak with a good $9.99 California wine...
You gota do what you gotta do man...
m
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury
> Sent: Friday, July 07, 2000 8:09 PM
> To: jBoss Developer
> Subject: RE: [jBoss-Dev] Nasty one
>
>
> Yeah that is the one... only I have dug deeper and I have traces every
> where.
>
> I you look closely at the message before that dump and you will see a
> strange "EntityBean.setEntityContext" message... that really
> caught my eye.
>
> If you explode that (by doing a new Exception().printStackTrace() in the
> test code of setEntityCOntext()" you realize that the commit is called.
> That is described in bugzilla.
>
> That behaviour is kinda strange, on an exception the commit goes on with a
> bean activation and entitycontext and all that which is not right since
> there was an exception...
>
> that's the first bug.
>
> Once I fix that then I can move on to the root of the exception
> in the call
> in the first place which is entityContext.getEJBObject = null
>
> dum da da
>
> marc
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Mulder
> > Sent: Friday, July 07, 2000 6:56 PM
> > To: jBoss Developer
> > Subject: Re: [jBoss-Dev] Nasty one
> >
> >
> > Hmm... I guess I'm not sure I'm seeing the same thing. When I
> > run the test client, it bombs out and the server shows the following:
> >
> > java.rmi.RemoteException
> > at
> > org.jboss.zol.testbean.bean.EnterpriseEntityBean.createEntity(Ente
> > rpriseEntityBean.java:78)
> > at java.lang.reflect.Method.invoke(Native Method )
> > at
> > org.jboss.ejb.EntityContainer$ContainerInterceptor.invoke(EntityCo
> > ntainer.java:549)
> > at
> > org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(Enti
> > tySynchronizationInterceptor.java:189)
> > at
> > org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInsta
> > nceInterceptor.java:100)
> > at
> >
> org.jboss.ejb.plugins.TxInterceptor$RunInvoke.run(TxInterceptor.java:342)
> > at
> > org.jboss.ejb.plugins.TxInterceptor.runWithTransactions(TxIntercep
> > tor.java:173)
> > at org.jboss.ejb.plugins.TxInterceptor.invoke(TxInterceptor.java:98)
> >
> > If I look at TxInterceptor.java line 173, it calls rollback if
> > the transaction was new (does nothing otherwise) and then rethrows the
> > exception. So what were you seeing again? You said something about a
> > commit followed by other strange things?
> > Are we looking at a failure in the same place? On the client side
> > it's right after "Calling method createEntity on enterpriseEntity..."
> >
> > Thanks,
> > Aaron
> >
> >
> >
>
>
>
