You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Jose Alberto Fernandez <jo...@us.oracle.com> on 2000/01/12 21:01:01 UTC
Re: setting config file for web application
Ari Halberstadt wrote:
> Craig wrote:
> >Ari Halberstadt wrote:
> >
> >> How can you specify a config file for a web application without messing
> >> with the web application's web.xml file? There's the WEB-INF/web.xml file,
> >>...
> >
> >A big piece of the thinking behind web applications, and the "web.xml"
> >deployment descriptor, is to make the web application as independent of the
> >environment it runs in as possible. The result of this line of thinking was
> >that *everything* (except the context path) is specified in the web.xml file.
> >Providing a mechanism to access a path to a properties file, as you suggest,
> >would create a dependency on the external environment that is not currently
> >present.
>
> Except that this line of thinking doesn't work in the real world. It's nice
> to have a config file that specifies constant things, like the name of the
> application. But there are also variable parameters, e.g., database
> connection parameters, whose specific values have nothing whatsoever to do
> with the application and which cannot be predicted in advance. The whole
> point of parameters is to allow runtime parameterization, if they could be
> coded as constants in the code there would be no need for the parameters.
> Tomcat (and the servlet spec) really needs a way to specify additional
> variable properties without requiring people to muck around with the
> application's web.xml file.
>
I agree completely with you. To suggest that in order to deploy an application I
have to open the application JAR, play with the descriptors (probably braking
something else) and then re-jar the whole thing in order to deploy is kind of
moronic, if we think on shrink-wrap application that we go purchase at Safeway :-)
It has always been my impression that the specs do not address this issue because
it is outside of the application itself and depends on the container and tools
being used for deployment. For example, it the container is tomcat alone,
deployment info is different that if the container is Apache/tomcat distributed
across different machines (static files go one place and dnamic stuff goes
somewhere else).
However it would be nice to have an extensible basic DTD for what such deployment
XML should look like. It has to be extensible in order to allow each vendor to
control their own requirements of their own container.
>
> >
> >The servlet 2.2 API spec requires that the "web.xml" file be found in the
> >WEB-INF directory. If you want to support alternative configuration files,
> >one approach would be to use a startup script for your servlet container that
> >copied different "web.xml" files depending on command line options into the
> >official place. I've had to play this kind of game in environments where I
> >have separate development and production servers, to set the correct database
> >connection parameters based on which environment I am running in.
>
> This feels like a kludge. I want to distribute a constant set of sources
> and let people specify their own configuration in an independent location.
> As another example, let's say I have 10 virtual hosts, each of which is
> provided with its own database. I only want to keep one copy of the
> application around, and the various source files (.java, .jsp, etc.) can
> easily be shared among all of the virtual hosts. The only things that need
> to vary are the parameters for each host. I don't see how to do this with
> the current web.xml scheme.
>
> I think server.dtd needs an additional attribute to specify the location of
> a config file for a context. Then we'd have to decide what is allowed in
> that file (I'd suggest making it just like web.xml) and how its data are
> combined with the web.xml file distributed with the application.
>
> -- Ari Halberstadt mailto:ari@shore.net <http://www.magiccookie.com/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
--
------------------------------------------------------------------------
Jose Alberto Fernandez 500 Oracle Parkway, M/S 9op4
Development Manager Redwood Shores, CA 94065
ORACLE Corp. Phone: (650) 506-8830
Java Products Group Fax: (650) 506-7303
Languages & Obj-Relational Tech Email: jofernan@us.oracle.com
Re: setting config file for web application
Posted by Bob Jamison <rj...@lincom-asg.com>.
>
> Tomcat, or any other server, needs to provide tools that make it easy to install new
> applications (and tweak the configuration properties to suit the local environment).
> That's one of the places that container providers can compete on value.
>
> Adding access to external properties into the servlet spec creates totally unnecessary
> complexity (and reduced portability), due to the variety of possible environments to
> deploy into
I agree, and .....
as with any other Open Source project: You Want It, You Do It.
This will be wonderful. Thanks in advance. (j/k! ;-)
Actually, since the main app directory, the parent of WEB-INF, is basically
the "current working directory" of the app, any file placed there should be easily
readable by the app. I don't see this as a problem, unless the app is one of those
wonderful things (j/k again) that requires an absolutely perfect environment
in which to run. I consider a good app one which fails 'softly' when things are
not quite perfect, and faults on the side of operating in a reduced mode, instead
of merely dying. Good example, loading a config file:
1. Try the current working directory
2. Try a "standard place"
3. Try a place defined by a Variable
etc
etc
n. All else fails, use defaults
Actually, this somewhat relates to a request I have made to Sun a couple of times
in the past. I think a Java app should have a default .properties file, that gets
auto-loaded by the VM, when the app is started, like running MyClass
will autoload MyClass.properties. This is akin to X-windows loading a config
file with the same name as the program, from the app-defaults directory.
Bob
Re: setting config file for web application
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
Jose Alberto Fernandez wrote:
> Ari Halberstadt wrote:
>
> > Craig wrote:
> > >Ari Halberstadt wrote:
> > >
> > >> How can you specify a config file for a web application without messing
> > >> with the web application's web.xml file? There's the WEB-INF/web.xml file,
> > >>...
> > >
> > >A big piece of the thinking behind web applications, and the "web.xml"
> > >deployment descriptor, is to make the web application as independent of the
> > >environment it runs in as possible. The result of this line of thinking was
> > >that *everything* (except the context path) is specified in the web.xml file.
> > >Providing a mechanism to access a path to a properties file, as you suggest,
> > >would create a dependency on the external environment that is not currently
> > >present.
> >
> > Except that this line of thinking doesn't work in the real world. It's nice
> > to have a config file that specifies constant things, like the name of the
> > application. But there are also variable parameters, e.g., database
> > connection parameters, whose specific values have nothing whatsoever to do
> > with the application and which cannot be predicted in advance. The whole
> > point of parameters is to allow runtime parameterization, if they could be
> > coded as constants in the code there would be no need for the parameters.
> > Tomcat (and the servlet spec) really needs a way to specify additional
> > variable properties without requiring people to muck around with the
> > application's web.xml file.
> >
>
Tomcat, or any other server, needs to provide tools that make it easy to install new
applications (and tweak the configuration properties to suit the local environment).
That's one of the places that container providers can compete on value.
Adding access to external properties into the servlet spec creates totally unnecessary
complexity (and reduced portability), due to the variety of possible environments to
deploy into
>
> I agree completely with you. To suggest that in order to deploy an application I
> have to open the application JAR, play with the descriptors (probably braking
> something else) and then re-jar the whole thing in order to deploy is kind of
> moronic, if we think on shrink-wrap application that we go purchase at Safeway :-)
>
> It has always been my impression that the specs do not address this issue because
> it is outside of the application itself and depends on the container and tools
> being used for deployment. For example, it the container is tomcat alone,
> deployment info is different that if the container is Apache/tomcat distributed
> across different machines (static files go one place and dnamic stuff goes
> somewhere else).
>
Yes, that's what installer programs are for. How many Windows apps would you install
if you had to open the Windows Registry and tweak all the new settings required for
this app?
It's also totally consistent with the role of Deployer being separate from the
Application Developer, and is the same theme that is used for EJB containers and
J2EE-compatible servers.
>
> However it would be nice to have an extensible basic DTD for what such deployment
> XML should look like. It has to be extensible in order to allow each vendor to
> control their own requirements of their own container.
>
Configuration of the server itself should be unique to that server. Configuration of
a web application (i.e. the web.xml file) should be 100% consistent and portable
across all containers that implement a given rev of the servlet spec.
Craig
Re: setting config file for web application
Posted by Jose Alberto Fernandez <jo...@us.oracle.com>.
"Craig R. McClanahan" wrote:
> Tom Clarke wrote:
>
> > On Wed, 12 Jan 2000, Jose Alberto Fernandez wrote:
> >
> > > Ari Halberstadt wrote:
> > >
> > > > Craig wrote:
> > > >
> > > > Except that this line of thinking doesn't work in the real world. It's nice
> > > > to have a config file that specifies constant things, like the name of the
> > > > application. But there are also variable parameters, e.g., database
> > > > connection parameters, whose specific values have nothing whatsoever to do
> >
> > Yes I was wondering about this too. I have two typical situations where
> > something outside of the .war is needed:
> >
> > 1. Database Connections - More generally this is the server specific
> > information. All the web applications I build have dev/staging and
> > production servers so we have a configuration file with only the server
> > specific info in, which is explicitly excluded from the roll script.
> >
>
> (Rhetorical question, but bear with me) Have you ever installed a Windows
> application? What's the typical user experience? The app comes with an installer
> program that lets you customize the installation directory, the default
> configuration options, and even what portions of the app get installed. Along the
> way, the installer creates directories as needed (customized by your choices),
> plus registry entries, start menu shortcuts, and everything else you need to point
> and click to start your application.
>
> Now, assume you are handed a Windows app with a 20-page README.TXT file that tells
> you what to do to install it. The same steps are required, but you have to do
> them all manually. How likely are you to actually use this application?
>
> What's the difference between this sceneario and a servlet/JSP based web app? Not
> a thing -- it is your responsibility as a web application provider to include an
> installation/customization utility that makes it easy for a sysadmin to deploy
> your application. The servlet 2.2 spec already provides a standard platform for
> defining portable applications, just as the Windows API includes standard
> environment for applications to install themselves (of course,this only applies to
> the Windows platform, but that is not relevant to the point I'm trying to make).
>
There is a very big difference here. In the traditional Windows case the application
installer is for ONE Container (the Windows OS). In the case we are discussing here
the Application needs to be able to install in an unbound number of containers with
different requirements.
This means that you need to standarize the installation API in order to be able to
provide the "Windows installation experience".
J2EE goes half way there with the web.xml file format. However the current
conceptualization on how to go from there to a running application is flaw. The flaw
is in that web.xml contains not only information that needs to be modified during
installation but also information that SHOULD NOT be touch.
What people are asking here is for standardizing a mechanism that gives you the
following:
1) Customize an application to a particular container type
(This depends on the container to be used)
2) Customize the application to a particular execution environment
(This may be more application specific, but the list of what is needed can be
found on the web.xml file)
3) Being able to do this with minimal manipulation (if any) of the original WAR file.
What we need is an standardize way to take the (external) customization information,
and get the content in the web.xml and produce (based on the specific container) the
info needed to perform the deployment on that particular container. For example the
resulting .xml file may be just an expanded web.xml with the additional information
required by an specific container.
Once you have such a framework you can have all kinds of installation tools that help
you with the deployment of the applications.
>
> >
> > 2. Customizable applications - I have also devloped a semi-shrink wrapped
> > servlet application and using a .war to allow it to be easily installed on
> > multiple web sites seems really good.
> >
> > However, one of the requirements of which is to be able to
> > change the L&F. As such, being able to override the default JSPs seems
> > like the way to do it.
> >
>
> Same difference ... it is up to you as an application provider to provide
> appropriate customization capabilities. Such things are usually
> application-specific, and have nothing to do with the platform itself.
>
This I agree with you, this is an application specific requirement. But there should
be some way a developer can set information (references in web.xml) in order to be
able to do this.
>
> >
> > In either case, it is undesirable to break up the .war.
> >
>
> I disagree. There are no undocumented APIs involved ... your installer program
> can very easily do this for the user. The installer will "break up" the war file,
> recognize the options you want to change, and reconstruct it -- no big deal.
>
The problem here is that there is no way to distinguish a customized application from
a non customized. It is like saying than when you install a windows app. You take your
floppies go thru the installer picking options and then the installer ask you to
create new floppies with the customized version of the app, and then after that then
you actually go and deploy that. Sounds funny to me.
>
> >
> > Tom
> >
>
> Craig McClanahan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
--
------------------------------------------------------------------------
Jose Alberto Fernandez 500 Oracle Parkway, M/S 9op4
Development Manager Redwood Shores, CA 94065
ORACLE Corp. Phone: (650) 506-8830
Java Products Group Fax: (650) 506-7303
Languages & Obj-Relational Tech Email: jofernan@us.oracle.com
Re: setting config file for web application
Posted by co...@costin.dnt.ro.
> Now, assume you are handed a Windows app with a 20-page README.TXT file that tells
> you what to do to install it. The same steps are required, but you have to do
> them all manually. How likely are you to actually use this application?
Craig, I agree with you on this one.
> I disagree. There are no undocumented APIs involved ... your installer program
> can very easily do this for the user. The installer will "break up" the war file,
> recognize the options you want to change, and reconstruct it -- no big deal.
Who provides the installer?
The servlet engine ( tomcat )? The War vendor ? Third-party ?
Please re-visit my proposal for automatic installation ( using RPM for
example ) - i.e. have a well-known ( or at least defined ) way to build
RPMs ( or pkg, or installShield ). It is easy to implement it, and it is
also easy to define "global" parameters, that will be set in all contexts
( like jdbc.driver, etc).
Costin
Re: setting config file for web application
Posted by Tom Clarke <to...@imon.net>.
On Fri, 14 Jan 2000, Craig R. McClanahan wrote:
> Tom Clarke wrote:
>
> What's the difference between this sceneario and a servlet/JSP based web app? Not
> a thing -- it is your responsibility as a web application provider to include an
> installation/customization utility that makes it easy for a sysadmin to deploy
> your application. The servlet 2.2 spec already provides a standard platform for
> defining portable applications, just as the Windows API includes standard
> environment for applications to install themselves (of course,this only applies to
> the Windows platform, but that is not relevant to the point I'm trying to make).
Well in this case, the development effort required to make a swish
installer is undesirable. I control all three servers, I just want a way
to keep information about the local environment seperate from my
application. (Someone suggested JNDI, and this would seem like a good way
to get to it - still need a provider that will read from a properties or
.ini file tho).
An installer doesn't really help much here. In fact I want the entire
dev->stage, stage->live to be completely automated and require no human
intervention.
> >
> > However, one of the requirements of which is to be able to
> > change the L&F. As such, being able to override the default JSPs seems
> > like the way to do it.
>
> Same difference ... it is up to you as an application provider to provide
> appropriate customization capabilities. Such things are usually
> application-specific, and have nothing to do with the platform itself.
>
It seems non-trivial to build an installer that allows customization of
L&F. Homesite (or any editor) would be a much better tool - and this
would mean taking it out of the context of an installer, I just want a
way of distiguishing the custom parts from the distributed packaged app.
In this case it might just be to specify the location of the files.
I also want to be able to update the app, without updating the L&F
customizations.
Tom
Re: setting config file for web application
Posted by "Craig R. McClanahan" <cm...@mytownnet.com>.
Tom Clarke wrote:
> On Wed, 12 Jan 2000, Jose Alberto Fernandez wrote:
>
> > Ari Halberstadt wrote:
> >
> > > Craig wrote:
> > >
> > > Except that this line of thinking doesn't work in the real world. It's nice
> > > to have a config file that specifies constant things, like the name of the
> > > application. But there are also variable parameters, e.g., database
> > > connection parameters, whose specific values have nothing whatsoever to do
>
> Yes I was wondering about this too. I have two typical situations where
> something outside of the .war is needed:
>
> 1. Database Connections - More generally this is the server specific
> information. All the web applications I build have dev/staging and
> production servers so we have a configuration file with only the server
> specific info in, which is explicitly excluded from the roll script.
>
(Rhetorical question, but bear with me) Have you ever installed a Windows
application? What's the typical user experience? The app comes with an installer
program that lets you customize the installation directory, the default
configuration options, and even what portions of the app get installed. Along the
way, the installer creates directories as needed (customized by your choices),
plus registry entries, start menu shortcuts, and everything else you need to point
and click to start your application.
Now, assume you are handed a Windows app with a 20-page README.TXT file that tells
you what to do to install it. The same steps are required, but you have to do
them all manually. How likely are you to actually use this application?
What's the difference between this sceneario and a servlet/JSP based web app? Not
a thing -- it is your responsibility as a web application provider to include an
installation/customization utility that makes it easy for a sysadmin to deploy
your application. The servlet 2.2 spec already provides a standard platform for
defining portable applications, just as the Windows API includes standard
environment for applications to install themselves (of course,this only applies to
the Windows platform, but that is not relevant to the point I'm trying to make).
>
> 2. Customizable applications - I have also devloped a semi-shrink wrapped
> servlet application and using a .war to allow it to be easily installed on
> multiple web sites seems really good.
>
> However, one of the requirements of which is to be able to
> change the L&F. As such, being able to override the default JSPs seems
> like the way to do it.
>
Same difference ... it is up to you as an application provider to provide
appropriate customization capabilities. Such things are usually
application-specific, and have nothing to do with the platform itself.
>
> In either case, it is undesirable to break up the .war.
>
I disagree. There are no undocumented APIs involved ... your installer program
can very easily do this for the user. The installer will "break up" the war file,
recognize the options you want to change, and reconstruct it -- no big deal.
>
> Tom
>
Craig McClanahan
Re: setting config file for web application
Posted by co...@costin.dnt.ro.
> Yes I was wondering about this too. I have two typical situations where
> something outside of the .war is needed:
> 1. Database Connections - More generally this is the server specific
> information. All the web applications I build have dev/staging and
> production servers so we have a configuration file with only the server
> specific info in, which is explicitly excluded from the roll script.
Yes - that will also be important for database tag libraries - it
would be really bad to have the jdbc parameters ( driver, password) inside
the page, or to edit them for every server where we deploy.
A simple solution would be to define some params at the server level,
and have all contexts inherit them ( and treat them as normal context
params)
Or use JNDI - that would be the best solution probably ( and a
server that supports JNDI is supposed to set the default context,
so you just need to define what you need). This solution is also
very scalable.
In any case, something that is allways needed is the
context path - it would be very easy to set a default
context path ( using a context param in the current spec ),
and that would allow automated instalation ( i.e. no user
interaction ).
Costin
Re: setting config file for web application
Posted by Tom Clarke <tc...@agency.com>.
On Wed, 12 Jan 2000, Jose Alberto Fernandez wrote:
> Ari Halberstadt wrote:
>
> > Craig wrote:
> >
> > Except that this line of thinking doesn't work in the real world. It's nice
> > to have a config file that specifies constant things, like the name of the
> > application. But there are also variable parameters, e.g., database
> > connection parameters, whose specific values have nothing whatsoever to do
Yes I was wondering about this too. I have two typical situations where
something outside of the .war is needed:
1. Database Connections - More generally this is the server specific
information. All the web applications I build have dev/staging and
production servers so we have a configuration file with only the server
specific info in, which is explicitly excluded from the roll script.
2. Customizable applications - I have also devloped a semi-shrink wrapped
servlet application and using a .war to allow it to be easily installed on
multiple web sites seems really good.
However, one of the requirements of which is to be able to
change the L&F. As such, being able to override the default JSPs seems
like the way to do it.
In either case, it is undesirable to break up the .war.
Tom