Daniel López wrote:
> Scott Ferguson escribió:
> Cool, thanks. I'm assuming that this would go inside the custom tag like:
Correct. You could also use it in an attribute style like:
although I'm not sure that's more readable.
> 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.
Well, the theory would be that your two pools have different purposes,
which is why there are two pools, so the qualifier would give a bit of
extra documentation at the injection point.
We'll see how the idea works out in practice. My guess is that most
project will only need a few qualifiers (since having 10s of DataSources
would be unusual), so it won't turn out to be as many extra classes as
it might seem.
>> 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.
The annotation is javax.inject.Named, which is included in the "ee"
virtual package. So you'd use
(Although I generally like the xmlns:ee on the top element, I've written
it inline just for emphasis.)
> 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 :).
Right. CDI is more of a preferred direction. The nice thing is that you
can migrate gracefully. There's no need to rip out the current code.
> 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
resin-interest mailing list