[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
[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
[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
[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
[JBoss JIRA] Created: (JBESB-2465) HttpProtocol class should check SOAP endpoint address in stead of target-host-url property
by Gerbrand de Goeij (JIRA)
HttpProtocol class should check SOAP endpoint address in stead of target-host-url property
------------------------------------------------------------------------------------------
Key: JBESB-2465
URL: https://jira.jboss.org/jira/browse/JBESB-2465
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: 4.5
Reporter: Gerbrand de Goeij
In the org.jboss.soa.esb.http.configurators.HttpProtocol class, in the method configure there is a check if the scheme of the targetURI starts with "http".
But when you want to use a WSDL that is located on the file system (ie. because the WSDL is not available online) this piece of code does not work (because in my case the targetURI (property "target-host-url") starts with "file://...".
Therefore I think it's better to base the decision on which ProtocolSocketFactory should be used upon the SOAP endpoint address (in stead of the WSDL location URI).
--
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 month
[JBoss JIRA] Created: (JBESB-2501) Monitoring details needed on individual messages
by Tom Cunningham (JIRA)
Monitoring details needed on individual messages
------------------------------------------------
Key: JBESB-2501
URL: https://jira.jboss.org/jira/browse/JBESB-2501
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Management
Affects Versions: 4.5
Reporter: Tom Cunningham
Assignee: Tom Cunningham
We need to expand support for monitoring to include some sort of trace on an individual message - which is a feature we've talked about for some time. The first level of this support would probably be being able to track a "tracer bullet" message through header id's and keeping statistics on that message.
>From Burr's notes from Cybercity:
"Governance: tracebility of messages, message header logging, draw a graph to show each place a message visits, trace back to a failure where did the message visit prior to that failure, we are currently using JON but only seeing the aggregate numbers, not actually seeing which messages impacted the failing services. Record the message headers to see the back-trail.
and
-- The msg count/failure count isn't valuable, monitoring of the log (via JON alert based on ERROR or FATAL) is more valuable
-- Start & stop individual listeners vs the whole esb archive.
-- SLAs are important, hard to define in JON like if this service has a response time slower than X then alert. The current response time is an average, we want to look for discreet response times (avg at 5 secs but 1 message at 20 secs then alert)"
--
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 month