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 2002/11/07 10:23:12 UTC
[VOTE] Proposed jspc refactoring
Hi,
jspc is IMO overly complex, with many features nobody knows how to use,
and nobody cares to test (hence sometimes some of them are randomly
broken during Jasper refactorings).
I propose that:
- In Tomcat 5, all jspc options are removed, in favor of allowing only
the webapp mode (with its relevant options). This webapp mode would
generate code and classes which should be deployed in the work
directory, exactly the same as if they were dynamically compiled by
Jasper (which has the big advantage of using only one big operation mode
for everything). Single file mode is IMO useless (dynamic compilation
works fine).
- In Tomcat 4.1, the options will stay in for compatibility, but the
usage help will be modified to be the same as Tomcat 5.
It has to be noted that:
- The JSP runtime is now very efficient. The old webapp mode (with its
static web.xml) is a hack (and a 100% proprietary one at that).
- Precompilation should only occur at webapp deployment time in the
general case (the generated code is closely tied to the Jasper runtime
release).
- Additional features could be added to the manager servlet to, for
example, cause precompilation of the deployed webapp in a separate process.
- I am -1 to returning to the old "webapp" option behavior (ie, the
generated files should by default be deployed in the work directory, not
/WEB-INF/classes).
<ballot>
+1 [ ] Remove the options
-1 [ ] Do not remove the options
</ballot>
Note: Users may vote, but only committers have binding votes.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Costin Manolache <cm...@yahoo.com>.
As someone who is actually using jspc ...
> - In Tomcat 5, all jspc options are removed, in favor of allowing only
> the webapp mode (with its relevant options). This webapp mode would
> generate code and classes which should be deployed in the work
> directory, exactly the same as if they were dynamically compiled by
> Jasper (which has the big advantage of using only one big operation mode
> for everything). Single file mode is IMO useless (dynamic compilation
> works fine).
-1
I actually need real java classes, with a package name I can customize
and deployed in an arbitrary directory (outside tomcat tree).
> It has to be noted that:
> - The JSP runtime is now very efficient. The old webapp mode (with its
> static web.xml) is a hack (and a 100% proprietary one at that).
Not sure which 'webapp mode', but generating the web.xml fragment is
an essential feature and 100% standard - it translates JSPs to servlets
and generates the web.xml declarations. After the operation you'll have
very servlets in a standard web.xml.
As for jasper runtime - it can be included in the webapp ( just like any
library ). AFAIK the runtime doesn't depend on tomcat.
> - Precompilation should only occur at webapp deployment time in the
> general case (the generated code is closely tied to the Jasper runtime
> release).
I need precompilation at build time - the distributed .war will have only
servlets.
> - Additional features could be added to the manager servlet to, for
> example, cause precompilation of the deployed webapp in a separate
> process. - I am -1 to returning to the old "webapp" option behavior (ie,
> the generated files should by default be deployed in the work directory,
> not /WEB-INF/classes).
Again, I must -1 this too.
>
> <ballot>
> +1 [ ] Remove the options
> -1 [X] Do not remove the options
> </ballot>
I agree jspc needs some refactoring - and only the 'webapp' mode should
be preserved, but I think my use case is valid and should be preserved.
At the moment I only use jasper inside ant - so removing the CLI completely,
removing the javac compilation and so on would be fine ( for me ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Steve Downey <st...@netfolio.com>.
I dislike this option immensely. It's entirely contrary to what JSPC is for.
It's a tool for generating servlets from JSP that do not require the entire
JSP machinery. It produces a web.xml file that maps each jsp page to the
generated servlet. The generated servlets are portable between servlet
engines. They can be compiled by a normal java compiler. In short, they are
very much unlike the output in the work directory.
What you are proposing is the same as the precompile option on the URL.
Here's a script that will do it for all compliant JSP engines
find . -name '*jsp' -printf "http://`echo $HOSTNAME`/%P?jsp_precompile\n" \
| xargs -n 1 lynx -head -source
On Thursday 07 November 2002 04:23 am, Remy Maucherat wrote:
> Hi,
>
> jspc is IMO overly complex, with many features nobody knows how to use,
> and nobody cares to test (hence sometimes some of them are randomly
> broken during Jasper refactorings).
>
> I propose that:
> - In Tomcat 5, all jspc options are removed, in favor of allowing only
> the webapp mode (with its relevant options). This webapp mode would
> generate code and classes which should be deployed in the work
> directory, exactly the same as if they were dynamically compiled by
> Jasper (which has the big advantage of using only one big operation mode
> for everything). Single file mode is IMO useless (dynamic compilation
> works fine).
> - In Tomcat 4.1, the options will stay in for compatibility, but the
> usage help will be modified to be the same as Tomcat 5.
>
> It has to be noted that:
> - The JSP runtime is now very efficient. The old webapp mode (with its
> static web.xml) is a hack (and a 100% proprietary one at that).
> - Precompilation should only occur at webapp deployment time in the
> general case (the generated code is closely tied to the Jasper runtime
> release).
> - Additional features could be added to the manager servlet to, for
> example, cause precompilation of the deployed webapp in a separate process.
> - I am -1 to returning to the old "webapp" option behavior (ie, the
> generated files should by default be deployed in the work directory, not
> /WEB-INF/classes).
>
> <ballot>
> +1 [ ] Remove the options
> -1 [ ] Do not remove the options
> </ballot>
>
> Note: Users may vote, but only committers have binding votes.
>
> Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 7 Nov 2002, Henri Gomez wrote:
> Date: Thu, 07 Nov 2002 12:43:45 +0100
> From: Henri Gomez <hg...@apache.org>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Developers List <to...@jakarta.apache.org>
> Subject: Re: [VOTE] Proposed jspc refactoring
>
> Remy Maucherat wrote:
> > Hi,
> >
> > jspc is IMO overly complex, with many features nobody knows how to use,
> > and nobody cares to test (hence sometimes some of them are randomly
> > broken during Jasper refactorings).
> >
> > I propose that:
> > - In Tomcat 5, all jspc options are removed, in favor of allowing only
> > the webapp mode (with its relevant options). This webapp mode would
> > generate code and classes which should be deployed in the work
> > directory, exactly the same as if they were dynamically compiled by
> > Jasper (which has the big advantage of using only one big operation mode
> > for everything). Single file mode is IMO useless (dynamic compilation
> > works fine).
> > - In Tomcat 4.1, the options will stay in for compatibility, but the
> > usage help will be modified to be the same as Tomcat 5.
>
> I would say that we're extensively JSPC in ant tasks to generate servlet
> (.java), compile via javac and then put all the classes in a .jar which
> will be included in the final .war (in lib) which include the jsp
> mapping generated by JSPC.
>
> With this methodology, we're sure that what we deploy on our production
> will works (no jsp compilation error on users browser), no time spent in
> compilation at runtime, easy deployement since the WAR alleady included
> everything.
>
An additional advantage for some folks is that you can run the resulting
webapp on a JRE instead of a JDK.
> So what did you means by classes which should be deployed in work
> directory ?
>
> > - I am -1 to returning to the old "webapp" option behavior (ie, the
> > generated files should by default be deployed in the work directory, not
> > /WEB-INF/classes).
>
> It's not my opinion, JSP are nothing more than servlet after all and
> why prevent users to have then in WEB-INF/classes or WEB-INF/lib ?
>
> Also consider massive web hosting situation with many tomcats running
> the same WebApps (with differents settings and JVM owner).
>
> Having everything in a .war (ie data + precompiled jsp in .class or
> .jar) make life easier for web admins since upgrading a version is just
> to replace a .war by a new one.
>
> With your proposed solution, they will have update the war, clean the
> work directory (by hand ?) and move the new classes in the work
> directory. Also did Manager/Admin will be updated for such task ?
>
> > <ballot>
> > +1 [ ] Remove the options
> > -1 [ ] Do not remove the options
> > </ballot>
> >
> > Note: Users may vote, but only committers have binding votes.
>
> So I'm -1 on removing the options
>
>
I'm -1 on removing the options unless they are replaced with equivalent
functionality that *does* work correctly and *is* maintained. (Basically,
this is J-F's "do not remove and fix" option.
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Henri Gomez <hg...@apache.org>.
Remy Maucherat wrote:
> Hi,
>
> jspc is IMO overly complex, with many features nobody knows how to use,
> and nobody cares to test (hence sometimes some of them are randomly
> broken during Jasper refactorings).
>
> I propose that:
> - In Tomcat 5, all jspc options are removed, in favor of allowing only
> the webapp mode (with its relevant options). This webapp mode would
> generate code and classes which should be deployed in the work
> directory, exactly the same as if they were dynamically compiled by
> Jasper (which has the big advantage of using only one big operation mode
> for everything). Single file mode is IMO useless (dynamic compilation
> works fine).
> - In Tomcat 4.1, the options will stay in for compatibility, but the
> usage help will be modified to be the same as Tomcat 5.
I would say that we're extensively JSPC in ant tasks to generate servlet
(.java), compile via javac and then put all the classes in a .jar which
will be included in the final .war (in lib) which include the jsp
mapping generated by JSPC.
With this methodology, we're sure that what we deploy on our production
will works (no jsp compilation error on users browser), no time spent in
compilation at runtime, easy deployement since the WAR alleady included
everything.
So what did you means by classes which should be deployed in work
directory ?
> - I am -1 to returning to the old "webapp" option behavior (ie, the
> generated files should by default be deployed in the work directory, not
> /WEB-INF/classes).
It's not my opinion, JSP are nothing more than servlet after all and
why prevent users to have then in WEB-INF/classes or WEB-INF/lib ?
Also consider massive web hosting situation with many tomcats running
the same WebApps (with differents settings and JVM owner).
Having everything in a .war (ie data + precompiled jsp in .class or
.jar) make life easier for web admins since upgrading a version is just
to replace a .war by a new one.
With your proposed solution, they will have update the war, clean the
work directory (by hand ?) and move the new classes in the work
directory. Also did Manager/Admin will be updated for such task ?
> <ballot>
> +1 [ ] Remove the options
> -1 [ ] Do not remove the options
> </ballot>
>
> Note: Users may vote, but only committers have binding votes.
So I'm -1 on removing the options
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Steve Downey <st...@netfolio.com>.
On Friday 08 November 2002 03:28 pm, Hans Bergsten wrote:
> Glenn Nielsen wrote:
> > Remy Maucherat wrote:
> > [...]
> > I agree that JSPC needs to be simplified and that the webapp mode should
> > be retained. But the webapp mode should allow for a war file to be
> > generated
> > which is self contained including the precompiled JSP classses. And for
> > the
> > generated war to be able to run from the war file with no need to unpack
> > it.
>
> Why add this to JSPC? Isn't it already very easy to use external tools
> to create the WAR file (the jar command, ant's war task, etc)? I have
> no objections to cleaning up the JSPC code, but I would like it to
> stay focused on it's its main task: convert JSP source to servlet
> source. I have sometimes wished for automatic compilation of the servlet
> source to class files, but in the name of simplicity and separation of
> concerns, I think it's better handled by other tools.
>
In one way, it would be better to have the JSPC do the java compilation,
because it can tell exactly what the environment is supposed to be. The
libraries that are available, etc. It's reproduceable in ant, but it's not a
terribly expensive option to maintain in jasper2, since it follows the same
path as the runtime compiler.
> > Also I agree that this feature is a proprietary feature of Tomcat and we
> > should no longer try to generate a war that can be deployed in any
> > container.
>
> Why not? This works today (at least in TC 4.0.4) and I find it very
> handy to be able to create a JAR file for all my JSPs that I know I
> can deploy to any container along with the jasper-runtime.jar. If there
> are issues with this that I don't know about, please tell me. Otherwise
> I see no reason to remove this capability.
>
> If you can use JSPC to create the servlet source and web.xml fragments,
> it's easy to use other tools to compile the source and create a WAR with
> all other parts of the app (servlets, taglibs, web.xml, static stuff,
> etc.) and deploy it to Tomcat or any other container. As far as I can
> see, there's no need for a proprietary solution to get this to work.
>
> > [...]
>
> Hans
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Glenn Nielsen wrote:
> Remy Maucherat wrote:
> [...]
> I agree that JSPC needs to be simplified and that the webapp mode should
> be retained. But the webapp mode should allow for a war file to be
> generated
> which is self contained including the precompiled JSP classses. And for
> the
> generated war to be able to run from the war file with no need to unpack
> it.
Why add this to JSPC? Isn't it already very easy to use external tools
to create the WAR file (the jar command, ant's war task, etc)? I have
no objections to cleaning up the JSPC code, but I would like it to
stay focused on it's its main task: convert JSP source to servlet
source. I have sometimes wished for automatic compilation of the servlet
source to class files, but in the name of simplicity and separation of
concerns, I think it's better handled by other tools.
> Also I agree that this feature is a proprietary feature of Tomcat and we
> should no longer try to generate a war that can be deployed in any
> container.
Why not? This works today (at least in TC 4.0.4) and I find it very
handy to be able to create a JAR file for all my JSPs that I know I
can deploy to any container along with the jasper-runtime.jar. If there
are issues with this that I don't know about, please tell me. Otherwise
I see no reason to remove this capability.
If you can use JSPC to create the servlet source and web.xml fragments,
it's easy to use other tools to compile the source and create a WAR with
all other parts of the app (servlets, taglibs, web.xml, static stuff,
etc.) and deploy it to Tomcat or any other container. As far as I can
see, there's no need for a proprietary solution to get this to work.
> [...]
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
JavaServer Pages http://TheJSPBook.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Steve Downey <st...@netfolio.com>.
It's better to look at it as a compiler. It's output happens to be java, but
it acts a whole lot more like a compiler than a precompiler. Precompilers are
usually more like macro preprocessors.
On Friday 08 November 2002 07:05 am, John Trollinger wrote:
> I have to disagree with this, jspc is a pre compiler, not a webapp
> packager.
>
>
> John
>
> > I agree that JSPC needs to be simplified and that the webapp
> > mode should be retained. But the webapp mode should allow
> > for a war file to be generated which is self contained
> > including the precompiled JSP classses. And for the
> > generated war to be able to run from the war file with no
> > need to unpack it.
> >
> > Also I agree that this feature is a proprietary feature of
> > Tomcat and we should no longer try to generate a war that can
> > be deployed in any container.
> >
> > There may be a way to do this:
> >
> > Put the generated JSP class files in a /WEB-INF/jspwork/
> > directory. This work directory would only be used by jasper
> > for loading jsp pages, the normal work directory would still
> > be used for all other things.
> >
> > Add the "jspwork" attribute to the DefaultContext and Context
> > config elements. This attribute would specify the directory
> > path within the war file to use for loading the JSP page
> > classes from by Jasper.
> >
> > This would allow JSPC to create a war file which was self
> > contained including the precompiled JSP page classes and be
> > runnable directly from the war or unpacked into a directory.
> >
> > +1 if we modify Tomcat & Jasper to support precompiled JSP
> > pages running
> > +from a
> > self contained war file.
> >
> > Regards,
> >
> > Glenn
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:tomcat-dev-> unsubscribe@jakarta.apache.org>
> > For
> > additional commands,
> > e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Proposed jspc refactoring
Posted by John Trollinger <ja...@trollingers.com>.
I have to disagree with this, jspc is a pre compiler, not a webapp
packager.
John
> I agree that JSPC needs to be simplified and that the webapp
> mode should be retained. But the webapp mode should allow
> for a war file to be generated which is self contained
> including the precompiled JSP classses. And for the
> generated war to be able to run from the war file with no
> need to unpack it.
>
> Also I agree that this feature is a proprietary feature of
> Tomcat and we should no longer try to generate a war that can
> be deployed in any container.
>
> There may be a way to do this:
>
> Put the generated JSP class files in a /WEB-INF/jspwork/
> directory. This work directory would only be used by jasper
> for loading jsp pages, the normal work directory would still
> be used for all other things.
>
> Add the "jspwork" attribute to the DefaultContext and Context
> config elements. This attribute would specify the directory
> path within the war file to use for loading the JSP page
> classes from by Jasper.
>
> This would allow JSPC to create a war file which was self
> contained including the precompiled JSP page classes and be
> runnable directly from the war or unpacked into a directory.
>
> +1 if we modify Tomcat & Jasper to support precompiled JSP
> pages running
> +from a
> self contained war file.
>
> Regards,
>
> Glenn
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:tomcat-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Glenn Nielsen <gl...@mail.more.net>.
Remy Maucherat wrote:
> Hi,
>
> jspc is IMO overly complex, with many features nobody knows how to use,
> and nobody cares to test (hence sometimes some of them are randomly
> broken during Jasper refactorings).
>
> I propose that:
> - In Tomcat 5, all jspc options are removed, in favor of allowing only
> the webapp mode (with its relevant options). This webapp mode would
> generate code and classes which should be deployed in the work
> directory, exactly the same as if they were dynamically compiled by
> Jasper (which has the big advantage of using only one big operation mode
> for everything). Single file mode is IMO useless (dynamic compilation
> works fine).
> - In Tomcat 4.1, the options will stay in for compatibility, but the
> usage help will be modified to be the same as Tomcat 5.
>
> It has to be noted that:
> - The JSP runtime is now very efficient. The old webapp mode (with its
> static web.xml) is a hack (and a 100% proprietary one at that).
> - Precompilation should only occur at webapp deployment time in the
> general case (the generated code is closely tied to the Jasper runtime
> release).
> - Additional features could be added to the manager servlet to, for
> example, cause precompilation of the deployed webapp in a separate process.
> - I am -1 to returning to the old "webapp" option behavior (ie, the
> generated files should by default be deployed in the work directory, not
> /WEB-INF/classes).
>
> <ballot>
> +1 [ ] Remove the options
> -1 [ ] Do not remove the options
> </ballot>
>
> Note: Users may vote, but only committers have binding votes.
>
> Remy
>
I agree that JSPC needs to be simplified and that the webapp mode should
be retained. But the webapp mode should allow for a war file to be generated
which is self contained including the precompiled JSP classses. And for the
generated war to be able to run from the war file with no need to unpack it.
Also I agree that this feature is a proprietary feature of Tomcat and we
should no longer try to generate a war that can be deployed in any container.
There may be a way to do this:
Put the generated JSP class files in a /WEB-INF/jspwork/ directory. This work
directory would only be used by jasper for loading jsp pages, the normal work
directory would still be used for all other things.
Add the "jspwork" attribute to the DefaultContext and Context config elements.
This attribute would specify the directory path within the war file to use for
loading the JSP page classes from by Jasper.
This would allow JSPC to create a war file which was self contained including
the precompiled JSP page classes and be runnable directly from the war or
unpacked into a directory.
+1 if we modify Tomcat & Jasper to support precompiled JSP pages running from a
self contained war file.
Regards,
Glenn
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [4.1.15] Jasper flushing, tagging ?
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Remy Maucherat wrote:
> jean-frederic clere wrote:
>
>> Remy Maucherat wrote:
>>
>> > I was wondering if people have been testing Jasper 2 from Tomcat 5
>> > with flushing disabled. If testing is ok (Watchdog is, but from my
>> > experience it's not enough ;-) ), I would be willing to port it to the
>> > 4.1.x branch. I have yet to see a problem using the latest Tomcat 5
>> > code (I think it's a good sign).
>> >
>> > Comments ?
>>
>>
>> Tagging or annoncing a tag on Friday afternoon (at least GMT) is not
>> very nice for the ones that are able to do Tomcat things during their
>> day work.
>>
>> I have some problems with HEAD requests (Content-type/Content-length)
>> that I would be happy to see fixed. (I have no time for the moment :-((()
>
>
>
> And what is that problem ?
Something like the PR 14293 (and 13846).
>
> BTW, that milestone does not need to become an official release, like
> 4.1.13 and 4.1.14 (my mail wasn't a last_minute_fix_before_final
> warning). Since you also won't be around on monday, it's likely that
> I'll tag before that.
>
> Rémy
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [4.1.15] Jasper flushing, tagging ?
Posted by Remy Maucherat <re...@apache.org>.
jean-frederic clere wrote:
> Remy Maucherat wrote:
>
> > I was wondering if people have been testing Jasper 2 from Tomcat 5
> > with flushing disabled. If testing is ok (Watchdog is, but from my
> > experience it's not enough ;-) ), I would be willing to port it to the
> > 4.1.x branch. I have yet to see a problem using the latest Tomcat 5
> > code (I think it's a good sign).
> >
> > Comments ?
>
>
> Tagging or annoncing a tag on Friday afternoon (at least GMT) is not
> very nice for the ones that are able to do Tomcat things during their
> day work.
>
> I have some problems with HEAD requests (Content-type/Content-length)
> that I would be happy to see fixed. (I have no time for the moment :-((()
And what is that problem ?
BTW, that milestone does not need to become an official release, like
4.1.13 and 4.1.14 (my mail wasn't a last_minute_fix_before_final
warning). Since you also won't be around on monday, it's likely that
I'll tag before that.
Rémy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [4.1.15] Jasper flushing, tagging ?
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Remy Maucherat wrote:
> I was wondering if people have been testing Jasper 2 from Tomcat 5 with
> flushing disabled. If testing is ok (Watchdog is, but from my experience
> it's not enough ;-) ), I would be willing to port it to the 4.1.x
> branch. I have yet to see a problem using the latest Tomcat 5 code (I
> think it's a good sign).
>
> Comments ?
Tagging or annoncing a tag on Friday afternoon (at least GMT) is not very nice
for the ones that are able to do Tomcat things during their day work.
I have some problems with HEAD requests (Content-type/Content-length) that I
would be happy to see fixed. (I have no time for the moment :-((()
>
> After that, I plan to tag 4.1.15.
>
> Remy
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [4.1.15] Jasper flushing, tagging ?
Posted by peter lin <pe...@labs.gte.com>.
thanks again for the information. I will go with setting the buffer
then.
peter
Remy Maucherat wrote:
>
> peter lin wrote:
>
> > thanks remy for the information that helps. What if I decide to buffer
> > the response myself in a response wrapper? Does catalina try to call
> > clearBuffer, reset, resetBuffer, flush or flushBuffer in the event a
> > request is passed to my errorpage? Also, does the status code change
> > and the exception set in the request object with
> > request.setAttribute("Throwable") if html has already been sent to the
> > browser?
>
> If you buffer everything, then Jasper will do a forward instead of an
> include.
>
> >
> > In cases where the exception occurs before any content is sent to the
> > browser, it all works fine. I need to ensure exceptions display my
> > custom errorpage, but I'd rather not set the page buffer to an
> > arbitrarily large 64K or 100K.
> >
>
> I think you should, since in the end it should be the same (something
> will need a buffer to hold your bytes, right ?).
> If I were you, I'd try to set a big servlet buffer size rather than a
> big JSP page buffer size (that doesn't run into the issues a servlet
> like Jasper has when trying to recycle things while being thread safe,
> so it would be more efficient; plus it will compute the content-length now).
>
> Rémy
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [4.1.15] Jasper flushing, tagging ?
Posted by Remy Maucherat <re...@apache.org>.
peter lin wrote:
> thanks remy for the information that helps. What if I decide to buffer
> the response myself in a response wrapper? Does catalina try to call
> clearBuffer, reset, resetBuffer, flush or flushBuffer in the event a
> request is passed to my errorpage? Also, does the status code change
> and the exception set in the request object with
> request.setAttribute("Throwable") if html has already been sent to the
> browser?
If you buffer everything, then Jasper will do a forward instead of an
include.
>
> In cases where the exception occurs before any content is sent to the
> browser, it all works fine. I need to ensure exceptions display my
> custom errorpage, but I'd rather not set the page buffer to an
> arbitrarily large 64K or 100K.
>
I think you should, since in the end it should be the same (something
will need a buffer to hold your bytes, right ?).
If I were you, I'd try to set a big servlet buffer size rather than a
big JSP page buffer size (that doesn't run into the issues a servlet
like Jasper has when trying to recycle things while being thread safe,
so it would be more efficient; plus it will compute the content-length now).
Rémy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [4.1.15] Jasper flushing, tagging ?
Posted by peter lin <pe...@labs.gte.com>.
thanks remy for the information that helps. What if I decide to buffer
the response myself in a response wrapper? Does catalina try to call
clearBuffer, reset, resetBuffer, flush or flushBuffer in the event a
request is passed to my errorpage? Also, does the status code change
and the exception set in the request object with
request.setAttribute("Throwable") if html has already been sent to the
browser?
In cases where the exception occurs before any content is sent to the
browser, it all works fine. I need to ensure exceptions display my
custom errorpage, but I'd rather not set the page buffer to an
arbitrarily large 64K or 100K.
peter lin
Remy Maucherat wrote:
>
> peter lin wrote:
>
> > On a related note to flushing. I've discovered a bug, but don't want to
> > file one until I know for sure it's not a duplicate of the other flush
> > bugs already in bugzilla.
> >
> > The bug is the following:
> >
> > if a page throws an exception and an errorPage directive is set, the
> > resulting error page will print out anything left over from the parent
> > page and the errorpage. That means .... and everything preceding
> > the exception is written to the browser. One way around this I found was
> > to set the buffer to a large size, like buffer="64K".
> >
> > To reproduce the bug:
> >
> > create a page with some html (has to be more than the default buffer
> > size), towards the bottom throw an exception.
> > create a custom error page.
> > using a browser load the page and the resulting out put should contain
> > html from both pages.
> >
> > This bug can be reproduced with autFlush set to true and false. If
> > people are busy, I'm willing to spend a couple hours going through the
> > code to find a fix and submit a patch. If it's not a bug, any pointers
> > would be appreciated.
>
> If the buffer size is exceeded, then some data (the top of your page)
> will get sent to the client.
> After that, when the exception occurs, there's no way to get the data
> back (obviously).
>
> The servlet container error handling will not do anything in that case
> (error pages and status reports will not be processed), while Jasper
> also attempts to include the error page if forwarding to it failed. IMO,
> that's not that great an idea because it creates messy output, and the
> inclusion shouldn't happen (the error should be logged and ignored).
> It's been like that for a while, AFAIK.
>
> Rémy
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [4.1.15] Jasper flushing, tagging ?
Posted by Remy Maucherat <re...@apache.org>.
peter lin wrote:
> On a related note to flushing. I've discovered a bug, but don't want to
> file one until I know for sure it's not a duplicate of the other flush
> bugs already in bugzilla.
>
> The bug is the following:
>
> if a page throws an exception and an errorPage directive is set, the
> resulting error page will print out anything left over from the parent
> page and the errorpage. That means .... and everything preceding
> the exception is written to the browser. One way around this I found was
> to set the buffer to a large size, like buffer="64K".
>
> To reproduce the bug:
>
> create a page with some html (has to be more than the default buffer
> size), towards the bottom throw an exception.
> create a custom error page.
> using a browser load the page and the resulting out put should contain
> html from both pages.
>
> This bug can be reproduced with autFlush set to true and false. If
> people are busy, I'm willing to spend a couple hours going through the
> code to find a fix and submit a patch. If it's not a bug, any pointers
> would be appreciated.
If the buffer size is exceeded, then some data (the top of your page)
will get sent to the client.
After that, when the exception occurs, there's no way to get the data
back (obviously).
The servlet container error handling will not do anything in that case
(error pages and status reports will not be processed), while Jasper
also attempts to include the error page if forwarding to it failed. IMO,
that's not that great an idea because it creates messy output, and the
inclusion shouldn't happen (the error should be logged and ignored).
It's been like that for a while, AFAIK.
Rémy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [4.1.15] Jasper flushing, tagging ?
Posted by peter lin <pe...@labs.gte.com>.
On a related note to flushing. I've discovered a bug, but don't want to
file one until I know for sure it's not a duplicate of the other flush
bugs already in bugzilla.
The bug is the following:
if a page throws an exception and an errorPage directive is set, the
resulting error page will print out anything left over from the parent
page and the errorpage. That means <html> .... and everything preceding
the exception is written to the browser. One way around this I found was
to set the buffer to a large size, like buffer="64K".
To reproduce the bug:
create a page with some html (has to be more than the default buffer
size), towards the bottom throw an exception.
create a custom error page.
using a browser load the page and the resulting out put should contain
html from both pages.
This bug can be reproduced with autFlush set to true and false. If
people are busy, I'm willing to spend a couple hours going through the
code to find a fix and submit a patch. If it's not a bug, any pointers
would be appreciated.
peter lin
Remy Maucherat wrote:
>
> I was wondering if people have been testing Jasper 2 from Tomcat 5 with
> flushing disabled. If testing is ok (Watchdog is, but from my experience
> it's not enough ;-) ), I would be willing to port it to the 4.1.x
> branch. I have yet to see a problem using the latest Tomcat 5 code (I
> think it's a good sign).
>
> Comments ?
>
> After that, I plan to tag 4.1.15.
>
> Remy
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[4.1.15] Jasper flushing, tagging ?
Posted by Remy Maucherat <re...@apache.org>.
I was wondering if people have been testing Jasper 2 from Tomcat 5 with
flushing disabled. If testing is ok (Watchdog is, but from my experience
it's not enough ;-) ), I would be willing to port it to the 4.1.x
branch. I have yet to see a problem using the latest Tomcat 5 code (I
think it's a good sign).
Comments ?
After that, I plan to tag 4.1.15.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Jeanfrancois Arcand <jf...@apache.org>.
I am +1 of refactoring the code and do something less "overly complex".
I just have a look at the code and start speaking french..... ;-)
I can help if needed.
-- Jeanfrancois
Remy Maucherat wrote:
> Hi,
>
> jspc is IMO overly complex, with many features nobody knows how to
> use, and nobody cares to test (hence sometimes some of them are
> randomly broken during Jasper refactorings).
>
> I propose that:
> - In Tomcat 5, all jspc options are removed, in favor of allowing only
> the webapp mode (with its relevant options). This webapp mode would
> generate code and classes which should be deployed in the work
> directory, exactly the same as if they were dynamically compiled by
> Jasper (which has the big advantage of using only one big operation
> mode for everything). Single file mode is IMO useless (dynamic
> compilation works fine).
> - In Tomcat 4.1, the options will stay in for compatibility, but the
> usage help will be modified to be the same as Tomcat 5.
>
> It has to be noted that:
> - The JSP runtime is now very efficient. The old webapp mode (with its
> static web.xml) is a hack (and a 100% proprietary one at that).
> - Precompilation should only occur at webapp deployment time in the
> general case (the generated code is closely tied to the Jasper runtime
> release).
> - Additional features could be added to the manager servlet to, for
> example, cause precompilation of the deployed webapp in a separate
> process.
> - I am -1 to returning to the old "webapp" option behavior (ie, the
> generated files should by default be deployed in the work directory,
> not /WEB-INF/classes).
>
> <ballot>
> +1 [ ] Remove the options
> -1 [ ] Do not remove the options
> </ballot>
>
> Note: Users may vote, but only committers have binding votes.
>
> Remy
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Remy Maucherat wrote:
> jean-frederic clere wrote:
>
>>
>>
>> The problem is that keeping the options is where the work has to be
>> done...
>> Removing cost (nearly) nothing but brinks nothing.
>> Probably the vote could be:
>> [ ] - Remove the options
>> [ ] - Keep the options _and_ fix them.
>
>
>
> I don't really agree, as I think it's just too complex for users right
> now (too many useless options).
Ok, my vote is:
<ballot>
+1 [X] Remove the options
-1 [ ] Do not remove the options
</ballot>
I have look again in the code ;-)
>
> Remy
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Remy Maucherat <re...@apache.org>.
jean-frederic clere wrote:
>
>
> The problem is that keeping the options is where the work has to be
> done...
> Removing cost (nearly) nothing but brinks nothing.
> Probably the vote could be:
> [ ] - Remove the options
> [ ] - Keep the options _and_ fix them.
I don't really agree, as I think it's just too complex for users right
now (too many useless options).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Remy Maucherat wrote:
> Hi,
>
> jspc is IMO overly complex, with many features nobody knows how to use,
> and nobody cares to test (hence sometimes some of them are randomly
> broken during Jasper refactorings).
>
> I propose that:
> - In Tomcat 5, all jspc options are removed, in favor of allowing only
> the webapp mode (with its relevant options). This webapp mode would
> generate code and classes which should be deployed in the work
> directory, exactly the same as if they were dynamically compiled by
> Jasper (which has the big advantage of using only one big operation mode
> for everything). Single file mode is IMO useless (dynamic compilation
> works fine).
> - In Tomcat 4.1, the options will stay in for compatibility, but the
> usage help will be modified to be the same as Tomcat 5.
>
> It has to be noted that:
> - The JSP runtime is now very efficient. The old webapp mode (with its
> static web.xml) is a hack (and a 100% proprietary one at that).
> - Precompilation should only occur at webapp deployment time in the
> general case (the generated code is closely tied to the Jasper runtime
> release).
> - Additional features could be added to the manager servlet to, for
> example, cause precompilation of the deployed webapp in a separate process.
> - I am -1 to returning to the old "webapp" option behavior (ie, the
> generated files should by default be deployed in the work directory, not
> /WEB-INF/classes).
>
> <ballot>
> +1 [ ] Remove the options
> -1 [ ] Do not remove the options
> </ballot>
The problem is that keeping the options is where the work has to be done...
Removing cost (nearly) nothing but brinks nothing.
Probably the vote could be:
[ ] - Remove the options
[ ] - Keep the options _and_ fix them.
>
> Note: Users may vote, but only committers have binding votes.
>
> Remy
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Henri Gomez <hg...@apache.org>.
Costin Manolache wrote:
> To clarify - I agree jspc has a lot of broken options and
> features. My use case is:
>
> <taskdef classname="org.apache.jasper.JspC" name="jasper2" >
> <classpath>
> <pathelement location="${java.home}/../lib/tools.jar"/>
> <fileset dir="${tomcat.home}/server/lib">
> <include name="*.jar"/>
> </fileset>
> <fileset dir="${tomcat.home}/common/lib">
> <include name="*.jar"/>
> </fileset>
> <pathelement location="${build.dir}/classes"/>
> <path refid="all_other_jars"/>
> </classpath>
> </taskdef>
>
> <jasper2 verbose="0"
> package="my.package"
> compile="true"
> validateXml="false"
> uriroot="${webapp.dir}"
> webXmlFragment="${build.dir}/generated_web.xml"
> outputDir="${build.dir}/src/my/package" />
>
> <loadfile property="generated_web.xml"
> srcFile="${build.dir}/generated_web.xml" />
>
> <replace file="${jspui.webapp.dir}/WEB-INF/web.xml"
> token="<!--GENERATED_JSPS-->"
> value="${generated_web.xml}" />
>
> <javac destdir="${build.dir}/classes"
> optimize="off"
> debug="on"
> srcdir="${build.dir}/src" >
> <classpath refid='...' />
> <include name="my/package/**" />
> </javac>
I'm using a similar way with jspc from Tomcat 3.3.2-dev :
<java classname="org.apache.jasper.JspC">
<classpath refid="jspc.classpath"/>
<arg line="
-d ${build.dir}/src
-uriroot ${build.dir}/dst
-webinc ${build.dir}/dst/WEB-INF/jsp.xml
-webapp ${build.dir}/dst" />
</java>
<javac srcdir="${build.dir}/src"
destdir="${build.dir}/classes"
debug="${compile.debug}"
deprecation="${compile.deprecation}"
optimize="${compile.optimize}"
excludes="bas*,status*">
<classpath refid="jsp.compile.classpath"/>
</javac>
<mkdir dir="${build.dir}/dst/WEB-INF/lib"/>
<jar jarfile="${build.dir}/dst/WEB-INF/lib/${wname}-jsps-${jarext}.jar"
basedir="${build.dir}/classes"/>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Henri Gomez <hg...@apache.org>.
>> Another big advantage of using JSP -> servlet is that you didn't have
>> security problems of code exposure ;)
>
>
>
> Hey, stop making fun of me, and get back to work ;-)
Oui patron ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Remy Maucherat <re...@apache.org>.
Henri Gomez wrote:
>
> > BTW, no matter how I look at it, the practice of generating servlets
> > seems really ugly to me (of course, there are so many ugly things
> > about JSPs, I guess it's only one of them).
>
>
> Another big advantage of using JSP -> servlet is that you didn't have
> security problems of code exposure ;)
Hey, stop making fun of me, and get back to work ;-)
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Henri Gomez <hg...@apache.org>.
> BTW, no matter how I look at it, the practice of generating servlets
> seems really ugly to me (of course, there are so many ugly things about
> JSPs, I guess it's only one of them).
Another big advantage of using JSP -> servlet is that you didn't have
security problems of code exposure ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Costin Manolache <cm...@yahoo.com>.
Remy Maucherat wrote:
> Costin Manolache wrote:
>
>> To clarify - I agree jspc has a lot of broken options and
>> features. My use case is:
>>
>> Removing the CLI or any other options is fine for me. I don't need
>> jspc to compile or do any fancy thing - just compile JSPs to servlets
>> and generate the web.xml fragment.
>
>
> Actually, I don't care about any use case of jspc (which is good as it's
> broken).
> I was just trying to help out fix bugs, and thought it would be better
> to try to provide user friendly tools (instead of bloated and broken
> ones). I'll focus on some other area of the code then.
I do care about this use case, and I'm pretty sure it's not broken.
I have no problem with deprecating the other features and CLI -
if nobody is maintaining them it would be better to cut them. But
I use this feature ( and intend to fix it if it brakes )
> BTW, no matter how I look at it, the practice of generating servlets
> seems really ugly to me (of course, there are so many ugly things about
> JSPs, I guess it's only one of them).
:-)
It's not that bad - generating servlets is one of the things I like
in jsp.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Proposed jspc refactoring
Posted by Martin Algesten <pu...@taglab.com>.
What about trying to argue for why an error page returns error code 200?
Martin
-----Original Message-----
From: Remy Maucherat [mailto:remm@apache.org]
Sent: 07 November 2002 16:10
To: Tomcat Developers List
Subject: Re: [VOTE] Proposed jspc refactoring
Costin Manolache wrote:
> To clarify - I agree jspc has a lot of broken options and features. My
> use case is:
>
> Removing the CLI or any other options is fine for me. I don't need
> jspc to compile or do any fancy thing - just compile JSPs to servlets
> and generate the web.xml fragment.
Actually, I don't care about any use case of jspc (which is good as it's
broken).
I was just trying to help out fix bugs, and thought it would be better
to try to provide user friendly tools (instead of bloated and broken
ones). I'll focus on some other area of the code then.
BTW, no matter how I look at it, the practice of generating servlets
seems really ugly to me (of course, there are so many ugly things about
JSPs, I guess it's only one of them).
Remy
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> To clarify - I agree jspc has a lot of broken options and
> features. My use case is:
>
> Removing the CLI or any other options is fine for me. I don't need
> jspc to compile or do any fancy thing - just compile JSPs to servlets
> and generate the web.xml fragment.
Actually, I don't care about any use case of jspc (which is good as it's
broken).
I was just trying to help out fix bugs, and thought it would be better
to try to provide user friendly tools (instead of bloated and broken
ones). I'll focus on some other area of the code then.
BTW, no matter how I look at it, the practice of generating servlets
seems really ugly to me (of course, there are so many ugly things about
JSPs, I guess it's only one of them).
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Costin Manolache <cm...@yahoo.com>.
To clarify - I agree jspc has a lot of broken options and
features. My use case is:
<taskdef classname="org.apache.jasper.JspC" name="jasper2" >
<classpath>
<pathelement location="${java.home}/../lib/tools.jar"/>
<fileset dir="${tomcat.home}/server/lib">
<include name="*.jar"/>
</fileset>
<fileset dir="${tomcat.home}/common/lib">
<include name="*.jar"/>
</fileset>
<pathelement location="${build.dir}/classes"/>
<path refid="all_other_jars"/>
</classpath>
</taskdef>
<jasper2 verbose="0"
package="my.package"
compile="true"
validateXml="false"
uriroot="${webapp.dir}"
webXmlFragment="${build.dir}/generated_web.xml"
outputDir="${build.dir}/src/my/package" />
<loadfile property="generated_web.xml"
srcFile="${build.dir}/generated_web.xml" />
<replace file="${jspui.webapp.dir}/WEB-INF/web.xml"
token="<!--GENERATED_JSPS-->"
value="${generated_web.xml}" />
<javac destdir="${build.dir}/classes"
optimize="off"
debug="on"
srcdir="${build.dir}/src" >
<classpath refid='...' />
<include name="my/package/**" />
</javac>
Removing the CLI or any other options is fine for me. I don't need
jspc to compile or do any fancy thing - just compile JSPs to servlets
and generate the web.xml fragment.
Costin
Remy Maucherat wrote:
> Hi,
>
> jspc is IMO overly complex, with many features nobody knows how to use,
> and nobody cares to test (hence sometimes some of them are randomly
> broken during Jasper refactorings).
>
> I propose that:
> - In Tomcat 5, all jspc options are removed, in favor of allowing only
> the webapp mode (with its relevant options). This webapp mode would
> generate code and classes which should be deployed in the work
> directory, exactly the same as if they were dynamically compiled by
> Jasper (which has the big advantage of using only one big operation mode
> for everything). Single file mode is IMO useless (dynamic compilation
> works fine).
> - In Tomcat 4.1, the options will stay in for compatibility, but the
> usage help will be modified to be the same as Tomcat 5.
>
> It has to be noted that:
> - The JSP runtime is now very efficient. The old webapp mode (with its
> static web.xml) is a hack (and a 100% proprietary one at that).
> - Precompilation should only occur at webapp deployment time in the
> general case (the generated code is closely tied to the Jasper runtime
> release).
> - Additional features could be added to the manager servlet to, for
> example, cause precompilation of the deployed webapp in a separate
> process. - I am -1 to returning to the old "webapp" option behavior (ie,
> the generated files should by default be deployed in the work directory,
> not /WEB-INF/classes).
>
> <ballot>
> +1 [ ] Remove the options
> -1 [ ] Do not remove the options
> </ballot>
>
> Note: Users may vote, but only committers have binding votes.
>
> Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Costin Manolache wrote:
> Hans Bergsten wrote:
>
>
>>>Removing the CLI and keeping the basic functionality seems like
>>>a good idea.
>>
>>"CLI" as in ...? Sorry, I'm not familar with this acronym.
>
>
> Command line interface. jspc.sh, main() and the argument processing.
Ah, I should have known ;-)
> Just use the jspc task in ant. My understanding is that ant's
> <jspc> can also generate code for other containers, so one
> extra benefit.
But why should we require Ant? Isn't it better to refactor the code
so that the CLI interface and the Ant task can use the same core,
just using different interfaces?
> [...]
>>>I would go even further - since we are already using ant to
>>>compile the java to .class, it may be a good idea to make the
>>>.jsp->.java task 'first class'.
>>
>>Not sure I follow. If you mean to do this in addition to fixing
>>JSPC (with the -webapp option), it's okay with me.
>
>
> Basically add an execute() method and setters to Compiler, and
> calling jasper indirectly, using the ant task.
>
> Jasper will be a very large ant task. That means we could
> switch jasper versions ( or other jsp impl ), it could be used
> in other containers or applications, etc.
Are you saying pretty much what I said above: a common core that can
be used both a an Ant task implementation and a CLI?
> ( well, I'm not volunteering for that - but I think it would
> be a nice idea for 5.0 ).
I agree that this type of refactoring is better targetted for TC 5.
For TC 4.1.x I suggest we just fix what's broken. I still haven't
heard what _is_ broken, though. Can someone tell me? I'll start
running some test soon (this weekend, most likely) with TC 4.1.14
(or .15 if it's available by then) and see what I'll find.
> [...]
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
JavaServer Pages http://TheJSPBook.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Costin Manolache <cm...@yahoo.com>.
Hans Bergsten wrote:
>> Removing the CLI and keeping the basic functionality seems like
>> a good idea.
>
> "CLI" as in ...? Sorry, I'm not familar with this acronym.
Command line interface. jspc.sh, main() and the argument processing.
Just use the jspc task in ant. My understanding is that ant's
<jspc> can also generate code for other containers, so one
extra benefit.
And if jspc becomes first-class - we'll stop the
nightly gump test failures for ant :-) ( JSPC is
actually tested by gump - part of ant tests ).
( there are failures - but it seems they happen only
in gump env, and I wasn't yet able to fix them ).
>> I would go even further - since we are already using ant to
>> compile the java to .class, it may be a good idea to make the
>> .jsp->.java task 'first class'.
>
> Not sure I follow. If you mean to do this in addition to fixing
> JSPC (with the -webapp option), it's okay with me.
Basically add an execute() method and setters to Compiler, and
calling jasper indirectly, using the ant task.
Jasper will be a very large ant task. That means we could
switch jasper versions ( or other jsp impl ), it could be used
in other containers or applications, etc.
( well, I'm not volunteering for that - but I think it would
be a nice idea for 5.0 ).
BTW, a separate issue would be extending the JMX support
to jasper. We use JMX mostly for configuration, but that's
only a small part of what can be done. We can extract
informations or control jasper at runtime ( recompile, set
jikes, etc ). And jasper would be even easier to embed.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Costin Manolache wrote:
> Remy has a point - the current code is not very clean, and doesn't
> seem to be tested/maintained enough.
>
> I use the ant tasks - and I have a feeling many other users of jspc
> are doing the same.
>
> Removing the CLI and keeping the basic functionality seems like
> a good idea.
"CLI" as in ...? Sorry, I'm not familar with this acronym.
> For example compiling a jsp page outside a webapp can't work
> in all cases - if it has includes, etc it needs to resolve, it
> needs taglib definitions from WEB-INF, etc. I can't see any
> good reason to keep it if it's half broken by definition.
Right, I agree.
> Also - compiling the java files is the job of <javac>,
> and the mapping and web.xml fragment generation can be
> more easily done using only the ant tasks.
Even though I see one advantage with including compilation to class
files in JSPC (simlicity, no need to set up Ant, which is not always
available in the web app developers environment), I wasn't aware of
the -compile option until this week (since it's not documented).
I'm okay with removing it and handle compilation in other ways.
> I would go even further - since we are already using ant to
> compile the java to .class, it may be a good idea to make the
> .jsp->.java task 'first class'.
Not sure I follow. If you mean to do this in addition to fixing
JSPC (with the -webapp option), it's okay with me.
> In any case - the task is supported ( at least by me, it seems Henri is
> using it as well ).
> If there are people who want to support the CLI and the other
> options - then we can keep them, but if not - I think it's better
> to remove them or mark as unsupported.
See above.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
JavaServer Pages http://TheJSPBook.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Proposed jspc refactoring
Posted by John Trollinger <ja...@trollingers.com>.
I have to time to go through and fix all the options (including cleaning
up the code) but I would like to see what options are actually used (or
would like to be used if they work)
I also have no problems maintaining jscp as I use it a lot and have
customized it to do what I want.
I would just like some direction to go with..
John
> -----Original Message-----
> From: news [mailto:news@main.gmane.org] On Behalf Of Costin Manolache
> Sent: Thursday, November 07, 2002 1:39 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: Re: [VOTE] Proposed jspc refactoring
>
>
> Remy has a point - the current code is not very clean, and
> doesn't seem to be tested/maintained enough.
>
> I use the ant tasks - and I have a feeling many other users
> of jspc are doing the same.
>
> Removing the CLI and keeping the basic functionality seems like
> a good idea.
>
> For example compiling a jsp page outside a webapp can't work
> in all cases - if it has includes, etc it needs to resolve, it
> needs taglib definitions from WEB-INF, etc. I can't see any
> good reason to keep it if it's half broken by definition.
>
> Also - compiling the java files is the job of <javac>,
> and the mapping and web.xml fragment generation can be
> more easily done using only the ant tasks.
>
> I would go even further - since we are already using ant to
> compile the java to .class, it may be a good idea to make the
> .jsp->.java task 'first class'.
>
> In any case - the task is supported ( at least by me, it
> seems Henri is
> using it as well ).
> If there are people who want to support the CLI and the other
> options - then we can keep them, but if not - I think it's
> better to remove them or mark as unsupported.
>
> Costin
>
>
>
> Hans Bergsten wrote:
>
> > Remy Maucherat wrote:
> >> Hi,
> >>
> >> jspc is IMO overly complex, with many features nobody knows how to
> >> use, and nobody cares to test (hence sometimes some of them are
> >> randomly broken during Jasper refactorings).
> >
> > I will not formally vote on this, because I've been
> inactive in this
> > project for so long I feel I need to familiarize myself with the
> > current code base before I can exercise my voting
> priviledges. But I
> > do have some comments, see below.
> >
> >> I propose that:
> >> - In Tomcat 5, all jspc options are removed, in favor of allowing
> >> only the webapp mode (with its relevant options). This webapp mode
> >> would generate code and classes which should be deployed
> in the work
> >> directory, exactly the same as if they were dynamically
> compiled by
> >> Jasper (which has the big advantage of using only one big
> operation
> >> mode for everything). Single file mode is IMO useless (dynamic
> >> compilation works fine).
> >
> > I agree with you regading single file mode, but not with the rest.
> >
> >> - In Tomcat 4.1, the options will stay in for
> compatibility, but the
> >> usage help will be modified to be the same as Tomcat 5.
> >
> > I'm not sure what you mean by this proposal. Are you saying
> that the
> > TC 4.1.x version would have a usage message (documentation) that
> > doesn't match its features? If so, why? If there will be
> differences
> > between the TC 4.1.x and TC 5 versions, I assume we will maintain a
> > separate code base for each version, each with documentation that
> > correctly reflects their features.
> >
> >> It has to be noted that:
> >> - The JSP runtime is now very efficient. The old webapp mode (with
> >> its static web.xml) is a hack (and a 100% proprietary one at that).
> >
> > Efficiency is not all that important here, since precomiplation is
> > done before deployment (that's the whole idea, right ;-)
> >
> > Not sure what you mean with "100% proprietary". The web.xml file (or
> > fragment) that is generated is defined by the servlet spec.
> >
> >> - Precompilation should only occur at webapp deployment
> time in the
> >> general case (the generated code is closely tied to the Jasper
> >> runtime release).
> >
> > I don't agree. It's very handy to be able to generate a JAR
> file with
> > all JSP pages for an application and deploy it to many different
> > container instances (Tomcat or others, as long as
> jasper-runtime.jar
> > is included). There are many users that want to keep the production
> > environment as simple (and small in embedded systems, for
> instance) as
> > possible, and deploying precompiled JSP pages lets me use a
> production
> > environment without the JSP compiler and use JRE instead of the JDK.
> >
> >> - Additional features could be added to the manager
> servlet to, for
> >> example, cause precompilation of the deployed webapp in a separate
> >> process.
> >
> > That's a separate thing, more of a container feature than
> JSPC in my
> > mind.
> >
> >> - I am -1 to returning to the old "webapp" option behavior
> (ie, the
> >> generated files should by default be deployed in the work
> directory,
> >> not /WEB-INF/classes).
> >
> > Why not discuss what the problems with the current options are, and
> > try to find a solution instead? Like I've said, it's been a while
> > since I was actively involved with Tomcat development, but
> I know that
> > in Tomcat 4.0.4, JSPC seemed to work fine with all options
> available
> > at the time. How did Jasper2 break things? If I understand what the
> > main problem is, I can help find a solution (primarily for Tomcat
> > 4.1.x; I'm afraid I don't have enough cycles to get into
> Tomcat 5 at
> > the moment).
> >
> > Hans
>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:tomcat-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Costin Manolache <cm...@yahoo.com>.
Remy has a point - the current code is not very clean, and doesn't
seem to be tested/maintained enough.
I use the ant tasks - and I have a feeling many other users of jspc
are doing the same.
Removing the CLI and keeping the basic functionality seems like
a good idea.
For example compiling a jsp page outside a webapp can't work
in all cases - if it has includes, etc it needs to resolve, it
needs taglib definitions from WEB-INF, etc. I can't see any
good reason to keep it if it's half broken by definition.
Also - compiling the java files is the job of <javac>,
and the mapping and web.xml fragment generation can be
more easily done using only the ant tasks.
I would go even further - since we are already using ant to
compile the java to .class, it may be a good idea to make the
.jsp->.java task 'first class'.
In any case - the task is supported ( at least by me, it seems Henri is
using it as well ).
If there are people who want to support the CLI and the other
options - then we can keep them, but if not - I think it's better
to remove them or mark as unsupported.
Costin
Hans Bergsten wrote:
> Remy Maucherat wrote:
>> Hi,
>>
>> jspc is IMO overly complex, with many features nobody knows how to use,
>> and nobody cares to test (hence sometimes some of them are randomly
>> broken during Jasper refactorings).
>
> I will not formally vote on this, because I've been inactive in this
> project for so long I feel I need to familiarize myself with the
> current code base before I can exercise my voting priviledges. But I
> do have some comments, see below.
>
>> I propose that:
>> - In Tomcat 5, all jspc options are removed, in favor of allowing only
>> the webapp mode (with its relevant options). This webapp mode would
>> generate code and classes which should be deployed in the work
>> directory, exactly the same as if they were dynamically compiled by
>> Jasper (which has the big advantage of using only one big operation mode
>> for everything). Single file mode is IMO useless (dynamic compilation
>> works fine).
>
> I agree with you regading single file mode, but not with the rest.
>
>> - In Tomcat 4.1, the options will stay in for compatibility, but the
>> usage help will be modified to be the same as Tomcat 5.
>
> I'm not sure what you mean by this proposal. Are you saying that the
> TC 4.1.x version would have a usage message (documentation) that doesn't
> match its features? If so, why? If there will be differences between the
> TC 4.1.x and TC 5 versions, I assume we will maintain a separate code
> base for each version, each with documentation that correctly reflects
> their features.
>
>> It has to be noted that:
>> - The JSP runtime is now very efficient. The old webapp mode (with its
>> static web.xml) is a hack (and a 100% proprietary one at that).
>
> Efficiency is not all that important here, since precomiplation is
> done before deployment (that's the whole idea, right ;-)
>
> Not sure what you mean with "100% proprietary". The web.xml file (or
> fragment) that is generated is defined by the servlet spec.
>
>> - Precompilation should only occur at webapp deployment time in the
>> general case (the generated code is closely tied to the Jasper runtime
>> release).
>
> I don't agree. It's very handy to be able to generate a JAR file with
> all JSP pages for an application and deploy it to many different
> container instances (Tomcat or others, as long as jasper-runtime.jar
> is included). There are many users that want to keep the production
> environment as simple (and small in embedded systems, for instance) as
> possible, and deploying precompiled JSP pages lets me use a production
> environment without the JSP compiler and use JRE instead of the JDK.
>
>> - Additional features could be added to the manager servlet to, for
>> example, cause precompilation of the deployed webapp in a separate
>> process.
>
> That's a separate thing, more of a container feature than JSPC in my
> mind.
>
>> - I am -1 to returning to the old "webapp" option behavior (ie, the
>> generated files should by default be deployed in the work directory, not
>> /WEB-INF/classes).
>
> Why not discuss what the problems with the current options are, and
> try to find a solution instead? Like I've said, it's been a while since
> I was actively involved with Tomcat development, but I know that in
> Tomcat 4.0.4, JSPC seemed to work fine with all options available at
> the time. How did Jasper2 break things? If I understand what the main
> problem is, I can help find a solution (primarily for Tomcat 4.1.x; I'm
> afraid I don't have enough cycles to get into Tomcat 5 at the moment).
>
> Hans
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Proposed jspc refactoring
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Remy Maucherat wrote:
> Hi,
>
> jspc is IMO overly complex, with many features nobody knows how to use,
> and nobody cares to test (hence sometimes some of them are randomly
> broken during Jasper refactorings).
I will not formally vote on this, because I've been inactive in this
project for so long I feel I need to familiarize myself with the
current code base before I can exercise my voting priviledges. But I
do have some comments, see below.
> I propose that:
> - In Tomcat 5, all jspc options are removed, in favor of allowing only
> the webapp mode (with its relevant options). This webapp mode would
> generate code and classes which should be deployed in the work
> directory, exactly the same as if they were dynamically compiled by
> Jasper (which has the big advantage of using only one big operation mode
> for everything). Single file mode is IMO useless (dynamic compilation
> works fine).
I agree with you regading single file mode, but not with the rest.
> - In Tomcat 4.1, the options will stay in for compatibility, but the
> usage help will be modified to be the same as Tomcat 5.
I'm not sure what you mean by this proposal. Are you saying that the
TC 4.1.x version would have a usage message (documentation) that doesn't
match its features? If so, why? If there will be differences between the
TC 4.1.x and TC 5 versions, I assume we will maintain a separate code
base for each version, each with documentation that correctly reflects
their features.
> It has to be noted that:
> - The JSP runtime is now very efficient. The old webapp mode (with its
> static web.xml) is a hack (and a 100% proprietary one at that).
Efficiency is not all that important here, since precomiplation is
done before deployment (that's the whole idea, right ;-)
Not sure what you mean with "100% proprietary". The web.xml file (or
fragment) that is generated is defined by the servlet spec.
> - Precompilation should only occur at webapp deployment time in the
> general case (the generated code is closely tied to the Jasper runtime
> release).
I don't agree. It's very handy to be able to generate a JAR file with
all JSP pages for an application and deploy it to many different
container instances (Tomcat or others, as long as jasper-runtime.jar
is included). There are many users that want to keep the production
environment as simple (and small in embedded systems, for instance) as
possible, and deploying precompiled JSP pages lets me use a production
environment without the JSP compiler and use JRE instead of the JDK.
> - Additional features could be added to the manager servlet to, for
> example, cause precompilation of the deployed webapp in a separate process.
That's a separate thing, more of a container feature than JSPC in my
mind.
> - I am -1 to returning to the old "webapp" option behavior (ie, the
> generated files should by default be deployed in the work directory, not
> /WEB-INF/classes).
Why not discuss what the problems with the current options are, and
try to find a solution instead? Like I've said, it's been a while since
I was actively involved with Tomcat development, but I know that in
Tomcat 4.0.4, JSPC seemed to work fine with all options available at
the time. How did Jasper2 break things? If I understand what the main
problem is, I can help find a solution (primarily for Tomcat 4.1.x; I'm
afraid I don't have enough cycles to get into Tomcat 5 at the moment).
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
JavaServer Pages http://TheJSPBook.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Proposed jspc refactoring
Posted by John Trollinger <ja...@trollingers.com>.
>
> <ballot>
> +1 [ ] Remove the options
> -1 [X] Do not remove the options
> </ballot>
I think some of the options are useless and should go away, but some of
them are (or could be usefull if they worked).
Right now I don't think jspc meets many peoples needs, maybe it is time
to find out the needs of users for jspc and implement those correctly.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>