You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Josh Rehman <jr...@citysearch.com> on 2004/02/11 01:16:39 UTC
Best practice question: where to place project libraries
I need servlet-api.jar to compile my project. I may need some of the
commons-beans stuff in the future. Should I put these libs in my
projects lib folder (and then in the war) or should I rely on the tomcat
versions? If the latter, which jar will be used, and what should I do if
I deploy to a different container?
I'm leaning toward duplicating the libraries (this removes an
environment dependancy, too), but I'd like some advice.
--
Josh Rehman
citysearch.com
213.739.3559
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Best practice question: where to place project libraries
Posted by Josh Rehman <jr...@citysearch.com>.
Justin Ruthenbeck wrote:
> Although I haven't personally ever needed functionality like this,
> there's no argument it'd be useful in some situations. Wanna implement
> it for everyone? ;) Like John Holman mentioned, however, there will be
> (practically insurmountable?) problems making the Tomcat container
> classloader update with new libraries included in the app's WAR.
> That'll get really messy really quick.
I'm advocating something more radical: *copy* libraries in said
directories into the containers common and shared directories. Someone
else mentioned that this would alter the environement for other webapps,
which is an important drawback. Another drawback is the restart requirement.
But the fact remains that the developer should have some easy way to
indicate to the deployer what dependancies need to be met esp WRT JNDI
resources, and an easy (for the deployer) way to satisfy these
dependancies. AFAIk there is no good way to do this.
META-INF/context.xml does this in a small way, and it would be nice to
generalize to libraries and drivers. I'm not yet in a position to do
this development, although I might soon be.
--
Josh Rehman
citysearch.com
213.739.3559
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Best practice question: where to place project libraries
Posted by Justin Ruthenbeck <ju...@nextengine.com>.
At 07:40 PM 2/10/2004, you wrote:
>Justin Ruthenbeck wrote:
>>I haven't used the META-INF/context.xml convention, so I'm not too
>>familiar with it. Conceptually, it's questionable whether a webapp
>>should be able to modify container configuration ... even if it's just
>>configuration for that one app. Practically it may be useful, but it's
>>a bluring of the lines of responsibility between the development and
>>deployment -- two things which really should be separate.
>
>The question has been answered ("yes, a webapp can alter the
>container"), and yes, the container should be modifiable by the
>developer, but only under certain circumstances. I would not allow even
>the META-INF/context.xml convention on a production server, for example.
>However it's quite handy during development, and extending the
>convention would be handier still.
>
>I am not aware of a way to prevent Tomcat from respecting the
>META-INF/context.xml convention, but if there was a way I'd expect it to
>be mentioned here:
Although I haven't personally ever needed functionality like this,
there's no argument it'd be useful in some situations. Wanna implement
it for everyone? ;) Like John Holman mentioned, however, there will be
(practically insurmountable?) problems making the Tomcat container
classloader update with new libraries included in the app's WAR. That'll
get really messy really quick.
justin
______________________________________________
Justin Ruthenbeck
Software Engineer, NextEngine Inc.
justinr - AT - nextengine DOT com
Confidential. See:
http://www.nextengine.com/confidentiality.php
______________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Best practice question: where to place project libraries
Posted by Josh Rehman <jr...@citysearch.com>.
Justin Ruthenbeck wrote:
> I haven't used the META-INF/context.xml convention, so I'm not too
> familiar with it. Conceptually, it's questionable whether a webapp
> should be able to modify container configuration ... even if it's just
> configuration for that one app. Practically it may be useful, but it's
> a bluring of the lines of responsibility between the development and
> deployment -- two things which really should be separate.
The question has been answered ("yes, a webapp can alter the
container"), and yes, the container should be modifiable by the
developer, but only under certain circumstances. I would not allow even
the META-INF/context.xml convention on a production server, for example.
However it's quite handy during development, and extending the
convention would be handier still.
I am not aware of a way to prevent Tomcat from respecting the
META-INF/context.xml convention, but if there was a way I'd expect it to
be mentioned here:
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/printer/deployer-howto.html
And if it existed it could apply to deployment of shared libraries, too.
--
Josh Rehman
citysearch.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Best practice question: where to place project libraries
Posted by Justin Ruthenbeck <ju...@nextengine.com>.
At 04:49 PM 2/10/2004, you wrote:
>>As a general rule, strive to keep your webapp self-contained and
>>autonomous with only J2EE-standard dependencies (things like JNDI
>>objects that are configurable in every container). Unless there's a
>>reason not to (JDBC drivers is one common one), package your own
>>dependent libraries with your app -- it frees you from versioning
>>problems (maintaining the correct library versions for your app over
>>time) and makes migration between containers much easier.
>
>Thanks. You bring up an interesting aspect of container configuration:
>database drivers. It would be interesting to extend the
>META-INF/context.xml tomcat convention to include support for the
>installation of 3rd party libraries. E.g., libraries placed in
>META-INF/server/lib will be placed into the similiar tomcat directory on
>deployment. Same thing for common/lib.
Interesting idea. It could be useful for some people (especially those
with simple setups), but I think just about every administrator out there
would shutter at the thought of some random webApp modifying the
libraries that all other webApps use. That and if you need to support
multiple containers, you're still SOL.
I haven't used the META-INF/context.xml convention, so I'm not too
familiar with it. Conceptually, it's questionable whether a webapp
should be able to modify container configuration ... even if it's just
configuration for that one app. Practically it may be useful, but it's a
bluring of the lines of responsibility between the development and
deployment -- two things which really should be separate.
justin
PS: Kinda funny how only us West Coasters tend to post between the hours
of 3-7pm PST.
______________________________________________
Justin Ruthenbeck
Software Engineer, NextEngine Inc.
justinr - AT - nextengine DOT com
Confidential. See:
http://www.nextengine.com/confidentiality.php
______________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Best practice question: where to place project libraries
Posted by Oliver Geisser <ol...@gmx.de>.
Hi
Josh Rehman wrote:
>
>
> Justin Ruthenbeck wrote:
>
>> As a general rule, strive to keep your webapp self-contained and
>> autonomous with only J2EE-standard dependencies (things like JNDI
>> objects that are configurable in every container). Unless there's a
>> reason not to (JDBC drivers is one common one), package your own
>> dependent libraries with your app -- it frees you from versioning
>> problems (maintaining the correct library versions for your app over
>> time) and makes migration between containers much easier.
>
>
> Thanks. You bring up an interesting aspect of container configuration:
> database drivers. It would be interesting to extend the
> META-INF/context.xml tomcat convention to include support for the
> installation of 3rd party libraries. E.g., libraries placed in
> META-INF/server/lib will be placed into the similiar tomcat directory on
> deployment. Same thing for common/lib.
No. I don't think this is a good solution.
The best solution would be to use the database driver inside the
webapp.war (if there is one provided).
This would require some (heavy) refactoring of the classloader/JNDI
mechanism, but it can be done.
And in an perfect world this would be part of the (next) servlet spec
so every container would behave in the same way.
Ciao, Olli
-- og
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Best practice question: where to place project libraries
Posted by John Holman <j....@qmul.ac.uk>.
Matt Raible wrote:
>>-----Original Message-----
>>From: Josh Rehman [mailto:jrehman@citysearch.com]
>>Sent: Tuesday, February 10, 2004 5:49 PM
>>
>>Thanks. You bring up an interesting aspect of container
>>configuration:
>>database drivers. It would be interesting to extend the
>>META-INF/context.xml tomcat convention to include support for the
>>installation of 3rd party libraries. E.g., libraries placed in
>>META-INF/server/lib will be placed into the similiar tomcat
>>directory on
>>deployment. Same thing for common/lib.
>
>
> +1 - that'd be slick!
Seems wrong to me - one web application should not be able
to change the environment for others. (Also I think a Tomcat
server restart would be needed for it to take effect anyway).
John.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
RE: Best practice question: where to place project libraries
Posted by Matt Raible <li...@raibledesigns.com>.
> -----Original Message-----
> From: Josh Rehman [mailto:jrehman@citysearch.com]
> Sent: Tuesday, February 10, 2004 5:49 PM
>
> Thanks. You bring up an interesting aspect of container
> configuration:
> database drivers. It would be interesting to extend the
> META-INF/context.xml tomcat convention to include support for the
> installation of 3rd party libraries. E.g., libraries placed in
> META-INF/server/lib will be placed into the similiar tomcat
> directory on
> deployment. Same thing for common/lib.
+1 - that'd be slick!
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Best practice question: where to place project libraries
Posted by Josh Rehman <jr...@citysearch.com>.
Justin Ruthenbeck wrote:
> As a general rule, strive to keep your webapp self-contained and
> autonomous with only J2EE-standard dependencies (things like JNDI
> objects that are configurable in every container). Unless there's a
> reason not to (JDBC drivers is one common one), package your own
> dependent libraries with your app -- it frees you from versioning
> problems (maintaining the correct library versions for your app over
> time) and makes migration between containers much easier.
Thanks. You bring up an interesting aspect of container configuration:
database drivers. It would be interesting to extend the
META-INF/context.xml tomcat convention to include support for the
installation of 3rd party libraries. E.g., libraries placed in
META-INF/server/lib will be placed into the similiar tomcat directory on
deployment. Same thing for common/lib.
--
Josh Rehman
citysearch.com
213.739.3559
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Best practice question: where to place project libraries
Posted by Justin Ruthenbeck <ju...@nextengine.com>.
Forgot to mention...
At 04:36 PM 2/10/2004, you wrote:
>At 04:16 PM 2/10/2004, you wrote:
>>I need servlet-api.jar to compile my project. I may need some of the
>>commons-beans stuff in the future. Should I put these libs in my
>>projects lib folder (and then in the war) or should I rely on the
>>tomcat versions? If the latter, which jar will be used, and what should
>>I do if I deploy to a different container?
>>
>>I'm leaning toward duplicating the libraries (this removes an
>>environment dependancy, too), but I'd like some advice.
>
>As a general rule, strive to keep your webapp self-contained and
>autonomous with only J2EE-standard dependencies (things like JNDI
>objects that are configurable in every container). Unless there's a
>reason not to (JDBC drivers is one common one), package your own
>dependent libraries with your app -- it frees you from versioning
>problems (maintaining the correct library versions for your app over
>time) and makes migration between containers much easier.
>
>If you're actively supporting multiple containers, it's practically
>required.
Libraries such as servlet-api.jar will be provided by each vendor and
shouldn't be included in the distribution (use it to compile, but at
runtime, rely on your container to provide those interfaces). Including
something like servlet-api.jar in your distro will get messy. 3rd-party
libraries (such as commons-*) should be included since they're really
part of your app -- not the container.
justin
______________________________________________
Justin Ruthenbeck
Software Engineer, NextEngine Inc.
justinr - AT - nextengine DOT com
Confidential. See:
http://www.nextengine.com/confidentiality.php
______________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
Re: Best practice question: where to place project libraries
Posted by Justin Ruthenbeck <ju...@nextengine.com>.
At 04:16 PM 2/10/2004, you wrote:
>I need servlet-api.jar to compile my project. I may need some of the
>commons-beans stuff in the future. Should I put these libs in my
>projects lib folder (and then in the war) or should I rely on the tomcat
>versions? If the latter, which jar will be used, and what should I do if
>I deploy to a different container?
>
>I'm leaning toward duplicating the libraries (this removes an
>environment dependancy, too), but I'd like some advice.
As a general rule, strive to keep your webapp self-contained and
autonomous with only J2EE-standard dependencies (things like JNDI objects
that are configurable in every container). Unless there's a reason not
to (JDBC drivers is one common one), package your own dependent libraries
with your app -- it frees you from versioning problems (maintaining the
correct library versions for your app over time) and makes migration
between containers much easier.
If you're actively supporting multiple containers, it's practically
required.
justin
______________________________________________
Justin Ruthenbeck
Software Engineer, NextEngine Inc.
justinr - AT - nextengine DOT com
Confidential. See:
http://www.nextengine.com/confidentiality.php
______________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org