jspc

Hello, I wish compile ahead automatically the files java starting from the files jsp, using the command jspc.bat. But I muddle myself with the syntax of the command. My directories are organized in the following way: " D:\folders\projets\calc\web ": sources jsp. Example of file name: marcsslst.jsp

Jspc

with javac - correct? However when I compile these source files generated from jspc I get the following error: handlePageException(java.lang.Exception) in javax.servlet.jsp.PageContext cannot be applied to (java.lang.Throwable) if (pageContext != null) pageContext.handlePageExcept

jspC

Hi, I am trying to run the jspc command and am experiencing some problems! I get errors about classes not being found, is there any way to reference classes from the CLASSPATH in the jspc task or do I have to put all the class files needed by the web app in the WEB-INF/classes / WEB-INF/lib

jspc

Hi! I run Tomcat version bin-window-5.0.9. I couldn't find the jspc in Tomacat/bin/ !!? Where i can find it or get it? Tanks __ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25¢ http://photos.yahoo.c

JspC output?

Whilst on the subject of JspC...does anyone know why no output is obtained when you run it from the command line? I am excecuting "java org.apache.jasper.JspC ..." and I never get any output! Again, is this a bug, or intended behaviour?! Many thanks, Dave

Jspc documentation

> Kin-Man, > I have a side question. > I am looking for the documentation /comments on the Jasper compiler(jspc)-I > have > looked through the JspC.java but there are no comment about different > compiler options. > I wondering if you can point me in a right directio

JspC / jspc.bat

In trying to use JspC I have noticed that it does not create the .java files the same way Jasper does when going to the page in a browser. I am trying to change this so that they both work the same way (and use as much of the same code as possible for obvious reasons), is anyone else working on

JspC enhancement

ot; option applies the package name prefix, but creates all the jsps in the same package. This leads to "duplicate class" problems if two jsps in different directories share the same name. BACKGROUND: Our company used to use JspC in Tomcat3 to precompile our JSPs for deployment. Tomcat

Jspc problems ?

Hi, I tried to use Jasper in Ant as a Ant Task to precompile JSP files. I defined the taskdef in Ant as mentioned in the JavaDoc as following: The JSP-to-Java is successful but some error when compi

jspc task

I am experiencing difficulties using the org.apache.jasper.JspC class within jasper-compiler.jar (any version) Using : After jasper2 has completed..onto evaluation of log file jspc task does not execute as all

JspC exception

Hi all, I am doing compilation using JspC.It is giving ClassCastException. parentClassLoader = (URLClassLoader)Thread.currentThread().getContextClassLoader() getContextClassLoader() will return AntClassLoader which is incompatible with URLClassLoader. Is this a bug? If so, does it ha

RE: [VOTE] Proposed jspc refactoring (how I use jspc)

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 ta

JSPC scripts broken

The JSPC scripts are broken. They need to pick up the new jasper-compiler.jar from the jasper directory. Also, although the catalina.sh script supports cygwin, the jasper script does not. <><><><><><><><><><><><><

JSPC and Ant

Does the Ant project have plans to support a build tag? Is JSPC friendly enough? That would rock. Steve

problem with jspc

While running the command jspc in tomcat\bin with -webapp option. It gave a error.The problem deduced is... All the JSP files include another JSP file i.e, ImagePath.jsp which contains <% org.apache.struts.util.PropertyMessageResources _resBun

jspc -compiler switch

Hello Dev, I've read the posting guidelines for the list, the submission guidelines for jakarta, and the archives for the tomcat-dev. I'm still not quite sure of sending in a diff for my change, etc. Please be kind :) We've been using the jspc co

jspc - more patch

