And we sincerely appreciate everyone's input. Honestly, thanks loads, folks.
Another thing is this, that's really confusing me......
We have a crude logging mechanism that outputs to standard error. Part of
the output we generate
lists the class name via the getClass().getName() invocation sequence. When
we look at the output,
this line prints the name of the class in whose .class file we have
indicated to the debugger
we want to break. Very confusing to someone as simple as myself! If this was
a subclassing
issue, wouldn't we expect to see the class name of the derived CMP class?
Strangely, we see our
"breakpoint" class. We've managed to see some things about the execution of
our CMP beans using
this that has helped us with our bug (thankfully), but we're still confused
about the lack of the break-point
hits.....
In an earilier response, I ponder about the propagation of transactions, so
if you're so inclined look there.
Perhaps, the sympathetic breakpoint model is messed up by some subtle JTS
transaction issue? (Wild guess)
-----Original Message-----
From: Dave Wolf [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 01, 2000 11:18 AM
To: [EMAIL PROTECTED]
Subject: Re: CMP EJB Debugging using J2EE RI 1.2.1
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".
===========================================================================
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".
