RE: Pre-compiled JSPs?
Hi Tim, Sorry, I'm sure I'm being a bit dense but I seem to be missing something important here. Are the jspf files included (embedded) into the class file when Jasper compiles the jsp files to java? Essentially, the compiled class file will include the original jsp and also the fragment? Thanks for your help! Richard. -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: 06 September 2005 17:01 To: Tomcat Users List Subject: Re: Pre-compiled JSPs? There is no need to turn jspf into classes. The jspf are included by real jsp files. Those jsp files are turned into the class files. -Tim Richard Burman wrote: Tim, Is there no way of turning the fragment (jspf) file into .class files or do they need to remain as JSPs? Cheers, Richard. -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: 06 September 2005 16:14 To: Tomcat Users List Subject: Re: Pre-compiled JSPs? From the jasper task all the [valid] jsp's are turned into java files and compiled into class files. Those class files need to be a jar file in WEB-INF/lib or inside WEB-INF/classes. The jasper task can also rewrite web.xml so that all the mappings from the JSP -- class file are taken care of. Once all the jsp's are compiled and mapped in web.xml. They can be deleted from the deployment war file (or dir). -Tim Richard Burman wrote: Hi Tim, Yeah, that's my exact issue, except the pages somewhat more complicated than your example. ;o) I've tried renaming one of them to jspf and, unsurprisingly, it has been ignored by the JSP compiler. I'll have to take your word that it would still work in the parent (once the reference had been changed to point to jspf, not jsp) as I don't have a test bed up and running at the moment. Okay, so we've ascertained how to avoid the 'fragments' being compiled because they're effectively not valid JSP pages because they use beans that are never declared within themselves. The 'parent' page will compile because it has all it needs to be compiled but the fragment cannot be compiled without the presence of the parent. Does this mean that I can only include the 'parent' JSPs in my JAR file and included in my web.xml? Do I have to keep the fragments as raw JSPs in my webapp, then? I'd really rather get them all together in a JAR, if possible, which is why I'm on this voyage of discovery! :o) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pre-compiled JSPs?
Yes, think of jspf like .h files in c. You don't compile .h files, but .c files include .h files at compile time. -Tim Richard Burman wrote: Hi Tim, Sorry, I'm sure I'm being a bit dense but I seem to be missing something important here. Are the jspf files included (embedded) into the class file when Jasper compiles the jsp files to java? Essentially, the compiled class file will include the original jsp and also the fragment? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pre-compiled JSPs? - Solved. Thanks!
Right, I get it now. Thanks for all your help Tim, Darryl and Nicolas! Happy Tomcat-ing, Richard. -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: 07 September 2005 12:15 To: Tomcat Users List Subject: Re: Pre-compiled JSPs? Yes, think of jspf like .h files in c. You don't compile .h files, but .c files include .h files at compile time. -Tim Richard Burman wrote: Hi Tim, Sorry, I'm sure I'm being a bit dense but I seem to be missing something important here. Are the jspf files included (embedded) into the class file when Jasper compiles the jsp files to java? Essentially, the compiled class file will include the original jsp and also the fragment? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pre-compiled JSPs?
Hi Nicolas,
Thanks for your reply, I really appreciate your help. I'm not sure I
fully understand your solution. I see now that the webXmlFragment
provides a convenient way to generate the XML needed for the Servlets
but that have bizarre names.
Let's say I have a jsp:
/RichardsApp/DoSomething.jsp
Running Jasper at it provides a java file:
/RichardsApp/DoSomething_jsp.java
Then the Servlet definition would be:
servlet
servlet-nameRichardsApp.DoSomething_jsp/servlet-name
servlet-classRichardsApp.DoSomething_jsp/servlet-class
/servlet
The way to reference my JSP used to be:
http://myserver:8080/RichardsApp/DoSomething.jsp
What would the new reference be?
http://myserver:8080/RichardsApp/DoSomething_jsp
or
http://myserver:8080/RichardsApp/DoSomething
Have I missed something obvious?
Thanks for your help!
Richard.
-Original Message-
From: Karasek-XID, Nicolas [mailto:[EMAIL PROTECTED]
Sent: 05 September 2005 12:04
To: Tomcat Users List
Subject: RE: Pre-compiled JSPs?
Hi,
You need to insert in your web.xml the reference to the precompiled
servlets. Jasper can generate a web.xml fragment when turning JSP into
servlets. You can then insert the fragment into your web.xml
Something like this with ant:
!-- turn jsp into servlets --
jasper2 verbose=0
package=your.package
validateXml=false
uriroot=${webapp.path}
webXmlFragment=generated-web.xml
outputDir=${webapp.path}/WEB-INF/src /
!-- Load the precompiled snippet into a property --
loadfile property=precompiled
srcFile= generated-web.xml
encoding=ISO-8859-1 /
!-- Now replace the web.xml with a predefined snippet --
!-- copy web.xml --
replace file=web.xml value=${precompiled}
replacetokenlt;!-- jsp-servlets will be inserted here - do not remove
this line --gt;/replacetoken
/replace
-Original Message-
From: Richard Burman [mailto:[EMAIL PROTECTED]
Sent: lundi 5 septembre 2005 12:44
To: Tomcat Users List
Subject: Pre-compiled JSPs?
Hi everyone,
I have a fairly elaborate problem but hope that some people out there
can help with it.
I am trying to take a large webapp and create pre-compiled JSPs. We
already compile the java into class files, then package in JARs, then
finally a WAR, but we would like to be able to package the JSPs into a
neat package, too.
The first hurdle was trying to circumvent the issue of when JSPs include
each other and a bean is used in both JSPs but can only be declared once
when the JSPs are combined. Thus, you have to leave out the bean
declaration in the second JSP but then it will not compile on it's own
because it has no knowledge of the bean. Fortunately, in the recent
Tomcat releases, it's possible to use the flag
'errorOnUseBeanInvalidClassAttribute' to ignore this problem.
Once the JSPs have been turned into Java classes by Jasper2, it's not
too hard to compile them into class files. But how do you deploy these
compiled classes so that Tomcat knows to use them? If the Whatever.jsp
file doesn't exist, how does Tomcat know where or how to find the
compiled JSP file? Should I put them in a JAR and deploy somewhere? Do I
need to change the web.xml or similar to inform Tomcat about this?
If anyone has any suggestions, advice or solutions to this, I would be
eternally grateful! :)
Thanks,
Richard.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pre-compiled JSPs?
What you see looks like normal jasper name mangling of generated pages. You use: http://myserver:8080/RichardsApp/DoSomething.jsp I presume there is also a generated mapping entry, that you may have overlooked: servlet-mapping servlet-nameRichardsApp.DoSomething_jsp/servlet-name url-pattern/DoSomething.jsp/url-pattern /servlet-mapping Richard Burman wrote: Hi Nicolas, Thanks for your reply, I really appreciate your help. I'm not sure I fully understand your solution. I see now that the webXmlFragment provides a convenient way to generate the XML needed for the Servlets but that have bizarre names. Let's say I have a jsp: /RichardsApp/DoSomething.jsp Running Jasper at it provides a java file: /RichardsApp/DoSomething_jsp.java Then the Servlet definition would be: servlet servlet-nameRichardsApp.DoSomething_jsp/servlet-name servlet-classRichardsApp.DoSomething_jsp/servlet-class /servlet The way to reference my JSP used to be: http://myserver:8080/RichardsApp/DoSomething.jsp What would the new reference be? http://myserver:8080/RichardsApp/DoSomething_jsp or http://myserver:8080/RichardsApp/DoSomething Have I missed something obvious? Thanks for your help! Richard. -- Darryl L. Miles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pre-compiled JSPs?
Eureka! I get it now. :) Indeed, I hadn't noticed the servlet-mapping section down the bottom. I looked at the xml and foolishly assumed that it merely repeated all the way to the bottom. Now that you've pointed out that, it all makes sense. Thanks for all your help, I shall have a play and hopefully have new, sparkly, compiled JSPs soon! Richard. -Original Message- From: Darryl L. Miles [mailto:[EMAIL PROTECTED] Sent: 06 September 2005 12:33 To: Tomcat Users List Subject: Re: Pre-compiled JSPs? What you see looks like normal jasper name mangling of generated pages. You use: http://myserver:8080/RichardsApp/DoSomething.jsp I presume there is also a generated mapping entry, that you may have overlooked: servlet-mapping servlet-nameRichardsApp.DoSomething_jsp/servlet-name url-pattern/DoSomething.jsp/url-pattern /servlet-mapping Richard Burman wrote: Hi Nicolas, Thanks for your reply, I really appreciate your help. I'm not sure I fully understand your solution. I see now that the webXmlFragment provides a convenient way to generate the XML needed for the Servlets but that have bizarre names. Let's say I have a jsp: /RichardsApp/DoSomething.jsp Running Jasper at it provides a java file: /RichardsApp/DoSomething_jsp.java Then the Servlet definition would be: servlet servlet-nameRichardsApp.DoSomething_jsp/servlet-name servlet-classRichardsApp.DoSomething_jsp/servlet-class /servlet The way to reference my JSP used to be: http://myserver:8080/RichardsApp/DoSomething.jsp What would the new reference be? http://myserver:8080/RichardsApp/DoSomething_jsp or http://myserver:8080/RichardsApp/DoSomething Have I missed something obvious? Thanks for your help! Richard. -- Darryl L. Miles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pre-compiled JSPs?
Ah, I thought it was all too good to be true. Now that I have an understanding of how to put it all together, I have given it a go but hit another snag. Remember the use of the 'errorOnUseBeanInvalidClassAttribute' flag? Well, of course, that means that when the JSPs were turned into Java classes, they ignored the fact that the bean wasn't declared in that JSP and generated the classes regardless. What about when you try to compile the Java into a .class file? Suddenly, the Java is missing a variable declaration and cannot compile the class. Is there a way round this? If not, what's the point in including the flag?! Yours, Confused of UK. ;o) -Original Message- From: Richard Burman [mailto:[EMAIL PROTECTED] Sent: 06 September 2005 13:50 To: Tomcat Users List Subject: RE: Pre-compiled JSPs? Eureka! I get it now. :) Indeed, I hadn't noticed the servlet-mapping section down the bottom. I looked at the xml and foolishly assumed that it merely repeated all the way to the bottom. Now that you've pointed out that, it all makes sense. Thanks for all your help, I shall have a play and hopefully have new, sparkly, compiled JSPs soon! Richard. -Original Message- From: Darryl L. Miles [mailto:[EMAIL PROTECTED] Sent: 06 September 2005 12:33 To: Tomcat Users List Subject: Re: Pre-compiled JSPs? What you see looks like normal jasper name mangling of generated pages. You use: http://myserver:8080/RichardsApp/DoSomething.jsp I presume there is also a generated mapping entry, that you may have overlooked: servlet-mapping servlet-nameRichardsApp.DoSomething_jsp/servlet-name url-pattern/DoSomething.jsp/url-pattern /servlet-mapping Richard Burman wrote: Hi Nicolas, Thanks for your reply, I really appreciate your help. I'm not sure I fully understand your solution. I see now that the webXmlFragment provides a convenient way to generate the XML needed for the Servlets but that have bizarre names. Let's say I have a jsp: /RichardsApp/DoSomething.jsp Running Jasper at it provides a java file: /RichardsApp/DoSomething_jsp.java Then the Servlet definition would be: servlet servlet-nameRichardsApp.DoSomething_jsp/servlet-name servlet-classRichardsApp.DoSomething_jsp/servlet-class /servlet The way to reference my JSP used to be: http://myserver:8080/RichardsApp/DoSomething.jsp What would the new reference be? http://myserver:8080/RichardsApp/DoSomething_jsp or http://myserver:8080/RichardsApp/DoSomething Have I missed something obvious? Thanks for your help! Richard. -- Darryl L. Miles - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pre-compiled JSPs?
errorOnUseBeanInvalidClassAttribute (IIRC) is a test when jsp:useBean is used without a default constructor being available. If you are using include files which were as meant as compile time include fragments, rename them (the include files) to jspf and they will be ignored by the jsp compiler. -Tim Richard Burman wrote: Ah, I thought it was all too good to be true. Now that I have an understanding of how to put it all together, I have given it a go but hit another snag. Remember the use of the 'errorOnUseBeanInvalidClassAttribute' flag? Well, of course, that means that when the JSPs were turned into Java classes, they ignored the fact that the bean wasn't declared in that JSP and generated the classes regardless. What about when you try to compile the Java into a .class file? Suddenly, the Java is missing a variable declaration and cannot compile the class. Is there a way round this? If not, what's the point in including the flag?! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pre-compiled JSPs?
Sorry, I don't understand. How will my JSP compile at all if a section (fragment) is ignored and, presumably, omitted from the resulting java file? -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: 06 September 2005 15:05 To: Tomcat Users List Subject: Re: Pre-compiled JSPs? errorOnUseBeanInvalidClassAttribute (IIRC) is a test when jsp:useBean is used without a default constructor being available. If you are using include files which were as meant as compile time include fragments, rename them (the include files) to jspf and they will be ignored by the jsp compiler. -Tim Richard Burman wrote: Ah, I thought it was all too good to be true. Now that I have an understanding of how to put it all together, I have given it a go but hit another snag. Remember the use of the 'errorOnUseBeanInvalidClassAttribute' flag? Well, of course, that means that when the JSPs were turned into Java classes, they ignored the fact that the bean wasn't declared in that JSP and generated the classes regardless. What about when you try to compile the Java into a .class file? Suddenly, the Java is missing a variable declaration and cannot compile the class. Is there a way round this? If not, what's the point in including the flag?! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pre-compiled JSPs?
For example: File a.jsp % String worldVar = null; % [EMAIL PROTECTED] file='b.jsp'% Hello %=worldVar% File b.jsp %worldVar = world% Notice b.jsp will not precompile. But then again - no one should be calling b.jsp since its not a jsp - its a jsp fragment. It should be calld b.jspf. I am guessing - your pages have a similar issue. -Tim Richard Burman wrote: Sorry, I don't understand. How will my JSP compile at all if a section (fragment) is ignored and, presumably, omitted from the resulting java file? -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: 06 September 2005 15:05 To: Tomcat Users List Subject: Re: Pre-compiled JSPs? errorOnUseBeanInvalidClassAttribute (IIRC) is a test when jsp:useBean is used without a default constructor being available. If you are using include files which were as meant as compile time include fragments, rename them (the include files) to jspf and they will be ignored by the jsp compiler. -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pre-compiled JSPs?
Hi Tim, Yeah, that's my exact issue, except the pages somewhat more complicated than your example. ;o) I've tried renaming one of them to jspf and, unsurprisingly, it has been ignored by the JSP compiler. I'll have to take your word that it would still work in the parent (once the reference had been changed to point to jspf, not jsp) as I don't have a test bed up and running at the moment. Okay, so we've ascertained how to avoid the 'fragments' being compiled because they're effectively not valid JSP pages because they use beans that are never declared within themselves. The 'parent' page will compile because it has all it needs to be compiled but the fragment cannot be compiled without the presence of the parent. Does this mean that I can only include the 'parent' JSPs in my JAR file and included in my web.xml? Do I have to keep the fragments as raw JSPs in my webapp, then? I'd really rather get them all together in a JAR, if possible, which is why I'm on this voyage of discovery! :o) I really appreciate your help with this. Regards, Richard. -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: 06 September 2005 15:57 To: Tomcat Users List Subject: Re: Pre-compiled JSPs? For example: File a.jsp % String worldVar = null; % [EMAIL PROTECTED] file='b.jsp'% Hello %=worldVar% File b.jsp %worldVar = world% Notice b.jsp will not precompile. But then again - no one should be calling b.jsp since its not a jsp - its a jsp fragment. It should be calld b.jspf. I am guessing - your pages have a similar issue. -Tim Richard Burman wrote: Sorry, I don't understand. How will my JSP compile at all if a section (fragment) is ignored and, presumably, omitted from the resulting java file? -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: 06 September 2005 15:05 To: Tomcat Users List Subject: Re: Pre-compiled JSPs? errorOnUseBeanInvalidClassAttribute (IIRC) is a test when jsp:useBean is used without a default constructor being available. If you are using include files which were as meant as compile time include fragments, rename them (the include files) to jspf and they will be ignored by the jsp compiler. -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pre-compiled JSPs?
From the jasper task all the [valid] jsp's are turned into java files and compiled into class files. Those class files need to be a jar file in WEB-INF/lib or inside WEB-INF/classes. The jasper task can also rewrite web.xml so that all the mappings from the JSP -- class file are taken care of. Once all the jsp's are compiled and mapped in web.xml. They can be deleted from the deployment war file (or dir). -Tim Richard Burman wrote: Hi Tim, Yeah, that's my exact issue, except the pages somewhat more complicated than your example. ;o) I've tried renaming one of them to jspf and, unsurprisingly, it has been ignored by the JSP compiler. I'll have to take your word that it would still work in the parent (once the reference had been changed to point to jspf, not jsp) as I don't have a test bed up and running at the moment. Okay, so we've ascertained how to avoid the 'fragments' being compiled because they're effectively not valid JSP pages because they use beans that are never declared within themselves. The 'parent' page will compile because it has all it needs to be compiled but the fragment cannot be compiled without the presence of the parent. Does this mean that I can only include the 'parent' JSPs in my JAR file and included in my web.xml? Do I have to keep the fragments as raw JSPs in my webapp, then? I'd really rather get them all together in a JAR, if possible, which is why I'm on this voyage of discovery! :o) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pre-compiled JSPs?
Tim, Is there no way of turning the fragment (jspf) file into .class files or do they need to remain as JSPs? Cheers, Richard. -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: 06 September 2005 16:14 To: Tomcat Users List Subject: Re: Pre-compiled JSPs? From the jasper task all the [valid] jsp's are turned into java files and compiled into class files. Those class files need to be a jar file in WEB-INF/lib or inside WEB-INF/classes. The jasper task can also rewrite web.xml so that all the mappings from the JSP -- class file are taken care of. Once all the jsp's are compiled and mapped in web.xml. They can be deleted from the deployment war file (or dir). -Tim Richard Burman wrote: Hi Tim, Yeah, that's my exact issue, except the pages somewhat more complicated than your example. ;o) I've tried renaming one of them to jspf and, unsurprisingly, it has been ignored by the JSP compiler. I'll have to take your word that it would still work in the parent (once the reference had been changed to point to jspf, not jsp) as I don't have a test bed up and running at the moment. Okay, so we've ascertained how to avoid the 'fragments' being compiled because they're effectively not valid JSP pages because they use beans that are never declared within themselves. The 'parent' page will compile because it has all it needs to be compiled but the fragment cannot be compiled without the presence of the parent. Does this mean that I can only include the 'parent' JSPs in my JAR file and included in my web.xml? Do I have to keep the fragments as raw JSPs in my webapp, then? I'd really rather get them all together in a JAR, if possible, which is why I'm on this voyage of discovery! :o) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Pre-compiled JSPs?
There is no need to turn jspf into classes. The jspf are included by real jsp files. Those jsp files are turned into the class files. -Tim Richard Burman wrote: Tim, Is there no way of turning the fragment (jspf) file into .class files or do they need to remain as JSPs? Cheers, Richard. -Original Message- From: Tim Funk [mailto:[EMAIL PROTECTED] Sent: 06 September 2005 16:14 To: Tomcat Users List Subject: Re: Pre-compiled JSPs? From the jasper task all the [valid] jsp's are turned into java files and compiled into class files. Those class files need to be a jar file in WEB-INF/lib or inside WEB-INF/classes. The jasper task can also rewrite web.xml so that all the mappings from the JSP -- class file are taken care of. Once all the jsp's are compiled and mapped in web.xml. They can be deleted from the deployment war file (or dir). -Tim Richard Burman wrote: Hi Tim, Yeah, that's my exact issue, except the pages somewhat more complicated than your example. ;o) I've tried renaming one of them to jspf and, unsurprisingly, it has been ignored by the JSP compiler. I'll have to take your word that it would still work in the parent (once the reference had been changed to point to jspf, not jsp) as I don't have a test bed up and running at the moment. Okay, so we've ascertained how to avoid the 'fragments' being compiled because they're effectively not valid JSP pages because they use beans that are never declared within themselves. The 'parent' page will compile because it has all it needs to be compiled but the fragment cannot be compiled without the presence of the parent. Does this mean that I can only include the 'parent' JSPs in my JAR file and included in my web.xml? Do I have to keep the fragments as raw JSPs in my webapp, then? I'd really rather get them all together in a JAR, if possible, which is why I'm on this voyage of discovery! :o) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Pre-compiled JSPs?
Hi everyone, I have a fairly elaborate problem but hope that some people out there can help with it. I am trying to take a large webapp and create pre-compiled JSPs. We already compile the java into class files, then package in JARs, then finally a WAR, but we would like to be able to package the JSPs into a neat package, too. The first hurdle was trying to circumvent the issue of when JSPs include each other and a bean is used in both JSPs but can only be declared once when the JSPs are combined. Thus, you have to leave out the bean declaration in the second JSP but then it will not compile on it's own because it has no knowledge of the bean. Fortunately, in the recent Tomcat releases, it's possible to use the flag 'errorOnUseBeanInvalidClassAttribute' to ignore this problem. Once the JSPs have been turned into Java classes by Jasper2, it's not too hard to compile them into class files. But how do you deploy these compiled classes so that Tomcat knows to use them? If the Whatever.jsp file doesn't exist, how does Tomcat know where or how to find the compiled JSP file? Should I put them in a JAR and deploy somewhere? Do I need to change the web.xml or similar to inform Tomcat about this? If anyone has any suggestions, advice or solutions to this, I would be eternally grateful! :) Thanks, Richard. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Pre-compiled JSPs?
Hi,
You need to insert in your web.xml the reference to the precompiled
servlets. Jasper can generate a web.xml fragment when turning JSP into
servlets. You can then insert the fragment into your web.xml
Something like this with ant:
!-- turn jsp into servlets --
jasper2 verbose=0
package=your.package
validateXml=false
uriroot=${webapp.path}
webXmlFragment=generated-web.xml
outputDir=${webapp.path}/WEB-INF/src /
!-- Load the precompiled snippet into a property --
loadfile property=precompiled
srcFile= generated-web.xml
encoding=ISO-8859-1 /
!-- Now replace the web.xml with a predefined snippet --
!-- copy web.xml --
replace file=web.xml value=${precompiled}
replacetokenlt;!-- jsp-servlets will be inserted here - do not remove
this line --gt;/replacetoken
/replace
-Original Message-
From: Richard Burman [mailto:[EMAIL PROTECTED]
Sent: lundi 5 septembre 2005 12:44
To: Tomcat Users List
Subject: Pre-compiled JSPs?
Hi everyone,
I have a fairly elaborate problem but hope that some people out there
can help with it.
I am trying to take a large webapp and create pre-compiled JSPs. We
already compile the java into class files, then package in JARs, then
finally a WAR, but we would like to be able to package the JSPs into a
neat package, too.
The first hurdle was trying to circumvent the issue of when JSPs include
each other and a bean is used in both JSPs but can only be declared once
when the JSPs are combined. Thus, you have to leave out the bean
declaration in the second JSP but then it will not compile on it's own
because it has no knowledge of the bean. Fortunately, in the recent
Tomcat releases, it's possible to use the flag
'errorOnUseBeanInvalidClassAttribute' to ignore this problem.
Once the JSPs have been turned into Java classes by Jasper2, it's not
too hard to compile them into class files. But how do you deploy these
compiled classes so that Tomcat knows to use them? If the Whatever.jsp
file doesn't exist, how does Tomcat know where or how to find the
compiled JSP file? Should I put them in a JAR and deploy somewhere? Do I
need to change the web.xml or similar to inform Tomcat about this?
If anyone has any suggestions, advice or solutions to this, I would be
eternally grateful! :)
Thanks,
Richard.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
timeout + SingleSignOn + pre-compiled JSPs
Hi, I'm using TC 5.0.28 running 3 WARs with SingleSignOn feature. I also have code that modify the user's timeout for authenticated users only. (Anonymous have 5 minutes and authenticated users have 1 hour). It has been worked for a year without problems! Recently I'm getting short (5 minutes) timeouts when changing contexts even for authenticated users...Since we haven't modified our apps, the only suspect I could identify (so far) is our deployment schema - We've just changed our deployments from exploded files to 3 WAR files with pre-compiled jsps using the Tomcat Deployer... Is there anyone with the same problem? Is it possible to get into timeout problems using WAR instead of files? Thanks in advance... Paulo Alvim Powerlogic - Brazil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
404 Error when accessing pre-compiled JSPs
Hello everyone, I am attempting to deploy pre-compiled jsps in Tomcat 4.1.18 (I can't upgrade, I'm stuck with 4.1.18). I've searched the archive extensively and found that I am doing all the things suggested, but I still cannot seem to find any of my web pages. I'm wondering if any of my steps are wrong and I'm just missing something. This is what I've accomplished so far: 1. Used JSPC to precompile all my jsp's and include their subdirectory in their package statements (i.e. if a jsp exist in myApp/myDir I create a package statement of package com.mycompany.myApp.myDir; for that jsp. 2. I compile the generated .java file into a class file. I make the output directory for the compile my WEB-INF/classes directory so the javac command takes care of creating all the subdirectories based on the package statement of each .java file. 3. I copy the contents of the generated web.xml fragments, merge them into one file (with proper ordering, servlet declarations first, servlet mapping after them, etc.) and then merge this into my existing web.xml file. 4. I then remove all my .jsp files, wipe out everything under my work/Standalone/localhost directory, and restart Tomcat. When I try to access my first page (http://myserver:8080/pt/logon.jsp) I get a 404: Requested resource is not available. Here are a few things I've noticed and have questions about: 1. In my servlet declaration statement can I name my servlet the same as the class name? i.e. if my jsp compiles to com.mycompany.myApp.subDir.anotherSubDir.myclass_jsp can my servlet declaration look like this: servlet servlet-namecom.mycompany.myApp.subDir.anotherSubDir.myclass_jsp /servlet-name servlet-classcom.mycompany.myApp.subDir.anotherSubDir.myclass_jsp /servlet-class /servlet 2. Just to make sure (since I know all the examples show this already), you DO NOT want to include your applications name in the url-pattern of a servlet mapping, correct? In other words, if my application is under webapps/myApp then I want my servlet map to say: servlet-mapping servlet-namecom.mycompany.myApp.subDir.anotherSubDir.myclass_jsp /servlet-name url-pattern/subDir/anotherSubDir/myclass.jsp/url-pattern /servlet-mapping NOT servlet-mapping servlet-namecom.mycompany.subDir.anotherSubDir.myclass_jsp /servlet-name url-pattern/myApp/subDir/anotherSubDir/myclass.jsp/url-pattern /servlet-mapping I feel like I'm really close to getting this running, so this last stuff is very frustrating. Any help would be greatly appreciated. Thanks, Jason __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 404 Error when accessing pre-compiled JSPs
Ah ha! As it turns out, the /web-app end tag in my web.xml file got chopped off during the merge of web.xml fragments. I put this back on and everything seems to work... except one thing: We have some JSP files that get autogenerated by a development tool we're using. Most of these JSPs compile fine, but there are a number that end up as zero length .java files after compiling them with jspc. Is there any reason why jspc might create empty .java files for what look to be relatively simple, but correct, .jsp files? --- Jason Palmatier [EMAIL PROTECTED] wrote: Hello everyone, I am attempting to deploy pre-compiled jsps in Tomcat 4.1.18 (I can't upgrade, I'm stuck with 4.1.18). I've searched the archive extensively and found that I am doing all the things suggested, but I still cannot seem to find any of my web pages. I'm wondering if any of my steps are wrong and I'm just missing something. This is what I've accomplished so far: 1. Used JSPC to precompile all my jsp's and include their subdirectory in their package statements (i.e. if a jsp exist in myApp/myDir I create a package statement of package com.mycompany.myApp.myDir; for that jsp. 2. I compile the generated .java file into a class file. I make the output directory for the compile my WEB-INF/classes directory so the javac command takes care of creating all the subdirectories based on the package statement of each .java file. 3. I copy the contents of the generated web.xml fragments, merge them into one file (with proper ordering, servlet declarations first, servlet mapping after them, etc.) and then merge this into my existing web.xml file. 4. I then remove all my .jsp files, wipe out everything under my work/Standalone/localhost directory, and restart Tomcat. When I try to access my first page (http://myserver:8080/pt/logon.jsp) I get a 404: Requested resource is not available. Here are a few things I've noticed and have questions about: 1. In my servlet declaration statement can I name my servlet the same as the class name? i.e. if my jsp compiles to com.mycompany.myApp.subDir.anotherSubDir.myclass_jsp can my servlet declaration look like this: servlet servlet-namecom.mycompany.myApp.subDir.anotherSubDir.myclass_jsp /servlet-name servlet-classcom.mycompany.myApp.subDir.anotherSubDir.myclass_jsp /servlet-class /servlet 2. Just to make sure (since I know all the examples show this already), you DO NOT want to include your applications name in the url-pattern of a servlet mapping, correct? In other words, if my application is under webapps/myApp then I want my servlet map to say: servlet-mapping servlet-namecom.mycompany.myApp.subDir.anotherSubDir.myclass_jsp /servlet-name url-pattern/subDir/anotherSubDir/myclass.jsp/url-pattern /servlet-mapping NOT servlet-mapping servlet-namecom.mycompany.subDir.anotherSubDir.myclass_jsp /servlet-name url-pattern/myApp/subDir/anotherSubDir/myclass.jsp/url-pattern /servlet-mapping I feel like I'm really close to getting this running, so this last stuff is very frustrating. Any help would be greatly appreciated. Thanks, Jason __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Using Pre-Compiled JSPs.
Hi Guys, I am finding problem in deploying / configuring precompiled jsp's on tomcat. The problem is as follows, 1. I have /opt/jakarta-tomcat-3.2.2/webapps/sample/HelloWorld.jsp 2. I start tomcat /opt/jakarta-tomcat-3.2.2/bin/startup.sh 3. It compiles HelloWorld.jsp file and creates .java and class files under work directory when I browse for the first time. they are, /opt/jakarta-tomcat-3.2.2/work/localhost_8080%2Fsample/_0002fHelloWorld_0002 ejspHelloWorld_jsp_0.java /opt/jakarta-tomcat-3.2.2/work/localhost_8080%2Fsample/_0002fHelloWorld_0002 ejspHelloWorld.class 4. Now I move /opt/jakarta-tomcat-3.2.2/webapps/sample/HelloWorld.jsp to /opt/jakarta-tomcat-3.2.2/webapps/sample/HelloWorld.jsp.bak 5. Refresh the browser, getting the following error, Not Found (404) Original request: /sample/HelloWorld.jsp Not found request: /sample/HelloWorld.jsp 6. I understand that the file is not existing, but is there any way that I can configure tomcat to access .class files directly, /opt/jakarta-tomcat-3.2.2/work/localhost_8080%2Fsample/_0002fHelloWorld_0002 ejspHelloWorld.class file. I need to configure tomcat to look for only .class files (like _0002fHelloWorld_0002ejspHelloWorld.class) because I don't have jsp files with me. Thanks in Advance ... Regards -Harish -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Possible to deploy pre-compiled JSPs with tomcat?
Is it possible to deploy pre-compiled (ie. binary) JSPs with tomcat? We're going to potentially deploying our app to many sites that we don't have full control over where we'd like to keep the source hidden. I did some digging with other engines (specifically oracle) and found this...Just wondering if the same is possible with tomcat. Thanks Dave Deployment of Binary Files Only If your JSP source is proprietary, you can avoid exposing the source by pre-translating JSP pages and deploying only the translated and compiled binary files. Pages that are pre-translated, either from previous execution in an on-demand translation scenario or by using ojspc, can be deployed to any environment that supports the OracleJSP container. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: Possible to deploy pre-compiled JSPs with tomcat?
Hm.. for this app. Could you use wget to compile the binaries and then make a war file out of the binaries? Just an idea. -Tino On Fri, 2002-05-03 at 07:07, Dave North wrote: Is it possible to deploy pre-compiled (ie. binary) JSPs with tomcat? We're going to potentially deploying our app to many sites that we don't have full control over where we'd like to keep the source hidden. I did some digging with other engines (specifically oracle) and found this...Just wondering if the same is possible with tomcat. Thanks Dave Deployment of Binary Files Only If your JSP source is proprietary, you can avoid exposing the source by pre-translating JSP pages and deploying only the translated and compiled binary files. Pages that are pre-translated, either from previous execution in an on-demand translation scenario or by using ojspc, can be deployed to any environment that supports the OracleJSP container. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
using pre-compiled JSPs
Hello, I would like to know whether pre-compiled JSPs is a conventional way for deploying JSPs at the customers sites? Are there any disadvantages with this approach? Thanks, Eitan Ben-Noach
RE: using pre-compiled JSPs
I like it for two reasons: 1. Performance 2. Don't need to distribute JavaC with the application The drawbacks as I see it: 1. Recompiling the JSPs generally works better than updating servlets for getting an update out while the server is running 2. There isn't currently any good way of merging the generated web.xml file with your web.xml file. (Making automated builds relies on inserting some special token to your web.xml file in order to do the merge, or requires building a process that reads your web.xml file, knows where the other xml file goes, and performs the merge for you). 3. It can be confusing for new developers who don't quite understand that file.jsp is really being handled by a servlet and that's why their changes to the file.jsp file are not seeming to take affect. Randy -Original Message- From: Eitan Ben-Noach [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 10, 2001 12:19 PM To: [EMAIL PROTECTED] Subject: using pre-compiled JSPs Hello, I would like to know whether pre-compiled JSPs is a conventional way for deploying JSPs at the customers sites? Are there any disadvantages with this approach? Thanks, Eitan Ben-Noach
RE: using pre-compiled JSPs
One big disadvantage is that if you have precompiled JSP's, your web application is no longer portable to different servers (possibly not even across Tomcat versions, although I'm not sure). The reason is that the JSP spec does not include any guidelines for naming or implementing the generated servlet, i.e. it's implementation dependent. On the other hand, you could take the generated servlet, put it into the WEB-INF/classes directory, and add a url mapping to the web.xml file, but even there, you would want to check the generated servlet to make sure it wasn't using container-dependent code. Greg Trasuk, President StratusCom Manufacturing Systems Inc. - We use technology to turn information into profits on your plant floor. http://stratuscom.ca -Original Message- From: Eitan Ben-Noach [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 10, 2001 12:19 PM To: [EMAIL PROTECTED] Subject: using pre-compiled JSPs Hello, I would like to know whether pre-compiled JSPs is a conventional way for deploying JSPs at the customers sites? Are there any disadvantages with this approach? Thanks, Eitan Ben-Noach winmail.dat
RE: using pre-compiled JSPs
-Original Message- From: Greg Trasuk [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 10, 2001 3:06 PM To: [EMAIL PROTECTED] Subject: RE: using pre-compiled JSPs One big disadvantage is that if you have precompiled JSP's, your web application is no longer portable to different servers (possibly not even across Tomcat versions, although I'm not sure). The reason is that the JSP spec does not include any guidelines for naming or implementing the generated servlet, i.e. it's implementation dependent. On the other hand, you could take the generated servlet, put it into the WEB-INF/classes directory, and add a url mapping to the web.xml file, but even there, you would want to check the generated servlet to make sure it wasn't using container-dependent code. I don't believe that this is correct. If you use JSPC with the right arguments it will produce a web.xml file fragment that includes the servlet mappings and will produce standard .java files that you will need to compile to .class files. The only reason that you would have an incompability is if the other container didn't implement the spec correctly (which you would have if you moved the JSPs anyways). Randy
