Mailing-List: contact dev-help@aries.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aries.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer;
  b=cEDCGyDHxhBTRyxPFJ9lfYGxu4ygbE+PeSRphlUEtrJ0nWCtn2B/NoBlT4C6c7DUd1CDugFhsHnSX38zyKIpQS9xlWa+C9oghbRRcXWcfCPe/J4PIoxXy4xD0eCGf/tP/WPGQ2xcRt2cqz0xwGcSkAUQ1orIm179CtgjlsoQBeM=
  ;
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Another weaving problem?
From: David Jencks <david_jencks@yahoo.com>
In-Reply-To: <BLU128-W1064DD8B9734F0D5D64CD4DF7D0@phx.gbl>
Date: Thu, 2 Jun 2011 15:34:39 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <3063CDA8-9025-4B04-9B21-997FA26F5EAC@yahoo.com>
References: <9820D92C-5208-4DC3-892F-D0516CE61432@yahoo.com>
 <BLU128-W1064DD8B9734F0D5D64CD4DF7D0@phx.gbl>
To: dev@aries.apache.org

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:

>=20
> Hi David,
>=20
> 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:
>=20
> --------------------------------------------------------
>=20
> public final Callable<Object> =
org_apache_aries_proxy_weaving_WovenProxy_unwrap() {
>   return dispatcherField;
> }
>=20
>=20
>=20
> public final boolean =
org_apache_aries_proxy_weaving_WovenProxy_isProxyInstance() {
>=20
>   return dispatcherField !=3D null && listenerField !=3D null;
>=20
> }
>=20
> --------------------------------------------------------
>=20
> dispatcherField and listenerField are protected final member variables =
with long, auto-generated field names that should never clash with =
anything already in the class.
>=20
> 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.
>=20
> It's a shame that the webbeans implementation can't use the existing =
proxying, but I suppose that's not possible...
>=20
>=20
>=20
> For completeness, weaving also adds the following code to every class =
that it weaves (not just the highest supertype):
>=20
> --------------------------------------------------------
>=20
> protected Constructor(Callable<Object> dispatcher, InvocationListener =
listener) {
>   //either this for the sub-types =20
>   super(dispatcher, listener);=20
>=20
>   //or this for the highest woven supertype
>   super(); // sometimes this(); if there is no no-args super
>   dispatcherField =3D dispatcher;=20
>   listenerField =3D listener;
>=20
> }
>=20
> public WovenProxy =
org_apache_aries_proxy_weaving_WovenProxy_createNewProxyInstance(Callable<=
Object> dispatcher, InvocationListener listener) {
>   return new ThisClass(dispatcher, listener);
> }
>=20
> --------------------------------------------------------
>=20
>=20
> Regards,
>=20
> Tim
>=20
>=20
> ----------------------------------------
>> From: david_jencks@yahoo.com
>> Subject: Another weaving problem?
>> Date: Tue, 31 May 2011 17:05:04 -0700
>> To: dev@aries.apache.org
>>=20
>> 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:
>>=20
>> 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.throwUnproxyableResolutio=
nException(InjectionExceptionUtils.java:39)
>> at =
org.apache.webbeans.util.WebBeansUtil.checkUnproxiableApiType(WebBeansUtil=
.java:1852)
>> at =
org.apache.webbeans.component.creation.ManagedBeanCreatorImpl.checkCreateC=
onditions(ManagedBeanCreatorImpl.java:70)
>> at =
org.apache.webbeans.util.WebBeansUtil.defineManagedBean(WebBeansUtil.java:=
2598)
>> at =
org.apache.webbeans.config.BeansDeployer.defineManagedBean(BeansDeployer.j=
ava:859)
>> at =
org.apache.webbeans.config.BeansDeployer.deploySingleAnnotatedType(BeansDe=
ployer.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(AbstractL=
ifeCycle.java:129)
>> at =
org.apache.webbeans.web.lifecycle.WebContainerLifecycle.startApplication(W=
ebContainerLifecycle.java:87)
>> at =
org.apache.geronimo.openwebbeans.WebBeansConfigurationListener.contextInit=
ialized(WebBeansConfigurationListener.java:85)
>> at =
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.jav=
a: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)
>>=20
>> I don't see any final methods in MySessionBean:
>>=20
>> @SessionScoped
>> class MySessionBean implements Serializable
>> {
>> private static final long serialVersionUID =3D 1L;
>>=20
>> private int id =3D 0;
>>=20
>> public void setId(int id)
>> {
>> this.id =3D id;
>> }
>>=20
>> public int getId()
>> {
>> return id;
>> }
>>=20
>> public void ping()
>> {
>> }
>>=20
>> }
>>=20
>> so I'm guessing the weaving might have added something??
>>=20
>> 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?
>>=20
>> thanks
>> david jencks
>>=20
> 		 	   		 =20