[Geoserver-devel] Please use Tomcat for development work! (at least while we're bug fixing)

GeoServer GeoServer Developer
1

Hey, so I have a request for this latest round of shaking out bugs.
Could everyone please use Tomcat? It's easily are most buggy servlet
container for geoserver right, and it's the obvious choice for new
people to use, so I would like it to work really well. And the only
way that is going to happen is if we all actually use it, more than
just running through the most obvious tests right before putting out a
release. The cite tests can test the core components really well, but
that's _not_ where we're having trouble. The troubles are in the web
interface. I just shook out a few bugs in SaveXmlAction, tomcat was
making nulls instead of empty lists, which caused nasty null pointer
exceptions if you didn't define a plugIns folder. I know tomcat is
substantially slower than resin, and does not do fancy reloading of
servlets, but if you use the test-ext ant target then it will nicely
delete the tomcat files for you, you just need to restart it. And I
think it's very important that we do good tomcat testing, as it is the
reference implementation of the servlet container.

Aso, JSPCompiler seems to be the thing tomcat really doesn't like. We
just got a bug about it on windows in addition to it never working on
linux. David, is there an easy way we could just not run it on Tomcat,
if you can't get it working on linux? That might be an easier
solution, since it's really just an optimization. I already replaced
tomcat with jetty for our 'recommended' servlet containers, I could
even say we steer a bit clear of it as it's slow, which will then just
be re-enforced to users when they start it up without the JSPCompiler.
After we get 1.2.0 out we can go back to our favorite servlet
containers, but for now I'd really like it if we all put in good tomcat
time.

Chris

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

2

hi

cholmes@anonymised.com wrote:

Hey, so I have a request for this latest round of shaking out bugs. Could everyone please use Tomcat? It's easily are most buggy servlet
container for geoserver right, and it's the obvious choice for new
people to use, so I would like it to work really well. And the only
way that is going to happen is if we all actually use it, more than
just running through the most obvious tests right before putting out a
release. The cite tests can test the core components really well, but
that's _not_ where we're having trouble. The troubles are in the web
interface. I just shook out a few bugs in SaveXmlAction, tomcat was
making nulls instead of empty lists, which caused nasty null pointer
exceptions if you didn't define a plugIns folder. I know tomcat is
substantially slower than resin, and does not do fancy reloading of
servlets, but if you use the test-ext ant target then it will nicely
delete the tomcat files for you, you just need to restart it. And I
think it's very important that we do good tomcat testing, as it is the
reference implementation of the servlet container.

What do you mean by fancy reloading? Tomcat does detect when a web app changes and if you think it does not you can always use the manager webapplication to reload it manually (there is even an ant file that can do that). Just drop the new file in the webapps folder and tomcat reloads it.

Aso, JSPCompiler seems to be the thing tomcat really doesn't like. We
just got a bug about it on windows in addition to it never working on
linux. David, is there an easy way we could just not run it on Tomcat,
if you can't get it working on linux? That might be an easier
solution, since it's really just an optimization. I already replaced
tomcat with jetty for our 'recommended' servlet containers, I could
even say we steer a bit clear of it as it's slow, which will then just
be re-enforced to users when they start it up without the JSPCompiler.
After we get 1.2.0 out we can go back to our favorite servlet
containers, but for now I'd really like it if we all put in good tomcat
time.

Chris

What is this JSPCompiler all about? Tomcat comes with a custom ant task that can be used to precompile JSPs. Isn't that exactly what you want?

Just curious, I may be missing something...

Simon

3

>Hey, so I have a request for this latest round of shaking out bugs.
>Could everyone please use Tomcat? It's easily are most buggy
servlet
>container for geoserver right, and it's the obvious choice for new
>people to use, so I would like it to work really well. And the only
>way that is going to happen is if we all actually use it, more than
>just running through the most obvious tests right before putting out
a
>release. The cite tests can test the core components really well,
but
>that's _not_ where we're having trouble. The troubles are in the
web
>interface. I just shook out a few bugs in SaveXmlAction, tomcat was
>making nulls instead of empty lists, which caused nasty null pointer
>exceptions if you didn't define a plugIns folder. I know tomcat is
>substantially slower than resin, and does not do fancy reloading of
>servlets, but if you use the test-ext ant target then it will nicely
>delete the tomcat files for you, you just need to restart it. And I
>think it's very important that we do good tomcat testing, as it is
the
>reference implementation of the servlet container.
>
>
What do you mean by fancy reloading? Tomcat does detect when a web
app
changes and if you think it does not you can always use the manager
webapplication to reload it manually (there is even an ant file that
can
do that). Just drop the new file in the webapps folder and tomcat
reloads it.

Yeah, I've heard that, I should probably try it out more, but I always
find myself waiting, and I don't really like to use the manager web
application. With resin you just drop it in and within a few seconds
its sure to build it up all nice for you. And resetting resin will
automatically load it up, which tomcat never seems to do for me (again,
I know I'm being biased and haven't dug completely into it, but resin
definitely performs faster, as does jetty, so it's never been super
worth it for me to dig into it. But these are good suggestions, since
I will just be testing on tomcat until 1.2.0)

>Aso, JSPCompiler seems to be the thing tomcat really doesn't like.
We
>just got a bug about it on windows in addition to it never working
on
>linux. David, is there an easy way we could just not run it on
Tomcat,
>if you can't get it working on linux? That might be an easier
>solution, since it's really just an optimization. I already
replaced
>tomcat with jetty for our 'recommended' servlet containers, I could
>even say we steer a bit clear of it as it's slow, which will then
just
>be re-enforced to users when they start it up without the
JSPCompiler.
>After we get 1.2.0 out we can go back to our favorite servlet
>containers, but for now I'd really like it if we all put in good
tomcat
>time.
>
>Chris
>
>
>
What is this JSPCompiler all about? Tomcat comes with a custom ant
task
that can be used to precompile JSPs. Isn't that exactly what you
want?

Can you run the custom ant task programmatically? Basically David wrote
a JSPCompiler that runs when starting up the web interface for
geoserver. It's really nice because it speeds things up once you're
inside. But it doesn't work quite right with tomcat, especially not on
linux. Perhaps using tomcat's built in precompiler is a good way to
go. It's possible to run within the a webapp? And if so how?
Basically we want to do the compilation for people, so that when they
start up geoserver it works fast right away. And we don't really want
to have to tell them to precompile their jsps, give them an extra step
in the install process, as we want it as easy as possible.

Just curious, I may be missing something...

Good to ask, we could very well be missing something. If you know a
good way to pre compile tomcat jsps from within the webapp we'd love to
hear it.

Chris

Simon

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

4

cholmes@anonymised.com wrote:

Hey, so I have a request for this latest round of shaking out bugs.
Could everyone please use Tomcat? It's easily are most buggy

servlet

container for geoserver right, and it's the obvious choice for new
people to use, so I would like it to work really well. And the only
way that is going to happen is if we all actually use it, more than
just running through the most obvious tests right before putting out

a

release. The cite tests can test the core components really well,

but

that's _not_ where we're having trouble. The troubles are in the

web

interface. I just shook out a few bugs in SaveXmlAction, tomcat was
making nulls instead of empty lists, which caused nasty null pointer
exceptions if you didn't define a plugIns folder. I know tomcat is
substantially slower than resin, and does not do fancy reloading of
servlets, but if you use the test-ext ant target then it will nicely
delete the tomcat files for you, you just need to restart it. And I
think it's very important that we do good tomcat testing, as it is

the

reference implementation of the servlet container.

What do you mean by fancy reloading? Tomcat does detect when a web
app
changes and if you think it does not you can always use the manager
webapplication to reload it manually (there is even an ant file that
can
do that). Just drop the new file in the webapps folder and tomcat
reloads it.

Yeah, I've heard that, I should probably try it out more, but I always
find myself waiting, and I don't really like to use the manager web
application. With resin you just drop it in and within a few seconds
its sure to build it up all nice for you. And resetting resin will
automatically load it up, which tomcat never seems to do for me (again,
I know I'm being biased and haven't dug completely into it, but resin
definitely performs faster, as does jetty, so it's never been super
worth it for me to dig into it. But these are good suggestions, since
I will just be testing on tomcat until 1.2.0)

I've just re-read the tomcat documentation. Reloading should definitely
work, at least on unix systems. I've experienced some problems with
geoserver/tomcat on windows too, but that was because I couldn't
replace the war file in the webapps directory (most likely because
geoserver did still have some files open...). Tomcat checks every few
seconds for changes and recompiles the jsps. If it does not, there
might be some missing configuration options (it's possible to disable
this behavior).

Aso, JSPCompiler seems to be the thing tomcat really doesn't like.

We

just got a bug about it on windows in addition to it never working

on

linux. David, is there an easy way we could just not run it on

Tomcat,

if you can't get it working on linux? That might be an easier
solution, since it's really just an optimization. I already

replaced

tomcat with jetty for our 'recommended' servlet containers, I could
even say we steer a bit clear of it as it's slow, which will then

just

be re-enforced to users when they start it up without the

JSPCompiler.

After we get 1.2.0 out we can go back to our favorite servlet
containers, but for now I'd really like it if we all put in good

tomcat

time.

Chris

What is this JSPCompiler all about? Tomcat comes with a custom ant
task
that can be used to precompile JSPs. Isn't that exactly what you
want?

Can you run the custom ant task programmatically? Basically David wrote
a JSPCompiler that runs when starting up the web interface for
geoserver. It's really nice because it speeds things up once you're
inside. But it doesn't work quite right with tomcat, especially not on
linux. Perhaps using tomcat's built in precompiler is a good way to
go. It's possible to run within the a webapp? And if so how? Basically we want to do the compilation for people, so that when they
start up geoserver it works fast right away. And we don't really want
to have to tell them to precompile their jsps, give them an extra step
in the install process, as we want it as easy as possible.

I'm sure you can run the compiler programmatically. One way would be to
integrate the custom ant tasks from tomcat (see the ant manual for that
"developing with ant"/"using ant task outside of ant"). Otherwise it
would certainly be possible to call the compiler directly from java code.
Maybe there's even a configuration option in tomcat that allows to
pre-compile all jsps, though I haven't seen one...

See http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jasper-howto.html for
the ant task from tomcat.

Another way to solve what you want to achieve is to use a tool that
walks through the admin website once the site is deployed.

I'd personally say, the pre-compilation is not really that important,
unless you are in a development environment. The compilation just
happens once, the first time the page is accessed. In a production
environment (where the server supposedly runs for a long time) this
does not hurt anybody. In a development environment you could add the
pre-compilation to the build steps (I guess other servlet containers
have also some kind of pre-compilation support).

The more I think about this, I think that this whole pre-compilation
should be dealt with outside of geoserver. It's a general issue
not specific to geoserver. Is it really worth the effort in face
of the problems it's causing?

If existing servlet containers do not deal well with this problem it
might be appropriate to contact the servlet containers mailing list.
This would anyway be a good idea (I'm by no means a tomcat pro... ;-).
They probably have heard about this issue before (and have found a
solution to this).

Just curious, I may be missing something...

Good to ask, we could very well be missing something. If you know a
good way to pre compile tomcat jsps from within the webapp we'd love to
hear it.

Chris

Simon

5

Quoting Simon Räss <cocoa@anonymised.com>:

cholmes@anonymised.com wrote:

>>>Hey, so I have a request for this latest round of shaking out bugs.
>>>Could everyone please use Tomcat? It's easily are most buggy

I am using Tomcat 5, richard has switched because Resin 3.X is not working
(resin 2.X is okay).

The buggyness - for all of the servlet containers - change with the version numbers.

Jody

>>>exceptions if you didn't define a plugIns folder. I know tomcat is
>>>substantially slower than resin, and does not do fancy reloading of
>>>servlets, but if you use the test-ext ant target then it will nicely

Hmm I am finding it faster for initial use, maybe the reloading of servlets is
what is causing Richard grief. His bug is that Resin stops responding - he has
not submited it yet (to my knowledge).

>>What is this JSPCompiler all about? Tomcat comes with a custom ant
>>task
>>that can be used to precompile JSPs. Isn't that exactly what you
>>want?

No it is not - that only works for Tomcat, and for the embeded servlet. The
goal here is a war, sticking precompiled results in the war ties it to a
specific servlet container.

>Can you run the custom ant task programmatically? Basically David wrote
>a JSPCompiler that runs when starting up the web interface for
>geoserver. It's really nice because it speeds things up once you're
>inside. But it doesn't work quite right with tomcat, especially not on
>linux.

The technique the JSPCompiler uses is supposed to be the correct cross platform
way of doing things. We should really just fix it.

Another way to solve what you want to achieve is to use a tool that
walks through the admin website once the site is deployed.

Um - that is what the JSPCompiler is :slight_smile:

I'd personally say, the pre-compilation is not really that important,

Chris found it to be quite important - because it defines the initial impresion
the user gets about the application. this is all about having the first screen
appear to draw quickly.

Jody

6

Am 08.04.2004 um 16:16 schrieb jgarnett@anonymised.com:

exceptions if you didn't define a plugIns folder. I know tomcat is
substantially slower than resin, and does not do fancy reloading of
servlets, but if you use the test-ext ant target then it will nicely

Hmm I am finding it faster for initial use, maybe the reloading of servlets is
what is causing Richard grief. His bug is that Resin stops responding - he has
not submited it yet (to my knowledge).

What is this JSPCompiler all about? Tomcat comes with a custom ant
task
that can be used to precompile JSPs. Isn't that exactly what you
want?

No it is not - that only works for Tomcat, and for the embeded servlet. The
goal here is a war, sticking precompiled results in the war ties it to a
specific servlet container.

Can you run the custom ant task programmatically? Basically David wrote
a JSPCompiler that runs when starting up the web interface for
geoserver. It's really nice because it speeds things up once you're
inside. But it doesn't work quite right with tomcat, especially not on
linux.

The technique the JSPCompiler uses is supposed to be the correct cross platform
way of doing things. We should really just fix it.

Another way to solve what you want to achieve is to use a tool that
walks through the admin website once the site is deployed.

Um - that is what the JSPCompiler is :slight_smile:

I don't know anything about JSPCompiler obviously :wink:

I'd personally say, the pre-compilation is not really that important,

Chris found it to be quite important - because it defines the initial impresion
the user gets about the application. this is all about having the first screen
appear to draw quickly.

Yeah, I remember these discussions on the mailing list some time ago. I understand the goal is a very easy installation of geoserver and that even includes an embeded servlet engine (jetty?).

Simon

Jody

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

7

Simon Raess wrote:

Chris found it to be quite important - because it defines the initial impresion
the user gets about the application. this is all about having the first screen
appear to draw quickly.

I'd personally say, the pre-compilation is not really that important,

Yeah, I remember these discussions on the mailing list some time ago. I understand the goal is a very easy installation of geoserver and that even includes an embeded servlet engine (jetty?).

Me too - only I think we are starting to get different directions for the "easy install" goal

Path 1) geoserver.war with instructions to drop in your servlet container
Path 2) embeded (jetty?) with ant script to start/stop (can't tell if this is a binary or source environment)

Path 2 may be targeted at new geoserver developers?

Then we have a different issue - the intial impression of the Web based user interface.
Out of the box on resin things look pretty bad for the very first page load - the screen updates as different tiles compile and run. Chris put a quick stop to this one and asked for a precompile - which we could not figure out how to do. The JSPCompiler is the solution - it basically walks the application on the very first startup offering an indication of progress. When the first page comes up after that - everything looks and acts quickly.

In the course of normal development I usually just start from the Login.do page and duck the JSPCompiler. The JSPCompiler is all about end user experience - and adds time to the compile edit debug cycle.

Time that should actually be spent - the other reason to do a precompile - is to catch JSP compile errors as part of your compile/edit/debug cycle. JSPCompiler does not address this! (It cannot hit every JSP - it just concentrates on the main ones).

There is an Eclipse resin project type that offers intergration with the resin precompiler - but really any precompile will do. The trick is we cannot ship the result in the final geoserver.war for Path 1 (Path 2 may be done).

I hope this helps everyone make sense of this issue. We have three things going on at once:
1) Two Paths for a "easy installation"
2) A User experience problem solved by JSPCompiler
3) A need to check that JSP pages actually compile