Hi to all, A coworker found some more problems with jspc encoding and provided the attached patch for 3.3.1. Thanks to take a look and apply (didn't have access to cvs via ssh for now). Regards -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-ma

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 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

Re: JspC enhancement

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

jspc packaging fails?

Hello, I'm trying the 'packaged jsp' of jspc. And I hope I understand it well. Using ant 1.5.2 and Tomcat 4.1.21: While http-getting /progs/broker/searchobject.jsp I get the next error: javax.servlet.ServletException: org/apache/jsp/searchobject_jsp (wro

jspc and index.jsp

Hi, I have managed to pre-compile my jsp's down to class files and put them in web-inf/classes. I have this entry in web.xml index.jsp index.htm index.html I have the servlet WEB-INF/classes/index.class I have the mapping: index index index /i

Re: JspC exception

Jagadeesha T wrote: Hi all, I am doing compilation using JspC.It is giving ClassCastException. parentClassLoader = (URLClassLoader)Thread.currentThread().getContextClassLoader() getContextClassLoader() will return AntClassLoader which is incompatible with URLClassLoader. Is this a bug?

Tomcat 4 and JSPC

Hello all,my name Alexey Volovoy and i'm java/xml developer , recently i start working with JSP. I was trying to use JSP command line compiler in tomcat 4.0. Got the following error 2001-01-15 11:01:49 - ERROR-the file '\snoop.jsp' generated the following genera l exception: java.util.EmptyStackE

JspC recompiles unchanged files

Hello, Does anyone know why JspC pre-compiles all jsp's, even if they have not changed? I am using Ant to pre-compile and compile my jsps, and it is frustrating that they are ALL pre-compiled every time. Is this "intended behaviour" or a bug? Many thanks, Dave

[PATCH] JspC package names

In 4.0.1, JspC commandline tool is not making package names that correspond to subdirectories in my context directory (i.e. I need "/help/testhelp.jsp" to become "help/testhelp.java" and be "package help;"). There is a setOutputInDirs method on the CommandLineCon

RE: jspc -compiler switch

erCompiler class. The diff is huge and mostly non-significant. FWIW the relevant lines are at or around 448, 1156, and 1522 of the diff file. -Original Message- From: Alan Arvesen Sent: Wednesday, April 10, 2002 2:12 PM To: [EMAIL PROTECTED] Subject: jspc -compiler switch

Jasper2: jspc and JspCompilationContext

There are few bugs in jspc, mostly related with the generation of the class name and the mangling. It seems CommandLineCtx and JspEngineContext are almost completely duplicated. I did a small change and turned JspCompilationContext into an abstract class, with all the code from

Re: jspc - more patch

Quoting Henri Gomez <[EMAIL PROTECTED]>: Oups, attachment missing : > Hi to all, > > A coworker found some more problems with jspc encoding and > provided the attached patch for 3.3.1. > > Thanks to take a look and apply (didn't have access to > cv

JspC memory leak fix

Yo Tomcatters, I have fixed the memory leak in my copy of jasper, running under tomcat 4.0.4. I modified the file org.apache.jasper.compiler.TagCache and added this, at line 130, Introspector.flushCaches(); java.beans.Introspector was taking up all the RAM. After this f

[Possible bug with jspc]

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 mor

Re: 4.1.12 JSPC question

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 t

[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

Re: JSPC refactoring/documentation

- 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. >

Re: JSPC refactoring/documentation

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 beneif

Re: JSPC refactoring/documentation

Remy Maucherat wrote: 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 cons

Re: JSPC refactoring/documentation

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 current

Re: JSPC refactoring/documentation

on 2002/11/11 10:10 AM, "Remy Maucherat" <[EMAIL PROTECTED]> wrote: > I'm now independent and unemployed, so I'm not aware of the Sun > schedules for the spec anymore :-P I'm sorry to hear that Remy. > Probably within 3-6 months given J2EE > 1.4 is in beta. The rule is we cannot release a stable

Re: JSPC refactoring/documentation

Jon Scott Stevens wrote: on 2002/11/11 10:10 AM, "Remy Maucherat" wrote: >I'm now independent and unemployed, so I'm not aware of the Sun >schedules for the spec anymore :-P I'm sorry to hear that Remy. Yeah, I miss knowing the schedule ;-) Don't worry too much, I'm on vacation at the mo

Re: JSPC refactoring/documentation

"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 real

Re: JSPC refactoring/documentation

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 refacto

Re: JSPC refactoring/documentation

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

Re: JSPC refactoring/documentation

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

Re: JSPC refactoring/documentation

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 productio

RE: JSPC refactoring/documentation

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.

Re: JSPC refactoring/documentation

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

Re: JSPC refactoring/documentation

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, espec

Re: JSPC refactoring/documentation

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

Re: JSPC refactoring/documentation

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 t

Re: JSPC refactoring/documentation

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 lis

Re: JSPC refactoring/documentation

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 an

Re: JSPC refactoring/documentation

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 >becom

Re: JSPC refactoring/documentation

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 feature

Re: jspc and index.jsp

h the uriroot or uribase attributes at compile time! Do I need to be setting these! Thanks. Matt - Original Message - From: "Lee Peik Feng" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Tuesday, March 25, 2003 10:29 AM Subject: Re: j

JSPC and TC 5?

Is there any particular reason why the jspc.sh/bat and jasper.sh/bat files are not included in Tomcat 5? I realize that Ant is the preferred way to precompile a web application, but JSPC is very convenient to use for simple sites when there's no Ant installation in place. I tested using t

possible bug in jspc

Hi, I've been chasing an inconsistency in the behaviour wrt jsp error page execution. in this case the error page is evaluated and flushed to the response in this case the error page is evaluated but is not flushed to the response I checked the struts tags and they're fine, I als

[PATH} Jspc can't handle taglibs

public String getRealPath(String path) { if (myResourceBaseURL == null) { return null; } if (!myResourceBaseURL.getProtocol().startsWith("file")) { return null; } try { String theRealPath = getResou

Info on customizing jspc - jasper

I wanted to use JspC to generate a java program (not exactly a servlet) which writes its output to a file on the disk instead of the HttpServletResponse's JspWriter. In practice, i just need to customize the fixed parts of the generated code like: public class Foo extends HttpJspBase

RE: [PATCH] JspC package names

I think this has been fixed with the patch to correct bug 5471. That changes how package names are generated in CommandLineContext. I'm glad to see someone else is using jspc. It's been broken so often, I thought I was the only one. > -Original Message- > From: Mik

Re: [PATCH] JspC package names

Cool... Looks like I fell victim to the File.separator vs. URI problem that you mention in the bug too :) ... I know what you mean about poor jspc being left hanging -- I've been using a heavily tweaked/patched 3.2 version for the longest time. It seems to be a little better in 4.0 no

JSPC bug with pacakge option

Seems like im hitting a bug in the class org.apache.jasper.JspC When i run the jspc without any package specified it works fine. However when i specify the package with option "-p jsp" i get .java files for each .jsp files created with package specified as "package jsp.;"

Re: Jasper2: jspc and JspCompilationContext

[EMAIL PROTECTED] wrote: > There are few bugs in jspc, mostly related with the generation of the > class name and the mangling. Ooops, sorry, I thought I got it right. At least for the examples webapp, it did appear to work good. It is quite hard to un-spaghetti the code without b

Re: Jasper2: jspc and JspCompilationContext

On Thu, 13 Jun 2002, Remy Maucherat wrote: > [EMAIL PROTECTED] wrote: > > There are few bugs in jspc, mostly related with the generation of the > > class name and the mangling. > > Ooops, sorry, I thought I got it right. At least for the examples > webapp, it did ap

Re: Jasper2: jspc and JspCompilationContext

[EMAIL PROTECTED] wrote: > On Thu, 13 Jun 2002, Remy Maucherat wrote: > > >>[EMAIL PROTECTED] wrote: >> >>>There are few bugs in jspc, mostly related with the generation of the >>>class name and the mangling. >> >>Ooops, sorry, I thought I go

Jasper2: JspFactory problems with jspc

It seems the factory is set in JspRuntimeContext, which is never called if we pre-compile the jsps. I'm almost done with refactoring the JspC, it seems to work fine (except this one). Can I move this to HttpJspBase ( since the class will be loaded allways, including for jspc com

jspc patch for TC 3.3.2

Hi, One of my coworker have some problems with jspc when included jsp got a relative path. Find attached a possible patch. Thanks to comment and commit if valid. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD

Re: [Possible bug with jspc]

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 t

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 instead. This was probably done as a

Antw: [VOTE] Proposed jspc refactoring

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

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

Re: [VOTE] Proposed jspc refactoring

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

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

Re: [VOTE] Proposed jspc refactoring

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,

RE: [VOTE] Proposed jspc refactoring

> > > +1 [ ] Remove the options > -1 [X] Do not remove the options > 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 ou

Re: [VOTE] Proposed jspc refactoring

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

Re: [VOTE] Proposed jspc refactoring

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

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: I'm using a similar way with

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. Actual

RE: [VOTE] Proposed jspc refactoring

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 clar

Re: [VOTE] Proposed jspc refactoring

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 ;) -- T

Re: [VOTE] Proposed jspc refactoring

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

Re: [VOTE] Proposed jspc refactoring

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: For additional commands, e-mail:

Re: [VOTE] Proposed jspc refactoring

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 thi

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 will not formally vote on this, because I've been inactive in this project for so l

Re: [VOTE] Proposed jspc refactoring

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 ref

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 compil

Re: [VOTE] Proposed jspc refactoring

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

RE: [VOTE] Proposed jspc refactoring

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 h

Re: [VOTE] Proposed jspc refactoring

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

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

Re: [VOTE] Proposed jspc refactoring

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 no

RE: [VOTE] Proposed jspc refactoring

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

Re: [VOTE] Proposed jspc refactoring

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

Re: [VOTE] Proposed jspc refactoring

nown ;-) Just use the jspc task in ant. My understanding is that ant's 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 u

Re: [VOTE] Proposed jspc refactoring

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 portab

Re: [VOTE] Proposed jspc refactoring

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

Re: [VOTE] Proposed jspc refactoring

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 >

JspC compile JSP with JSTL

I just wonder if anyone have done this before. I am using JspC to compile JSP from the command line. It was working OK until I tried to use JSTL. As soon as I add the following lines to the to be compiled JSP <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core"; %>

Re: Info on customizing jspc - jasper

; Sent: Tuesday, November 27, 2001 10:32 AM Subject: Info on customizing jspc - jasper > I wanted to use JspC to generate a java program (not exactly a servlet) > which writes its output to a file on the disk instead of the > HttpServletResponse's JspWriter. > > In practice, i just

Re: Info on customizing jspc - jasper

gt; Sent: Tuesday, November 27, 2001 10:32 AM Subject: Info on customizing jspc - jasper > I wanted to use JspC to generate a java program (not exactly a servlet) > which writes its output to a file on the disk instead of the > HttpServletResponse's JspWriter. > > In practice,

Re: Info on customizing jspc - jasper

Thanks Alberto - Original Message - From: "Bill Barker" <[EMAIL PROTECTED]> To: "Tomcat Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, November 27, 2001 8:27 PM Subject: Re: Info on customizing jspc - jasper > This is off-topic for the dev list. You&#

  1   2   3   4   5   >