July 2008 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-1808) business_rules_service QS is missing an action

by Jaroslaw Kijanowski (JIRA)

business_rules_service QS is missing an action ---------------------------------------------- Key: JBESB-1808 URL: http://jira.jboss.com/jira/browse/JBESB-1808 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.2.1 CP2 Reporter: Jaroslaw Kijanowski >From the readme file in the business_rules_service QS: The customer status is actually set in the jboss-esb.xml via the SetupMessage action since it is not provided with the inbound XML. There's no SetupMessage which would initialize the status of a customer. This has an impact on business rules, which won't fire (besides the logging rules), because they depend on the status value of a customer. Moreover when deploying I get this: 15:07:15,372 INFO [ContentBasedWiretap] Missing or empty destination list - This action class won't have any effect 15:07:15,372 INFO [ContentBasedWiretap] Missing or empty destination list - This action class won't have any effect I guess it's because there are two business rules files, both not used for routing... But that's already filed: JBESB-986 -- 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

16 years, 5 months

3
5
0 / 0

[JBoss JIRA] Created: (JBESB-1856) Update ServicesGuide section, "Content Based Routing using Smooks". The Smooks configuration example is missing.

by Daniel Bevenius (JIRA)

Update ServicesGuide section, "Content Based Routing using Smooks". The Smooks configuration example is missing. ---------------------------------------------------------------------------------------------------------------- Key: JBESB-1856 URL: http://jira.jboss.com/jira/browse/JBESB-1856 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Reporter: Daniel Bevenius Assigned To: Daniel Bevenius Fix For: 4.4 On page 43, the is this line: "The Smooks configuration for the above example would look as follows." But there is now configuration example in below this. This needs to be re-added as the next section describes the configuration and without the example make this difficult to understand. -- 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

16 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBESB-1804) Handle wild card binding address

by Kevin Conner (JIRA)

Handle wild card binding address -------------------------------- Key: JBESB-1804 URL: http://jira.jboss.com/jira/browse/JBESB-1804 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Configuration Affects Versions: 4.2.1 CP3, 4.3 Reporter: Kevin Conner Fix For: 4.2.1 CP4, 4.4 At present we default to jboss.bind.address for the jndi-url (in jbossesb-properties.xml) but there is an issue when the ANY address is used with -b Starting the server using -b 0.0.0.0 will cause our EPRs to specify an IP address of 0.0.0.0. We should use our own property, as other projects do, and have this initialised using ServerConfigUtil.fixRemoteAddress. -- 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

16 years, 5 months

1
3
0 / 0

[JBoss JIRA] Created: (JBESB-1622) Need to make sure that Message ID is not overwritten by JMS message ID

by Tom Cunningham (JIRA)

Need to make sure that Message ID is not overwritten by JMS message ID ---------------------------------------------------------------------- Key: JBESB-1622 URL: http://jira.jboss.com/jira/browse/JBESB-1622 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Message Store Affects Versions: 4.2.1 CP1 Reporter: Tom Cunningham Need to make sure that the message ID is not overwritten by the JMS message ID. The message ID is going to be used to correlate reply-to messages and link message metadata - we're going to need them to be consistent so for monitoring. -- 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

16 years, 5 months

4
12
0 / 0

[JBoss JIRA] Created: (JBESB-1703) https_2way_ssl quickstart not runnable

by Julian Coleman (JIRA)

https_2way_ssl quickstart not runnable -------------------------------------- Key: JBESB-1703 URL: http://jira.jboss.com/jira/browse/JBESB-1703 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Examples Affects Versions: 4.2.1 CP2 Environment: RHEL 5 Reporter: Julian Coleman The https_2way_ssl quickstart doesn't run out of the box. First, it doesn't deploy correctly, as the ESB dependency is wrong. Second, an extra "/" is needed to find the keystore. -- 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

16 years, 5 months

3
4
0 / 0

[JBoss JIRA] Created: (JBESB-1729) EJBProcessor doing JNDI lookup on every call - could cache

