aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Ellis <RICEL...@uk.ibm.com>
Subject Re: Yet another proxy/weaving problem
Date Tue, 07 Jun 2011 09:05:47 GMT
I think the decision about whether it is logically correct to mark the 
WovenProxy interface as synthetic is down to semantics. The WovenProxy 
class is not dynamically generated, so it is in essence, not synthetic. 
However, as you rightly point out only the weaving code calls the 
interface and since the interface is added to classes dynamically then I 
think we are in agreement that it would be better marked as synthetic in 
this case. I was trying to work out if you had a proposal for how to 
actually get it marked as synthetic, but it seems you don't, in which case 
my proposal for adding the flag via a plugin during process-classes is the 
only option on the table at the moment. Tim and I will work to get 
something in under Aries-669 to do this.

To answer your question "Can this feature be written so that it doesn't 
need to add an interface to every class?":
The motivation for adding the interface was to reduce the need for 
reflective calls in the proxy code, which helped towards improving the 
proxy performance by about 400% under some circumstances. Given this 
improvement I would suggest that we try to be as accommodating as possible 
of the interface. So if you mean is there a way to get the same 
performance we have achieved without using an interface at all, then the 
answer is maybe, but I haven't thought of a way to do it. If you have any 
suggestions...

To answer your other question "I also don't really understand the purpose 
of the introduced static_init* method, does it need to be called from 
subclasses, why can't you add the new bytecode to an existing <clinit> 
method?"
There was an existing StaticInitMerger class in the ASM library, so we 
used that out of convenience rather than adding the code to the existing 
<clinit>. Adding code to the existing <clinit> was harder because we had 
to add information that couldn't be written until after we have visited 
all the methods in the class (including the <clinit>) so we couldn't weave 
the <clinit> whenever we encountered it because we might not yet have all 
the required information. Using the ASM utility essentially renamed 
multiple <clinit> methods found in the code to static_init_* methods and 
then called them all from a single <clinit>. Obviously at the time we were 
not aware that this would have side effects in certain places such as 
those you encountered. The design I proposed in the comment on Aries-669 
should resolve the problem by allowing us to mark a single generated 
static_init_UUID method as synthetic and putting a single call to that 
method in an existing <clinit> if we find one. If there isn't an existing 
<clinit> then we will simply create one marked synthetic. As Tim mentioned 
in his comment on Aries-669 we will try to implement a solution avoiding 
any ASM source.

Rich




From:
David Jencks <david_jencks@yahoo.com>
To:
dev@aries.apache.org
Date:
06/06/2011 21:57
Subject:
Re: Yet another proxy/weaving problem




On Jun 6, 2011, at 5:30 AM, Richard Ellis wrote:

> David,
> 
> I don't think it is easy to mark the WovenProxy class as synthetic 
because 
> it is a real interface with source in the org.apache.aries.proxy.weaving 

> package. AFAIK there is no way to mark an interface as synthetic only on 

> the implementing class, but not on the interface class itself. It is 
> probably possible for us to write a plugin that operates during the 
> process-classes phase which will add the synthetic marker to the 
> WovenProxy interface class after compilation. Is this what you had in 
> mind?

I kinda figured that since you can change all the other bytecode in 
unknown user supplied classes you might be able to think of a way to get 
this flag into this known class you wrote.  I was more wondering if it was 
logically correct to mark it synthetic.  I thought it probably was since 
according to the extensive documentation of how this stuff works you have 
so kindly supplied.... um my random guess based on trying to understand 
the code is that only weaving generated code ever calls this interface.

I'd still like an explicit answer to my original question,
**************************************************
Can this feature be written so that it doesn't need to add an interface to 
every class?
**************************************************

I also don't really understand the purpose of the introduced static_init* 
method, does it need to be called from subclasses, why can't you add the 
new bytecode to an existing <clinit> method?

thanks
david jencks


> 
> Thanks,
> Rich
> 
> 
> 
> From:
> David Jencks <david_jencks@yahoo.com>
> To:
> dev@aries.apache.org
> Cc:
> dev@openwebbeans.apache.org, "Geronimo Dev List \(JIRA\)" 
> <dev@geronimo.apache.org>
> Date:
> 04/06/2011 17:03
> Subject:
> Re: Yet another proxy/weaving problem
> 
> 
> 
> I've now found another place where the added WovenProxy interface breaks 

> OpenWebBeans.   The lack of response on the aries list to my first post 
> makes me think that perhaps this interface can't be removed.  I notice 
> that there's an isSynthetic() method on Class.  I'm not sure what this 
> means but I'm wondering if it would be possible to mark this interface 
> synthetic and have the relevant parts of OWB ignore synthetic interfaces 

> rather than explicitly configuring it to ignore this particular 
interface?
> 
> thanks
> david jencks
> 
> On Jun 2, 2011, at 11:53 PM, David Jencks wrote:
> 
>> another day another problem....
>> 
>> org.apache.webbeans.exception.WebBeansConfigurationException: Decorator 

> : Name:null, WebBeans Type:DECORATOR, API 
> 
Types:[org.jboss.jsr299.tck.tests.context.dependent.InteriorDecorator,org.apache.aries.proxy.weaving.WovenProxy,org.jboss.jsr299.tck.tests.context.dependent.Interior,java.lang.Object],


> Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default] 

> delegate attribute must implement all of the decorator decorated types, 
> but decorator type interface org.apache.aries.proxy.weaving.WovenProxy 
is 
> not assignable from delegate type of interface 
> org.jboss.jsr299.tck.tests.context.dependent.Interior
>> 
>> 
>> I believe the story here is that decorator classes must not implement 
> interfaces that the delegate doesn't implement, but aries is adding the 
> org.apache.aries.proxy.weaving.WovenProxy to the decorator class.
>> 
>> OWB is already excluding Serializable and I can modify the code to also 

> exclude org.apache.aries.proxy.weaving.WovenProxy and the jcdi tests 
pass 
> but this is going to involve making the list of ignored interfaces 
> configurable and may not be acceptable to OWB.
>> 
>> Is there any way to make the weaving/proxying code not add this 
> interface?  I don't think the jdk proxying code needs to add 
> interfaces....
>> 
>> thanks
>> david jencks
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 

> 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
> 
> 
> 
> 
> 









Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message