April 2007 - esb-issues - Jboss List Archives

[JBoss JIRA] Updated: (JBESB-425) Easy proxy for EJB3, Spring-POJO, WS

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-425?page=all ] Mark Little updated JBESB-425: ------------------------------ Fix Version/s: 4.2 (was: 4.2 Milestone Release 2) > Easy proxy for EJB3, Spring-POJO, WS > ------------------------------------ > > Key: JBESB-425 > URL: http://jira.jboss.com/jira/browse/JBESB-425 > Project: JBoss ESB > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Rosetta, Documentation, Examples, Configuration > Reporter: Mark Little > Assigned To: Daniel Marchant > Fix For: 4.2 > > > Make it really, really easy to proxy an existing EJB3, Spring, MDB or WS onto the bus as an action. -- 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

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBESB-434) Hibernate listener

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-434?page=all ] Mark Little updated JBESB-434: ------------------------------ Fix Version/s: 4.2 (was: 4.2 Milestone Release 2) > Hibernate listener > ------------------ > > Key: JBESB-434 > URL: http://jira.jboss.com/jira/browse/JBESB-434 > Project: JBoss ESB > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Transports > Reporter: Mark Little > Assigned To: Daniel Marchant > 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

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Work logged: (JBESB-193) Need support for notification generatoin from within ActionProcessor.process method

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-193?page=worklog#action_12360873 ] Mark Little logged work on JBESB-193: ------------------------------------- Time Spent: 2 hours Remaining Estimate: 0 minutes Time Spent: 2 hours > Need support for notification generatoin from within ActionProcessor.process method > ----------------------------------------------------------------------------------- > > Key: JBESB-193 > URL: http://jira.jboss.com/jira/browse/JBESB-193 > Project: JBoss ESB > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Rosetta > Affects Versions: 5.0 > Reporter: Tom Fennelly > Assigned To: Mark Little > Fix For: 4.2 > > Time Spent: 2 hours > Remaining Estimate: 0 minutes > > In version 4.0, the Action Processing pipeline management code raises notifications in response to an exception from the ActionProcessor.process method. The pipeline managemnt code calls the getOkNotification (no exception) or getErrorNotification (exception) to get the notification message. > For many reasons, this is a very flawed model. Notifications should be raised from within the process method by means of attaching the notifications (error or otherwise) to the message (the mechanism is a design issue). Once the process method returns, the pipline processing management code can check the message for notifications. If there are errors, it can/should (?) abort the message processing, send the error notification (by whatever notification options are configured on the listener) and signal the failure to the calling process (by whatever failure config is configured on the listener). > The getOk and getErro methods can then be removed. -- 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

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBESB-193) Need support for notification generatoin from within ActionProcessor.process method

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-193?page=comments#action_12360833 ] Mark Little commented on JBESB-193: ----------------------------------- Have been working on the following changes to the chaining. If a message comes back from process and it has a Fault defined, then the processing stops and the message will be sent back (it's an error message). If an error happens at any point in the chaining and/or results in an exception, then a specific error message will be sent back (it will have a Fault defined). The destination of these error messages will be based on: (i) FaultTo on original message (ii) if no FaultTo set, then ReplyTo on original message (iii) if no ReplyTo, then From on original message. (iv) if no From then default ReplyTo should have been set at the sender anyway. Any message returned from process can have its own Call section in the message. In which case, a Fault message returned will be routed giving preference to that information over anything that came in on the original received message. > Need support for notification generatoin from within ActionProcessor.process method > ----------------------------------------------------------------------------------- > > Key: JBESB-193 > URL: http://jira.jboss.com/jira/browse/JBESB-193 > Project: JBoss ESB > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Rosetta > Affects Versions: 5.0 > Reporter: Tom Fennelly > Assigned To: Mark Little > Fix For: 4.2 > > > In version 4.0, the Action Processing pipeline management code raises notifications in response to an exception from the ActionProcessor.process method. The pipeline managemnt code calls the getOkNotification (no exception) or getErrorNotification (exception) to get the notification message. > For many reasons, this is a very flawed model. Notifications should be raised from within the process method by means of attaching the notifications (error or otherwise) to the message (the mechanism is a design issue). Once the process method returns, the pipline processing management code can check the message for notifications. If there are errors, it can/should (?) abort the message processing, send the error notification (by whatever notification options are configured on the listener) and signal the failure to the calling process (by whatever failure config is configured on the listener). > The getOk and getErro methods can then be removed. -- 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

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Work started: (JBESB-193) Need support for notification generatoin from within ActionProcessor.process method

