esb-issues April 2011

esb-issues@lists.jboss.org

1 participants
55 discussions

[JBoss JIRA] Created: (JBESB-3316) jBPM JCA inflow need to support JMSProviderAdapter

by Kevin Conner (JIRA)

jBPM JCA inflow need to support JMSProviderAdapter -------------------------------------------------- Key: JBESB-3316 URL: https://jira.jboss.org/jira/browse/JBESB-3316 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.4 CP3 Reporter: Kevin Conner This is to allow the initial context to be provided by an adapter rather than defaulting to the server values. -- 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

13 years

2
2
0 / 0

[JBoss JIRA] Created: (JBESB-3598) Remove redundant calls to product/rosetta/src/org/jboss/internal/soa/esb/rosetta/pooling/SessionExecutorInit.java

by Julian Coleman (JIRA)

Remove redundant calls to product/rosetta/src/org/jboss/internal/soa/esb/rosetta/pooling/SessionExecutorInit.java ----------------------------------------------------------------------------------------------------------------- Key: JBESB-3598 URL: https://issues.jboss.org/browse/JBESB-3598 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.4 CP5 Environment: SOA 4.3.0 CP05 ER1 Reporter: Julian Coleman Fix For: 4.4 CP5 Changes to messaging from version 1.4.0.SP3.CP04 removed the need to have a workaround for non-daemon threads, by ensuring that all created threads are daemon threads. See: .../src/main/org/jboss/messaging/util/JBMThreadFactory.java in: http://fisheye.jboss.org/changelog/Messaging?cs=4937 for details of the change. org/jboss/internal/soa/esb/rosetta/pooling/SessionExecutorInit.java can now be removed along with any calls to it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

2
2
0 / 0

[JBoss JIRA] Created: (JBESB-3599) HttpRouter action does not propagate exceptions (cloned)

by Tom Cunningham (JIRA)

HttpRouter action does not propagate exceptions (cloned) -------------------------------------------------------- Key: JBESB-3599 URL: https://issues.jboss.org/browse/JBESB-3599 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Affects Versions: 4.6 Reporter: Aaron Pestel Assignee: David Ward Fix For: 4.7 In the process() method of org/jboss/soa/esb/actions/routing/http/HttpRouter.java, lines 140 and 148, it eats exceptions and logs them to stderr. This causes the action chain to continue as if no error occurred. It seems these exceptions should get propagated up. Here's the use case. Create ESB WS Proxy scenario. Client invokes ESB, ESB action invokes HttpRouter action, HttpRouter action is pointing to an endpointUrl that is invalid, instead of propagating the exception up to the ESB service, it eats the exception and continues processing. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

1
3
0 / 0

[JBoss JIRA] Created: (JBESB-3589) SOAP Header data from SOAPMessageContext in JAXWS Handlers.

by CYRIL GERBIER (JIRA)

