[JBoss JIRA] Created: (JBESB-2239) StartProcessInstanceCommand: Return token id/process instance id
by Burr Sutter (JIRA)
StartProcessInstanceCommand: Return token id/process instance id
----------------------------------------------------------------
Key: JBESB-2239
URL: https://jira.jboss.org/jira/browse/JBESB-2239
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Process flow
Affects Versions: 4.4 CP1
Reporter: Burr Sutter
A very common request is to have the BpmProcessor action return a token/process instance id. Perhaps in the
<action name="start_a_new_process_instance"
class="org.jboss.soa.esb.services.jbpm.actions.BpmProcessor">
<property name="command" value="StartProcessInstanceCommand" />
<property name="process-definition-name" value="bpm_orchestration3Process"/>
<property name="key" value="businessKey"/>
<property name="esbToBpmVars">
<mapping esb="BODY_CONTENT" bpm="theBody" />
<mapping esb="contentsAsString" bpm="theData" />
</property>
</action>
Perhaps we could do that as variable mapping.
It has also be requested that we clean up the callback EPR XML. It is a rather large chunk of information currently
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 5 months
[JBoss JIRA] Created: (JBESB-2160) Caching registry interceptor impacts must be documented and configuration values updated
by Kevin Conner (JIRA)
Caching registry interceptor impacts must be documented and configuration values updated
----------------------------------------------------------------------------------------
Key: JBESB-2160
URL: https://jira.jboss.org/jira/browse/JBESB-2160
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Configuration, Documentation
Affects Versions: 4.4
Reporter: Jiri Pechanec
Assignee: Daniel Bevenius
Priority: Critical
Fix For: 4.4 CP1
If the CachingRegistryInterceptor is used in out-of-process binary - client or another ESB it can cause serious headache.
The problem is that if the service is undeployed or EPRs changed then there are still old values in the cache. So for example it reports it cannot connect to the queue that is not already there etc.
Another problem is that default value for load balancer cache timeout is 60 seconds and CachingRegistryIntreceptor is 600 secods. So if there is a service undeployed in the cluster the load balancer will repeatedly receive stale EPRs.
See example of records in log
2008-08-27 09:39:42,785 DEBUG [main][org.jboss.internal.soa.esb.couriers.JmsCourier] Error from JMS system.
javax.jms.JMSException: There is no administratively defined queue with name:queue/banker_deploy_process_esb
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.createQueue(ServerSessionEndpoint.java:291)
at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$createQueue$aop(SessionAdvised.java:105)
at org.jboss.jms.server.endpoint.advised.SessionAdvised$createQueue_6431069199924553036.invokeNext(SessionAdvised$createQueue_6431069199924553036.java)
at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
at org.jboss.jms.server.endpoint.advised.SessionAdvised$createQueue_6431069199924553036.invokeNext(SessionAdvised$createQueue_6431069199924553036.java)
at org.jboss.jms.server.endpoint.advised.SessionAdvised.createQueue(SessionAdvised.java)
at org.jboss.jms.wireformat.SessionCreateQueueRequest.serverInvoke(SessionCreateQueueRequest.java:74)
at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:143)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:866)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:608)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:420)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:173)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163)
at org.jboss.remoting.Client.invoke(Client.java:1634)
at org.jboss.remoting.Client.invoke(Client.java:548)
at org.jboss.remoting.Client.invoke(Client.java:536)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:189)
at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:160)
at org.jboss.jms.client.delegate.ClientSessionDelegate.org$jboss$jms$client$delegate$ClientSessionDelegate$createQueue$aop(ClientSessionDelegate.java:297)
at org.jboss.jms.client.delegate.ClientSessionDelegate$createQueue_6431069199924553036.invokeNext(ClientSessionDelegate$createQueue_6431069199924553036.java)
at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientSessionDelegate$createQueue_6431069199924553036.invokeNext(ClientSessionDelegate$createQueue_6431069199924553036.java)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
at org.jboss.jms.client.delegate.ClientSessionDelegate$createQueue_6431069199924553036.invokeNext(ClientSessionDelegate$createQueue_6431069199924553036.java)
at org.jboss.jms.client.delegate.ClientSessionDelegate.createQueue(ClientSessionDelegate.java)
at org.jboss.jms.client.JBossSession.createQueue(JBossSession.java:250)
at org.jboss.internal.soa.esb.rosetta.pooling.JmsSession.createQueue(JmsSession.java:186)
at org.jboss.internal.soa.esb.couriers.JmsCourier.createMessageProducer(JmsCourier.java:334)
at org.jboss.internal.soa.esb.couriers.JmsCourier.deliver(JmsCourier.java:188)
at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.deliver(TwoWayCourierImpl.java:189)
at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.attemptDelivery(ServiceInvoker.java:530)
at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.access$200(ServiceInvoker.java:452)
at org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:318)
at org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:198)
at org.jboss.soa.esb.qa.framework.SendESBMessage.sendSync(SendESBMessage.java:103)
at org.jboss.soa.esb.qa.framework.ESBTestServices.deployJBPMProcess(ESBTestServices.java:675)
at org.jboss.soa.esb.samples.quickstart.jbpmrulesaction.BPMRulesActionHandlerTest.setupClass(BPMRulesActionHandlerTest.java:31)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:604)
at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:394)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:142)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:79)
at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:165)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:103)
at org.testng.TestRunner.runWorkers(TestRunner.java:678)
at org.testng.TestRunner.privateRun(TestRunner.java:624)
at org.testng.TestRunner.run(TestRunner.java:495)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:300)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:295)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:275)
at org.testng.SuiteRunner.run(SuiteRunner.java:190)
at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:792)
at org.testng.TestNG.runSuitesLocally(TestNG.java:765)
at org.testng.TestNG.run(TestNG.java:699)
at org.testng.TestNG.privateMain(TestNG.java:824)
at org.testng.TestNG.main(TestNG.java:802)
2008-08-27 09:39:42,787 WARN [main][org.jboss.soa.esb.client.ServiceInvoker] Possible configuration error while using Courier for EPR [JMSEpr [ PortReference < <wsa:Address jms://127.0.0.1:1099/queue/banker_deploy_process_esb/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.initial : org.jnp.interfaces.NamingContextFactory/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : 127.0.0.1:1099/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.url.pkgs : org.jnp.interfaces/>, <wsa:ReferenceProperties jbossesb:destination-type : queue/>, <wsa:ReferenceProperties jbossesb:specification-version : 1.1/>, <wsa:ReferenceProperties jbossesb:connection-factory : ConnectionFactory/>, <wsa:ReferenceProperties jbossesb:persistent : true/>, <wsa:ReferenceProperties jbossesb:acknowledge-mode : AUTO_ACKNOWLEDGE/>, <wsa:ReferenceProperties jbossesb:transacted : false/>, <wsa:ReferenceProperties jbossesb:type : urn:jboss/esb/epr/type/jms/> > ]] and Service [test:jbpm-deploy] and Message [header: [ To: JMSEpr [ PortReference < <wsa:Address jms://127.0.0.1:1099/queue/banker_deploy_process_esb/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.initial : org.jnp.interfaces.NamingContextFactory/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : 127.0.0.1:1099/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.url.pkgs : org.jnp.interfaces/>, <wsa:ReferenceProperties jbossesb:destination-type : queue/>, <wsa:ReferenceProperties jbossesb:specification-version : 1.1/>, <wsa:ReferenceProperties jbossesb:connection-factory : ConnectionFactory/>, <wsa:ReferenceProperties jbossesb:persistent : true/>, <wsa:ReferenceProperties jbossesb:acknowledge-mode : AUTO_ACKNOWLEDGE/>, <wsa:ReferenceProperties jbossesb:transacted : false/>, <wsa:ReferenceProperties jbossesb:type : urn:jboss/esb/epr/type/jms/> > ] ReplyTo: JMSEpr [ PortReference < <wsa:Address jms://localhost/queue/banker_deploy_process_esb_reply/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : 127.0.0.1:1099/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.initial : org.jnp.interfaces.NamingContextFactory/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.url.pkgs : org.jnp.interfaces/>, <wsa:ReferenceProperties jbossesb:destination-type : queue/>, <wsa:ReferenceProperties jbossesb:specification-version : 1.1/>, <wsa:ReferenceProperties jbossesb:connection-factory : ConnectionFactory/>, <wsa:ReferenceProperties jbossesb:message-selector : jbossESBresponseUUID='5b468d68-faa0-47dd-86a5-aef5deaec823'/>, <wsa:ReferenceProperties jbossesb:persistent : true/>, <wsa:ReferenceProperties jbossesb:acknowledge-mode : AUTO_ACKNOWLEDGE/>, <wsa:ReferenceProperties jbossesb:transacted : false/> > ] MessageID: 88e0c518-fadc-4546-b16f-599872258cee ]]. javax.jms.JMSException: There is no administratively defined queue with name:queue/banker_deploy_process_esb
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 5 months
[JBoss JIRA] Created: (JBESB-2159) The variables from services started in forked branches are lsot
by Kevin Conner (JIRA)
The variables from services started in forked branches are lsot
---------------------------------------------------------------
Key: JBESB-2159
URL: https://jira.jboss.org/jira/browse/JBESB-2159
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Process flow
Affects Versions: 4.4
Environment: IR1 on FC8
Reporter: Jiri Pechanec
Assignee: Kevin Conner
Priority: Critical
Fix For: 4.4 CP1, 4.5
The bpm_orchestartion2 qs provides different results in 4.2 and 4.3 versions. The problem is the the message modifications done in forked branches are not propagated back to the process. There are two possible explanations for this behaviour
1) The ProcessInstance.setVaribale method in jBPM does not set variable on root context - which means that there is bug in jBPM
2) Or behaviour with default configuration has changed
I am attaching modified jboss-esb.xml and process definiton file that stores the service outcome under different variables in different branches so they are not overwritten in join node.
You will see that in 4.3 the branch slots are not progpagated after the join node.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 5 months
[JBoss JIRA] Created: (JBESB-2178) Add ability to reflectively inject FileFilter into file-based gateways
by Ryan Hochstetler (JIRA)
Add ability to reflectively inject FileFilter into file-based gateways
----------------------------------------------------------------------
Key: JBESB-2178
URL: https://jira.jboss.org/jira/browse/JBESB-2178
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Adapters
Reporter: Ryan Hochstetler
It would greatly enhance the flexibility of the file-based gateways if one could specify a class implementing java.io.FileFilter as part of the configuration of that gateway. This would be a far more flexible manner of choosing which files to accept than the clunky extension-based mechanism currently in place.
Please consider the following use case:
One unified drop-box: uncompressed files of various extensions are picked up for "Service A" (.dat, .txt, .etc), and compressed files of various extensions are picked up for "Service B" (.zip, .tar.gz, .rar). Currently, this would require six different file channels, whereas my suggestion would only require two. Sure, I could split the drop boxes into "compressed" and "uncompressed", but with the "no input-suffix required" feature broken, I'd still need six.
Another use case might be that we wish to accept only files which are of a certain age onto the bus. Another might filter on file size. (I actually wrote a FileSizeLimitComposer(long threshold) extends LocalFileMessageComposer to accomplish this task by setting bytes as the payload at or below the threshold and a lightweight file handle (string or java.io.File) as the payload above the threshold, but a FileFilter would have been a much better option).
My point being: JBESB is already internally using java.io.FileFilter (FileGatewayListener._inputFileFilter), why not make the FileGatewayListener extremely flexible by allowing us to define our own FileFilters?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 5 months
[JBoss JIRA] Created: (JBESB-2219) [SystemPrintln] ClassCastException on attachment
by Joakim Sandström (JIRA)
[SystemPrintln] ClassCastException on attachment
------------------------------------------------
Key: JBESB-2219
URL: https://jira.jboss.org/jira/browse/JBESB-2219
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.4
Reporter: Joakim Sandström
org.jboss.soa.esb.actions.SystemPrintln assumes that the attachments contain Message objects
09:12:03,960 WARN [ActionProcessingPipeline] Unexpected exception caught while processing the action pipeline: header: [ To: JMSEpr [ PortReference < <wsa:Address jms://phobos:1099/queue/documents.aggregate.document/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.initial : org.jnp.interfaces.NamingContextFactory/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : phobos:1099/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.url.pkgs : org.jnp.interfaces/>, <wsa:ReferenceProperties jbossesb:destination-type : queue/>, <wsa:ReferenceProperties jbossesb:specification-version : 1.1/>, <wsa:ReferenceProperties jbossesb:connection-factory : ConnectionFactory/>, <wsa:ReferenceProperties jbossesb:persistent : true/>, <wsa:ReferenceProperties jbossesb:acknowledge-mode : AUTO_ACKNOWLEDGE/>, <wsa:ReferenceProperties jbossesb:transacted : false/>, <wsa:ReferenceProperties jbossesb:type : urn:jboss/esb/epr/type/jms/> > ] MessageID: f85dbd1f-6358-4a57-aa1d-571a30d25a5a RelatesTo: jms:correlationID#f85dbd1f-6358-4a57-aa1d-571a30d25a5a ]
java.lang.ClassCastException: java.lang.String cannot be cast to org.jboss.soa.esb.message.Message
at org.jboss.soa.esb.actions.SystemPrintln.process(SystemPrintln.java:117)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:316)
at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:530)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 5 months