March 2013 - esb-issues - Jboss List Archives

[JBoss JIRA] (JBESB-3740) Clarify usage of acknowledge-mode on jms-message-filter

by Tom Cunningham (JIRA)

[ https://issues.jboss.org/browse/JBESB-3740?page=com.atlassian.jira.plugin... ] Tom Cunningham updated JBESB-3740: ---------------------------------- Fix Version/s: 4.13 (was: 4.12) > Clarify usage of acknowledge-mode on jms-message-filter > ------------------------------------------------------- > > Key: JBESB-3740 > URL: https://issues.jboss.org/browse/JBESB-3740 > Project: JBoss ESB > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Documentation > Affects Versions: 4.11 > Reporter: Tom Cunningham > Fix For: 4.13 > > > Description of problem: > The ESB Programmers Guide [1] only states that CLIENT_ACKNOWLEDGE mode can be > set on the jms-message-filter configuration, but does not talk about the > resulting > behavior, or about any restrictions. > The docs should be more clear about > - the resulting behavior if different ack modes are used > - any restrictions that apply, such as not using CLIENT_ACKNOWLEDGE mode on > non-gateway queues using jms-provider > - which providers these settings apply to (jms-provider, jms-jca-provider) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3732) ReadOnlyRemoteGatewayListenerIntegrationTest breaking Hudson build

by Tom Cunningham (JIRA)

[ https://issues.jboss.org/browse/JBESB-3732?page=com.atlassian.jira.plugin... ] Tom Cunningham updated JBESB-3732: ---------------------------------- Fix Version/s: 4.13 (was: 4.12) > ReadOnlyRemoteGatewayListenerIntegrationTest breaking Hudson build > ------------------------------------------------------------------ > > Key: JBESB-3732 > URL: https://issues.jboss.org/browse/JBESB-3732 > Project: JBoss ESB > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.11 > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Priority: Minor > Fix For: 4.13 > > > ReadOnlyRemoteGatewayListenerIntegrationTest is breaking the Hudson build : > http://hudson.qa.jboss.com/hudson/job/jboss-esb-linux/1726/consoleText > Going to try commenting out that single test to see if the Hudson build can successfully complete after that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3723) Add support for WS-Security UsernameToken with digested password, nonces and timestamps.

by Tom Cunningham (JIRA)

[ https://issues.jboss.org/browse/JBESB-3723?page=com.atlassian.jira.plugin... ] Tom Cunningham updated JBESB-3723: ---------------------------------- Fix Version/s: 4.13 (was: 4.12) > Add support for WS-Security UsernameToken with digested password, nonces and timestamps. > ---------------------------------------------------------------------------------------- > > Key: JBESB-3723 > URL: https://issues.jboss.org/browse/JBESB-3723 > Project: JBoss ESB > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Security, Web Services > Affects Versions: 4.10 > Environment: JBoss SOA-Platform 5.2.0 > Reporter: Duncan Doyle > Fix For: 4.13 > > Attachments: jboss-esb.xml, jboss-web.xml, jboss-wsse-server.xml, SimpleWssecurityUsernameToken.java, UserDigestPassCallbackHandler.java, WssecurityUsernametoken.java > > > Current support for WS-Security UsernameToken in JBoss ESB is limited to usernames and passwords passed in plain text in the WS-Security SOAP header. JBossWS supports UsernameToken with digested passwords, nonces and timestamps. So, an ESB service could be fronted with a JBossWS webservice with UsernameToken with digested password and nonce, which can call the ESB service via ServiceInvoker, or which can be used in an ActionPipeline via SOAPProcessor. However, in that case, the authenticated user (and his roles) will not be propagated through the ESB services as no AuthenticationRequest is set on the ESB message. This has the big disadvantage that the ESB services themselves can not be secured. > The attached code shows an implementation which is able to retrieve the username, digested password, nonce and timestamp from within a JAX-WS endpoint. This data is used to create an ESB AuthenticationRequest, where nonce and timestamp are set on the properties map. The new UserDigestPassCallbackHandler is based on the UserPassCallbackHandler and is able to retrieve the nonce and timestamp from the AuthenticationRequest and make them availble to the UsernameTokenCallback. > This solution provides the ability to propagate the original user and his roles through the entire services chain. It also allows the ESB services to use the same security-domain configuration as the JAX-WS endpoint. > I'm aware that the JAX-WS endpoint code might be hard to include in the ESB platform itself, but, if it can not be included in a default component, it might be a nice idea to include this example in one of the quickstarts. > The 'application-policy' used in this setup is the setup from the Web Services chapter in the JBoss EAP 5.1 Administration and Configuration Guide: > <application-policy name="jbossws-domain"> > <authentication> > <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"> > <module-option name="usersProperties">props/jbossws-domain-users.properties</module-option> > <module-option name="rolesProperties">props/jbossws-domain-roles.properties</module-option> > <module-option name="hashAlgorithm">SHA</module-option> > <module-option name="hashEncoding">BASE64</module-option> > <module-option name="hashUserPassword">false</module-option> > <module-option name="hashStorePassword">true</module-option> > <module-option name="storeDigestCallback">org.jboss.ws.extensions.security.auth.callback.UsernameTokenCallback</module-option> > </login-module> > </authentication> > </application-policy> -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBESB-2272) ESB testable against external binaries (product test suite)

by Tom Cunningham (JIRA)

[ https://issues.jboss.org/browse/JBESB-2272?page=com.atlassian.jira.plugin... ] Tom Cunningham updated JBESB-2272: ---------------------------------- Fix Version/s: 4.13 (was: 4.12) > ESB testable against external binaries (product test suite) > ----------------------------------------------------------- > > Key: JBESB-2272 > URL: https://issues.jboss.org/browse/JBESB-2272 > Project: JBoss ESB > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Testing > Affects Versions: 4.2.1 CP1, 4.2.1 CP2, 4.2.1 CP3, 4.2.1 CP4 > Reporter: Aleksandar Kostadinov > Assignee: Tom Cunningham > Fix For: 4.13 > > Attachments: external-esb.patch > > > When running the ESB test suite against external binaries, there is currently a mismatch between libraries downloaded by the test suite and libraries found in the external distribution. This makes running the suite against the external JBoss AS distribution meaningless because doesn't prove ESB will work with the libraries found in the JBoss AS server. > As a solution I see, the various junit tasks run by the testsuite should have classpath point at the libraries in the JBoss AS rather than these generated during build and downloaded by the build script. Running the test suite against external binaries should be the same as verifying an ESB installation (be it on top of JBoss AS or standalone). > The issue supersedes JBESB-1513 and is the cause of JBESB-1711. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3735) Error Handling in docs needs clarification

by Tom Cunningham (JIRA)

[ https://issues.jboss.org/browse/JBESB-3735?page=com.atlassian.jira.plugin... ] Tom Cunningham updated JBESB-3735: ---------------------------------- Fix Version/s: 4.13 (was: 4.12) > Error Handling in docs needs clarification > ------------------------------------------ > > Key: JBESB-3735 > URL: https://issues.jboss.org/browse/JBESB-3735 > Project: JBoss ESB > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Documentation > Affects Versions: 4.11 > Reporter: Tom Cunningham > Fix For: 4.13 > > > In ESB Programmers Guide, chapter "Error Handling When Actions are Being Processed" need clarification on action processing pipeline's behavior when an exception is thrown in an action's process() method. > There is no clear statement what should happen with the pipeline execution. Will following actions be executed? Or is the execution interrupted immediately? Or does it depend on the exception type? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3721) NullPointerException deploying a scheduled-listener with invalid scheduleidref attribute

by Tom Cunningham (JIRA)

[ https://issues.jboss.org/browse/JBESB-3721?page=com.atlassian.jira.plugin... ] Tom Cunningham updated JBESB-3721: ---------------------------------- Fix Version/s: 4.13 (was: 4.12) > NullPointerException deploying a scheduled-listener with invalid scheduleidref attribute > ---------------------------------------------------------------------------------------- > > Key: JBESB-3721 > URL: https://issues.jboss.org/browse/JBESB-3721 > Project: JBoss ESB > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Deployment > Affects Versions: 4.10 > Reporter: Martin Weiler > Fix For: 4.13 > > > Deploying a service with a schedule-listener using an incorrect value for the scheduleidref attribute results in a NullPointerException: > {noformat} > ERROR [AbstractKernelController] Error installing to Start: name=jboss.esb.vfszip:/data/jboss/work/jboss-soa-p-5.2.0.GA/jboss-as/server/test/deploy/Quickstart_scheduled_services.esb/ state=Create > java.lang.RuntimeException: java.lang.NullPointerException > at org.jboss.soa.esb.listeners.config.Configuration.create(Configuration.java:185) > ... > Caused by: java.lang.NullPointerException > at org.jboss.soa.esb.listeners.config.mappers.ScheduleMapper.map(ScheduleMapper.java:61) > at org.jboss.soa.esb.listeners.config.mappers.ESBAwareGenerator.addESBAwareConfig(ESBAwareGenerator.java:216) > at org.jboss.soa.esb.listeners.config.mappers.ESBAwareGenerator.generate(ESBAwareGenerator.java:102) > at org.jboss.soa.esb.listeners.config.mappers.XMLBeansModel.generateESBAwareConfig(XMLBeansModel.java:441) > {noformat} > The existence of the referenced schedule-provider should be verified, and if it does not exist, a meaningful exception should be thrown instead of the NullPointerException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3693) Remove connections properties and tests from jbossesb-properties.xml

by Tom Cunningham (JIRA)

[ https://issues.jboss.org/browse/JBESB-3693?page=com.atlassian.jira.plugin... ] Tom Cunningham updated JBESB-3693: ---------------------------------- Fix Version/s: 4.13 (was: 4.12) > Remove connections properties and tests from jbossesb-properties.xml > -------------------------------------------------------------------- > > Key: JBESB-3693 > URL: https://issues.jboss.org/browse/JBESB-3693 > Project: JBoss ESB > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 4.10 > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Fix For: 4.13 > > > The connections part of the jbossesb-properties.xml is obsoleted (found nowhere in code). Remove it from jbossesb-properties.xml files and tests, as well as the "connection" entries in ModulePropertyManager > <properties name="connection"> > <property name="min-pool-size" value="5"/> > <property name="max-pool-size" value="10"/> > <property name="blocking-timeout-millis" value="5000"/> > <property name="abandoned-connection-timeout" value="10000"/> > <property name="abandoned-connection-time-interval" value="30000"/> > </properties> -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3644) Create pom for rosetta JAR

by Tom Cunningham (JIRA)

[ https://issues.jboss.org/browse/JBESB-3644?page=com.atlassian.jira.plugin... ] Tom Cunningham updated JBESB-3644: ---------------------------------- Fix Version/s: 4.13 (was: 4.12) > Create pom for rosetta JAR > -------------------------- > > Key: JBESB-3644 > URL: https://issues.jboss.org/browse/JBESB-3644 > Project: JBoss ESB > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Build and Release > Affects Versions: 4.10 > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Fix For: 4.13 > > > Need a pom.xml detailing the dependencies of the rosetta JAR so that we can release this to maven repositories. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3856) IterableTimedCache expiry causes deployment issues with Camel non-core components

by Tom Cunningham (JIRA)

[ https://issues.jboss.org/browse/JBESB-3856?page=com.atlassian.jira.plugin... ] Tom Cunningham updated JBESB-3856: ---------------------------------- Fix Version/s: 4.13 (was: 4.12) > IterableTimedCache expiry causes deployment issues with Camel non-core components > --------------------------------------------------------------------------------- > > Key: JBESB-3856 > URL: https://issues.jboss.org/browse/JBESB-3856 > Project: JBoss ESB > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Deployment > Affects Versions: 4.11 > Environment: > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Fix For: 4.13 > > > There's a problem with deployment of esb application, where the camel gateway is used . > If is the application deployed right after the server start, there's no problem. But if you wait about 30-60 minutes, error occurs, and about 100 of this error message are shown: > DEBUG [JBossPackageScanClassResolver] Cannot find class 'apache/camel/converter/stream/InputStreamCache.class' in any classloaders: [BaseClassLoader@2444569{vfszip:/home/rbalent/qa/tests/quickstarts/tests/output/lib/Quickstart_camel_http.esb/}] > To see the messages you must set log threshold to DEBUG. > To reproduce it, just start server, deploy attached Quickstart_camel_http.esb, then you will see the correct message in server log: > BEFORE** > Camel HTTP Hello World! > AFTER** > Lines "BEFORE**", and "AFTER**" are added to find the message body in server log easier. > then undeploy Quickstart_camel_http.esb and wait about 30-60 minutes. After this time, deploy the esb package again. You will see the mentioned lines in server log, and incorrect message body: > The received message will look like this: > BEFORE** > java.io.ByteArrayInputStream@6c515139AFTER** > After server restart it works again. > Quickstart_camel_http.esb, server log of successful deployment and failed deployment are attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3629) Provide alternative registry implementation

by Tom Cunningham (JIRA)

[ https://issues.jboss.org/browse/JBESB-3629?page=com.atlassian.jira.plugin... ] Tom Cunningham updated JBESB-3629: ---------------------------------- Fix Version/s: 4.13 (was: 4.12) > Provide alternative registry implementation > ------------------------------------------- > > Key: JBESB-3629 > URL: https://issues.jboss.org/browse/JBESB-3629 > Project: JBoss ESB > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Registry and Repository > Affects Versions: 4.10 CP1 > Reporter: Tom Cunningham > Assignee: Tom Cunningham > Fix For: 4.13 > > > The issue here is: in a cluster environment, after a malfunction on JBoss (e.g. JVM crash, erroneous deployment etc) the registry remains with invalid endpoints and the ESB has an erroneous behavior by using those endpoints. Even your removeDeadEPR property is unusable, because as stated in the documentation the "the end-point reference for a service that is [...] slow to respond may, inadvertently, be removed from the registry by mistake". > Since we have a cluster and to manually clean the DB is not just to drop the tables and restart the server, this is a major issue for us, because it can lead to erroneous service calls if a server node crashes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues March 2013