SOAP Header data from SOAPMessageContext in JAXWS Handlers. ------------------------------------------------------------ Key: JBESB-3589 URL: https://issues.jboss.org/browse/JBESB-3589 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Affects Versions: 4.7 CP2 Environment: Release ID: JBoss [SOA] 5.0.2.GA_SOA (build: SVNTag=5.0.2.GA_SOA date=201006221603) java version "1.6.0_07" Java(TM) SE Runtime Environment (build 1.6.0_07-b06) Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing) Reporter: CYRIL GERBIER I would like to add some JAXWS handlers in web services SOAP. I am using JBOSS SOAP 5.0.2.GA_SOA release (see boot.log for more details). I made a sample based on webservice_wsaddressing quickstart samples (samples\quickstarts\webservice_wsaddressing): - for WSAClient, I added a new JAXWS handler (MyClientHandler extends SOAPHandler<SOAPMessageContext>). This one adds context data in SOAPHeader from xml marshalled by JAXB. - for StatefulEndpointImpl, I added a new JAXWS handler (MyServerHandler implements SOAPHandler<SOAPMessageContext>). This one reads xml context data in SOAPHeader and give an context object from JAXB. This system works fine with JBOSS AS 4.2 and CXF stack. But using, JBOSS SOAP 5.0.2.GA and native JBossws stack, I encountered severals problems: - on client side, data are not correctly sent : hereafter a sample of HTTP SOAP Request sent : <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header xmlns:wsa="http://www.w3.org/2005/08/addressing"> <cv:ContextVersion xmlns:cv="http://si.msa.fr/GestionnaireEchangesInternes/SOA/AppelServices">1.0</cv:ContextVersion> <ns2:MDWTargetContext xmlns:ns2="http://si.msa.fr/GestionnaireEchangesInternes/SOA/AppelServices/Objets/Re..."/> <wsa:To>uri:jaxrpc-samples-wsaddressing/TestService</wsa:To> <wsa:ReplyTo> <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address> <wsa:ReferenceParameters> <ns1:clientid xmlns:ns1="http://somens">clientid-2</ns1:clientid> </wsa:ReferenceParameters> </wsa:ReplyTo> <wsa:Action>http://org.jboss.ws/addressing/stateful/action</wsa:Action> <wsa:MessageID>urn:uuid:6f521ca2-fa85-49a7-9f1f-f9719237629e</wsa:MessageID> </env:Header> <env:Body> <ns1:getItems xmlns:ns1="http://webservice.webservicewsa.quickstart.samples.esb.soa.jboss.org/"/> </env:Body> </env:Envelope> We can see that MDWTargetContext has no data when marshalling in SOAPHeader (just xml structure) whereas it is correct when marshalling in System.out: <MDWTargetContext xmlns="http://si.msa.fr/GestionnaireEchangesInternes/SOA/AppelServices/Objets/Re..."> <CORGAMO>021</CORGAMO><DPT>82</DPT><ED>E</ED><ND>N</ND></MDWTargetContext> - on server side, when I send a manually a correct request (because of issue on client) : <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header xmlns:wsa="http://www.w3.org/2005/08/addressing"> <cv:ContextVersion xmlns:cv="http://si.msa.fr/GestionnaireEchangesInternes/SOA/AppelServices">1.0</cv:ContextVersion> <ns2:MDWTargetContext xmlns:ns2="http://si.msa.fr/GestionnaireEchangesInternes/SOA/AppelServices/Objets/Re..."> <ns2:CORGAMO>021</ns2:CORGAMO> <ns2:DPT>82</ns2:DPT> <ns2:ED>E</ns2:ED> <ns2:ND>N</ns2:ND> </ns2:MDWTargetContext> <wsa:To>uri:jaxrpc-samples-wsaddressing/TestService</wsa:To> <wsa:ReplyTo> <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address> <wsa:ReferenceParameters> <ns1:clientid xmlns:ns1="http://somens">clientid-2</ns1:clientid> </wsa:ReferenceParameters> </wsa:ReplyTo> <wsa:Action>http://org.jboss.ws/addressing/stateful/action</wsa:Action> <wsa:MessageID>urn:uuid:6f521ca2-fa85-49a7-9f1f-f9719237629e</wsa:MessageID> </env:Header> <env:Body> <ns1:getItems xmlns:ns1="http://webservice.webservicewsa.quickstart.samples.esb.soa.jboss.org/"/> </env:Body> </env:Envelope> datas from ns2:MDWTargetContext are correctly unmarshalled, by I can't read ContextVersion data : node is found but getTextContent returns null: 17:34:15,953 INFO [MyServerHandler] Fournisseur : Request message 17:34:15,984 INFO [MyServerHandler] ContextVersion : 17:34:15,984 INFO [MyServerHandler] TargetContext : ED E 17:34:15,984 INFO [MyServerHandler] TargetContext : ND N 17:34:15,984 INFO [MyServerHandler] TargetContext : CORGAMO 021 17:34:15,984 INFO [MyServerHandler] TargetContext : DPT 82 Can you help me to solve this problem : - to send xml context data from client in SOAP Header - to receive correcly ContextVersion (why getTextContext returns null). I attach quickstart sample in order to reproduce the problem. Please copy it to quickstart sample directory and type "ant deploy" to deploy esb archive and "ant runtest" to test from client. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

2
7
0 / 0

[JBoss JIRA] Created: (JBESB-3582) SOA-P 5.1.0 classloader caching issues with embedded jar artifacts

by Dave Siracusa (JIRA)

SOA-P 5.1.0 classloader caching issues with embedded jar artifacts ------------------------------------------------------------------ Key: JBESB-3582 URL: https://issues.jboss.org/browse/JBESB-3582 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment Affects Versions: 5.0 Milestone Release 1 Environment: Windows 7 Reporter: Dave Siracusa An existing .ESB file with embedded jar artifact ends up being used for subsequently deployed .ESB applications even if the second ESB contains a newer/different version of the embedded jar artifact. If you repeatly redeploy the first and the second, eventually the ESB file fails to deploy due to duplicate class issues. SOA-P 5.0.0/1/2 does not behave this way as the VFSClassloader uniquely captures each artifact in the tmp vsf folder. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

4
13
0 / 0

← Newer
1
2
3
4
5
6
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues April 2011