[javaee-spec users] Re: DataSourceDefinition

From: Romain Manni-Bucau <>
Date: Wed, 27 Aug 2014 07:07:44 +0200

For me the main issue is you configure a pool from a DataSource with
all defaults "vendor specific". So if you have a custom wrapper then
you are behind the container pool which can be killing you wrapper
implementation (no support of validation, slower....)

Romain Manni-Bucau
Twitter: @rmannibucau

2014-08-27 2:55 GMT+02:00 Josh Juneau <>:
> The continued pattern of applying more standards across the platform is
> beneficial to everyone. I think that it is clear to see from the responses
> in this thread that there are many use cases for this annotation, in
> particular. I am in the camp of those who do not use this feature for
> production, but I can see how it may be useful for some situations.
> Perhaps adding a note in the JavaDoc regarding best practices would be
> beneficial. However, stating blatantly that this should not be used in
> production is perhaps not the best approach since some are finding good
> use-cases for a production environment.
> Josh Juneau
> On Aug 26, 2014, at 4:55 PM, arjan tijms <> wrote:
> On Tue, Aug 26, 2014 at 8:22 PM, Romain Manni-Bucau <>
> wrote:
>> to enforce your "nobody uses it" the main issue is it is not usable
>> for prod - often not the same team handles config and packaging
> There are undoubtedly situations where there are different teams doing
> development and configuration (simplest case is externally obtained
> applications that need to be integrated into an intranet), but it's also
> often the case that it does concern the same team.
> The beauty of Java EE is that both cases can be supported; the data source
> can be defined using standardized embedded code/configuration, or it can
> done via non-standard external means. Hopefully a future Java EE version can
> also define a standardized external way. In most cases it's now a fairly
> simple change to go from embedded to external or the other way around and
> the majority of the code is completely oblivious to this change.
> This means theoretically a beginner can prototype an app using the embedded
> data-source element in web.xml. Prototypes have a tendency to grow into
> production apps, and at some point when the app and requirements have grown
> one can simply remove the single data-source element from web.xml again and
> define the data source externally. Then when the team eventually matures and
> fully understands when to separate things and when not, the data-source
> element may simply be added again in order to simplify things. All this
> without ever changing any code that depends on the data source.
>> - and
>> portable since it doesn't integrate with common Java solution (common
>> jdbc config - think to [dbcp] for surely the most known one).
> I'm not entirely sure what you mean here. Do you perhaps mean to say that
> Tomcat doesn't support @DataSourceDefinition?
> Every Java EE server now certainly supports it. The Java EE 6 TCK probably
> didn't test this facility thoroughly, as a couple of early (but certified)
> Java EE 6 products indeed didn't support it well at first, but since some
> time the support is pretty good (see e.g.
> We also tested our kick off app (see
> and
> on a number of
> servers and @DataSourceDefinition worked everywhere.
> I think it's thus fairly portable ;)
> Kind regards,
> Arjan