You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2004/03/23 14:25:30 UTC
[RT] On building on stone
I want Cocoon to last long and to be able to stand the pressure of a big
user community, a diverse development community and that of companies
built on top of it.
For this reason, we must identify in advance all moves that lead to
making the cocoon project weaker.
There are three things that provide foundation for a project:
1) its technology
2) its community
3) its license
The three things are not so unrelated as some people think, but this is
not the topic for today.
Gump indicates that Cocoon has 205 dependencies on external projects.
Gump has been able to do a clean cocoon run only *once* in its entire
three-years-long existance.
This is not good. It shows that we are building on sand.
There are two ways to get out of this:
1) better modularity (to reduce dependencies)
2) more solid dependencies for our core (to increase solidity of our
foundations)
As for better modularity, we designed the Cocoon Blocks.
We now have to finish #2.
- 0 -
I've been helping Pier write a block-like container for his employer and
found out that no matter how hard we try, the Avalon interfaces cannot
allow to implement Cocoon Blocks the way we designed them.
In short: if we want to have hot-deployable, polymorphically dependent
high-level cocoon web application components, we can't use Avalon4.
- o -
This leads to a rather difficult choice:
1) avoid implementing real blocks
2) change our foundation framework
I would go for #2, since I consider real blocks vital for the evolution
of this project.
Now, if we go #2 there are three choices:
1) patch avalon
2) change framework
3) do our own
Here my choice would not be technologically driven but rather socially
driven: I would do our own.
Why? because Avalon's communities are not healthy. The turnover rate is
incredily high and the burn-out period is amazingly short. Its simply
too fragile to build cocoon on something like this.
From a community perspective, Avalon is sand. Avalon's biggest problem
is that technology is more important than the community. Purity that
leads to forks is more important than compromises that keep the
community together.
This is such a strong cultural clash which impact was for long
underestimated.
Not so anymore and since now we need to make a choice, my choice would
be to design our own framework and container.
- o -
So, here is my detailed proposal:
1) implement our own framework and container in order to implement
cocoon blocks [this creates the solid foundation that we control]
2) create an avalon emulation layer for the legacy components that
would allow avalon components to run unmodified [this allows users to
have a smooth migration path and no immediate impact on their
development/mainteinance costs]
3) operate as incrementally as possible and work to change as little
code as possible [this makes the community transition smoother, reduces
enthropy and bugs introduced by the new code]
4) keep the framework and container *MINIMAL* to our own needs. [we
WILL NOT redistribute the framework independently]
5) the name for our framework+container will be simply Cocoon Core
6) I volunteer to help directly in writing code
- 0 -
Now, before everybody and their dog replies to this and wishes to
convince us to use their framework, the only measure of judgement would
nto be technological but community and its culture.
Cocoon needs a rock solid core.
Solid in both technical, social and legal way.
I believe that social and legal solidity build technical one. The
opposite is not true. Cocoon and Avalon (both highly considered from a
technical perspective) demonstrate this pretty well.
I see no potential cocoon core out there that is not a one-man show and
that allows us to do what we want to achieve with real blocks.
Thus the proposal to write and maintain our own, in order to finally,
once and for all, build on stone and escape the social quicksands in
core depenendies.
Fire at will: I have my abstesto underwear on.
--
Stefano.
Re: [RT] On building on stone
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 23 Mar 2004, at 18:22, Sylvain Wallez wrote:
>> Please, Stefano - *do not* under any circumstances (despite Sylvain's
>> suggestion) take your underwear off while coding. :)
>
> Hey Geoff, he doesn't have a webcam, so let him code the way he likes
> ;-)
Note to self: given that I have a webcam pointed at me at all time when
I'm at work, remember not to pick nose and to shave in the morning! :-P
Pier
Re: [RT] On building on stone
Posted by Sylvain Wallez <sy...@apache.org>.
Geoff Howard wrote:
> Sylvain Wallez wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>> Fire at will: I have my abstesto underwear on.
>>
>
>> Put it off: it doesn't help to get code written (see point 6)!
>
>
> Please, Stefano - *do not* under any circumstances (despite Sylvain's
> suggestion) take your underwear off while coding. :)
Hey Geoff, he doesn't have a webcam, so let him code the way he likes ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] On building on stone
Posted by Geoff Howard <co...@leverageweb.com>.
Sylvain Wallez wrote:
> Stefano Mazzocchi wrote:
>
>> Fire at will: I have my abstesto underwear on.
>
> Put it off: it doesn't help to get code written (see point 6)!
Please, Stefano - *do not* under any circumstances (despite Sylvain's
suggestion) take your underwear off while coding. :)
Geoff
Re: [RT] On building on stone
Posted by Sylvain Wallez <sy...@apache.org>.
Stefano Mazzocchi wrote:
> I want Cocoon to last long and to be able to stand the pressure of a
> big user community, a diverse development community and that of
> companies built on top of it.
<snip/>
> So, here is my detailed proposal:
>
> 1) implement our own framework and container in order to implement
> cocoon blocks [this creates the solid foundation that we control]
>
> 2) create an avalon emulation layer for the legacy components that
> would allow avalon components to run unmodified [this allows users to
> have a smooth migration path and no immediate impact on their
> development/mainteinance costs]
>
> 3) operate as incrementally as possible and work to change as little
> code as possible [this makes the community transition smoother,
> reduces enthropy and bugs introduced by the new code]
>
> 4) keep the framework and container *MINIMAL* to our own needs. [we
> WILL NOT redistribute the framework independently]
>
> 5) the name for our framework+container will be simply Cocoon Core
>
> 6) I volunteer to help directly in writing code
Although this means that we enter a long road before having 2.2, I think
this is the way to go. The Cocoon house is big, and it must have solid
foundations that it controls in order to continue growing.
Now point 2 is important, as lots of people have invested in Cocoon and
would be very confused if we abruptly changed the way Cocoon works.
Fortunately, we stayed on ECM and avoided the migration to more complex
containers, which should ease the writing of this compatibility layer.
It's also the occasion to consider what we can learn from the good, the
bad and the ugly in existing containers while building our own,
specifically adapted to our needs. As Steven said, so many people write
their own containers nowadays that it's certainly not rocket science,
although it requires clever ideas, an area in which Pier and you have
proved your abilities ;-)
<snip/>
> Fire at will: I have my abstesto underwear on.
Put it off: it doesn't help to get code written (see point 6)!
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] On building on stone
Posted by Geoff Howard <co...@leverageweb.com>.
Stefano Mazzocchi wrote:
> I want Cocoon to last long and to be able to stand the pressure of a big
> user community, a diverse development community and that of companies
> built on top of it.
...
> This leads to a rather difficult choice:
>
> 1) avoid implementing real blocks
> 2) change our foundation framework
>
> I would go for #2, since I consider real blocks vital for the evolution
> of this project.
>
> Now, if we go #2 there are three choices:
>
> 1) patch avalon
> 2) change framework
> 3) do our own
>
> Here my choice would not be technologically driven but rather socially
> driven: I would do our own.
>
> Why? because Avalon's communities are not healthy. The turnover rate is
> incredily high and the burn-out period is amazingly short. Its simply
> too fragile to build cocoon on something like this.
I'd add a parallel reason which may also be understood by people who may be less
convinced about the health of that community or its importance (alas, I am no
longer one). We cannot trust this core to a separate entity who have many other
needs to consider in parallel. Why? We have specific needs, and need them
quick. Also, we've found in practice that our container needs don't always have
a lot of overlap with others' needs. We are far simpler in some ways, more
complicated in others. If in some hypothetical future scenario others share a
good deal of our needs, we can decide at that time if we should enable others to
use our core by packaging separately - but I would be surprised if we ever would
a) want this core managed elsewhere, or b) want to have to answer to users with
different needs totally unrelated to Cocoon.
> Fire at will: I have my abstesto underwear on.
Hopefully you will not need it. Your proposal needs to be tested by fire, but
not you - let's get that out here early. Personally, knowing that there is
already some "code on disk" makes this seem very attainable. If it means we
have blocks sooner than later, I am 100% behind it.
Geoff
RE: [RT] On building on stone
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> As for your specific solution, well, I think it's better to start with
> what Pier has, then, once the code is in our CVS, we'll discuss how to
> improve it/change it/throw it away.
I agree. It was just a reflexive comment when I read what the main
difference was (hotswappability).
> How's that as a deal?
Sure!
Bring it on.
/LS
Re: [RT] On building on stone
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Sutic wrote:
>
>>From: Stefano Mazzocchi [mailto:stefano@apache.org]
>>
>>But...
>>
>>
>>>Is this related to the statefulness of the component?
>>
>>... as you correctly spot, the thing is way more tricky than
>>it looks at
>>first.
>>
>>The way we solved this was to enable a sort of loose-coupling wiring
>>between components. This requires block A to check for the
>>wire validity everytime a service is invoqued and, if not, look it up
>
> again
>
>>(obviously the framework will provide helping code for this).
>
>
> Could also be solved by introducing the notion of component
> transactions.
> Add a read and write lock to each component wire.
> Block A could in effect disable hot-swapping of a component while it is
> used (i.e. get a read-lock on the wire), while the hot-swap machinery
> tries to get a write-lock on the wire. Thus, the component will
> never be swapped when used, and thus the wire-check is unneccessary.
See why I want to have our own kernel? to attract new ideas!
Leo, if you have new ideas bring, them on. Just like we did for Woody
that later became Cocoon Forms (CForms) we are going to use Tani (Pier's
container implementation) to seed the Cocoon Kernel (CKernel).
It might be without modifications or it might be completely rewritten.
We *DO*NOT* care!
It's not an ego fight, it's not my ideas are better then yours, it's not
we are going to conquer the world and show how smart we are....
.. the goal is to create a solid foundation for cocoon so that it can
grow in the next generations and allow much more complex web
applications to be built.
The more ideas, the merrier.
As for your specific solution, well, I think it's better to start with
what Pier has, then, once the code is in our CVS, we'll discuss how to
improve it/change it/throw it away.
How's that as a deal?
--
Stefano.
Re: On blocks reload (Re: [RT] On building on stone)
Posted by Sylvain Wallez <sy...@apache.org>.
Pier Fumagalli wrote:
> On 26 Mar 2004, at 17:46, Pier Fumagalli wrote:
>
>> That's ALL _IMVHO_, I don't know what others think, but we mustn't
>> forget that our container needs to solve one very very very specific
>> problem, the Cocoon problem...
>
>
> Hmm... Thought about it over some nicotine, and if people do really
> feel strong about not loosing component instances "all of a sudden",
> I'd rather go down the path the JVM uses: garbage collection.
>
> When a block is "reloaded" (because of an update of its classes, or a
> change in its configuration), simply its instance remains available in
> the container, but "inactive".
>
> All new lookups will happen on the new block instances, previously
> acquired components will still work with the old block, no question
> asked (never loose anything).
>
> And then to have a some sort of "Garbage Collector" which flushes out
> all previously deployed block instances not having components
> instances wired from other blocks.
+1. I was about to propose exactly this, as we don't need to handle
non-existing blocks as in the case of distributed systems. Blocks
dependencies will always be satisfied, it just that "who" satifies it
changes over time. So when a component is looked up, it's used until
released, even if its originating block has been replaced by another one
inbetween.
Something that has to be considered, though, is if the whole wire (i.e.
all used components) between two blocks changes at once, or if traffic
progressively switched from the old wire to the new one (i.e. lookup in
the new block even if some components of the old one are still being
used). The first solution avoids any consistency problems, but at the
same time can prevent the actual wire switch to occur, especially under
load, where there will be a permanent traffic over the old wire,
preventing the switch to the new one.
> Only thing I can think about is that some block might never be garbage
> collected because someone didn't release a wiring, but probably we can
> "force" a manual disconnection (notify the admin who triggered the
> reload, or something).
Yep.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: On blocks reload (Re: [RT] On building on stone)
Posted by Torsten Curdt <tc...@vafer.org>.
>> That's ALL _IMVHO_, I don't know what others think, but we mustn't
>> forget that our container needs to solve one very very very specific
>> problem, the Cocoon problem...
>
>
> Hmm... Thought about it over some nicotine, and if people do really feel
> strong about not loosing component instances "all of a sudden", I'd
> rather go down the path the JVM uses: garbage collection.
>
> When a block is "reloaded" (because of an update of its classes, or a
> change in its configuration), simply its instance remains available in
> the container, but "inactive".
>
> All new lookups will happen on the new block instances, previously
> acquired components will still work with the old block, no question
> asked (never loose anything).
>
> And then to have a some sort of "Garbage Collector" which flushes out
> all previously deployed block instances not having components instances
> wired from other blocks.
>
> Only thing I can think about is that some block might never be garbage
> collected because someone didn't release a wiring, but probably we can
> "force" a manual disconnection (notify the admin who triggered the
> reload, or something).
sounds great to me +1
--
Torsten
RE: On blocks reload (Re: [RT] On building on stone)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Pier,
I'd actually rather see you just axed the block with no
further ado.
Having a stale reference to a component may just make the
bugs more subtle and harder to find.
/LS
> From: Pier Fumagalli [mailto:pier@betaversion.org]
On blocks reload (Re: [RT] On building on stone)
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 26 Mar 2004, at 17:46, Pier Fumagalli wrote:
> That's ALL _IMVHO_, I don't know what others think, but we mustn't
> forget that our container needs to solve one very very very specific
> problem, the Cocoon problem...
Hmm... Thought about it over some nicotine, and if people do really
feel strong about not loosing component instances "all of a sudden",
I'd rather go down the path the JVM uses: garbage collection.
When a block is "reloaded" (because of an update of its classes, or a
change in its configuration), simply its instance remains available in
the container, but "inactive".
All new lookups will happen on the new block instances, previously
acquired components will still work with the old block, no question
asked (never loose anything).
And then to have a some sort of "Garbage Collector" which flushes out
all previously deployed block instances not having components instances
wired from other blocks.
Only thing I can think about is that some block might never be garbage
collected because someone didn't release a wiring, but probably we can
"force" a manual disconnection (notify the admin who triggered the
reload, or something).
Pier
RE: [RT] On building on stone
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Pier Fumagalli [mailto:pier@betaversion.org]
>
> Why? If a request fails because I reloaded the XSLT Transformer block,
> well, I'm ready to loose that request... Cocoon is a servlet, at the
> end of the day, and I'd rather loose XSLT translation for 1/2
> a second while I reload the XALAN block, than wait 10 minutes while I
> reload the JVM, as I can't reload XSLT because every single Pipeline
in
> my sitemap is locking on it, and (of course) I will never ever be able
to
> reload it until the traffic on my website goes down to ZERO...
In all read/write lock implementations I've ever seen, having a pending
writer means that readers queue up. That is, you'll have to wait
until all *currently executing pipelines* have finished. Then you'll
get your write lock and can swap the block. All pipelines that
tried to lock the component after your request to acquire a write
lock will have queued up, and will start executing as soon as you
release your write lock.
But the point here wasn't really to argue specific cases, was it?
> Dude, don't get upset, I'm not thinking about the holy grail here, I
> _DO_NOT_WANT_ to write another Avalon, I want Cocoon to have a
> container tailored EXACTLY for its own requirements, being a servlet
> and all...
>
> Let's not forget that we work on HTTP connections, and that at any
> given point in time, those can be disconnected, time out, or your
> network admin can unplug the cable...
>
> What's the difference between that, and loosing the connection for a
> second with a component? Thing, that (by the way) will _NEVER_ happen
> automagically, but only when the administrator decides that it's time
> to reload a block instance?
Because I think that you are trading a little complexity in the
container for a lot of complexity in the blocks.
Then again, that's *my* VHO.
Basically the question is this:
Is the code expected to handle a swap of a block gracefully?
If a block swap really is like unplugging a network cable, or toasting
the switch/router, then code should just re-throw the exception and
exit abruptly. However, if the code is somehow expected to recover, then
I think that there should be some mechanism whereby the swapping is
made invisibly to the code (i.e. when the block isn't used). Otherwise
the amount of error-handling code will become impractical.
/LS
Re: [RT] On building on stone
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 26 Mar 2004, at 14:44, Leo Sutic wrote:
>> From: Pier Fumagalli [mailto:pier@betaversion.org]
>>
>> On 26 Mar 2004, at 11:57, Leo Sutic wrote:
>>>
>>> Think about TCP/IP. You have guaranteed delivery of packets
>> (which you
>>> don't have with UDP). Completely guaranteed? No. A
>> chopped-off network
>>> cable is not something that the protocol can handle. But still very
>>> useful.
>>
>> The TCP/IP is a good example...
>>
>> To use the same parallel, when I open a TCP connection I am guaranteed
>
>> that I'm going to get a Socket object (to use Java) I can use. But the
>
>> platform doesn't guarantee me that its InputStream or OutputStream are
>
>> going to be valid forever, they might throw IOExceptions, and the
>> socket itself can be in a connected or disconnected status (you're
>> never guaranteed).
>>
>> You go usually until you don't hit an IOException on the streams (or
>> isConnected() returns true), but then you'll have (somehow) to handle
>> that state change which you don't control...
>>
>> Wirings between blocks behave in the same way, you go until one of the
>
>> methods you call doesn't return an exception, or until the wiring is
>> available (err, you can check on that),
>
> Actually, you can't.
>
> There's no guarantee that the block isn't going to be swapped out
> between the checking call and the next method call.
>
> So there's absolutely no point in making the checking call.
>
> There's even no guarantee that the block won't be swapped out ***while
> it
> is executing a method***.
>
> Now that's starting to become dangerous.
Why? If a request fails because I reloaded the XSLT Transformer block,
well, I'm ready to loose that request... Cocoon is a servlet, at the
end of the day, and I'd rather loose XSLT translation for 1/2 a second
while I reload the XALAN block, than wait 10 minutes while I reload the
JVM, as I can't reload XSLT because every single Pipeline in my sitemap
is locking on it, and (of course) I will never ever be able to reload
it until the traffic on my website goes down to ZERO...
Dude, don't get upset, I'm not thinking about the holy grail here, I
_DO_NOT_WANT_ to write another Avalon, I want Cocoon to have a
container tailored EXACTLY for its own requirements, being a servlet
and all...
Let's not forget that we work on HTTP connections, and that at any
given point in time, those can be disconnected, time out, or your
network admin can unplug the cable...
What's the difference between that, and loosing the connection for a
second with a component? Thing, that (by the way) will _NEVER_ happen
automagically, but only when the administrator decides that it's time
to reload a block instance?
Instead, the difference between having to shut down a VM because you
need to reload a component (and loosing ALL your requests, but also all
your continuations, sessions, you name it), and unwiring a component
(and loosing ONLY the requests that were using that component), is for
Cocoon quite a friggin' advantage.
That's ALL _IMVHO_, I don't know what others think, but we mustn't
forget that our container needs to solve one very very very specific
problem, the Cocoon problem...
Pier
RE: [RT] On building on stone
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Pier Fumagalli [mailto:pier@betaversion.org]
>
> On 26 Mar 2004, at 11:57, Leo Sutic wrote:
> >
> > Think about TCP/IP. You have guaranteed delivery of packets
> (which you
> > don't have with UDP). Completely guaranteed? No. A
> chopped-off network
> > cable is not something that the protocol can handle. But still very
> > useful.
>
> The TCP/IP is a good example...
>
> To use the same parallel, when I open a TCP connection I am guaranteed
> that I'm going to get a Socket object (to use Java) I can use. But the
> platform doesn't guarantee me that its InputStream or OutputStream are
> going to be valid forever, they might throw IOExceptions, and the
> socket itself can be in a connected or disconnected status (you're
> never guaranteed).
>
> You go usually until you don't hit an IOException on the streams (or
> isConnected() returns true), but then you'll have (somehow) to handle
> that state change which you don't control...
>
> Wirings between blocks behave in the same way, you go until one of the
> methods you call doesn't return an exception, or until the wiring is
> available (err, you can check on that),
Actually, you can't.
There's no guarantee that the block isn't going to be swapped out
between the checking call and the next method call.
So there's absolutely no point in making the checking call.
There's even no guarantee that the block won't be swapped out ***while
it
is executing a method***.
Now that's starting to become dangerous.
> If component locking needs to be performed, it needs to be a framework
> feature unaccessible to components, otherwise it will be abused of.
Well, for stateless interfaces (think MailServer), the framework
should lock the component during the method call, so the block isn't
swapped
out while it is executing a call.
For stateful interfaces (think ContentHandler), the framework can lock
the component between lookup and release.
/LS
Re: [RT] On building on stone
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 26 Mar 2004, at 11:57, Leo Sutic wrote:
>
> Think about TCP/IP. You have guaranteed delivery of packets (which
> you don't have with UDP). Completely guaranteed? No. A chopped-off
> network cable is not something that the protocol can handle. But
> still very useful.
The TCP/IP is a good example...
To use the same parallel, when I open a TCP connection I am guaranteed
that I'm going to get a Socket object (to use Java) I can use. But the
platform doesn't guarantee me that its InputStream or OutputStream are
going to be valid forever, they might throw IOExceptions, and the
socket itself can be in a connected or disconnected status (you're
never guaranteed).
You go usually until you don't hit an IOException on the streams (or
isConnected() returns true), but then you'll have (somehow) to handle
that state change which you don't control...
Wirings between blocks behave in the same way, you go until one of the
methods you call doesn't return an exception, or until the wiring is
available (err, you can check on that), no more, no less as you would
do with a Socket.
Plus (I think) if a component is allowed to programmatically declare
its locking to other blocks, I'm absolutely sure that 2 days down the
line we're going to have people complaining about:
Them: "I tried to reload that block, but it didn't"
Us: "What does the exception say?"
Them: "Well it says unable to reload because of active lock from
MyBlock"
Us: (look at source code of MyBlock and see that someone wrote lock()
into it)
If component locking needs to be performed, it needs to be a framework
feature unaccessible to components, otherwise it will be abused of.
In the framework, it's easier... At deployment time say to the deployer
that the block is "locked" and the framework will never reload it, and
all other blocks requiring it, will be "guaranteed" that they won't
loose references to the components, even if I simply don't see the
point.
Pier
RE: [RT] On building on stone
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Pier Fumagalli [mailto:pier@betaversion.org]
>
> On 25 Mar 2004, at 17:44, Leo Sutic wrote:
>
> > Could also be solved by introducing the notion of component
> > transactions. Add a read and write lock to each component wire.
> > Block A could in effect disable hot-swapping of a component while it
is
> > used (i.e. get a read-lock on the wire), while the hot-swap
machinery
> > tries to get a write-lock on the wire. Thus, the component will
> > never be swapped when used, and thus the wire-check is unneccessary.
>
> That (IMVHO) a bad approach. Components should not "lock", because
> (anyway) that lock cannot be guaranteed...
>
> So, what's the point in "guaranteeing" the availability of a
component?
The point is to avoid unnecessary failures by guaranteeing that the
framework
will handle events that are expected to occur in itself. There's a
difference between a switch being unplugged (an exceptional
circumstance),
and a block being swapped (which is quite normal).
In the exceptional circumstance you can simply release all acquired
resources and let the exception propagate upwards to some error handler,
because it is inherent in the definition of an exception that there's
really nothing you can do about it, but a block swap should be handled
gracefully - perhaps by trying again.
> Much _much_ better to make you completely aware that someone can
> disconnect that wiring at any time, and you'll write your code to
> handle it...
Yes, because every coder just loves to write error-handling code?
Either a block swap is something you should write error-handling
code for or not. If it is, then you risk the same problem as
Java has with ThreadDeathError - there's really no sensible way to
protect against it.
If it isn't, then, well, boom.
Letting the framework handle the type of errors that *should* be
handled is good, because it moves handling for *common* *events*
*that* *naturally* *occur* *within* *the* *system's* *specification*
to a central point.
Trying to make the framework handle errors that are completely
outside the spec (server losing power), is bad.
Think about TCP/IP. You have guaranteed delivery of packets (which
you don't have with UDP). Completely guaranteed? No. A chopped-off
network cable is not something that the protocol can handle. But
still very useful.
/LS
Re: [RT] On building on stone
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 25 Mar 2004, at 17:44, Leo Sutic wrote:
> Could also be solved by introducing the notion of component
> transactions.
> Add a read and write lock to each component wire.
> Block A could in effect disable hot-swapping of a component while it is
> used (i.e. get a read-lock on the wire), while the hot-swap machinery
> tries to get a write-lock on the wire. Thus, the component will
> never be swapped when used, and thus the wire-check is unneccessary.
That (IMVHO) a bad approach. Components should not "lock", because
(anyway) that lock cannot be guaranteed...
Imagine this: I have a JDBC connection block upon which instantiates
java.sql.Connection components...
Kewl, I make it transactional, the framework GUARANTEES me that I'm not
going to loose it...
Whops, my network administrator (happened today at noon) reinstalling
the firewall accidentally disconnects the power cable of the switch...
IOExceptions thrown everywhere... Now, if my component (using the JDBC
connection) is not ready to handle that, my website falls over (and
VNUNET did fall over today at noon).
So, what's the point in "guaranteeing" the availability of a component?
Much _much_ better to make you completely aware that someone can
disconnect that wiring at any time, and you'll write your code to
handle it...
To handle it if the framework unwires your JDBC connection instance,
and to handle it if you have an IOException because your admin
unplugged a cable.
Let's not over-think our problems... :-P
Pier
RE: [RT] On building on stone
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> But...
>
> > Is this related to the statefulness of the component?
>
> ... as you correctly spot, the thing is way more tricky than
> it looks at
> first.
>
> The way we solved this was to enable a sort of loose-coupling wiring
> between components. This requires block A to check for the
> wire validity everytime a service is invoqued and, if not, look it up
again
> (obviously the framework will provide helping code for this).
Could also be solved by introducing the notion of component
transactions.
Add a read and write lock to each component wire.
Block A could in effect disable hot-swapping of a component while it is
used (i.e. get a read-lock on the wire), while the hot-swap machinery
tries to get a write-lock on the wire. Thus, the component will
never be swapped when used, and thus the wire-check is unneccessary.
/LS
Re: [RT] On building on stone
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Sutic wrote:
>
>>From: Stefano Mazzocchi [mailto:stefano@apache.org]
>>
>>Because avalon components are directly wired while the new components
>>will be loosely wired. This is the only way we can achieve
>>hot-swapping polimorphism and Avalon4 simply cannot do that.
>
>
> So, even if you instead of having:
>
> Client ---- Component
>
> have:
>
> Client ---- Proxy ---- Component
>
> You can't do the hotswap?
We are doing this, yes.
But there are a few tricky things here: cocoon blocks are polymorphic
*themselves*, polymorphism is not exposed only thru the java interfaces,
but it's a higher level concept (for example, you have a "skin" block,
then you have your own skin flavor, think of debian virtual packages)
If you are dealing with resources (as debian is, for example), this is
no big deal, and it's all taken care at resource lookup.
Cocoon Blocks are special because they contain *both* services (thru
components) and resources (thru pipeline invocations).
Please note how polymorphism is used not only for different flavors (as
for a skin, for example), but also (and way more important!!) for
versioning!
If block A1 requires block B implemented right now by Block B1, then
block A looks up a component that is currently on B1, but we hotswap the
wiring to B2 (the new version), block A should not notice a difference.
But...
> Is this related to the statefulness of the component?
... as you correctly spot, the thing is way more tricky than it looks at
first.
The way we solved this was to enable a sort of loose-coupling wiring
between components. This requires block A to check for the wire validity
everytime a service is invoqued and, if not, look it up again (obviously
the framework will provide helping code for this).
Avalon's notion of wiring is way more primitive than this and it is
impossible for us to obtain the functionality we want without doing
back-incompatible changes to the avalon framework.
--
Stefano.
RE: [RT] On building on stone
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> Because avalon components are directly wired while the new components
> will be loosely wired. This is the only way we can achieve
> hot-swapping polimorphism and Avalon4 simply cannot do that.
So, even if you instead of having:
Client ---- Component
have:
Client ---- Proxy ---- Component
You can't do the hotswap?
Is this related to the statefulness of the component?
/LS
Re: [RT] On building on stone
Posted by Stefano Mazzocchi <st...@apache.org>.
Leo Sutic wrote:
>>From: Stefano Mazzocchi [mailto:stefano@apache.org]
>>
>>But this will also mean that will be isolated from other blocks and
>
> will
>
>>not be able, for example, to load components from other blocks.
>
>
> Is that "not be able" as in "not under any circumstances", or "not under
> all
> circumstances"?
>
> That is, why isn't it able?
Because avalon components are directly wired while the new components
will be loosely wired. This is the only way we can achieve hot-swapping
polimorphism and Avalon4 simply cannot do that.
--
Stefano.
RE: [RT] On building on stone
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> But this will also mean that will be isolated from other blocks and
will
> not be able, for example, to load components from other blocks.
Is that "not be able" as in "not under any circumstances", or "not under
all
circumstances"?
That is, why isn't it able?
/LS
Re: [RT] On building on stone
Posted by Stefano Mazzocchi <st...@apache.org>.
Pier Fumagalli wrote:
> "Old" blocks can (IMVHO) work just fine in the new container, "New"
> blocks will work a bazillion times better! :-P
Pier hits the nail on the head here: Cocoon's use of Avalon grew over
years and years, like a tectonic plate that while solid in a particular
time frame, over time morphs into thick and revolving crusts.
This doesn't mean that it doesn't work. It does, in fact. But Avalon's
generality and the aim to solve more problems in one shot ended up
harming us, so much so that Cocoon's code is more complex than it needs
to be.
Moreover, because of the way components are loaded, used and released
and how roles are established, there is simply no way we can have hot
deployable dynamic polimorphism.
What does this mean for you?
Well, it's rather simple: old code will work in an avalon sandbox. It
basically means that it will see cocoon *exactly* as it used to be before.
But this will also mean that will be isolated from other blocks and will
not be able, for example, to load components from other blocks.
so, here is a picture
+-------------+ +----------------+
| Cocoon Core |---| Avalon Sandbox |
+-------------+ | +------------+ |
| | | old code | |
| | +------------+ |
| +----------------+
|
| +------------+ +-----------+
+----------| new code |====| new block |
+------------+ +-----------+
So, the question I hear emerging is: why should I migrate my code to the
new core?
The answer will come up shortly.
--
Stefano.
RE: [RT] On building on stone
Posted by Matthew Langham <ml...@s-und-n.de>.
> 3 +1s and no -1s... Enough for me. I'll make that happen! :-P
>
+1 from me as well!
Matthew
Re: [RT] On building on stone
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 24 Mar 2004, at 07:36, Bertrand Delacretaz wrote:
> Le 24 mars 04, à 08:27, Carsten Ziegeler a écrit :
>
>> David Crossley wrote:
>>>
>>> Pier Fumagalli wrote:
>>> ...if this
>>> community at large
>>>> wants to see more of the implementation and what I'm talking about,
>>>> just speak up, and I'll get a formal authorization from my manager
>>>> (until now, confirmation is only verbal).
>>>
>>> Okay, here is one person speaking up. How many do you need?
>>>
>> Yes, let's give it a try! So, Pier, please speak to your manager :)
>
> +1 from out here. That's three, and counting...
3 +1s and no -1s... Enough for me. I'll make that happen! :-P
Pier
Re: [RT] On building on stone
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le 24 mars 04, à 08:27, Carsten Ziegeler a écrit :
> David Crossley wrote:
>>
>> Pier Fumagalli wrote:
>> ...if this
>> community at large
>>> wants to see more of the implementation and what I'm talking about,
>>> just speak up, and I'll get a formal authorization from my manager
>>> (until now, confirmation is only verbal).
>>
>> Okay, here is one person speaking up. How many do you need?
>>
> Yes, let's give it a try! So, Pier, please speak to your manager :)
+1 from out here. That's three, and counting...
-Bertrand
RE: [RT] On building on stone
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
David Crossley wrote:
>
> Pier Fumagalli wrote:
> <snip/>
> >
> > With the invaluable help of Stefano and his vision on blocks, I'm
> > pretty close to a release of the code, and if this
> community at large
> > wants to see more of the implementation and what I'm talking about,
> > just speak up, and I'll get a formal authorization from my manager
> > (until now, confirmation is only verbal).
>
> Okay, here is one person speaking up. How many do you need?
>
Yes, let's give it a try! So, Pier, please speak to your manager :)
Carsten
Re: [RT] On building on stone
Posted by David Crossley <cr...@apache.org>.
Pier Fumagalli wrote:
<snip/>
>
> With the invaluable help of Stefano and his vision on blocks, I'm
> pretty close to a release of the code, and if this community at large
> wants to see more of the implementation and what I'm talking about,
> just speak up, and I'll get a formal authorization from my manager
> (until now, confirmation is only verbal).
Okay, here is one person speaking up. How many do you need?
--David
Re: [RT] On building on stone
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 23 Mar 2004, at 13:45, Bertrand Delacretaz wrote:
>> 2) create an avalon emulation layer for the legacy components that
>> would allow avalon components to run unmodified [this allows users to
>> have a smooth migration path and no immediate impact on their
>> development/mainteinance costs]
>
> Both sound very good assuming someone is able and willing to do the
> work. But I understand you and Pier would have (or already have had)
> energy to contribute.
I had quite a lot of time to spare on it as my employer (as the members
of the PMC know) asked me to lay down the groundwork for our next
back-end platform. And basically, I had to come up with a framework
satisfying certain requirements.
With the invaluable help of Stefano and his vision on blocks, I'm
pretty close to a release of the code, and if this community at large
wants to see more of the implementation and what I'm talking about,
just speak up, and I'll get a formal authorization from my manager
(until now, confirmation is only verbal).
I am sorry for those who are not on the PMC (on the PMC I keep a more
detailed status update, and occasionally post some code snapshots), but
it's not _MY_ code. Yes, I wrote it, but it's my EMPLOYER's code, and
legally I personally don't own it.
- O -
Back from the working bench, right now all I can say is that some of
the contracts WILL HAVE to change in the root container, and Stefano's
100% right, we cannot use the contracts outlined by Avalon4.
That said, I am sure that on an individual block level (forgetting
about infra-block contracts) compatibility can be provided quite easily
by re-wrapping some of the interfaces, providing some extensions, and
doing some sh***y glue-work.
"Old" blocks can (IMVHO) work just fine in the new container, "New"
blocks will work a bazillion times better! :-P
Pier
Re: [RT] On building on stone
Posted by David Crossley <cr...@apache.org>.
Pier Fumagalli wrote:
<snip/>
>
> All they asked me for for is some form of "recognition" if the code
> ends up in Cocoon land (quick quick, go back and modify the @author
> fields in the classes to include VNU Publications), so that they can
> prepare a nice "press release" to please our investors, and they can
> have better discounts when asking for something to be developed by
> Orixo :-) (hi guys! :-P)
Just like anybody else that contributes, the status.xml file
(i.e. Changes) and the CREDITS.txt provide plenty of exposure.
Documentation and examples of use could provide even more.
> My _personal_ requirement, is that I wouldn't want a clean-cut fork to
> happen, because at the end of the day, I'd have to abandon the Cocoon
> fork and get back to the VNU's fork (doh, they pay me).
>
> A directory on the CVS repository which I can check out and build
> without requiring too many dependancies on Cocoon's main "publication
> core" will be more than enough, I can build my own "Ant" build files.
> That would make my (working) life _so_ much easier...
You could just add it to cocoon-2.2 and do whatever you want.
--David
Re: [RT] On building on stone
Posted by Pier Fumagalli <pi...@betaversion.org>.
I keep forgetting to add something...
On 23 Mar 2004, at 13:45, Bertrand Delacretaz wrote:
>> ... 4) keep the framework and container *MINIMAL* to our own needs.
>> [we WILL NOT redistribute the framework independently]..
>
> Sure. But if the next Cocoon Core is sufficiently small (and
> *perceived* as such) and powerful, people might want to use it "just"
> as a container, even for simple things...
My employer doesn't care really about what happens to the code, we're
going to use it anyway as our foundation, whether it's donated to
Cocoon and we maintain our own "fork", whether you guys want it at all
or not... All that VNU cares about is that we deliver a platform based
on _OUR_ blocks (lots of which you will never see in a million years,
because they're core of our business! :-)
BTW, not to scare anyone, I work for a news company
<http://www.vnunet.com/> , not a software company. OUR blocks will be
those blocks linking our websites to our backends (Oracle Databases,
Navision Financials, QuarkDMS publishing environments, and yada yada
yada).
All they asked me for for is some form of "recognition" if the code
ends up in Cocoon land (quick quick, go back and modify the @author
fields in the classes to include VNU Publications), so that they can
prepare a nice "press release" to please our investors, and they can
have better discounts when asking for something to be developed by
Orixo :-) (hi guys! :-P)
My _personal_ requirement, is that I wouldn't want a clean-cut fork to
happen, because at the end of the day, I'd have to abandon the Cocoon
fork and get back to the VNU's fork (doh, they pay me).
A directory on the CVS repository which I can check out and build
without requiring too many dependancies on Cocoon's main "publication
core" will be more than enough, I can build my own "Ant" build files.
That would make my (working) life _so_ much easier...
Pier
Re: [RT] On building on stone
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le 23 mars 04, à 14:25, Stefano Mazzocchi a écrit :
<snip-good-stuff cause="mucho agreement"/>
> ...So, here is my detailed proposal:
>
> 1) implement our own framework and container in order to implement
> cocoon blocks [this creates the solid foundation that we control]
>
> 2) create an avalon emulation layer for the legacy components that
> would allow avalon components to run unmodified [this allows users to
> have a smooth migration path and no immediate impact on their
> development/mainteinance costs]
Both sound very good assuming someone is able and willing to do the
work. But I understand you and Pier would have (or already have had)
energy to contribute.
I think the "in order to implement cocoon blocks" bit is key: although
Avalon is obviously shaky at the moment, the current ECM stuff used
here is very stable and took a lot of work to polish. There must be a
very good reason to replace it, and if it's Real Blocks combined with
pouring concrete where needed, great!
> ... 4) keep the framework and container *MINIMAL* to our own needs.
> [we WILL NOT redistribute the framework independently]..
Sure. But if the next Cocoon Core is sufficiently small (and
*perceived* as such) and powerful, people might want to use it "just"
as a container, even for simple things...
> ...Fire at will: I have my abstesto underwear on.
No need for it as far as I'm concerned. Thanks for your realistic and
respectful point of view.
-Bertrand
Re: [RT] On building on stone
Posted by Stefano Mazzocchi <st...@apache.org>.
Jorg Heymans wrote:
>>
>> Cocoon needs a rock solid core.
>>
>> Solid in both technical, social and legal way.
>>
>
> Stefano,
>
> - i am considering cocoon as the basis for a new product in the next 3
> months. It will be based on 2.1.x, a possible future core migration
> makes me nervous to say the least. My previous decision last year in may
> to use the 2.0.x branch for my project backfired when i now see how much
> easier things could have been with flow, woody etc.
eheh, well, you'll have the same perception next year, trust me ;-)
But at the same time, we will provide a legacy sandbox so that migration
will be easier for you.
Cocoon strives to find a balance between innovation and compatibility.
if you have a better idea on how we can achieve them, I'm all ears!
Really, I'm not sarcastic, I think we all want to make cocoon better but
also make our users happy and feel comfortable with its solidity.
Unfortunatley, these are two forces pointing in the opposite direction
and finding a balance that doesn't tear apart the social structure of
this project is hard and tricky.
I think my plan of action makes a good balance, but, again, I'm very
open to alternative courses of action.
But just like flow and cforms show, it would be a shame to stop the
innovative forces and wonderful creativity that this project and its
community contains.
> - developing the new core will draw developer resources and focus away
> from the 2.1.x branch - right? I know, it's OSS, so i can just jump in
> and fill the gaps where needed. Again makes me nervous.
Keep in mind that the new core will touch code that you have probably
never seen and that you'll never touch yourself. Stuff like the very
deep internals of the sitemap processor, for example, or the cache
mechanism, or how sources are resolved and pipeline assembled.
You wouldn't touch those things anyway, but we are not going to touch
them for 2.1 either because they are rock solid already! [besides the
store leaking, but that's an issue that we'll have to solve anyway and
we may back=port it from 2.1 or viceversa]
My point is: I'm not writing any code at the moment for cocoon, so is
Pier, so is Sylvain, so it's Carsten.... Say we start working on 2.2
*WHILE* everybody keep fixing bugs on cforms and polishes configuration
files and documentation, that does not reduce anything from 2.1
Parallelization is the key.
Today 2.1 reached the architectural limits of what a built-time modular
system can do and this makes it too hard for people to fix things in the
core.
And there is so much to polish in there!
So, to cut it short: 2.2 will not *DRAIN AWAY* forces from 2.1, 2.2 will
unlock forces that 2.1 is already stopping!
> - being able to reuse avalon components in cocoon and vice versa was a
> big selling point for me and made me feel comfortable in choosing cocoon
> as my future preferred container.
Well, dream on. Avalon components have never been reusable across
containers becaus of every container being somewhat different. Also,
Excalibur is going to die, either migrated to jakarta-commons or brought
back in cocoon.
Sure, on paper it looks fantastic and, believe me, that was the original
vision when I proposed Avalon.
But as the name say, this is a mythical place, a dream, a pulsion.
Real life shows that there is no such place and I'm now stopping from
donating resources or limiting ourselves to find a place that I now
believe it doesn't exist.
> Maybe i should go and read your presentation on blocks to see what all
> the fuss is about and why cocoon absolutely can't survive without them.
Well, it took a great deal of time and effort to convince this community
of the power of the sitemap first, then continuations.
I'm ready to keep pushing for real blocks this time, because I think
this is the next major revolution in webapp frameworks.
--
Stefano.
Re: [RT] On building on stone
Posted by Martin Holz <ho...@fiz-chemie.de>.
Jorg Heymans <jh...@domek.be> writes:
> - developing the new core will draw developer resources and focus away
> from the 2.1.x branch - right? I know, it's OSS, so i can just jump in
> and fill the gaps where needed. Again makes me nervous.
Developer resources in Open Source projects are fundamentally different
from those in commercial projects. They are directly related to the
fun in programming. So the new core may generate additional resources.
However there are lots of existing cocoon applications so 2.1
will be activly maintained for quite a while,unless all
developers consider migration to 2.2 trivial.
Martin
Re: [RT] On building on stone
Posted by Jorg Heymans <jh...@domek.be>.
>
> Cocoon needs a rock solid core.
>
> Solid in both technical, social and legal way.
>
Stefano,
- i am considering cocoon as the basis for a new product in the next 3
months. It will be based on 2.1.x, a possible future core migration
makes me nervous to say the least. My previous decision last year in may
to use the 2.0.x branch for my project backfired when i now see how much
easier things could have been with flow, woody etc.
- developing the new core will draw developer resources and focus away
from the 2.1.x branch - right? I know, it's OSS, so i can just jump in
and fill the gaps where needed. Again makes me nervous.
- being able to reuse avalon components in cocoon and vice versa was a
big selling point for me and made me feel comfortable in choosing cocoon
as my future preferred container.
Maybe i should go and read your presentation on blocks to see what all
the fuss is about and why cocoon absolutely can't survive without them.
Regards
Jorg
Re: [RT] On building on stone
Posted by Steven Noels <st...@outerthought.org>.
On 23 Mar 2004, at 14:25, Stefano Mazzocchi wrote:
> Thus the proposal to write and maintain our own, in order to finally,
> once and for all, build on stone and escape the social quicksands in
> core depenendies.
Makes perfect sense to me. I guess we should look at our current
investment in ECM knowledge & code, look at Pier's alternative, and
basically decide and JFDI. We gave Avalon a loyal "customer" to deal
with in the past, but there never was a life-time engagement contract.
We already missed various new container efforts over @ Avalon, and I'm
confident we now know what we need and are able to build it ourselves
in the (new) core of Cocoon. Given the flurry of new containers out
there, I think people are demonstrating that container development is
not rocket science - and since it's core to Cocoon's operations, it's
sensible to deal with that ourselves.
There will be aspects of backward-compatibility to deal with, which we
can deal with by providing compatibility layers, or by just going for
Cocoon 3.0. 2.1 is there, it's solid and used a lot, and if there's
consensus that innovation should not be hindered by compatibility, we
can simply vote and start 3.0. I would humbly suggest not to change the
syntax of the sitemap into Lisp, though. ;-)
> Fire at will: I have my abstesto underwear on.
I honestly see no reason why. Thanks for biting the bullet, and even
more thanks to step up and agree to do part of the coding effort. I
hope many will join you.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [RT] On building on stone
Posted by Thor Heinrichs-Wolpert <th...@lunartek.com>.
Possibly, but JMX is also used to load and unload components. If the
API matched, I can replace any component at runtime with a simple
config change.
JMX forms the kernel of JBOSS to handle all of it's inter-core loading
and can act as a runtime message-plane for communicating between
components.
It has more to it than just the ability to see into objects or
components through an MBean.
In the product I was referring to, we just update the config of the
server in its datastore (JMX allows us to use flat files, XML files and
databases if the API is consistent for the component) and then message
the backplane to reload, change, alter, download new components in
jars, etc. all at runtime. The one thing we are adding in is MD5Urls
which is a new thing in the Jini API allowing us to distinguish between
different versions of similarly named jars.
So I think JMX can be a bolt on, or an underpinning depending on how
you use it. I'd be surprised if it didn't meet the core of what you
described blocks needed. If a block has a consistent API (Interface)
then any block that supports that API could be loaded/unloaded and
messaged to from other components using the JMX services and usage
guidelines.
Thoughts?
Thor HW
On 25-Mar-04, at 7:16 AM, Stefano Mazzocchi wrote:
> Thor Heinrichs-Wolpert wrote:
>
>> Sounds good ... as you may remember when you started to talk about
>> Blocks in Ghent we started talking about JMX then as well. It may
>> not have everything you want or need, but it does have some good
>> points and a basic lifecycle. I believe that MX4J
>> (http://mx4j.sourceforge.net/) is released under an Apache license
>> and is also being used in Geronimo. I think it would be worth
>> examining it as a piece of the Core needed for blocks.
>> I can say that in a previous commercial endeavour I used JMX as the
>> core to manage all of the component loading, monitoring and
>> distribution.
>> I'm willing to pitch in here ... and after March 29th able to as well.
>
> Thor,
>
> there is a great deal of value in having a JMX wrapper around our
> blocks, but just to let JMX do what JMX is supposed to: remote
> management and configuration.
>
> At the same time, I think JXM is not capable of doing what we need for
> cocoon blocks, so it cannot be used as the core and, even more
> important, it's not something we control.
>
> The important thing is both stability of our foundations and the
> ability to evolve them (without passing thru a massive world-impacting
> political JSR).
>
> --
> Stefano.
>
Re: [RT] On building on stone
Posted by Stefano Mazzocchi <st...@apache.org>.
Thor Heinrichs-Wolpert wrote:
> Sounds good ... as you may remember when you started to talk about
> Blocks in Ghent we started talking about JMX then as well. It may not
> have everything you want or need, but it does have some good points and
> a basic lifecycle. I believe that MX4J (http://mx4j.sourceforge.net/)
> is released under an Apache license and is also being used in Geronimo.
> I think it would be worth examining it as a piece of the Core needed
> for blocks.
>
> I can say that in a previous commercial endeavour I used JMX as the core
> to manage all of the component loading, monitoring and distribution.
>
> I'm willing to pitch in here ... and after March 29th able to as well.
Thor,
there is a great deal of value in having a JMX wrapper around our
blocks, but just to let JMX do what JMX is supposed to: remote
management and configuration.
At the same time, I think JXM is not capable of doing what we need for
cocoon blocks, so it cannot be used as the core and, even more
important, it's not something we control.
The important thing is both stability of our foundations and the ability
to evolve them (without passing thru a massive world-impacting political
JSR).
--
Stefano.
Re: [RT] On building on stone
Posted by Thor Heinrichs-Wolpert <th...@lunartek.com>.
Sounds good ... as you may remember when you started to talk about
Blocks in Ghent we started talking about JMX then as well. It may not
have everything you want or need, but it does have some good points and
a basic lifecycle. I believe that MX4J (http://mx4j.sourceforge.net/)
is released under an Apache license and is also being used in Geronimo.
I think it would be worth examining it as a piece of the Core needed
for blocks.
I can say that in a previous commercial endeavour I used JMX as the
core to manage all of the component loading, monitoring and
distribution.
I'm willing to pitch in here ... and after March 29th able to as well.
Cheers,
Thor HW
Re: [RT] On building on stone
Posted by Antonio Gallardo <ag...@agssa.net>.
Bertrand Delacretaz dijo:
> IMHO the current perception that Cocoon is a "big thing" is largely due
> to the complexity imposed by Avalon, and this will go away with a
> simpler container framework. We'll just have to adjust our user's
> perceptions once this is realized ;-)
+1 I believe that.
Best Regards,
Antonio Gallardo
Re: [RT] On building on stone
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le 24 mars 04, à 18:53, Peter Brant a écrit :
> (also from a normal-developer-user perspective) I agree with Jorg that
> it's
> really nifty to be able to reuse my Cocoon components outside of a
> Cocoon/Web-oriented environment. It would be great to retain this
> ability regardless
> of the results of this discussion.
If the Cocoon Core becomes sufficiently small and simple (and I believe
it will given the right container), it won't matter much if you use it
without requiring the web features.
IMHO the current perception that Cocoon is a "big thing" is largely due
to the complexity imposed by Avalon, and this will go away with a
simpler container framework. We'll just have to adjust our user's
perceptions once this is realized ;-)
-Bertrand
Re: [RT] On building on stone
Posted by Peter Brant <pm...@gmx.at>.
(also from a normal-developer-user perspective) I agree with Jorg that it's
really nifty to be able to reuse my Cocoon components outside of a
Cocoon/Web-oriented environment. It would be great to retain this ability regardless
of the results of this discussion.
Pete
> agree, YAC(tm) Yet Another Container to learn - now that i grasped the
> avalon stuff and was going to start using it heavily on other projects
> as well (and reusing my cocoon avalon components on the way - nifty!).
>
--
+++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++
100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz
Re: [RT] On building on stone
Posted by Jorg Heymans <jh...@domek.be>.
>
> * Increasing burden on potential users in that they have to learn
> yet another container. As several folks have pointed out, there
> are many containers. Too many for anyone developer to ever really
> understand.
>
agree, YAC(tm) Yet Another Container to learn - now that i grasped the
avalon stuff and was going to start using it heavily on other projects
as well (and reusing my cocoon avalon components on the way - nifty!).
This thread makes me wonder if i should still invest any time in Avalon
based development at all. All this negative stuff about its community
and future is not so visible to normal-developer-user eyes, well for me
it was an eye-opener (pun intented).
Jorg
RE: [RT] On building on stone
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
> <SNIP/>
>
> So, here is my detailed proposal:
>
> 1) implement our own framework and container in order to
> implement cocoon blocks [this creates the solid foundation
> that we control]
>
> 2) create an avalon emulation layer for the legacy
> components that would allow avalon components to run
> unmodified [this allows users to have a smooth migration path
> and no immediate impact on their development/mainteinance costs]
>
> 3) operate as incrementally as possible and work to change
> as little code as possible [this makes the community
> transition smoother, reduces enthropy and bugs introduced by
> the new code]
>
> 4) keep the framework and container *MINIMAL* to our own
> needs. [we WILL NOT redistribute the framework independently]
>
> 5) the name for our framework+container will be simply Cocoon Core
>
> 6) I volunteer to help directly in writing code
>
+100 for all points ,especially for point 2)
The container is our core and it is much easier and also safer to
maintain our own container than to rely on someone else. In the past
years we always had to struggle each time the used container changed
in an unforseeable way. With our own container, our core is
independent. Great!
Carsten
Re: [RT] On building on stone
Posted by Jean Pierre LeJacq <jp...@quoininc.com>.
On Wed, 24 Mar 2004, Pier Fumagalli wrote:
> On 24 Mar 2004, at 16:43, Jean Pierre LeJacq wrote:
>
> > Clearly, if Avalon simply is insufficient, then an alternative should
> > be found.
>
> And what if an alternative is not there?
Then building makes sense.
--
JP
Re: [RT] On building on stone
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 24 Mar 2004, at 16:43, Jean Pierre LeJacq wrote:
> Clearly, if Avalon simply is insufficient, then an alternative should
> be found.
And what if an alternative is not there?
Pier
Re: [RT] On building on stone
Posted by Jean Pierre LeJacq <jp...@quoininc.com>.
On Tue, 23 Mar 2004, Stefano Mazzocchi wrote:
> 1) patch avalon
> 2) change framework
> 3) do our own
>
> Here my choice would not be technologically driven but rather socially
> driven: I would do our own.
I see some significant disadvantages for cocoon to develop its own
container framework.
* Diversion of resources to build and support the container.
* Loss of extensive experience of other container developers.
Building a robust and high performance container is not trivial.
* Increasing burden on potential users in that they have to learn
yet another container. As several folks have pointed out, there
are many containers. Too many for anyone developer to ever really
understand.
All of these point to the community aspect of the goals Stefano
stated. My strong preference would be to build on top of an
existing container that is widely used. This helps build a larger
community. Clearly, if Avalon simply is insufficient, then an
alternative should be found. Why not select another?
--
JP