tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: Lutris_Kelp: [Fwd: What Do We Do With The User's Classpath?]
Date Wed, 19 Jul 2000 20:22:34 GMT
cmanolache@yahoo.com wrote:

> However, a more likely case is:
>
> - sysadmin upgrades the database and the driver
> - All apps including FooBar driver will no longer work in Catalina,
> because they use a (now) wrong driver.
>

But the sysadmin can know what apps he/she installed, and what libraries they have
included, just be looking.  How does the *sysadmin* know that this particular app
will work right with the new driver?  Seems like the smart admins would go back to
the web app provider and ask ... and pull the now useless drivers from WEB-INF/lib
if the app developer says yes.


>
> It is more likely because (IMHO) the sysadmin knows better than the web
> app developer what database it wants to use for his server and what is
> the right driver.
>
> Another problem ( I repeated this case few times, it seems nobody reads my
> mails :-( ) - you may have a database like Oracle where a native driver
> exists and ( as Oracle claims) it's faster.
>

Oh your mails get read and analyzed all right.  It's just that there is more than
one use case that you have to design servers and APIs for.  The class loader
issues with Tomcat (which currently follows the "system class path first"
approach) are proof enough that this is not optimal for everyone.

>
> Not to mention that the webapp developer have no idea where the
> application will run - it can be any server or any application.
>

And if you don't give the app developer control of the runtime dependencies of
their app, they have no way to predict whether the app will run on any given
server.

Microsoft is finally learning the about the damage caused by DLL hell -- let's not
recreate (or perpetuate) the same types of problems here.

>
> Costin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message