I like the way JspC works in Tomcat 4.0.x (at least from 4.0.4 and
forward). As far as I can tell, it does exactly what you want without
the need for extra options (it generates directory-based packages by
default). I'm sorry I still haven't found the time to look into the
problems with the Tomcat
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-11-18 12:48 ---
The patch attachment dated 09/03/03 along with Mark's notes from 10/18 worked
great with our application (334 jsp's, 8 or so directories).
Previously we had two issues
On 11/12/2002 at 4:03 PM Costin Manolache wrote:
Fredrik Westermarck wrote:
The problem that I and others have experienced is that proposals and/or
patches, by non-committers, don't get discussed or voted about.
You have to keep pushing. If you send patches and proposals you can
become a
Costin Manolache wrote:
The problem that I and others have experienced is that proposals and/or
patches, by non-committers, don't get discussed or voted about.
You have to keep pushing.
Well I did, but the next person might not. In that case the community as
a whole may miss important
/show_bug.cgi?id=14537
PATCH: Fix for NPE with JSPC and tag library references
Summary: PATCH: Fix for NPE with JSPC and tag library references
Product: Tomcat 4
Version: 4.1.12
Platform: All
OS/Version: All
Status: NEW
Severity
Remy Maucherat [EMAIL PROTECTED] wrote:
I'd also like to point out that the servlet API changes are very
limited, and it will be possible to use Tomcat 5.0 with the Jasper
from Tomcat 4.1. So I think major new features should go in the 5.0
codebase.
What is a realistic timeline for 5.0
Remy Maucherat wrote:
Glenn Nielsen wrote:
Remy Maucherat wrote:
Bill Barker wrote:
I think we have too many dev branches already, and this is causing
maintenance problems. I'd like to have those things go in either 4.1
or 5.0. Esp the jspc refactoring ;-) jspc is currently broken
Glenn Nielsen wrote:
Remy Maucherat wrote:
Glenn Nielsen wrote:
I'm now independent and unemployed, so I'm not aware of the Sun
schedules for the spec anymore :-P Probably within 3-6 months given
J2EE 1.4 is in beta. The rule is we cannot release a stable version of
5.0.x until the specs
Remy Maucherat wrote:
I consider 4.1.x can recieve bug fixes and minor feature additions
(example: the JNDI realm new feature which just got added,
optimisations, etc ...), similar to HTTPd 2.0. This is consistent with
the patches I and others have been applying, the release process we've
Glenn Nielsen wrote:
If I understand correctly, what you are saying above is that Tomcat 4
development should be frozen except for bug fixes and all changes and new
features go in
Tomcat 5? Is that a correct summary? If so I think it is premature to do
so, especially since a production
Has there or will there be any type of requirement gathering on jspc
refactoring.
I would like to help refactor this but would like to know what options
need to be supported / added and which ones to remove.
John
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
Costin Manolache wrote:
I consider 4.1.x can recieve bug fixes and minor feature additions
(example: the JNDI realm new feature which just got added,
optimisations, etc ...), similar to HTTPd 2.0. This is consistent with
the patches I and others have been applying, the release process we've
been
Costin Manolache wrote:
Glenn Nielsen wrote:
If I understand correctly, what you are saying above is that Tomcat 4
development should be frozen except for bug fixes and all changes and new
features go in
Tomcat 5? Is that a correct summary? If so I think it is premature
to do
so,
John Trollinger wrote:
Has there or will there be any type of requirement gathering on jspc
refactoring.
I would like to help refactor this but would like to know what options
need to be supported / added and which ones to remove.
Everyone has apparently different opinions on what features
Fredrik Westermarck wrote:
Do you actually mean that a new feature will only be added if there is
enough committers that need the feature? Does this apply only to 4.1.x?
Well... In theory it should apply to all tomcat features, or at
least to important ones - they must be first proposed on
Costin Manolache wrote:
Do you actually mean that a new feature will only be added if there is
enough committers that need the feature? Does this apply only to 4.1.x?
Well... In theory it should apply to all tomcat features, or at
least to important ones - they must be first proposed on the
Fredrik Westermarck wrote:
The problem that I and others have experienced is that proposals and/or
patches, by non-committers, don't get discussed or voted about.
You have to keep pushing. If you send patches and proposals you can
become a committer - and then you'll start ignoring patches and
Bill Barker wrote:
Based on problems reported by users of JSPC Remy made a proposal
to deprecate it.
This resulted in a number of people responding that they used JSPC
and strongly felt it should be kept.
There did seem to be some consensus that JSPC could beneifit from
a review
Glenn Nielsen wrote:
Remy Maucherat wrote:
Bill Barker wrote:
I think we have too many dev branches already, and this is causing
maintenance problems. I'd like to have those things go in either 4.1
or 5.0. Esp the jspc refactoring ;-) jspc is currently broken in 4.1
and not really
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
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
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
Based on problems reported by users of JSPC Remy made a proposal
to deprecate it.
This resulted in a number of people responding that they used JSPC
and strongly felt it should be kept.
There did seem to be some consensus that JSPC could beneifit from
a review and refactoring to make it easier
- Original Message -
From: Glenn Nielsen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, November 10, 2002 9:44 PM
Subject: JSPC refactoring/documentation
Based on problems reported by users of JSPC Remy made a proposal
to deprecate it.
This resulted in a number of people
/show_bug.cgi?id=14302
Jspc can't be used to compile the entire web application
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
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
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
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
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
As a user, I agree with Hans Bergsten's comments on the bug database.
Being able to deploy a single war file with all precompiled JSP's to
the
webapp directory is a very useful feature. It would be bad for us if we
weren't
able to do that any longer. (Only thing to remember is to use the
correct
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
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
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
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,
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
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
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
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
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
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
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 ;)
--
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
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: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
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
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
On Thu, 7 Nov 2002, Henri Gomez wrote:
Date: Thu, 07 Nov 2002 12:43:45 +0100
From: Henri Gomez [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: [VOTE] Proposed jspc refactoring
Remy Maucherat wrote:
Hi
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
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
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: [EMAIL PROTECTED]
Subject: Re: [VOTE] Proposed jspc refactoring
Remy has a point - the current code
For what it's worth, here's how I benefit from jspc on a regular basis.
I'm one of the principal developers of a fairly high-traffic site powered by tomcat
4.1.12.
We use jspc for correctness checking as part of our compile cycle, for two reasons:
a)To enforce valid jsp tag use (required
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
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
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
Hi all,
I toyed a bit with the webapp option of JSPC, and a few things seemed
really odd.
- Although there are options to generate web.xml files or fragments,
this makes no sense as the generated files are now meant to be put in
the work directory instead. This was probably done
to allow the packages to be generated from the dir
structure, I also belive there are bugs about this)
Just my 2 cents..
John
-Original Message-
From: Remy Maucherat [mailto:remm;apache.org]
Sent: Wednesday, November 06, 2002 9:29 AM
To: Tomcat Developers List
Subject: JSPC problems
: JSPC problems with webapp option
Hi all,
I toyed a bit with the webapp option of JSPC, and a few things seemed
really odd.
- Although there are options to generate web.xml files or fragments,
this makes no sense as the generated files are now meant to be put in
the work directory
: Wednesday, November 06, 2002 3:29 PM
To: Tomcat Developers List
Subject: JSPC problems with webapp option
Hi all,
I toyed a bit with the webapp option of JSPC, and a few things seemed
really odd.
- Although there are options to generate web.xml files or fragments,
this makes no sense
Although I'm just a user, I would like to warnings also. On a related
note, --compile isn't covered in the documentation. I stumbled across
it when I look at the source code a month back. It might be nice to
output the warnings to a file for those who have large webapps with
thousands of jsp
Remy Maucherat wrote:
Hi all,
I toyed a bit with the webapp option of JSPC, and a few things seemed
really odd.
- Although there are options to generate web.xml files or fragments,
this makes no sense as the generated files are now meant to be put in
the work directory instead
peter lin wrote:
Although I'm just a user, I would like to warnings also. On a related
note, --compile isn't covered in the documentation. I stumbled across
it when I look at the source code a month back. It might be nice to
output the warnings to a file for those who have large webapps with
/show_bug.cgi?id=14302
Jspc can't be used to compile the entire web application
Summary: Jspc can't be used to compile the entire web application
Product: Tomcat 4
Version: 4.1.12
Platform: All
OS/Version: All
Status: NEW
Severity
/show_bug.cgi?id=14302
Jspc can't be used to compile the entire web application
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
/show_bug.cgi?id=14302
Jspc can't be used to compile the entire web application
--- Additional Comments From [EMAIL PROTECTED] 2002-11-06 20:17 ---
I agree with others that commented on the proposal posted on Tomcat-Dev that
removing the web.xml generation feature would be a bad idea.
Being
/show_bug.cgi?id=14302
Jspc can't be used to compile the entire web application
--- Additional Comments From [EMAIL PROTECTED] 2002-11-06 20:23 ---
I do not agree, as the generated code may not compatible between versions of
Jasper, or even between minor Tomcat revisions. You *have
/show_bug.cgi?id=14302
Jspc can't be used to compile the entire web application
--- Additional Comments From [EMAIL PROTECTED] 2002-11-06 21:19 ---
Recompiling for a new version of Tomcat is reasonable. But I may also want to
compile a JSP app and deploy on a different container. I can do
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-10-18 06:53 ---
Greg,
Yes I had the problems with normal JSP compilation as well, and it was due to
an unchecked cast. Here is the change that resolves it:
JSPCompilationContext.java
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-10-16 07:58 ---
Mark,
that patch introduced other problems with normal JSP compilation, so
I have backed it out of my copy of jasper.Note that I'm not a tomcat
committer
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-10-16 03:25 ---
I am unclear as to whether this problem is approaching a resolution. I am also
suffering from the same issue in relation to the lack of class packaging for
files
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-10-16 04:58 ---
Greg, I have applied your patch and this has enabled me to proceed
successfully. It would be great if this could be integrated into the next
Tomcat release
I spent the last two days trying to use JspC to compile an entire webapp
and came across a problem. I'm not sure if this is a bug or not, but I
can reproduce it every time. I'm still trying to track down the cause,
but I thought I'd post a question and maybe some one with more knowledge
can
Here is a bit more information. I took a look at the jar files for jsp
1.1 tags and they include a taglib.tld file in meta-inf/. Once I remove
that, it compiles the pages fine. It looks like there's a conflict in
either jasper compiler or jspc that is unable to resolve which .tld file
to use
/show_bug.cgi?id=13212
JSPC is unable to compile when JSP1.1 taglib jar contains tld file
Summary: JSPC is unable to compile when JSP1.1 taglib jar
contains tld file
Product: Tomcat 4
Version: 4.1.12
Platform: All
OS/Version: Other
Here is a bit more information. I took a look at the jar files for jsp
1.1 tags and they include a taglib.tld file in meta-inf/. Once I remove
that, it compiles the pages fine. It looks like there's a conflict in
either jasper compiler or jspc that is unable to resolve which .tld file
to use
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-09-27 15:40 ---
Hi,
I analyzed the problem with jspc and jsp pages in a directory structure.
These are the problems based on the Tomcat 4.1.12 version:
1. the directory structure
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-09-17 18:28 ---
Is anyone going to add the patch for package names.. as it would realy make a
lot of other things work nicely (ie ant compiles of JSP pages)
--
To unsubscribe, e-mail
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-09-09 13:38 ---
I have a fix that modifies the javac code by adding a -isolate flag that
compiles each jsp file in isolation. If anyone wants it, let me know and I can
upload
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-09-09 14:42 ---
I also had JspC do the compilation itself, which made the JspC easier to deal
with (IMHO). Unfortunately, other committers didn't agree, and compilation is
now
patrickl2002/09/04 08:32:53
Modified:jasper2/src/bin jspc-using-launcher.bat
Log:
Append %PATH% for all Windows platforms since the %0 DOS bug is not limited to
Windows 9x platforms
Revision ChangesPath
1.3 +1 -7 jakarta-tomcat-jasper/jasper2/src/bin/jspc
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-09-03 14:49 ---
Created an attachment (id=2903)
Contributed patch for this problem.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-09-03 14:50 ---
I have attached a patch from [EMAIL PROTECTED] that appears to fix the
package naming problem.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional
/show_bug.cgi?id=11891
JspC does not work for webapps
[EMAIL PROTECTED] changed:
What|Removed |Added
Severity|Normal |Major
Status|RESOLVED
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-08-29 10:46 ---
Created an attachment (id=2866)
jspdemo before JspC generation
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-08-29 10:46 ---
Created an attachment (id=2867)
jspdemo after JspC generation
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL
patrickl2002/08/29 11:19:59
Modified:jasper2/src/bin jspc-using-launcher.bat
Log:
Update scripts that use commons-launcher.jar so that %PATH% is only used on Windows
9x
Revision ChangesPath
1.2 +7 -1 jakarta-tomcat-jasper/jasper2/src/bin/jspc-using
/show_bug.cgi?id=11891
JspC does not work for webapps
Summary: JspC does not work for webapps
Product: Tomcat 4
Version: 4.1.9
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
/show_bug.cgi?id=11891
JspC does not work for webapps
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Additional Comments
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-08-21 12:53 ---
Created an attachment (id=2789)
diff of JspCompilationContext.java
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-08-21 12:53 ---
Created an attachment (id=2790)
diff JspC.java
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-08-21 12:54 ---
Created an attachment (id=2791)
diff messages.properties
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
/show_bug.cgi?id=11891
JspC does not work for webapps
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-08-21 13:21 ---
Created an attachment (id=2792)
this patch should replace the first one (forgot a piece)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-08-21 13:23 ---
the 4th patch is a replacement for the first JspC.java patch.. sorry about the
confusion I know I am going to cause.. :-)
--
To unsubscribe, e-mail: mailto:[EMAIL
/show_bug.cgi?id=11891
JspC does not work for webapps
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-08-21 14:29 ---
I can not reproduce your problem with the -webinc flag. It all works fine for
me, did you try it with something simple or your big app?
thanks,
John
--
To unsubscribe
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-08-21 15:01 ---
For a simple webapp, ls -R :
webapp/:
CVS/ WEB-INF/ date.jsp hello.jsp hello2.jsp subdir/
webapp/CVS:
Entries Repository Root
webapp/WEB-INF:
CVS/ jsp.xml
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-08-21 15:22 ---
the package names will always be org.apache.jsp (unless you specify other wise
with the -p option. Can you attach your sample war file, as I have the same
simple type
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-08-21 15:31 ---
Created an attachment (id=2793)
Webapp that demonstrates the -webinc problem
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-08-21 15:36 ---
I've attached a demo webapp. Are you sure that the packages should all be
org.apache.jsp? What good is putting the different hello.java classes in
different
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-08-21 15:44 ---
Your sample works fine for me. Make sure you applied the patchs correctly.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto
/show_bug.cgi?id=11891
JspC does not work for webapps
--- Additional Comments From [EMAIL PROTECTED] 2002-08-21 15:51 ---
Yes org.apache.jsp is ok for all the package names. If you run the webapp you
will see that despite the fact that the classes are both
org.apache.jsp.Hello_jsp
201 - 300 of 410 matches
Mail list logo
