[EJB 3.0] - Re: interceptor metadata issue
by tterm
The interceptors (org.jboss.aop.advice.Interceptor) are requested during an ejb3 method call. The client side interceptor code is the following:
public class ExampleClientInterceptor implements Interceptor, Serializable {
| private static Logger logger = Logger.getLogger(ExampleClientInterceptor.class);
|
| public String getName() {
| return "ExampleClientInterceptor";
| }
|
| public Object invoke(Invocation invocation) throws Throwable {
| logger.debug("Client: request");
| SimpleMetaData metaData = invocation.getMetaData();
| metaData.addMetaData("tag", "attr", "Hello JBoss;-)");
| Object obj = invocation.invokeNext();
| logger.debug("Client: response");
| return obj;
| }
| }
If I do an EJB3 request I get allways this exception:
| java.lang.ClassCastException: org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput
| org.jboss.aop.util.MarshalledValue.writeExternal(MarshalledValue.java:190)
| org.jboss.serial.persister.ExternalizePersister.writeData(ExternalizePersister.java:58)
| org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.jav
| a:275)
| org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:3
| 86)
| org.jboss.aop.metadata.SimpleMetaData.writeExternal(SimpleMetaData.java:226)
| org.jboss.serial.persister.ExternalizePersister.writeData(ExternalizePersister.java:58)
| org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.jav
| a:275)
| org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:3
| 86)
| org.jboss.aop.joinpoint.MethodInvocation.writeExternal(MethodInvocation.java:321)
| org.jboss.serial.persister.ExternalizePersister.writeData(ExternalizePersister.java:58)
| org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.jav
| a:275)
| org.jboss.serial.objectmetamodel.DataContainer$DataContainerOutput.writeObject(DataContainer.java:3
| 86)
| org.jboss.serial.io.MarshalledObjectForLocalCalls.<init>(MarshalledObjectForLocalCalls.java:38)
| org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:53)
| org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| de.fh_wiesbaden.cs.vs.jboss_ejb3_instrumentation.interceptor.client.ARMRunningClient.invoke(ARMRunn
| ingClient.java:248)
| de.fh_wiesbaden.cs.vs.jboss_ejb3_instrumentation.interceptor.client.ClientARMInterceptor.invoke(Cli
| entARMInterceptor.java:94)
| org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| de.fh_wiesbaden.cs.vs.jboss_ejb3_instrumentation.interceptor.client.ClientGetCorrelatorFromThreadLo
| calInterceptor.invoke(ClientGetCorrelatorFromThreadLocalInterceptor.java:43)
| org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| org.jboss.ejb3.stateless.StatelessClusteredProxy.invoke(StatelessClusteredProxy.java:100)
| $Proxy92.getCategory(Unknown Source)
| de.fh_wiesbaden.cs.vs.xpetstore.web.struts.action.category.CategoryAction.doExecute(CategoryAction.
| java:48)
| de.fh_wiesbaden.cs.vs.xpetstore.web.struts.action.BaseAction.execute(BaseAction.java:78)
| org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:446)
| org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:266)
| org.apache.struts.action.ActionServlet.process(ActionServlet.java:1292)
| org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:492)
| javax.servlet.http.HttpServlet.service(HttpServlet.java:697)
| javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| de.fh_wiesbaden.cs.vs.xpetstore.web.filter.SignOnFilter.doFilter(SignOnFilter.java:128)
| com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(Unknown Source)
| com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(Unknown Source)
| org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
|
If I set the last parameter (Payload.KEY) for the addMetaData() method to 'AS_IS' then it works fine in jboss-4.0.4 and also 4.0.5. If the default payload key is MARSHALLED then it crashes with the ClassCastException.
Regards,
Thomas Termin
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975684#3975684
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975684
19 years, 1 month
[Installation, Configuration & Deployment] - Version number in JAR, SAR and EAR names
by djr667
Is there a reason why version numbers are not included in all JAR, SAR, EAR. ?AR filenames.
For example you have the following:
antlr-2.7.6.jar
bsh-1.3.0.jar
ehcache-1.1.jar
quartz-all-1.5.2.jar
but all other JARs have no version number.
What about SARs etc. Why not:
jbossweb-tomcat-5.5.17.sar instead of jbossweb-tomcat55.sar
ejb3-rc9.deployer instead of ejb3.deployer
This would make finding out what version of what is installed trivial.
I also notice that ejb3.deployer\META-INF\jboss-service.xml defines mbean code="org.jboss.ejb3.JarsIgnoredForScanning" which lists JARs literally minus version numbers, even though many, when downloaded from Apache et al, have version numbers (e.g. commons-collections.jar). Some entries have version numbers but do not match the versions we have upgraded to. Is there a list somewhere of such definitions (so I can upgrade them)?
Dave
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3975679#3975679
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3975679
19 years, 1 month