I think the situation they are trying to cover is that if you serialize and serialize a managed connection factory, the result should be .equals to what you started with. This is not necessary with Geronimo but seems to be what they are suggesting as far as looking up a connection factory in jndi.
The mutable properties problem is indeed a problem. I've always figured that if I changed the values the new and old mcfs would not be equal. I'd prefer it if the spec included a lifecycle so the mcf could object if you changed the properties, or some kind of "freeze" method.
However, the spec also kind of implies that all the properties are set during deployment and not changed thereafter, so I think it is pretty much a theoretical problem.
david jencks
On Thursday, April 29, 2004, at 09:22 PM, Jeremy Boynes wrote:
I see where the J2CA spec says that equals() and hashCode() should the properties that make the MCF "unique and specific", but I have a couple of concerns:
1) I don't know what that is. For example, with Oracle you can specify the instance using a URL or by setting properties (host, server, port, ...), so two instances could be configured in different ways, have different properties, but point to the same EIS instance.
2) All the properties are mutable, which could change the values used in comparison. Short of implementing a JavaBean change notification and have the CM subscribe I don't see how this can work.
Seems to me that the safest way is to define these using identity on the MCF, then no two MCFs will be the same and the app server will need to treat them differently. This does preclude a couple of optimizations (e.g. that the CM could map two different CF's to the same MCF) but I don't think it stops it working.
An alternative may be to have the MCF delegate to the EIS implementation e.g. by calling equals on a delegate instance e.g. the OracleDataSource from above. That way the driver gets to determine what is equivalent.
Any thoughts? Jeremy
( For acronym decoding see the J2CA spec. )
