Hi,
On Wed, Aug 27, 2014 at 7:07 AM, Romain Manni-Bucau <rmannibucau_at_gmail.com>
wrote:
> 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....)
>
Well, it does't actually kill the wrapper implementation and performance
itself isn't affected directly, but of course via the wrapper mechanism
that I explained above only those settings that are intended for the data
source (driver) can be configured. Settings for the container / pool cannot.
Those either have to be statically configured at the annotation/xml element
level (like the min and max pool size settings), or they have to be omitted
altogether.
So yes, that is currently a limitation of the @DataSourceDefinition
facility and my wrapper approach. Instead of dropping the facility
altogether because of this, I'd rather see work being done to approve it ;)
Kind regards,
Arjan
>
>
> 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
>