PojoCache implementation class AOP instrumentation depends o

[ben.wang]

This was discussed in jbosscache-dev mailing list but I have moved it here.

In 2.0, PojoCache has used JBoss AOP framework to obtain interceptor based architecture. As a result, it will need to do byte code weaving for some implementation classes (currently there is only one class). However, this poses a problem since the weaved code is version dependent on JBoss AOP. That is, code weaved in 1.5 can't be run in 2.0.

So now AS5.0 will use 2.0 while 4.2 will stay in 1.5. What is our option?

[ben.wang]

This is the email trails:

---------

I spoke to Dimitris yesterday about this and we will stay with JBoss AOP 1.5.x for AS 4.2.x.

We haven't made any guarantees about the woven code being the same between different aop versions, and although I can see that this would be "nice", the woven code is actually being changed frequently to do optimizations, fix bugs etc. Also, JBoss AOP 2 is still in alpha stage, so there may well be more internal changes, especially when we come to optimizing performance. In other words, I'm not sure if it will be practical to lock down the internal weaving of classes as a (semi-)public API? How many classes do you weave by the way?

Since you are using compile-time weaving, I think the best solution atm would be to have some sort of install script for JBoss that takes the unwoven POJOCache, and weaves that against the target jboss aop version in jboss and deploys that in jboss.


> -----Original Message-----
> From: Ben Wang [mailto:[e-mail]]
> Sent: 16 November 2006 14:22
> To: Kabir Khan
> Cc: [e-mail]
> Subject: RE: Problem with the instrumentation of PojoCacheImpl
>
> Hmmn... This is a problem for me because I use compile time weaving
> for my own PojoCache code. So that means I need to create two distros
> for different version of JBoss Aop.
>
> Will jboss-4.2 also uses AOP2.0? If it is, maybe I will upgrade to
> 2.0. I can propbably claim that JBC release 2.0 won't work with 4.0.x
> anyway since the API incompatability.
>
> -Ben
>
> -----Original Message-----
> From: Kabir Khan
> Sent: Thursday, November 16, 2006 7:01 PM
> To: Ben Wang
> Subject: RE: Problem with the instrumentation of PojoCacheImpl
>
> JBoss A/S will use AOP 2.0.0.alpha2. How the classes are being woven
> does change between AOP versions, so if compile-time weaving is being
> used, it must be run against the same version of AOP.
>
> So, for jboss cache standalone and for jboss 4.0.x I would go with
> JBoss AOP 1.5.x, but in head it needs to be 2.0.0.alpha.
> I think you will probably need to create an install script for JBC
> that compile-time weaves the JBC classes against the target AOP
> version.
>
> > -----Original Message-----
> > From: Ben Wang [mailto:[e-mail]]
> > Sent: 16 November 2006 07:24
> > To: Kabir Khan
> > Subject: FW: Problem with the instrumentation of PojoCacheImpl
> >
> > Kabir,
> >
> > JBC is currently on 1.5 while JBoss AS is 2.0 snapshot for
> JBoss Aop.
> > This error seems to be saying 2.0 is not backward
> comptabile with 1.5?
> > If it is, which version should we upgrade to in JBC?
> >
> > Thanks,
> >
> > -Ben
> >
> > -----Original Message-----
> > From: Brian Stansberry
> > Sent: Thursday, November 16, 2006 3:04 PM
> > To: Ben Wang
> > Cc: jbosscache-dev
> > Subject: Problem with the instrumentation of PojoCacheImpl
> >
> > Getting the following when running FIELD repl tests.
> >
> > There was a mismatch between the jboss-aop-jdk50.jar in JBC
> /lib and
> > in AS HEAD. I copied the AS version over to JBC and cleaned and
> > rebuilt JBC, but still had the same problem.
> >
> > 2006-11-16 00:13:19,500 ERROR
> > [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost
> > ].[/http-s
> > coped-field].[jsp]] Servlet.service() for servlet jsp threw
> exception
> > java.lang.NoSuchMethodError:
> >
> org.jboss.aop.instrument.JoinPointGenerator.generateJoinPointClass()V
> > at
> > org.jboss.cache.pojo.impl.PojoCacheImpl$PojoCacheImplAdvisor.a
> ttach30850
> > 19539260813833(PojoCacheImpl$PojoCacheImplAdvisor.java)
> > at
> > org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java)
> > at
> >
> org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:109)
> > at
> > org.jboss.web.tomcat.tc6.session.JBossCacheService.setPojo(JBo
> > ssCacheSer
> > vice.java:581)
> > at
> > org.jboss.web.tomcat.tc6.session.FieldBasedClusteredSession.se
> > tJBossInte
> > rnalAttribute(FieldBasedClusteredSession.java:323)
> > at
> > org.jboss.web.tomcat.tc6.session.ClusteredSession.setInternalA
> > ttribute(C
> > lusteredSession.java:1432)
> > at
> > org.jboss.web.tomcat.tc6.session.ClusteredSession.setAttribute
> > (Clustered
> > Session.java:552)
> > at
> > org.apache.catalina.session.StandardSessionFacade.setAttribute
> > (StandardS
> > essionFacade.java:130)
> > at
> > org.apache.jsp.setSession_jsp._jspService(setSession_jsp.java:63)
> > at
> > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> > at
> > org.apache.jasper.servlet.JspServletWrapper.service(JspServlet
> > Wrapper.ja
> > va:390)
> > at
> > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet
> > .java:320)
> > at
> > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilt
> > er(Applica
> > tionFilterChain.java:290)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli
> > cationFilt
> > erChain.java:206)
> > at
> > org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyH
> > eaderFilte
> > r.java:96)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilt
> > er(Applica
> > tionFilterChain.java:235)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli
> > cationFilt
> > erChain.java:206)
> > at
> > org.apache.catalina.core.StandardWrapperValve.invoke(StandardW
> > rapperValv
> > e.java:228)
> > at
> > org.apache.catalina.core.StandardContextValve.invoke(StandardC
> > ontextValv
> > e.java:175)
> > at
> > org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(
> > SecurityAs
> > sociationValve.java:174)
> > at
> > org.jboss.web.tomcat.tc6.session.ClusteredSessionValve.invoke(
> > ClusteredS
> > essionValve.java:89)
> > at
> > org.jboss.web.tomcat.tc6.session.BatchReplicationClusteredSess
> > ionValve.i
> > nvoke(BatchReplicationClusteredSessionValve.java:102)
> > at
> > org.apache.catalina.authenticator.AuthenticatorBase.invoke(Aut
> > henticator
> > Base.java:433)
> > at
> > org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccCont
> > extValve.j
> > ava:74)
> > at
> > org.apache.catalina.core.StandardHostValve.invoke(StandardHost
> > Valve.java
> > :128)
> > at
> > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReport
> > Valve.java
> > :105)
> > at
> > org.apache.catalina.core.StandardEngineValve.invoke(StandardEn
> > gineValve.
> > java:109)
> > at
> > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdap
> > ter.java:2
> > 12)
> > at
> > org.apache.coyote.http11.Http11Processor.process(Http11Process
> > or.java:81
> > 8)
> > at
> > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandle
> r.process(
> > Http11Protocol.java:624)
> > at
> > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.
> java:445)
> > at java.lang.Thread.run(Thread.java:595)
> >
> > Brian Stansberry
> > Lead, AS Clustering
> > JBoss, a division of Red Hat
> > Ph: 510-396-3864
> > skype: bstansberry

