Why the unchanged JSPs are compiling every time when I start debugger

I found that everytime I start the debugger, IDEA cleans the CALALINA_BASE/work/_scratchdir so that every JSP page needs to be parsed and compiled again, even when it is not changed since last run.
This feature greatly slows down my job. I wonder if there is a way to void this? As far as I know, when Tomcat starts again , it will see if the Compiled JSP classes are older than the JSP source, and passed by those are not.

16 comments

You must have validate JSPs on build. You can check that off in the
module's j2ee preferences.

R


On 10/22/04 6:59 AM, in article
13360699.1098442749234.JavaMail.itn@is.intellij.net, "warbaby"
<no_mail@jetbrains.com> wrote:

I found that everytime I start the debugger, IDEA cleans the
CALALINA_BASE/work/_scratchdir so that every JSP page needs to be parsed and
compiled again, even when it is not changed since last run.
This feature greatly slows down my job. I wonder if there is a way to void
this? As far as I know, when Tomcat starts again , it will see if the
Compiled JSP classes are older than the JSP source, and passed by those are
not.


0

No! How could I !
hehe, my project have over 1000 JSPs, it'll take some hours to Validator them all.
I investigate the situation once more yesterday. I found out that when idea start debugging webapp, it first creates a "UNIQUE dir" in IDEA installation path. The dir contain a "conf" dir, where server.xml and web.xml are placed in.
Then idea set the CATALINA_BASE to the "UNIQUE" dir and use the generated configuration to start the container.
After that it performs an unreasonable action : to delete the "work" directory which contains the generated java and class file for JSPs. I think it is hardcored in IDEA for this, at least i didn't found any settings can change it.
This results in the slowness. Assume that your webapps login-page contains serveral struts tiles, and you need to Parse and Compile all of them when you restart debugger and login. Only after that, could you get to the page you want to debug.

Have I made myself clear? Sorry for my poor poor english.
-_-b

0

i must declare that i didn't mean that idea compiles jsp for me on building the project. I mean that after start the debugger, and when the servlet container (tomcat) is already running, and when you open a page in your browser for the first time, the JSPs is compiled by the CONTAINER because IDEA clearned the cache.

0

Hi,

IDEA removes the scratch dir where Jasper compilation results are stored
in order not to see stale compilation results (Jaspers seems check
only file timestamps so jsp with includes could be incorrect)

warbaby wrote:

No! How could I !
hehe, my project have over 1000 JSPs, it'll take some hours to Validator them all.
I investigate the situation once more yesterday. I found out that when idea start debugging webapp, it first creates a "UNIQUE dir" in IDEA installation path. The dir contain a "conf" dir, where server.xml and web.xml are placed in.
Then idea set the CATALINA_BASE to the "UNIQUE" dir and use the generated configuration to start the container.
After that it performs an unreasonable action : to delete the "work" directory which contains the generated java and class file for JSPs. I think it is hardcored in IDEA for this, at least i didn't found any settings can change it.
This results in the slowness. Assume that your webapps login-page contains serveral struts tiles, and you need to Parse and Compile all of them when you restart debugger and login. Only after that, could you get to the page you want to debug.

Have I made myself clear? Sorry for my poor poor english.
-_-b



--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0

I thought that "feature" was fixed with the move to Jasper2.

Norris Shelton
Sun Certified Java Programmer




Maxim Mossienko wrote:

Hi,

>

IDEA removes the scratch dir where Jasper compilation results are
stored in order not to see stale compilation results (Jaspers seems
check only file timestamps so jsp with includes could be incorrect)

>

warbaby wrote:

>
>> No! How could I !
>> hehe, my project have over 1000 JSPs, it'll take some hours to
>> Validator them all. I investigate the situation once more
>> yesterday. I found out that when idea start debugging webapp, it
>> first creates a "UNIQUE dir" in IDEA installation path. The dir
>> contain a "conf" dir, where server.xml and web.xml are placed in.
>> Then idea set the CATALINA_BASE to the "UNIQUE" dir and use the
>> generated configuration to start the container. After that it
>> performs an unreasonable action : to delete the "work" directory
>> which contains the generated java and class file for JSPs. I think it
>> is hardcored in IDEA for this, at least i didn't found any settings
>> can change it.
>> This results in the slowness. Assume that your webapps login-page
>> contains serveral struts tiles, and you need to Parse and Compile all
>> of them when you restart debugger and login. Only after that, could
>> you get to the page you want to debug.
>>
>> Have I made myself clear? Sorry for my poor poor english.
>> -_-b
>>
>
>

0

I have this also. Idea does not cache any of the compiled JSPs. Kind
of makes development slow. I understand what they are doing and why, I
just wish they could disable the behavior for TC 5.

