July 2007 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-659) 2 JBossAS instances cannot share the same JBossMQ service for JMS gateways if JMS is installed

by James Williams (JIRA)

2 JBossAS instances cannot share the same JBossMQ service for JMS gateways if JMS is installed ---------------------------------------------------------------------------------------------- Key: JBESB-659 URL: http://jira.jboss.com/jira/browse/JBESB-659 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Environment: JBossAS 4.2GA, JBossESB - Head as of 07/05.2007. Reporter: James Williams Assigned To: Mark Little I am trying to get 2 JBossAS instances to share the same JMS Server for gateways. There's a lot of moving parts, but I'll try to explain the configurations: 1. JBossAS 4.2.0-GA default config with all .ESB archives, minus the quickstart_helloworld.esb. This server is started using the "-b localhost -c node0" startup parameters. 2. JBossAS 4.2.0-GA default config with "jbossesb.sar" and "quickstart_helloworld.esb". All other .ESB archives are removed and my goal is to use the JMS service in server #1 for gateways/listeners. The quickstart_helloworld.esb archive in this server has its own gateway/listener queues. This server is started using the "-b 192.168.200.1 -c node1" startup parameters. 3. JBossAS 4.2-GA default config with "jbossesb.sar" and "quickstart_helloworld.esb". All other .ESB archives are removed and my goal is to use the JMS service in server #1 for gateways/listeners. The quickstart_helloworld.esb archive in this server has its own gateway/listener queues that are different from the gateways/listeners in #2. This server is started using the "-b 192.168.200.2 -c node2" startup parameters. I'm not having any problems with nodes #2 and #3 sharing the JMS service that's running on #1, so long as JBossMQ isn't installed on node #2 or #3. If JMS is installed, quickstart_helloworld.esb archive fails to deploy on both #2 or #3. It complains that the Gateway queue does not exist, but it most certainly does. Worse yet, when I run the SendJMSMessage test class, it cannot find the queue either. It's as if jbossesb.sar is somehow screwing up all jndi lookups for the queue. There are a couple things I've done to try to rule out other potential root causes: 1. I tried running #1, #2, #3 w/out any .ESB archives or jbossesb.sar to verify that a JMS client can indeed drop requests into queues on all servers. To me, this validates that 3 unclustered JBossAS instances can each have their own JMS queues that are all accessible on a single machine, like my test environment, just by having the app servers bootstrapped by unique config and ip address. I was worried that the JMS service might be the culprit, but that doesn't appear to be the case. 2. I removed JMS from #2 and #3 to verify that the queues are setup correctly on #1 and to verify that #2 and #3 can indeed share the same JMS service provided they do not have JMS running themselves. -- 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

14 years, 7 months

3
7
0 / 0

[JBoss JIRA] Created: (JBESB-502) Blocking Gateway - in and out.

by Kurt Stam (JIRA)

Blocking Gateway - in and out. ------------------------------ Key: JBESB-502 URL: http://jira.jboss.com/jira/browse/JBESB-502 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.2 Milestone Release 1 Environment: any Reporter: Kurt Stam Assigned To: Mark Little Fix For: 4.2 Milestone Release 2 I do think we should make an option for a blocking gateway, where the gateway waits for a a reply from an ESB Service. Basically we set the 'replyTO' on the message and route to a 'replyTO' service which replies back to the gateway. This is another argument for gateways to be in and out. -- 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

14 years, 7 months

4
8
0 / 0

[JBoss JIRA] Created: (JBESB-476) Make action, listener etc configuration setting by setter method the default

by Tom Fennelly (JIRA)

Make action, listener etc configuration setting by setter method the default ---------------------------------------------------------------------------- Key: JBESB-476 URL: http://jira.jboss.com/jira/browse/JBESB-476 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.0 Reporter: Tom Fennelly Assigned To: Mark Little Fix For: 4.2 We currently configure everything by constructor. This is not great for a number of reasons: 1. It can't be compile time validated. 2. Not as "obvious" to someone developing against the API. If in an interface, their IDE (or at least compiler - if using a stone ax) will complain immediately that they're not implementing the interface correctly. 3. Makes our code a little bit more complicated re the reflection code that needs to be implemented. So I suggest making the interface (that all these things implement) contain a setter method that takes the config. The mandate on the implementation is that they contain a public default constructor. -- 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

14 years, 7 months

4
12
0 / 0

[JBoss JIRA] Created: (JBESB-556) Make the webservice_bpel quickstart into a Trailblazer

by Tom Fennelly (JIRA)

