Discussion:
WAR file and context.xml overwriting on deployment
Joe Reger, Jr.
2004-11-16 22:28:24 UTC
Permalink
Hi.

I have a java web app that I package as a WAR file. People download it.
They install it on their instance of Tomcat. They configure application
settings as variables in context.xml.

The problem is that each time they grab updated code (a new WAR file) they
overwrite their context.xml file with the default settings.

Is there some more user-friendly way to deal with this configuration issue?
How do others that provide downloadable WAR files do this?

I understand that this may not be the traditional usage of WAR files and
Tomcat. Ideas welcome.

Thanks,

Joe Reger
QM
2004-11-17 00:48:16 UTC
Permalink
: The problem is that each time they grab updated code (a new WAR file) they
: overwrite their context.xml file with the default settings.
:
: Is there some more user-friendly way to deal with this configuration issue?
: How do others that provide downloadable WAR files do this?

This is the opposite of what I've seen: usually, the context.xml (the
version copied to {tomcat}/conf/{engine}/{host}/{context-name}.xml) is
*not* overritten with the (newer) version in the newly-deployed WAR
file.

as for dealing with this issue:
As context.xml is Tomcat-specific, you could expect a certain level
of Tomcat expertise from your users. By "expertise" in this case, I
mean, "remove the old context XML file before deploying the new WAR, to
make sure the newer file is copied over."

-QM
--
software -- http://www.brandxdev.net
tech news -- http://www.RoarNetworX.com
b***@tcs.com
2004-11-17 06:36:11 UTC
Permalink
Hi,
I have a question for webapplication developer ,
I have already applied JDBcRealm but im confused between the security -
constraints in the web.xml and the realm
because in web.xml also web.xml we declare the security roles and also in
database table so if we have say 5-10 differernt kind of users do we need
to declare them in web.xml and also to create them in database ??
My second question is after the application authentication type "FORM" my
action is =j_security_check how ever in i want to direct the user to
some welcome jsp after succcessful log where do i need to mention
that??

your help is appreciated
thanks
regards


Birendar Singh Waldiya
Tata Consultancy Services Limited
Mailto: ***@tcs.com
Website: http://www.tcs.com

DISCLAIMER: The information contained in this message is intended only and solely for the addressed individual or entity indicated in this message and for the exclusive use of the said addressed individual or entity indicated in this message (or responsible for delivery of the message to such person) and may contain legally privileged and confidential information belonging to Tata Consultancy Services Limited. It must not be printed, read, copied, disclosed, forwarded, distributed or used (in whatsoever manner) by any person other than the addressee. Unauthorized use, disclosure or copying is strictly prohibited and may constitute unlawful act and can possibly attract legal action, civil and/or criminal. The contents of this message need not necessarily reflect or endorse the views of Tata Consultancy Services limited on any subject matter.
Any action taken or omitted to be taken based on this message is entirely at your risk and neither the originator of this message nor Tata Consultancy Services Limited takes any responsibility or liability towards the same. Opinions, conclusions and any other information contained in this message that do not relate to the official business of Tata Consultancy Services limited shall be understood as neither given nor endorsed by Tata Consultancy Services Limited or any affiliate of Tata Consultancy Services Limited. If you have received this message in error, you should destroy this message and may please notify the sender by e-mail.
Thank you.
Tim Funk
2004-11-17 11:31:54 UTC
Permalink
See section SRV.12.3 Programmatic Security of the Servlet spec for the role
link question.

As for the welcome page - the spec wasn't meant to handle cases like this.
The container protects resources. Once you try to access a protected resource
- you mustr authenticate. Then you are passed to the protected resource, not
to a different page.

-Tim
Post by b***@tcs.com
Hi,
I have a question for webapplication developer ,
I have already applied JDBcRealm but im confused between the security -
constraints in the web.xml and the realm
because in web.xml also web.xml we declare the security roles and also in
database table so if we have say 5-10 differernt kind of users do we need
to declare them in web.xml and also to create them in database ??
My second question is after the application authentication type "FORM" my
action is =j_security_check how ever in i want to direct the user to
some welcome jsp after succcessful log where do i need to mention
that??
your help is appreciated
thanks
regards
Shapira, Yoav
2004-11-17 13:34:27 UTC
Permalink
Hi,
You could use a different, your own, configuration file. You would then
have some logic into the file name, e.g. myconfigfile-v1 for WAR v1, and
then when your ship WAR v2, use myconfigfile-v2, so it wouldn't
overwrite the first, etc.

Yoav Shapira http://www.yoavshapira.com
-----Original Message-----
Sent: Tuesday, November 16, 2004 5:28 PM
Subject: WAR file and context.xml overwriting on deployment
Hi.
I have a java web app that I package as a WAR file. People download
it.
They install it on their instance of Tomcat. They configure
application
settings as variables in context.xml.
The problem is that each time they grab updated code (a new WAR file)
they
overwrite their context.xml file with the default settings.
Is there some more user-friendly way to deal with this configuration
issue?
How do others that provide downloadable WAR files do this?
I understand that this may not be the traditional usage of WAR files
and
Tomcat. Ideas welcome.
Thanks,
Joe Reger
---------------------------------------------------------------------
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.
Loading...