[kabirkhan]

install script for JBoss that takes the unwoven POJOCache

I mean install script for JBC

[ben.wang]

So what we need to do is during the copying of the JBC library from 3d party dir to build, we need to do an "aopc" on the jar.

But in this way, Kabir, I will need to unjar pojocache.jar first and then jar it again after instrumentation, is it correct?

One other issue is for future upgrade. User can not simply drop the jar from the JBC released version.

Now why can't JBoss Aop try to maintain some binary compatability between releases?

[kabirkhan]

So what we need to do is during the copying of the JBC library from 3d party dir to build, we need to do an "aopc" on the jar.

But in this way, Kabir, I will need to unjar pojocache.jar first and then jar it again after instrumentation, is it correct?

Yes

One other issue is for future upgrade. User can not simply drop the jar from the JBC released version.

Hence the "install" script I mentioned. I think jboss messaging does this as well.

Now why can't JBoss Aop try to maintain some binary compatability between releases?

Now that this has become a requirement, we will attempt to do this. I have always seen the woven code as an internal implementation detail, and so have not really thought about this part before. Now that we have run into a real need for this we will attempt to keep this in sync between minor versions. However, before we go final with 2.0.0.GA we *might* still need to make adjustments to what is being woven in.

[ben.wang]

Hence the "install" script I mentioned. I think jboss messaging does this as well.

I have checked with Ovidiu but he doesn't seem to be aware of it though? I assume the install script will be during the build time to run "aopc" before copying the pojo-cache.jar over to build directory. Is this what you are thinking of as well?

Now that this has become a requirement, we will attempt to do this. I have always seen the woven code as an internal implementation detail, and so have not really thought about this part before. Now that we have run into a real need for this we will attempt to keep this in sync between minor versions. However, before we go final with 2.0.0.GA we *might* still need to make adjustments to what is being woven in.

OK. As long as we have gurantee for minor releases, I am ok with it. Otherwise, it'd be nightmare to maintain it for all the relases. Thanks.

[kabirkhan]

I have updated the repository with a snapshot that should fix your problem, i.e. what will go in aop alpha 3.