RE: [Proxool-developer] Bug 673073

[Christian N. <chr...@em...>]

> I know, I've stated my thoughts on this before, but again I'll restate
> it: Proxool should not be installed at an individual web application
> level, but at the common classloader level. 

On *general* terms I disagree. IMHO moving 3rd party libraries up to the container classloader level is almost alvays a bad idea. The two main problems are these:

1)Classloader/version conflicts.
When you move a library up to the container classloader you expose the other apps in the container to danger if they include diffenrent versions of some of the same 3rd party libraries as the globally exposed library. This can result in ClassCastExeptions, problems with SEARIALID and unpredictable behaviour. I've experienced this many times with commonly used libraries such as Log4J and JAXP. As Bill said, he got this problem immediately with Proxool due to conflicts with Commons logging. This problem will increase with any additional 3rd party libraries we choose to depend on (if any...). Maybe we should just get the Commons logging code and refacor it as Proxool code (the Apache licence allows us to do so). This will solve the classloader issues and retain our dynamic logging support. 

2) Making your app dependant on a non-standard container.
To be portable web apps should only depend on a clean J2EE container (not a J2EE container + general libraries). This is again on general terms. If Proxool is used totally transparently as a JDBC driver this problem dissapears I guess. You certainly have some good arguments for making it global. Especially your point about sharing pools across applications.

> You want one instance of proxool per VM to ensure the Singleton pattern
> is enforced.

Er.. This might be a bit picky, but technically this will not break the Singleton pattern as instances of Proxool spawned from differnent classloaders are not instances of the same class.

> Additionally, of course, you break the transparency by forcing Servlet
> developers to write proxool specific code within their Servlet
> application. 
> And which Servlet would I write this "destroy" code if my
> web application has multiple Servlets? 

Wichever you like. Or maybe just use the ServletConfigurator servlet Bill is writing for 0.7.

> Proxool is most effective because
> of its transparency, I say we should foster this transparency.

Yes, this is a strong argument, but must be weighted aginst the problems mentioned above. 

It is also a strong argument for Proxool to implement DataSource since this is the standard way of appservers to serve connections shared by different apps. I used to be aginst us implementing DataSource, but now I have changed my mind. Thanks Martin :)

This is an open ended discussion that have strong advocates for either apporach. For instance: Struts recommends deployment in each app, while Log4J recommends gobal deployment.

I suggest we document both approaches with the pros and cons for each.

CHR
-- 
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

Meet Singles
http://corp.mail.com/lavalife