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
Blog:
http://rmannibucau.wordpress.com/
LinkedIn:
http://fr.linkedin.com/in/rmannibucau
Github:
https://github.com/rmannibucau
2014-08-27 2:55 GMT+02:00 Josh Juneau <juneau001_at_gmail.com>:
> 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
> http://jj-blogger.blogspot.com
> https://www.apress.com/index.php/author/author/view/id/1866
>
> On Aug 26, 2014, at 4:55 PM, arjan tijms <arjan.tijms_at_gmail.com> wrote:
>
> On Tue, Aug 26, 2014 at 8:22 PM, Romain Manni-Bucau <rmannibucau_at_gmail.com>
> 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.
> http://henk53.wordpress.com/2012/06/30/the-state-of-datasourcedefinition-in-java-ee).
> We also tested our kick off app (see
> https://github.com/javaeekickoff/java-ee-kickoff-app and
> http://jdevelopment.nl/open-source/java-ee-kickoff-app) on a number of
> servers and @DataSourceDefinition worked everywhere.
>
> I think it's thus fairly portable ;)
>
> Kind regards,
> Arjan