2014-08-27 9:13 GMT+02:00 arjan tijms <arjan.tijms_at_gmail.com>:
> 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.
>
Not really - of course it depends the feature - but if you return
without proxying the connections then even if your wrapper supports a
lot of features then the "container facade" will ignore it. Of course
you can make your wrapper even more clever but that's a workaround for
me. In term of bottlenexk you get the container + your own one pool
"locks". Best case it is negligeable but since it depends "container
defaults" it can be impacting.
> 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
>
>