by Tom Fennelly (JIRA)

EJBProcessor doing JNDI lookup on every call - could cache ---------------------------------------------------------- Key: JBESB-1729 URL: http://jira.jboss.com/jira/browse/JBESB-1729 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Adapters Reporter: Tom Fennelly -- 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

16 years, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JBESB-467) Reducing registry lookup overhead

by Mark Little (JIRA)

Reducing registry lookup overhead --------------------------------- Key: JBESB-467 URL: http://jira.jboss.com/jira/browse/JBESB-467 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Registry and Repository, Rosetta Affects Versions: 4.0 Reporter: Mark Little Assigned To: Kurt Stam Priority: Critical Fix For: 4.2, 5.0 >From our previous discussion on reducing registry lookup overhead (currently lookup per message send): There are a number of solutions to this and we should try to support them all eventually: (i) EPR lifetime: service deployers can register a lifetime associated with the EPR in the registry and when something reads the EPR it also receives information on how long the EPR will remain valid for. After that time elapses, clients must go back to the registry to get a new copy. (ii) building on (i), EPRs can be marked as persistent - they never change so one lookup will always be enough. (iii) interactions with services are scoped by sessions and the EPR is assumed to remain valid for the duration of the session. The service can be marked as useable within such a session. (iv) EPRs are looked up once per client lifecycle and only rebound if the service fails. If you recall from the original ESB architecture document, service migration is something that is on the roadmap (5.0) and if a service moves it can leave a forwarding address (EPR) and the architecture allows messages to be redirected and eventually short-cut, i.e., the client EPR is updated with the new EPR transparently as a result of receiving a response from a different endpoint. (iii) and (iv) are really for the 5.0 architecture. However, it should be possible to add something along (i) and (ii) for 4.0. What do you think? -- 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

16 years, 5 months

3
10
0 / 0

[JBoss JIRA] Created: (JBESB-1652) Need to update install/readme.txt

by Tom Cunningham (JIRA)

Need to update install/readme.txt --------------------------------- Key: JBESB-1652 URL: http://jira.jboss.com/jira/browse/JBESB-1652 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.2.1 CP2 Reporter: Tom Cunningham Fix For: 4.2.1 TP-FP1 Need to update install/readme.txt - it suggests using jbossws-native-2.0.1.SP2 from the jbossws downloads page, this release is no longer there. "If you are running JBossESB on JBoss AS 4.2.1.GA, you will need to update the Application Server with JBossWS 2.0.1.SP2 (Native). To do this, download the "jbossws-native-2.0.1.SP2" distribution from http://labs.jboss.org/jbossws/downloads/." -- 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

16 years, 5 months

3
5
0 / 0

[JBoss JIRA] Created: (JBESB-1861) Allow the overriding of the default maxThreads on MessageAwareListener

by Mark Little (JIRA)

Allow the overriding of the default maxThreads on MessageAwareListener ---------------------------------------------------------------------- Key: JBESB-1861 URL: http://jira.jboss.com/jira/browse/JBESB-1861 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Rosetta, Transports Affects Versions: 4.2.1 CP3 Reporter: Mark Little Assigned To: Mark Little Priority: Critical Fix For: 4.4 Spoken with TomF about this. -- 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

16 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JBESB-1758) New parameter for ObjectToXStream to change mode for dealing with duplicate references

by Tuomo Jylkkￃﾃￂﾤ (JIRA)

New parameter for ObjectToXStream to change mode for dealing with duplicate references -------------------------------------------------------------------------------------- Key: JBESB-1758 URL: http://jira.jboss.com/jira/browse/JBESB-1758 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.2.1 Environment: All Reporter: Tuomo Jylkkￃﾃￂﾤ ObjectToXStream doesn't has parameter to configure XStream mode. Now we cannot change mode for dealing with duplicate references from default (XStream.XPATH_RELATIVE_REFERENCES) to other modes. -- 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

16 years, 5 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues July 2008