Good points. Just proposing a possibility.
Dave Wolf
Internet Applications Division
Sybase
----- Original Message -----
From: "Harsh" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, November 01, 2000 1:33 PM
Subject: Re: CMP EJB Debugging using J2EE RI 1.2.1
> 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".
>
>
===========================================================================
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".
