Re: [Resin-interest] Custom datasource implementation

2010-04-13 Thread Daniel López
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:
 --
leaf:ConnectionPoolDataSource
  ...
/leaf:ConnectionPoolDataSource
 --
 and the old bean way:
 --
bean name=MyPool
  typeorg.leaf.ConnectionPoolDataSource/type
  jndi-namejava: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:
--
leaf:ConnectionPoolDataSource
resin:Jndijava:comp/env/jdbc/MyPool/resin:Jndi
  ...
/leaf:ConnectionPoolDataSource
--
 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?
--
leaf:ConnectionPoolDataSource
resin:NameMyPool/resin:Name
resin:Jndijava:comp/env/jdbc/MyPool/resin:Jndi
  ...
/leaf:ConnectionPoolDataSource
--
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 ;).

Thanks,
D.


___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


Re: [Resin-interest] Custom datasource implementation

2010-04-13 Thread Scott Ferguson
Daniel López wrote:
 Scott Ferguson escribió:
   
 Cool, thanks. I'm assuming that this would go inside the custom tag like:
 --
 leaf:ConnectionPoolDataSource
 resin:Jndijava: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:NameMyPool/resin:Name
 resin:Jndijava: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:eeMyPool/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
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


Re: [Resin-interest] Custom datasource implementation

2010-04-12 Thread Scott Ferguson
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:
 --
leaf:ConnectionPoolDataSource
  ...
/leaf:ConnectionPoolDataSource
 --
 and the old bean way:
 --
bean name=MyPool
  typeorg.leaf.ConnectionPoolDataSource/type
  jndi-namejava: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.

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.

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.

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
 Am I missing something? I like much better the old way :).
 D.


 S'està citant Scott Ferguson f...@caucho.com:

   
 Daniel López wrote:
 
 Hi there,

 For some reason, I would like to be able inside Resin a datasource
 implementation other than Resin's, C3P0 for example, and I have been
 unable to find in the documentation how would one configure it. The
 examples that I found use the database tag, which does not seem to
 have an attribute to specify an implementation class for the DataSource.

 Is it possible at all?

   
 You'd treat it as a generic bean. In Resin 4.0.x, it would be the

 c3p0:DataSourceImpl xmlns:c3p0=...
   ...
 /c3p0:DataSourceImpl

 The database tag wouldn't make sense, because it's integrated with
 Resin's JCA/pooling code, which is what you're trying to replace.

 -- Scott
 
 D.
   


 





 ___
 resin-interest mailing list
 resin-interest@caucho.com
 http://maillist.caucho.com/mailman/listinfo/resin-interest

   



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


Re: [Resin-interest] Custom datasource implementation

2010-04-10 Thread d . lopez
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
 typeorg.leaf.ConnectionPoolDataSource/type
 jndi-namejava: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).

Am I missing something? I like much better the old way :).
D.


S'està citant Scott Ferguson f...@caucho.com:

 Daniel López wrote:
 Hi there,

 For some reason, I would like to be able inside Resin a datasource
 implementation other than Resin's, C3P0 for example, and I have been
 unable to find in the documentation how would one configure it. The
 examples that I found use the database tag, which does not seem to
 have an attribute to specify an implementation class for the DataSource.

 Is it possible at all?

 You'd treat it as a generic bean. In Resin 4.0.x, it would be the

 c3p0:DataSourceImpl xmlns:c3p0=...
   ...
 /c3p0:DataSourceImpl

 The database tag wouldn't make sense, because it's integrated with
 Resin's JCA/pooling code, which is what you're trying to replace.

 -- Scott
 D.








___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest


Re: [Resin-interest] Custom datasource implementation

2010-04-08 Thread Scott Ferguson
Daniel López wrote:
 Hi there,

 For some reason, I would like to be able inside Resin a datasource 
 implementation other than Resin's, C3P0 for example, and I have been 
 unable to find in the documentation how would one configure it. The 
 examples that I found use the database tag, which does not seem to 
 have an attribute to specify an implementation class for the DataSource.

 Is it possible at all?
   
You'd treat it as a generic bean. In Resin 4.0.x, it would be the

c3p0:DataSourceImpl xmlns:c3p0=...
  ...
/c3p0:DataSourceImpl

The database tag wouldn't make sense, because it's integrated with 
Resin's JCA/pooling code, which is what you're trying to replace.

-- Scott
 D.
 ---
 Daniel Lopez Janariz (d.lo...@uib.es)
 ---


 ___
 resin-interest mailing list
 resin-interest@caucho.com
 http://maillist.caucho.com/mailman/listinfo/resin-interest

   



___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest