February 2012 - esb-issues - Jboss List Archives

[JBoss JIRA] (JBESB-3738) Upgrade helloworld_action/Oracle AQ quickstart

by Tom Cunningham (JIRA)

Tom Cunningham created JBESB-3738: ------------------------------------- Summary: Upgrade helloworld_action/Oracle AQ quickstart Key: JBESB-3738 URL: https://issues.jboss.org/browse/JBESB-3738 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.11 Reporter: Tom Cunningham Assignee: Tom Cunningham Fix For: 4.11 Customer-provided tips for working with Oracle AQ: 1. Schema different to User If the configuration of the adapter has been selected as that using the URL, rather than the individual configuration elements, then the 'SCHEMA' element is not discussed in the documentation. This could cause a problem if the connect as user/password is different to the actual owner of the queue. To get round this, we have configured our adapter as follows: <jms-provider connection-factory="ConnectionFactory" name="JBossAQ"> <property name="java.naming.factory.initial" value="org.jboss.soa.esb.oracle.aq.AQInitialContextFactory"/> <property name="java.naming.oracle.aq.user" value="${eessi.oracle.aq.user}"/> <property name="java.naming.oracle.aq.password" value="${eessi.oracle.aq.password}"/> <property name="java.naming.oracle.aq.url" value="${eessi.oracle.aq.url}"/> <property name="java.naming.oracle.aq.schema" value="${eessi.oracle.aq.queue.owner}"/> Also, we have had to change the adapter class AQInitialContextFactory as follows: public void init(Hashtable<?, ?> env) { dbuser = (String) env.get(AQInitialContextFactory.DB_USER); dbpass = (String) env.get(AQInitialContextFactory.DB_PASSWD); aqConnectionUrl = (String) env.get(AQInitialContextFactory.DB_CONNECTION_URL); // Added by DH to allow for schema to be set if provided alongside the URL if (env.get(AQInitialContextFactory.DB_SCHEMA)!=null) { aqSchemaName = (String) env.get(AQInitialContextFactory.DB_SCHEMA); } else { aqSchemaName = (String) env.get(AQInitialContextFactory.DB_USER); } if (aqConnectionUrl == null ) { aqServerName = (String) env.get(AQInitialContextFactory.DB_SERVER); aqServerDBInst = (String) env.get(AQInitialContextFactory.DB_INSTANCE); aqDBDriver = (String) env.get(AQInitialContextFactory.DB_DRIVER); aqSchemaName = (String) env.get(AQInitialContextFactory.DB_SCHEMA); aqServerPort = (String) env.get(AQInitialContextFactory.DB_PORT); if (aqServerPort != null) { try { aqServerPortNumber = Integer.parseInt(aqServerPort); } catch (NumberFormatException e) { log.error("caught exception converting port", e); } } } } This allows the configuration to be a little more flexible. 2. Same named queue/queue table across multiple schemas. If, for example, on a test instance, multiple schemas own the same named queue, then the query in the AQUtil class is not correct. By not joining queue table owner to queue owner, a semi cartesian product ensues and binding to the correct queue is not always possible (success will depend on the ordering of the returned records in the resultset). to fix this, we have changed the AQUtil class as follows: private static final String GET_QUEUES_PSQL = "SELECT allq.OWNER as owner, allq.NAME as name, allq.QUEUE_TYPE as queue_type, allqt.RECIPIENTS as recipients" + " from SYS.ALL_QUEUES allq, SYS.ALL_QUEUE_TABLES allqt " + " where allq.QUEUE_TABLE = allqt.QUEUE_TABLE and upper(allq.OWNER) in (?) and allqt.owner = allq.owner order by name asc"; You will need to change the GET_QUEUES_SQL statement to reflect this fix also. -- 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, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBESB-3486) RemoteFileSystemFactory should also support ConfigTree

by Joakim Sandstroem (JIRA)

