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?
Ike