[JBoss JIRA] Created: (JBESB-3574) EPRHelper modifies EPRs when serialising to XML
by Kevin Conner (JIRA)
EPRHelper modifies EPRs when serialising to XML
-----------------------------------------------
Key: JBESB-3574
URL: https://issues.jboss.org/browse/JBESB-3574
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transports
Affects Versions: 4.7 CP2
Reporter: Kevin Conner
Assignee: Tom Cunningham
The setSpecificEPR initialises a type extension if one is not already present, but this cannot be done safely.
Any modifications to an EPR should only be done at the construction point, as it is the creator who is responsible for doing this.
I'll attach a diff which configures the type on construction, but we should also consider updating the EPR classes to throw exceptions if modifications are made after the creator has finished with their construction.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] Created: (JBESB-3639) Quickstarts fail to compile or deploy depending on existence of /server/default directory
by Tom Cunningham (JIRA)
Quickstarts fail to compile or deploy depending on existence of /server/default directory
-----------------------------------------------------------------------------------------
Key: JBESB-3639
URL: https://issues.jboss.org/browse/JBESB-3639
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Build and Release
Affects Versions: 4.10 CP1
Reporter: Tom Cunningham
Assignee: Tom Cunningham
Fix For: 4.10 CP1
When one tries to deploy (ant deploy) any quickstart the QS/conf/base-build.xml among other thins checks for existence of /server/default directory... if the directory doesn't exist, the ant execution fails.
If anyone removes or renames (that is presumable) the default profile he would not be able to run the quickstarts ant at all...
To reproduce:
1) unzip SOA-P
2) move/rename ${SOA-P}/jboss-as/server/default to ${SOA-P}/jboss-as/server/<anything-else>
3) from ${SOA-P}/jboss-as/samles/quickstarts/helloworld run 'ant deploy':
$ ant deploy
Buildfile: build.xml
BUILD FAILED
/SOA-P/jboss-as/samples/quickstarts/helloworld/build.xml:9: The following error occurred while executing this line:
/SOA-P/jboss-as/samples/quickstarts/conf/base-build.xml:57: Cannot determine build hierarchy
Total time: 0 seconds
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] Created: (JBESB-3628) business_ruleservice_stateful QS doesn't work as expected
by Tom Cunningham (JIRA)
business_ruleservice_stateful QS doesn't work as expected
---------------------------------------------------------
Key: JBESB-3628
URL: https://issues.jboss.org/browse/JBESB-3628
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Examples
Affects Versions: 4.10 CP1
Reporter: Tom Cunningham
Assignee: Tom Cunningham
Fix For: 4.10 CP1
After the second message is sent, business_ruleservice_stateful QS should set the discount on the second order to 10 %. Instead, the following is seen in server.log, stating that the discount is actually 0 %.
2010-10-19 13:12:56,924 INFO [STDOUT] (pool-37-thread-1) set discount of 0.0 on order 2 for customer user1
2010-10-19 13:12:56,924 INFO [STDOUT] (pool-37-thread-1) set discount of 0.0 on order 1 for customer user1
2010-10-19 13:12:56,924 INFO [STDOUT] (pool-37-thread-1) Customer user1 now has a shopping total of 129.84
2010-10-19 13:12:56,925 INFO [STDOUT] (pool-37-thread-1) set discount of 0.0 on order 2 for customer user1
2010-10-19 13:12:56,925 INFO [STDOUT] (pool-37-thread-1) Customer user1 now has a shopping total of 129.84
The time the third message is sent, the discount is actually set to 10 %, with this in the server.log:
2010-10-19 13:37:19,701 INFO [STDOUT] (pool-28-thread-1) set discount of 0.0 on order 3 for customer user1
2010-10-19 13:37:19,701 INFO [STDOUT] (pool-28-thread-1) set discount of 0.0 on order 2 for customer user1
2010-10-19 13:37:19,701 INFO [STDOUT] (pool-28-thread-1) set discount of 0.0 on order 1 for customer user1
2010-10-19 13:37:19,702 INFO [STDOUT] (pool-28-thread-1) Customer user1 now has a shopping total of 194.76
2010-10-19 13:37:19,702 INFO [STDOUT] (pool-28-thread-1) set discount of 10.0 on order 3 for customer user1
2010-10-19 13:37:19,702 INFO [STDOUT] (pool-28-thread-1) set discount of 10.0 on order 3 for customer user1
2010-10-19 13:37:19,702 INFO [STDOUT] (pool-28-thread-1) Customer user1 now has a shopping total of 194.76
2010-10-19 13:37:19,702 INFO [STDOUT] (pool-28-thread-1) Customer user1 now has a shopping total of 194.76
It seems as if a different Customer instance is picked when the rules are fired the second time - the instance that still has the discount set to 0 %. This would suggest some faulty behavior wrt. classloading, perhaps even SOA-2419.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] Created: (JBESB-3645) Improve POSTHttpMethodFactory so it handles byte[] messages - SOA-P 4.3
by Rick Wagner (JIRA)
Improve POSTHttpMethodFactory so it handles byte[] messages - SOA-P 4.3
-----------------------------------------------------------------------
Key: JBESB-3645
URL: https://issues.jboss.org/browse/JBESB-3645
Project: JBoss ESB
Issue Type: Patch
Security Level: Public (Everyone can see)
Components: Rosetta
Affects Versions: 4.4
Environment: n/a
Reporter: Rick Wagner
Assignee: Kevin Conner
Fix For: 4.7
Attachments: postfac.patch
I tried to use the HttpRouter to push messages to an external consumer (per http://www.jboss.org/community/wiki/HttpRouter). It almost worked but the messages had been converted to byte[] somewhere inside the ESB so when they got on the wire they looked like:
0x0000: 4500 00d9 213c 4000 4006 0000 7f00 0001 E...!<@.@.......
0x0010: 7f00 0001 f4d4 0050 85f6 5922 0afe 80de .......P..Y"....
0x0020: 8018 9f7e fecd 0000 0101 080a 2ea9 9208 ...~............
0x0030: 2ea9 9208 504f 5354 202f 6d65 6469 6361 ....POST./medica
0x0040: 6c20 4854 5450 2f31 2e31 0d0a 436f 6e74 l.HTTP/1.1..Cont
0x0050: 656e 742d 5479 7065 3a20 7465 7874 2f78 ent-Type:.text/x
0x0060: 6d6c 3b63 6861 7273 6574 3d55 5446 2d38 ml;charset=UTF-8
0x0070: 0d0a 5573 6572 2d41 6765 6e74 3a20 4a61 ..User-Agent:.Ja
0x0080: 6b61 7274 6120 436f 6d6d 6f6e 732d 4874 karta.Commons-Ht
0x0090: 7470 436c 6965 6e74 2f33 2e30 2e31 0d0a tpClient/3.0.1..
0x00a0: 486f 7374 3a20 6c6f 6361 6c68 6f73 742e Host:.localhost.
0x00b0: 7365 726d 6f2e 636f 6d0d 0a43 6f6e 7465 sermo.com..Conte
0x00c0: 6e74 2d4c 656e 6774 683a 2039 0d0a 0d0a nt-Length:.9....
0x00d0: 5b42 4066 6438 3936 63 [B@fd896c
I'll attach a patch to make POSTHttpMethodFactory handle byte[] as a special case (in the same spirit as JMSRouter#createJMSMessageWithObjectType() which also does this).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] Created: (JBESB-3642) ESB - SOAPProxy throws SAXParseException when soapAction is missing in WSDL and message has attachment
by Tom Cunningham (JIRA)
ESB - SOAPProxy throws SAXParseException when soapAction is missing in WSDL and message has attachment
------------------------------------------------------------------------------------------------------
Key: JBESB-3642
URL: https://issues.jboss.org/browse/JBESB-3642
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Deployment
Affects Versions: 4.10
Environment: SOA-P 5.1 running on Mac 10.6 JDK 1.6
Reporter: Rick Wagner
Assignee: David Ward
SOAPProxy throws SAXParseException when soapAction is missing in WSDL and message has attachment. If the soapAction ="" in the WSDL, then the message is not parsed. If there is no soapAction in the WSDL, then SOAPProxy attempts to parse the document to find the operation in the message, and throws a SAXParseException. See Steps to Reproduce below for more details.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months