RemoteFileSystemFactory should also support ConfigTree ------------------------------------------------------ Key: JBESB-3486 URL: https://jira.jboss.org/browse/JBESB-3486 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Adapters Affects Versions: 4.9, 4.4 CP4, 4.8, 4.7 CP2, 4.7 CP1, 4.7, 4.6 Reporter: Joakim Sandstroem org.jboss.soa.esb.util.RemoteFileSystemFactory only supports FTPEpr, it should also provide a factory method that takes a ConfigTree - The configuration tree can then contain RemoteFileSystem.PARMS* Provides: 1. cleaner configuration using separate properties 2. support for directories directly under the user home folder (applies to sftp, issue below) Issue: 1. use the original RemoteFileSystemFactory and provide sftp://sftp-user:pwd@sftp.server/test-dir as the ftp epr 2. test-dir resides directly in the sftp-user home directory 3. try to upload a file to this directory -> You get the following exception: Caused by: org.jboss.soa.esb.util.RemoteFileSystemException: 2: No such file at org.jboss.internal.soa.esb.util.SecureFtpImpl.uploadFile(SecureFtpImpl.java:578) at fi.barona.esb.integration.sonet.Sonet.sendFile(Sonet.java:142) ... 14 more Caused by: 2: No such file at com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2291) at com.jcraft.jsch.ChannelSftp._realpath(ChannelSftp.java:1824) at com.jcraft.jsch.ChannelSftp.cd(ChannelSftp.java:263) at org.jboss.internal.soa.esb.util.SecureFtpImpl.uploadFile(SecureFtpImpl.java:548) ... 15 more The above exception occurs because jsch (sftp) does not recognize that the test-dir resides directly in the user home folder, the path should be test-dir, not /test-dir -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

3
5
0 / 0

[JBoss JIRA] Created: (JBESB-2469) Remote directory cannot be relative for (S)FTP(S) gateway

by Martin Vecera (JIRA)

Remote directory cannot be relative for (S)FTP(S) gateway --------------------------------------------------------- Key: JBESB-2469 URL: https://jira.jboss.org/jira/browse/JBESB-2469 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.4 CP2 Reporter: Martin Vecera FtpImpl, SecureFtpImpl and FtpsImpl are calling "cd" with the directory specified in jboss-esb.xml every time they are getting list of files. When the directory is specified relatively you would need structure like ftp_dir/ftp_dir/ftp_dir/ftp_dir... This must be at least documented, but doing cd every X seconds is waste of time. It should be sufficient only once IMHO. -- 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

12 years, 2 months

5
6
0 / 0

[JBoss JIRA] (JBESB-3736) Syntax error in opensso quickstart readme

by Tom Cunningham (JIRA)

Tom Cunningham created JBESB-3736: ------------------------------------- Summary: Syntax error in opensso quickstart readme Key: JBESB-3736 URL: https://issues.jboss.org/browse/JBESB-3736 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 4.11 Reporter: Tom Cunningham Fix For: 4.11 The read instructs the user to alter the Tomcat catalina.sh file to look like this: After Editing: JAVA_OPTS="$JAVA_OPTS -Xmx1G -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager" But, the (full) line should read: JAVA_OPTS="$JAVA_OPTS -Xmx1G -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties " -- 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, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBESB-3022) It is not possible to use different credentials on the input of the service and on the SOAPProxy that invokes the proxied service

by Jiri Pechanec (JIRA)

It is not possible to use different credentials on the input of the service and on the SOAPProxy that invokes the proxied service --------------------------------------------------------------------------------------------------------------------------------- Key: JBESB-3022 URL: https://jira.jboss.org/jira/browse/JBESB-3022 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Affects Versions: 4.7 Reporter: Jiri Pechanec Attachments: soapproxy-diffauth.zip There is a use case - I have a secured ESB service using HTTPS/BASIC auth invoking invoking secured HTTPS/BASIC auth web service via SOAPProxy. If the credentials are passed from the client then everything works correctly. But if I have different credentials required for ESB client and different credentials are required by proxied Web Service then I use property <property name="clientCredentialsRequired" value="false" /> to set static credentials for proxied web service. This property works correctly if the ESB service is unsecured. Unfortunately if it is secured then probably the credentials stored in HTTP header stored in ESB message overwrites the static credentials set by the SOAPProxy action. The attached example is modified webservice_proxy_secure QS and has static credentials set to wrong values - so proxied web service should not be invoked. But if ant runtest is executed then the wrong credentials are not used. -- 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

