Daniel López wrote:
> Scott Ferguson escribió:
>
> Cool, thanks. I'm assuming that this would go inside the custom tag like:
> --
> <leaf:ConnectionPoolDataSource>
> <resin:Jndi>java:comp/env/jdbc/MyPool</resin:Jndi>
> ...
> </leaf:ConnectionPoolDataSource>
> --
>
Correct. You could also use it in an attribute style like:
<leaf:ConnectionPoolDataSource resin:Jndi="java:comp/env/jdbc/MyPool"/>
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?
> --
> <leaf:ConnectionPoolDataSource>
> <resin:Name>MyPool</resin:Name>
> <resin:Jndi>java:comp/env/jdbc/MyPool</resin:Jndi>
> ...
> </leaf:ConnectionPoolDataSource>
> --
> 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
<leaf:ConnectionPoolDataSource>
<ee:Named xmlns:ee="urn:java:ee">MyPool</ee:Named>
(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.
-- Scott
> 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" ;).
>
> Thanks,
> D.
>
>
> _______________________________________________
> resin-interest mailing list
> [email protected]
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>
>
_______________________________________________
resin-interest mailing list
[email protected]
http://maillist.caucho.com/mailman/listinfo/resin-interest
