June 2007 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-500) package rules, jbpm and smooks as services

by Kurt Stam (JIRA)

package rules, jbpm and smooks as services ------------------------------------------ Key: JBESB-500 URL: http://jira.jboss.com/jira/browse/JBESB-500 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.0 Beta 1 Maintenance Pack 1 Reporter: Kurt Stam Assigned To: Kurt Stam Fix For: 4.2 Milestone Release 2 If we package up all our services as individual .esb archives, we will make it much easier to deploy things like rules, smooks and jBPM. If we go down this road the can become individual self-contained deployments. And so it becomes much easier to maintain them for us as well as to deploy and use them for our users, basically another step towards JBI like architecture. So we should restructure our SVN such that i.e. 'rules' has it's own place. I think we should have three more directories: services/jbpm -> jbpm.esb services/smooks -> smooks.esb services/cbr/jbr -> cbr-jbr.esb each of them builds an .esb archive, and each project has it's own lib directory, so we can clean up the current lib/ext directory which contains everything and the kitchen sink. -- 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

18 years, 10 months

2
12
0 / 0

[JBoss JIRA] Created: (JBESB-533) FTP bus that is read-only (no rename, post-delete etc)

by Daniel Bevenius (JIRA)

FTP bus that is read-only (no rename, post-delete etc) ------------------------------------------------------ Key: JBESB-533 URL: http://jira.jboss.com/jira/browse/JBESB-533 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Adapters Affects Versions: 4.2 Milestone Release 2 Reporter: Daniel Bevenius Assigned To: Daniel Bevenius Priority: Minor Fix For: 4.2 Milestone Release 1 I currently have a requirement to use the ftpbus to connect to an ftp server running on a mainframe computer. The permissions that exists there are for the current file and it is read only. This means that we cannot rename the file upon pickup and not move/delete after processing it. Proposed solutions: 1. Add a property to the ftp-message-filter, for example read-only="true". This would probably make it more clear to the end user that the other properties like post-delete, post-directory, work-suffix, post-delete, post-directory etc, are not valid for this configuration. If the read-only value is true a subclass of RemoteGatewayListener would be used. The current implementation sets the gatewayClass in the class FtpListenerMapper line 80: if(listener.getIsGateway()) { listenerNode.setAttribute("gatewayClass", RemoteGatewayListener.class.getName()); Is there another way to set the gatewayClass that I'm not aware of? I'll investigate this and perhaps post a question to the design forum. 2. Add a strategy to the RemoteGatewayListener that handles delete and rename. The default strategy would work like it does now but one would be able to specify a strategy in the configuration to override it. The strategy to use would then be set in the checkMyParams if the default strategy in not wanted. I would appreciate any suggestions or comments. I assigned this to myself only because I need to start on this as soon as possible. -- 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

18 years, 10 months

3
22
0 / 0

[JBoss JIRA] Created: (JBESB-519) Update quickstarts to more clearly demonstrate deployToAS vs deployToESB

by Burr Sutter (JIRA)

Update quickstarts to more clearly demonstrate deployToAS vs deployToESB ------------------------------------------------------------------------ Key: JBESB-519 URL: http://jira.jboss.com/jira/browse/JBESB-519 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.2 Milestone Release 1 Reporter: Burr Sutter Fix For: 4.2 Milestone Release 2 Based on the introduction of the ESB Server in 4.2 MR1 the quickstarts are a little bit confusing. Helloworld base-build.xml refers to "JBoss ESB Server at '${jbosshome.dir}'." when jbosshome.dir should be mapped to the AS, not to the ESB home. I propose that quickstart.properties have a AS home and ESB home and the build.xml's updated accordingly. As it stands not the jbosshome.dir is being overloaded. The helloworld quickstart (and ideally all of them) should illustrate: - StandAloneBootStrapper - AS deployment (previously known as SAR deployment) - ESB server deployment (new in 4.2) - WAR deployment (if that model actually works) Not every quickstart works with the ESB server and I believe this needs to be more clearly specified in the readme.txt -- 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

18 years, 10 months

4
20
0 / 0

[JBoss JIRA] Created: (JBESB-615) String templating is not deployed into jbossesb-server

by Kevin Conner (JIRA)

String templating is not deployed into jbossesb-server ------------------------------------------------------ Key: JBESB-615 URL: http://jira.jboss.com/jira/browse/JBESB-615 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Transformation Service Reporter: Kevin Conner Assigned To: Kevin Conner Fix For: 4.2 The stringtemplate jar is no longer distributed with the jbossesb-server along with it's associated antlr jar String templating does not work in current distributions. -- 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

