[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-3561) Registry Error When JBOSS bind to 0.0.0.0
by Anurag Debnath (JIRA)
Registry Error When JBOSS bind to 0.0.0.0
-----------------------------------------
Key: JBESB-3561
URL: https://issues.jboss.org/browse/JBESB-3561
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBoss Enterprise SOA Platform 5.0.1
Reporter: Anurag Debnath
When the server hosting ESB is started with flag -b 0.0.0.0, the UDDI
registry puts services under this address and are thus unreachable by
remote ServiceInvokers.
Tested by deploying 'HelloWorld' quickstart and examining UDDI through
the UDDI console.
* Start server with no flags. Examing UDDI registry will show service
is bound to '127.0.0.1'
* Start server with -b 123.123.123.123. UDDI registry will show service
bound to '123.123.123.123'
* Start server with -b 0.0.0.0 UDDI registry will show service bound to
'0.0.0.0' (unreachable remotely)
* Start server with -b 0.0.0.0 -Djboss.esb.bind.address=123.123.123.123
UDDI registry will show service bound to '0.0.0.0'
* Start server with -b 0.0.0.0 and JAVA_OPTS including
"jboss.esb.bind.address=123.123.123.123" UDDI registry will show service
bound to '0.0.0.0'
Proposed fix is a system property read by
org.jboss.soa.esb.helpers.NamingContextPool that specifies the desired
octet to plug into java.naming.provider.url.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 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-3353) EBWS should support Web service generation from a WSDL
by Jeff DeLong (JIRA)
EBWS should support Web service generation from a WSDL
------------------------------------------------------
Key: JBESB-3353
URL: https://jira.jboss.org/browse/JBESB-3353
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: 4.8
Reporter: Jeff DeLong
EBWS should be extended to allow the user to specify a WSDL (in lieu of a set of XSDs). The WSDL would be required to conform to certain limitations, in particular only a single operation would be allowed to be specified, and the soap: address in the wsdl:port would be overwritten to match the deployment environment.
This would support top-down service development. For example when using JBoss Savara project to generate WSDL documents from a Choregraphy model.
--
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
12 years, 8 months