cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thor Heinrichs-Wolpert <>
Subject Re: [RT] On building on stone
Date Mon, 29 Mar 2004 16:02:34 GMT
I wasn't saying to trash it.  We had started to talk about a clean 

Since you can mark any and all items as view only in JMX, it removes 
your immutable problem.

I've never been a fan of recreating something just for the sake of 
recreating it myself, so I would've started with MX4J and then only 
removed it if it gave me problems.  Then I can focus on my problems and 
not ones that have been mostly solved for me in a way that many others 
are already used to working on.  I guess this comes from my perspective 
of working on fixed ceiling projects that must have a delivery (or I 
don't get paid) and as a contract researcher where I'm mostly 
interested in solving my problems rather than building everything from 
scratch all of the time.

I'd still be interested in seeing what the Geronimo folks are doing to 
see if we have cross community interest in ways that Apache projects 
will use MX4J.

I'm just talking about my approach, had we started from a clean slate 
and had an agreement on things we would want to try out and see which 
is better.  I would have proposed that we leverage MX4J and have it 
load in the tree processor and some other blocks and see how everyone 
likes that.  If not, we do something different.  If there is already 
something written, then maybe we just use that, or if the interfaces 
and implementation model are easy enough we could always replace the 
core and see what we think.  From the discussions here I didn't think 
the swapping, load/unload was solved based upon the questions coming 
from Pier and the discussions on how to do that.

If I'm wrong, great.  Then lets have a look at the new kernel and see 
what we want to view in it.

Thor HW

On 29-Mar-04, at 7:40 AM, Stefano Mazzocchi wrote:

> Thor Heinrichs-Wolpert wrote:
>> The ability to swap in/out components and have the other components 
>> in the system use it without much in the way of hiccups is a more 
>> interesting design problem than the load/unload and config.
> Yes, totally. And we already have it working and solved with this new 
> container. Why would we trash it to move to JMX? what would that buy 
> us?
> -- 
> Stefano, seriously curious.

View raw message