[JBoss Messaging] - Re: Incompatible local class org.jboss.remoting.InvokerLocat
by tonylmai
>From the exception thrown:
anonymous wrote : local class incompatible: stream classdesc serialVersionUID = -2909329895029296248, local class serialVersionUID = -4977622166779282521
server version = -2909329895029296248 == Long.valueOf(0xd79ffbdff05ab388L);
local version = -4977622166779282521 == Long.valueOf(0xbaebef030b02bba7L);
By looking at the code,
public class InvokerLocator {
| ...
| static
| {
| if(Version.getDefaultVersion() == 1)
| serialVersionUID = 0xd79ffbdff05ab388L; <--- server version
| else
| serialVersionUID = 0xbaebef030b02bba7L; <--- local version
| }
| }
So version from server is set to 1. Why?
public class Version {
| ...
| public static int getDefaultVersion()
| {
| return defaultByteVersion;
| }
| ...
| defaultByteVersion = 22; <----- default
| boolean precompatibleFlag = false;
| String precompatible = System.getProperty("jboss.remoting.pre_2_0_compatible");
| if(precompatible != null && precompatible.length() > 0)
| precompatibleFlag = Boolean.valueOf(precompatible).booleanValue();
| if(precompatibleFlag)
| {
| defaultByteVersion = 1; <----- set to 1
| performVersioning = false;
| } else
| {
| String userDefinedVersion = System.getProperty("jboss.remoting.version");
| if(userDefinedVersion != null && userDefinedVersion.length() > 0)
| {
| byte userByteVersion = (new Byte(userDefinedVersion)).byteValue(); <-- could be 1
| ....
| }
So either the server is running with jboss.remoting.pre_2_0_compatible flagged to true or jboss.remoting.version is set to 1.
Does that sound right?
Yet I couldn't find any reference to either one of them in the server's scripts.
Any idea?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034817#4034817
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034817
19 years
[JBoss Seam] - Injection of a stateless session bean (SLSB) into another SL
by trickyvail
I've set up a SLSB as follows:
@Stateless
| @Name("simpleBean")
| public class SimpleBean implements Simple
| {
| public String getName()
| {
| return "simple";
| }
| }
|
The "simpleBean" bean can be accessed from a EL expression on a facelets page without any trouble.
I have another SLSB like this:
@Stateless
| @Name("containerBean")
| public class ContainerBean implements Container
| {
| @In
| SimpleBean simpleBean;
|
| public String getName()
| {
| return simpleBean.getName();
| }
| }
However, when I try to access the getName method of "containerBean" I run into the following error:
Caused by: org.jboss.seam.RequiredException: In attribute requires non-null value: containerBean.simpleBean
| at org.jboss.seam.Component.getValueToInject(Component.java:1919)
|
If I change "simpleBean" into a JavaBean provided and annotate "containerBean" with In(create=true) the injection works as expected, but if I create a similar annotation without changing "simpleBean" to a JavaBean I get an error like this:
... 95 more
| Caused by: java.lang.IllegalArgumentException: Could not set field value by reflection: ContainerBean.simpleBean on: com.somedomain.stateless.ContainerBean with value: class org.javassist.tmp.java.lang.Object_$$_javassist_3
| at org.jboss.seam.util.Reflections.set(Reflections.java:77)
| at org.jboss.seam.Component.setFieldValue(Component.java:1555)
| ... 117 more
| Caused by: java.lang.IllegalArgumentException
| at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:63)
|
The seam documentation makes it clear that SLSB's live in the stateless context which is not included in the context search. Is this why my "simpleBean" can not be found for injection into my "containerBean"? I'm not familiar with how seam and the ejb3 container interact during instantiation of these SLSB objects into pools - perhaps the beans are being created out of order? Perhaps I'm trying to do something way beyond the intention of the EJB3 SLSB specification. I'm pretty much resolved that what I'm trying to do here is not a great idea. Is there a different way to dynamically assign a reference to a SLSB to a different SLSB when a method is called? I would be very interested to hear other peoples insight and wisdom on the subject. Thanks in advance and kind regards.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034807#4034807
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034807
19 years
[JBoss jBPM] - Re: JBPM 3.2 - Mailing process - NullPointerException during
by ygiriyap
I added a new hibernate mapping file for MailAction class.
org.jbpm.graph.action.MailAction.hbm.xml
<?xml version="1.0"?>
| <!DOCTYPE hibernate-mapping PUBLIC
| "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
| "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
|
| <hibernate-mapping default-access="field" >
| <subclass name="org.jbpm.graph.action.MailAction" discriminator-value="M" extends="org.jbpm.graph.def.Action">
| </subclass>
|
| </hibernate-mapping>
Now I could successfully deploy the process.
Wait ... BUT !!!!
When I try to instantiate the mailing process ... am getting NullPointerException
| 42156 [http-8080-Processor25] ERROR org.jbpm.webapp.bean.ProcessBean - Failed to start process: org.jbpm.graph.def.DelegationException
| org.jbpm.graph.def.DelegationException
| at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:367)
| at org.jbpm.graph.def.GraphElement.raiseException(GraphElement.java:358)
| at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:261)
| at org.jbpm.graph.def.GraphElement.executeActions(GraphElement.java:215)
| at org.jbpm.graph.def.GraphElement.fireAndPropagateEvent(GraphElement.java:185)
| at org.jbpm.graph.def.GraphElement.fireEvent(GraphElement.java:169)
| at org.jbpm.graph.def.Node.enter(Node.java:302)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
| at java.lang.reflect.Method.invoke(Unknown Source)
| at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:147)
| at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$5e7dd3fd.enter(<generated>)
| at org.jbpm.graph.def.Transition.take(Transition.java:151)
| at org.jbpm.graph.def.Node.leave(Node.java:393)
| at org.jbpm.graph.node.TaskNode.leave(TaskNode.java:209)
| at org.jbpm.graph.def.Node.leave(Node.java:357)
| at org.jbpm.graph.node.TaskNode.execute(TaskNode.java:190)
| at org.jbpm.graph.def.Node.enter(Node.java:318)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
| at java.lang.reflect.Method.invoke(Unknown Source)
| at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:147)
| at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$5e7dd3fd.enter(<generated>)
| at org.jbpm.graph.def.Transition.take(Transition.java:151)
| at org.jbpm.graph.def.Node.leave(Node.java:393)
| at org.jbpm.graph.node.StartState.leave(StartState.java:70)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
| at java.lang.reflect.Method.invoke(Unknown Source)
| at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:147)
| at org.jbpm.graph.def.Node$$EnhancerByCGLIB$$5e7dd3fd.leave(<generated>)
| at org.jbpm.graph.exe.Token.signal(Token.java:194)
| at org.jbpm.graph.exe.Token.signal(Token.java:165)
| at org.jbpm.webapp.bean.ProcessBean.startInstance(ProcessBean.java:162)
| at org.jbpm.webapp.bean.ProcessBean$StartInstanceListener.processAction(ProcessBean.java:123)
| at javax.faces.event.ActionEvent.processListener(ActionEvent.java:77)
| at javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:758)
| at javax.faces.component.UICommand.broadcast(UICommand.java:368)
| at javax.faces.component.UIData.broadcast(UIData.java:854)
| at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:448)
| at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:752)
| at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:97)
| at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
| at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
| at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
| at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
| at org.jbpm.webapp.filter.LogFilter.doFilter(LogFilter.java:59)
| 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.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
| 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:667)
| at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
| at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
| at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
| at java.lang.Thread.run(Unknown Source)
| Caused by: java.lang.NullPointerException
| at org.jbpm.mail.Mail.send(Mail.java:98)
| at org.jbpm.mail.Mail.execute(Mail.java:63)
| at org.jbpm.graph.def.Action.execute(Action.java:122)
| at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:247)
|
This error is being thrown from ... GraphElement.executeAction method.
log.error("action threw exception: " + exception.getMessage(), exception);
Mail support being one of the major features of JBPM 3.2, should have enough documentation and make it easy to implement.
Please let me know any pointers to solve this.
Many thanks.
--Yash
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034801#4034801
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034801
19 years
[JBoss Seam] - Injected SLSB not getting interceptors sometimes
by stu2
I'm running Seam 1.2.1, and these symptoms appear in SeamTest.
I have SLSB A which is injected via @In with SLSB B. A seems to have all appropriate interceptors, and @Logger injection works fine. A calls B. B blows up upon writing to the log because the log is never initialized. I've tried having B declare @Logger Log log explicitly and (in the example I'll post here) by extending EntityController.
Here's relevant bits of A:
| @Name("ingestService")
| @Stateless
| @AutoCreate
| public class IngestServiceImpl implements IngestService
| {
| @Logger static Log log;
| @In CsvIngest ingestUtil;
|
|
| .... (in a method)
| ingestResult = ingestUtil.ingest(feedFile, feedDefinition, previousFeedItems);
|
B will throw NullPointerException when it tries to log. What I found odd is that A has all indications of receiving the interceptors, which do the injection. B looks like a direct invocation (no sign of interceptors). And I can's see a meaningful difference between A and B - so I'm stuck.
Anyway, here's the relevant bits from B:
| @Stateless
| @Name("ingestUtil")
| @AutoCreate
| public class CsvIngestUtil extends EntityController implements CsvIngest
| {
|
| ... below from the throwing method - last line is 135 referenced from stacktrace
|
| item.setFeedItemStatus(FeedItemStatus.INSERT_REQUESTED);
| // I put this here to test if the em was injected - it is because the assert doesn't throw
| assert getEntityManager() != null : "null entity manager!";
| System.out.println("EntityManager is not null. [" + getEntityManager().getClass().getName() + "]");
| debug("Scheduling item [" + item.getUniqueInternalCode() + "] for insert"); // throws here
|
The stacktrace showing the (to me) unexpected presence/absence of interceptors is:
| aused by: java.lang.NullPointerException
| at org.jboss.seam.framework.Controller.debug(Controller.java:183)
| at com.fb.core.business.ingest.CsvIngestUtil.updateItemFromPreviousData(CsvIngestUtil.java:135)
| at com.fb.core.business.ingest.CsvIngestUtil.ingest(CsvIngestUtil.java:85)
| at com.fb.core.business.IngestServiceImpl.processFeedImportNoPersistance(IngestServiceImpl.java:76)
| at com.fb.core.business.IngestServiceImpl.processFeedImport(IngestServiceImpl.java:52)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:109)
| at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
| at org.jboss.seam.intercept.EJBInvocationContext.proceed(EJBInvocationContext.java:37)
| at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:57)
| at org.jboss.seam.interceptors.BijectionInterceptor.aroundInvoke(BijectionInterceptor.java:47)
| at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
| at org.jboss.seam.interceptors.MethodContextInterceptor.aroundInvoke(MethodContextInterceptor.java:27)
| at org.jboss.seam.intercept.SeamInvocationContext.proceed(SeamInvocationContext.java:69)
| at org.jboss.seam.intercept.RootInterceptor.invoke(RootInterceptor.java:103)
| at org.jboss.seam.intercept.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:53)
| at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:118)
| at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
| at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
| at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
| at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
| at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
|
Any idea what I'm doing wrong here? Any more info I could provide if not?
I confess I'm a bit confused by when I should expect interception. I'm using SLSB more often than I would otherwise because I want @Logger and other interceptor services to work, but I realize this is because I don't understand enough yet.
Thanks,
Stu
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4034796#4034796
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4034796
19 years