12 years, 2 months

5
11
0 / 0

[JBoss JIRA] (JBESB-3741) Enabling compression on JBossWS webservice endpoints

by Tom Cunningham (JIRA)

Tom Cunningham created JBESB-3741: ------------------------------------- Summary: Enabling compression on JBossWS webservice endpoints Key: JBESB-3741 URL: https://issues.jboss.org/browse/JBESB-3741 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Affects Versions: 4.11 Reporter: Tom Cunningham Fix For: 4.11 Help Desk Ticket Reference: https://c.na7.visual.force.com/apex/Case_View?id=500A0000007CJFt&sfdc.ove... project_key: SOA A customer requested the ability to enable compression on JBossWS endpoints, however the codebase used within SOA does not allow for features/interceptors to be specified on a global basis. Within the ESB codebase we extend the CXF servlet in order to enable invm invocations with the CXF codebase, this same mechanism can be used to enable global features/interceptors by extending the servlet as follows. public class ESBFeatureCXFServletExt extends ESBCXFServletExt { private static Logger LOG = Logger.getLogger(ESBFeatureCXFServletExt.class) ; @Override public void loadBus(final ServletConfig config) throws ServletException { super.loadBus(config) ; if (bus.getExtension(ESBFeatureCXFServletExt.class) == null) { bus.setExtension(this, ESBFeatureCXFServletExt.class) ; final GZIPFeature feature = new GZIPFeature() ; feature.initialize(bus) ; LOG.info("Included GZIP Feature on CXF bus deployment") ; } } } This servlet will enable the GZIP feature on each CXF bus which is deployed. -- 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, 2 months

2
2
0 / 0

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

by Tom Cunningham (JIRA)

Tom Cunningham created JBESB-3735: ------------------------------------- Summary: 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.11 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

2
2
0 / 0

[JBoss JIRA] (JBESB-3744) SqlTableGatewayListener does not recover from DB failure

by Brian Blasko (JIRA)

Brian Blasko created JBESB-3744: ----------------------------------- Summary: SqlTableGatewayListener does not recover from DB failure Key: JBESB-3744 URL: https://issues.jboss.org/browse/JBESB-3744 Project: JBoss ESB Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Rosetta Affects Versions: 4.10 Reporter: Brian Blasko If the DB goes down when listening, the gateway will attempt to reconnect but after the max number of retries of 5(hard coded in JdbcCleanConn.connection, it returns a null connection. This then causes a NPE in pollForCandidates which in turns causes the thread to exit. Then when the DB comes back up, the listener will not restart. The gateway listener should not throw the NPE and should be capable of recovery. -- 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, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBESB-3641) JSF issues with jbpm-console and AS6

by Tom Cunningham (JIRA)

JSF issues with jbpm-console and AS6 ------------------------------------ Key: JBESB-3641 URL: https://issues.jboss.org/browse/JBESB-3641 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Components: Process flow Affects Versions: 4.11 Reporter: Tom Cunningham Assignee: Tom Cunningham Fix For: 4.11 Investigate / Release note the JSF errors occurring in the jbpm-console on AS6. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBESB-3357) Mavenise the ESB build

by Kevin Conner (JIRA)

Mavenise the ESB build ---------------------- Key: JBESB-3357 URL: https://jira.jboss.org/browse/JBESB-3357 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: Build and Release Affects Versions: 4.8 Reporter: Kevin Conner Priority: Optional Fix For: 4.9 To be done for 4.9 if we have time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

2
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues February 2012