18 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (JBESB-584) Upgrade JBossESB from Smooks v0.8 to v0.9

by Tom Fennelly (JIRA)

Upgrade JBossESB from Smooks v0.8 to v0.9 ----------------------------------------- Key: JBESB-584 URL: http://jira.jboss.com/jira/browse/JBESB-584 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Reporter: Tom Fennelly Assigned To: Tom Fennelly There are a number of bug fixes and quite a number of new features/cleanups in 0.9. -- 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

18 years, 10 months

3
11
0 / 0

[JBoss JIRA] Created: (JBESB-523) Migrate CI system over to QA lab

by Mark Little (JIRA)

Migrate CI system over to QA lab -------------------------------- Key: JBESB-523 URL: http://jira.jboss.com/jira/browse/JBESB-523 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Testing Reporter: Mark Little Assigned To: Prabhat Jha Priority: Critical Fix For: 4.2 Please talk to Kevin Conner about this because he is currently managing our CI system in the Newcastle office. We need to have at least the same kind of coverage when it is migrated. -- 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

18 years, 10 months

5
55
0 / 0

[JBoss JIRA] Created: (JBESB-509) Change source tree structure

by Mark Little (JIRA)

Change source tree structure ---------------------------- Key: JBESB-509 URL: http://jira.jboss.com/jira/browse/JBESB-509 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Packaging Affects Versions: 4.2 Milestone Release 1 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.2 Now we have a separate directory for services outside of core, I'd like to remove the core itself and merge listeners and rosetta into rosetta (promoting it to the same level as services). -- 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

18 years, 10 months

3
18
0 / 0

[JBoss JIRA] Created: (JBESB-647) JAXRRegistryService doesn't unpack "cause" exception after proxied invocation of Registry

by Tom Fennelly (JIRA)

JAXRRegistryService doesn't unpack "cause" exception after proxied invocation of Registry ----------------------------------------------------------------------------------------- Key: JBESB-647 URL: http://jira.jboss.com/jira/browse/JBESB-647 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.2 Milestone Release 2 Reporter: Tom Fennelly Assigned To: Mark Little Fix For: 4.2 The JAXRRegistryService class creates a dynamic proxy around the Registry implementation class. It does this so as to push and pop the scoped classloader. As a proxy, it obviously makes reflective "invoke" calls on the proxied Registry instance. If there's an exception, it comes back as a cause on an InvocationTargetException, causing an UndeclaredThrowableException wherever Regsitry methods are being called. This obscures the resulting exceptions that are appearing in the console/logs. The dynamic proxy in JAXRRegistryService should catch all InvocationTargetException, extract and rethrow its cause (which is the real exception that's declared on the Registry interface). -- 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

18 years, 10 months

3
4
0 / 0

[JBoss JIRA] Created: (JBESB-551) Investigate the possiblility of dynamically generating a JBossWS ServiceEndpoint that implements a given interface

by Tom Fennelly (JIRA)

Investigate the possiblility of dynamically generating a JBossWS ServiceEndpoint that implements a given interface ------------------------------------------------------------------------------------------------------------------ Key: JBESB-551 URL: http://jira.jboss.com/jira/browse/JBESB-551 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 So, you could dynamically build the SOAP interface to expose a back end EJB be generating a JBossWS ServiceEndpoint that implements the beans remote interface etc -- 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

18 years, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (JBESB-642) JBossRulesRouter does not dispose of WorkingMemory

by Jeff DeLong (JIRA)

JBossRulesRouter does not dispose of WorkingMemory -------------------------------------------------- Key: JBESB-642 URL: http://jira.jboss.com/jira/browse/JBESB-642 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Content Based Routing Affects Versions: 4.2 Reporter: Jeff DeLong Assigned To: Mark Little In examining the JBossRulesRouter code it does not dispose of workingMemory (statefulSession) at the end of the method. WorkingMemory workingMemory = ruleBase.newStatefulSession(); logger.log(Level.DEBUG, "Obtained message=" + message + " with ruleSet=" + ruleSet); workingMemory.setGlobal("destinations", destinations); if (objectList!=null) { for (Object object : objectList) { workingMemory.assertObject(object); } } workingMemory.assertObject(message); logger.log(Level.DEBUG, "Fire the JBossRules Engine"); workingMemory.fireAllRules(); logger.log(Level.DEBUG, "Outgoing Destinations: " + destinations); return destinations; } I believe it should: i.e., WorkingMemory workingMemory = ruleBase.newStatefulSession(); ... workingMemory.dispose(); This allows garbage collection of the workingMemory. -- 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

18 years, 10 months

3
5
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues June 2007