You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Francisco Borges (JIRA)" <ji...@apache.org> on 2007/07/13 14:01:08 UTC

[jira] Created: (GERONIMO-3319) Asking for connection using the wrong CRI won't fail.

Asking for connection using the wrong CRI won't fail.
-----------------------------------------------------

                 Key: GERONIMO-3319
                 URL: https://issues.apache.org/jira/browse/GERONIMO-3319
             Project: Geronimo
          Issue Type: Bug
      Security Level: public (Regular issues)
    Affects Versions: 1.2
         Environment: Linux masalembu 2.6.20-16-generic #2 SMP Wed May 23 01:46:23 UTC 2007
Two AMD Unknown 2004MHz processors, 8020.65 total bogomips, 1994M RAM
System library 2.5.0
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Server VM (build 1.6.0-b105, mixed mode)
            Reporter: Francisco Borges


I have some code that uses ConnectionRequestInfo (CRI) objects to get 
connections, and also some tests for it. They all work on JBoss, but on 
Geronimo1.2, they will succeed regardless of the what I write in the CRI.

The problem being: Geronimo does not seem to pass back the CRI to my 
MCF for comparison.

Set up of my test is:

Deploy factory using <match-all/>

Pass CRI with the wrong values (unexisting DB, unexisting user etc) to

import javax.resource.cci.Connection;
import javax.resource.spi.ConnectionRequestInfo;
[...]
(Connection)connectionManager.allocateConnection(xhiveManagedConnectionFactory, 
        (ConnectionRequestInfo) connectionSpec);

                                                  ========
Here is the comparison of the debugging of my app under Jboss and Geronimo:

*JBoss* (4.2.0) will:

1. Call (my implementation of)
class ManagedConnectionFactory {
ManagedConnection matchManagedConnections(
       java.util.Set set, 
       javax.security.auth.Subject subject,
       javax.resource.spi.ConnectionRequestInfo connectionRequestInfo) 
throws ResourceException 

Which fails to match, deletes an unmatched connection, and returns null;

2. Call (my implementation of)
Class ManagedConnectionFactory {
ManagedConnection createManagedConnection(Subject, ConnectionRequestInfo)

Where an exception is thrown due to the wrong parameters.

                                                 =========

On *Geronimo*, the code never reaches neither createManagedConnection nor 
matchManagedConnections, and I get the pre-existing (valid) connection 
back. 

Could Geronimo be using the pool with  <select-one-assume-match/>
despite the fact that I have <match-all/> in the pool configuration at 
geronimo-ra.xml?


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (GERONIMO-3319) Asking for connection using the wrong CRI won't fail.

Posted by "David Jencks (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/GERONIMO-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Jencks updated GERONIMO-3319:
-----------------------------------

    Component/s: connector

> Asking for connection using the wrong CRI won't fail.
> -----------------------------------------------------
>
>                 Key: GERONIMO-3319
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-3319
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: connector
>    Affects Versions: 1.2
>         Environment: Linux masalembu 2.6.20-16-generic #2 SMP Wed May 23 01:46:23 UTC 2007
> Two AMD Unknown 2004MHz processors, 8020.65 total bogomips, 1994M RAM
> System library 2.5.0
> java version "1.6.0"
> Java(TM) SE Runtime Environment (build 1.6.0-b105)
> Java HotSpot(TM) Server VM (build 1.6.0-b105, mixed mode)
>            Reporter: Francisco Borges
>
> I have some code that uses ConnectionRequestInfo (CRI) objects to get 
> connections, and also some tests for it. They all work on JBoss, but on 
> Geronimo1.2, they will succeed regardless of the what I write in the CRI.
> The problem being: Geronimo does not seem to pass back the CRI to my 
> MCF for comparison.
> Set up of my test is:
> Deploy factory using <match-all/>
> Pass CRI with the wrong values (unexisting DB, unexisting user etc) to
> import javax.resource.cci.Connection;
> import javax.resource.spi.ConnectionRequestInfo;
> [...]
> (Connection)connectionManager.allocateConnection(xhiveManagedConnectionFactory, 
>         (ConnectionRequestInfo) connectionSpec);
>                                                   ========
> Here is the comparison of the debugging of my app under Jboss and Geronimo:
> *JBoss* (4.2.0) will:
> 1. Call (my implementation of)
> class ManagedConnectionFactory {
> ManagedConnection matchManagedConnections(
>        java.util.Set set, 
>        javax.security.auth.Subject subject,
>        javax.resource.spi.ConnectionRequestInfo connectionRequestInfo) 
> throws ResourceException 
> Which fails to match, deletes an unmatched connection, and returns null;
> 2. Call (my implementation of)
> Class ManagedConnectionFactory {
> ManagedConnection createManagedConnection(Subject, ConnectionRequestInfo)
> Where an exception is thrown due to the wrong parameters.
>                                                  =========
> On *Geronimo*, the code never reaches neither createManagedConnection nor 
> matchManagedConnections, and I get the pre-existing (valid) connection 
> back. 
> Could Geronimo be using the pool with  <select-one-assume-match/>
> despite the fact that I have <match-all/> in the pool configuration at 
> geronimo-ra.xml?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.