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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
