December 2008 - esb-issues - Jboss List Archives

[JBoss JIRA] Created: (JBESB-1996) Evaluate, if a AS/400 Dataqueue Ressource Adapter is usable for Jboss and/or Jboss ESB

by Heiko Wiesjbossner (JIRA)

Evaluate, if a AS/400 Dataqueue Ressource Adapter is usable for Jboss and/or Jboss ESB -------------------------------------------------------------------------------------- Key: JBESB-1996 URL: https://jira.jboss.org/jira/browse/JBESB-1996 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Adapters Reporter: Heiko Wiesjbossner A Dataqueue is like a jms queue on IBM's (AS/400 / Iseries / System i / and all the other names for the AS/400). Whith the Ressource Adapter i wrote you can transform the Dataqueue Message into a jms Message without any coding. Configuration is made with annotations. The rest is handled by the RA. I think, this is the best way to connect from old school RPG or Cobol Applications to J2EE. It is a very performant and ressource saving way. -- 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

15 years, 8 months

3
7
0 / 0

[JBoss JIRA] Created: (JBESB-1678) Style in ESB management console is invalid

by Jiri Pechanec (JIRA)

Style in ESB management console is invalid ------------------------------------------ Key: JBESB-1678 URL: http://jira.jboss.com/jira/browse/JBESB-1678 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Tooling Affects Versions: 4.2.1 CP2 Reporter: Jiri Pechanec Assigned To: Tom Cunningham Priority: Minor The file style_master.css in ESB console contains invalid style definition, see snippet TH { background-color : #000099; color: #DEB887; font-weight: bold; }.bg_table { background-color : #DEB887; } }.bg_cell{ background-color : #ffffff; } The bg_cell definition is orphaned. -- 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, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (JBESB-1797) Repackage management console

by Kevin Conner (JIRA)

Repackage management console ---------------------------- Key: JBESB-1797 URL: http://jira.jboss.com/jira/browse/JBESB-1797 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Management Affects Versions: 4.3 Reporter: Kevin Conner Fix For: 4.4 We need to revisit the packaging of the management console and come up with a solution that allows the modification of the database without recompiling the code. -- 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, 8 months

2
4
0 / 0

[JBoss JIRA] Created: (JBESB-2185) Patch for [jUDDI retains invalid EPRs]

by Joakim Sandström (JIRA)

Patch for [jUDDI retains invalid EPRs] -------------------------------------- Key: JBESB-2185 URL: https://jira.jboss.org/jira/browse/JBESB-2185 Project: JBoss ESB Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: 4.4 Reporter: Joakim Sandström Patch for 'jUDDI retains invalid EPRs' issue (JBESB-866). Patch: The RegistryUtil.register method unregisters matching EPR's using unregister(category, name, epr) before (re)registering the same EPR. Not included in the patch: Registry.unRegisterEPR(serviceCategoryName, serviceName, epr) could return a boolean true/false and not raise a ServiceNotFoundException if the service isn't found - to avoid unneccesary stack traces in the log. -- 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

15 years, 8 months

3
13
0 / 0

[JBoss JIRA] Created: (JBESB-1646) Add support for making schedule-provider Jobs clusterable

by Tom Fennelly (JIRA)

Add support for making schedule-provider Jobs clusterable --------------------------------------------------------- Key: JBESB-1646 URL: http://jira.jboss.com/jira/browse/JBESB-1646 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rosetta Reporter: Tom Fennelly This should support "singleton" execution of a job in a clustered env, with fail-over etc. See http://java-x.blogspot.com/2006/12/using-quartz-scheduler-in-cluster.html -- 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, 9 months

3
2
0 / 0

[JBoss JIRA] Created: (JBESB-2203) Duplicate service names during cluster startup

by Joakim Sandström (JIRA)

Duplicate service names during cluster startup ---------------------------------------------- Key: JBESB-2203 URL: https://jira.jboss.org/jira/browse/JBESB-2203 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Registry and Repository Affects Versions: 4.4 Environment: jboss esb cluster, replicated mysql 5.1. Reporter: Joakim Sandström If I startup more than one cluster node at the same time when uddi is empty it will be populated as follows: -Service A -- node1 EPR -Service A -- node2 EPR Expected uddi content; -Service A --node1 EPR --node2 EPR The esb cluster nodes access the same mysq node (transaction READ_COMMITTED). -- 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

15 years, 9 months

3
5
0 / 0

[JBoss JIRA] Created: (JBESB-1936) Create a contract publisher to handle remote WS endpoints

by Kevin Conner (JIRA)

Create a contract publisher to handle remote WS endpoints --------------------------------------------------------- Key: JBESB-1936 URL: https://jira.jboss.org/jira/browse/JBESB-1936 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Web Services Affects Versions: 4.4 Reporter: Kevin Conner Fix For: 4.5 We have a contract publisher that exposes wsdl for a co-located JBoss WS endpoint, WebserviceContractPublisher. We should have an equivalent that can be used to expose the wsdl of remote services through the ESB. -- 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

15 years, 9 months

3
9
0 / 0

[JBoss JIRA] Created: (JBESB-2127) Text supplied to the TEXTVALUE field of JMXDATA table too long

by Lukas Petrovicky (JIRA)

