You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Donald <pe...@realityforge.org> on 2003/03/18 10:22:14 UTC
Fwd: AW: [Newbie] Proxy objects in Fortress - why?
Hi,
Could someone look at this and apply the changes?
---------- Forwarded Message ----------
Subject: AW: [Newbie] Proxy objects in Fortress - why?
Date: Thu, 6 Mar 2003 16:10:01 +0100
From: "Olaf Bergner" <ol...@gmx.de>
To: "Avalon framework users" <us...@avalon.apache.org>
Hi Peter,
Peter Donald wrote:
> On Wed, 5 Mar 2003 00:50, Olaf Bergner wrote:
> > to create an instance of the component wrapper. A preliminary
>
> inspection of
>
> > the javadocs seems to indicate that this might work even in jdk1.2.
> >
> > Anyways, if you want to see it, you can have it. Just give me a note.
>
> I would like to see it integrated (or at least an option) in
> fortress/ecm. SO
> send along some diffs.
>
> --
> Cheers,
>
> Peter Donald
Attached you will find three diffs, one unified, one context, one standard,
as created by Eclipse, all rolled up into one single zip. I have never made
any diffs before, so I chose to use all three different formats Eclipse has
to offer. Hopefully, one of 'em will do the job. The diffs are to be applied
against the org.apache.avalon.fortress.impl.handler package.
Some notes:
1) In order to implement dispose() of
org.apache.excalibur.mpool.ObjectFactory there's got to be a way of asking
the generated wrapper class for the wrapped class. I have been reluctant to
implement the equivalent of Object getWrappedObject() since this would offer
clients a way of bypassing the wrapper class' purpose. Anyways, if you
should find the code useful I would offer to add such a method.
2) No effort was made to make WrapperObjectFactory threadsafe. I am no
expert in concurrent programming, and I am not sure if an implementation of
ObjectFactory is supposed to operate in a multithreaded environment.
3) The HandlersTestCase will fail, since none of the work interfaces Role1,
Role2, ... implements the method getID() this test case calls. This works
for the ProxyObjectFactory due to its usage of the
PassThroughInvocationHandler. Add those methods and the test case passes.
IMHO, this constitutes a minor bug, er ... shortcoming in the test suite but
you will have to decide for yourself.
4) I added 5 classes: WrapperObjectFactory, WrapperGenerator,
BCELWrapperGenerator, BCELCodeGenerator and ProxyUtility. The latter factors
out some methods from ProxyHelper which I decided to leave untouched, so
this is a severe case of code duplication ;).
5) In order to see the new code at work you will have to replace new
ProxyObjectFactory(...) in AbstractContainer.createObjectFactory(...) with
new WrapperObjectFactory(...), but whom do I tell this ...
Please let me know if you should have any issues with the code that might
need attention. I will try to fix it as soon as I find some spare time (I am
in the final months of my diploma in mathematics, so right now I am more
concerned with group theory, topology, ... than with BCEL byte code manglers
;)).
Oh, yes, regarding the code: You may tweak, rewrite, refactor it, port it to
VB ..., er, no, wait! Don't do that! If you want to have it, it's yours.
Cheers,
Olaf Bergner
-------------------------------------------------------
--
Cheers,
Peter Donald
*--------------------------------*
| Every rule has an exception, |
| except the rule of exceptions. |
*--------------------------------*
Re: Fwd: AW: [Newbie] Proxy objects in Fortress - why?
Posted by Chris Nokleberg <ch...@sixlegs.com>.
Berin Loritsch wrote:
> Peter Donald wrote:
>
>> Hi,
>>
>> Could someone look at this and apply the changes?
>
> All the BCEL stuff looks complex to say the least,
> but code wise it seems ok.
Just thought I should pop in to say that if you end up using CGLIB for
anything, there is probably an easier way to make wrapper objects.
The Delegator class is normally used to combine multiple objects
(interface implementation or beans) into a single object. The generated
methods are just stubs that call the underlying objects. But if you have
only one object, the resulting generated class acts just like a wrapper.
This is the API method you'd want to use:
Delegator.create(Class[] interfaces, Object[] delegates,
ClassLoader loader)
See:
http://cglib.sourceforge.net/apidocs/net/sf/cglib/Delegator.html
Note that this is totally different from the MethodDelegate class, which
is based on the Avalon delegate stuff. The names are a bit unfortunate
but Delegator was written first.
-Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Fwd: AW: [Newbie] Proxy objects in Fortress - why?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote, On 18/03/2003 21.42:
> On Wed, 19 Mar 2003 05:33, Berin Loritsch wrote:
>
>>Peter Donald wrote:
...
>>Do we want to have a compile/runtime dependency on
>>BCEL if for our users' purpose the Dynamic Proxy
>>version is OK?
>
> Use DynamicProxy where possible otherwise when we want to support JDK1.2 (like
> say for Cocoon) we use BCEL.
BTW, IIUC Cocoon will now rely on 1.3.
We did a poll on our lists and basically nobody uses 1.2 anymore.
Just a note; the above suggestion is just right.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Fwd: AW: [Newbie] Proxy objects in Fortress - why?
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> Use DynamicProxy where possible otherwise when we want to support JDK1.2 (like
> say for Cocoon) we use BCEL.
FYI, Cocoon decided to move from 1.2+ to 1.3+ for the upcoming 2.1
release. This was done also to simplify moving to more modern Avalon
containers without imposing too much problems here.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Fwd: AW: [Newbie] Proxy objects in Fortress - why?
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> Use DynamicProxy where possible otherwise when we want to support JDK1.2 (like
> say for Cocoon) we use BCEL.
FYI, Cocoon decided to move from 1.2+ to 1.3+ for the upcoming 2.1
release. This was done also to simplify moving to more modern Avalon
containers without imposing too much problems here.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Fwd: AW: [Newbie] Proxy objects in Fortress - why?
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 19 Mar 2003 05:33, Berin Loritsch wrote:
> Peter Donald wrote:
> > Hi,
> >
> > Could someone look at this and apply the changes?
>
> All the BCEL stuff looks complex to say the least,
> but code wise it seems ok.
>
> Do we want to have a compile/runtime dependency on
> BCEL if for our users' purpose the Dynamic Proxy
> version is OK?
Use DynamicProxy where possible otherwise when we want to support JDK1.2 (like
say for Cocoon) we use BCEL.
> Hmm. We need to perform some runtime resolution
> to see if the BCEL jar is available, and if the
> user requests it.
yep.
> Disposing components is pretty important--esp.
> if they save state when they are disposed. Could we
> provide that mechanism via a protected or package accessible
> method? WOuld that be sufficient?
package access.
--
Cheers,
Peter Donald
*----------------------------------------------------------*
The phrase "computer literate user" really means the person
has been hurt so many times that the scar tissue is thick
enough so he no longer feels the pain.
-- Alan Cooper, The Inmates are Running the Asylum
*----------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Fwd: AW: [Newbie] Proxy objects in Fortress - why?
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> Hi,
>
> Could someone look at this and apply the changes?
All the BCEL stuff looks complex to say the least,
but code wise it seems ok.
Do we want to have a compile/runtime dependency on
BCEL if for our users' purpose the Dynamic Proxy
version is OK?
Hmm. We need to perform some runtime resolution
to see if the BCEL jar is available, and if the
user requests it.
Disposing components is pretty important--esp.
if they save state when they are disposed. Could we
provide that mechanism via a protected or package accessible
method? WOuld that be sufficient?
Any other questions/answers?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org