Jody

8

>> Chris found it to be quite important - because it defines the
initial
>> impresion
>> the user gets about the application. this is all about having the
>> first screen
>> appear to draw quickly.
>
> I'd personally say, the pre-compilation is not really that
important,
>
> Yeah, I remember these discussions on the mailing list some time
ago.
> I understand the goal is a very easy installation of geoserver and
> that even includes an embeded servlet engine (jetty?).
>
Me too - only I think we are starting to get different directions for
the "easy install" goal

Path 1) geoserver.war with instructions to drop in your servlet
container
Path 2) embeded (jetty?) with ant script to start/stop (can't tell if
this is a binary or source environment)

Path 2 may be targeted at new geoserver developers?

Sorry for the confusion over path 2. I would say path 2 is currently
targeted at new geoserver developers, but it's also where I'm figuring
out to do a real easy binary install. So for now it's just the source
environment, and probably will be until 1.2.1, and I don't really
expect that many people to use it. But relatively soon I will do a
binary release with jetty, and include it as one of the download
options. There will be one for linux with a shell script, and
eventually one for windows with an install shield. The idea behind
both being to skip the one still annoying step of the war install 'get
a servlet container'. They will have their own build tasks, which will
not include the full source tree, probably just a conf directory, maybe
some docs, the app, and the embedded jetty. The war will still be
distributed, for users who know already have the servlet container they
like. And the source will have it all, where you can build what you'd
like.

