aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Another weaving problem?
Date Thu, 02 Jun 2011 22:34:39 GMT
Hi Tim,

First I fixed this in OWB by having their proxyability-checking code ignore synthetic methods.
 This works and AFAICT the actual proxy building code seems to work ok.  However a couple
of OWB committers have objected to this and one of them has told me that starting in java
1.5 marking methods final has no effect on whether the JIT can optimize better.  I'm a little
nervous about this change also since the synthetic flag is not exposed by the java reflection
code.

So when I get a minute I'm going to try removing the final modifier from the generated synthetic
methods and restore the OWB code.  If you have any concerns please speak up :-)

thanks!
david jencks

On Jun 1, 2011, at 1:28 AM, Timothy Ward wrote:

> 
> Hi David,
> 
> The proxying code does indeed add a couple of final methods on the highest woven supertype
of a class hierarchy. The equivalent source for these would be the following:
> 
> --------------------------------------------------------
> 
> public final Callable<Object> org_apache_aries_proxy_weaving_WovenProxy_unwrap()
{
>   return dispatcherField;
> }
> 
> 
> 
> public final boolean org_apache_aries_proxy_weaving_WovenProxy_isProxyInstance() {
> 
>   return dispatcherField != null && listenerField != null;
> 
> }
> 
> --------------------------------------------------------
> 
> dispatcherField and listenerField are protected final member variables with long, auto-generated
field names that should never clash with anything already in the class.
> 
> Both of these methods are marked synthetic in the bytecode, which I would have hoped
meant that they would be safely ignored. The primary reason for making the methods final is
to ensure the JIT can optimize effectively, so if you'd like to try changing line 67 of AbstractWovenProxyAdapter
to remove the ACC_FINAL part of the bitmask then that will stop the methods from being final.
This should have no functional effect on the proxy code, just a potential, minor performance
impact.
> 
> It's a shame that the webbeans implementation can't use the existing proxying, but I
suppose that's not possible...
> 
> 
> 
> For completeness, weaving also adds the following code to every class that it weaves
(not just the highest supertype):
> 
> --------------------------------------------------------
> 
> protected Constructor(Callable<Object> dispatcher, InvocationListener listener)
{
>   //either this for the sub-types  
>   super(dispatcher, listener); 
> 
>   //or this for the highest woven supertype
>   super(); // sometimes this(); if there is no no-args super
>   dispatcherField = dispatcher; 
>   listenerField = listener;
> 
> }
> 
> public WovenProxy org_apache_aries_proxy_weaving_WovenProxy_createNewProxyInstance(Callable<Object>
dispatcher, InvocationListener listener) {
>   return new ThisClass(dispatcher, listener);
> }
> 
> --------------------------------------------------------
> 
> 
> Regards,
> 
> Tim
> 
> 
> ----------------------------------------
>> From: david_jencks@yahoo.com
>> Subject: Another weaving problem?
>> Date: Tue, 31 May 2011 17:05:04 -0700
>> To: dev@aries.apache.org
>> 
>> Thanks tim for fixing the SerialVersionUID problem. I think I'm running into another
problem with the weaving since this doesn't show up with plain geronimo + owb. Most of the
jcdi tck fails with deployment errors like this:
>> 
>> 2011-05-31 16:02:27,902 ERROR [WebBeansConfigurationListener] An error occured while
starting application context path : [/org.jboss.jsr299.tck.tests.context.ContextTest]
>> 2011-05-31 16:02:27,903 ERROR [ContextTest]] Exception sending context initialized
event to listener instance of class org.apache.geronimo.openwebbeans.WebBeansConfigurationListener
>> javax.enterprise.inject.UnproxyableResolutionException: WebBeans with api type with
normal scope must be proxiable to inject.
>> org.jboss.jsr299.tck.tests.context.MySessionBean has final methods! CDI doesn't allow
that.
>> at org.apache.webbeans.util.InjectionExceptionUtils.throwUnproxyableResolutionException(InjectionExceptionUtils.java:39)
>> at org.apache.webbeans.util.WebBeansUtil.checkUnproxiableApiType(WebBeansUtil.java:1852)
>> at org.apache.webbeans.component.creation.ManagedBeanCreatorImpl.checkCreateConditions(ManagedBeanCreatorImpl.java:70)
>> at org.apache.webbeans.util.WebBeansUtil.defineManagedBean(WebBeansUtil.java:2598)
>> at org.apache.webbeans.config.BeansDeployer.defineManagedBean(BeansDeployer.java:859)
>> at org.apache.webbeans.config.BeansDeployer.deploySingleAnnotatedType(BeansDeployer.java:539)
>> at org.apache.webbeans.config.BeansDeployer.deployFromClassPath(BeansDeployer.java:484)
>> at org.apache.webbeans.config.BeansDeployer.deploy(BeansDeployer.java:165)
>> at org.apache.webbeans.lifecycle.AbstractLifeCycle.startApplication(AbstractLifeCycle.java:129)
>> at org.apache.webbeans.web.lifecycle.WebContainerLifecycle.startApplication(WebContainerLifecycle.java:87)
>> at org.apache.geronimo.openwebbeans.WebBeansConfigurationListener.contextInitialized(WebBeansConfigurationListener.java:85)
>> at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4521)
>> at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5004)
>> at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:4999)
>> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>> at java.lang.Thread.run(Thread.java:680)
>> 
>> I don't see any final methods in MySessionBean:
>> 
>> @SessionScoped
>> class MySessionBean implements Serializable
>> {
>> private static final long serialVersionUID = 1L;
>> 
>> private int id = 0;
>> 
>> public void setId(int id)
>> {
>> this.id = id;
>> }
>> 
>> public int getId()
>> {
>> return id;
>> }
>> 
>> public void ping()
>> {
>> }
>> 
>> }
>> 
>> so I'm guessing the weaving might have added something??
>> 
>> Is there a description of what the weaving does in terms of java code? Or even a
description of what it does in java op codes?
>> 
>> thanks
>> david jencks
>> 
> 		 	   		  


Mime
View raw message