[JBoss JIRA] (JBESB-3772) SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when deliverSync is succesful
by Duncan Doyle (JIRA)
Duncan Doyle created JBESB-3772:
-----------------------------------
Summary: SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when deliverSync is succesful
Key: JBESB-3772
URL: https://issues.jboss.org/browse/JBESB-3772
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta
Affects Versions: 4.10 CP1, 4.10
Environment: Fedora 16 x86_64, JBoss SOA-P 5.2.0, HornetQ TechPreview,
Reporter: Duncan Doyle
I have a number of chained async, one-way services, which all use transacted JCA (with HornetQ tech preview). I set a generic "FaultTo" EPR in a custom composer-class set on the FS-Provider of the first service (entry point into the ESB), with the intention that, if any of async, one-way services fail, the Fault Message will be sent to my FaultService.
One of my one-way services uses a SyncServiceInvoker to do a request-response call, in the middle of its action pipeline to a synchronous request-response service for message validation. The result is then used in the same pipeline to do some CBR. The problem is that, when I pass the message to the SyncServiceInvoker (which is configured to suspend the transaction), the ReplyTo and FaultTo headers get set to 'null' (as expected, as the synchronous request-response service needs to pass its reply and fault message to the caller), however, these ReplyTo and FaultTo headers never get set back to their original value if the call succeeds. In the exception flow of SyncServiceInvoker, the ReplyTo and FaultTo do get reset to their original value (with the remark that this is not actually necessary, which is wrong). So, when my CBR routes the message to the next service, the ReplyTo and FaultTo headers are null, implying that the async, one-way services will not sent a possible Fault Message to the FaultService.
In my opinion, resetting the ReplyTo and FaultTo headers needs to be done in the 'finally' block, not the 'exception' block.
--
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
[JBoss JIRA] (JBESB-3796) Exception handling after SyncServiceInvoker fails
by Jason Shepherd (JIRA)
Jason Shepherd created JBESB-3796:
-------------------------------------
Summary: Exception handling after SyncServiceInvoker fails
Key: JBESB-3796
URL: https://issues.jboss.org/browse/JBESB-3796
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta
Affects Versions: 4.10
Environment: SOA Platform 5.2.0
Reporter: Jason Shepherd
Attachments: SupportCase00634223.zip
I have an EBWS based service which is using the SyncServiceInvoker to call a second service. This all works fine but if I throw an exception after the SyncServiceInvoker call the exception is not propagated to the client as a soap fault.
However if I remove the invocation of the SyncServiceInvoker and throw an exception, a soap fault is sent to the client.
I have attached a test project which demonstrates this.
To see the fault just comment out the SyncServiceInvoker call.
--
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
[JBoss JIRA] (JBESB-3838) Http Provider returns 200 http response code for Soap Fault
by Jason Shepherd (JIRA)
Jason Shepherd created JBESB-3838:
-------------------------------------
Summary: Http Provider returns 200 http response code for Soap Fault
Key: JBESB-3838
URL: https://issues.jboss.org/browse/JBESB-3838
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 4.10
Environment: SOA-P 5.2.0
CXF WS stack
Reporter: Jason Shepherd
When a pipeline includes a SOAPProcessor action which calls a Web Service, if the wrapped web service returns a soap fault, and HTTP response code 500, the HTTP Provider Gateway returns a response code 200 to an ESB Client, instead of the expected 500 response.
This seems contrary to the WS-I 1.0 Basic Profile specification, and breaks some Spring WS Clients.
This issue does not happen with a JBR-Provider using the HTTP protocol. The expected 500 response code is returned by it.
You can use the attached project to reproduce the issue.
1. Replace the 'webservice_producer' quickstart in SOA-P 5.2 samples/quickstart directory with the one attached.
2. Run 'ant clean deploy' to deploy it to a running instance
3. Run 'ant runtest' to send a WS Request to the HTTP Provider gateway.
When I hit the GoodbyeWorldWS directly with SOAPUI I can see that I get a 500 HTTP response code. However in the output of the test, I can see the response of the HTTP Provider was 200:
runtest:
[echo] Http Client
[java] Request payload:
[java] <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:good="http://webservice_producer/goodbyeworld">
[java] <soapenv:Header/>
[java] <soapenv:Body>
[java] <good:sayGoodbye>
[java] <message>goodbye</message>
[java] </good:sayGoodbye>
[java] </soapenv:Body>
[java] </soapenv:Envelope>
[java] --------------------------
[java]
[java] 16:30:38,927 DEBUG [main][header] >> "POST /Quickstart_webservice_producer/http/test/x HTTP/1.1[\r][\n]"
[java] 16:30:38,970 DEBUG [main][header] >> "Content-Type: text/xml;charset=UTF-8[\r][\n]"
[java] 16:30:38,973 DEBUG [main][header] >> "User-Agent: Jakarta Commons-HttpClient/3.1[\r][\n]"
[java] 16:30:38,973 DEBUG [main][header] >> "Host: localhost:8080[\r][\n]"
[java] 16:30:38,973 DEBUG [main][header] >> "Content-Length: 292[\r][\n]"
[java] 16:30:38,973 DEBUG [main][header] >> "[\r][\n]"
[java] 16:30:38,973 DEBUG [main][content] >> "<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:good="http://webservice_producer/goodbyeworld">[\n]"
[java] 16:30:38,973 DEBUG [main][content] >> " <soapenv:Header/>[\n]"
[java] 16:30:38,973 DEBUG [main][content] >> " <soapenv:Body>[\n]"
[java] 16:30:38,973 DEBUG [main][content] >> " <good:sayGoodbye>[\n]"
[java] 16:30:38,973 DEBUG [main][content] >> " <message>goodbye</message>[\n]"
[java] 16:30:38,974 DEBUG [main][content] >> " </good:sayGoodbye>[\n]"
[java] 16:30:38,974 DEBUG [main][content] >> " </soapenv:Body>[\n]"
[java] 16:30:38,974 DEBUG [main][content] >> "</soapenv:Envelope>"
[java] 16:30:39,265 DEBUG [main][header] << "HTTP/1.1 200 OK[\r][\n]"
[java] 16:30:39,266 DEBUG [main][header] << "HTTP/1.1 200 OK[\r][\n]"
[java] 16:30:39,267 DEBUG [main][header] << "Server: Apache-Coyote/1.1[\r][\n]"
[java] 16:30:39,267 DEBUG [main][header] << "X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1[\r][\n]"
[java] 16:30:39,267 DEBUG [main][header] << "asyncServiceInvoke: false[\r][\n]"
[java] 16:30:39,267 DEBUG [main][header] << "Content-Length: 298[\r][\n]"
[java] 16:30:39,268 DEBUG [main][header] << "Date: Mon, 30 Jul 2012 06:30:39 GMT[\r][\n]"
[java] 16:30:39,268 DEBUG [main][header] << "[\r][\n]"
[java] 16:30:39,273 DEBUG [main][content] << "<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>app exception!</faultstring><detail><ns1:AppException xmlns:ns1="http://webservice_producer/goodbyeworld" /></detail"
[java] 16:30:39,273 DEBUG [main][content] << "></soap:Fault></soap:Body></soap:Envelope>"
[java]
[java] Response Status Code: 200
[java] Response payload:
[java] <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>app exception!</faultstring><detail><ns1:AppException xmlns:ns1="http://webservice_producer/goodbyeworld" /></detail></soap:Fault></soap:Body></soap:Envelope>
[java] --------------------------
[java]
--
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
[JBoss JIRA] (JBESB-3802) Rewrite schemas imported by SOAPProcessor to point to locally cached versions
by Jason Shepherd (JIRA)
Jason Shepherd created JBESB-3802:
-------------------------------------
Summary: Rewrite schemas imported by SOAPProcessor to point to locally cached versions
Key: JBESB-3802
URL: https://issues.jboss.org/browse/JBESB-3802
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: 4.11
Environment: JBoss Enterprise SOA-P 5.2
Reporter: Jason Shepherd
When wrapping an external webservice using SOAPProcessor, the contract is correctly published in the contract web application, see JBESB-3789. However any schema files imported by the wrapped web service are referenced on the wrapped web service, they are not cached by the ESB. Please cache a copy of the imported schemas locally, so that a client of the ESB does not have to contact the original, wrapped, web service to retrieve the schemas.
This issue will fix will also effect JBR, HTTP gateway schemas as well.
--
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
[JBoss JIRA] Created: (JBESB-3597) DLQ handling on JCA side causes duplicate redelivery to DLQ
by Toshiya Kobayashi (JIRA)
DLQ handling on JCA side causes duplicate redelivery to DLQ
-----------------------------------------------------------
Key: JBESB-3597
URL: https://issues.jboss.org/browse/JBESB-3597
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Adapters, Examples
Affects Versions: 4.9 CP1
Reporter: Toshiya Kobayashi
JCA DLQ handling interferes with JBM DLQ handling and may end up with unexpected results. You can find discussions in JBAS-7465 and JBPAPP-3352.
In ESB, you can reproduce the issue with jms_transacted quickstart.
====================
- Edit jboss-esb.xml to set dLQMaxResent=3
<property name="dLQMaxResent" value="3"/>
- ant deplpy
- ant runtest
The message will be sent to DLQ.
- Check jboss.messaging.destination:name=DLQ,service=Queue via jmx-console
You will see MessageCount=1
- Check jboss.esb.quickstart.destination:name=quickstart_jms_transacted_Request_esb,service=Queue via jmx-console
You will see MessageCount=1, DeliveringCount=1 though the message has been sent to DLQ.
- ant deploy
Redeploying the queue causes re-delivering the message to DLQ
- Check jboss.messaging.destination:name=DLQ,service=Queue via jmx-console
You will see MessageCount=2 (duplicate).
=====================
Looking at JBAS-7465 and JBPAPP-3352, there is less chance to resolve the root issue from AS/JBM side. I filed this JIRA for something we can address from ESB side.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 1 month
[JBoss JIRA] Created: (JBESB-3010) SyncServiceInvoker: Failed to send fault message in case of exception.
by Boris Belovic (JIRA)
SyncServiceInvoker: Failed to send fault message in case of exception.
----------------------------------------------------------------------
Key: JBESB-3010
URL: https://jira.jboss.org/jira/browse/JBESB-3010
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta
Affects Versions: 4.7
Reporter: Boris Belovic
I made simple service with SyncServiceInvoker action. SyncServiceInvoker is configured to fail when proxied service throws an exception. Fault message is not sent to the sender and I got this exception.
2009-11-30 08:54:55,076 DEBUG [org.jboss.soa.esb.listeners.message.ActionProcessingPipeline] (pool-41-thread-1) Unexpected exception caught while processing the action pipeline: header: [ To: JMSEpr [ PortReference < <wsa:Address jms:localhost#queue/serviceA_esb/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.initial : org.jnp.interfaces.NamingContextFactory/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : localhost/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.url.pkgs : org.jnp.interfaces/>, <wsa:ReferenceProperties jbossesb:destination-type : queue/>, <wsa:ReferenceProperties jbossesb:destination-name : queue/serviceA_esb/>, <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/serviceA_esb_reply/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : localhost/>, <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:destination-name : queue/serviceA_esb_reply/>, <wsa:ReferenceProperties jbossesb:specification-version : 1.1/>, <wsa:ReferenceProperties jbossesb:connection-factory : ConnectionFactory/>, <wsa:ReferenceProperties jbossesb:message-selector : jbossESBresponseUUID='616488c6-8ffc-4539-9237-dcaf8cebec81'/>, <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: 8d6450a3-f5f4-4c97-8656-a4c6b5836bfb RelatesTo: jms:correlationID#8d6450a3-f5f4-4c97-8656-a4c6b5836bfb ]
org.jboss.soa.esb.actions.ActionProcessingException: Error delivering message to service 'Services:ServiceB'
at org.jboss.soa.esb.actions.SyncServiceInvoker.process(SyncServiceInvoker.java:85)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:634)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:586)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:420)
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)
Caused by: org.jboss.soa.esb.couriers.FaultMessageException: org.jboss.soa.esb.actions.ActionProcessingException: This is an ActionProcessingException.
at org.jboss.soa.esb.listeners.message.errors.Factory.createExceptionFromFault(Factory.java:50)
at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.pickup(TwoWayCourierImpl.java:207)
at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.attemptDelivery(ServiceInvoker.java:675)
at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.access$200(ServiceInvoker.java:569)
at org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:359)
at org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:219)
at org.jboss.soa.esb.actions.SyncServiceInvoker.process(SyncServiceInvoker.java:77)
... 7 more
Caused by: org.jboss.soa.esb.actions.ActionProcessingException: This is an ActionProcessingException.
at org.jboss.soa.esb.samples.quickstart.syncserviceinvoker.ExceptionAction.process(ExceptionAction.java:20)
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:597)
at org.jboss.soa.esb.listeners.message.ActionProcessorMethodInfo.processMethods(ActionProcessorMethodInfo.java:102)
at org.jboss.soa.esb.listeners.message.OverriddenActionLifecycleProcessor.process(OverriddenActionLifecycleProcessor.java:74)
... 7 more
2009-11-30 08:54:55,076 DEBUG [org.jboss.soa.esb.filter.FilterManager] (pool-41-thread-1) FilterManager calling org.jboss.internal.soa.esb.message.filter.MetaDataFilter(a)594482c8.onOutput
2009-11-30 08:54:55,076 DEBUG [org.jboss.soa.esb.filter.FilterManager] (pool-41-thread-1) FilterManager calling org.jboss.internal.soa.esb.message.filter.GatewayFilter(a)20e64641.onOutput
2009-11-30 08:54:55,099 ERROR [org.jboss.soa.esb.listeners.message.ActionProcessingPipeline] (pool-41-thread-1) Failed to send fault to address JMSEpr [ PortReference < <wsa:Address jms:localhost#queue/serviceA_esb_reply/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : localhost/>, <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:destination-name : queue/serviceA_esb_reply/>, <wsa:ReferenceProperties jbossesb:specification-version : 1.1/>, <wsa:ReferenceProperties jbossesb:connection-factory : ConnectionFactory/>, <wsa:ReferenceProperties jbossesb:message-selector : jbossESBresponseUUID='616488c6-8ffc-4539-9237-dcaf8cebec81'/>, <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/> > ] for message header: [ To: JMSEpr [ PortReference < <wsa:Address jms:localhost#queue/serviceA_esb_reply/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : localhost/>, <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:destination-name : queue/serviceA_esb_reply/>, <wsa:ReferenceProperties jbossesb:specification-version : 1.1/>, <wsa:ReferenceProperties jbossesb:connection-factory : ConnectionFactory/>, <wsa:ReferenceProperties jbossesb:message-selector : jbossESBresponseUUID='616488c6-8ffc-4539-9237-dcaf8cebec81'/>, <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/> > ] From: JMSEpr [ PortReference < <wsa:Address jms:localhost#queue/serviceA_esb/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.initial : org.jnp.interfaces.NamingContextFactory/>, <wsa:ReferenceProperties jbossesb:java.naming.provider.url : localhost/>, <wsa:ReferenceProperties jbossesb:java.naming.factory.url.pkgs : org.jnp.interfaces/>, <wsa:ReferenceProperties jbossesb:destination-type : queue/>, <wsa:ReferenceProperties jbossesb:destination-name : queue/serviceA_esb/>, <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/> > ] RelatesTo: 8d6450a3-f5f4-4c97-8656-a4c6b5836bfb ]
org.jboss.soa.esb.couriers.CourierMarshalUnmarshalException: Failed to serialize ESB Message.
at org.jboss.internal.soa.esb.couriers.JmsCourier.internalDeliver(JmsCourier.java:224)
at org.jboss.internal.soa.esb.couriers.JmsCourier.deliver(JmsCourier.java:181)
at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.deliver(TwoWayCourierImpl.java:189)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.messageTo(ActionProcessingPipeline.java:861)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.faultTo(ActionProcessingPipeline.java:811)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:666)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:586)
at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:420)
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)
Caused by: java.io.IOException: Util.serialize caught XMLStreamException:
at org.jboss.soa.esb.util.Util.serialize(Util.java:198)
at org.jboss.internal.soa.esb.couriers.JmsCourier.internalDeliver(JmsCourier.java:218)
... 11 more
Caused by: javax.xml.stream.XMLStreamException
at org.jboss.internal.soa.esb.message.format.xml.marshal.MarshalUnmarshalManager.marshal(MarshalUnmarshalManager.java:149)
at org.jboss.internal.soa.esb.message.format.xml.BodyImpl.writeChildContent(BodyImpl.java:146)
at org.jboss.internal.soa.esb.util.stax.ElementContent.writeContent(ElementContent.java:41)
at org.jboss.internal.soa.esb.util.stax.StreamHelper.writeElement(StreamHelper.java:125)
at org.jboss.internal.soa.esb.message.format.xml.MessageImpl.writeChildContent(MessageImpl.java:236)
at org.jboss.internal.soa.esb.util.stax.ElementContent.writeContent(ElementContent.java:41)
at org.jboss.soa.esb.util.Util.serialize(Util.java:188)
... 12 more
--
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
12 years, 3 months
[JBoss JIRA] (JBESB-3705) Setting the context root of an ESB application
by Siamak Sadeghianfar (Created) (JIRA)
Setting the context root of an ESB application
----------------------------------------------
Key: JBESB-3705
URL: https://issues.jboss.org/browse/JBESB-3705
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Deployment
Affects Versions: 4.10, 4.9
Reporter: Siamak Sadeghianfar
Priority: Minor
Currently an ESB application is deployed at a context root the same as the application name. For example app.esb is deployed at /app. This causes problem when used with maven since artifacts are usually in form of app-1.x.x.esb.
It should be possible to customize the context root of an esb application through a descriptor, rather than enforcing the archive name. For example in jboss-esb.xml:
{code:xml}
<jbossesb>
*<context-root>/app</context-root>*
<services>
...
<services>
</jbossesb>
{code}
--
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, 3 months