by Mark Little (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-193?page=all ] Work on JBESB-193 started by Mark Little. > Need support for notification generatoin from within ActionProcessor.process method > ----------------------------------------------------------------------------------- > > Key: JBESB-193 > URL: http://jira.jboss.com/jira/browse/JBESB-193 > Project: JBoss ESB > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Rosetta > Affects Versions: 5.0 > Reporter: Tom Fennelly > Assigned To: Mark Little > Fix For: 4.2 > > > In version 4.0, the Action Processing pipeline management code raises notifications in response to an exception from the ActionProcessor.process method. The pipeline managemnt code calls the getOkNotification (no exception) or getErrorNotification (exception) to get the notification message. > For many reasons, this is a very flawed model. Notifications should be raised from within the process method by means of attaching the notifications (error or otherwise) to the message (the mechanism is a design issue). Once the process method returns, the pipline processing management code can check the message for notifications. If there are errors, it can/should (?) abort the message processing, send the error notification (by whatever notification options are configured on the listener) and signal the failure to the calling process (by whatever failure config is configured on the listener). > The getOk and getErro methods can then be removed. -- 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

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBESB-401) During Trailblazer DEMO, JMS doesn't reconnect after a restart of the App Server [JMS Provider]

by Kevin Conner (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-401?page=all ] Kevin Conner closed JBESB-401. ------------------------------ Resolution: Done There were a number of issues around the trailblazer which have been tidied up. - missing queue definition for credit reference replies - two messages sent back as reply (credit reference and original) - retry for bank on disconnect > During Trailblazer DEMO, JMS doesn't reconnect after a restart of the App Server [JMS Provider] > ----------------------------------------------------------------------------------------------- > > Key: JBESB-401 > URL: http://jira.jboss.com/jira/browse/JBESB-401 > Project: JBoss ESB > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Rosetta > Affects Versions: 4.0 > Environment: JBoss ESB 4.0 GA + JBoss AS 4.0.5GA - Win 2000 - Fedora Core 6 > Reporter: Bruno Georges > Assigned To: Kevin Conner > Fix For: 4.2 Milestone Release 2 > > > During Trailblazer DEMO, JMS doesn't reconnect when App Server restart: ERROR [JmsCourier] JMS error. Attempting JMS reconnect. > ant runJMSBank > [java] 10:00:01,759 WARN [Connection] Connection failure, use javax.jms.Connection.setExceptionListener() to handle this error and reconnect > [java] org.jboss.mq.SpyJMSException: No pong received; - nested throwable: (java.io.IOException: ping timeout.) > [java] at org.jboss.mq.Connection$PingTask.run(Connection.java:1277) > [java] at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(ClockDaemon.java:364) > [java] at java.lang.Thread.run(Thread.java:595) > [java] Caused by: java.io.IOException: ping timeout. > [java] ... 3 more > ant runESB > [java] 09:58:52,056 ERROR [JmsCourier] JMS error. Attempting JMS reconnect. > [java] javax.jms.IllegalStateException: The consumer is closed > [java] at org.jboss.mq.SpyMessageConsumer.checkClosed(SpyMessageConsumer.java:963) > [java] at org.jboss.mq.SpyMessageConsumer.receive(SpyMessageConsumer.java:360) > [java] at org.jboss.internal.soa.esb.couriers.JmsCourier.pickup(JmsCourier.java:349) > [java] at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.pickup(TwoWayCourierImpl.java:184) > [java] at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.pickup(TwoWayCourierImpl.java:166) > [java] at org.jboss.soa.esb.listeners.message.MessageAwareListener.waitForEventAndProcess(MessageAwareListener.java:246) > [java] at org.jboss.soa.esb.listeners.message.MessageAwareListener.doRun(MessageAwareListener.java:228) > [java] at org.jboss.soa.esb.listeners.lifecycle.AbstractThreadedManagedLifecycle.run(AbstractThreadedManagedLifecycle.java:114) > [java] at java.lang.Thread.run(Thread.java:595) > [java] 09:59:51,775 WARN [Connection] Connection failure, use javax.jms.Connection.setExceptionListener() to handle this error and reconnect > [java] org.jboss.mq.SpyJMSException: No pong received; - nested throwable: (java.io.IOException: ping timeout.) > [java] at org.jboss.mq.Connection$PingTask.run(Connection.java:1277) > [java] at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(ClockDaemon.java:364) > [java] at java.lang.Thread.run(Thread.java:595) > [java] Caused by: java.io.IOException: ping timeout. > [java] ... 3 more > [java] 09:59:52,056 ERROR [JmsCourier] JMS error. Attempting JMS reconnect. -- 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

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBESB-466) Incorrect classloading using Class.forName

