[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, 10 months
[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, 11 months
[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, 11 months
[JBoss JIRA] Created: (JBESB-1574) Add freemarker support to soapui-client smook transoformation
by Stefano Maestri (JIRA)
Add freemarker support to soapui-client smook transoformation
-------------------------------------------------------------
Key: JBESB-1574
URL: http://jira.jboss.com/jira/browse/JBESB-1574
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Stefano Maestri
Assigned To: Stefano Maestri
Tom fennely says:
<tfennelly> I just had a quick look at that soapclient stuff and it doesn't support dynamic values going into the transforms, but it wouldn't be difficult to add it
<maeste> ok, perfect, I can take a look if is fine for you. Any hints?
<tfennelly> sure
<maeste> I'm going to open a Jira issue
<tfennelly> so look at the SoapUIClientService class in the soapui-client service
<tfennelly> sure
<tfennelly> it receives a parameter map that contains the params to be mapped into the SOAP request template
<tfennelly> you could also use this map to carry the params that are to be used in the transformation
<tfennelly> e.g. a value to be inserted as a header
<maeste> ok I see
<tfennelly> just push this map into the applySmooksTransform and set it into the BeanAccessor context
<tfennelly> Ithis will make this map available to e.g. freemarker templates
<tfennelly> then you just write a freemarker template that uses the dynamic value...
<tfennelly> smooks will add the result of the templating op to the SOAP header
--
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, 11 months