[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[dtp-connect-dev] Re: [dtp-dev] New Element for Connection Profile Extension Point
- From: rcernich@xxxxxxxxxx
- Date: Fri, 12 May 2006 09:35:16 -0600
- Delivered-to: firstname.lastname@example.org
These changes have been committed.
dtp-dev-bounces@xxxxxxxxxxx wrote on 05/10/2006 10:09:20 PM:
> Hey all,
> I've added a new element to the connection profile extension point. The
> new element, connectionFactoryAdapter, allows developers to add
> factories that are applied as adapters for specific connection factories
> already defined for a connection profile type. This allows the adapter
> 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
> 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
> This is not a change from the current requirements for custom DB
> This feature could also be used by ODA for creating ODA connection
> for all profiles providing a java.sql.Connection connection factory.
> 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
> The connectionFactoryAdapter element does provide a mechanism for
> overriding the adapter for specific profile types, if necessary. Also,
> 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
> factory already specified, that factory will be used instead of the
> 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
> 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.
> dtp-dev mailing list