May 2010 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-2981) Support textual file contents in file and remote gateways

by Kevin Conner (JIRA)

Support textual file contents in file and remote gateways --------------------------------------------------------- Key: JBESB-2981 URL: https://jira.jboss.org/jira/browse/JBESB-2981 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.7 Reporter: Kevin Conner Fix For: 4.8 The current implementation of these gateways generates the contents of the message as a byte[], as they must assume that they are binary. We should add the ability to create textual representations, instead of binary ones, by converting the byte[] to a String using a specified character set. -- 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

14 years, 6 months

4
5
0 / 0

[JBoss JIRA] Created: (JBESB-3017) jboss-esb.xml schema location fix

by Tom Eicher (JIRA)

jboss-esb.xml schema location fix --------------------------------- Key: JBESB-3017 URL: https://jira.jboss.org/jira/browse/JBESB-3017 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Deployment, Documentation, Examples Affects Versions: 4.6, 4.5 Reporter: Tom Eicher 1. All jboss-esb.xml still point to http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml... where nowadays it should be http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/etc/schem... 2. shouldn't we use version 1.1.0 now ? 3. please include a xsi:schemaLocation xsi:schemaLocation="http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/etc/schem... http://anonsvn.jboss.org/repos/labs/labs/jbossesb/trunk/product/etc/schem..."> Cheers, 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

14 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (JBESB-3082) Optional Parameter in XsltAction

by Fernando Ribeiro (JIRA)

Optional Parameter in XsltAction -------------------------------- Key: JBESB-3082 URL: https://jira.jboss.org/jira/browse/JBESB-3082 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Fernando Ribeiro The resultType parameter should really be optional, as described in the documentation. <action name="action1" class="org.jboss.soa.esb.actions.transformation.xslt.XsltAction"> <property name="templateFile" value="/xsl/Stylesheet1.xsl" /> </action> .. gives me an error saying resultType needs to be there. -- 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

14 years, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (JBESB-3081) Error in Documentation of XsltAction

by Fernando Ribeiro (JIRA)

Error in Documentation of XsltAction ------------------------------------ Key: JBESB-3081 URL: https://jira.jboss.org/jira/browse/JBESB-3081 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.7 Reporter: Fernando Ribeiro On page 98 of the Programmers Guide, it says "XslAction" instead of "XsltAction". -- 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

14 years, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (JBESB-3234) NotifyTCP assumes payload is characher based

by Tom Fennelly (JIRA)

NotifyTCP assumes payload is characher based -------------------------------------------- Key: JBESB-3234 URL: https://jira.jboss.org/jira/browse/JBESB-3234 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.7 Reporter: Tom Fennelly Priority: Minor Fix For: 4.9 org.jboss.soa.esb.notification.NotifyTCP assumes the message payload is a String (explicitly, or encoded as a byte[]). No need to make such a restrictive assumption. If it's a byte payload, just send it out onto the target socket as raw bytes - will work for any encoded payload type then. -- 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

14 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (JBESB-3138) Usename token authentication does not work

by Jiri Pechanec (JIRA)

Usename token authentication does not work ------------------------------------------ Key: JBESB-3138 URL: https://jira.jboss.org/jira/browse/JBESB-3138 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.7 Reporter: Jiri Pechanec Priority: Critical If security is enable on service and SOAP message with Username token is sent then server throws SecurityException 12:45:40,293 ERROR [ActionProcessingPipeline] SecurityService exception : org.jboss.soa.esb.services.security.SecurityServiceException: Service 'MyWSProducerService' has been configured for security but no AuthenticationRequest could be located in the Message Context. Cannot authenticate without an AuthenticationRequest. at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:527) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:419) at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:540) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) -- 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

14 years, 6 months

4
11
0 / 0

[JBoss JIRA] Created: (JBESB-2270) Provide an alternative for bean configured action

by Kevin Conner (JIRA)

Provide an alternative for bean configured action ------------------------------------------------- Key: JBESB-2270 URL: https://jira.jboss.org/jira/browse/JBESB-2270 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.4 Reporter: Kevin Conner Fix For: 4.x The bean configured action code has a number of deficiencies which include the following - instantiation of the action per message - no support for standard callbacks (including lifecycles) We should create an alternative which creates a single instance of the action, configures properties through reflection and also supports the standard callback methods. -- 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

14 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (JBESB-3329) Add CamelGateway capability

