[JBoss JIRA] Created: (JBESB-3376) Provide support for SOAPProcessor to invoke CXF WS Endpoints
by Magesh Kumar B (JIRA)
Provide support for SOAPProcessor to invoke CXF WS Endpoints
------------------------------------------------------------
Key: JBESB-3376
URL: https://jira.jboss.org/browse/JBESB-3376
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: 4.7
Reporter: Magesh Kumar B
Assignee: Magesh Kumar B
Fix For: 4.9
SOAPProcessor uses JBossWS-SPI to invoke the WS Endpoint. This is not compatible with CXF.
java.lang.UnsupportedOperationException: Not yet supported
at org.jboss.soa.esb.actions.soap.adapter.SOAPProcessorServletContext.getAttribute(SOAPProcessorServletContext.java:45)
at org.jboss.wsf.stack.cxf.RequestHandlerImpl.handleHttpRequest(RequestHandlerImpl.java:53)
at org.jboss.soa.esb.actions.soap.SOAPProcessor.process(SOAPProcessor.java:187)
SOAPProcessor issue is not just with the mock classes. Even if the mock class is fixed to support attributes, the CXF's JBossWS SPI implementation[1] does not handle this well. The reason is that it expects a ServletControllerExt in the ServletContext and we cannot create this by ourselves. It has to be set by CXF somehow inside the RequestHandlerImpl. Using the JBossWS-SPI is not possible on CXF ATM.
[1] http://anonsvn.jboss.org/repos/jbossws/stack/cxf/tags/jbossws-cxf-3.3.1.S...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JBESB-3402) LHS of rules failing to match on ESB redeploy
by David Ward (JIRA)
LHS of rules failing to match on ESB redeploy
---------------------------------------------
Key: JBESB-3402
URL: https://jira.jboss.org/browse/JBESB-3402
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Content Based Routing
Reporter: David Ward
Assignee: David Ward
Priority: Critical
Fix For: 4.9
It became evident that Drools caches ClassLoaders by default.
The problem that showcased this was that on redeploy of the business_rules* quickstarts, none of the LHS of the DRL rules were matching. When we deploy a new ESB archive, there is a new ClassLoader. However Drools was holding onto the old ClassLoader. Because an Object is only ever "equal" to another Object if it came from the same ClassLoader, none of the Objects on the LHS matched the expression.
Two things need to happen to fix this problem:
1. KnowledgeBuilderConfigurations need to be created with a Properties argument containing ClassLoaderCacheOption.PROPERTY_NAME="true".
2. KnowledgeBuilderConfigurations need to be created with a ClassLoader argument containing a custom ESB ClassLoader, which under-the-hood uses the LifecycleResource mechanism to associate the original Thread ContextClassLoader (the deployment's ClassLoader) with calls to loadClass(), findResource(), etc. Luckily most of what is needed here already exists in the DroolsRuleAgentHelper code.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months
[JBoss JIRA] Created: (JBESB-3397) halt()/dispose() race condition in DroolsRuleBaseState
by David Ward (JIRA)
halt()/dispose() race condition in DroolsRuleBaseState
------------------------------------------------------
Key: JBESB-3397
URL: https://jira.jboss.org/browse/JBESB-3397
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Content Based Routing
Reporter: David Ward
Assignee: David Ward
Fix For: 4.9
What happens:
Thread 1 creates a stateful session and spawns daemon Thread 2 (with the correct TCCL).
Thread 2 calls fireUntilHalt() on the stateful session, which suspends that Thread.
Thread 3 calls halt() on the stateful session, which will cause Thread 2 to stop *once all the rules have finished firing*, however returns immediately.
Thread 3 calls dispose() on the stateful session, *but the rules might not have finished firing*. This could cause unpredictable results.
What needs to happen:
Thread 1 creates a stateful session and spawns daemon Thread 2 (with the correct TCCL).
Thread 2 calls fireUntilHalt() on the stateful session, which suspends that Thread.
Thread 3 calls halt() on the stateful session, which will cause Thread 2 to stop once all the rules have finished firing, however returns immediately.
Thread 3 calls join() on Thread 2, which will return *once all the rules have finished firing* and Thread 2 is done.
Thread 3 calls dispose() on the stateful session safely, as now the rules have finished firing. This means predictable results.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 9 months