You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Gerhard Froehlich <ge...@at.ibm.com> on 2002/07/01 14:40:51 UTC
Re: Separation to Phoenix and Avalon 5 [was Re: [RT] Cocoon Blocks]
>Gerhard Froehlich wrote:
>>
>> Hi Stefano,
>> can you give a clear separation to Phoenix and Avalon 5?
>
>Sorry, I can't really parse the question.
>
>What do you mean?
Oh sorry. I was a little bit in a hurry at the weekend.
I follow two main architectural discussions in the moment:
(1) The Avalon 5 Design on the Avalon dev. list
(2) Cocoon Block Design here
Both approaches want the same:
"Provide a component oriented framework, where you can easy plugin
Components
on runtime".
I know there are lot of Cocoon and Avalon related details in this two
concepts,
but this is IMHO the common denominator.
Peter Donald and Berin Loritsch wrote interesting RTs last days and I see
lot of parallels to your COB proposal:
<http://marc.theaimsgroup.com/?l=avalon-dev&m=102513578616579&w=2>
<http://marc.theaimsgroup.com/?l=avalon-dev&m=102449360809559&w=2>
Therefor I'm little bit concerned that we have double functionality in the
future,
especialy when Avalon 5 is coming. I'm concerned that we have a framework
in a
framework, which IMAO doesn't make things easier than now:
My worst scenario:
As a Cocoon 3.0 Developer I must develop my Cocoon components as Avalon 5
components
and promote them to the internal Avalon 5 ComponentContainer with the
special
Avalon procedure.
In a second step I have to promote the Cocoon components to the Cocoon
Kernel or whatever
with the special Cocoon procedure.
You see what I mean?
But I'm sure that you already made your thoughts about this topic. I just
want
to hear your opinion and maybe you can sweep off my concerns in one
sentence :-).
What I want is a short comparsion of this two architecures dicussions in
the moment.
Greets
Gerhard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Separation to Phoenix and Avalon 5 [was Re: [RT] Cocoon Blocks]
Posted by Andy Lewis <aj...@ascii27.net>.
Thanks...got it...I think.
I'll be interested to hear how the research comes out....
> Andy Lewis wrote:
>
>> If I have a custom transformer or generator that I wanted to deploy as a part of Coccon block,
>> can I using that interface? And is it an Avalon component or not? Are there adidtional steps
>> beyond just making it a cocoon block?
>
> Sitemap components follow the avalon lifecycles but aren't exactly 'avalon components' because
> they are intrinsically tight to the cocoon interfaces.
>
> The question you should ask yourself when deciding if something is an avalon component is:
>
> can I deploy my component in another avalon container? (say, Phoenix?)
>
> If you look into org.apache.cocoon.components many of them are avalon components that could be
> ported to other containers (even the
> 'programminglanguage' component, the core of the XSP engine, could be decoupled from Cocoon and
> used elsewhere).
>
> But a 'sitemap component', by design, isn't portable.
>
> Also, another difference is that while avalon components are accessed by role (thus behavior)
> and it's the container's concern to look it up, sitemap components are accessed by both role
> and hint, thus it is *not* the container's concern to look up the class (its concern is only to
> map the hint to the classname, but control is re-inverted back).
>
> On avalon-dev we had a pretty serious (and painful) discussion about this and it has been
> suggested that Cocoon has been using Avalon for its lifecycle (configurable, loggable, etc..)
> more than for its inverted lookup capabilities. So Avalon has been used *and* abused by this
> project.
>
> Used for moveable components and abused for those cocoon-specific
> components.
>
> This said, it becomes obvious why we need two different deployment mechanism: one for generic
> avalon components (think of Parsers, XSLT Processors, Source Resolvers, Code Producers, etc..),
> and another for cocoon-specific stuff (think of a web mail, a skin, a shopping cart, etc..).
>
> The question was: even if these two things are different and live in two different
> architectural layers, could the same code be used to implement both?
>
> I've spent some time investigating this and I don't think Phoenix is up to the job, because it
> is more biased toward having a single instance per JVM.
>
> Now I'm looking at Fortress and Merlin as possible future candidates.
>
> I'll report back when I'm done.
>
> Stefano.
>
>
>
> --------------------------------------------------------------------- To unsubscribe, e-mail:
> cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
--
"The heights of genius are only measurable by the depths of stupidity."
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Separation to Phoenix and Avalon 5 [was Re: [RT] Cocoon Blocks]
Posted by Stefano Mazzocchi <st...@apache.org>.
Andy Lewis wrote:
> If I have a custom transformer or generator that I wanted to deploy as a part of Coccon block, can
> I using that interface? And is it an Avalon component or not? Are there adidtional steps beyond
> just making it a cocoon block?
Sitemap components follow the avalon lifecycles but aren't exactly
'avalon components' because they are intrinsically tight to the cocoon
interfaces.
The question you should ask yourself when deciding if something is an
avalon component is:
can I deploy my component in another avalon container? (say, Phoenix?)
If you look into org.apache.cocoon.components many of them are avalon
components that could be ported to other containers (even the
'programminglanguage' component, the core of the XSP engine, could be
decoupled from Cocoon and used elsewhere).
But a 'sitemap component', by design, isn't portable.
Also, another difference is that while avalon components are accessed by
role (thus behavior) and it's the container's concern to look it up,
sitemap components are accessed by both role and hint, thus it is *not*
the container's concern to look up the class (its concern is only to map
the hint to the classname, but control is re-inverted back).
On avalon-dev we had a pretty serious (and painful) discussion about
this and it has been suggested that Cocoon has been using Avalon for its
lifecycle (configurable, loggable, etc..) more than for its inverted
lookup capabilities. So Avalon has been used *and* abused by this
project.
Used for moveable components and abused for those cocoon-specific
components.
This said, it becomes obvious why we need two different deployment
mechanism: one for generic avalon components (think of Parsers, XSLT
Processors, Source Resolvers, Code Producers, etc..), and another for
cocoon-specific stuff (think of a web mail, a skin, a shopping cart,
etc..).
The question was: even if these two things are different and live in two
different architectural layers, could the same code be used to implement
both?
I've spent some time investigating this and I don't think Phoenix is up
to the job, because it is more biased toward having a single instance
per JVM.
Now I'm looking at Fortress and Merlin as possible future candidates.
I'll report back when I'm done.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Separation to Phoenix and Avalon 5 [was Re: [RT] Cocoon Blocks]
Posted by Andy Lewis <aj...@ascii27.net>.
<snip />
>
> So, I picture Cocoon being (or containing) two different containers:
>
> - an avalon component container (could be Fortress or Merlin)
> - a cocoon block container (could be based on Phoenix or we make our
> own)
>
> In that case, the way you write, use and deploy 'avalon components' in Cocoon and in all other
> avalon containers is one thing. And this is totally independent on how your write, use and
> deploy 'cocoon blocks', which behave on a completely different level.
>
> At least, this is my vision ATM, but I'm wide open to suggestions, expecially if they make it
> easier to implement the concept of cocoon blocks :)
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
Ok...I could be just completely lost here...but....
If I have a custom transformer or generator that I wanted to deploy as a part of Coccon block, can
I using that interface? And is it an Avalon component or not? Are there adidtional steps beyond
just making it a cocoon block?
--
"The heights of genius are only measurable by the depths of stupidity."
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Separation to Phoenix and Avalon 5 [was Re: [RT] Cocoon Blocks]
Posted by Stefano Mazzocchi <st...@apache.org>.
Gerhard Froehlich wrote:
>
> >Gerhard Froehlich wrote:
> >>
> >> Hi Stefano,
> >> can you give a clear separation to Phoenix and Avalon 5?
> >
> >Sorry, I can't really parse the question.
> >
> >What do you mean?
>
> Oh sorry. I was a little bit in a hurry at the weekend.
>
> I follow two main architectural discussions in the moment:
>
> (1) The Avalon 5 Design on the Avalon dev. list
> (2) Cocoon Block Design here
>
> Both approaches want the same:
> "Provide a component oriented framework, where you can easy plugin
> Components
> on runtime".
> I know there are lot of Cocoon and Avalon related details in this two
> concepts,
> but this is IMHO the common denominator.
>
> Peter Donald and Berin Loritsch wrote interesting RTs last days and I see
> lot of parallels to your COB proposal:
> <http://marc.theaimsgroup.com/?l=avalon-dev&m=102513578616579&w=2>
> <http://marc.theaimsgroup.com/?l=avalon-dev&m=102449360809559&w=2>
>
> Therefor I'm little bit concerned that we have double functionality in the
> future,
> especialy when Avalon 5 is coming. I'm concerned that we have a framework
> in a
> framework, which IMAO doesn't make things easier than now:
>
> My worst scenario:
> As a Cocoon 3.0 Developer I must develop my Cocoon components as Avalon 5
> components
> and promote them to the internal Avalon 5 ComponentContainer with the
> special
> Avalon procedure.
> In a second step I have to promote the Cocoon components to the Cocoon
> Kernel or whatever
> with the special Cocoon procedure.
>
> You see what I mean?
>
> But I'm sure that you already made your thoughts about this topic. I just
> want
> to hear your opinion and maybe you can sweep off my concerns in one
> sentence :-).
> What I want is a short comparsion of this two architecures dicussions in
> the moment.
Ah, ok.
I promised Sylvain to come up with a detailed answer to the overlap
between these two efforts and I will, but for new let me give you a
short description of what it is my vision of the concept.
- o -
First of all, Cocoon blocks adopt the exact same design concepts of
Avalon Blocks, in fact, this is why they share the name.
Also, they share the fact that 'hints' are considered harmful: the
container should be in control of module lookup and should not be
'hinted' by the components, or the control is 'reinverted' and SoC is
broken.
Even if many things are shared, there are some differences: mainly, the
block behavior is identified by an interface, which is the service
descriptor.
This could be abstract in Avalon so that the descripting contract could
be either a java interface, a WSDL file or a cocoon sitemap. This is
something we could propose to the Avalon people at the framework level.
The question on the table is:
will it be possible to reuse an avalon container (say Phoenix) to
deploy cocoon blocks?
I honestly have no idea and I'm going to investigate this and ask around
how difficult this could be. This said, I'm all in favor of sharing code
since I'm lazy and I don't want to write it myself :) (these deep
classloading issues are pretty nasty to debug! I've done it once for
JServ and if I can avoid doing it again I'll be happy)
At the same time, those avalon block containers (phonenix, for example)
are not designed to be 'embeddable', but are designed to be called
directly from command line (so they might not be friendly about several
instances running on the same JVM. We'll see (I'll ask avalon-dev about
it).
But there is something to note:
> My worst scenario:
> As a Cocoon 3.0 Developer I must develop my Cocoon components as Avalon 5
> components
> and promote them to the internal Avalon 5 ComponentContainer with the
> special
> Avalon procedure.
> In a second step I have to promote the Cocoon components to the Cocoon
> Kernel or whatever
> with the special Cocoon procedure.
Careful here: first of all, Avalon Blocks were deprecated. They are
talking about 'components'. So, there is a big difference between a
Cocoon Block and an Avalon Component: the first is mostly a sitemap
which exposes a web service, the second is some logic which exposes a
service callable by the program.
So, first of all, it doesn't make any sense to make a 'Cocoon Block'
deployable in, say, James run by Phoenix. It doesn't make sense because
a Cocoon Block uses the sitemap (which is a cocoon-specific concept) as
an interface with the outside of the module.
So, I picture Cocoon being (or containing) two different containers:
- an avalon component container (could be Fortress or Merlin)
- a cocoon block container (could be based on Phoenix or we make our
own)
In that case, the way you write, use and deploy 'avalon components' in
Cocoon and in all other avalon containers is one thing. And this is
totally independent on how your write, use and deploy 'cocoon blocks',
which behave on a completely different level.
At least, this is my vision ATM, but I'm wide open to suggestions,
expecially if they make it easier to implement the concept of cocoon
blocks :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org