[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[dtp-connect-dev] New Element for Connection Profile Extension Point
- From: rcernich@xxxxxxxxxx
- Date: Wed, 10 May 2006 22:09:20 -0600
- Delivered-to: firstname.lastname@example.org
I've added a new element to the connection profile extension point. The
new element, connectionFactoryAdapter, allows developers to add connection
factories that are applied as adapters for specific connection factories
already defined for a connection profile type. This allows the adapter to
be applied to all profile types containing that factory. The benefit of
this is that it allows components to be developed without needing to know
about specific connection profile types.
This new feature has been applied to the SQL model connection factory.
This factory is now defined as an adapter and will be applied to all
connection profiles defining a "java.sql.Connection" connection factory.
This alleviates developers providing custom DB connection profiles from
having to define a SQL model connection factory of their own. They now
must simply provide a java.sql.Connection connection factory. (In addition
to this, their profile must also reference a driver definition which
specifies a vendor and version that can be used to look up a DB definition.
This is not a change from the current requirements for custom DB profiles.)
This feature could also be used by ODA for creating ODA connection objects
for all profiles providing a java.sql.Connection connection factory. This
would allow any DB profile to be accessible through the ODA APIs.
The following is a summary of the API changes:
IConnectionFactoryProvider: removed getConnectionProfileProvider() from
the interface definition.
connectionProfile extension point: added connectionFactoryAdapter element.
The connectionFactoryAdapter element does provide a mechanism for
overriding the adapter for specific profile types, if necessary. Also, if
a profile has an existing connection factory of the same type as the
adapter, the connection factory will be used in place of the adapter.
(Basically, if there are any existing profiles with a SQL model connection
factory already specified, that factory will be used instead of the factory
adapter defined within ...sqm.core; i.e. this should not break existing
The specific changes can be located in the patch file attached to the BZ
request for this feature.
Note, this does not address the multiple connection issue (i.e. two
connections will still be created when connecting to a DB). After spending
much time, I could not find a way to do this without making significant
changes to the code base. In the end, I opted for a simpler mechanism
which fit well within the current APIs (notice there was only a single
breaking change to the provisional API). This also allowed existing UI
contributions and filter logic to be used as-is.
Please let me know if you have any questions, comments, concerns, etc.
I plan to commit these changes Friday.