> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Leo Simons
>
> Leo Sutic wrote:
> >>From: news [mailto:[EMAIL PROTECTED] 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
Leo Sutic wrote:
From: news [mailto:[EMAIL PROTECTED] 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 preserv
ed.
Swappable - should be swapped using ALT3
Nothing declared - should be swapped using ALT2.
Ralph
-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 08, 2004 12:45 PM
To: [EMAIL PROTECTED]
Subject: Re: [Kernel22] How to develop a component?
> From: news [mailto:[EMAIL PROTECTED] 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
Ralph Goers wrote:
I think you have captured this pretty well. Some thoughts:
ALT1 - IMO the disadvantages are worse than they appear. Yes, distributed
apps and DB connections exhibit this behavior, but when you are talking
about ALL the cocoon components having this behavior the code will tur
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 intac
> -Original Message-
> From: Ralph Goers [mailto:[EMAIL PROTECTED]
> Sent: den 8 april 2004 19:52
> To: '[EMAIL PROTECTED]'
> Subject: RE: [Kernel22] How to develop a component?
>
>
> I think you have captured this pretty well. Some thoughts:
>
TED]
Sent: Thursday, April 08, 2004 10:29 AM
To: [EMAIL PROTECTED]
Subject: RE: [Kernel22] How to develop a component?
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?
An
> From: news [mailto:[EMAIL PROTECTED] 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 s
Leo Sutic wrote:
From: news [mailto:[EMAIL PROTECTED] 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.
made that into an actual testcase :-D:
public abstract class ReloadingProxyTestCase exte
PROTECTED]
Sent: Thursday, April 08, 2004 7:38 AM
To: [EMAIL PROTECTED]
Subject: RE: [Kernel22] How to develop a component?
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 unde
> > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
> >
> > 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'
Leo Sutic wrote:
>
> > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
> >
> > 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
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
>
> 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 wit
Leo Sutic wrote:
>
> > -Original Message-
> > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
> > Sent: den 8 april 2004 16:24
> > To: [EMAIL PROTECTED]
> > Subject: RE: [Kernel22] How to develop a component?
> >
> >
> > >
&
> -Original Message-
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
> Sent: den 8 april 2004 16:24
> To: [EMAIL PROTECTED]
> Subject: RE: [Kernel22] How to develop a component?
>
>
> >
> > > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
&
Leo Sutic wrote:
From: news [mailto:[EMAIL PROTECTED] 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 stil
>
> > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
> >
> > 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 s
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
>
> How does the working code look like?
The working code of what?
The adapter / sandbox / compatibility layer?
/LS
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:
>
> StatefulCompon
> From: news [mailto:[EMAIL PROTECTED] 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 t
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!]
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 peop
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 d
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
>
> 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.
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 gu
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
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 versi
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
insi
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 tom
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 fu
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
component
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
b
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 n
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
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
> > pr
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 o
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
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, i
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 s
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 should
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
>
> 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 tha
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
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
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 m
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
"Stefano Mazzocchi" <[EMAIL PROTECTED]> 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.
"Bruno Dumon" <[EMAIL PROTECTED]> 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 wh
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
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
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 Ava
> From: news [mailto:[EMAIL PROTECTED] 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
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
inte
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 bui
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 bu
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)
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 build
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
gen
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
>
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 IM
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 bl
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
genera
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
> > gen
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 blo
64 matches
Mail list logo
