The other day, I was thinking of doing the same thing for the purposes of
"injecting" my own code before and after each method call. I wanted to
allow this functionality at any API call, so I did not want to make explicit
modification to all of my beans. However, I was not able to achieve this
due to the fact that the container interspects the .class file for proper
method. A proxy would not have a class file to examine, so the container
would fail to deploy the bean.
I recon you can modify ANT to create such a proxy automatically for you,
however, it would take a place of a .java file and be more like a statically
generated file.
If you ever solve your problem dynamically, tell me.
-AP_
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Kenji Konaka
Sent: Monday, July 30, 2001 12:23 PM
To: [EMAIL PROTECTED]
Subject: Re: Proxy based Bean implementation ?
Thanks Gene,
> You can do it if you manually proxy your bean class to your dynamic
proxy,
> but you cannot just supply an interface and simply tell the container to
use
> the dynamic proxy as the bean class at runtime. This is a limitation of
> declarative typing of the EJB specs.
okay, so it cannot be done,... -- one of the wild guess I actually
have had was it might be possible to specify the name of the
Factory-class in place of the actual class name in place of
<ejb-class>...</ejb-class> tag. and somehow(?) tell the container
that it is for the name of the Factory-class... (<= maybe it was a
silly idea/imagination anyway :p)
one of the other way I was thinking is to replace (or sit in front of)
the original ClassLoader used for Beans class loading, and do the
proxy class generation within this custom classloader, if the
classname requested appears to be "MyBeanProxy" ... but then this was
rejected too early on, partly because it can possibly be container
specific...
> thought of this idea before and wished I could do the same thing... no
> more bean class writing! However, CMP 2.0 is slowly converging towards
> this: in 2.0, you provide an abstract class where all getters and
setters
> are also abstract. This is ALMOST as bare-bone as an interface!
hmm., maybe close - but does not apply exactly to my case...
thank you very much :)
kenji
===========================================================================
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".
