tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cost...@covalent.net
Subject RE: [PATCH] Apache2 mod_jk2
Date Tue, 04 Jun 2002 20:00:03 GMT
On Tue, 4 Jun 2002, Mladen Turk wrote:

> > We can add a 'handler' property to reflect the java-side 
> > handler that will be executed ( or one for the handler type 
> > and one for the instance).
> 
> I can extend the JkUriSet, but I need the the table of handlers, input
> filters, output filter and protocols that I'll go through, for each
> particular hook.
> The SetJavaHandler is only example for handler modules.
> SetJavaInputFilter and SetJavaOutputFilter are other two.
> I'm afraid that JkUriSet doesn't allow that. Of course it can be
> extended to keep the config directive count low,
> like 'JkUriSet handler someHandler', and will be confusing.


Jk uses jk_uriEnv_t to represent a location. There are various properties
you can associate with it, and various components will use this structure.

I'm more or less ok with adding new directives - like SetJavaInputFilter.
But the directive should set options on jk_uriEnv.

The problem with new directive - JkUriSet works the same as 
workers2.properties ( i.e. associate name=value for the location
'object' ). 
I think this model - of having different 'objects' with 'properties'
is pretty flexible, and with workers2.properties you'll have it
working for any web server. 

<Location /foo>
JkUriSet inputFilter MyFilter
</Location> 
or

[uri:/foo]
inputFilter=MyFilter 

are doing the same thing, call setAttribute( "inputFilter", "MyFilter" ).

It's ok to add a 
 JkInputFilter MyFilter
or 
 SetInputFilter MyFilter,
but I don't think it's much more intuitive than the current solution.

> > Again, the goal is to keep the C-Java interface to a minimum 
> > that can be optimized, and do more work on the java side.
> > 
> 
> That's my goal too. The Java side will have all the interface, and C
> side will just find the paticular hook, and implement the missing
> interface.

Finding the hook is already implemented, all you need is a worker that 
will forward the information that you need ( as oposed to the current 
worker_ajp that forwards the full request ).


> Again I need four special data structures that consists of synced
> apr_table, and apr_hash_table,
> bassicaly the extended jk_map_aprtable.
> 
> I'd like to minimize the various configuration files. Modules will be
> the part of Apache server and IMO their configuration should be inside
> the server configuration file.

I partially agree.

The reasons we use workers2.properties ( and I think you should use
it too, even if using only httpd.conf is possible ):

- same format for all servers ( IIS, I hope soon others )
- easier automated generation ( i.e. I hope we'll be able to use JMX
and java to generate and maintain the file )
- reloading ( for some options ).
- easier for people who are not familiar with httpd.conf

On the other side using httd.conf:
- is faster ( since <Location> will be used, and the internal apache 
mapper )
- familiar for apache users
- single config file

Both are valid - and each user can choose, but we should support both.
The 'java bean' style of using setters/getters for configuration
makes this reasonably easy.

Costin


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message