April 2009 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-2243) JmsSession should cache the acknowledge mode rather than deferring to the underlying session

by Kevin Conner (JIRA)

JmsSession should cache the acknowledge mode rather than deferring to the underlying session -------------------------------------------------------------------------------------------- Key: JBESB-2243 URL: https://jira.jboss.org/jira/browse/JBESB-2243 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.4, 4.4 CP1 Reporter: Kevin Conner Assignee: Kevin Conner Fix For: 4.5, 4.4 CP2 The reason for this is to ensure that failed sessions do not remain in the 'in use' state if a subsequent call to getAcknowledgeMode generates an error. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years

1
3
0 / 0

[JBoss JIRA] Created: (JBESB-2476) Clarification of content for ESB Registry Guide

by Jim Ma (JIRA)

Clarification of content for ESB Registry Guide ----------------------------------------------- Key: JBESB-2476 URL: https://jira.jboss.org/jira/browse/JBESB-2476 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.2.1 CP4 Reporter: Jim Ma Fix For: 4.2.1 CP5 QE questions the correctness of the following statement from Chapter 1 - What is the Registry, page 3: "It may be updated dynamically when services first start-up, or statically by an external administrator. " Clarification needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years

2
1
0 / 0

[JBoss JIRA] Created: (JBESB-2487) incomplete example in ESB Registry Guide

by Jim Ma (JIRA)

incomplete example in ESB Registry Guide ---------------------------------------- Key: JBESB-2487 URL: https://jira.jboss.org/jira/browse/JBESB-2487 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.2.1 CP4 Reporter: Jim Ma Fix For: 4.2.1 CP5 The SOAP example from Chapter 3 is missing details required to implement. For example, removing the juddi-service.sar , adding the axis1.4.jar and commons-discovery-0.2.jar to {$profile}/lib. I found the scout configured with AxisTransport does not work with the juddi server running in same jbossesb instance . Do we need add a note in it ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years

2
1
0 / 0

[JBoss JIRA] Created: (JBESB-1801) bpm_orchestartion3 quickstart does not report the token id for signalling

by Jiri Pechanec (JIRA)

bpm_orchestartion3 quickstart does not report the token id for signalling ------------------------------------------------------------------------- Key: JBESB-1801 URL: http://jira.jboss.com/jira/browse/JBESB-1801 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Examples Affects Versions: 4.2.1 CP3 Environment: Embedded, production Reporter: Jiri Pechanec Assigned To: Kevin Conner Fix For: 4.2.1 CP3 The quickstart should print on the screen the id of token that should be used for signalling -- 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

4
10
0 / 0

[JBoss JIRA] Created: (JBESB-1695) jBPM datasource should be XA datasource

by Jiri Pechanec (JIRA)

jBPM datasource should be XA datasource --------------------------------------- Key: JBESB-1695 URL: http://jira.jboss.com/jira/browse/JBESB-1695 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Process flow, Rosetta Affects Versions: 4.2.1 CP2 Reporter: Jiri Pechanec Assigned To: Kevin Conner Fix For: 4.2.1 CP3 If the SQL listener with transactions is used configured according helloworld_tx_sql and is enhanced with jBPM use - start service, it fails because both datasources are local. To prevent the issue these steps should be done 1) Change the jBPM DS to be XA datasource - this means that schme toll must be also modified 2) Change QS to use H2 database and XA datasource - it serves users as guidline 3) Switch to h2 database for all datasources -- 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

3
15
0 / 0

[JBoss JIRA] Created: (JBESB-1650) Clean up OracleAQ documentation

by Tom Cunningham (JIRA)

Clean up OracleAQ documentation ------------------------------- Key: JBESB-1650 URL: http://jira.jboss.com/jira/browse/JBESB-1650 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Message Store Affects Versions: 4.2.1 CP2 Reporter: Tom Cunningham Assigned To: Tom Cunningham Fix For: 4.2.1 CP3 Got some notes from Narayanan Raghavan about his experience with the OracleAQ message provider. They are using it and it is working well but the experience getting it configured could be a little smoother : - they didn't need ojdbc14.jar (need to double check this) - they needed the "full version" of cglib.jar (the full version is in the EAP) - they found the sample jboss-esb.xml confusing - it talks about moving a message from one OracleAQ -> another OracleAQ, and there should be a sample provided of moving a message from OracleAQ - > JBoss Messaging -- 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

3
7
0 / 0

[JBoss JIRA] Created: (JBESB-1562) Investigate permgen usage

by Kevin Conner (JIRA)

Investigate permgen usage ------------------------- Key: JBESB-1562 URL: http://jira.jboss.com/jira/browse/JBESB-1562 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 4.2.1 CP1 Reporter: Kevin Conner Fix For: 4.2.1 CP2 We need to investigate the current permgen usage to make sure there are no leaks. -- 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

3
7
0 / 0

[JBoss JIRA] Created: (JBESB-1498) StackOverflowError caused by NamingContext

by Naveen Malik (JIRA)

