Cocoon interceptor inside Tomcat?

[Jonas Bosson <jo...@illuminet.se>]

Hello!

I'm starting to investigate the possibility of creating a cocoon 
 interceptor in tomcat.

This would:
* enable XML from dynamic content / servlets (pipe to formatter)
* use features in IE5/XML-browser and at the same time produce 
   html to other browsers
* greatly improve XML possibilities

Work needed:
* Intercept output stream at beforeBody (if type=xml/type -> change
  output to a buffer) actually before any headers have been sent, 
  since we might want to change content type.
  (possibly intercept at setContentType?)

* Read the buffer instead of the XML file in Cocoon and set the 
  response output to the output of the intercepted app.

Has this been done/are any work in progress?
Another option is to create the same in Apache, but that would 
include a rewrite of cocoon into C/C++.

best regards,
Jonas, IllumiNet

Re: Virtual hosts, Catalina and resources

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

Hi Nick, see below.

Nick Betteridge wrote:

> I'm in the middle of trying to set up Catalina using the Embedded class
> to create virtual hosts (straight forward) and then monitor each virtual
> host resource.
>
> What is relatively easy is the resource allocation of the connection
> thread for the HttpSession/HttpConnection thread - accessed via JNI.
>
> The physical disk resources of each virtual host - really a collection
> of war directories - is also straight forward.
>
> The area where I'm hung up is the resource measurement of the virtual
> host footprints that are in the JVM.
>
> I'm in the middle of setting up each StandardHost as a thread but I'm
> not too sure if I'm wandering down the wrong path.
>

In the current implementation, none of the Container components (Engine,
Host, Context, Wrapper) create their own threads at all, except for
background threads started to manage automatic reloading (if enabled) or
session expiration.  They rely on the Connector implementation to supply the
running thread on which each individual request is executed.  And, because
the Connector implementations recycle threads, a given thread can be used by
different virtual hosts at different times.

So, while no requests are active, the StandardHost object itself occupies
zero CPU time.  The only CPU time occupied by any webapps running on that
host are the background ticker tasks for reloading and session expiration.

It's memory footprint is problematic to calculate, but would be the sum of
the space occupied by the StandardHost object itself, all subordinate
objects (Contexts and their webapps), and so on.  But how do you ask the JVM
how much memory any given Java object is occupying so that you can add this
up?

>
> Any input or suggestions from anybody?
>

One thing you might think about is adding a Valve at the host level that
tracks the amount of time spent handling a particular request, and counting
it towards the resource usage of that host.  The fact that your Valve
actually received the request means that it belongs to this host, and this
approach also deals with multiple simultaneous requests gracefully (although
obviously overlapping requests will be counting the same wall clock time).

>
> Thanks
> Nick

Craig

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

Virtual hosts, Catalina and resources

[Nick Betteridge <n....@syntactics.com>]

I'm in the middle of trying to set up Catalina using the Embedded class
to create virtual hosts (straight forward) and then monitor each virtual
host resource.

What is relatively easy is the resource allocation of the connection
thread for the HttpSession/HttpConnection thread - accessed via JNI.

The physical disk resources of each virtual host - really a collection
of war directories - is also straight forward.

The area where I'm hung up is the resource measurement of the virtual
host footprints that are in the JVM.

I'm in the middle of setting up each StandardHost as a thread but I'm
not too sure if I'm wandering down the wrong path.

Any input or suggestions from anybody?

Thanks
Nick

Re: Re: Cocoon interceptor inside Tomcat?

[Jonas Bosson <jo...@illuminet.se>]

Thanks Craig and Costin!

What I will do:

1. I have set up a BufferedHttpServletResponse for the current implementations of
  jsdk and tomcat. It traps the buffer (more controlled than the BufferedServletOutputStream)
  (it will be a bit like beforeCommit - but with a wrapper since a beforeCommit - interceptor
   won't have much access to the stream or the buffer.)
  
2. Create a cocoon filter (Craig's recommendation) in servlet 2.3 
   (and learn how much is implemented in dev-tomcat...)

The goal is have a XML-server that supports Webb-DAV and remote Access Control.
It takes a lot of fiddling, but the result would be a distributed file system and
web site that understands different user agents. I have not yet seen DAV implemented
in TomCat so I use Apache and mod_dav. But then the jserv - would have to create
a filtering pipe from an ActionHandler in Apache and I don't see the solution for that
yet. The implementation in apache would be something like "mod_include" - but for 
servlet filtering on content-type / other attribute. And I have seen nothing about
that. But perhaps the nearly started mod_java - project at java.appache.org.

It's a puzzle. But it should work... ;-)

best,
Jonas Bosson

cmanolache@yahoo.com wrote:
> 
> > The RequestInterceptor architecture in Tomcat 3.2 isn't really set up to
> > intercept the output stream in the way you would need to do this easily.
> > You can change the headers in the beforeBody() entry point, but it's
> > difficult to replace the output stream itself unless you build a custom
> > Response implementation further up the request processing pipeline and
> > modify the connectors to use your implementation instead.
> 
> beforeCommit() is there just for that :-)
> 
> ( it is supposed to work in the same way as IIS output
> filters. Apache filters are a bit more complex - and more powerfull ,
> probably in 3.4. Let me know if you have any problems with it )
> 
> Costin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

Re: Cocoon interceptor inside Tomcat?

[cm...@yahoo.com]

> The RequestInterceptor architecture in Tomcat 3.2 isn't really set up to
> intercept the output stream in the way you would need to do this easily.
> You can change the headers in the beforeBody() entry point, but it's
> difficult to replace the output stream itself unless you build a custom
> Response implementation further up the request processing pipeline and
> modify the connectors to use your implementation instead.


beforeCommit() is there just for that :-)


( it is supposed to work in the same way as IIS output
filters. Apache filters are a bit more complex - and more powerfull ,
probably in 3.4. Let me know if you have any problems with it )

Costin

Re: Cocoon interceptor inside Tomcat?

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

See below.

Jonas Bosson wrote:

> Hello!
>
> I'm starting to investigate the possibility of creating a cocoon
>  interceptor in tomcat.
>
> This would:
> * enable XML from dynamic content / servlets (pipe to formatter)
> * use features in IE5/XML-browser and at the same time produce
>    html to other browsers
> * greatly improve XML possibilities
>
> Work needed:
> * Intercept output stream at beforeBody (if type=xml/type -> change
>   output to a buffer) actually before any headers have been sent,
>   since we might want to change content type.
>   (possibly intercept at setContentType?)
>
> * Read the buffer instead of the XML file in Cocoon and set the
>   response output to the output of the intercepted app.
>
> Has this been done/are any work in progress?
> Another option is to create the same in Apache, but that would
> include a rewrite of cocoon into C/C++.
>

The RequestInterceptor architecture in Tomcat 3.2 isn't really set up to
intercept the output stream in the way you would need to do this easily.
You can change the headers in the beforeBody() entry point, but it's
difficult to replace the output stream itself unless you build a custom
Response implementation further up the request processing pipeline and
modify the connectors to use your implementation instead.

In Tomcat 4.0 (i.e. Catalina) the Valve approach lets you wrap the
response before passing it on to the next object in the pipeline, so this
is much easier.  However, if you're going that way I would strongly
suggest that you create a javax.servlet.Filter implementation (new
feature in the 2.3 servlet spec) instead.  One of the design goals of
filters was to make precisely this kind of thing possible.  That way,
your Cocoon interceptor would be portable to any 2.3 servlet container,
instead of being specific to Tomcat.

>
> best regards,
> Jonas, IllumiNet
>

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