[JBoss JIRA] Created: (JBESB-3440) Smooks 1.2 JavaBean namespace with wise SoapClient causes ClassNotFoundException
by Toshiya Kobayashi (JIRA)
Smooks 1.2 JavaBean namespace with wise SoapClient causes ClassNotFoundException
--------------------------------------------------------------------------------
Key: JBESB-3440
URL: https://jira.jboss.org/browse/JBESB-3440
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.7 CP2
Reporter: Toshiya Kobayashi
I'm using the wise SoapClient to call an external SOAP web service. The ESB service itself is exposed as web service as well, but using a different XSD, and only OneWay.
Smooks is used to transform the input XML SOAP message into the format that the external web service wants. Since wise wants it's message as JAXB-objects, the Smooks transformation is configured to instantiate the wise-generated JAXB classes.
When writing this as resource-config tags (smooks-1.0.xsd namespace), it works correctly. However, when using the much shorter and preferred jb:bean tags (javabean-1.2.xsd namespace), ClassNotFoundException occurs while deploying the .ESB service: Smooks can't find the generated classes. This makes sense, since Wise won't create them until the first request. Apparently the behaviour is quite different between the 1.0 and the 1.2 notation, while using the same Smooks runtime.
1.0 Behaviour:
- During .ESB deployment, the configuration is only parsed. No classes are loaded.
- With the first request, Wise creates JAXB sources.
- While transforming, Smooks classloads the JAXB classes.
1.2 Behaviour:
- During .ESB deployment, classes in the configuration are already classloaded. Hence, ClassNotFoundException.
===========
This is the older version of the WISE SOAPClient, released pre Smooks
v1.1 (when the extended namespace configs were introduced). So, it
probably wouldn't have been tested against the newer features in the
newer versions of Smooks i.e. may not be forward compatible.
--
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
13 years, 8 months
[JBoss JIRA] Created: (JBESB-3420) SOAPProcessor picks up wrong WSDL when two WS Endpoints with the same name are deployed via different deployments
by Magesh Kumar B (JIRA)
SOAPProcessor picks up wrong WSDL when two WS Endpoints with the same name are deployed via different deployments
-----------------------------------------------------------------------------------------------------------------
Key: JBESB-3420
URL: https://jira.jboss.org/browse/JBESB-3420
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: 4.7
Reporter: Magesh Kumar B
Fix For: 4.9 CP1
JBossWS creates deployments with the format
jboss.ws:context=foo,endpoint=fooservice
If two deployments are deployed like this
jboss.ws:context=foo1,endpoint=fooservice
jboss.ws:context=foo2,endpoint=fooservice
Then the following
<property name="jbossws-endpoint" value="fooservice"/>
will find any one of the deployment above that may not be what we intended.
The property should be changed to use the deployment name rather than just the endpoint's shortname to avoid picking up the wrong WSDL
<property name="jbossws-endpoint" value="jboss.ws:context=foo1,endpoint=fooservice"/>
--
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
13 years, 8 months
[JBoss JIRA] Created: (JBESB-880) The ESB is blocked under heavy load when using JMS
by Jiri Pechanec (JIRA)
The ESB is blocked under heavy load when using JMS
--------------------------------------------------
Key: JBESB-880
URL: http://jira.jboss.com/jira/browse/JBESB-880
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta, Transports
Affects Versions: 4.2 Milestone Release 3
Environment: RHEL 5, PostgreSQL
Reporter: Jiri Pechanec
Assigned To: Mark Little
Priority: Blocker
When the ESB is forced to process a huge batch of messages then it blocks completely.
The ESB configuration was just one service with one listener and gateway. Both gateway and listener are using JMS. The testing was executed twice using one and then four threads per listener and gateway.
The service contains two actions that serves only for message counting.
If you try to send 10000 messages sized around 20 KB it will probaly block after few minutes of processing. The ESB do not respond to TERM signal and even JMX console is not available. The only solution is to kill process violently. With the smaller messages the block does not happend or happends after bigger amount of messages.
The sender is generating following log messages
[Timer-1][BisocketServerInvoker] org.jboss.remoting.transport.bisocket.BisocketServerInvoker$ControlMonitorTimerTask@201d592a: detected failure on control connection Thread[control: Socket[addr=/10.34.34.47,port=2660,localport=51957],5,main]: requesting new control connection
We can not exclude problem in JBoss Messaging itself but when we tried to use plain JMS without ESB we were able to send/receive 300000 messages without any problem.
Moreover the more messages were processed the longer time it takes for the next batch to be processed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 8 months
[JBoss JIRA] Created: (JBESB-3470) SOAPProcessor isn't thread-safe
by Pavel Macik (JIRA)
SOAPProcessor isn't thread-safe
-------------------------------
Key: JBESB-3470
URL: https://jira.jboss.org/browse/JBESB-3470
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.9 CP1
Reporter: Pavel Macik
Priority: Blocker
The SOAPProcessor during message processing creates and destroys a subcontext named "env" which is fine when the ESB service is configured as single-threaded. But when the ESB service's action pipeline is configured as multi-threaded (maxThreads > 1) one of the following exceptions will occure:
javax.naming.NameNotFoundException: env not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
at org.jnp.server.NamingServer.unbind(NamingServer.java:349)
at org.jnp.interfaces.NamingContext.unbind(NamingContext.java:871)
at org.jnp.interfaces.NamingContext.destroySubcontext(NamingContext.java:1193)
at org.jnp.interfaces.NamingContext.destroySubcontext(NamingContext.java:1185)
at org.jboss.soa.esb.actions.soap.SOAPProcessor.process(SOAPProcessor.java:231)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:649)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:603)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:433)
at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:540)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
or
javax.naming.NameAlreadyBoundException; remaining name 'env'
at org.jnp.server.NamingServer.createSubcontext(NamingServer.java:619)
at org.jnp.interfaces.NamingContext.createSubcontext(NamingContext.java:1116)
at org.jnp.interfaces.NamingContext.createSubcontext(NamingContext.java:1096)
at org.jboss.soa.esb.actions.soap.SOAPProcessor.process(SOAPProcessor.java:229)
... 7 more
--
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
13 years, 8 months
[JBoss JIRA] Created: (JBESB-3396) ESB CEP support for multiple event streams
by David Ward (JIRA)
ESB CEP support for multiple event streams
------------------------------------------
Key: JBESB-3396
URL: https://jira.jboss.org/browse/JBESB-3396
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Configuration, Content Based Routing, Documentation, Examples
Affects Versions: 4.9
Reporter: David Ward
Assignee: David Ward
Fix For: 4.9 CP1
CEP applications often are designed to correlate messages from multiple event streams. A common example (used often the Drools CEP presentations and documentation) is a Online Trading System, which has a "Home Broker Stream" and a "Stock Trader Stream".
An Enterprise Service Bus such as JBoss ESB can provide a good architecture to support this type of CEP application. The developer could create three ESB Serivces. The first would create the Drool stateful knowledge session (and somehow publish this object to make it available for the other services), insert static facts, and call fireUntilHalt. The second service would represent the Home Broker Stream. It would receive trade requests from the Home Broker (say via a SOAP message), transform the XML into Java BuyOrderEvent objects, and insert these events into the stateful knowledge session via the Home Broker Stream entry point. The third service would be similar to the second service, except that it would handle messages from the Stock Trader, which for the sake of this example, come in as XML via a JMS transport, get transformed into Java BuyAckEvent objects and inserted into the session via the Stock Trader Stream entry point.
The rationale for having multiple services is to be able to handle different protocols and perform different transformations.
--
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
13 years, 8 months
[JBoss JIRA] Created: (JBESB-3404) Improve business_ruleservice_cep quickstart
by David Ward (JIRA)
Improve business_ruleservice_cep quickstart
-------------------------------------------
Key: JBESB-3404
URL: https://jira.jboss.org/browse/JBESB-3404
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Content Based Routing, Examples
Affects Versions: 4.9
Reporter: David Ward
Assignee: David Ward
Fix For: 4.9 CP1
The business_ruleservice_cep quickstart is a good start to an example CEP application. For example, it uses @role(event)'s and sliding time windows.
However, it could be improved in at least a couple ways:
1. Also use entry-points.
2. Re-work it so that things like classnames, test hooks and some of the overall scenario make a bit more sense for a CEP app.
--
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
13 years, 8 months