[JBoss JIRA] Created: (JBESB-3601) webservice_proxy_security needs to be updated
by Tom Cunningham (JIRA)
webservice_proxy_security needs to be updated
---------------------------------------------
Key: JBESB-3601
URL: https://issues.jboss.org/browse/JBESB-3601
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Documentation
Reporter: Tom Cunningham
Priority: Minor
Fix For: 4.10
In step 1 of the readme file the path to server.xml file is now jboss-as/server/production/deploy/jbossweb.sar/server.xml.
Also step 2 mentions starting the server with version 4.x style path.
---------------------------------------------------------------------
1. BEFORE you start the server:
type 'ant genkey'
copy the contents of build/server.xml into copy into
jbossesb-server-4.x/server/default/deploy/jboss-web.deployer/server.xml
2. start the server in jbossesb-server-4.x/bin/ with ./run.sh
--
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-3555) Allow for pluggable password encryption/decryption mechanism in esb
by Matt Davis (JIRA)
Allow for pluggable password encryption/decryption mechanism in esb
-------------------------------------------------------------------
Key: JBESB-3555
URL: https://issues.jboss.org/browse/JBESB-3555
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 4.8, 4.7 CP2
Reporter: Matt Davis
The customer would like the ability to plugin their own encryption implementation for FilePassword. For instance, in the jbossesb-properties, they would like to specify <property name="org.jboss.soa.esb.services.security.publicKeystorePassword" value="testKeystorePassword"/> using their own plugin implementation. Currently the implementation is hard coded and not pluggable.
--
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-3647) Please document Smooks transformation with POJO input
by Tom Cunningham (JIRA)
Please document Smooks transformation with POJO input
-----------------------------------------------------
Key: JBESB-3647
URL: https://issues.jboss.org/browse/JBESB-3647
Project: JBoss ESB
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Transformation Service
Affects Versions: 4.10 CP1
Reporter: Tom Cunningham
Assignee: Tom Fennelly
Fix For: 4.10 CP1
The user had to rely on source code-reading to use Smooks with POJO input. This is a valid usage of Smooks and is alluded to several times in the documentation, but it is never spelled out how to accomplish it. (In particular, the beanId to use with FreeMarker is not spelled out.) Please add this information to Section 12.1.9.4 of the Programmer's Guide.
--
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-3648) Router in Smooks Creates Inverse Persistence
by Tom Cunningham (JIRA)
Router in Smooks Creates Inverse Persistence
--------------------------------------------
Key: JBESB-3648
URL: https://issues.jboss.org/browse/JBESB-3648
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transformation Service
Affects Versions: 4.10
Reporter: Tom Cunningham
Assignee: Tom Fennelly
Fix For: 4.10 CP1
Smooks' JMS Router configures message persistence incorrectly. The documentation suggests the following configuration will result in persistent messages to the ESB:
<jms:router routeOnElement="student" beanId="studentFragment" destination="queue/StudentRecordQueue">
<jms:message deliveryMode="persistent"/>
</jms:router>
Instead, this leads to non-persistent messages. This is due to a bug in org.milyn.routing.jms.JMSRouter:
final int deliveryModeInt = "non-persistent".equals( jmsProperties.getDeliveryMode() ) ? DeliveryMode.PERSISTENT : DeliveryMode.NON_PERSISTENT;
This should instead be the inverse:
final int deliveryModeInt = "non-persistent".equals( jmsProperties.getDeliveryMode() ) ? DeliveryMode.NON_PERSISTENT : DeliveryMode.PERSISTENT;
This is a particularly major bug because the work around will cause incorrect functionality in future versions of the ESB, which will hopefully fix the issue with a patched version of Smooks' JMS Cartridge.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] Created: (JBESB-3622) DefaultJMSPropertiesSetter needs to filter out JMS properties
by Kevin Conner (JIRA)
DefaultJMSPropertiesSetter needs to filter out JMS properties
-------------------------------------------------------------
Key: JBESB-3622
URL: https://issues.jboss.org/browse/JBESB-3622
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transports
Affects Versions: 4.9 CP1
Reporter: Kevin Conner
The current property setter checks for properties that start with JMSX and JMS_ but we also need to include any properties that begin with JMS.
The spec states that the prefixes JMSX and JMS_ are reserved for the JMS spec and implementations respectively, but it also states in a later section that any identifier name which does not begin with 'JMS' is application specific.
Two implementations that will raise exceptions are WSMQ and HornetQ.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] Created: (JBESB-3643) WISE SOAPClient exception loss
by Tom Cunningham (JIRA)
WISE SOAPClient exception loss
------------------------------
Key: JBESB-3643
URL: https://issues.jboss.org/browse/JBESB-3643
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.10
Reporter: Tom Cunningham
Assignee: Tom Cunningham
Fix For: 4.10 CP1
WISE currently captures the exception raised by the WS invocation, and then goes through a list of exceptions to see if the exception matches those.
What we'd like to do is catch the exception, look inside the InvocationTargetException, and if it is a javax.xml.ws.soap.SOAPFaultException, wrap it in the same as other exceptions.
REPRODUCE :
1. Deploy the WAR attached to SOA-3205 file on SOA-P 5.1
2. Unzip the webservice_consumer_wise_smooks.zip into the quickstarts directory
3. ant deploy
4. ant runtest
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] Created: (JBESB-3567) Remove thread local use within SOAPProcessor
by Kevin Conner (JIRA)
Remove thread local use within SOAPProcessor
--------------------------------------------
Key: JBESB-3567
URL: https://issues.jboss.org/browse/JBESB-3567
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Kevin Conner
SOAPProcessor allows for references to the current ESB message to be passed directly to an invoked webservice (executed within thread) but this is inherently broken.
Any webservice implementation can choose to move processing over to a different thread (thereby losing the reference) but it also means that the execution of a webservice, from within the context an ESB invocation, may differ from a normal invocation.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months