tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: Some JK2 ideas v.3
Date Mon, 19 Jul 2004 15:18:36 GMT
>>>
>>> We should first determine if Apache2 will have to monitor a 
>>> service/system links to the various tomcats (in cluster 
>>> configuration) to learn about real-time topology.
>>>
>>
>>
>> In fact, that is why I've pursued the .xml config over the current one.
>> The main idea is to _internally_ have config tree (right now we don't 
>> have
>> that).
>> So that internal configuration tree will be populated either using
>> directives in the native httpd.conf or reading server.xml stream from 
>> TC or
>> from file.


You must keep in mind that tomcat5 is no longer server.xml centric !

It can use separate config files in different directories, if it is 
embedded it can use the embedor's config, etc.

And httpd.conf is static - you can't modify it. We support using 
httpd.conf for performance-versus-flexibility or for native auth - if 
you want to use the apache mapper and auth instead of jk mapper and 
tomcat auth.

So IMO any jk config MUST be JMX-like.




> 
> 
> Of course we should have somewhere in the new module the configuration 
> tree in whatever native format we could imagine, apr_map maybe or 
> apr_xml_tree if existing.

File format is not important - dynamic changes and updates are the 
important issue.



> 
>>
>>>> - the configuration should be in Apache's config file, rather than 
>>>> some complex properties file
>>>
>>>
>>> +1

See above.

Apache config file is clearly better than any arbitrary static 
jk-specific config file. And it does provide close integration - 
including auth* using any of apache modules, and anything you can dream 
of in terms of apache modules.

However - it is very static, and I doubt this will change soon. Even 
with apache2, if you change the config ( add a webapp ) you need to 
restart apache ( which may be interesting if multithreaded and some 
module is using sessions).

The real important feature in jk2 is the JMX emulation - I know almost 
nobody uses it :-).







>>>
>>
>>
>> The general idea is to connect to TC and get the URI/VHOST topology, 
>> but we
>> still need the 'intervene' directives for connector specific ones.
>> How to make them simpler to use the JK and JK2?
>>
>> Perhaps using something like:
>>
>> <CoyoteWorker workerA>
>> ...directives
>>
>> </CoyoteWorker>
> 
> 
> I agreed for this on worker configuration in httpd.conf.

> 
>> And then:
>>
>> <Files *.jsp>
>>    CoyoteUsesWorker workerA
>> </Files>
> 
> 
> ok.
> 
> We should also be able to handle :
> 
> <Location /myspecialurl>
>     CoyoteUsesWorker workerA
> </Files>
> 
> Something very familiar to Apache admins.

+1 ( it's actually already working AFAIK - or it used to be ).




>>>> - it should work well with other modules (I guess if somehow it is 
>>>> accepted into the Apache codebase, it will be required)
>>>
>>>
>>> That's why we should focus on Apache 2 only module.
>>>
>>
>>
>> Not sure I'm in favor of that (unless you meant dropping 1.3 module by
>> that).
> 
> 
> Of course, I want a module designed for Apache 2.x (2.0/2.1). Apache 1.3
> could live with jk 1.2.x. IIS/NES/DOMINO could use jk 1.2 or jk2.
> No more code complexity to handle all the web-servers around,
> we should focus on Apache 2.x.
> 
> For example majors Linux distributions are now using Apache 2 instead of 
> Apache 1.3. So Apache 2.x will be more and more used.
> 
>> Without having a common codebase and API that can be used outside 
>> Apache2?

I like apache2, but keeping the options open is pretty important. Tomcat 
can be integrated in more than Web servers :-)

If you have a good infrastructure ( library ) for dynamic config and 
request forwarding - why not keep it reusable for other applications, 
even for things besides tomcat.


Having a closeley integrated variant ( using this library ) is a great 
idea, and it would be even better if this could be bundled with apache.




> 
> We should discuss what will be in the API, some will be only APR 
> dependant, but of course many will be dependant of Apache 2.x, for 
> examples Apache requests.
> 
> But we could see simple call, like :
> 
> int xxx_forward_simple_request(
>                         xxx_worker_t *,
>                         apr_pool_t * req_uri,
>                         apr_pool_t * reply_data);
> 
> int xxx_forward_simple_post_request(
>                         xxx_worker_t *,
>                         apr_pool_t * req_uri,
>                         apr_pool_t * post_data,
>                         apr_pool_t * reply_data);
> 
> int xxx_forward_full_request(
>                         xxx_worker_t *,
>                         apr_pool_t * req_uri,
>             apr_table_t * headers,
>                         apr_pool_t * post_data,
>                         apr_pool_t * reply_data);
> 
> 
> 
> 
>> In that case why not write only proxy_coyote for mod_proxy?
> 
> 
> Since it will be nice to be able to be warned in mod_xxx
> from real-time topology updates, ie application down on one
> tomcat, new application on another tomcat, cluster updates...

This may be a good feature for mod_proxy as well BTW :-)


> 
>>>> - I think the protocol should be an extension of AJP/1.3
>>>
>>>
>>> I proposed eons ago, AJP/1.3 extension, called AJP/1.4 and it could 
>>> be a good candidate. In my idea we should start to write an APR based
>>> AJP/1.4 library, which could be first used outside Apache 2 server 
>>> for test and benchs purposes.
>>>
>>
>>
>> +1, but in contradiction with previous :).
>> I would also like to see the gzip like extension to AJP/xx for 
>> lowering the
>> data transfer.
> 
> 
> It was proposed some times ago together with some light crypto to secure
> apache - tomcat link when you're not in a secure network. All of these 
> could be made optional in protocol negociation side of AJP/14...

It's all nice, but I don't see it as the biggest priority and it may be 
better implemented after everything else settles down ( otherwise the 
extra code would make changes harder ).

It seems close apache2 integration is a pretty big change

Costin


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


Mime
View raw message