You are right saying for jms it is easier but:
1) for ConnectionFactory you have the same issue: you don't always
know which RA you use (actually you often only know it once you know
your container and binding the container to the app is not a good idea
if it is not a ra of your ear IMHO - most common case AFAIK)
2) for Destination it works...but is also pretty useless since you can
get the name from @Resource(name) in 80% of cases which means
@*Definition is just boilerplate code - in particular for simple apps.
I understand the "it works fast" point but look the whole chain of
reactions: "it works fast", "but that's not usable". For prototypes I
think a default one would have been enough without any config in the
container.
PS: what I also missed (behind a well defined factory and
configuration "loader") was the support of placeholders (system
properties/environment) which would allow to use it in test and prod
once you have your own DataSource/Queue/...
Romain Manni-Bucau
Twitter: @rmannibucau
Blog:
http://rmannibucau.wordpress.com/
LinkedIn:
http://fr.linkedin.com/in/rmannibucau
Github:
https://github.com/rmannibucau
2014-08-26 20:35 GMT+02:00 John D. Ament <john.d.ament_at_gmail.com>:
> I disagree. I think the JMS definitions work better.
>
> DataSource is confusing because you need credential information.
>
>
> On Tue, Aug 26, 2014 at 2:33 PM, Arun Gupta <arun.gupta_at_gmail.com> wrote:
>>
>> Hi Romain,
>>
>> I hope Configuration JSR will provide a cleaner solution to all of
>> this. But @*Definitions (reminds of Death Star ;-) indeed seems like
>> have a limited scope.
>>
>> Arun
>>
>> On Tue, Aug 26, 2014 at 11:22 AM, Romain Manni-Bucau
>> <rmannibucau_at_gmail.com> wrote:
>> > Hi Arun,
>> >
>> > 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 - and
>> > portable since it doesn't integrate with common Java solution (common
>> > jdbc config - think to [dbcp] for surely the most known one). IMHO
>> > @*Definitions were an error and configuration should really be handled
>> > mainly outside the application and inside the application for embedded
>> > cases/cloud but using a CDI event if possible (didnt check but it
>> > should) or another standard listener where we can - as it is now more
>> > and more done - register resources.
>> >
>> > I think it is the main goal of config jsr.
>> >
>> > Would be great IMHO to get @*Definition deprecated if really not used
>> > (maybe same kind of polling that for @New can help) in favor of config
>> > jsr solution which should be really more powerful.
>> >
>> >
>> >
>> >
>> > Romain Manni-Bucau
>> > Twitter: @rmannibucau
>> > Blog: http://rmannibucau.wordpress.com/
>> > LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> > Github: https://github.com/rmannibucau
>> >
>> >
>> > 2014-08-26 20:12 GMT+02:00 Arun Gupta <arun.gupta_at_gmail.com>:
>> >> There is clear evidence that nobody is using @DataSourceDefinition in
>> >> production code. See the conversation at:
>> >>
>> >> https://twitter.com/arungupta/status/504039335688404992
>> >>
>> >> Seems like its good only for demos. I'd urge platform EG and other EGs
>> >> in Java EE 8 to strongly consider adding a similar annotation.
>> >>
>> >> Cheers
>> >> Arun
>> >>
>> >> --
>> >> http://blog.arungupta.me
>> >> http://twitter.com/arungupta
>>
>>
>>
>> --
>> http://blog.arungupta.me
>> http://twitter.com/arungupta
>
>