BTM

Add setDataSource() method to PoolingDataSource/ResourceBean

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.3.3
  • Fix Version/s: 2.2.0
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

The current approach to configuring the wrapped datasource is by specifying its:

  • classname as a String via the 'className' property
  • configuration properties as a Properties via the 'driverProperties' property

Please add a second approach to configuring the wrapped datasource by setting a property with a datasource instance.
This approach enables configuration flexibility of defining database datasources separately from BTM and setting them on the BTM wrapper datasources, particularly useful with Spring bean configuration. We can then keep JTA manager configuration separate from database datasource configuration, making our configuration easier for different databases in different environments (e.g. the BTM PoolingDataSource beans refer to datasource names such as "dbDataSource" and we control which Spring application context files containing the dbDataSources with those expected names are loaded and therefore injected to the BTM datasource).

We can partially get there by using a property for the 'className' value, but can't configure the 'driverProperties' as easily because different datasources have different property names. So we end up separating the property config from the datasource config and must ensure the 'className' and 'driverProperties' pair of properties always match, vs configuring the datasource bean in one spot (class and properties together) and setting the datasource.

Activity

Hide
Ludovic Orban added a comment -

This is a well-known limitation, mostly because of historical reasons.

It can be removed but it's not as trivial as just adding a pair of getter / setter. Let's target it for 2.1.

Show
Ludovic Orban added a comment - This is a well-known limitation, mostly because of historical reasons. It can be removed but it's not as trivial as just adding a pair of getter / setter. Let's target it for 2.1.
Hide
Stéphane Nicoll added a comment -

Hey, I second that request. This applies to the connection factory as well where you redefine how the connection factory gets created instead of injecting it

Show
Stéphane Nicoll added a comment - Hey, I second that request. This applies to the connection factory as well where you redefine how the connection factory gets created instead of injecting it

People

Vote (2)
Watch (2)

Dates

  • Created:
    Updated: