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

  <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
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest

resin-interest mailing list

Reply via email to