[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, 4 months
[JBoss JIRA] Created: (JBESB-3128) http_gateway synchronousTimeout - operates twice as slow as expected the first time it is encountered by a service
by Len DiMaggio (JIRA)
http_gateway synchronousTimeout - operates twice as slow as expected the first time it is encountered by a service
------------------------------------------------------------------------------------------------------------------
Key: JBESB-3128
URL: https://jira.jboss.org/jira/browse/JBESB-3128
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Process flow
Affects Versions: 4.7
Environment: 4.7 GA
Reporter: Len DiMaggio
I'm seeing a very odd problem with the ESB's http_gateway synchronousTimeout property.
Briefly - the timer operates 100% slower than it should - but only the first time the timer is invoked for deployed .esb archive. This is reproducible at will with ESB 4.7 and SOA-P 5.0 ER7.
After experimenting with this - the delay seems to be on a per-service basis - in other words, the first time a service that hits synchronousTimeout, the timeout operates twice as slow as it should. Starting with the second time that a service encounters a synchronousTimeout, the timeout operates as expected.
I'm seeing this with the default synchronousTimeout value, and if the value is defined in the service definition in jboss-esb.xml
========================================
A modified version of the http_gateway quickstart is attached to demonstrate the problem. The modifications are:
* A new action class (my40secAction) is added - this class is identical to myAction, except that it introduces a 40 seconde delay.
* A modified jboss-esb.xml file - the Sales:List service is modified to have a 10 second synchronousTimeout, and the action invokes the My40secAction class - and a second service (SlowSales) is added - this service is a clone of Sales:List:
<service category="Sales" name="List" description="" invmScope="GLOBAL">
<listeners>
<!-- Receives: http://<host>:<port>/Quickstart_http_gateway/http/sales/* but will be forced to
authenticate because the "sales" bus has basic auth configured (above)... -->
<http-gateway name="sales" busidref="secureFriends" urlPattern="sales/*"> <property name="synchronousTimeout" value="10000"/> </http-gateway>
</listeners>
<actions mep="RequestResponse">
<action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.My40secAction"/>
</actions>
</service>
<service category="SlowSales" name="SlowList" description="" invmScope="GLOBAL">
<listeners>
<!-- Receives: http://<host>:<port>/Quickstart_http_gateway/http/sales/* but will be forced to
authenticate because the "sales" bus has basic auth configured (above)... -->
<http-gateway name="slowsales" busidref="secureFriends" urlPattern="slowsales/*"> <property name="synchronousTimeout" value="10000"/> </http-gateway>
</listeners>
<actions mep="RequestResponse">
<action name="print" class="org.jboss.soa.esb.samples.quickstart.httpgateway.My40secAction"/>
</actions>
</service>
========================================
Here's an example of the behavior I'm seeing:
Test run #1 - approx 20 sec - unexpected as the test is configured for 10 sec timeout
[ldimaggi@ldimaggi http_gateway]$ date;lynx -dump -source -auth=kermit:thefrog http://localhost:8080/Quickstart_http_gateway/http/sales/a/b/c; date
Fri Jan 15 15:52:47 EST 2010
<html><head><title>JBoss Web/2.1.3 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 500 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Exception report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The server encountered an internal error () that prevented it from fulfilling this request.</u></p><p><b>exception</b> <pre>javax.servlet.ServletException: Failed to deliver message.
org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:215)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
</pre></p><p><b>root cause</b> <pre>org.jboss.soa.esb.listeners.message.ResponseTimeoutException: No response received for service [Sales:List].
org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:427)
org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:219)
org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:187)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
</pre></p><p><b>note</b> <u>The full stack trace of the root cause is available in the JBoss Web/2.1.3 logs.</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/2.1.3</h3></body></html>Fri Jan 15 15:53:07 EST 2010
Then - immediately follows test run #2 - approx 10 seconds - this is what I would have expected
[ldimaggi@ldimaggi http_gateway]$ date;lynx -dump -source -auth=kermit:thefrog http://localhost:8080/Quickstart_http_gateway/http/sales/a/b/c; date
Fri Jan 15 15:53:14 EST 2010
<html><head><title>JBoss Web/2.1.3 - Error report</title><style><!--H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}HR {color : #525D76;}--></style> </head><body><h1>HTTP Status 500 - </h1><HR size="1" noshade="noshade"><p><b>type</b> Exception report</p><p><b>message</b> <u></u></p><p><b>description</b> <u>The server encountered an internal error () that prevented it from fulfilling this request.</u></p><p><b>exception</b> <pre>javax.servlet.ServletException: Failed to deliver message.
org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:215)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
</pre></p><p><b>root cause</b> <pre>org.jboss.soa.esb.listeners.message.ResponseTimeoutException: No response received for service [Sales:List].
org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:427)
org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:219)
org.jboss.soa.esb.listeners.gateway.http.HttpGatewayServlet.service(HttpGatewayServlet.java:187)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
</pre></p><p><b>note</b> <u>The full stack trace of the root cause is available in the JBoss Web/2.1.3 logs.</u></p><HR size="1" noshade="noshade"><h3>JBoss Web/2.1.3</h3></body></html>Fri Jan 15 15:53:25 EST 2010
--
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, 5 months
[JBoss JIRA] Created: (JBESB-3157) Feature request - consistent requirement for URL char encoding between ftp gateway and notifier
by Len DiMaggio (JIRA)
Feature request - consistent requirement for URL char encoding between ftp gateway and notifier
-----------------------------------------------------------------------------------------------
Key: JBESB-3157
URL: https://jira.jboss.org/jira/browse/JBESB-3157
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Rosetta
Affects Versions: 4.7
Reporter: Len DiMaggio
Priority: Minor
We're inconsistent with how we handle special characters between ftp gateway listener definitions and ftp notifier definitions - it would make it simpler for users if we handled these in the same way.
For example, to use a directory of "ftp_dir##" and a password of "password##:
FTP gateway listener:
<ftp-provider hostname="servername.com" name="FTPprovider">
<ftp-bus busid="notifyFTPChannel">
<ftp-message-filter directory="/ftp_dir##"
error-delete="false" error-suffix=".HAS_ERROR"
input-suffix=".notifiertest" passive="true"
password="password##" post-delete="false"
post-suffix=".COMPLETE" username="username"
work-suffix=".esbWorking" />
</ftp-bus>
</ftp-provider>
FTP: notifier:
<action class="org.jboss.soa.esb.actions.Notifier" name="notify">
<property name="okMethod" value="notifyOK" />
<property name="notification-details">
<NotificationList type="OK">
<target class="NotifyFTP">
<ftp
URL="ftp://username:password%23%23@servername.com/ftp_dir%23%23"
filename="{jbossesb.message.id}.notifier"
passive="true" />
</target>
</NotificationList>
</property>
</action>
--
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, 7 months
[JBoss JIRA] Created: (JBESB-2460) BinarySecurityToken class hardwired to X.509 certificates
by Rune Molin (JIRA)
BinarySecurityToken class hardwired to X.509 certificates
---------------------------------------------------------
Key: JBESB-2460
URL: https://jira.jboss.org/jira/browse/JBESB-2460
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: 4.5
Reporter: Rune Molin
In order to support WS Security Kerberos Token Profile at a later time, please make the class org.jboss.soa.esb.services.security.auth.ws.BinarySecurityToken abstract. Currently it is hardwired to only support X.509 Certificate Token Profile.
By making this class abstract sooner rather than later, users could implement Kerberos Token Profile themselves, without having to duplicate too much code. This will of course mean moving the existing certificate bound implementation into a new class, CertificateSecurityToken perhaps
--
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, 9 months
[JBoss JIRA] Created: (JBESB-3022) It is not possible to use different credentials on the input of the service and on the SOAPProxy that invokes the proxied service
by Jiri Pechanec (JIRA)
It is not possible to use different credentials on the input of the service and on the SOAPProxy that invokes the proxied service
---------------------------------------------------------------------------------------------------------------------------------
Key: JBESB-3022
URL: https://jira.jboss.org/jira/browse/JBESB-3022
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: 4.7
Reporter: Jiri Pechanec
Attachments: soapproxy-diffauth.zip
There is a use case - I have a secured ESB service using HTTPS/BASIC auth invoking invoking secured HTTPS/BASIC auth web service via SOAPProxy. If the credentials are passed from the client then everything works correctly. But if I have different credentials required for ESB client and different credentials are required by proxied Web Service then I use property <property name="clientCredentialsRequired" value="false" /> to set static credentials for proxied web service.
This property works correctly if the ESB service is unsecured. Unfortunately if it is secured then probably the credentials stored in HTTP header stored in ESB message overwrites the static credentials set by the SOAPProxy action.
The attached example is modified webservice_proxy_secure QS and has static credentials set to wrong values - so proxied web service should not be invoked. But if ant runtest is executed then the wrong credentials are not used.
--
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, 10 months