[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
[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
[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
[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