BaseConnectionManager2.managedConnectionToListenerMap

[deegs_ca]

BaseConnectionManager2.managedConnectionToListenerMap not retrieving listeners

Jboss3.0.0RC3
jdk1.3
win2k pro

I'm getting a null pointer when trying to access a "Connection" a servlet. This seems to be because when BaseConnectionManager2 calls managedConnectionToListenerMap.get() using one of my managed connections as the key, it returns null? What could be causing this. I even check that it is getting stored by adding extra debug in the following method but even within the method scope I can't retrieve it.

public ManagedConnection getManagedConnection(Subject subject, ConnectionRequestInfo cri)
throws ResourceException
{
ManagedConnection mc = poolingStrategy.getConnection(subject, cri);
if (getConnectionEventListener(mc) == null)
{
//it is a new ManagedConnection, so no one else can be getting it.

Object o = registerConnectionEventListener(mc);

log.warn("putting key " + mc + " with a value of " + o);
managedConnectionToListenerMap.put(mc, o);
debugMap();

log.warn("testing get of key " + mc + " : return = " + managedConnectionToListenerMap.get(mc));


My mbean is NoTxConnectionManager from my service.xml.

When the log gets printed , I get the following....

2002-08-12 12:49:39,218 WARN [org.jboss.resource.connectionmanager.NoTxConnectionManager] putting key com.apexion.jca.spi.ManagedConnectionImpl@33c658 with a value of org.jboss.resource.connectionmanager.NoTxConnectionManager$NoTxConnectionEventListener@720434
2002-08-12 12:49:39,218 WARN [org.jboss.resource.connectionmanager.NoTxConnectionManager] testing get of key com.apexion.jca.spi.ManagedConnectionImpl@33c658 : return = null
.
.
.
java.lang.NullPointerException
at org.jboss.resource.connectionmanager.BaseConnectionManager2.registerAssociation(BaseConnectionManager2.java:670)
at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:511)
at com.apexion.jca.cci.ConnectionFactoryImpl.getConnection(ConnectionFactoryImpl.java:74)


Any help is much appreciated, before I lose all my hair :)

[deegs_ca]

apologies, what I meant was obtain a javax.resource.cci.Connection from a servlet context i.e. using jndi, then connection factory etc...


Again, much obliged for the help.
-cheers

[deegs_ca]

I tweaked a little with the source from BaseConnectionManager2 and instead of using the whole object as the key, I put it into the map with the toString() method.

i.e. instead of

hash.put(o1, o2);

i use

hash.put(o1.toString(), o2)

this is not a solution but the lookup is succeeding now. However, this only exposes other areas in the code which fall victim to the same failing hashmap lookup.

-d

[davidjencks]

I think you failed to properly implement equals and hashCode in your ManagedConnection. This is the normal way to fail at hashmap lookup. I found Effective Java to have very useful advice on correctly implementing these methods.

[davidjencks]

My previous response doesn't make any sense. However, I think you have implemented equals and hashCode in your ManagedConnection implementation.

Why? Do you need it for some purpose?

The ManagedConnection interface does not include equals or hashCode. The jca 1.5 spec does indicate clearly when you are required to implement equals and hashCode. Although several classes are prohibited from implementing equals and hashCode, these are all new in jca 1.5. I think leaving out a prohibition for implementing equals and hashCode is an oversight in the specification.

[deegs_ca]

David,

I discovered what was causing my problem and it was self inflicted.

I was using the java.lang.reflect.Proxy and java.lang.reflect.Invocationhandler to activate logging of all the methods in my jca interface implementations.

For a brief discussion of this see

http://developer.java.sun.com/developer/TechTips/2000/tt0530.html#tip1

What this does is allow me to create a new class at runtime which wraps every method defined on the class's interfaces, implements the required interfaces, and gives me an intercept point to insert, in this case, logging without sprinkling logging code throughout my source.

Somehow, a reference to the unwrapped object was getting used to lookup the wrapped object or vice versa. Thus, wrapped_object != object implies failing hashmap lookup.

In regards to implementing hashCode and equals, at first I implemented them where the interfaces requested and the spec recommended. But then I saw no point to this, for much the same reasons you stated. i.e. it is unnecessary. Why should I guess about how the container spi will store my objects.

At any rate, I disabled the logging and everything worked.

many thanks
-doug

[deegs_ca]

Apologize if this is a duplicate, but the following response did not appear....

>> begin

David,

I discovered what was causing my problem and it was self inflicted.

I was using the java.lang.reflect.Proxy and java.lang.reflect.Invocationhandler to activate logging of all the methods in my jca interface implementations.

For a brief discussion of this see

http://developer.java.sun.com/developer/TechTips/2000/tt0530.html#tip1

What this does is allow me to create a new class at runtime which wraps every method defined on the class's interfaces, implements the required interfaces, and gives me an intercept point to insert, in this case, logging without sprinkling logging code throughout my source.

Somehow, a reference to the unwrapped object was getting used to lookup the wrapped object or vice versa. Thus, wrapped_object != object implies failing hashmap lookup.

In regards to implementing hashCode and equals, at first I implemented them where the interfaces requested and the spec recommended. But then I saw no point to this, for much the same reasons you stated. i.e. it is unnecessary. Why should I guess about how the container spi will store my objects.

At any rate, I disabled the logging and everything worked.

many thanks
-doug