StackOverflowError caused by NamingContext ------------------------------------------ Key: JBESB-1498 URL: http://jira.jboss.com/jira/browse/JBESB-1498 Project: JBoss ESB Issue Type: Patch Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.2.1 Environment: JBoss AS 4.2.1, Java 1.5.0_12 Reporter: Naveen Malik When starting JBoss AS 4.2.1 with JBoss ESB 4.2.1GA installed a stack overflow exception is logged several times: 2008-01-17 16:13:52,336 WARN [org.jboss.soa.esb.listeners.lifecycle.AbstractThreadedManagedLifecycle] Unexpected error from doRun() java.lang.StackOverflowError at java.lang.StringCoding.decode(StringCoding.java:228) at java.lang.String.<init>(String.java:405) at java.lang.String.<init>(String.java:433) at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:519) at java.net.Socket.connect(Socket.java:469) at java.net.Socket.<init>(Socket.java:366) at java.net.Socket.<init>(Socket.java:266) at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:84) at org.jnp.interfaces.TimedSocketFactory.createSocket(TimedSocketFactory.java:77) at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:239) at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1387) at org.jnp.interfaces.NamingContext.list(NamingContext.java:795) at javax.naming.InitialContext.list(InitialContext.java:401) at org.jboss.ha.jndi.TreeHead.list(TreeHead.java:354) at org.jboss.ha.jndi.HAJNDI.list(HAJNDI.java:161) at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:258) at $Proxy70.list(Unknown Source) at org.jnp.interfaces.NamingContext.list(NamingContext.java:802) at javax.naming.InitialContext.list(InitialContext.java:401) at org.jboss.ha.jndi.TreeHead.list(TreeHead.java:354) at org.jboss.ha.jndi.HAJNDI.list(HAJNDI.java:161) at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:258) at $Proxy70.list(Unknown Source) at org.jnp.interfaces.NamingContext.list(NamingContext.java:802) at javax.naming.InitialContext.list(InitialContext.java:401) at org.jboss.ha.jndi.TreeHead.list(TreeHead.java:354) at org.jboss.ha.jndi.HAJNDI.list(HAJNDI.java:161) at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:258) at $Proxy70.list(Unknown Source) ... at org.jnp.interfaces.NamingContext.list(NamingContext.java:802) at javax.naming.InitialContext.list(InitialContext.java:401) at org.jboss.ha.jndi.TreeHead.list(TreeHead.java:354) at org.jboss.ha.jndi.HAJNDI.list(HAJNDI.java:161) at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.ha.framework.interfaces.HARMIClient.invoke(HARMIClient.java:258) at $Proxy70.list(Unknown Source) -- 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

5
18
0 / 0

[JBoss JIRA] Created: (JBESB-952) Classloading issue for .war files within .ears

by Tom Cunningham (JIRA)

Classloading issue for .war files within .ears ---------------------------------------------- Key: JBESB-952 URL: http://jira.jboss.com/jira/browse/JBESB-952 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.2 Reporter: Tom Cunningham Assigned To: Mark Little There seems to be a classloading problem on redeploy for .WAR files within .ESB packages - and also with .WAR files side by side .ESB files in an .EAR. This was seen in JBESB-721, which was fixed by repackaging things. Basically if you have an ESB file set up like this : --- My.esb --------My.jar --------My.war --------META-INF/jboss-esb.xml The classes references in My.jar don't seem to be flushed when the .esb redeploys, because if they are accessed from .esb actions, they cause ClassCastExceptions, yet they work from the .war. helloworld_hibernate_action in SVN revision 14780 are a decent test case for 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

17 years

3
7
0 / 0

[JBoss JIRA] Created: (JBESB-2515) HttpRouter needs to be able to dynamically populate query string on per message basis

by Aaron Pestel (JIRA)

HttpRouter needs to be able to dynamically populate query string on per message basis ------------------------------------------------------------------------------------- Key: JBESB-2515 URL: https://jira.jboss.org/jira/browse/JBESB-2515 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Aaron Pestel Priority: Minor We need to be able to proxy generic HTTP requests. In this case, let's assume they are OGC WMS/WFS requests. Here is an example: http://lyceum.massgis.state.ma.us/wiki/doku.php?id=wfs:getfeature_url_filter The basic idea is that a client makes an HTTP request like this: http://server/wfs?request=getFeature&name=roads&bounds=323.32,33423.32,33... This request goes to a Web Feature Service and XML is returned with the geospatial features. In the case of WMS, an image is returned (like GoogleEarth Network Link). So, when the client makes this request to the ESB, the ESB needs to be able to capture the query string (since that's really the request payload). Currently JBR/HTTP gateway doesn't do this, but assumption is that the new Tomcat HTTP gateway will. When it does, the HttpRouter will need to be able to append that query string to the URL it is accessing for the real service implementation. Currently, the only way to get the HttpRouter to do this is to write a custom HttpMethodFactory (https://support.redhat.com/portal/restricted/caseDetail.html?caseId=283475). That's an ok workaround for now, but the end solution should not require code. There should be a simple way to pass the query string from the HttpGateway to the HttpRouter without writing code - similar to how the HttpRouter allows passing MappedHeaderList HTTP headers without writing code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years

2
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues April 2009