You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2003/03/21 12:05:26 UTC

[5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Hi,

It is not very convinient or easy to insert the declarations for 
compiled JSPs into the webapp's web.xml file. It also has the 
disadvantage of adding a lot of mess in the web.xml, which the user may 
not like.

For that reason, I propose that Tomcat parses a new (optional) XML file, 
with the same DTD as web.xml, which would contain declarations identical 
to web.xml, and which would be used for declaring the compiled JSPs. I 
propose naming that file compiledjsp.xml.

An additional advantage is that it would allow Tomcat to precompile 
webapps as they are deployed (otherwise, nasty XML manipulation is 
needed to do that, and I think overwriting the originial web.xml during 
deployment is bad).

Maybe someone has a better solution for this problem. Any comments ?

Remy


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:

> I don't know. 
> 
> jasper-compiler is needed only to support development use cases, it
> obviously shouldn't be used on production servers.
> 
> We are mixing 2 very different use cases here:
> - development - you don't need to precompile and jasper-compiler is neede
> 
> - production - it's crazy to not precompile, and jasper-compiler serves
> no purpose ( and it may be safer to not have it ). A javac compiler is also
> not need, and probably a lot of other jars and features that are not used
> can be disabled.
> If we figure out how to .ser the web.xml and all the other descriptors - 
> to optimize startup time - you can even run the production server without
> using an xml parser.
> 
> 
> IMO precompilation happens _before_ deploy - it is part of the build
> process, and results in a standard .war file that can be deployed in 
> any container.
> 
> 
> The deploy stage can generate tomcat-specific files ( like .ser, expand
> jars from the .war, move files around or distribute them in a cluster, etc).
> We could have a step that precompiles and JSP - in case the original
> .war didn't precompile, and in this case we can generate whatever file 
> format we want ( preferably .ser - it's much faster ). However the important
> case for jspc is the previous one ( i.e. precompile the app before you ship,
> as part of the build process ).

Ok, so the deployer shouldn't do anything in addition to what it does 
right now, then ?
That's fine by me, it works good enough, and I've documented how to use 
the Ant script :)
I think I should add copying jasper-runtime.jar to /WEB-INF/lib, then.

Remy


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:

> Costin Manolache wrote:
>> The main point is to _not_ hack anything, but just use the standard.
>> 
>> If you precompile your app - and include jasper-runtime.jar in
>> WEB-INF/lib - the result should work in _any_ container - the precompiled
>> jsps are _just_ regular servlets that happen to use a lib and extend from
>> a base class. That used to work - I haven't tested it recently but it
>> should still work.
>> 
>> The result of precompilation must remain a webapplication that is not
>> specific to tomcat ( or worse - to a specific version of tomcat, as would
>> be the case here, I assume such a change won't be backported to 4.0 !).
>> 
>> We have a standard way to declare the servlets that result from jsp
>> precompile, we have a standard way to declare the mappings - and I see
>> no good reason to invent another mechanism to do this.
>> 
>> I don't like web.xml - and in 2.4 is even worse than it ever was
>> ( with the XML Schema it enters a whole new level of complexity and
>> uglyness). However it is good enough for this use case - and it is the
>> standard.
> 
> Hey, I think I like the longer version better.
> 
> During deploy, we do:
> - hack web.xml
> - copy jasper-runtime.jar to /WEB-INF/lib
> 
> So we can keep jasper-compiler.jar in /server/lib ?

I don't know. 

jasper-compiler is needed only to support development use cases, it
obviously shouldn't be used on production servers.

We are mixing 2 very different use cases here:
- development - you don't need to precompile and jasper-compiler is neede

- production - it's crazy to not precompile, and jasper-compiler serves
no purpose ( and it may be safer to not have it ). A javac compiler is also
not need, and probably a lot of other jars and features that are not used
can be disabled.
If we figure out how to .ser the web.xml and all the other descriptors - 
to optimize startup time - you can even run the production server without
using an xml parser.


IMO precompilation happens _before_ deploy - it is part of the build
process, and results in a standard .war file that can be deployed in 
any container.


The deploy stage can generate tomcat-specific files ( like .ser, expand
jars from the .war, move files around or distribute them in a cluster, etc).
We could have a step that precompiles and JSP - in case the original
.war didn't precompile, and in this case we can generate whatever file 
format we want ( preferably .ser - it's much faster ). However the important
case for jspc is the previous one ( i.e. precompile the app before you ship,
as part of the build process ).


Costin 


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> The main point is to _not_ hack anything, but just use the standard.
> 
> If you precompile your app - and include jasper-runtime.jar in WEB-INF/lib -
> the result should work in _any_ container - the precompiled jsps are _just_
> regular servlets that happen to use a lib and extend from a base class.
> That used to work - I haven't tested it recently but it should still work.
> 
> The result of precompilation must remain a webapplication that is not
> specific to tomcat ( or worse - to a specific version of tomcat, as would 
> be the case here, I assume such a change won't be backported to 4.0 !).
> 
> We have a standard way to declare the servlets that result from jsp
> precompile, we have a standard way to declare the mappings - and I see
> no good reason to invent another mechanism to do this.
> 
> I don't like web.xml - and in 2.4 is even worse than it ever was
> ( with the XML Schema it enters a whole new level of complexity and
> uglyness). However it is good enough for this use case - and it is the
> standard.

Hey, I think I like the longer version better.

During deploy, we do:
- hack web.xml
- copy jasper-runtime.jar to /WEB-INF/lib

So we can keep jasper-compiler.jar in /server/lib ?

Remy


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Posted by Costin Manolache <cm...@yahoo.com>.
The main point is to _not_ hack anything, but just use the standard.

If you precompile your app - and include jasper-runtime.jar in WEB-INF/lib -
the result should work in _any_ container - the precompiled jsps are _just_
regular servlets that happen to use a lib and extend from a base class.
That used to work - I haven't tested it recently but it should still work.

The result of precompilation must remain a webapplication that is not
specific to tomcat ( or worse - to a specific version of tomcat, as would 
be the case here, I assume such a change won't be backported to 4.0 !).

We have a standard way to declare the servlets that result from jsp
precompile, we have a standard way to declare the mappings - and I see
no good reason to invent another mechanism to do this.

I don't like web.xml - and in 2.4 is even worse than it ever was
( with the XML Schema it enters a whole new level of complexity and
uglyness). However it is good enough for this use case - and it is the
standard.


Costin


Tim Funk wrote:

> Could an alternate hack be to modify JspServlet to allow an additional
> init parameter which would be the file which contains the mapping of the
> precompiled jsp's? The config file could just be the web.xml snippet
> generated by the precompilation process. This way web.xml isn't touched
> and if Jasper is used in another container, then all is OK?
> 
> 
> -Tim
> 
> 
> Bill Barker wrote:
>> I think that parsing two web.xml files is plenty.  There is no reason to
>> add
>> a third.  Also, since it is possible to use Jasper with other containers,
>> adding a non-standard feature like this makes that harder to do.
>>



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Posted by Tim Funk <fu...@joedog.org>.
Could an alternate hack be to modify JspServlet to allow an additional 
init parameter which would be the file which contains the mapping of the 
precompiled jsp's? The config file could just be the web.xml snippet 
generated by the precompilation process. This way web.xml isn't touched 
and if Jasper is used in another container, then all is OK?


-Tim


Bill Barker wrote:
> I think that parsing two web.xml files is plenty.  There is no reason to add
> a third.  Also, since it is possible to use Jasper with other containers,
> adding a non-standard feature like this makes that harder to do.
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Friday, March 21, 2003 3:05 AM
Subject: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs


> Hi,
>
> It is not very convinient or easy to insert the declarations for
> compiled JSPs into the webapp's web.xml file. It also has the
> disadvantage of adding a lot of mess in the web.xml, which the user may
> not like.
>
> For that reason, I propose that Tomcat parses a new (optional) XML file,
> with the same DTD as web.xml, which would contain declarations identical
> to web.xml, and which would be used for declaring the compiled JSPs. I
> propose naming that file compiledjsp.xml.

I think that parsing two web.xml files is plenty.  There is no reason to add
a third.  Also, since it is possible to use Jasper with other containers,
adding a non-standard feature like this makes that harder to do.

>
> An additional advantage is that it would allow Tomcat to precompile
> webapps as they are deployed (otherwise, nasty XML manipulation is
> needed to do that, and I think overwriting the originial web.xml during
> deployment is bad).

I agree with Costin here.  It should be easy enough to read web.xml as DOM
and save the changes.

>
> Maybe someone has a better solution for this problem. Any comments ?
>
> Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:

>> I agree that using ant replace is a hack - the right solution would be to
>> read the XML with DOM, insert the elements in the right place, and save
>> back ( DOM - so we don't loose comments ). Or even read it as a file, and
>> use regexp. No problem if we save the original web.xml in the process.
> 
> I see modifying the original web.xml as a problem.

Not sure what you mean by "original" web.xml. From the point of view of
tomcat, the "original" is the modified web.xml which includes declarations 
for all jsps. 

What you mean by "original" - i.e. the incomplete web.xml that relied on
tomcat-specific JspServlet to function - is a development artifact.


> If you don't want the explicit extra XML file, I would instead create a
> new extra deployment descriptor in the work directory during the deploy
> procedure.  That way, the feature is hidden, but you can't deploy the
> compiled webapp to another server without modifying the deployment
> descritptor yourself.


> An additional note: I think the order of elements is irrelevant with the
> new spec, so that simplifies things.

It is not in the old spec - and it is a good practice to maintain backward
compatibility, i.e. people will probably develop apps that run in 2.3 and
2.4 containers for a while.

Not to mention that the order is irrelevant only in the 2.4 web.xml which
also uses schema. 

I plan to stick with the 2.3 descriptor for a while, xml schema is one of
the worst technologies that I know.


Costin


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Remy Maucherat wrote:
> 
> 
>>Hi,
>>
>>It is not very convinient or easy to insert the declarations for
>>compiled JSPs into the webapp's web.xml file. It also has the
>>disadvantage of adding a lot of mess in the web.xml, which the user may
>>not like.
>>
>>For that reason, I propose that Tomcat parses a new (optional) XML file,
>>with the same DTD as web.xml, which would contain declarations identical
>>to web.xml, and which would be used for declaring the compiled JSPs. I
>>propose naming that file compiledjsp.xml.
>>
>>An additional advantage is that it would allow Tomcat to precompile
>>webapps as they are deployed (otherwise, nasty XML manipulation is
>>needed to do that, and I think overwriting the originial web.xml during
>>deployment is bad).
>>
>>Maybe someone has a better solution for this problem. Any comments ?
> 
> 
> I don't think it is a good idea. That won't be standard, and I don't think
> this is a good reason to "extend" it.
> 
> The precompilation should be part of the deployment or pre-deployment step - 
> the developer shouldn't see the modified web.xml. 
> 
> I agree that using ant replace is a hack - the right solution would be to 
> read the XML with DOM, insert the elements in the right place, and save back
> ( DOM - so we don't loose comments ). Or even read it as a file, and use 
> regexp. No problem if we save the original web.xml in the process.

I see modifying the original web.xml as a problem.
If you don't want the explicit extra XML file, I would instead create a 
new extra deployment descriptor in the work directory during the deploy 
procedure.  That way, the feature is hidden, but you can't deploy the 
compiled webapp to another server without modifying the deployment 
descritptor yourself.
An additional note: I think the order of elements is irrelevant with the 
new spec, so that simplifies things.

Remy


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:

> Hi,
> 
> It is not very convinient or easy to insert the declarations for
> compiled JSPs into the webapp's web.xml file. It also has the
> disadvantage of adding a lot of mess in the web.xml, which the user may
> not like.
> 
> For that reason, I propose that Tomcat parses a new (optional) XML file,
> with the same DTD as web.xml, which would contain declarations identical
> to web.xml, and which would be used for declaring the compiled JSPs. I
> propose naming that file compiledjsp.xml.
> 
> An additional advantage is that it would allow Tomcat to precompile
> webapps as they are deployed (otherwise, nasty XML manipulation is
> needed to do that, and I think overwriting the originial web.xml during
> deployment is bad).
> 
> Maybe someone has a better solution for this problem. Any comments ?

I don't think it is a good idea. That won't be standard, and I don't think
this is a good reason to "extend" it.

The precompilation should be part of the deployment or pre-deployment step - 
the developer shouldn't see the modified web.xml. 

I agree that using ant replace is a hack - the right solution would be to 
read the XML with DOM, insert the elements in the right place, and save back
( DOM - so we don't loose comments ). Or even read it as a file, and use 
regexp. No problem if we save the original web.xml in the process.

Costin




---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Posted by Steve Downey <st...@geowealth.com>.
What about using external entities?

ie:

<?xml version="1.0" encoding="ISO-8859-1"?>

<!DOCTYPE web-app
    PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
   "http://java.sun.com/dtd/web-app_2_3.dtd"
[
    <!ENTITY jspservlet system "jspservlet.xml>
]
>

then, between the servlet and servlet mapping sections

&jspservlet;





    -SMD
----- Original Message ----- 
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Friday, March 21, 2003 6:05 AM
Subject: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs


> Hi,
> 
> It is not very convinient or easy to insert the declarations for 
> compiled JSPs into the webapp's web.xml file. It also has the 
> disadvantage of adding a lot of mess in the web.xml, which the user may 
> not like.
> 
> For that reason, I propose that Tomcat parses a new (optional) XML file, 
> with the same DTD as web.xml, which would contain declarations identical 
> to web.xml, and which would be used for declaring the compiled JSPs. I 
> propose naming that file compiledjsp.xml.
> 
> An additional advantage is that it would allow Tomcat to precompile 
> webapps as they are deployed (otherwise, nasty XML manipulation is 
> needed to do that, and I think overwriting the originial web.xml during 
> deployment is bad).
> 
> Maybe someone has a better solution for this problem. Any comments ?
> 
> Remy
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Posted by Costin Manolache <cm...@yahoo.com>.
Craig R. McClanahan wrote:

> Many app servers have private deployment descriptors for "extra"
> information, similar to what Remy is proposing -- indeed, one could claim
> that Tomcat does this already with how we use $CATALINA_HOME/conf/web.xml
> to set default behavior (well, at least until Costin's recent patch :-).

Not sure what patch you're talking about, it should still work.
I only added code to deal with the case when the default web.xml is not 
found ( i.e. no defaults - all config in the app WEB-INF/web.xml ).


> * IMHO, the deployment descriptor should be viewed as an
>   output of a development process, rather than an input --
>   just as you package .class files (created from .java files)
>   for all your bean classes.  It is straightforward to create
>   an Ant build.xml file (or whatever) that assembles fragments
>   provided by the application developer, plus fragments generated
>   by JSPC, into the ultimate web.xml file packaged in the webapp.
>   The developer should never even have to look at the
>   merged version of this file (in the same way that developers
>   using an IDE-type tool that auto-generates web.xml files
>   avoids the need to look at it).

+1 - except that I'm not sure we use the same vocabulary :-)
The .WAR and WEB-INF/web.xml are the output of the development process,
shiped to the deployer. 

"Deployment descriptor" should be part of the deployment process - 
that includes TOMCAT/webapps/myapp.xml and any other deployment files
we may generate or use as part of the deployment. Web.xml is a "deployment
descriptor" too - and is one input in the deployment process. 

Many servlet containers use a WEB-INF/CONTAINER.xml deployment descriptor,
part of the .WAR. IMHO that's a very bad practice - it allows the .war to
control the URL or other properties, and this may affect the security in 
some cases.  

In tomcat5 - I think we should reduce the use of tomcat-specific deployment
and config files, we already have JMX that abstracts the config, and we
should try to be consistent ( i.e. use some generic JMX config file ).

Costin






---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Posted by "Craig R. McClanahan" <cr...@apache.org>.

On Fri, 21 Mar 2003, Remy Maucherat wrote:

> Date: Fri, 21 Mar 2003 12:05:26 +0100
> From: Remy Maucherat <re...@apache.org>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Developers List <to...@jakarta.apache.org>
> Subject: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
>
> Hi,
>
> It is not very convinient or easy to insert the declarations for
> compiled JSPs into the webapp's web.xml file. It also has the
> disadvantage of adding a lot of mess in the web.xml, which the user may
> not like.
>
> For that reason, I propose that Tomcat parses a new (optional) XML file,
> with the same DTD as web.xml, which would contain declarations identical
> to web.xml, and which would be used for declaring the compiled JSPs. I
> propose naming that file compiledjsp.xml.
>
> An additional advantage is that it would allow Tomcat to precompile
> webapps as they are deployed (otherwise, nasty XML manipulation is
> needed to do that, and I think overwriting the originial web.xml during
> deployment is bad).
>
> Maybe someone has a better solution for this problem. Any comments ?
>

Many app servers have private deployment descriptors for "extra"
information, similar to what Remy is proposing -- indeed, one could claim
that Tomcat does this already with how we use $CATALINA_HOME/conf/web.xml
to set default behavior (well, at least until Costin's recent patch :-).
However, I think it would be bad policy to implement Remy's suggestion for
the incorporation of JSPC output framgments, for several reasons:

* Applications that would depend on this behavior
  are no longer portable to other containers, whereas
  (as Costin points out) a webapp that includes
  jasper-runtime.jar will run on any compliant
  servlet container.

* Most "extra info" deployment descriptors contain
  customized elements that are not in the standard
  deployment descriptor's DTD or schema -- that is not
  the case for the elements we are talking about here.

* IMHO, the deployment descriptor should be viewed as an
  output of a development process, rather than an input --
  just as you package .class files (created from .java files)
  for all your bean classes.  It is straightforward to create
  an Ant build.xml file (or whatever) that assembles fragments
  provided by the application developer, plus fragments generated
  by JSPC, into the ultimate web.xml file packaged in the webapp.
  The developer should never even have to look at the
  merged version of this file (in the same way that developers
  using an IDE-type tool that auto-generates web.xml files
  avoids the need to look at it).

> Remy

Craig


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Posted by Remy Maucherat <re...@apache.org>.
John Trollinger wrote:
> Remy,
> 
> I think it would be nice to have a pre-compilier like JspC used to be.
> The precompile part of the jsp spec is just not that handy when trying
> to do builds and having ant tasks pass or fail based on the jsp and
> compiling jsp pages into servelts is not an option for everyone.

You can do that by using a script and compile your JSPs "indivudually". 
The community decided webapp mode is meant for webapp compilation.

Remy


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


RE: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Posted by John Trollinger <ja...@trollingers.com>.
Remy,

I think it would be nice to have a pre-compilier like JspC used to be.
The precompile part of the jsp spec is just not that handy when trying
to do builds and having ant tasks pass or fail based on the jsp and
compiling jsp pages into servelts is not an option for everyone.

John

> -----Original Message-----
> From: Chris Brown [mailto:brown2@reflexe.fr] 
> Sent: Friday, March 21, 2003 6:43 AM
> To: Tomcat Developers List
> Subject: Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
> 
> 
> 
> Hi Remy,
> 
> It might be worth COPYING the original web.xml at deployment 
> time, to make a runtime-web.xml, to do what you propose, 
> leaving the original web.xml untouched.  This way, you can 
> add the declarations for compiled JSPs, and -- as a bonus -- 
> allow clean modification of things like init-params for 
> servlets, filters, and the context itself.  Such 
> modifications could be done in the admin webapp.
> 
> If the application is redeployed, or at least if web.xml is 
> modified, then a new copy of web.xml can be made, merging in 
> the modifications made to the older (now obsolete) copy, and 
> of course, the declarations for the compiled JSPs.
> 
> I'm all for deploying applications as simply as possible, 
> letting end-users customise things from nice graphical 
> interfaces without touching configuration files directly.  
> Many less experienced individuals screw up web.xml when 
> attempting to modify stuff, and it implies unpacking WARs, 
> and looking through lots of "confusing" application structure 
> (where's web.xml? what's xml anyway?  why doesn't tomcat 
> start now that I've typed an apostrophie in the servlet's 
> init-param...?)
> 
> - Chris
> 
> ----- Original Message -----
> From: "Remy Maucherat" <re...@apache.org>
> To: "Tomcat Developers List" <to...@jakarta.apache.org>
> Sent: Friday, March 21, 2003 12:05 PM
> Subject: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
> 
> 
> > Hi,
> >
> > It is not very convinient or easy to insert the declarations for 
> > compiled JSPs into the webapp's web.xml file. It also has the 
> > disadvantage of adding a lot of mess in the web.xml, which the user 
> > may not like.
> >
> > For that reason, I propose that Tomcat parses a new (optional) XML 
> > file, with the same DTD as web.xml, which would contain 
> declarations 
> > identical to web.xml, and which would be used for declaring the 
> > compiled JSPs. I propose naming that file compiledjsp.xml.
> >
> > An additional advantage is that it would allow Tomcat to precompile 
> > webapps as they are deployed (otherwise, nasty XML manipulation is 
> > needed to do that, and I think overwriting the originial web.xml 
> > during deployment is bad).
> >
> > Maybe someone has a better solution for this problem. Any comments ?
> >
> > Remy
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> >
> >
> >
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs

Posted by Chris Brown <br...@reflexe.fr>.
Hi Remy,

It might be worth COPYING the original web.xml at deployment time, to make a
runtime-web.xml, to do what you propose, leaving the original web.xml
untouched.  This way, you can add the declarations for compiled JSPs, and --
as a bonus -- allow clean modification of things like init-params for
servlets, filters, and the context itself.  Such modifications could be done
in the admin webapp.

If the application is redeployed, or at least if web.xml is modified, then a
new copy of web.xml can be made, merging in the modifications made to the
older (now obsolete) copy, and of course, the declarations for the compiled
JSPs.

I'm all for deploying applications as simply as possible, letting end-users
customise things from nice graphical interfaces without touching
configuration files directly.  Many less experienced individuals screw up
web.xml when attempting to modify stuff, and it implies unpacking WARs, and
looking through lots of "confusing" application structure (where's web.xml?
what's xml anyway?  why doesn't tomcat start now that I've typed an
apostrophie in the servlet's init-param...?)

- Chris

----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Friday, March 21, 2003 12:05 PM
Subject: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs


> Hi,
>
> It is not very convinient or easy to insert the declarations for
> compiled JSPs into the webapp's web.xml file. It also has the
> disadvantage of adding a lot of mess in the web.xml, which the user may
> not like.
>
> For that reason, I propose that Tomcat parses a new (optional) XML file,
> with the same DTD as web.xml, which would contain declarations identical
> to web.xml, and which would be used for declaring the compiled JSPs. I
> propose naming that file compiledjsp.xml.
>
> An additional advantage is that it would allow Tomcat to precompile
> webapps as they are deployed (otherwise, nasty XML manipulation is
> needed to do that, and I think overwriting the originial web.xml during
> deployment is bad).
>
> Maybe someone has a better solution for this problem. Any comments ?
>
> Remy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org