RE: Best practice question: where to place project libraries
Howdy, >> Yes, there's an excellent way to do this: documentation. End of story > >That is not the end of story, of course, or else you wouldn't support >META-INF/context.xml. I personally wish we didn't support it, in fact. I think it's caused much more confusion than it's worth, and something that causes our power users like you to be confused is usually not good. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practice question: where to place project libraries
Shapira, Yoav wrote: Yes, there's an excellent way to do this: documentation. End of story That is not the end of story, of course, or else you wouldn't support META-INF/context.xml. -- Josh Rehman citysearch.com 213.739.3559 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best practice question: where to place project libraries
Howdy, >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. Yes, there's an excellent way to do this: documentation. End of story ;) Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practice question: where to place project libraries
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practice question: where to place project libraries
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practice question: where to place project libraries
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best practice question: where to place project libraries
Howdy, My take on this: everything used to build every version of your deliverable should be under source code control: that includes dependencies such as servlet-api.jar. So it's not OK to simply rely on the tomcat distro servlet-api.jar. It IS OK to copy the tomcat distro servlet-api.jar into your source code control system. It is also OK to use a 3rd party repository like ibiblio for your dependencies, but some organizations won't like that. As for putting these libraries in your WAR: Senor Ruthenbeck was right no target in saying you don't put container-provided libraries in the WAR, as most containers (including tomcat) will barf. Yoav Shapira Millennium ChemInformatics >-Original Message- >From: Josh Rehman [mailto:[EMAIL PROTECTED] >Sent: Tuesday, February 10, 2004 7:17 PM >To: Tomcat Users List >Subject: 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: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Re: Re: Re: Best practice question: where to place project libraries
Ya hemos recibido su solicitud de correo en breve le enviaremos su nombre de usuario y contreseña. Gracias por confiar en nosotros - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Re: Re: Best practice question: where to place project libraries
Ya hemos recibido su solicitud de correo en breve le enviaremos su nombre de usuario y contreseña. Gracias por confiar en nosotros - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Re: Best practice question: where to place project libraries
Ya hemos recibido su solicitud de correo en breve le enviaremos su nombre de usuario y contreseña. Gracias por confiar en nosotros - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Re: Best practice question: where to place project libraries
Ya hemos recibido su solicitud de correo en breve le enviaremos su nombre de usuario y contreseña. Gracias por confiar en nosotros - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Re: Best practice question: where to place project libraries
Ya hemos recibido su solicitud de correo en breve le enviaremos su nombre de usuario y contreseña. Gracias por confiar en nosotros - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Re: Best practice question: where to place project libraries
Ya hemos recibido su solicitud de correo en breve le enviaremos su nombre de usuario y contreseña. Gracias por confiar en nosotros - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Re: Best practice question: where to place project libraries
Ya hemos recibido su solicitud de correo en breve le enviaremos su nombre de usuario y contreseña. Gracias por confiar en nosotros - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Best practice question: where to place project libraries
Ya hemos recibido su solicitud de correo en breve le enviaremos su nombre de usuario y contreseña. Gracias por confiar en nosotros - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practice question: where to place project libraries
Matt Raible wrote: -Original Message- From: Josh Rehman [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practice question: where to place project libraries
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Best practice question: where to place project libraries
> -Original Message- > From: Josh Rehman [mailto:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practice question: where to place project libraries
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practice question: where to place project libraries
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practice question: where to place project libraries
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best practice question: where to place project libraries
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
