8:54 a.m.
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:ben.wang@jboss.com]
Sent: 16 November 2006 14:22
To: Kabir Khan
Cc: jbosscache-dev(a)lists.jboss.org
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:ben.wang@jboss.com]
> 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
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986544#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...