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 16:22:31 GMT
Henri Gomez wrote:

>> 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.
> 
> 
> Well httpd.conf is static but nothing prevent from doing :
> 
> <Location /examples>
> AjpWorker myworker
> </Location>
> 
> => All /examples goes to myworker, which could be a simple tomcat
> or a cluster. but the idea behind is to make updates to this 'myworker'
> from the behind, JMX or AJP13++/AJP14 link.


And what if /examples context is removed ?

Or a new context is dynamically added ?

What about /examples/protected/ which may need to be authenticated - if 
we really want to support "play nice with other apache modules", then we 
need to support authentication using apache modules. Then what if the 
webapp is reloaded with a different protected uri ?




> 
> 
>> So IMO any jk config MUST be JMX-like.
> 
> 
> May be.
> 
>>>
>>>
>>> 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).
> 
> 
> Not necessary. Nothing prevent us from doing something like this :
> 
> <Location /*.jsp>
> AjpWorker myworker
> </Location>
> 
> 
> <Location /servlet/*>
> AjpWorker myworker
> </Location>
> 
> 
> And if the mod_xxx is able to discover the webapp attached to myworker,
> you got them redirected to the correct worker.

And you lose the real integration into apache - which is the ability to 
use other modules.

My point is that we have 2 use cases, one is "strong integration", where 
you want to use apache modules, and the other is "dynamic", where you 
want to deal with a server where apps are often deployed or changed.

You just can't support both use cases with the same solution - if you 
try, it's a lose-lose situation.




> 
>> The real important feature in jk2 is the JMX emulation - I know almost 
>> nobody uses it :-).
> 
> 
> Well the code is too complex in jk2, and that's also why we need some 
> cleanups.

I agree.

However starting from scratch without having a flexible design that 
takes into account the dynamicity of tomcat is bound to result in 
another chunk of complex code ( after some time ), or something 
inflexible ( mod_webapp ? ).



> 
> 
>>>> 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 :-)
> 
> 
> Of course but many users and admins are confused in using jk2 with
> Apache 2 for example. Too many way to do the same conf make jk2
> a difficult thing and that's why many stay on jk 1.2.x

What about 2 ways only :-) ?

Again - if you can find a solution to use httpd.conf and support a 
dynamic environment without giving up integration, then I'm fine. Using 
httpd.conf file and some custom directives that don't work with other 
modules is the worse choice, you lose both integration and dynamic config.


> 
>> 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.
> 
> 
> Well if other application want to access an embedded tomcat, they could
> use JNI or direct Java calls ?

In most cases, other apps need to use TCP/unix sockets and jk protocol ( 
  I'm talking about native apps ). JNI is far too complicated, 
especially from single-threaded apps.



> 
>> 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.
> 
> 
> Of course that's the idea, having a resonable module which could came
> with Apache 2.x distributions, following the same code standards (ie 
> using apr_/ap_) and also the same documentation format (the HTTPD 2.0
> documentation is really clear).

+1 - as long as the code has a good architecture that takes jmx in 
account, and uses a modular approach.

( this means - parts of it could be reused )


> 
>>> 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 :-)
> 
> 
> mod_proxy didn't support clustering :(
> 
>>>
>>>>>> - 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 ).
> 
> 
> Of course, negociation is one thing, implementation is another.

:-)

> 
>> It seems close apache2 integration is a pretty big change
> 
> 
> Yes, a total rewrite of the existing code, no more jk, no more jk2, but
> cut/paste, redesign and rewrite.

Ok, but it should start with "design" ( or even better - agreement on 
requirements before design !)


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