[JBoss JIRA] Created: (JBESB-1419) SQLGatewayListener has problems when uses lowercase values in process fields
by Jiri Pechanec (JIRA)
SQLGatewayListener has problems when uses lowercase values in process fields
----------------------------------------------------------------------------
Key: JBESB-1419
URL: http://jira.jboss.com/jira/browse/JBESB-1419
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.2.1
Environment: FC7/PostgreSQL
Reporter: Jiri Pechanec
Fix For: 4.2.1 CP1
Contents of the table
soaesb1=> select * from gateway_table where upper(status_col) like 'P%';
unique_id | data_column | status_col
-----------+------------------+------------
1 | Hello ESB World! | p
2 | How why ya? | p
3 | Thanks. | p
4 | Cya! | p
5 | Bye ESB World | p
Log messages
2007-12-21 07:01:56,925 WARN [org.jboss.soa.esb.listeners.gateway.SqlTableGatewayListener] Cannot change row state from Pending to Working. Number of rows in state Pending = 0
--
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
18 years, 3 months
[JBoss JIRA] Created: (JBESB-1392) Unable to use message store after removing application
by Jiri Pechanec (JIRA)
Unable to use message store after removing application
------------------------------------------------------
Key: JBESB-1392
URL: http://jira.jboss.com/jira/browse/JBESB-1392
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Message Store
Affects Versions: 4.2.1
Reporter: Jiri Pechanec
Priority: Critical
If an ESB app writes a message to message store either intentionally or unintentionally, is later undeployed and the message class was soted in ESb file then the message store can't be iterated. The reason is that for iteration only getAllMessages etc methods can be used which throes ClassNotFoundException.
There should be methods to iterate only over UUID of message store or this situation must be handled in other way not not prevent message store from use.
--
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
18 years, 3 months
[JBoss JIRA] Created: (JBESB-1404) Support for JMS authentication
by mwax (JIRA)
Support for JMS authentication
------------------------------
Key: JBESB-1404
URL: http://jira.jboss.com/jira/browse/JBESB-1404
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Rosetta
Affects Versions: 4.2.1
Reporter: mwax
ESB currently does not provide explicit support for JMS authentication. In real production systems, authentication is typically manadatory.
Potential solutions:
In cases where JNDI authentication only is required, adding JNDI properties to the jms-provider definition will work, as in the following example for TIBCO:
<jms-provider name="TIBCOJMSProvider"
connection-factory="QueueConnectionFactory"
jndi-context-factory="com.tibco.tibjms.naming.TibjmsInitialContextFactory"
jndi-pkg-prefix="com.tibco.tibjms.naming"
jndi-URL="tcp://myhost:7222">
<property name="java.naming.security.principal" value="username"/>
<property name="java.naming.security.credentials" value="password"/>
...
However, for consistency it might be better to either create new attributes for the jms-provider element, e.g., jndi-security-principal, or to deprecate the jndi attributes and replace them with properties, such as:
<jms-provider name="TIBCOJMSProvider"
connection-factory="QueueConnectionFactory">
<property name="java.naming.factory.initial" value="com.tibco.tibjms.naming.TibjmsInitialContextFactory"/>
<property name="java.naming.provider.url" value="tcp://myhost:7222"/>
<property name="java.naming.security.principal" value="username"/>
<property name="java.naming.security.credentials" value="password"/>
This latter alternative would simplify the code, which currently needs to translate from, e.g., jndi-URL to java.naming.provider.url.
In cases where authentication is required to after the JNDI lookup, changes to the code are needed. The following change to the JmsConnectionPool addAnotherSession method works when the JMS username and password are the same as the JNDI principal and credentials:
String username = poolKey.get(Context.SECURITY_PRINCIPAL);
String password = poolKey.get(Context.SECURITY_CREDENTIALS);
if (JMSEpr.QUEUE_TYPE.equals(destinationType)) {
QueueConnectionFactory factory = (QueueConnectionFactory) factoryConnection;
if (username != null || password != null) {
jmsConnection = factory.createQueueConnection(username, password);
} else {
jmsConnection = factory.createQueueConnection();
}
} else {
TopicConnectionFactory factory = (TopicConnectionFactory) factoryConnection;
if (username != null || password != null) {
jmsConnection = factory.createTopicConnection(username, password);
} else {
jmsConnection = factory.createTopicConnection();
}
}
This does not work if the JMS username and password are distinct from the JNDI values. I tried simply creating new keys to store the username and password, but this requires additional code changes, as methods such as JmsConnectionPool.getPool only have access to the java.naming.xxx properties of the EPR.
--
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
18 years, 4 months