Then we have a different issue - the intial impression of the Web
based
user interface.
Out of the box on resin things look pretty bad for the very first
page
load - the screen updates as different tiles compile and run. Chris
put
a quick stop to this one and asked for a precompile - which we could
not
figure out how to do. The JSPCompiler is the solution - it basically
walks the application on the very first startup offering an
indication
of progress. When the first page comes up after that - everything
looks
and acts quickly.

Yes, I think the JSPCompiler is a great solution, and I still very much
believe in the importance of a precompile. If you're downloading the
war for evaluation and the web interface just crawls along (like it
does without precompilation) then you're much more likely to just move
on, try something else or wait until a faster version comes out.

In the course of normal development I usually just start from the
Login.do page and duck the JSPCompiler. The JSPCompiler is all about
end user experience - and adds time to the compile edit debug cycle.

Yeah, I do the same. And one option is to tell tomcat users to just use
the Login.do page. Though fixing it for real would be nice.

There is an Eclipse resin project type that offers intergration with
the
resin precompiler - but really any precompile will do. The trick is
we
cannot ship the result in the final geoserver.war for Path 1 (Path 2
may
be done).

I hope this helps everyone make sense of this issue. We have three
things going on at once:
1) Two Paths for a "easy installation"
2) A User experience problem solved by JSPCompiler
3) A need to check that JSP pages actually compile

Good summary Jody. And I personally think we should eventually live
with two paths for 'easy installation', some people will want the war
with their servlet container, some won't care. If it becomes a bitch
to support both we can just see which one people like more and point
others to the source.

Chris

Jody

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/