tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject RE: [VOTE] JK2 2.1
Date Tue, 01 Oct 2002 18:26:53 GMT
Mladen Turk wrote:

> 
> Well, what I was yelling about was the core components, like load
> balancer, uriMap, uriEnv.
> We can write our own functionality, copy the code from the APR, or
> something else if faster. These are the components that cannot easily be
> supported using #idfef HAS_APR #elif MOZILLA #else...
> 
> So, we need a decision, are we going to use (for example)
> apr_time_now(), write our own, using #ifdef #else, or what for those
> core components?

As I said, the load balancer, mapper and uriEnv ( and most other components) 
should be pluggable.

You should be able to have multiple balancer implementations and select
the one you want. Or have multiple mapper implementations and select one.
( for uriEnv it may be a bit more complicated, as it must 'extend' the
base structure - most likely a 'pure virtual' aproach would help in this 
case ).

If this is not possible now - we should fix it first, then add the 
alternate components ( with no #ifdef ).  


> Other thing. If we say that core components has to be 'non-mandatory' of
> any component like apr or nspr or whatever, the code like #ifdef HAS_APR
> must not be in such a component, or it loose its meaning like component
> free. And what is component free code (APR doesn't belong to that
> category, it is more a system abstraction layer like posix).

What I'm saying is that jk2 'core' should consist of jk_env, possibly 
jk_config and the 'definition/programming model' for components.

The current jk_channel_socket, mapper, etc are a set of components - 
with the caracteristic that they can work in apache1.3 or other cases
without APR, that the code is very close to the one in jk1, etc.

If we are not modular enough to support alternate implementations for
jk_uriEnv - than we should fix this problem first. For channels I'm
pretty sure it is possible, and for mapper it should be easy.
Also for marshalling it should be easy.


> So...
> If you wish make some draft about what are the core components, what is
> 'mandatory' inside them and what is not, so that we know how to write
> the code for such a component.

All I'm saying is that most components should be replaceable. What 
seemed the most important was the channels, protocol and the vm plugin -
and for that it seems to work. There is no reason why you couldn't
add code to find a component by name - the config is a special case 
because it requires a bootrsrap ( i.e. it must be hardcoded that you
want jk_my_apr_config ), but for all other components it should be
easy ( and desirable ) to support multiple implementations.

And if we have some strange operating system or piece of code that is not
abstracted by APR ( like starting Kaffe VM or accessing some 
OS-specific feature that is not portable by definition and as such
not supported by APR ) - then a specific component can be used.

I think jk_env and what's related with the components is 'mandatory',
everything else could have multiple implementations. 

Costin


> 
> 
>> -----Original Message-----
>> From: news [mailto:news@main.gmane.org] On Behalf Of Costin Manolache
>> Sent: Tuesday, October 01, 2002 7:13 PM
>> To: tomcat-dev@jakarta.apache.org
>> Subject: RE: [VOTE] JK2 2.1
>> 
> 
> MT.

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