June 2010 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-3342) null Camel header triggers IllegalArgumentException in CamelMessageComposer

by David Ward (JIRA)

null Camel header triggers IllegalArgumentException in CamelMessageComposer --------------------------------------------------------------------------- Key: JBESB-3342 URL: https://jira.jboss.org/browse/JBESB-3342 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta, Transports Affects Versions: 4.9 Reporter: David Ward Assignee: David Ward Fix For: 4.9 If the incoming Camel Message has a null header value, then when trying to set it as an ESB Message property will trigger an IllegalArgumentException, like so: 15:48:28,174 ERROR [DefaultErrorHandler] Failed delivery for exchangeId: 3b0371eb-076f-4f14-9635-3245ff547f2f. Exhausted after delivery attempt: 1 caught: java.lang.IllegalArgumentException: null 'value' arg in method call. java.lang.IllegalArgumentException: null 'value' arg in method call. at org.jboss.internal.soa.esb.assertion.AssertArgument.isNotNull(AssertArgument.java:43) at org.jboss.internal.soa.esb.message.format.xml.PropertiesImpl.setProperty(PropertiesImpl.java:74) at org.jboss.soa.esb.listeners.gateway.camel.CamelMessageComposer.populateMessage(CamelMessageComposer.java:61) at org.jboss.soa.esb.listeners.gateway.camel.CamelMessageComposer.populateMessage(CamelMessageComposer.java:41) at org.jboss.soa.esb.listeners.message.AbstractMessageComposer.compose(AbstractMessageComposer.java:76) at org.jboss.soa.esb.listeners.gateway.camel.ServiceProcessor.process(ServiceProcessor.java:48) at org.apache.camel.impl.ProcessorEndpoint.onExchange(ProcessorEndpoint.java:95) The CamelMessageComposer should check for null values and not set them as properties. -- 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

15 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBESB-3341) Upgrade Camel from 2.2.0 to 2.3.0

by David Ward (JIRA)

Upgrade Camel from 2.2.0 to 2.3.0 --------------------------------- Key: JBESB-3341 URL: https://jira.jboss.org/browse/JBESB-3341 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Rosetta, Transports Affects Versions: 4.9 Reporter: David Ward Assignee: David Ward Fix For: 4.9 Camel 2.3.0 has 276 bug fixes since 2.2.0. Let's make sure we get those fixes before we release ESB 4.9 with the new CamelGateway. -- 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

15 years, 10 months

1
5
0 / 0

[JBoss JIRA] Created: (JBESB-3330) XsltAction cannot find maxThreads in parent configuration

by Leon Doud (JIRA)

XsltAction cannot find maxThreads in parent configuration --------------------------------------------------------- Key: JBESB-3330 URL: https://jira.jboss.org/browse/JBESB-3330 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.8 Environment: JBoss ESB 4.8 JBoss App Server 4.2.3 Windows Vista Java 5 Reporter: Leon Doud XsltAction fails to find required maxThreads attribute in the parent configuration. An exception is thrown from line 460 of the XsltAction.java file that the required attribute "maxThreads" is not found. Use of the debugger shows the parent configuration variable local to the method is not null. The XsltAction is used in a service where the only listener is a scheduled listener. The event processor for the scheduled listener is a message composer. Related discussion thread: https://community.jboss.org/message/544665#544665 More details and a sample to recreate the issue will be added later. -- 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

15 years, 10 months

3
7
0 / 0

[JBoss JIRA] Created: (JBESB-1553) SOAPClient action remappes objects with null strings to empty strings

by Jiri Pechanec (JIRA)

SOAPClient action remappes objects with null strings to empty strings --------------------------------------------------------------------- Key: JBESB-1553 URL: http://jira.jboss.com/jira/browse/JBESB-1553 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Affects Versions: 4.2.1 CP1 Reporter: Jiri Pechanec Assigned To: Kevin Conner Fix For: 4.2.1 CP2 Use webservice_consumer2 quickstart and use the attached files - contains enhanced equals and toString defintions. Make sure that option1 is used. The object with following contents is sent to processing to ivoke web service id = 101 lineItems = [Line Item ID= 1 Price=10.0 Ship To=aname, Line Item ID= 2 Price=20.0 Ship To=aname2] shipTo = null But in the web service processing method the contents is id = 101 lineItems = [Line Item ID= 1 Price=10.0 Ship To=aname, Line Item ID= 2 Price=20.0 Ship To=aname2] shipTo = The difference is in shipTo property which was set tu null on the input but comes to web service as empty string. -- 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

15 years, 10 months

5
21
0 / 0

[JBoss JIRA] Created: (JBESB-3088) Wrong Parameter Name for soapUI SOAP Client Action

by Fernando Ribeiro (JIRA)

Wrong Parameter Name for soapUI SOAP Client Action -------------------------------------------------- Key: JBESB-3088 URL: https://jira.jboss.org/jira/browse/JBESB-3088 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.7 Reporter: Fernando Ribeiro On page 128 of the Programmers Guide, "operation" is mistaken by "SOAPAction", which is at http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/services/.... -- 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

15 years, 10 months

3
3
0 / 0

[JBoss JIRA] Created: (JBESB-3177) In FtpImpl.java also setSoTimeout(_timeout); in initialize(boolean bConnect)