by Kevin Conner (JIRA)

Incorrect classloading using Class.forName ------------------------------------------ Key: JBESB-466 URL: http://jira.jboss.com/jira/browse/JBESB-466 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0 Reporter: Kevin Conner Assigned To: Kevin Conner Fix For: 4.0 Maintenance Pack 1 Class.forName is used throughout the codebase but this does not work correctly when used in app servers etc. Classes (and resources) should be looked using the thread context classloader before anything else. -- 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

17 years, 2 months

4
10
0 / 0

[JBoss JIRA] Closed: (JBESB-403) Quickstart package hierarchy should be org.jboss...

by Sebastian Cao (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-403?page=all ] Sebastian Cao closed JBESB-403. ------------------------------- Resolution: Done > Quickstart package hierarchy should be org.jboss... > --------------------------------------------------- > > Key: JBESB-403 > URL: http://jira.jboss.com/jira/browse/JBESB-403 > Project: JBoss ESB > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Examples > Affects Versions: 4.0 > Reporter: Mark Little > Assigned To: Sebastian Cao > Priority: Minor > Fix For: 4.2 Milestone Release 2 > > Time Spent: 1 day > Remaining Estimate: 0 minutes > -- 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

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Work logged: (JBESB-403) Quickstart package hierarchy should be org.jboss...

by Sebastian Cao (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-403?page=worklog#action_12360790 ] Sebastian Cao logged work on JBESB-403: --------------------------------------- Time Spent: 6 hours Time Spent: 1 day (was: 2 hours) Final refactoring Replacements in config files Replacements in build files Replacements in readme files Testing > Quickstart package hierarchy should be org.jboss... > --------------------------------------------------- > > Key: JBESB-403 > URL: http://jira.jboss.com/jira/browse/JBESB-403 > Project: JBoss ESB > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Examples > Affects Versions: 4.0 > Reporter: Mark Little > Assigned To: Sebastian Cao > Priority: Minor > Fix For: 4.2 Milestone Release 2 > > Time Spent: 1 day > Remaining Estimate: 0 minutes > -- 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

17 years, 2 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBESB-443) Improve XSLT support and performance

by Tom Fennelly (JIRA)

[ http://jira.jboss.com/jira/browse/JBESB-443?page=all ] Tom Fennelly updated JBESB-443: ------------------------------- Fix Version/s: 5.0 Milestone Release 1 (was: 4.2) > Improve XSLT support and performance > ------------------------------------ > > Key: JBESB-443 > URL: http://jira.jboss.com/jira/browse/JBESB-443 > Project: JBoss ESB > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Transformation Service > Reporter: Mark Little > Assigned To: Tom Fennelly > Priority: Critical > Fix For: 5.0 Milestone Release 1 > > > Customers still want XSLT transformation support. Although Smooks supports XSLT, it may impose an overhead on some transformations versus native XSLT support. We need to see what the overhead is (if any) and maybe add native XSLT support within the ESB transformation service (a separate service implementation). -- 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

17 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues April 2007