On 05/09/2011 10:52 AM, Heiko Braun wrote:
On May 9, 2011, at 5:40 PM, David M. Lloyd wrote:
> Yeah there's absolutely nothing stopping us from recognizing JDBC driver
> types and knowing what defaults make sense for them, and how to work
> around their various problems; I think this would add a lot of value.
>
> Querying the domain for JDBC drivers doesn't really make a lot of sense
> IMO. You could support querying the domain for drivers configured via
> profiles, I suppose, but again that really makes sense at the profile
> level only. Querying for deployed driver types doesn't seem too useful
> to me either. I think that it's more important in this case to reflect
> the model as it really is and not try to create the illusion of some
> representation that isn't even possible.
Not sure if I understand the second half correctly:
"Querying the domain for JDBC drivers doesn't make sense"
The use case is as follows:
1) Specify datasource name, jndi
2) select driver
3) provide remaining config attributes
4) done
This will create a domain level datasource configuration.
The second step is the one that's causing the trouble atm.
Hence the question if it would be possible to query the available drivers.
Why doesn't it make sense?
Because drivers don't always exist at the same level as datasources.
You can choose from a list of profile-defined drivers, sure, but you
cannot select from deployed drivers. It just won't work, unless you add
a "query server for deployed drivers" option or something.
--
- DML