tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeanfrancois Arcand <jfarc...@apache.org>
Subject Re: [5.0] Cluster features
Date Tue, 03 Dec 2002 19:18:41 GMT


Remy Maucherat wrote:

> Costin Manolache wrote:
>
>> Remy Maucherat wrote:
>>
>>
>>
>>>> +1 if all new code goes in a separate module ( instead of catalina ),
>>>> and is built as separate .jar(s).
>>>
>>>
>>> I wanted to, however I can't do that without changing the API some 
>>> stuff
>>> in the session package (the damn classes are all package private) :-P
>>>
>>> I suppose it's a lot better to stop the hacks *now*, fix that, and put
>>> everything in the cluster package.
>>
>>
>>
>> Well, if you must - you must. But we shouldn't have the core depend 
>> on the clustering, just add the minimal stuff that you need in the 
>> session.
>> If we can stop the hacks and clean something - I think 5.0 is the 
>> best chance.
>>
>> I would preffer to have a consistent hook mechanism for everything - 
>> I'm not sure what callbacks will be involved in the clustering.
>
>
> I'll remove stuff in the Cluster API, modify some of the session 
> classes to allow extending them in a different package, and everything 
> in the core is then independent of the clustering. 

No security problems if we kept the current package protection 
mechanism. Making those classes "public" can be dangerous if the package 
protection is not enabled.

>
>
>>>> It may be worth reopening the "minimal tomcat" discussion :-)
>>>
>>>
>>> Maybe. If the difference is only a couple MBs, then it's not worth it,
>>> though.
>>
>>
>>
>> Bloat is not about MB or storage. It's about code complexity, potential
>> security, etc. 
>
>
> Ok. All distributions need to be thought as secure, though. 

Does that implies re-writting the current set of classloader? It might 
be a good time to revisit classloader and security :-)

>
>
>>> If we do an alternate distribution, it would have to be radically
>>> different IMO (like for example, being a simple set of JARs without the
>>> complex dir structure). The laucher + the catalina.properties + future
>>> mods to the config system should make that easy.
>>
>>
>>
>> That's what I was thinking about - a set of jars and minimal 
>> configuration.
>> Eventually using only MBeans for configuration and setup.
>
>
> I thought this was supposed to be JNDI. JMX does not have any support 
> for bean state serialization, right ?
>
>> BTW, we could use MBeans for the optional packages too. I think it works
>> pretty well. We'll need to get a consensus on requiring JMX for tomcat5,
>> but so far it doesn't seem it'll have a big impact on the code ( I did
>> all kind of experiments with modeler and ant lately ).
>
>
> +1 for JMX (as there's MX4J); as well as JNDI, BTW. 

+1

-- Jeanfrancois

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


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