Norris Shelton
Sun Certified Java Programmer




warbaby wrote:

>i must declare that i didn't mean that idea compiles jsp for me on building the project. I mean that after start the debugger, and when the servlet container (tomcat) is already running, and when you open a page in your browser for the first time, the JSPs is compiled by the CONTAINER because IDEA clearned the cache.

>

0

Hello Everybody Here!!
Thanks for your reply. I finally solved this problem. That isn't a tough mission. All I did is decompile the tomcatIntegration.jar and removed some lines.
The new jar can be downloaded at "http://www.jroller.com/resources/WarBaby/tomcatintegration.jar". This edition doesn't delete the work dir, and keeps the Context defined at your "TOMCAT_HOME/conf/server.xml" such as /manager and ROOT and /examples. (Those is also removed in the original plugin)

and reply to this:

_+IDEA removes the scratch dir where Jasper compilation results are stored
in order not to see stale compilation results (Jaspers seems check
only file timestamps so jsp with includes could be incorrect)+_
I really understand this, but I'd rather do the syn by myself, compared to the slowness.



Attachment(s):
tomcatIntegration.jar
0

Hi,

There is no need in decompiling of Tomcat plugin since
IntelliJ IDEA Plugin Development Package (
http://download.jetbrains.com/idea/idea-4.5.2.dev.zip) contains

  • Sources for plugins shipped with IDEA (Inspection Gadget,

Intention PowerPack, integrations for StarTeam, JSR45, Tomcat, WebLogic)

warbaby wrote:

Hello Everybody Here!!
Thanks for your reply. I finally solved this problem. That isn't a tough mission. All I did is decompile the tomcatIntegration.jar and removed some lines.
The new jar can be downloaded at "http://www.jroller.com/resources/WarBaby/tomcatintegration.jar". This edition doesn't delete the work dir, and keeps the Context defined at your "TOMCAT_HOME/conf/server.xml" such as /manager and ROOT and /examples. (Those is also removed in the original plugin)

and reply to this:

_+IDEA removes the scratch dir where Jasper compilation results are stored
in order not to see stale compilation results (Jaspers seems check
only file timestamps so jsp with includes could be incorrect)+_
I really understand this, but I'd rather do the syn by myself, compared to the slowness.



--
Best regards,
Maxim Mossienko
IntelliJ Labs / JetBrains Inc.
http://www.intellij.com
"Develop with pleasure!"

0



On 10/29/04 3:47 AM, in article
4405141.1099036032008.JavaMail.itn@is.intellij.net, "warbaby"
<no_mail@jetbrains.com> wrote:

Hello Everybody Here!!
Thanks for your reply. I finally solved this problem. That isn't a tough
mission. All I did is decompile the tomcatIntegration.jar and removed some
lines.
The new jar can be downloaded at
"http://www.jroller.com/resources/WarBaby/tomcatintegration.jar". This edition
doesn't delete the work dir, and keeps the Context defined at your
"TOMCAT_HOME/conf/server.xml" such as /manager and ROOT and /examples. (Those
is also removed in the original plugin)


These were removed because they caused startup problems, these were
requested to be removed from the group here. Not sure what is gained by
keeping them.

Also keeping the work dir used to caused old version of files to be
deployed, and while that might be your desired effect, there were some
serious side effects of it, which I have no doubt you will soon run into.
(Check this forum for what those were)

R

and reply to this:

_+IDEA removes the scratch dir where Jasper compilation results are stored
in order not to see stale compilation results (Jaspers seems check
only file timestamps so jsp with includes could be incorrect)+_
I really understand this, but I'd rather do the syn by myself, compared to the
slowness.


0

Oh, thank you! This is what i longed for!!

Hi,

There is no need in decompiling of Tomcat plugin
since
IntelliJ IDEA Plugin Development Package (
http://download.jetbrains.com/idea/idea-4.5.2.dev.zip)
contains

  • Sources for plugins shipped with IDEA

IDEA (Inspection Gadget,
Intention PowerPack, integrations for StarTeam,
JSR45, Tomcat, WebLogic)

0

Sorry, but i searched this forum for "jsp" "tomcat" and some other keywords only finding nothing that you mentioned. Could you please show me some?

The reason that I want to keep the ]]> in my original "server.xml" is mainly about the "manager application" of tomcat4.0.6. Unlike in tomcat4.1 (i don't use version 5 because of the undergoing project), the manager application is deploy using war file, and there must be a privileged="true" in the server.xml for its context. So when Idea removed the definition, it can not be used to reload my webapp.
Also for this, when I changed the servlet or struts class of my webapp, i often have to stop tomcat and restart it again (Reload changed classes is not always work). Then I suffered the "Cleaning of the cache". So I wish to change it.
In my opinion, the "Compare the timestamp of the JSPs and the Generated Java file, and ommit the unnessesary work" is the Container's Feature. Why not leave the problem just where it belongs. I know there maybe problem. Actually if you made the generated Java file's timestamp "IN THE FUTURE", nothing will happen when you modify your JSPs.
If this is the problem you mention, I think an experinced developer will soon find the problem and manually delete the "work" dir.
That's all. If you would tell me where I was wrong by the above, I will be very happy.



These were removed because they caused startup
problems, these were
requested to be removed from the group here. Not
sure what is gained by keeping them.

Also keeping the work dir used to caused old version
of files to be
deployed, and while that might be your desired
effect, there were some
serious side effects of it, which I have no doubt you
will soon run into.
(Check this forum for what those were)

0



On 10/29/04 10:49 PM, in article
31149854.1099108181013.JavaMail.itn@is.intellij.net, "warbaby"
<no_mail@jetbrains.com> wrote:

Sorry, but i searched this forum for "jsp" "tomcat" and some other
keywords only finding nothing that you mentioned. Could you please show me
some?

The reason that I want to keep the <Context> in my original "server.xml"
is mainly about the "manager application" of tomcat4.0.6. Unlike in tomcat4.1
(i don't use version 5 because of the undergoing project), the manager
application is deploy using war file, and there must be a
privileged="true" in the server.xml for its context. So when Idea
removed the definition, it can not be used to reload my webapp.
Also for this, when I changed the servlet or struts class of my webapp, i
often have to stop tomcat and restart it again (Reload changed classes is not
always work). Then I suffered the "Cleaning of the cache". So I wish to change
it.


And you can't override this setting with application specific xml file and
deploy that with your war file?

R


0

How about modifying to tomcat run panel to have a check box for these
settings and passing them to the code. That would probably be the best
solution.

Norris Shelton
Sun Certified Java Programmer




Maxim Mossienko wrote:

Hi,

>

There is no need in decompiling of Tomcat plugin since
IntelliJ IDEA Plugin Development Package (
http://download.jetbrains.com/idea/idea-4.5.2.dev.zip) contains

  • Sources for plugins shipped with IDEA (Inspection Gadget,

Intention PowerPack, integrations for StarTeam, JSR45, Tomcat, WebLogic)

>

warbaby wrote:

>
>> Hello Everybody Here!!
>> Thanks for your reply. I finally solved this problem. That isn't a
>> tough mission. All I did is decompile the tomcatIntegration.jar and
>> removed some lines.
>> The new jar can be downloaded at
>> "http://www.jroller.com/resources/WarBaby/tomcatintegration.jar".
>> This edition doesn't delete the work dir, and keeps the Context
>> defined at your "TOMCAT_HOME/conf/server.xml" such as /manager and
>> ROOT and /examples. (Those is also removed in the original plugin)
>>
>> and reply to this:
>>
>> _+IDEA removes the scratch dir where Jasper compilation results
>> are stored in order not to see stale compilation results (Jaspers
>> seems check only file timestamps so jsp with includes could be
>> incorrect)+_
>> I really understand this, but I'd rather do the syn by myself,
>> compared to the slowness.
>
>
>

0

How would I install this? Would I remove the IJ plugin and replace it
with your jar file?

Norris Shelton
Sun Certified Java Programmer




warbaby wrote:

>Oh, thank you! This is what i longed for!!
>

>
>>Hi,
>>
>>There is no need in decompiling of Tomcat plugin
>>since
>>IntelliJ IDEA Plugin Development Package (
>>http://download.jetbrains.com/idea/idea-4.5.2.dev.zip)
>>contains
>>* Sources for plugins shipped with IDEA
>>IDEA (Inspection Gadget,
>>Intention PowerPack, integrations for StarTeam,
>>JSR45, Tomcat, WebLogic)
>>
>>
>>

0

oh, just replace the jar file in \plugins\tomcatIntegration\lib with the new one, and enjoy it!
And by these days' using, i myself really enjoy it :)

0

Are you using Irida? Mine says \plugins\tomcat\lib\tomcat.jar. Will
the different names make a difference. That is why I thought I would
need to remove their whole path.


Norris Shelton
Sun Certified Java Programmer




warbaby wrote:

>oh, just replace the jar file in \plugins\tomcatIntegration\lib with the new one, and enjoy it!
>And by these days' using, i myself really enjoy it :)

>



Attachment(s):
moz-screenshot-7.jpg
0

Please sign in to leave a comment.