[JBoss JIRA] (JBESB-3777) Failed to install JBoss ESB 4.11 on JBoss AS 6.1(6.0)
by Dmytro Polivenok (JIRA)
Dmytro Polivenok created JBESB-3777:
---------------------------------------
Summary: Failed to install JBoss ESB 4.11 on JBoss AS 6.1(6.0)
Key: JBESB-3777
URL: https://issues.jboss.org/browse/JBESB-3777
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Configuration
Affects Versions: 4.11
Reporter: Dmytro Polivenok
Unable to install JBoss ESB 4.11 on JBoss AS 6.1 (6.0).
...
internal.deploy.jbossas6:
[copy] Copying 1 file to .../jboss-6.1.0.Final/server/default/deployers/esb.deployer/META-INF
[copy] Copying 1 file to .../jboss-6.1.0.Final/server/default/deployers/esb.deployer/lib
[copy] Copying 1 file to .../jboss-6.1.0.Final/server/default/deploy/jbpm.esb
[copy] Copying 1 file to .../jboss-6.1.0.Final/server/default/deployers/jbossws.deployer
[mkdir] Created dir: .../jboss-6.1.0.Final/server/default/data
BUILD FAILED
.../jbossesb-4.11/install/build.xml:555: Warning: Could not find file .../jbossesb-4.11/install/jUDDI-registryV3/esb-juddi-orm-as6_1.xml to copy.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (JBESB-3775) jboss-esb.xml to support HttpRouter dynamic endpoit URLs
by Diógenes Guedes Rettori (JIRA)
Diógenes Guedes Rettori created JBESB-3775:
----------------------------------------------
Summary: jboss-esb.xml to support HttpRouter dynamic endpoit URLs
Key: JBESB-3775
URL: https://issues.jboss.org/browse/JBESB-3775
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Configuration, Transports
Reporter: Diógenes Guedes Rettori
jboss-esb.xml should be able to support the dynamic definition of the HttpRouter endpointURL via parametrization and not static as it is today on the jboss-esb.xml file.
We have received requests for this features from some of our clients. Bottom line is clients are not willing to develop this programatically, but either use JBoss Developer Studio to specify this dynamic URL, but in order to do it, the jboss-esb.xml has to support it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (JBESB-3752) ServiceInvoker behaviour is inconsistent when used with transactions
by Michael Burman (JIRA)
Michael Burman created JBESB-3752:
-------------------------------------
Summary: ServiceInvoker behaviour is inconsistent when used with transactions
Key: JBESB-3752
URL: https://issues.jboss.org/browse/JBESB-3752
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transports
Affects Versions: 4.10
Environment: JBoss SOA 5.2.0 Platform
Reporter: Michael Burman
The ServiceInvoker behaviour is inconsistent when it comes to XA transactions. If the delivery fails with ServiceInvoker (there's a network timeout or something), the transaction is still committed, because it does not throw a RuntimeException. So instead of rolling back everything you just did in your actions, the staticRouter or such would commit the process and then throw this to DLQ. So when you run it from DLQ, you would again write to the database and so on. With SmooksSplitter this might cause some messages to go through and some not and other weird behaviour.
One fix would be to patch ServiceInvoker deliverAsync (as an example, deliverSync should be fixed also):
### Eclipse Workspace Patch 1.0
#P JBossESB
Index: rosetta/src/org/jboss/soa/esb/client/ServiceInvoker.java
===================================================================
--- rosetta/src/org/jboss/soa/esb/client/ServiceInvoker.java (revision 37896)
+++ rosetta/src/org/jboss/soa/esb/client/ServiceInvoker.java (working copy)
@@ -46,9 +46,9 @@
import org.jboss.soa.esb.couriers.Courier;
import org.jboss.soa.esb.couriers.CourierException;
import org.jboss.soa.esb.couriers.CourierFactory;
-import org.jboss.soa.esb.couriers.CourierTimeoutException;
import org.jboss.soa.esb.couriers.CourierMarshalUnmarshalException;
import org.jboss.soa.esb.couriers.CourierServiceBindException;
+import org.jboss.soa.esb.couriers.CourierTimeoutException;
import org.jboss.soa.esb.couriers.CourierTransportException;
import org.jboss.soa.esb.couriers.CourierUtil;
import org.jboss.soa.esb.couriers.FaultMessageException;
@@ -57,6 +57,7 @@
import org.jboss.soa.esb.listeners.ha.LoadBalancePolicy;
import org.jboss.soa.esb.listeners.ha.ServiceClusterInfo;
import org.jboss.soa.esb.listeners.ha.ServiceClusterInfoImpl;
+import org.jboss.soa.esb.listeners.jca.JcaGatewayException;
import org.jboss.soa.esb.listeners.message.IncompatibleTransactionScopeException;
import org.jboss.soa.esb.listeners.message.MessageDeliverException;
import org.jboss.soa.esb.listeners.message.MissingServiceException;
@@ -253,6 +254,12 @@
try {
post(message, new EPRInvoker());
} catch (MessageDeliverException mde) {
+
+ // We want to trigger JCA rollback in case of messagedeliver exception
+ if(isTransactional()) {
+ throw new JcaGatewayException(mde);
+ }
+
if (message.getProperties().getProperty(RedeliverStore.IS_REDELIVERY)==null
&& asyncRedelivery(message)
&& !service.equals(dlqService)) {
Here's a quickstart that provides a small example (replace correctBehaviour="true" to get JMS rollbacks), it just tries to call some nonexistant gateway to throw MessageDeliveryException (if there's a proper way to cause timeout in the code, then let me know, but the exception is never the less the same).
https://s3-eu-west-1.amazonaws.com/yak/jboss/jms_transacted_fail.zip
Once you run it with original settings and it fails, you still end up with lines in the database.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (JBESB-3780) BinarySecurityToken class hardwired to X.509 certificates
by Tom Cunningham (JIRA)
Tom Cunningham created JBESB-3780:
-------------------------------------
Summary: BinarySecurityToken class hardwired to X.509 certificates
Key: JBESB-3780
URL: https://issues.jboss.org/browse/JBESB-3780
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: 4.5
Reporter: Rune Molin
Assignee: Tom Cunningham
Fix For: 4.11
In order to support WS Security Kerberos Token Profile at a later time, please make the class org.jboss.soa.esb.services.security.auth.ws.BinarySecurityToken abstract. Currently it is hardwired to only support X.509 Certificate Token Profile.
By making this class abstract sooner rather than later, users could implement Kerberos Token Profile themselves, without having to duplicate too much code. This will of course mean moving the existing certificate bound implementation into a new class, CertificateSecurityToken perhaps
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (JBESB-3778) XMLHelper fails to load XSD referenced in jboss-esb.xml and fails with a misleading error message.
by Marek Baluch (JIRA)
Marek Baluch created JBESB-3778:
-----------------------------------
Summary: XMLHelper fails to load XSD referenced in jboss-esb.xml and fails with a misleading error message.
Key: JBESB-3778
URL: https://issues.jboss.org/browse/JBESB-3778
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: 4.11, 4.10
Reporter: Marek Baluch
In case we have the following ESB definition (please note that the xsd path is not prefixed by '/')
{code}
<actions faultXsd="ValidacionDatosFault.xsd" ...>
{code}
deployment will fail with
Caused by: org.xml.sax.SAXParseException: Content is not allowed in prolog.
...
The message is misleading because the XSD file will not be found. The problem lies in the fact that the ValidacionDatosFault.xsd is not prefixed by "/". The URI for that resource will look like "classpath://ValidacionDatosRequest.xsd" and the getPath() method will return an empty string which will be passed as argument to ClassUtil.getResource(String, Class).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (JBESB-3758) RecordRoute functionality on both service and message basis
by Tom Cunningham (JIRA)
Tom Cunningham created JBESB-3758:
-------------------------------------
Summary: RecordRoute functionality on both service and message basis
Key: JBESB-3758
URL: https://issues.jboss.org/browse/JBESB-3758
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Rosetta
Affects Versions: 4.11
Reporter: Tom Cunningham
Assignee: Tom Cunningham
Fix For: 4.11
Provide new, optional configuration options for ESB services to specify that the
message header should be updated upon service entry and service exit. This
allows users to track the history of the message through a set of services to see
what path it took. Reasonable default value to capture is the service name. This
is not intended to be a routing ticket.
Comments: A suggestion would be to include a 'record route' option for a service and
message, placing the information within the message context. The information
should start with the originator (service, gateway, client) and add other services
as the message progresses. We already have the EntryExitTimeFilter and
GatewayFilters, I'm sure it would be easy to extend their functionality and link in
to the current service information.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months