proxool-developer

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

RE: [Proxool-developer] Bug 673073

[Bill H. <bi...@lo...>]

On Wed, 2003-02-05 at 14:57, Christian Nedregaard wrote:

> Or maybe just use the ServletConfigurator servlet Bill is writing for 0.7.

And I've just committed it. This was Andrew Budarevsky's idea. To
configure Proxool and to get it to shutdown correctly you just need to
add something like this to your web.xml:

<servlet> 
  <servlet-name>ServletConfigurator</servlet-name> 
  <servlet-class>org.logicalcobwebs.proxool.configuration.ServletConfigurator</servlet-class> 
  <init-param> 
    <param-name>xmlFile</param-name> 
    <param-value>WEB-INF/proxool.xml</param-value> 
  </init-param> 
</servlet> 

If, for any reason, you don't want it to autoShutdown you can add:

  <init-param> 
    <param-name>autoShutdown</param-name> 
    <param-value>false</param-value> 
  </init-param> 

I'm going to be busy documenting the conclusions (?) from these
discussions now :( I'll post something on
http://proxool.sourceforge.net/dev (which is where I put draft
documentation prior to a release).

-- 
  Bill Horsman
  Proxool
  http://proxool.sourceforge.net
  ICQ: 119577180

RE: [Proxool-developer] Bug 673073

[Martin C. <mus...@us...>]

Ok I'm not entirely done my conversation here, but obviously the
timezone difference has put me behind;)

I'm not sure if I "totally" like the idea of again putting this on the
web application shoulders. The ServletConfiguration should run as an
individual monitor application separte from the applications, and
support all instances of proxool. I have an idea how this could work,
but it's a bit complex so really comments are welcome, and please bare
with me, I haven't had my morning coffee.

Could we make the proxool distribution for web containters in two parts
(or actually three). The first distribution would be a lean and mean
"controller" distribution that sits in the commons. All it would do is 
handle registration/deregistration of new pools, manage pools for the
same connection across applications, support redirecting configuration
to the individual pools, and of course manage starting them up/shutting
them down. 

The implementation goals would *have to be* that: 
a) We keep this controller lean and mean (i.e. the less features the
better)

b) remove all external dependencies 

c) be extremely careful of the method calls made to registered proxool
pools, to support backward compatibility in the future and avoid
MethodNotFoundExceptions.

The second distribution is just your standard proxool package, which
also now has the ability to recognise and register with the controller.
The commons-logging, and JDBC driver would be deployed here.

The third distribution would be your ServletConfiguration WAR, which
uses the controller to inspect the various running pools.

Eeek... perhaps a little too complex. I can already see flaws as I
re-read this too. But this would give yor WARs complete independence
from the proxool code. Also the managing of all pools from a single
Servlet is powerful (didn't Bill suggest making proxool one day a
fail-over solution;)

Two other feedbacks from previous posts:

- DataSource is a Good Thing (tm)

- Refactor logging code a Good Thing Too (unregistered)

Ok, I've done make wild and crazy suggestions. Back to my DocBook...
Martin

On Wed, 2003-02-05 at 10:14, Bill Horsman wrote:
> On Wed, 2003-02-05 at 14:57, Christian Nedregaard wrote:
> 
> > Or maybe just use the ServletConfigurator servlet Bill is writing for 0.7.
> 
> And I've just committed it. This was Andrew Budarevsky's idea. To
> configure Proxool and to get it to shutdown correctly you just need to
> add something like this to your web.xml:
> 
> <servlet> 
>   <servlet-name>ServletConfigurator</servlet-name> 
>   <servlet-class>org.logicalcobwebs.proxool.configuration.ServletConfigurator</servlet-class> 
>   <init-param> 
>     <param-name>xmlFile</param-name> 
>     <param-value>WEB-INF/proxool.xml</param-value> 
>   </init-param> 
> </servlet> 
> 
> If, for any reason, you don't want it to autoShutdown you can add:
> 
>   <init-param> 
>     <param-name>autoShutdown</param-name> 
>     <param-value>false</param-value> 
>   </init-param> 
> 
> I'm going to be busy documenting the conclusions (?) from these
> discussions now :( I'll post something on
> http://proxool.sourceforge.net/dev (which is where I put draft
> documentation prior to a release).