Scott Ferguson escribió:
> d.lo...@uib.es wrote:
>> Hi Scott,
>> Thanks for the pointer. I managed to get it to work, more or less,
>> using the new way:
>> and the old "bean" way:
>> <bean name="MyPool">
>> However, I find it more flexible to use the old bean way as it allows
>> me to publish it to JNDI, so the old JNDI-based applications don't
>> have to rewritten, and it allows me more easily to instantiate
>> different resources and assign them different names (If I understoon
>> correctly, I have to create a new @Qualified annotation for each name
>> with the new Resin 4.0's way).
> Well, I've just added a resin:Jndi="java:comp/env/jdbc/MyPool" to
> achieve the same thing as the old one.
Cool, thanks. I'm assuming that this would go inside the custom tag like:
> With the new Qualifiers, it's recommended to have a Qualifier for each
> kind of resource. You can use the annotation's attributes to distinguish
> between similar qualifiers. So you could have @Login(xa=false) vs
> @Login(xa=true) to distinguish a transactional DataSource from a
> non-transactional one.
I understand, but I simply want to be able to define two different
resources of the same class that used different configuration data and
assign them a different name. So I can have 2 pools pointing to
different databases in the same web application. I don't see the point
of creating a new annotation just for giving a name to a resource.
> Also, you can use the built-in @Named("MyPool") as a general Qualifier.
> It's recommended to use custom ones to improve the code's documentation,
> but the @Named works perfectly well.
Yes, I was able to use @Named("MyPool") when defining the pool using the
old <bean> way, but how does one assign the name MyPool to the bean
using the new way?
I apologise if that's documented somewhere but I was unable to find it.
> Unless you have a specific need for JNDI or have legacy code or are
> transitioning, I see less need in the future for JNDI. It's more
> cumbersome, and provides less code self-documentation than CDI injection.
> -- Scott
I agree, it's just that we have plenty of legacy applications that rely
on JNDI to find the datasource and in some cases, the code is generic
and has to be able to be used with different resources that are
specified externally at deploy time, so the code accessing the bean is
not compiled each time (a library). For example, we develop some
applications using PLSQL where you write no Java code at all as the Java
code to access the DB, execute the procedures etc. is already written in
a library. In those and similar cases we cannot use an annotation inside
the library but passing it a name and retrieving it through JNDI on
startup is an option. I also have to check if I can get the
annotations/CDI injection to work on Groovy defined classes, as I'm
using it for prototyping lately. But if I can't, at least I know I can
go back to good-old JNDI :).
In any case, I agree that CDI injection is a powerful mechanism and I
plan to use it where I can. It's simply that sometimes it's not the best
option so having both bases covered seems like "A Good Thing" ;).
resin-interest mailing list