[JBoss JIRA] (SWITCHYARD-634) Camel endpoint for reference binding is not destroyed after application undeployment
by Robert Balent (JIRA)
Robert Balent created SWITCHYARD-634:
----------------------------------------
Summary: Camel endpoint for reference binding is not destroyed after application undeployment
Key: SWITCHYARD-634
URL: https://issues.jboss.org/browse/SWITCHYARD-634
Project: SwitchYard
Issue Type: Bug
Components: core
Affects Versions: 0.3
Reporter: Robert Balent
Fix For: 0.4
Attachments: reference_binding_server.log, switchyard.xml
I've created simple application with camel file:// binding input, one bean injecting XML route, XML route and file:// reference binding output.
The problem is that when application is undeployed the reference binding stays still active and is not destroyed.
In log you can see:
* Creating endpoint uri=\[file:///home/rbalent/temp/sw-input], path=[/home/rbalent/temp/sw-input], parameters=[{}]
and when file is consumed
* Creating endpoint uri=\[file:///home/rbalent/temp/sw-output], path=[/home/rbalent/temp/sw-output], parameters=[{}]
But in undeployment process there is not even mention about the second endpoint. It stays still active. Of course file: endpoint can't consume any message but when I've tried it with camel-irc component it stays connected to irc server after application undeployment.
My switchyard.xml and full AS7 server.log with notes when application deployment and undeployment started is attached.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (SWITCHYARD-630) Application ClassLoader should be passed via deployer
by Keith Babo (JIRA)
Keith Babo created SWITCHYARD-630:
-------------------------------------
Summary: Application ClassLoader should be passed via deployer
Key: SWITCHYARD-630
URL: https://issues.jboss.org/browse/SWITCHYARD-630
Project: SwitchYard
Issue Type: Enhancement
Components: component-camel, component-hornetq, component-soap, deployment
Reporter: Keith Babo
Fix For: 0.4
Several gateways are doing something like this to set the class loader for incoming messages:
ClassLoader origCL = Thread.currentThread().getContextClassLoader();
try {
Thread.currentThread().setContextClassLoader(anotherCL);
}
finally {
Thread.currentThread().setContextClassLoader(origCL);
}
We should create a standard slot for the application loader and pass that in through init in the component's activator (or something equivalent).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (SWITCHYARD-629) Switchyard Application simulation support
by Gary Brown (JIRA)
Gary Brown created SWITCHYARD-629:
-------------------------------------
Summary: Switchyard Application simulation support
Key: SWITCHYARD-629
URL: https://issues.jboss.org/browse/SWITCHYARD-629
Project: SwitchYard
Issue Type: Feature Request
Reporter: Gary Brown
Would like to simulate switchyard applications from within Savara, using a scenario (i.e. sequence diagram) with example messages. The tooling will primarily be used from within Eclipse, although can also be used outside this environment.
To support enhancements and additions to switchyard, would prefer to point the Eclipse environment at an external installation of switchyard - i.e. so the user is not dependent upon a single version of switchyard bundled with the Eclipse plugins. Reason for mentioning this, is that selective classpath (to not include bindings) is not going to be easy with this approach, as it would require the user to configure their environment with knowledge of which jars to select.
The aim would be to have a component that I could initialise with a switchyard.xml, with any relevant classes/resources being in the classpath. Reason for specifying the location of the switchyard.xml, rather than just picking up from classpath, is that the simulator may be simulating more than one switchyard application at the same time (i.e. different apps playing different participants within a choreography - simulating the end to end business transaction).
The only difference from normal initialisation is that the bindings should not be initialised, and instead would interact with this simulation component, so inbound messages would be provided by the simulation container, and messages sent by the switchyard application would be received/handled by the simulation container. Each component instance should be a separate switchyard environment, to avoid conflicts with other components running different switchyard apps, and should support a 'close' method to tidyup its environment - i.e. its possible a session may be terminated mid way, if the scenario represents just a partial transaction. It would also be useful to be able to determine that a session was still active, to know further messages are expected.
For simplicity the component could provide a synchronous invoke method, that takes the message and an optional name that can be used to specify the source binding (where multiple have been defined), but if not specified and only a single source binding, then the message should be routed as if it came from that source binding. If no name is defined, and multiple possible bindings exist, then an exception should be thrown.
A callback interface should be provided that will be invoked to handle external service invocations (i.e. that would normally be routed via a reference binding). This interface should offer one-way and request/response variations, and supply the outbound message and the target binding name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months