You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2004/04/05 15:29:42 UTC
[Kernel22] How to develop a component?
I'm trying to figure out what the current kernel already provides
and what not.
Let's forget all the xml (descriptors etc) for a moment. Imagine I
want to write a block, that provides - let's say a special file
generator - that can be used in other blocks (in my app block).
Now, obviously this generator will implement our Cocoon Generator interface.
What else does the kernel already provide for the component lifecycle?
(Logging, Configuration etc.)
Or is this a to discuss/do?
Carsten
Re: [Kernel22] How to develop a component?
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> Gianugo Rabellino wrote:
>
>>Carsten Ziegeler wrote:
>>
>>>I'm trying to figure out what the current kernel already
>>
>>provides and
>>
>>>what not.
>>>
>>>Let's forget all the xml (descriptors etc) for a moment. Imagine I
>>>want to write a block, that provides - let's say a special file
>>>generator - that can be used in other blocks (in my app block).
>>>
>>>Now, obviously this generator will implement our Cocoon
>>
>>Generator interface.
>>
>>>What else does the kernel already provide for the component
>>
>>lifecycle?
>>
>>>(Logging, Configuration etc.)
>>>
>>>Or is this a to discuss/do?
>>
>>JFYI, Pier is in vacation ATM, so you're better not hold your
>>breath... :-)
>>
>
> Ah, thanks! I thought there are perhaps more people out there (Stefano?)
> that know the answer.
pretty busy these days, will try to catch up later.
--
Stefano.
RE: [Kernel22] How to develop a component?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Gianugo Rabellino wrote:
>
> Carsten Ziegeler wrote:
> > I'm trying to figure out what the current kernel already
> provides and
> > what not.
> >
> > Let's forget all the xml (descriptors etc) for a moment. Imagine I
> > want to write a block, that provides - let's say a special file
> > generator - that can be used in other blocks (in my app block).
> >
> > Now, obviously this generator will implement our Cocoon
> Generator interface.
> > What else does the kernel already provide for the component
> lifecycle?
> > (Logging, Configuration etc.)
> >
> > Or is this a to discuss/do?
>
> JFYI, Pier is in vacation ATM, so you're better not hold your
> breath... :-)
>
Ah, thanks! I thought there are perhaps more people out there (Stefano?)
that know the answer.
Carsten
Re: [Kernel22] How to develop a component?
Posted by Gianugo Rabellino <gi...@apache.org>.
Carsten Ziegeler wrote:
> I'm trying to figure out what the current kernel already provides
> and what not.
>
> Let's forget all the xml (descriptors etc) for a moment. Imagine I
> want to write a block, that provides - let's say a special file
> generator - that can be used in other blocks (in my app block).
>
> Now, obviously this generator will implement our Cocoon Generator interface.
> What else does the kernel already provide for the component lifecycle?
> (Logging, Configuration etc.)
>
> Or is this a to discuss/do?
JFYI, Pier is in vacation ATM, so you're better not hold your breath... :-)
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
(Blogging at: http://www.rabellino.it/blog/)
Re: [Kernel22] How to develop a component?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote:
...
> I think it's a good time for cleaning up what avalon did wrong, simplify
> as much as we can and tune it for our needs.
>
> But I'm wide open to suggestions, as long as we move away from avalon.
A bit OT... I can't stand Cocoon not be able to build properly in Gump,
and IMHO getting away from Avalon will greatly help in this.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [Kernel22] How to develop a component?
Posted by Steven Noels <st...@outerthought.org>.
On 08 Apr 2004, at 14:50, Stefano Mazzocchi wrote:
> At the same time, to put it rather explicitly: I don't want anything
> in org.apache.avalon.* to be a core dependency of org.apache.cocoon.*
> anymore because I don't trust avalon anymore: avalon is quicksand and
> you can't expect it to be there tomorrow in the same shape you want it
> to be.
I think many people agree on the fact that we shouldn't depend on the
Avalon products/containers anymore for Cocoon core operations. Some
would like compatibility to run existing components as-is, which seems
not trivial and shouldn't slow down the innovation train. OTOH, we
cannot simply throw the good ideas behind Avalon's lifecycle management
and container services away just because their method signatures carry
the org.apache.avalon name, no?
</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: [Kernel22] How to develop a component?
Posted by Stefano Mazzocchi <st...@apache.org>.
Reinhard Pötz wrote:
>> So, like we already said before, it is *totally* possible to have a
>> block load avalon components thru an avalon sandbox (sort of a
>> avalon->cocoon adapter). This allows you to reuse your avalon stuff
>> "AS IS". But this also means that your block cannot expose those
>> components outside of that block.
>
> Are there reasons that prevent me from writting a 'block wrapper' which
> can be exposed?
good question... I don't know :-)
Look: at the very end, I have no problems in having all sorts of
machinery to have avalon components run AS IS in cocoon 2.2. I believe
it to be a monumental PITA to do correctly, given the avalon 4.x way of
doing stuff (keep in mind that avalon is older than cocoon and was
designed on a java 1.1 JVM, in some senses is archaic), but I would love
to be proven wrong.
At the same time, to put it rather explicitly: I don't want anything in
org.apache.avalon.* to be a core dependency of org.apache.cocoon.*
anymore because I don't trust avalon anymore: avalon is quicksand and
you can't expect it to be there tomorrow in the same shape you want it
to be.
--
Stefano.
Re: [Kernel22] How to develop a component?
Posted by Reinhard Pötz <re...@apache.org>.
Stefano Mazzocchi wrote:
> Sylvain Wallez wrote:
>
>> Nicola Ken Barozzi wrote:
>>
>>> Carsten Ziegeler wrote:
>>> ...
>>>
>>>>> I strongly suggest that we start with org.apache.cocoon.* to avoid
>>>>> these problems down the road (including, yes, gump problems)
>>>>
>>>>
>>>>
>>>>
>>>> Yes, I understand of course all these problems, but I'm really afraid
>>>> of changing all the components now from Avalon interfaces to Cocoon
>>>> interfaces which are more or less the same but just use a different
>>>> package. In that case these components run in Cocoon but not in any
>>>> other container anymore that provides Avalon compatibility. And
>>>> that's imho bad. Not every project uses Cocoon, so it's absolutely
>>>> preferable to have components that I can use in several projects.
>>>>
>>>> Ok, I think if we decide to use our own versions of the interfaces it
>>>> will still be possible to do some hacky things and still provide
>>>> compatilibity with the Avalon versions.
>>>>
>>>> So what do others think?
>>>
>>>
>>>
>>>
>>> Cocoon components will never work putside of Cocoon.
>>> Non-cocoon components should not use the Cocoon interfaces.
>>>
>>> I don't see the problem, as long as we don't mix all like we did
>>> with Avalon.
>>
>>
>>
>>
>> IMO, the answer isn't so simple. A lot of people chose to use Avalon
>> interfaces to implement component-based systems, especially for
>> components related to business logic. These components can run inside
>> Cocoon, but not only. And this choice was made possible because the
>> COP-related interfaces are defined by outside of Cocoon, i.e. they
>> aren't tied to the web tier in a more global architecture.
>>
>> Now what if COP-related interfaces are defined within Cocoon? People
>> are left alone to write their business-related components. This is a
>> giant step back.
>>
>>
>> Also, I think the block kernel and ECM serve different complementary
>> purposes. The kernel is useful to implement coarse-grained entities
>> (blocks) that can be hotdeployed and hotswapped. ECM is useful to
>> implement fine-grained entities (components) that need to be
>> configured, eventually pooled, etc. But ECM-managed components aren't
>> individually hotswappable (they don't need to).
>>
>> So we can consider that there actually exists two levels of
>> containement. Blocks are managed by the kernel, and components are
>> managed by an ECM-type container, which, being part of a block is
>> itself managed by the kernel.
>>
>> This approach has the benefit of being an evolutionary path of what
>> we have today and still allows people to benefit from COP interfaces
>> to implement their own components, be them integrated into Cocoon or
>> not.
>>
>> WDYT?
>
>
> On paper, yes, but in real life it's not so simple.
>
> Avalon/ECM cannot define hotswappable components. This means that if
> your block has ECM components they cannot be exposed to other blocks,
> otherwise they would create "hard wires" between the two components
> that will not allow the blocks to be hotswappable.
>
> So, like we already said before, it is *totally* possible to have a
> block load avalon components thru an avalon sandbox (sort of a
> avalon->cocoon adapter). This allows you to reuse your avalon stuff
> "AS IS". But this also means that your block cannot expose those
> components outside of that block.
Are there reasons that prevent me from writting a 'block wrapper' which
can be exposed?
> This *is* already planned and allows you to keep your existing stuff,
> but there is no way you can have the avalon interfaces cooperate with
> the existing cocoon kernel functionality because of the intrinsic
> nature of an hotswappale mechanism.
>
--
Reinhard
RE: [Kernel22] How to develop a component?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> So, like we already said before, it is *totally* possible to have a
> block load avalon components thru an avalon sandbox (sort of a
> avalon->cocoon adapter). This allows you to reuse your avalon
> stuff "AS IS". But this also means that your block cannot expose those
> components outside of that block.
I don't think so.
The fact that Avalon doesn't support hotswap in all cases does
not mean that you can't write Avalon components that do support
such a thing.
Look at Composer.acquire() - does it matter if the object
returned is a proxy to some internal Avalon object? No!
You can have:
+Block-------------------------------------------+
| +-+Component |
| +Composer--+ +ECM----+ | |
| | |----| |--+-+Component |
| +----------+ +-------+ | |
| +-+Component |
+------------------------------------------------+
And then expose the components managed by the ECM via a proxy.
However, those components must either:
...be written in such a way as to support the additional
requirements that Cocoon has
...or have that functionality added via proxying etc.
So I think Carsten's (and my) business logic, and all our Avalon
components that we use across multiple projects and containers
are perfectly safe.
/LS
Re: [Kernel22] How to develop a component?
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Nicola Ken Barozzi wrote:
>
>> Carsten Ziegeler wrote:
>> ...
>>
>>>> I strongly suggest that we start with org.apache.cocoon.* to avoid
>>>> these problems down the road (including, yes, gump problems)
>>>
>>>
>>>
>>> Yes, I understand of course all these problems, but I'm really afraid
>>> of changing all the components now from Avalon interfaces to Cocoon
>>> interfaces which are more or less the same but just use a different
>>> package. In that case these components run in Cocoon but not in any
>>> other container anymore that provides Avalon compatibility. And
>>> that's imho bad. Not every project uses Cocoon, so it's absolutely
>>> preferable to have components that I can use in several projects.
>>>
>>> Ok, I think if we decide to use our own versions of the interfaces it
>>> will still be possible to do some hacky things and still provide
>>> compatilibity with the Avalon versions.
>>>
>>> So what do others think?
>>
>>
>>
>> Cocoon components will never work putside of Cocoon.
>> Non-cocoon components should not use the Cocoon interfaces.
>>
>> I don't see the problem, as long as we don't mix all like we did with
>> Avalon.
>
>
>
> IMO, the answer isn't so simple. A lot of people chose to use Avalon
> interfaces to implement component-based systems, especially for
> components related to business logic. These components can run inside
> Cocoon, but not only. And this choice was made possible because the
> COP-related interfaces are defined by outside of Cocoon, i.e. they
> aren't tied to the web tier in a more global architecture.
>
> Now what if COP-related interfaces are defined within Cocoon? People are
> left alone to write their business-related components. This is a giant
> step back.
>
>
> Also, I think the block kernel and ECM serve different complementary
> purposes. The kernel is useful to implement coarse-grained entities
> (blocks) that can be hotdeployed and hotswapped. ECM is useful to
> implement fine-grained entities (components) that need to be configured,
> eventually pooled, etc. But ECM-managed components aren't individually
> hotswappable (they don't need to).
>
> So we can consider that there actually exists two levels of
> containement. Blocks are managed by the kernel, and components are
> managed by an ECM-type container, which, being part of a block is itself
> managed by the kernel.
>
> This approach has the benefit of being an evolutionary path of what we
> have today and still allows people to benefit from COP interfaces to
> implement their own components, be them integrated into Cocoon or not.
>
> WDYT?
On paper, yes, but in real life it's not so simple.
Avalon/ECM cannot define hotswappable components. This means that if
your block has ECM components they cannot be exposed to other blocks,
otherwise they would create "hard wires" between the two components that
will not allow the blocks to be hotswappable.
So, like we already said before, it is *totally* possible to have a
block load avalon components thru an avalon sandbox (sort of a
avalon->cocoon adapter). This allows you to reuse your avalon stuff "AS
IS". But this also means that your block cannot expose those components
outside of that block.
This *is* already planned and allows you to keep your existing stuff,
but there is no way you can have the avalon interfaces cooperate with
the existing cocoon kernel functionality because of the intrinsic nature
of an hotswappale mechanism.
--
Stefano.
Re: [Kernel22] How to develop a component?
Posted by Sylvain Wallez <sy...@apache.org>.
Nicola Ken Barozzi wrote:
> Carsten Ziegeler wrote:
> ...
>
>>> I strongly suggest that we start with org.apache.cocoon.* to avoid
>>> these problems down the road (including, yes, gump problems)
>>
>>
>> Yes, I understand of course all these problems, but I'm really afraid
>> of changing all the components now from Avalon interfaces to Cocoon
>> interfaces which are more or less the same but just use a different
>> package. In that case these components run in Cocoon but not in any
>> other container anymore that provides Avalon compatibility. And
>> that's imho bad. Not every project uses Cocoon, so it's absolutely
>> preferable to have components that I can use in several projects.
>>
>> Ok, I think if we decide to use our own versions of the interfaces it
>> will still be possible to do some hacky things and still provide
>> compatilibity with the Avalon versions.
>>
>> So what do others think?
>
>
> Cocoon components will never work putside of Cocoon.
> Non-cocoon components should not use the Cocoon interfaces.
>
> I don't see the problem, as long as we don't mix all like we did with
> Avalon.
IMO, the answer isn't so simple. A lot of people chose to use Avalon
interfaces to implement component-based systems, especially for
components related to business logic. These components can run inside
Cocoon, but not only. And this choice was made possible because the
COP-related interfaces are defined by outside of Cocoon, i.e. they
aren't tied to the web tier in a more global architecture.
Now what if COP-related interfaces are defined within Cocoon? People are
left alone to write their business-related components. This is a giant
step back.
Also, I think the block kernel and ECM serve different complementary
purposes. The kernel is useful to implement coarse-grained entities
(blocks) that can be hotdeployed and hotswapped. ECM is useful to
implement fine-grained entities (components) that need to be configured,
eventually pooled, etc. But ECM-managed components aren't individually
hotswappable (they don't need to).
So we can consider that there actually exists two levels of
containement. Blocks are managed by the kernel, and components are
managed by an ECM-type container, which, being part of a block is itself
managed by the kernel.
This approach has the benefit of being an evolutionary path of what we
have today and still allows people to benefit from COP interfaces to
implement their own components, be them integrated into Cocoon or not.
WDYT?
Also, does someone know more about Keel (http://www.keelframework.org/)?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [Kernel22] How to develop a component?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@sea.gmane.org] On Behalf Of Nicola Ken Barozzi
>
> > So what do others think?
>
> Cocoon components will never work putside of Cocoon.
But will non-Cocoon components work inside of Cocoon? If so, with how
much work in adapting?
Or can a general adapter be written that uses proxies etc?
/LS
Re: [Kernel22] How to develop a component?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
...
>>I strongly suggest that we start with org.apache.cocoon.* to
>>avoid these problems down the road (including, yes, gump problems)
>
> Yes, I understand of course all these problems, but I'm really afraid
> of changing all the components now from Avalon interfaces to Cocoon
> interfaces which are more or less the same but just use a different
> package. In that case these components run in Cocoon but not in any
> other container anymore that provides Avalon compatibility. And
> that's imho bad. Not every project uses Cocoon, so it's absolutely
> preferable to have components that I can use in several projects.
>
> Ok, I think if we decide to use our own versions of the interfaces it
> will still be possible to do some hacky things and still provide
> compatilibity with the Avalon versions.
>
> So what do others think?
Cocoon components will never work putside of Cocoon.
Non-cocoon components should not use the Cocoon interfaces.
I don't see the problem, as long as we don't mix all like we did with
Avalon.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [Kernel22] How to develop a component?
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
>
> Stefano Mazzocchi wrote:
>
>>>:) Sounds good to me. Now what do you think of using the
>>
>>things from
>>
>>>Avalon that are good (for us)? Now, I think, some of the interfaces
>>>(for logging, contextualization, initialization) are good
>>
>>and we could
>>
>>>directly use them instead of building just a clone of them.
>>
>>There are two issues here, Carsten. One is about the present
>>and another is about the future. Present indicates that
>>reusing what's available is great, future indicates that if
>>we keep dependencies on
>>org.apache.avalon.* namespace we either end up forking it or,
>>more likely, we have potential classloading collision issues
>>in the future with things that avalon might produce.
>>
>>remember the rhino classloading problem with weblogic? same thing.
>>
>
> Sure.
>
>
>>I strongly suggest that we start with org.apache.cocoon.* to
>>avoid these problems down the road (including, yes, gump problems)
>>
>
> Yes, I understand of course all these problems, but I'm really afraid
> of changing all the components now from Avalon interfaces to Cocoon
> interfaces which are more or less the same but just use a different
> package. In that case these components run in Cocoon but not in any
> other container anymore that provides Avalon compatibility. And
> that's imho bad. Not every project uses Cocoon, so it's absolutely
> preferable to have components that I can use in several projects.
I don't buy this.
The "component portability" argument is moot, it's a myth, you can't
even move components from one container to another in avalon and ECM is
deprecated, now even fortress is deprecated.
Sorry, but the idea of a class-granular component is bullshit. APIs do
that for you. want a portable parser? use JAXP. want a portable xslt
transformer? use JAXP. want a object repository? use JCR.
The valuable component oriented paradigm is at the webapp level and
there is no way you can reuse cocoon blocks in a container that is not
cocoon.
At the class level, avalon components are normally a class thin wrapper
around an API. And, if not, they soon migrate until they become that!
It's not exactly something I would scream and yell if I had to rewrite
in different containers.
> Ok, I think if we decide to use our own versions of the interfaces it
> will still be possible to do some hacky things and still provide
> compatilibity with the Avalon versions.
There will be an avalon sandbox for legacy code. There is nothing hacky
in that.
--
Stefano.
Re: [Kernel22] How to develop a component?
Posted by Geoff Howard <co...@leverageweb.com>.
Carsten Ziegeler wrote:
>
> Stefano Mazzocchi wrote:
>
>>>:) Sounds good to me. Now what do you think of using the
>>
>>things from
>>
>>>Avalon that are good (for us)? Now, I think, some of the interfaces
>>>(for logging, contextualization, initialization) are good
>>
>>and we could
>>
>>>directly use them instead of building just a clone of them.
>>
>>There are two issues here, Carsten. One is about the present
>>and another is about the future. Present indicates that
>>reusing what's available is great, future indicates that if
>>we keep dependencies on
>>org.apache.avalon.* namespace we either end up forking it or,
>>more likely, we have potential classloading collision issues
>>in the future with things that avalon might produce.
>>
>>remember the rhino classloading problem with weblogic? same thing.
>>
>
> Sure.
>
>
>>I strongly suggest that we start with org.apache.cocoon.* to
>>avoid these problems down the road (including, yes, gump problems)
>>
>
> Yes, I understand of course all these problems, but I'm really afraid
> of changing all the components now from Avalon interfaces to Cocoon
> interfaces which are more or less the same but just use a different
> package. In that case these components run in Cocoon but not in any
> other container anymore that provides Avalon compatibility. And
> that's imho bad. Not every project uses Cocoon, so it's absolutely
> preferable to have components that I can use in several projects.
>
> Ok, I think if we decide to use our own versions of the interfaces it
> will still be possible to do some hacky things and still provide
> compatilibity with the Avalon versions.
>
> So what do others think?
I'm under the impression that this is very rare. The constant fracturing of the
container wars has to have made true interoperability very hard to achieve. Are
you saying that you have specific projects which use components across containers?
Existing components ought to be supported by the proposed avalon compatibility
block. Maybe new/updated components which need to interoperate with other
blocks in Cocoon and with other containers could be constructed carefully to be
valid components in both worlds. A pain, but the universe of people who are
likely to use both cocoon and other avalon components has to be a pretty small
and capable group.
If this doesn't seem possible in your case, let's think about why and weigh our
options.
Geoff
RE: [Kernel22] How to develop a component?
Posted by Bruno Dumon <br...@outerthought.org>.
On Tue, 2004-04-06 at 16:20, Carsten Ziegeler wrote:
> Stefano Mazzocchi wrote:
> > >
> > > :) Sounds good to me. Now what do you think of using the
> > things from
> > > Avalon that are good (for us)? Now, I think, some of the interfaces
> > > (for logging, contextualization, initialization) are good
> > and we could
> > > directly use them instead of building just a clone of them.
> >
> > There are two issues here, Carsten. One is about the present
> > and another is about the future. Present indicates that
> > reusing what's available is great, future indicates that if
> > we keep dependencies on
> > org.apache.avalon.* namespace we either end up forking it or,
> > more likely, we have potential classloading collision issues
> > in the future with things that avalon might produce.
> >
> > remember the rhino classloading problem with weblogic? same thing.
> >
> Sure.
>
> > I strongly suggest that we start with org.apache.cocoon.* to
> > avoid these problems down the road (including, yes, gump problems)
> >
> Yes, I understand of course all these problems, but I'm really afraid
> of changing all the components now from Avalon interfaces to Cocoon
> interfaces which are more or less the same but just use a different
> package. In that case these components run in Cocoon but not in any
> other container anymore that provides Avalon compatibility. And
> that's imho bad. Not every project uses Cocoon,
not every project uses Avalon either ;-)
> so it's absolutely
> preferable to have components that I can use in several projects.
>
> Ok, I think if we decide to use our own versions of the interfaces it
> will still be possible to do some hacky things and still provide
> compatilibity with the Avalon versions.
>
> So what do others think?
Haven't thought deeply about this, but just some thoughts (without
choosing either way for now):
- for Cocoon-specific components (e.g. sitemap components) it doesn't
matter that much, except for the porting effort, both for us and for
users who have custom-developed components.
- for more generic components, one could argue that it should be easy
enough to write a wrapper component around it that implements the
correct interfaces. This for both directions, i.e. embedding non-Cocoon
components in Cocoon or embedding Cocoon-components in other locations.
- This might be more difficult for components that don't stand on their
own but also have dependencies on other components, since then the way
in which component dependencies are resolved might be incompatible.
- Another problem might be that the Avalon interfaces are currently used
at a quite deep level inside Cocoon, not only at the component borders.
- But OTOH, if we start with interfaces which are clones of the Avalon
ones, porting that should be pretty straightforward.
- for embedding an Avalon-based application, one could also embed an
Avalon-container itself.
- If we're not going to use (or make) an Avalon container, in general
I'm also not convinced whether it's sane to still use the Avalon
interfaces.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [Kernel22] How to develop a component?
Posted by Carsten Ziegeler <cz...@apache.org>.
Nicola Ken Barozzi wrote:
> Leo Simons wrote:
> ...
> > avalon-framework very rarely doesn't get built by gump. It's the ECM
> > dependency that's causing the ripples, and the big set of dependencies
> > ECM has itself.
> >
> > Since it seems ECM is being put into the freezer anyway, just be
> > pragmatic and make the gump build of cocoon depend on an installed
> > package or some jars in cvs. It's not like ECM has changed a lot over
> > the last 2 years.
>
> Good suggestion as an interim solution. +1
>
We only use released versions of Avalon/Excalibur/etc., so that shouldn't
be any problem.
Carsten
Re: [Kernel22] How to develop a component?
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
> Leo Simons wrote:
> ...
>
>> avalon-framework very rarely doesn't get built by gump. It's the ECM
>> dependency that's causing the ripples, and the big set of dependencies
>> ECM has itself.
>>
>> Since it seems ECM is being put into the freezer anyway, just be
>> pragmatic and make the gump build of cocoon depend on an installed
>> package or some jars in cvs. It's not like ECM has changed a lot over
>> the last 2 years.
>
>
> Good suggestion as an interim solution. +1
I have no problems in making the avalon sandbox of the cocoon kernel
depend on frozen versions of Avalon Framework and Avalon ECM that didn't
change in the last two years.
As long as we agree *never to change it*.
If Leo's are right, it is also possible to make avalon components be
exposed "outside" the avalon sandbox without loss of functionality.
I don't see how, but I love to be proven wrong.
But I sand firmly on my position:
+1 on having an avalon sandbox
-1 on having the core of the cocoon kernel depend on avalon directly
--
Stefano.
Re: [Kernel22] How to develop a component?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
...
> avalon-framework very rarely doesn't get built by gump. It's the ECM
> dependency that's causing the ripples, and the big set of dependencies
> ECM has itself.
>
> Since it seems ECM is being put into the freezer anyway, just be
> pragmatic and make the gump build of cocoon depend on an installed
> package or some jars in cvs. It's not like ECM has changed a lot over
> the last 2 years.
Good suggestion as an interim solution. +1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [Kernel22] How to develop a component?
Posted by Leo Simons <ls...@jicarilla.org>.
Hi guys!
Nicola Ken Barozzi wrote:
>> And the dependency is very minimal. It's just a dependency against the
>> avalon framework api version 4.1.5 - a released version. There is no
>> need in following the development of Avalon.
>
> The issue is not so technical as it's of indipendence from something
> that, in the good and the bad, has not helped Cocoon be built by Gump
> for ages now.
avalon-framework very rarely doesn't get built by gump. It's the ECM
dependency that's causing the ripples, and the big set of dependencies
ECM has itself.
Since it seems ECM is being put into the freezer anyway, just be
pragmatic and make the gump build of cocoon depend on an installed
package or some jars in cvs. It's not like ECM has changed a lot over
the last 2 years.
(...)
I just read up on this thread when someone pointed me at it. What I
don't understand is what you think will be so difficult. By now there's
half a dozen examples of containers and/or microkernels out there that
can be easily made to run your typical avalon-style cocoon component.
Just to drive that point home, here's some tests from my own pet project:
http://cvs.sourceforge.net/viewcvs.py/jicarilla/jicarilla-sandbox/platform/container-integration/src/test/org/jicarilla/container/test/integration/avalon/
if I can figure out how to do this all on my own, surely the cocoon
community will have no trouble whatsoever attaining interoperability
between "new-style" and "old-style" blocks you need.
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
Component Community -- http://componentplanet.org/
Component Glue -- http://jicarilla.org/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
Re: [Kernel22] How to develop a component?
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:
> Steven Noels wrote:
>
>> On 07 Apr 2004, at 16:05, Nicola Ken Barozzi wrote:
>>
>>> Steven Noels wrote:
>>>
>>>> On 07 Apr 2004, at 11:09, Nicola Ken Barozzi wrote:
>>>>
>>>>> The issue is not so technical as it's of indipendence from
>>>>> something that, in the good and the bad, has not helped Cocoon be
>>>>> built by Gump for ages now.
>>>>
>>>>
>>>> As much as I like "Gumpinal Correctness" for the sanity of us
>>>> Cocoon committers, I'm not sure whether Gump has the goal of
>>>> driving architectural decisions for the projects it is aggregating
>>>> information from. It is a helper tool and should not decide for us,
>>>> no?
>>>
>>>
>>>
>>> Gump is deciding for us? Did I read "Gump wrote?" :-P
>>>
>>> The fact is that a tool tells me that a project we depend upon does
>>> not get built regularly: this *does* impact on architectural decisions.
>>
>>
>>
>> The reason of Excalibur not building might perhaps be because of its
>> developers not caring enough about providing a strong contract to its
>> users. We have an established codeset and user base which have
>> habitually been adopting and using the Avalon *APIs* (I'm not
>> referring to a particular container here) because of (a) they found
>> out about them inside Cocoon, and were encouraged to use them for
>> their own Cocoon components, and (b) maybe they even started to
>> actually like them, and thus might expect us to provide identical
>> services and interfaces in our own container - backed by a healthier
>> community.
>
>
>
> A big +1 here, also seconding Carsten. The Avalon *API* has led many
> people to COP, as this *API* provides simple means for a component to
> interact with its container. Sure, IOC type 2/3 make it more
> transparent, but IMO don't scale for large sets of components.
>
> So although Cocoon will have a new container, it should not consider
> Avalon APIs as just a bunch of legacy interfaces that have to run in a
> sandbox. It's a slap in the face of many people that have invested
> time to build their application-logic components on top of an enabling
> infrastructure that was seamlessly integrated with Cocoon but could be
> used in other kind of apps, therefore allowing actual
> cross-application reuse of these components. Without this support,
> people are left alone without architectural guidance, and this will be
> a step back leading to unisolated spaghetti code.
>
> So we can trash the ECM, we can change the configuration file format,
> but we *must* support (and not only as a legacy isolated sandbox) the
> Avalon framework APIs (a bunch of 1-method interfaces).
>
> Cross-block classloading problems isn't an issue IMO, as it seems to
> me fairly easy to use dynamic proxies to translate calls to an
> interface to calls to the same interface in a different classloader.
>
> My 1 euro. Yeah, a lot more than Steven ;-)
Add some USD to this. I'd like Cocoon to support Avalon Framework API
also. I don't understand why Avalon components could not be wired to be
exposed by block.
Vadim
Re: [Kernel22] How to develop a component?
Posted by Sylvain Wallez <sy...@apache.org>.
Steven Noels wrote:
> On 07 Apr 2004, at 16:05, Nicola Ken Barozzi wrote:
>
>> Steven Noels wrote:
>>
>>> On 07 Apr 2004, at 11:09, Nicola Ken Barozzi wrote:
>>>
>>>> The issue is not so technical as it's of indipendence from
>>>> something that, in the good and the bad, has not helped Cocoon be
>>>> built by Gump for ages now.
>>>
>>> As much as I like "Gumpinal Correctness" for the sanity of us Cocoon
>>> committers, I'm not sure whether Gump has the goal of driving
>>> architectural decisions for the projects it is aggregating
>>> information from. It is a helper tool and should not decide for us, no?
>>
>>
>> Gump is deciding for us? Did I read "Gump wrote?" :-P
>>
>> The fact is that a tool tells me that a project we depend upon does
>> not get built regularly: this *does* impact on architectural decisions.
>
>
> The reason of Excalibur not building might perhaps be because of its
> developers not caring enough about providing a strong contract to its
> users. We have an established codeset and user base which have
> habitually been adopting and using the Avalon *APIs* (I'm not
> referring to a particular container here) because of (a) they found
> out about them inside Cocoon, and were encouraged to use them for
> their own Cocoon components, and (b) maybe they even started to
> actually like them, and thus might expect us to provide identical
> services and interfaces in our own container - backed by a healthier
> community.
A big +1 here, also seconding Carsten. The Avalon *API* has led many
people to COP, as this *API* provides simple means for a component to
interact with its container. Sure, IOC type 2/3 make it more
transparent, but IMO don't scale for large sets of components.
So although Cocoon will have a new container, it should not consider
Avalon APIs as just a bunch of legacy interfaces that have to run in a
sandbox. It's a slap in the face of many people that have invested time
to build their application-logic components on top of an enabling
infrastructure that was seamlessly integrated with Cocoon but could be
used in other kind of apps, therefore allowing actual cross-application
reuse of these components. Without this support, people are left alone
without architectural guidance, and this will be a step back leading to
unisolated spaghetti code.
So we can trash the ECM, we can change the configuration file format,
but we *must* support (and not only as a legacy isolated sandbox) the
Avalon framework APIs (a bunch of 1-method interfaces).
Cross-block classloading problems isn't an issue IMO, as it seems to me
fairly easy to use dynamic proxies to translate calls to an interface to
calls to the same interface in a different classloader.
My 1 euro. Yeah, a lot more than Steven ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [Kernel22] How to develop a component?
Posted by Steven Noels <st...@outerthought.org>.
On 07 Apr 2004, at 16:05, Nicola Ken Barozzi wrote:
> Steven Noels wrote:
>
>> On 07 Apr 2004, at 11:09, Nicola Ken Barozzi wrote:
>>> The issue is not so technical as it's of indipendence from something
>>> that, in the good and the bad, has not helped Cocoon be built by
>>> Gump for ages now.
>> As much as I like "Gumpinal Correctness" for the sanity of us Cocoon
>> committers, I'm not sure whether Gump has the goal of driving
>> architectural decisions for the projects it is aggregating
>> information from. It is a helper tool and should not decide for us,
>> no?
>
> Gump is deciding for us? Did I read "Gump wrote?" :-P
>
> The fact is that a tool tells me that a project we depend upon does
> not get built regularly: this *does* impact on architectural
> decisions.
The reason of Excalibur not building might perhaps be because of its
developers not caring enough about providing a strong contract to its
users. We have an established codeset and user base which have
habitually been adopting and using the Avalon *APIs* (I'm not referring
to a particular container here) because of (a) they found out about
them inside Cocoon, and were encouraged to use them for their own
Cocoon components, and (b) maybe they even started to actually like
them, and thus might expect us to provide identical services and
interfaces in our own container - backed by a healthier community. We
must be careful to not alienate developers and users as Avalon did.
(Mind you that I'm only expressing my own vague concerns, I'm not
suggesting we are doing a bad job here.)
> Remember? Build on sand, build on stone... maybe you haven't been
> reading.
I have. But knowing my programming skills, feel free to skip my opinion
if that makes things easier. :-)
I see some value in the concerns that Carsten wants to express, and I
think it would be beneficial if many people give their
opinion/concerns/ideas. Otherwise, it feels like watching a
German/Italy football game. :-)
Just some copper 0.01 EUR coins,
</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: [Kernel22] How to develop a component?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Steven Noels wrote:
> On 07 Apr 2004, at 11:09, Nicola Ken Barozzi wrote:
>
>> The issue is not so technical as it's of indipendence from something
>> that, in the good and the bad, has not helped Cocoon be built by Gump
>> for ages now.
>
> As much as I like "Gumpinal Correctness" for the sanity of us Cocoon
> committers, I'm not sure whether Gump has the goal of driving
> architectural decisions for the projects it is aggregating information
> from. It is a helper tool and should not decide for us, no?
Gump is deciding for us? Did I read "Gump wrote?" :-P
The fact is that a tool tells me that a project we depend upon does not
get built regularly: this *does* impact on architectural decisions.
Remember? Build on sand, build on stone... maybe you haven't been reading.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [Kernel22] How to develop a component?
Posted by Stefano Mazzocchi <st...@apache.org>.
Steven Noels wrote:
> On 07 Apr 2004, at 11:09, Nicola Ken Barozzi wrote:
>
>> The issue is not so technical as it's of indipendence from something
>> that, in the good and the bad, has not helped Cocoon be built by Gump
>> for ages now.
>
>
> As much as I like "Gumpinal Correctness" for the sanity of us Cocoon
> committers, I'm not sure whether Gump has the goal of driving
> architectural decisions for the projects it is aggregating information
> from. It is a helper tool and should not decide for us, no?
Gump doesn't give us solutions, it points us to the problems.
--
Stefano.
Re: [Kernel22] How to develop a component?
Posted by Steven Noels <st...@outerthought.org>.
On 07 Apr 2004, at 11:09, Nicola Ken Barozzi wrote:
> The issue is not so technical as it's of indipendence from something
> that, in the good and the bad, has not helped Cocoon be built by Gump
> for ages now.
As much as I like "Gumpinal Correctness" for the sanity of us Cocoon
committers, I'm not sure whether Gump has the goal of driving
architectural decisions for the projects it is aggregating information
from. It is a helper tool and should not decide for us, no?
</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: [Kernel22] How to develop a component?
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> Nicola Ken Barozzi wrote:
>
>>The issue is not so technical as it's of indipendence from
>>something that, in the good and the bad, has not helped
>>Cocoon be built by Gump for ages now.
>>
>
> As I said, we would only have a reference to avalon framework
> version x.y.z - a fixed version so there shouldn't be any problem
> with gump because of that.
What if we need to change it?
--
Stefano.
RE: [Kernel22] How to develop a component?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
> The issue is not so technical as it's of indipendence from
> something that, in the good and the bad, has not helped
> Cocoon be built by Gump for ages now.
>
As I said, we would only have a reference to avalon framework
version x.y.z - a fixed version so there shouldn't be any problem
with gump because of that.
Carsten
RE: [Kernel22] How to develop a component?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> If you have two blocks in the avalon sandbox, you could share them
> between them, but there is no (easy? elegant?) way you can pass them
> arond *OUTSIDE* the sandbox and still allow blocks to be hotswappable
> and runtime polymorphic.
>
> [I would gladly be proven wrong here!]
You will not be proven wrong for all cases of Avalon components, but
for certain types of such components it is perfectly possible to
pass them around outside of the sandbox.
What remains is to figure out is under what conditions Avalon
components can be passed around and hot-swapped. I think we'll capture
something like 90%-95% of the business logic components that Carsten
and I are worried about. The remaining 5%-10%? We'll deal with them
when needed.
/LS
RE: [Kernel22] How to develop a component?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
>
> Leo Sutic wrote:
> >>From: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
> >>
> >>again, from memory, the real tough part is the barrier that's
> >>in place around the reference.
> >
> > I'd say the hard part is when A has significant state that isn't
> > preserved when it dies.
>
> right! Any reason it can't be preserved?
In theory no, in practice it isn't cost-effective to implement all
that code. Therefore it won't be done.
> reminds me of Persistable...
>
> > 1) A active
> > 2) schedule swap of A with B
> > 3) prepare swap to max extend (ie create and initialize B)
> > 4) suspend A and all processes referencing A
> > 5) swap
> > 1) stop A
> 1.5) save A state
> > 2) kill A (if it doesn't respond)
> 2.5) load A state into B
> > 3) start B
> > 4) update reference
> > 6) resume A and all processes referencing A
>
> the problem is that step 5 just keeps getting more and more
> expensive...and for all intents and purposes, needs to be atomic.
The idea I'm looking at is when A and B interact via short sessions -
for example, the time between a lookup and a release. As long as
B is released by A when you swap, you can just kill it. Avalon semantics
do not require B to maintain state across lookups.
So you do the barrier thing: block or fail lookups until all B's
have been released, the swap.
/LS
Re: [Kernel22] How to develop a component?
Posted by Leo Simons <ls...@jicarilla.org>.
Leo Sutic wrote:
>>From: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
>>
>>again, from memory, the real tough part is the barrier that's
>>in place around the reference.
>
> I'd say the hard part is when A has significant state that isn't
> preserved when it dies.
right! Any reason it can't be preserved?
reminds me of Persistable...
> 1) A active
> 2) schedule swap of A with B
> 3) prepare swap to max extend (ie create and initialize B)
> 4) suspend A and all processes referencing A
> 5) swap
> 1) stop A
1.5) save A state
> 2) kill A (if it doesn't respond)
2.5) load A state into B
> 3) start B
> 4) update reference
> 6) resume A and all processes referencing A
the problem is that step 5 just keeps getting more and more
expensive...and for all intents and purposes, needs to be atomic.
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
Component Community -- http://componentplanet.org/
Component Glue -- http://jicarilla.org/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
RE: [Kernel22] How to develop a component?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
>
> again, from memory, the real tough part is the barrier that's
> in place around the reference.
I'd say the hard part is when A has significant state that isn't
preserved when it dies. This makes it seem from client's perspective
as if the process at the other end has simply forgotten about
the commands it has been given previously.
Hotswapping stateless stuff is easy. Stateful stuff - that's the
hard part.
/LS
Re: [Kernel22] How to develop a component?
Posted by Leo Simons <ls...@jicarilla.org>.
Leo Sutic wrote:
> No, it doesn't. (Tell it to the person you quoted, though.)
isn't this a group discussion? :-D. Point taken though.
> ALT1: Wires are severed immediately, the component is reloaded.
can only do that on a coarse component level, otherwise its unmanageable.
> ALT2: Wires are left intact and the new component is loaded in parallell
> with the existing component.
>
> Disadvantages: A bit of a problem if the component was supposed to be
> a singleton
use a barrier :-D
> ALT3: Slap a read-write lock on every wire.
>
> Disadvantages: Deadlocks
use a barrier :-D
on an OS level, I think a lot of these things were thought about for a
long time, then solved, many years ago, even for large scale distributed
OSes. Not really my field though; too much pointer arithmic. From
memory, doing it reliably basically always goes something like
1) A active
2) schedule swap of A with B
3) prepare swap to max extend (ie create and initialize B)
4) suspend A and all processes referencing A
5) swap
1) stop A
2) kill A (if it doesn't respond)
3) start B
4) update reference
6) resume A and all processes referencing A
again, from memory, the real tough part is the barrier that's in place
around the reference. With java, barriers are way easier (because of
synchronization being available), but very expensive too.
If you want a hotswapping kernel, you probably want to look into
hotswapping kernels. Mach (now darwin) is a textbook example I think.
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
Component Community -- http://componentplanet.org/
Component Glue -- http://jicarilla.org/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
RE: [Kernel22] How to develop a component?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
>
> Leo Sutic wrote:
> > This is contrary to Avalon semantics, where a component reference,
> > once obtained, remains valid until it is released.
>
> right. It's contrary to java semantics, even.
Not really. It is more like the semantics you have for
remote objects. Except we don't throw RemoteException all the time.
(But neither does AltRMI, if I remember correctly.)
> Yep. Nothing to do with avalon-framework, though. I would say
> you'd have to [...]
> Agreed, its not very clean.
I have listed some other thoughts that I and Pier have thrown back
and forth below.
> All this, however, does not mean:
>
> "If you have two blocks in the avalon sandbox, you could share them
> between them, but there is no (easy? elegant?) way you can pass them
> arond *OUTSIDE* the sandbox and still allow blocks to be hotswappable
> and runtime polymorphic."
No, it doesn't. (Tell it to the person you quoted, though.)
> IOW, What you have shown here is that new-style cocoon blocks are
> incompatible with a standard assumption in most java code, namely,
> that references will remain references. You have not shown that
> these kinds of components cannot be used in an application where
> you violate that assumption, only that it will result in headache.
Yep.
> I can't see how it is relevant whether a reference is obtained
> through the avalon ServiceManager or through any other means.
Yep.
PROBLEM:
We have a set of components communicating across defined interfaces.
We want to be able to hot-swap the components. The interfaces are
considered permanent and need not be how-swapped.
DEFINITIONS:
We'll consider the simplest case.
Component: The component being swapped in this scenario. It consists
of implementation code, no interfaces. We make no assumptions regarding
the statefulness or statelessness of the component.
Client: The code using the component. The client is probably another
component, but we'll call it "client".
Container: The container in which we find the client and the component.
Wire: The connection between component and client. The important thing
with this wire is that it can be severed by the container. A component
(such as the client) obtain these wires by a lookup() operation, and
releases them via a release() operation. It is not defined just how
these two operations are done by the client, but the client can do them.
SCENARIO:
Client uses component. Component is to be hot-swapped. What does client
percieve when component is swapped? I.e. from the client's point of
view,
what happens?
And these are the alternatives that I know about...
ALT1: Wires are severed immediately, the component is reloaded.
Advantages: We know what happens with some certainty. The client will
get a big fat InvalidWireException thrown in its face, and have to deal
with it - but we know that this will happen and can thus code for it.
This is what happens when you run a distributed app / DB connection
pool,
so it's really not something that's unheard of.
Disadvantages: Coding for that InvalidWireException can turn into
a mess.
ALT2: Wires are left intact and the new component is loaded in parallell
with the existing component. All future lookup() operations will return
a wire to the new component, and the old component will be undeployed
when all wires to it has been release()'d.
Advantages: A smooth phasing-in of the new code. No exceptions thrown.
Disadvantages: A bit of a problem if the component was supposed to be
a singleton, or if it accesses some shared resource, such as a log file.
Suddenly, you have two instances of something that should only have
one instance. Additionally, you'll never know if there is some wire
that's unreleased, so if you hotswapped a component due to a serious
security
fix, you can't ever find out if the new code is really running
everywhere
in the system.
ALT3: Slap a read-write lock on every wire. When a component is about to
be undeployed, get a write lock on every wire before severing them.
Client must do a lock()/unlock() operation around blocks of code where
it can't handle the severing of a wire.
Advantages: Works perfectly well in theory.
Disadvantages: Deadlocks - but we can make lock() fail instead of block
to get around this. Perhaps. Harder to implement than alt 1 or 2.
/LS
Re: [Kernel22] How to develop a component?
Posted by Leo Simons <ls...@jicarilla.org>.
Leo Sutic wrote:
>>From: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
>>
>>write a failing testcase that doens't require me to understand every
>>little detail of cocoon internals and I could try.
>
> Easy.
<snip/>
made that into an actual testcase :-D:
public abstract class ReloadingProxyTestCase extends TestCase
{
ServiceManager manager;
ProxyInvalidator invalidator;
Client client;
public void setUp() throws Exception
{
super.setUp();
manager = getManager();
invalidator = getInvalidator();
client = getClient();
}
protected abstract ServiceManager getManager();
protected abstract ProxyInvalidator getInvalidator();
protected abstract Client getClient();
public void testCacheInvalidationDoesntWork()
{
client.login();
invalidator.invalidate();
try
{
client.attemptOperation();
}
catch( InvalidatedReferenceException ire )
{
fail( "client doesn't catch InvalidatedReferenceException!" );
}
}
public interface StatefulComponent
{
public void login (); // never throws any exception, ever.
public void doOperation (); // never throws any exception, ever.
public void logout (); // never throws any exception, ever.
}
public class AvalonStatefulComponent
extends AbstractLogEnabled,
implements Serviceable, StatefulComponent
{
public void login () {}
public void doOperation () {}
public void logout () {}
}
public interface Client
{
public void attemptLogin();
public void attemptOperation();
}
public class OldStyleClient implements Serviceable, Client
{
private StatefulComponent comp;
public void service( ServiceManager sm )
{
comp = (StatefulComponent)
sm.lookup(StatefulComponent.ROLE);
}
public void attemptLogin()
{
comp.login();
}
public void attemptOperation()
{
comp.doOperation();
}
}
}
> This is contrary to Avalon semantics, where a component reference,
> once obtained, remains valid until it is released.
right. It's contrary to java semantics, even. I'll try to withhold most
of my opinion as to how smart a design like this is in the interest of
keeping the discussion on-topic ;)
If you provide a component that has this kind of behaviour to an
avalon-framework-compatible component through that component its
servicemanager, it will not catch the InvalidatedReferenceException and
it will lead to unexpected results. Acked.
> Of course there are ways to code around this (or ignore it) in
> the vast majority of cases.
Yep. Nothing to do with avalon-framework, though. I would say you'd have
to mark components up with
/** @@SupportsInvalidationOfReferences() */
and have the container print a big fat warning if the tag is missing but
the ServiceManager (or anything which can lead to a reference that can
be invalidatied) being provided to the component contains components
that may invalidate.
Agreed, its not very clean.
All this, however, does not mean:
"If you have two blocks in the avalon sandbox, you could share them
between them, but there is no (easy? elegant?) way you can pass them
arond *OUTSIDE* the sandbox and still allow blocks to be hotswappable
and runtime polymorphic."
your test case shows that there is no easy or elegant way you can pass a
new style cocoon block into an old-style avalon component. Which will of
course be true for the majority of code in this world, because the
majority of software doesn't check for the not-yet-existant
InvalidatedReferenceException. You have major headache to deal with
there anyway, regardless of whether you have an avalon component or a
javabean or an EJB.
But the test case doesn't show that there is no easy or elegant way to
pass an old style avalon component into a new style cocoon block. After
all, the block is not going to be disfunctional if the reference to the
avalon component *doesn't invalidate*.
You could write a testcase for that. The testcase would be saying "all
code inside cocoon must be prepared for references to anything to
invalidate at any point in time". Ugh.
IOW, What you have shown here is that new-style cocoon blocks are
incompatible with a standard assumption in most java code, namely, that
references will remain references. You have not shown that these kinds
of components cannot be used in an application where you violate that
assumption, only that it will result in headache.
I can't see how it is relevant whether a reference is obtained through
the avalon ServiceManager or through any other means.
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
Component Community -- http://componentplanet.org/
Component Glue -- http://jicarilla.org/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
Re: [Kernel22] How to develop a component?
Posted by Sylvain Wallez <sy...@apache.org>.
Leo Sutic wrote:
>
>
>>From: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
>>
>>Stefano Mazzocchi wrote:
>>
>>
>>>If you have two blocks in the avalon sandbox, you could share them
>>>between them, but there is no (easy? elegant?) way you can
>>>
>>>
>>pass them
>>
>>
>>>arond *OUTSIDE* the sandbox and still allow blocks to be
>>>
>>>
>>hotswappable
>>
>>
>>>and runtime polymorphic.
>>>
>>>[I would gladly be proven wrong here!]
>>>
>>>
>>write a failing testcase that doens't require me to understand every
>>little detail of cocoon internals and I could try.
>>
>>
>
>Easy.
>
>interface StatefulComponent {
> public void login (); // never throws any exception, ever.
> public void doOperation (); // never throws any exception, ever.
> public void logout (); // never throws any exception, ever.
>}
>
>Client.java:
>
> StatefulComponent comp = (StatefulComponent)
> manager.lookup(StatefulComponent.ROLE);
> try {
> comp.login ();
> // (1)
> comp.doOperation ();
> comp.logout ();
> } finally {
> manager.release (comp);
> }
>
>If a block reload of the implementation of StatefulComponent
>occurs at (1), the comp proxy will be invalidated while in use,
>and the operation will fail.
>
>This is contrary to Avalon semantics, where a component reference,
>once obtained, remains valid until it is released.
>
>Of course there are ways to code around this (or ignore it) in
>the vast majority of cases.
>
>
A way to solve this problem is by deferring the actual swapping until
the component is released.
See http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=108033164725441&w=2
where I discussed this.
Of course, there should be a means to force component swap (either
manually or automatically) in case a release has been forgotten.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [Kernel22] How to develop a component?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Leo Sutic wrote:
>
> > From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> >
> > So, if I understand you correctly, the only difference is
> that I can
> > get an exception that I wasn't prepared to get when using Avalon.
>
> Yep, that's pretty much it.
>
> > If that's try then I don't see any reason why this wouldn't
> work with
> > using the Avalon interfaces - I'm just speaking of the
> interfaces not
> > the implementation!
>
> It will work, but the thing is that people have started
> assuming that some things will work in certain ways.
>
> So while the interfaces will work in practice, they won't in
> theory, since there are some semantics that are gone.
>
Okay, I see - so as long as I don't reload a block, it's pretty
much the same.
Thanks, Leo!
Carsten
RE: [Kernel22] How to develop a component?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> > From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> >
> > So, if I understand you correctly, the only difference is
> that I can
> > get an exception that I wasn't prepared to get when using Avalon.
>
> Yep, that's pretty much it.
One more thing - since all components are proxied now, you'll incur
a proxy overhead in the call.
But that can be minimized by smart container code. (Which we will
have, of course.)
/LS
RE: [Kernel22] How to develop a component?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>
> So, if I understand you correctly, the only difference is that I
> can get an exception that I wasn't prepared to get when using
> Avalon.
Yep, that's pretty much it.
> If that's try then I don't see any reason why this
> wouldn't work with using the Avalon interfaces - I'm just
> speaking of the interfaces not the implementation!
It will work, but the thing is that people have started
assuming that some things will work in certain ways.
So while the interfaces will work in practice, they won't
in theory, since there are some semantics that are
gone.
/LS
RE: [Kernel22] How to develop a component?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Leo Sutic wrote:
>
> > -----Original Message-----
> > From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> > Sent: den 8 april 2004 16:24
> > To: dev@cocoon.apache.org
> > Subject: RE: [Kernel22] How to develop a component?
> >
> >
> > >
> > > > From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> > > >
> > > > How does the working code look like?
> > >
> > > The working code of what?
> > >
> > > The adapter / sandbox / compatibility layer?
> > >
> > The working code with some cocoon interfaces. I guess the component
> > interface for the stateful component is the same.
> > So, the different should be in the client.java code. Or am I wrong?
>
> The new code would be very similar.
Believe me, I'm really just curious. Would the new code be the same
or just similar? Of course the lookup is different as a different
method is used. From what I understood the code would look like
this:
StatefulComponent comp =
(StatefulComponent)wire.lookup(StatefulComponent.class, SOMEHINT);
try {
comp.login ();
// (1)
comp.doOperation ();
comp.logout ();
} finally {
wire.release (comp);
}
>
> The new "Block" code uses Wirings instead of a
> ComponentManager/ServiceManager, but they are *very* similar.
> You should also include a
> comp.ensureWired() call
> at the top, to test if the block whose components you are
> using hasn't been reloaded since you last checked. (This call
> will also reload the block if it is scheduled for reload, but
> not yet reloaded).
So, would I do a comp.ensureWired() before each call to the component?
>
> ***The biggest change however***, is that you have to be
> prepared for the event that a component that you have looked
> up may disappear due to block reloading.
>
> This simply did not happen with Avalon. So you may get an
> exception where you didn't get one before.
>
> Otherwise you should be fine.
>
So, if I understand you correctly, the only difference is that I
can get an exception that I wasn't prepared to get when using
Avalon. If that's try then I don't see any reason why this
wouldn't work with using the Avalon interfaces - I'm just
speaking of the interfaces not the implementation!
Carsten
RE: [Kernel22] How to develop a component?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> Sent: den 8 april 2004 16:24
> To: dev@cocoon.apache.org
> Subject: RE: [Kernel22] How to develop a component?
>
>
> >
> > > From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> > >
> > > How does the working code look like?
> >
> > The working code of what?
> >
> > The adapter / sandbox / compatibility layer?
> >
> The working code with some cocoon interfaces. I guess the
> component interface for the stateful component is the same.
> So, the different should be in the client.java code. Or am I wrong?
The new code would be very similar.
The new "Block" code uses Wirings instead of a
ComponentManager/ServiceManager,
but they are *very* similar. You should also include a
comp.ensureWired() call
at the top, to test if the block whose components you are using hasn't
been
reloaded since you last checked. (This call will also reload the block
if it is
scheduled for reload, but not yet reloaded).
***The biggest change however***, is that you have to be prepared for
the
event that a component that you have looked up may disappear due to
block reloading.
This simply did not happen with Avalon. So you may get an exception
where
you didn't get one before.
Otherwise you should be fine.
/LS
RE: [Kernel22] How to develop a component?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
>
> > From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> >
> > How does the working code look like?
>
> The working code of what?
>
> The adapter / sandbox / compatibility layer?
>
The working code with some cocoon interfaces. I guess the
component interface for the stateful component is the same.
So, the different should be in the client.java code. Or
am I wrong?
Carsten
RE: [Kernel22] How to develop a component?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>
> How does the working code look like?
The working code of what?
The adapter / sandbox / compatibility layer?
/LS
RE: [Kernel22] How to develop a component?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Leo Sutic wrote:
>
> interface StatefulComponent {
> public void login (); // never throws any exception, ever.
> public void doOperation (); // never throws any exception, ever.
> public void logout (); // never throws any exception, ever.
> }
>
> Client.java:
>
> StatefulComponent comp = (StatefulComponent)
> manager.lookup(StatefulComponent.ROLE);
> try {
> comp.login ();
> // (1)
> comp.doOperation ();
> comp.logout ();
> } finally {
> manager.release (comp);
> }
>
> If a block reload of the implementation of StatefulComponent
> occurs at (1), the comp proxy will be invalidated while in
> use, and the operation will fail.
>
> This is contrary to Avalon semantics, where a component
> reference, once obtained, remains valid until it is released.
>
> Of course there are ways to code around this (or ignore it)
> in the vast majority of cases.
>
How does the working code look like?
Carsten
RE: [Kernel22] How to develop a component?
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: news [mailto:news@sea.gmane.org] On Behalf Of Leo Simons
>
> Stefano Mazzocchi wrote:
> > If you have two blocks in the avalon sandbox, you could share them
> > between them, but there is no (easy? elegant?) way you can
> pass them
> > arond *OUTSIDE* the sandbox and still allow blocks to be
> hotswappable
> > and runtime polymorphic.
> >
> > [I would gladly be proven wrong here!]
>
> write a failing testcase that doens't require me to understand every
> little detail of cocoon internals and I could try.
Easy.
interface StatefulComponent {
public void login (); // never throws any exception, ever.
public void doOperation (); // never throws any exception, ever.
public void logout (); // never throws any exception, ever.
}
Client.java:
StatefulComponent comp = (StatefulComponent)
manager.lookup(StatefulComponent.ROLE);
try {
comp.login ();
// (1)
comp.doOperation ();
comp.logout ();
} finally {
manager.release (comp);
}
If a block reload of the implementation of StatefulComponent
occurs at (1), the comp proxy will be invalidated while in use,
and the operation will fail.
This is contrary to Avalon semantics, where a component reference,
once obtained, remains valid until it is released.
Of course there are ways to code around this (or ignore it) in
the vast majority of cases.
/LS
Re: [Kernel22] How to develop a component?
Posted by Leo Simons <ls...@jicarilla.org>.
Stefano Mazzocchi wrote:
> If you have two blocks in the avalon sandbox, you could share them
> between them, but there is no (easy? elegant?) way you can pass them
> arond *OUTSIDE* the sandbox and still allow blocks to be hotswappable
> and runtime polymorphic.
>
> [I would gladly be proven wrong here!]
write a failing testcase that doens't require me to understand every
little detail of cocoon internals and I could try.
I just totally fail to see what restrictions you think are intrinsic to
avalon-framework-compatible components for preventing container feature
X or feature Y from working.
I understand the decision to move away from /depending/ on o.a.avalon.*
based on stuff like community dynamics, but I totally fail to understand
is the technical part of the rationale that, comes after that decision,
that says backwards (and forward, in fact) /compatibility/ is not
possible or not possible cleanly.
You're taking a rather firm stance without having code in place that
proves your point. I can imagine people "freaking out" at big
architectural change for a reason that is not understood and may not
even exist.
> Is this clear enough?
nope :-D
> if not, I'm glad to keep answering questions.
- What problem are you solving that can't be solved if a component
requires (for example) that the container honours the Servicable contract?
- Why not?
- Have you actually tried it?
- Where did it fail?
Apologies for jumping onto this topic like this, but I've just spent
half a year exploring solutions to these kinds of things and so far I
just haven't encountered any fundamental issue which you seem to be
fearing exists. When you say "not elegantly possible" people believe it
and that may be a bad thing if you're wrong ;)
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
Component Community -- http://componentplanet.org/
Component Glue -- http://jicarilla.org/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
RE: [Kernel22] How to develop a component?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
>
> Bertrand Delacretaz wrote:
>
> > Le 7 avr. 04, à 11:33, Carsten Ziegeler a écrit :
> >
> >> ...Exactly my point :) But the current idea of blocks is to only
> >> retain this possibility inside a sandbox which means it
> can't be used "inside"
> >> blocks. So if I develop my app as a block, I can't use these
> >> components inside my app!...
> >
> >
> > I thought the idea was to provide an ECM-like sandbox
> *inside* a block
> > (reading Stefano's last message on this thread), in which
> case you can
> > use your Avalon components inside a Cocoon block, but they
> cannot be
> > made available to other blocks.
> >
> > But I might be wrong..
>
> Bertrand is right and Carsten is freaking out for no reason.
Oh, if you think that I'm "freaking out" than you never really saw
me freaking out - believe me!
>
> Carsten, please, breath and read what I write.
>
> You don't have hotdeployment today so you won't be missing it
> for sure in your avalon sandbox, would you?
Yepp.
>
> If you have two blocks in the avalon sandbox, you could share
> them between them, but there is no (easy? elegant?) way you
> can pass them arond *OUTSIDE* the sandbox and still allow
> blocks to be hotswappable and runtime polymorphic.
Ok, so here is the different understanding. My understanding
was that the avalon sandbox is *one big block* and not a
sandbox I can run blocks in. Sorry that I misunderstood the
previous explanations.
So, if this is true, we *could* go this way. Although I and
some others here still don't see any technical problems. But
time will tell of course.
> <SNIP/>
>
> --
> Stefano, wishing people didn't think that innovation always
> means breaking stuff.
>
Carsten - trying to keep the discussion technical.
Re: [Kernel22] How to develop a component?
Posted by Stefano Mazzocchi <st...@apache.org>.
Bertrand Delacretaz wrote:
> Le 7 avr. 04, à 11:33, Carsten Ziegeler a écrit :
>
>> ...Exactly my point :) But the current idea of blocks is to only retain
>> this possibility inside a sandbox which means it can't be used "inside"
>> blocks. So if I develop my app as a block, I can't use these components
>> inside my app!...
>
>
> I thought the idea was to provide an ECM-like sandbox *inside* a block
> (reading Stefano's last message on this thread), in which case you can
> use your Avalon components inside a Cocoon block, but they cannot be
> made available to other blocks.
>
> But I might be wrong..
Bertrand is right and Carsten is freaking out for no reason.
Carsten, please, breath and read what I write.
You don't have hotdeployment today so you won't be missing it for sure
in your avalon sandbox, would you?
If you have two blocks in the avalon sandbox, you could share them
between them, but there is no (easy? elegant?) way you can pass them
arond *OUTSIDE* the sandbox and still allow blocks to be hotswappable
and runtime polymorphic.
[I would gladly be proven wrong here!]
So, in short:
1) if you have avalon components exposted thru cocoon blocks, these
blocks need to run in the avalon sandbox and they cannot be runtime
polymorphic because of the nature of avalon. This means that in order to
upload/change a block you need to restart the container. If we pass
around these components outside the sandbox, we force all blocks that
depend on this to be hardwired, loosing, in fact, the soft-wireness.
2) for cocoon components exposted thru cocoon blocks, this is not the
case.
Socially, I expect the values of 2) to drive the migration effort away
from 1).
This means:
if you avalon components exposed to your cocoon block, these components
will be loaded in an avalon sandbox *and* all the cocoon blocks (even
those outside the sandbox) that depend on this will not be hotswappable.
Even more explicitly:
you are NOT loosing any functionality!! since hotswappability is not
something you had before.
Is this clear enough? if not, I'm glad to keep answering questions.
--
Stefano, wishing people didn't think that innovation always means
breaking stuff.
RE: [Kernel22] How to develop a component?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Bertrand Delacretaz wrote:
>
> I thought the idea was to provide an ECM-like sandbox
> *inside* a block (reading Stefano's last message on this
> thread), in which case you can use your Avalon components
> inside a Cocoon block, but they cannot be made available to
> other blocks.
>
> But I might be wrong..
No, you're right :) But this doesn't help me if I want to use
blocks for my app *and* my thousands of Avalon components at
the same time. Of course, I can put everything in the sandbox,
but then I don't use blocks at all.
Carsten
Re: [Kernel22] How to develop a component?
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le 7 avr. 04, à 11:33, Carsten Ziegeler a écrit :
> ...Exactly my point :) But the current idea of blocks is to only retain
> this possibility inside a sandbox which means it can't be used "inside"
> blocks. So if I develop my app as a block, I can't use these components
> inside my app!...
I thought the idea was to provide an ECM-like sandbox *inside* a block
(reading Stefano's last message on this thread), in which case you can
use your Avalon components inside a Cocoon block, but they cannot be
made available to other blocks.
But I might be wrong..
-Bertrand
RE: [Kernel22] How to develop a component?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> Carsten Ziegeler wrote:
> ...
> > To be honest, I still don't buy the classloader problem theory. I'm
> > just saying that we should try to support interfaces like
> Configurable etc.
>
> For Cocoon blocks or for other components?
>
For all components :) A block might contain custom components and for
these components I want to support the Avalon interfaces.
> ...
> > And the dependency is very minimal. It's just a dependency
> against the
> > avalon framework api version 4.1.5 - a released version.
> There is no
> > need in following the development of Avalon.
>
> The issue is not so technical as it's of indipendence from
> something that, in the good and the bad, has not helped
> Cocoon be built by Gump for ages now.
>
> What I don't understand, is the portability of *which* Avalon
> components you don't want to loose. Business logic used as
> Avalon components?
Yes, for example. Or components for special purposes that can
be used outside of Cocoon as well.
> I don't see why not retain this
> possibility.
Exactly my point :) But the current idea of blocks is to only retain
this possibility inside a sandbox which means it can't be used "inside"
blocks. So if I develop my app as a block, I can't use these components
inside my app!
> The question is just about the *Cocoon*
> components, that are not portable anyway between Cocoon'ECM
> and, for example, Merlin.
If we would only talk about *Cocoon* components, than sure, we don't
need to support the Avalon interfaces there. But as far as I'm understanding
it, we are talking about all components.
Carsten
Re: [Kernel22] How to develop a component?
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
...
> To be honest, I still don't buy the classloader problem theory. I'm just
> saying that we should try to support interfaces like Configurable etc.
For Cocoon blocks or for other components?
...
> And the dependency is very minimal. It's just a dependency against the
> avalon
> framework api version 4.1.5 - a released version. There is no need in
> following the development of Avalon.
The issue is not so technical as it's of indipendence from something
that, in the good and the bad, has not helped Cocoon be built by Gump
for ages now.
What I don't understand, is the portability of *which* Avalon components
you don't want to loose. Business logic used as Avalon components? I
don't see why not retain this possibility. The question is just about
the *Cocoon* components, that are not portable anyway between Cocoon'ECM
and, for example, Merlin.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: [Kernel22] How to develop a component?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
>
> I want to create a migration path away from avalon.
>
> I propose to have a sandbox so that people know that somehow
> they should be thinking about migration. It's sort of a
> framework deprecation signal.
>
> The idea is that we'll start with a sandbox, then people
> realize that blocks give them better functionality, so they
> make an effort to pay the "migration cost" because of the
> additional functionality.
>
> This will take a while, potentially years, and after that
> period, we can remove the sandbox, unlocking ourselves from avalon.
>
> On the other hand, Carsten, what you are proposing locks us
> forever connected to a particular years-old version of avalon
> that might be soon deprecated by its own project.
>
No, no, perhaps my explanations are not good - I don't know.
All I'm still trying to say is, that I would like support for
the avalon lifecycle interfaces. So, precisly, I want to have
support for:
LogEnabled, Contextualizable, Configurable, Parameterizable,
Serviceable, Intializable, Startable, Disposable, ThreadSafe
and Poolable. Nothing more.
I'm not against defining new interfaces - as long as we still
support the old ones. And I'm not against in loosing *some*
functionality if I'm using those interfaces from above.
Most of them are simple to support. The only one might be
Serviceable.
> Would the need to modify/update avalon framework emerge, we
> would be required to change it, this will create a fork.
>
There is no need to modify/update the avalon framework. We can
do our own thing but just support the old interfaces listed
above.
So, I just want some kind of "legacy support".
Carsten
Re: [Kernel22] How to develop a component?
Posted by Stefano Mazzocchi <st...@apache.org>.
I want to create a migration path away from avalon.
I propose to have a sandbox so that people know that somehow they should
be thinking about migration. It's sort of a framework deprecation signal.
The idea is that we'll start with a sandbox, then people realize that
blocks give them better functionality, so they make an effort to pay the
"migration cost" because of the additional functionality.
This will take a while, potentially years, and after that period, we can
remove the sandbox, unlocking ourselves from avalon.
On the other hand, Carsten, what you are proposing locks us forever
connected to a particular years-old version of avalon that might be soon
deprecated by its own project.
Would the need to modify/update avalon framework emerge, we would be
required to change it, this will create a fork.
I remain against having the core of the cocoon kernel depend on anything
in the org.apache.avalon.* namespace: it might save us problems in the
present, but open a can of worms in the future.
--
Stefano.
RE: [Kernel22] How to develop a component?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
"Stefano Mazzocchi" <st...@apache.org> wrote:
>
> I don't buy this.
>
> The "component portability" argument is moot, it's a myth, you can't
> even move components from one container to another in avalon and ECM
> is deprecated, now even fortress is deprecated.
>
Sorry, but that's not 100% true. You can use your implementations from
ECM in Fortress (and even in Merlin) without *any* changes to your java
code.
"Only" configuration is different.
And sorry, it's not a myth - it's reality. In our company - and I know
not only here - we are practicing this like three years now. Introduced
because of Cocoon we are heavily based on Avalon. And the great thing is
that these Avalon components work in Avalon containers, in Cocoon and in
some other containers as well without any problems.
If we don't support them in the next versions, well, we not only have to
rewrite them but we have to maintain different versions. We can't even use
wrappers due to the class loading problems you mentioned. And that's very
bad.
> <SNIP/>
>
> > Ok, I think if we decide to use our own versions of the interfaces
> > it will still be possible to do some hacky things and still provide
> > compatilibity with the Avalon versions.
>
> There will be an avalon sandbox for legacy code. There is nothing
> hacky in that.
Sorry, I wasn't clear above: the sandbox is not hacky. What I meant is that
*if* we decide to support the Avalon interfaces only in the sandbox, it
should
be possible to plugin a hacky solution that allows to use the avalon
interfaces
even in our blocks without any classloader problems.
To be honest, I still don't buy the classloader problem theory. I'm just
saying
that we should try to support interfaces like Configurable etc. We have own
classloaders for the blocks anyway, so it shouldn't be that hard, to solve
the
problem there.
If classloading is the only reason against these interfaces than I think we
can
solve it.
And the dependency is very minimal. It's just a dependency against the
avalon
framework api version 4.1.5 - a released version. There is no need in
following
the development of Avalon.
Carsten
Re: [Kernel22] How to develop a component?
Posted by Carsten Ziegeler <cz...@apache.org>.
"Bruno Dumon" <br...@outerthought.org> wrote:
>
> Haven't thought deeply about this, but just some thoughts (without
> choosing either way for now):
>
> - for Cocoon-specific components (e.g. sitemap components) it doesn't
> matter that much, except for the porting effort, both for us and for
> users who have custom-developed components.
Yepp.
>
> - for more generic components, one could argue that it should be easy
> enough to write a wrapper component around it that implements the
> correct interfaces. This for both directions, i.e. embedding non-Cocoon
> components in Cocoon or embedding Cocoon-components in other locations.
Yes, but if there are classloading problems when the avalon interfaces are
used directly,
than you have these problems with the wrappers as well.
Carsten
RE: [Kernel22] How to develop a component?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
> >
> > :) Sounds good to me. Now what do you think of using the
> things from
> > Avalon that are good (for us)? Now, I think, some of the interfaces
> > (for logging, contextualization, initialization) are good
> and we could
> > directly use them instead of building just a clone of them.
>
> There are two issues here, Carsten. One is about the present
> and another is about the future. Present indicates that
> reusing what's available is great, future indicates that if
> we keep dependencies on
> org.apache.avalon.* namespace we either end up forking it or,
> more likely, we have potential classloading collision issues
> in the future with things that avalon might produce.
>
> remember the rhino classloading problem with weblogic? same thing.
>
Sure.
> I strongly suggest that we start with org.apache.cocoon.* to
> avoid these problems down the road (including, yes, gump problems)
>
Yes, I understand of course all these problems, but I'm really afraid
of changing all the components now from Avalon interfaces to Cocoon
interfaces which are more or less the same but just use a different
package. In that case these components run in Cocoon but not in any
other container anymore that provides Avalon compatibility. And
that's imho bad. Not every project uses Cocoon, so it's absolutely
preferable to have components that I can use in several projects.
Ok, I think if we decide to use our own versions of the interfaces it
will still be possible to do some hacky things and still provide
compatilibity with the Avalon versions.
So what do others think?
Carsten
Re: [Kernel22] How to develop a component?
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
>
> Stefano Mazzocchi wrote:
>
>>Carsten Ziegeler wrote:
>>
>>
>>>I'm trying to figure out what the current kernel already
>>
>>provides and
>>
>>>what not.
>>>
>>>Let's forget all the xml (descriptors etc) for a moment. Imagine I
>>>want to write a block, that provides - let's say a special file
>>>generator - that can be used in other blocks (in my app block).
>>>
>>>Now, obviously this generator will implement our Cocoon
>>
>>Generator interface.
>>
>>>What else does the kernel already provide for the component
>>
>>lifecycle?
>>
>>>(Logging, Configuration etc.)
>>>
>>>Or is this a to discuss/do?
>>
>>I guess it's a to-do/to-discuss.
>>
>>The block design didn't deal with component lifecycle because
>>that's another concern (and, originally, it was supposed to
>>be taken care of by avalon).
>>
>
> Ok.
>
>
>>I don't know Pier's ideas about this.
>>
>>I think it's a good time for cleaning up what avalon did
>>wrong, simplify as much as we can and tune it for our needs.
>>
>>But I'm wide open to suggestions, as long as we move away from avalon.
>>
>
> :) Sounds good to me. Now what do you think of using the things from
> Avalon that are good (for us)? Now, I think, some of the interfaces
> (for logging, contextualization, initialization) are good and we could
> directly use them instead of building just a clone of them.
There are two issues here, Carsten. One is about the present and another
is about the future. Present indicates that reusing what's available is
great, future indicates that if we keep dependencies on
org.apache.avalon.* namespace we either end up forking it or, more
likely, we have potential classloading collision issues in the future
with things that avalon might produce.
remember the rhino classloading problem with weblogic? same thing.
I strongly suggest that we start with org.apache.cocoon.* to avoid these
problems down the road (including, yes, gump problems)
> The only interface which could be better is Serviceable/Composable
> where the lookup is done using a plain String. There we should use
> something like lookup(Interface, Hint).
This is already taken care of by the current kernel.
--
Stefano.
RE: [Kernel22] How to develop a component?
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
>
> Carsten Ziegeler wrote:
>
> > I'm trying to figure out what the current kernel already
> provides and
> > what not.
> >
> > Let's forget all the xml (descriptors etc) for a moment. Imagine I
> > want to write a block, that provides - let's say a special file
> > generator - that can be used in other blocks (in my app block).
> >
> > Now, obviously this generator will implement our Cocoon
> Generator interface.
> > What else does the kernel already provide for the component
> lifecycle?
> > (Logging, Configuration etc.)
> >
> > Or is this a to discuss/do?
>
> I guess it's a to-do/to-discuss.
>
> The block design didn't deal with component lifecycle because
> that's another concern (and, originally, it was supposed to
> be taken care of by avalon).
>
Ok.
> I don't know Pier's ideas about this.
>
> I think it's a good time for cleaning up what avalon did
> wrong, simplify as much as we can and tune it for our needs.
>
> But I'm wide open to suggestions, as long as we move away from avalon.
>
:) Sounds good to me. Now what do you think of using the things from
Avalon that are good (for us)? Now, I think, some of the interfaces
(for logging, contextualization, initialization) are good and we could
directly use them instead of building just a clone of them.
The only interface which could be better is Serviceable/Composable
where the lookup is done using a plain String. There we should use
something like lookup(Interface, Hint).
WDYT?
Carsten
Re: [Kernel22] How to develop a component?
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> I'm trying to figure out what the current kernel already provides
> and what not.
>
> Let's forget all the xml (descriptors etc) for a moment. Imagine I
> want to write a block, that provides - let's say a special file
> generator - that can be used in other blocks (in my app block).
>
> Now, obviously this generator will implement our Cocoon Generator interface.
> What else does the kernel already provide for the component lifecycle?
> (Logging, Configuration etc.)
>
> Or is this a to discuss/do?
I guess it's a to-do/to-discuss.
The block design didn't deal with component lifecycle because that's
another concern (and, originally, it was supposed to be taken care of by
avalon).
I don't know Pier's ideas about this.
I think it's a good time for cleaning up what avalon did wrong, simplify
as much as we can and tune it for our needs.
But I'm wide open to suggestions, as long as we move away from avalon.
--
Stefano.