Text supplied to the TEXTVALUE field of JMXDATA table too long -------------------------------------------------------------- Key: JBESB-2127 URL: https://jira.jboss.org/jira/browse/JBESB-2127 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.4 Reporter: Lukas Petrovicky When running the SOA-P 4.3 testsuite on Oracle, one of the tests (Notifiers QS) found the following problem: 2008-10-17 04:20:07,500 WARN [org.hibernate.util.JDBCExceptionReporter] SQL Error: 12899, SQLState: 72000 2008-10-17 04:20:07,500 ERROR [org.hibernate.util.JDBCExceptionReporter] ORA-12899: value too large for column "SOAQRHEL4"."JMXDATA"."TEXTVALUE" (actual: 2041, maximum: 2000) 2008-10-17 04:20:07,500 WARN [org.hibernate.util.JDBCExceptionReporter] SQL Error: 12899, SQLState: 72000 2008-10-17 04:20:07,500 ERROR [org.hibernate.util.JDBCExceptionReporter] ORA-12899: value too large for column "SOAQRHEL4"."JMXDATA"."TEXTVALUE" (actual: 2041, maximum: 2000) 2008-10-17 04:20:07,501 ERROR [org.hibernate.event.def.AbstractFlushingEventListener] Could not synchronize database state with session org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103) at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:254) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:237) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:141) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) at org.jboss.soa.esb.monitoring.server.DataFiler.insertStatistics(DataFiler.java:194) at org.jboss.soa.esb.monitoring.server.DataFiler.persistData(DataFiler.java:230) at org.jboss.soa.esb.monitoring.server.FilerAction.fileMessage(FilerAction.java:70) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.soa.esb.listeners.message.ActionProcessorMethodInfo.processMethods(ActionProcessorMethodInfo.java:102) at org.jboss.soa.esb.listeners.message.OverriddenActionLifecycleProcessor.process(OverriddenActionLifecycleProcessor.java:74) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.processPipeline(ActionProcessingPipeline.java:520) at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:392) at org.jboss.soa.esb.listeners.message.MessageAwareListener$TransactionalRunner.run(MessageAwareListener.java:538) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) Caused by: java.sql.BatchUpdateException: ORA-12899: value too large for column "SOAQRHEL4"."JMXDATA"."TEXTVALUE" (actual: 2041, maximum: 2000) at oracle.jdbc.driver.DatabaseError.throwBatchUpdateException(DatabaseError.java:343) at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:10698) at org.jboss.resource.adapter.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:620) at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:48) at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:247) ... 22 more Further information can be found in the server log of that build: http://hudson.qa.jboss.com/hudson/view/SOA-Release/job/soa-it-db-jdk15/35... This issue seems to be related to JBESB-1348, if not the same. It doesn't happen anywhere else but Oracle. -- 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

15 years, 9 months

5
9
0 / 0

[JBoss JIRA] Created: (JBESB-2132) JBossRemotingGatewayListener: Allow the sync invocation timeout to be configurable

by Tom Fennelly (JIRA)

JBossRemotingGatewayListener: Allow the sync invocation timeout to be configurable ---------------------------------------------------------------------------------- Key: JBESB-2132 URL: https://jira.jboss.org/jira/browse/JBESB-2132 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transports Reporter: Tom Fennelly Priority: Minor Fix For: 4.x It's currently hardcoded at 20 seconds. -- 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

15 years, 9 months

4
7
0 / 0

[JBoss JIRA] Created: (JBESB-1557) JBossRemotingGateway listener should support multiple listeners for the same host port combination

by Daniel Bevenius (JIRA)

JBossRemotingGateway listener should support multiple listeners for the same host port combination -------------------------------------------------------------------------------------------------- Key: JBESB-1557 URL: http://jira.jboss.com/jira/browse/JBESB-1557 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Transports Affects Versions: 4.3 Reporter: Daniel Bevenius Assigned To: Daniel Bevenius Fix For: 4.3 Add support for having multiple jbr listeners listen to the same host port combination: <jbr-provider name="JBR-Http" protocol="http" host="localhost" path="service1"> <jbr-bus busid="Http-1" port="8765" /> </jbr-provider> <jbr-provider name="JBR-Http2" protocol="http" host="localhost" path="service2"> <jbr-bus busid="Http-2" port="8765"/> </jbr-provider> Also notice the addition of the path configuration parameter. This is intended to identify the path that will be used by a ws client that calls the service. Talked to Tom and he suggested placing the path property on the jbr-bus element so I'll change that. The attached example uses this way just as a proof-of-concept (too lazy to change it right now) The path is used by the JBossRemoteGatewayListener as the subsystem when adding InvokationHandlers to a Connector. So we are bascically keeping track of JBoss Remting Connectors that share the same host/port combination, and adding InvokationHandlers to them with the above specifed path as their subsystem. This solution requires that the JBoss Remoting ServerInvoker be modified and adding something like this: String subsystem = invocation.getSubsystem(); String clientId = invocation.getSessionId(); Map requestPayload = invocation.getRequestPayload(); if ( subsystem == null && requestPayload != null ) { String path = (String) requestPayload.get( HTTPMetadataConstants.PATH ); subsystem = path.substring( path.indexOf( '/' ) + 1 ); } log.info( "subsystem : " + subsystem ); This is needed so it can set the incoming path as the target subsystem. I'm not sure if this is the best way to do this but I'll ask in the Remoting forum if they have a better suggestion. Really, the gain with this is that we can have multiple webservice running in a ESB instance using the same port. This is important because we it becomes difficult opening a separate port for every web service. This is the issue we are facing at the moment. Note that this solution does not work when running multiple ESB instances on the same machine, as this would still cause a port conflict. The solution is specific to a single JVM. Any thought or comments on 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

15 years, 9 months

3
15
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues December 2008