[Beginner's Corner] - How to load a file packaged in the .esb?
by Derek Croxton
Derek Croxton [https://community.jboss.org/people/mataratones] created the discussion
"How to load a file packaged in the .esb?"
To view the discussion, visit: https://community.jboss.org/message/773228#773228
--------------------------------------------------------------
I'm trying to load an XSLT file from the .esb package. (This is for a custom action, ignore for the moment why I'm not doing an XsltAction.) The base path, for some reason, is jboss-as\bin\, which is obviously not in the .esb, and when I try to use a relative path that goes up a directory ("../"), I get a MalformedURL exception. A servlet would have a context, but my class is not a servlet, so I don't know how to get at a file inside the .esb. I don't think this is an unusual thing to do, but obviously I have no idea how to do it, and I would appreciate any help.
Derek
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/773228#773228]
Start a new discussion in Beginner's Corner at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 1 month
[jBPM] - How to Disable CommandBasedWSHumanTaskHandler in CommandDelegate
by Timothy Charman
Timothy Charman [https://community.jboss.org/people/tcharman] created the discussion
"How to Disable CommandBasedWSHumanTaskHandler in CommandDelegate"
To view the discussion, visit: https://community.jboss.org/message/766586#766586
--------------------------------------------------------------
Hi
I have written a different implementation of the human task, as I have a bunch of external systems to integrate. The work item handler extends either side of the human task lifecycle. This works fine when running locally.
But when I deploy to jBPM console server, things go awry because the CommandBasedWSHumanTaskHandler is registered with the session in the CommandDelegate. In turn, CommandBasedWSHumanTaskHandler registers a listener for human task events, which fire when the human task completes, and restarts my workflow, even though I have not included the CommandBasedWSHumanTaskHandler in my workflow.
My task handler listens for the same events, but by the time my task handler is ready to restart the process, it is too late - CommandBasedWSHumanTaskHandler has already started it.
This is really not desirable, as it means the behaviour on the server is different than when running locally through Eclipse, and it means I cannot contribute any of my own task handlers that interact with the human task service. I see no way to remove the CommandBasedWSHumanTaskHandler registration except by forking the code, which I want to avoid.
Anyone any ideas?
Thanks
Tim
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/766586#766586]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 1 month
[JBoss Remoting] - 3873 was closed suddenly
by Ron Sigal
Ron Sigal [https://community.jboss.org/people/ron_sigal] created the discussion
"3873 was closed suddenly"
To view the discussion, visit: https://community.jboss.org/message/773311#773311
--------------------------------------------------------------
While JBOSS5.1.0 GA running, there was an exception log in server.log like:
2012-05-30 07:43:43,176 INFO (main)[org.jboss.bootstrap.microcontainer.ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221053)] Started in 38s:998ms
2012-06-26 21:00:08,515 ERROR (WorkerThread#0[2001:1890:1001:240c:0:0:0:4:50783])[org.jboss.remoting.transport.socket.ServerThread] WorkerThread#0[2001:1890:1001:240c:0:0:0:4:50783] exception occurred during first invocation
java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedConstructorAccessor422.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.jboss.remoting.transport.socket.ServerThread.createServerSocketWrapper(ServerThread.java:909)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:491)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
Caused by: java.io.EOFException
at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)
at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.<init>(ObjectInputStreamWithClassLoader.java:100)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.createInput(JavaSerializationManager.java:54)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.getMarshallingStream(SerializableUnMarshaller.java:75)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.getMarshallingStream(SerializableUnMarshaller.java:58)
at org.jboss.remoting.transport.socket.ClientSocketWrapper.createInputStream(ClientSocketWrapper.java:179)
at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:162)
at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:66)
at org.jboss.remoting.transport.socket.ServerSocketWrapper.<init>(ServerSocketWrapper.java:46)
... 6 more
And we checked the 3873 using "netstat -antp" command. Don't know when this port was closed.
Could someone tell me how to prevent it or the root cause. Thanks in advance.
>From Richard Zhang.
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/773311#773311]
Start a new discussion in JBoss Remoting at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 1 month
[jBPM] - jBPM Persistence: Object unmarshalling with Drools accumulate
by Jason J
Jason J [https://community.jboss.org/people/jasonjho] created the discussion
"jBPM Persistence: Object unmarshalling with Drools accumulate"
To view the discussion, visit: https://community.jboss.org/message/773261#773261
--------------------------------------------------------------
Environment: Drools 5.3.1 + jBPM5.2
I am using a custom ObjectMarshallingStrategy when using jBPM persistence b/c I am unable to serialize the Facts that are inserted into the working memory.
To do this, I am plugging in a custom strategy on the persistence environment as such:
env.set(EnvironmentName.OBJECT_MARSHALLING_STRATEGIES, new ObjectMarshallingStrategy[] {
new MyResolverStrategy(...),
new JPAPlaceholderResolverStrategy(persistenceEnv),
new SerializablePlaceholderResolverStrategy(ClassObjectMarshallingStrategyAcceptor.DEFAULT)
});
I also have a rule in the ksession that is used to trigger some events in the jBPM workflow. This rule uses the "collect" feature of Drools and it accumulates Facts until a condition is met.
$currentApprovals: List(size >= 3) from collect(Approval() from $document.getCurrentApprovals())
I am getting the following exception
java.io.OptionalDataException: null
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1282) ~[na:1.6.0_31]
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) ~[na:1.6.0_31]
at org.drools.marshalling.impl.InputMarshaller.readLeftTuple(InputMarshaller.java:714) ~[drools-core-5.3.1.Final-csi.jar:5.3.1.Final]
at org.drools.marshalling.impl.InputMarshaller.readLeftTuple(InputMarshaller.java:619) ~[drools-core-5.3.1.Final-csi.jar:5.3.1.Final]
at org.drools.marshalling.impl.InputMarshaller.readLeftTuples(InputMarshaller.java:584) ~[drools-core-5.3.1.Final-csi.jar:5.3.1.Final]
at org.drools.marshalling.impl.InputMarshaller.readFactHandles(InputMarshaller.java:433) ~[drools-core-5.3.1.Final-csi.jar:5.3.1.Final]
at org.drools.marshalling.impl.InputMarshaller.readSession(InputMarshaller.java:266) ~[drools-core-5.3.1.Final-csi.jar:5.3.1.Final]
at org.drools.marshalling.impl.InputMarshaller.readSession(InputMarshaller.java:196) ~[drools-core-5.3.1.Final-csi.jar:5.3.1.Final]
at org.drools.marshalling.impl.DefaultMarshaller.unmarshall(DefaultMarshaller.java:93) ~[drools-core-5.3.1.Final-csi.jar:5.3.1.Final]
at org.drools.persistence.SessionMarshallingHelper.loadSnapshot(SessionMarshallingHelper.java:91) ~[drools-jbpm-persistence-jpa-5.3.1.Final-csi.jar:5.3.1.Final]
... 26 common frames omitted
Looking at this code, I see
case NodeTypeEnums.AccumulateNode: {
// accumulate nodes generate new facts on-demand and need special procedures when de-serializing from persistent storage
AccumulateMemory memory = (AccumulateMemory) context.wm.getNodeMemory( (BetaNode) sink );
memory.betaMemory.getLeftTupleMemory().add( parentLeftTuple );
readBehaviors( (BetaNode) sink,
memory.betaMemory,
context );
AccumulateContext accctx = new AccumulateContext();
parentLeftTuple.setObject( accctx );
// first we de-serialize the generated fact handle
InternalFactHandle handle = readFactHandle( context );
accctx.result = new RightTuple( handle,
(RightTupleSink) sink );
// then we de-serialize the associated accumulation context
accctx.context = (Serializable[]) stream.readObject();
...
...
It looks like the last line above is doing some deserializing. I am not familiar with this lower level code, but shouldn't this be using the ObjectMarshallingStrategy? How will the objects be able to deserialize correctly if I am relying on my own strategy to resolve facts?
Any help would be appreciated!!
--------------------------------------------------------------
Reply to this message by going to Community
[https://community.jboss.org/message/773261#773261]
Start a new discussion in jBPM at Community
[https://community.jboss.org/choose-container!input.jspa?contentType=1&con...]
12 years, 1 month