Make the webservice_bpel quickstart into a Trailblazer ------------------------------------------------------ Key: JBESB-556 URL: http://jira.jboss.com/jira/browse/JBESB-556 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.2 Milestone Release 2 Reporter: Tom Fennelly Assigned To: Tom Fennelly Fix For: 4.2 This is really a Trailblazer - too much in it to be a QS -- 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

14 years, 8 months

3
8
0 / 0

[JBoss JIRA] Created: (JBESB-511) Add integration test for default SFTP EPR.

by Mark Little (JIRA)

Add integration test for default SFTP EPR. ------------------------------------------ Key: JBESB-511 URL: http://jira.jboss.com/jira/browse/JBESB-511 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Rosetta, Testing Reporter: Mark Little Assigned To: Bruno Georges Fix For: 4.2 -- 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, 7 months

3
11
0 / 0

[JBoss JIRA] Created: (JBESB-506) Consider Mina support

by Mark Little (JIRA)

Consider Mina support --------------------- Key: JBESB-506 URL: http://jira.jboss.com/jira/browse/JBESB-506 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Transports Reporter: Mark Little Assigned To: Mark Little Priority: Optional Fix For: 5.0 http://mina.apache.org/ -- 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, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JBESB-652) Refactory JMSRouter to simplfy setting properties on JMSMessage from ESB Message object

by Daniel Bevenius (JIRA)

Refactory JMSRouter to simplfy setting properties on JMSMessage from ESB Message object --------------------------------------------------------------------------------------- Key: JBESB-652 URL: http://jira.jboss.com/jira/browse/JBESB-652 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Daniel Bevenius Assigned To: Mark Little Priority: Minor The use case for this is that we need to set the correlation id of the JMSMessage before it is sent by the JMSRouter. We have previously subclassed JMSRouter but this was not the best solution as we needed to override the route method and duplicate most of the code. I would be nice to have a method that would be called from the route method that looked something like this: setJMSProperties ( jmsMessage, esbMsg ); The default implementation could do nothing but would let subclasses only override this method. -- 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

2
10
0 / 0

[JBoss JIRA] Created: (JBESB-651) Update PackageJmsMessageContents to set the JMS header field JMSCorreletionID on the ESB Message Object body

by Daniel Bevenius (JIRA)

Update PackageJmsMessageContents to set the JMS header field JMSCorreletionID on the ESB Message Object body ------------------------------------------------------------------------------------------------------------ Key: JBESB-651 URL: http://jira.jboss.com/jira/browse/JBESB-651 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rosetta Reporter: Daniel Bevenius Assigned To: Mark Little Priority: Minor PackageJmsMessageContents currently adds the JMS header field JMSMessageID to the body of the ESB Message Object: if (jmsMsg.getJMSMessageID()!=null) { message.getBody().add("MessageId", jmsMsg.getJMSMessageID()); } It would be nice to add the JMSCorrelationID aswell, and perhaps other JMSHeader fields that can be set by an application. As far as I know the only others one besides the correlation id that can be set by an application are JMSType and JMSReplyTo. -- 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

2
12
0 / 0

[JBoss JIRA] Created: (JBESB-684) Richer message structure/hierarchy

by Mark Little (JIRA)

Richer message structure/hierarchy ---------------------------------- Key: JBESB-684 URL: http://jira.jboss.com/jira/browse/JBESB-684 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.2 Milestone Release 2 Reporter: Mark Little Assigned To: Mark Little Bill Burke said: "... maybe it would be better for ESB Message interface to have a similar hierarchy to JMS? What I mean is: Message | ObjectMessage, StringMessage, MapMessage We know that ESB has a richer message semantic, but from what I saw a few months ago, its has a one-interface-fits all for its payload." -- 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

1
6
0 / 0

[JBoss JIRA] Created: (JBESB-728) MessageFilter.process duplicates the code from ContentBasedWiretap.process

by Jiri Pechanec (JIRA)

MessageFilter.process duplicates the code from ContentBasedWiretap.process -------------------------------------------------------------------------- Key: JBESB-728 URL: http://jira.jboss.com/jira/browse/JBESB-728 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.2 Milestone Release 3 Reporter: Jiri Pechanec Assigned To: Mark Little Priority: Optional The code in MessageFilter is copy/paste of the code from ContentBasedWiretap. Proposed solution: 1) Refactor the destination not found code from ContentBasedWiretap.process to template method doDestinationNotFound 2) Refactor the destination not found code from MessageFilter.process to overriden method doDestinationNotFound 3) Remove method MessageFilter.process -- 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

2
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues July 2007