Dave:
This might not be entire true. The subclass *has* to be loaded per
classloader resolution mechanisms. You're right however that breakpoints
settings might not quite work as easily (unless the container provider
has chosen to delegate messages as opposed to subclassing the provider
bean class) 'cause the container provided bean subclass inherits the
same method table as the provider (super) class.
I'm surprised however, I don't this for sure and don't mean to offend
any container providers here, that the container generated class name is
not advertised/made public/documented for debugging purposes.
-harsh-
GemStone Systems
"If a dog will not come to you after having looked you in the face,
you should go home and examine your conscience" -- Woodrow Wilson
> Richard.
>
> One method that some CMP implementations use is to subclass the CMP bean
> with a code gernated BMP bean. That BMP bean will then super() to its
> parent as part of the work it does. For instance, imagin you write an
> entity bean called
>
> CMPEntity
>
> Which is implemented in
>
> foo.bar.CMPEntityBean.class
>
> When you deploy, you mape CMP fields to O:R maps. The container would then
> on its own generate a totall new class, possible called say
>
> CMPEntity_Generated
>
> That class would then extend yours, so
>
> public class foo.bar.CMPEntity_Generated extends foo.bat.CMPEntityBean
>
> At runtime, your class CMPENtity is never ever called. The container
> instead would call CMPEntity_Generated. Every method call in that class as
> part of its work will super up the your class.
>
> For this reason if you set a debugger up to debug foo.bar.CMPEntityBean in
> its ejbLoad() method, you never hit the break point. As your class is never
> ever loaded. Instead the subclass is loaded. Yes, you see your logging
> outputs as the subclass supers to its parent, causing your messages to
> print. But your class is never ever loaded.
>
> This may be why you are unsable to debug a CMP bean, and the bean class
> itself is never used, except as a super class in an inheritence system.
>
> You can indeed do work in ejbLoad() and ejbStore() such as encyrpting or
> decrypting a field, and that work will indeed occur due to the super()
> calls.
>
> Does that make more sense?
>
> Dave Wolf
> Internet Applications Division
>
> ----- Original Message -----
> From: "Richard Landon" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, October 31, 2000 7:33 PM
> Subject: Re: CMP EJB Debugging using J2EE RI 1.2.1
>
> > I have given this some further thought. Suppose for example I have a CMP
> > bean that I encrypt before
> > writing it to the DBMS. Does this response imply that I can not actually
> use
> > the ejbStore() and ejbLoad()
> > mechanisms for CMP Entity EJB? From my understanding of the J2EE
> > specifications, this would make little
> > sense (but I could not understand the specification).
> >
> > At any rate, I know my CMP entity container is in fact calling my methods,
> > as I have special code in there
> > and I see the output of these codes, nonethless, the debug breakpoint is
> not
> > being reached.
> >
> > -----Original Message-----
> > From: Dave Wolf [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, October 30, 2000 7:55 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: CMP EJB Debugging using J2EE RI 1.2.1
> >
> >
> > Richard,
> >
> > How do you know what class to set the stop in? Since many CMP
> > implementations work by subclassing your CMP bean with a code generated
> BMP
> > bean, how do you know the class name of the BMP bean the CMP layer
> created?
> > Since the BMP subclasses your CMP you will stiull see your debug
> statements,
> > although the subclass generated them from a call to super.*
> >
> > I doubt this is possible to do in many cases.
> >
> > Dave Wolf
> > Internet Applications Division
> > Sybase
> >
> > ----- Original Message -----
> > From: "Richard Landon" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, October 30, 2000 10:13 PM
> > Subject: Re: CMP EJB Debugging using J2EE RI 1.2.1
> >
> >
> > > -----Original Message-----
> > > From: Richard Landon
> > > Sent: Monday, October 30, 2000 7:06 PM
> > > To: 'A mailing list for Enterprise JavaBeans development'
> > > Cc: '[EMAIL PROTECTED]'
> > > Subject: CMP EJB Debugging using J2EE RI 1.2.1
> > >
> > >
> > > I am trying to debug a CMP Entity EJB using the J2EE RI 1.2.1 under NT.
> > > I have managed to be able to debug SESSION (stateless or stateful) EJB
> > > within the
> > > J2EE 1.2.1 RI using the JPDA interfaces and a suitable debugger.
> However,
> > > when I set a break-point in any CMP Entity EJB code (including
> > > setInitialContent!)
> > > the breakpoint is never hit!? I switched from a UI Debugger to jdb, and
> > the
> > > same thing.
> > > I inserted some "trace statements" so I know for a fact the code is
> > > executing, but the
> > > debugger will not break.
> > >
> > > This is most annoying, any suggestions?
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
