[JBossCache] - Problem running PojoCache in JBoss AS
by jcollins914
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:
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:
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.(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.
<!--
-->
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:
it would appear as follows:
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:
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=4003353#4003353
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003353
19 years, 3 months
[JBoss Seam] - Re: Invitation to try new Seam authentication features
by Lundegaard
anonymous wrote :
| anonymous wrote :
| | Is it possible to check authorization before RESTORE_VIEW?
| |
| | I had some problems, since without an authenticated user the @In attribute threw an exception.
| | And I don't want to have 404s for unauthorized users, when there isn't an existing file for the requested view.
| |
| What are you trying to inject with @In?
|
A class similar to org.jboss.seam.example.seamspace.LoginAction from where I get my authenticated user. Of course I solved the problem with @In(create=true), but nevertheless I think, it would be more consistent, if a non-authorized user had no access to resources with a security-constraint.
I just expected that unauthorized users won't get access to any existing or not-existing resource and so no bijection will occur for these resources.
Regards,
Thomas
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4003342#4003342
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4003342
19 years, 3 months