Splitting up a web app?

[Richard Evans <rd...@webtrak.co.uk>]

We have an existing web directory structure which has web pages in one place
(shared amongst several web apps), and servlet classes in a couple of other
locations (again shared).  I wanted to use tomcat with this structure but the
api 2.2 webapp mechanism seemed too restrictive.

So I added a couple of new attributes to the <Context> tag to allow for
additional class repositories and a web page page different from the
docBase. A few new methods in 

	 src/share/org/apache/tomcat/core/Context.java

and a change to a couple of methods in the same file was all that was needed.

Now, is this a bad thing?  Could it ever get into standard Tomcat?

I can send patches if anyone is interested, but I'd like to gauge how useful
the mod is.  For us it made it really practical to use tomcat.

Richard

Re: Splitting up a web app?

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Richard Evans wrote:

> We have an existing web directory structure which has web pages in one place
> (shared amongst several web apps), and servlet classes in a couple of other
> locations (again shared).  I wanted to use tomcat with this structure but the
> api 2.2 webapp mechanism seemed too restrictive.
>
> So I added a couple of new attributes to the <Context> tag to allow for
> additional class repositories and a web page page different from the
> docBase. A few new methods in
>
>          src/share/org/apache/tomcat/core/Context.java
>
> and a change to a couple of methods in the same file was all that was needed.
>
> Now, is this a bad thing?  Could it ever get into standard Tomcat?
>

I would suggest that such a change *not* be added to the standard Tomcat.  The
thinking for this is the same reasoning that web applications were defined the
way they are in the 2.2 spec -- the whole idea is that you can take a web
application archive (WAR) file, and install it on *any* compliant servlet
container, and it will "just work".  In order for this to be feasible, the
environment expected by a webapp should be self contained.

The way that I deal with shared stuff (both static content like HTML pages/images
and dynamic stuff like shared Java libraries) is set up my build environment with
a common source code control environment, and then have "deploy" scripts that
copy the appropriate files from my build workspace to each of the webapps that
need it.  The Ant build tool <http://jakarta.apache.org/ant> that we use for
building Tomcat itself makes this approach very reasonable, because it knows
about updating only the files that have been changed.  The extra disk space costs
(versus sharing a common directory) are trivial compared to the cost of giving up
a web app's "self contained" nature.

>
> I can send patches if anyone is interested, but I'd like to gauge how useful
> the mod is.  For us it made it really practical to use tomcat.

>
> Richard
>

Craig McClanahan

====================
See you at ApacheCon Europe <http://www.apachecon.com>!
Session VS01 (23-Oct 13h00-17h00):  Sun Technical Briefing
Session T06  (24-Oct 14h00-15h00):  Migrating Apache JServ
                                    Applications to Tomcat

Re: Splitting up a web app?

[cm...@yahoo.com]

> We have an existing web directory structure which has web pages in one place
> (shared amongst several web apps), and servlet classes in a couple of other
> locations (again shared).  I wanted to use tomcat with this structure but the
> api 2.2 webapp mechanism seemed too restrictive.

Can't you do that with symlinks ? It should be easy, and no code change is
required.

Note that the 2.2 webapp specification has nothing to do with the internal
tomcat representation - it is just a format for external representation
of web applications ( just like XML is an exchange format - the data can
be stored in a database ).


> So I added a couple of new attributes to the <Context> tag to allow for
> additional class repositories and a web page page different from the
> docBase. A few new methods in 
> 
> 	 src/share/org/apache/tomcat/core/Context.java

-1 on adding that in Context ( i.e. in core).

Can you change it a bit ?
- use context attributes ( or notes !). ( you can add code to allow 
server.xml to specify "notes" - that would be very usefull and can go in
core)

- Replace the static and invocation interceptors ( you can extend them 
and override the relevant methods ). The new interceptors can use 
your attributes to implement what you need. You may need to add few 
URLs to the context classpath ( but that can be done in intereptor - no
need  to change the core )

We can create a new "module" containing contributed interceptors and
include your code - same as ant does with all the strange tasks that it
has.
I don't think it belongs in the set of interceptors included in src/share.

> and a change to a couple of methods in the same file was all that was needed.
> 
> Now, is this a bad thing?  Could it ever get into standard Tomcat?
> 
> I can send patches if anyone is interested, but I'd like to gauge how useful
> the mod is.  For us it made it really practical to use tomcat.

I think it can get into tomcat - as long as you re-write your code along
those lines. I'm strongly -1 on adding anything to tomcat.core unless
absolutely required ( and I'm +1 on removing stuff from there !) It took a
lot of work to simplify the core.

Of course, if your use case is not possible using just interceptors then
we'll need to find out what is the minimal change in core that will allow
you to do that. 

Please let me know if you need help, I'm interested in all
"practical" ways to use tomcat :-)

Costin