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
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
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]
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]
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]
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]
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]
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]
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]
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]
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
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
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
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
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
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
-
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
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
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
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
-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
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,
22 matches
Mail list logo
