1:47 p.m.
OOps, large portions were left out because I didn't use the tag... please see details
in ensuing copy.
|
| Greetings,
|
| I have read all of the documentation I can find on the JBoss AOP AND the JBoss Cache,
and even looked through the JBoss Cache public forum from beginning to end, drilling into
ANY of the cases whose subject might remotely indicate a potential solution to this. If
there is any place my question indicates I have not looked, please do point me in that
direction.
|
| Perhaps this list of steps could assist others in configuring their pojocache to run
under the application server (once this last little trinket is resolved). I have
downloaded the aop and cache distributions and looked extensively at the examples and
documentation therein.
|
| I dearly hope this problem sounds familiar to someone. Thanks in advance for your
consideration.
|
| I think I'm very close to having PojoCache working under the application server.
Below I provide the steps I've *ultimately* taken to get to where I am. There was
much other experimentation, but this has been the path that has taken me closest to
success. Below I list my 2 questions.
|
| 0: Prerequisites/assumptions:
| Jboss installation: Jboss Application server version 4.0.4.GA
| Jboss Cache distribution: version 1.4.1.GA
| JBoss aop distribution: version 1.5.2.GA
| JDK: 1.5.0_06 (Java 5.0)
| I'm attempting to utilize the jboss Pojo Cache using annotations to instrument
the pojocacheable objects.
|
| 1. Install application server 4.0.4, with DEFAULT configuration.
|
| 2. Obtain the latest production Jboss Cache distribution, (for me it was Jboss Cache
1.4.1.GA) We'll need pieces of this.
|
| 3. Obtain the latest JbossAOP distribution, (for me it was Jboss AOP 1.5.2.GA)
We'll need pieces of this.
|
| 4. If not using all configuration, i.e. if using default, copy jgroups.jar and
jboss-cache-jdk50.jar (from the cache distribution?s library directories),
|
| into the <jboss.home>/server/default/deploy directory.
|
| 5. Delete the jboss-aop.deployer folder from the
<jboss.install.dir>/server/default/deploy directory.
|
| 6. Copy the entire jboss-aop-jdk50.deployer folder and all its contents from the
jboss-40-install directory of the aop distribution into your
|
| <jboss.install.dir>/server/default/deploy directory. ** In an attempt to
eliminate the stacktrace I'm receiving, I replaced this folder with the one from the
jboss ejb installation's jboss-aop-jdk50.deployer folder, (different contents), but it
yielded the same results; see exception below.
|
| 7. Replace jboss-cache.jar in <jboss.install.dir>/server/default/lib with
jboss-cache-jdk50.jar, (found in jboss-cache distribution).
|
| 8. Put together a configuration file for the PojoCache Mbean service, and place it in
the deploy directory:
| Configure a file called XXXXX-service.xml, where XXXX is of your choosing. The
"-service.xml" suffix is the magic responsible for allowing JBoss to recognize
the contents of this file as the configuration for an mbean, i.e. it causes JBoss to
recognize this file. I chose gehc_pojocache-service.xml, with the mbean path of the
PojoCache, and place it in <jboss.home>/server/default/deploy. This will be
responsible for running JBoss Cache as an MBean service under the JBoss AS. Many samples
are available in the jboss-cache distribution.
|
| In this file, Be sure to alter the mbean configuration line to resemble the
following:
| <mbean code="org.jboss.cache.aop.PojoCache"
name="jboss.cache:service=PojoCache">
| This causes PojoCache to be run as a service MBean under the application server.
|
| 9. To run under the application server, I have a jsp page that instantiates an object
and calls a method on it. That method contains the following sample code to insert an
item, and then get the item:
|
| PojoCache userCache = new PojoCache();
| |
| | MBeanServer server = MBeanServerLocator.locateJBoss();
| | PojoCacheMBean userCache = (PojoCacheMBean)
MBeanProxyExt.create(PojoCacheMBean.class, "jboss.cache:service=PojoCache",
server);
| | userCache.putObject(userName, new UserInfoTEST(userName, 33));
| | UserInfoTEST userInfoFromCache = (UserInfoTEST)(userCache.getObject(userName));
|
| 10. The jsp and sample class with the code from instruction 9 are wrapped into a .war
file. One AOP aspectized class (com.gehcit.cp.security.UserInfoTEST), along with a
META-INF/jboss-aop.xml file containing:
|
| <aop>
| | <prepare expr="field(*
@org.jboss.cache.aop.annotation.PojoCacheable->*)" />
| | </aop>
|
| are placed into a .aop archive, after successfully enduring the aopc task in an ant
build that precompiles them to ready them for the pojocache. The UserInfoTEST class is
instrumented via use of the @pojocacheable tag. The aopc task is successful, and this has
been verified by running the same example, (by use of a public static void main(String
[]args) method inside the class in the war)... The .war and .aop files are placed into the
.ear file, along with an application.xml that notes their presence, (the war file as a web
module, and the .aop as a java module. The ear file is successfully deployed to
<jboss.install.dir>/server/default/deploy.
|
| I have run this example outside of the application server, and all's well, it just
doesn't seem to want to run in the application server environment. To run it outside
of the application server, the only thing that changes is the sample code mentioned in
step 9, which would become: JBoss allows us to use the same configuration file for
consistency, and consiously ignores the mbean tag.
|
| PojoCache userCache = new PojoCache();
| | PropertyConfigurator config = new PropertyConfigurator(); // configure tree
cache.
| | config.configure(userCache, "META-INF/gehc_pojocache-service.xml");
| | userCache.setClusterName("CPCluster1");
| | userCache.startService(); // start the pojo cache
| | userCache.putObject(userName, new UserInfoTEST(userName, 33));
| | UserInfoTEST userInfoFromCache = (UserInfoTEST)(userCache.getObject(userName));
|
| IT ALMOST WORKS... I'm very close, (I think/hope).
|
| I can provide my cache configuration xml, ant script, sample Eclipse projects, (tiny
stripped version to isolate this issue), etc. and/or answer any questions which might
assist in the reaching of a solution. However, I'm thinking this exception will
probably mean something to someone. It seems pretty indicative of what's wrong, just
not to me.
|
| My Questions:
|
| 1. When I visit the jsp page, and it runs the simple sample code listed above in item
9, the putObject() call causes the exception indicated by the following stacktrace:
|
| 13:18:01,139 ERROR [[jsp]] Servlet.service() for servlet jsp threw exception
| | org.jboss.util.NotImplementedException: Use getFieldWriteInfos
| | at org.jboss.aop.ClassAdvisor.getFieldWriteInterceptors(ClassAdvisor.java:243)
| | at com.gehcit.cp.security.UserInfoTEST.stName_w_$aop(UserInfoTEST.java)
| | at com.gehcit.cp.security.UserInfoTEST.<init>(UserInfoTEST.java:19)
| | at com.gehcit.trythis.TryThisWAR.tryThisWAR(TryThisWAR.java:56)
| | at org.apache.jsp.tryThis_jsp._jspService(tryThis_jsp.java:65)
| | at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
| | at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| | at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
| | at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
| | at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
| | at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| | at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
| | at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| | at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
| | at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
| | at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| | at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
| | at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
| | at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
| | at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
| | at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
| | at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
| | at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
| | at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
| | at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
| | at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
| | at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
| | at
org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
| | at java.lang.Thread.run(Unknown Source)
| I drilled into the source code that came with the aop distribution, and sure enough,
that method appears as follows:
|
| /** @deprecated use getFieldWriteInfos instead */
| | public Interceptor[][] getFieldWriteInterceptors()
| | {
| | throw new NotImplementedException("Use getFieldWriteInfos");
| | }
|
| Stepping down one line in the stack trace leads me to believe that the problem lies
with whatever precompiled my class files in the instrumentation process through aopc.
That was handled by the following ant task, which clearly shows that the aopc task lives
in the code that came with the jboss aop distribution, (in my case version 1.5.2.GA):
|
|
| *cache.lib and cache.lib50 are the lib and lib50 directories from the cache
distribution.
|
| <fileset dir="${cache.lib}">
| | <include name="**/*.jar" />
| | <exclude name="jboss-cache.jar" />
| | <exclude name="jboss-aop.jar" />
| | </fileset>
| |
| | <fileset dir="${cache.lib-50}">
| | <include name="**/*.jar" />
| | </fileset>
| |
| |
| | <path id="pojocache.lib.classpath">
| | <fileset dir="${cache.lib}">
| | <include name="jboss-common.jar" />
| | <include name="concurrent.jar" />
| | <include name="javassist.jar" />
| | <include name="trove.jar" />
| | </fileset>
| | <fileset dir="${cache.lib-50}">
| | <include name="jboss-cache-jdk50.jar" />
| | <include name="jboss-aop-jdk50.jar" />
| | </fileset>
| | </path>
| |
| |
| | <target name="aopc" description="Precompile aop test
classes" depends="copyclasses">
| | <taskdef name="aopc" classname="org.jboss.aop.ant.AopC"
classpathref="pojocache.lib.classpath" />
| |
| | <aopc compilerclasspathref="lib.classpath"
verbose="true">
| | <classpath path="${aop.class.dir}"/>
| | <src path="${aop.class.dir}" />
| | <!-- <include name="${UserInfoTEST.class}"/>
| | <aoppath path="${aop.path}"/> -->
| | <aopclasspath path="${aop.class.dir}"/>
| | </aopc>
| |
| | </target>
|
| It would appear that JBoss Cache 1.5.2.GA is at odds with JBoss AS 4.0.4.GA... but
they're both the newest GA releases available. Help?
|
|
| 2. In the gehc_pojocache-service.xml (my cache configuration file placed in the
<jboss.install.dir>/server/default/deploy to cause the mbean-itization of the
pojocache, should I manipulate the classpath line at the top of the file so that instead
of as follows:
|
| <classpath codebase="./lib" archives="jboss-cache.jar,
jgroups.jar" />
|
| it would appear as follows:
|
| <classpath codebase="./lib" archives="jboss-cache-jdk50.jar,
jgroups.jar" />
|
| Nobody seems to be doing this in any documentation or even in the sample xml files
that come with the distribution, but it seems to reference the jboss-cache.jar relatively,
and we don't really have one w/ the jdk5 aspirations. Experimentally changing it
doesn't seem to have any impact, even if I change it to: <classpath
codebase="./lib" archives="something_obviously_bogus_on_purpose.jar"
/>
|
| What's going on w/ this line?
|
| Thanks again for your time,
| Jeff
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4002999#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...