by David Ward (JIRA)

Add CamelGateway capability --------------------------- Key: JBESB-3329 URL: https://jira.jboss.org/browse/JBESB-3329 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Configuration, Documentation, Examples, Rosetta, Transports Affects Versions: 4.9 Reporter: David Ward Assignee: David Ward Fix For: 4.9 Add the CamelGateway capability as agreed upon in the JBossESB Developer Forum. -- 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

14 years, 6 months

1
4
0 / 0

[JBoss JIRA] Created: (JBESB-3193) Transform of bindings-jboss-beans.xml modifies it in a manner inconsistent with purpose of file

by Ryan Hochstetler (JIRA)

Transform of bindings-jboss-beans.xml modifies it in a manner inconsistent with purpose of file ----------------------------------------------------------------------------------------------- Key: JBESB-3193 URL: https://jira.jboss.org/jira/browse/JBESB-3193 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Deployment Affects Versions: 4.7 Reporter: Ryan Hochstetler The bindings-jboss-beans.xml and contained ServiceBindingManagerstore is a huge step forward in reducing the duplication of network interface and port binding information for all network-facing services within JBoss. The JBoss ESB 4.7 installer modifies the stock bindings-jboss-beans.xml in order to take advantage of the ServiceBindingManager. jbossesb-properties.xml, and another config the name of which i cannot recall) is put through an XSLT transform to substitute the JNDI interface and port for the property org.jboss.soa.esb.jndi.server.url Unfortunately, doing this in this manner adds a duplication of the JNDI port information to the very file which is intended to eliminate duplication of such information. Instead: Have the transform assign a name to the ServiceBindingMetadata bean for the naming service. <bean name="NamingServiceBindingMetatdata" class="org.jboss.services.binding.ServiceBindingMetadata"> <property name="serviceName">jboss:service=Naming</property> <property name="bindingName">Port</property> <property name="port">7099</property> <property name="description">The listening socket for the Naming service</property> </bean> Then, inject this value into your own configuration using a value-factory: <bean class="org.jboss.services.binding.ServiceBindingMetadata"> <property name="serviceName">EsbPropertyService</property> <property name="port"> <value-factory bean="NamingServiceBindingMetatdata" method="getPort" /> </property> <property name="description">Will process jbossesb-properties using xslt to support substituion of configuration properties.</property> <property name="serviceBindingValueSourceConfig"> <inject bean="EsbPropertyServiceXSLTConfig"/> </property> </bean> This is the quick-fix solution. There's probably an even better way to do this, but I'm out of time to figure it out. -- 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

14 years, 6 months

3
6
0 / 0

[JBoss JIRA] Created: (JBESB-2574) OGNLUtils.assertIsCollection fails

by jarkko Lietolahti (JIRA)

OGNLUtils.assertIsCollection fails ---------------------------------- Key: JBESB-2574 URL: https://jira.jboss.org/jira/browse/JBESB-2574 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.5 Reporter: jarkko Lietolahti The method private static boolean assertIsCollection(Element element) { if(element.getAttributeNS(JBOSSESB_SOAP_NS, IS_COLLECTION_ATTRIB).equals("true")) { // It's already been attributed... no need to check for the soapui comment... return true; } Comment firstComment = (Comment) YADOMUtil.getFirstChildByType(element, Node.COMMENT_NODE); // TODO: Get Ole (soapUI) to add an attribute to the collection element - better than looking for this comment. if(firstComment != null && firstComment.getTextContent().indexOf("1 or more repetitions") != -1) { return true; } return false; } Especially row; Comment firstComment = (Comment) YADOMUtil.getFirstChildByType(element, Node.COMMENT_NODE); is causing a grief. Given an WSDL like below; <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" > <soapenv:Header/> <soapenv:Body> <QueryRequest> <username>?</username> <password>?</password> <Customer id="?" telcoid="?"> </Customer>  <productIds>?</productIds> <isLookup>?</isLookup> <maxWaitTime>?</maxWaitTime> </QueryRequest> </soapenv:Body> </soapenv:Envelope> OGNLUtils creates ognlExpression QueryRequest[0] for all the elements below QueryRequest. E.g. ognl for username, password etc is "QueryRequest[0]" when in reality it should be QueryRequest.username , QueryRequest.password etc.. This is caused by the array element LATER in the WSDL; -- 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

14 years, 6 months

4
9
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues May 2010