by jarkko Lietolahti (JIRA)

In FtpImpl.java also setSoTimeout(_timeout); in initialize(boolean bConnect) ---------------------------------------------------------------------------- Key: JBESB-3177 URL: https://jira.jboss.org/jira/browse/JBESB-3177 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.7 Reporter: jarkko Lietolahti Currently FtpImpl.java (and the others) only set DataTimeout on m_oConn. We're seeing firewall issues where this is not enough and we need SoTimeout for the socket in order to avoid infinite waiting during __getReply(); So also call m_oConn.setSoTimeout(_timeout); Aka; if (_timeout > 0) { m_oConn.setDataTimeout(_timeout); // added by jarkko lietolahti, 9.2.2010 to address hanging replies from server m_oConn.setSoTimeout(_timeout); } -- 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

15 years, 10 months

4
7
0 / 0

[JBoss JIRA] Created: (JBESB-2905) FtpImpl timeout global and not always respected

by Tom Eicher (JIRA)

FtpImpl timeout global and not always respected ----------------------------------------------- Key: JBESB-2905 URL: https://jira.jboss.org/jira/browse/JBESB-2905 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.6, 4.5 Reporter: Tom Eicher org.jboss.internal.soa.esb.util.FtpImpl does look for a property org.jboss.soa.esb.ftp.timeout in jbossesb.sar/jbossesb-properties.xml, however: it does so only in 1 out of 3 constructors! ;-) code "String timeout = ModulePropertyManager..." should be moved from the "public FtpImpl (FTPEpr p_oP)" to the "protected void initialize (boolean bConnect)". other parameters in the 3 constructor should also be checked if they are respected in all three cases. Also: - "infinite" is not so good a default, as the thread will hang forever in case of firewall issues (I have one 48hrs old now ;-) even a ridiculous long one like 6hrs woule be better...("_timeout = 0;" in 2 places) - please add "<property name="org.jboss.soa.esb.ftp.timeout" value="60000"/>" to the default jbossesb-properties.xml so that people may know that this setting exists - please also allow configuration of timeout from ConfigTree (method "checkParams()" and Constant in "RemoteFileSystem") and from FileEpr. (and then add to doc ;-) Cheers & kind regards, Tom. -- 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

15 years, 10 months

5
6
0 / 0

[JBoss JIRA] Created: (JBESB-3320) In FtpImpl.java also setSoTimeout(_timeout); in initialize(boolean bConnect)

by Kevin Conner (JIRA)

In FtpImpl.java also setSoTimeout(_timeout); in initialize(boolean bConnect) ---------------------------------------------------------------------------- Key: JBESB-3320 URL: https://jira.jboss.org/jira/browse/JBESB-3320 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.7 Reporter: jarkko Lietolahti Fix For: 4.9 Currently FtpImpl.java (and the others) only set DataTimeout on m_oConn. We're seeing firewall issues where this is not enough and we need SoTimeout for the socket in order to avoid infinite waiting during __getReply(); So also call m_oConn.setSoTimeout(_timeout); Aka; {code} if (_timeout > 0) { m_oConn.setDataTimeout(_timeout); // added by jarkko lietolahti, 9.2.2010 to address hanging replies from server m_oConn.setSoTimeout(_timeout); } {code} The hanging occurs in org.apache.commons.net.ftp.FTP.__getReply() in line String line = _controlInput_.readLine(); The readLine() will hang forever if the server/firewall is blocking/etc fails to send reply through the control channel. There's also FTP.setDefaultTimeout (http://commons.apache.org/net/api/org/apache/commons/net/SocketClient.htm...) maybe we should set it also? Or maybe we need three different configuration parameters. -- 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

15 years, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (JBESB-3259) SOAP Invocation selects the first (wrong) endpoint

by Kurt Stam (JIRA)

SOAP Invocation selects the first (wrong) endpoint -------------------------------------------------- Key: JBESB-3259 URL: https://jira.jboss.org/jira/browse/JBESB-3259 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Affects Versions: 4.7 Reporter: Kurt Stam This issue was discovered when running the "webservice_esb_bpel" quickstart which is part of the RiftSaw codebase. This quickstart is based on the ActiveBPEL quickstart, and it may make sense to move this quickstart from the RiftSaw codebase into the JBossESB codebase. In the final step notificationStep the MBeanSoapUIInvoker.getEndpoint(String wsdl, Properties httpClientProps) seems to simply pick the *first* endpoint, which is not the right one.. For more details please see: https://jira.jboss.org/jira/browse/RIFTSAW-192 -- 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

15 years, 10 months

3
12
0 / 0

[JBoss JIRA] Created: (JBESB-3084) Customize Context Root of HTTP Gateway

by Fernando Ribeiro (JIRA)

Customize Context Root of HTTP Gateway -------------------------------------- Key: JBESB-3084 URL: https://jira.jboss.org/jira/browse/JBESB-3084 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.7 Reporter: Fernando Ribeiro It would be nice to be able to customize the context root in jboss-esb.xml, just like in jboss-web.xml. http://fernandoribeiro.eti.br/2009/09/13/how-to-change-the-context-root-i... -- 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

15 years, 10 months

3
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues June 2010