Scott Ferguson escribió:
> wrote:
>> Hi Scott,
>> Thanks for the pointer. I managed to get it to work, more or less,  
>> using the new way:
>> --
>>    <leaf:ConnectionPoolDataSource>
>>      ...
>>    </leaf:ConnectionPoolDataSource>
>> --
>> and the old "bean" way:
>> --
>>    <bean name="MyPool">
>>      <type>org.leaf.ConnectionPoolDataSource</type>
>>      <jndi-name>java:comp/env/jdbc/MyPool</jndi-name>
>>      <init>
>>       ...
>>      </init>
>>    </bean>
>> --
>> 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

Reply via email to