RE: [Kernel22] How to develop a component?
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 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?
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?
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?
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. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Kernel22] How to develop a component?
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. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Kernel22] How to develop a component?
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 Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [Kernel22] How to develop a component?
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. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Kernel22] How to develop a component?
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. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Kernel22] How to develop a component?
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. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Kernel22] How to develop a component?
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. smime.p7s Description: S/MIME Cryptographic Signature
RE: [Kernel22] How to develop a component?
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. [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?
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?
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?
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?
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 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?
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?
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] 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?
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 same. So, the different should be in the client.java code. Or am I wrong? Carsten
Re: [Kernel22] How to develop a component?
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 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-devm=108033164725441w=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?
-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] 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?
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?
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 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?
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 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?
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 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?
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'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?
Sorry, but this cannot work. Calling comp.ensureWired() accomplishes
nothing because the component could be dropped between completion of that
call and the next.
This whole idea will create the ugliest client code you have ever seen,
because each and every operation could fail, in which case you will have to
start over again from the beginning, or fail the whole thing (and probably
make somebody else retry the whole thing).
I'm with Sylvain on this one. Don't get rid of the block until it is
released.
Ralph
-Original Message-
From: Carsten Ziegeler [mailto:[EMAIL 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 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?
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.
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.
RE: [Kernel22] How to develop a component?
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 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?
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 turn into nothing but error handling logic. This is just plain non-workable in my view. ALT2 - Hmmm. You want to hot swap a singleton? Can you EVER really do that? Not only for the reasons you mentioned, but because presumably the singleton is managing stuff that is supposed to be permanently available. In this case your singleton is no longer a singleton. Frankly, I'd suggest that classes meant to be singletons should implement a Singleton (or NonSwappable or whatever) interface to prevent them from ever being reloaded. By the way - I think this is a problem for ALL the alternatives, not just this one. ALT3 - From a client perspective, this looks just like ALT2. The client does a lookup that obtains a read lock while release does the unlock. Since the Singleton thing makes no sense to me anyway, I'd say use ALT2. Ralph -Original Message- From: Leo Sutic [mailto:[EMAIL PROTECTED] 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? 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?
-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: 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 turn into nothing but error handling logic. This is just plain non-workable in my view. ALT2 - Hmmm. You want to hot swap a singleton? Can you EVER really do that? I have situations where you can have zero or one instance, but not two or more. For example, a DB has an upper limit to the number of connections it can handle. If a component is a client of the DB (it is a connection pool), I want to know that I either have no connection pool, or exactly one connection pool. If you suddenly run two side-by-side, then the new pool will never acquire a connection, while the old one will hold on to the ones it has acquired until it is released (and who knows when that may be). /LS
Re: [Kernel22] How to develop a component?
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?
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 turn into nothing but error handling logic. This is just plain non-workable in my view. ALT2 - Hmmm. You want to hot swap a singleton? Can you EVER really do that? Not only for the reasons you mentioned, but because presumably the singleton is managing stuff that is supposed to be permanently available. In this case your singleton is no longer a singleton. Frankly, I'd suggest that classes meant to be singletons should implement a Singleton (or NonSwappable or whatever) interface to prevent them from ever being reloaded. By the way - I think this is a problem for ALL the alternatives, not just this one. ALT3 - From a client perspective, this looks just like ALT2. The client does a lookup that obtains a read lock while release does the unlock. Since the Singleton thing makes no sense to me anyway, I'd say use ALT2. Ralph, what about when you want to hotswap your singleton to a new version? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
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 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?
Obviously, if I declared it as NonSwappable hot swapping would not be allowed - at least for the class (that doesn't mean the rest of the block couldn't be swapped, but that complicates matters). I guess I can envision 3 types: NonSwappable - can't ever be hotswapped. 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? Ralph Goers wrote: is managing stuff that is supposed to be permanently available. In this case your singleton is no longer a singleton. Frankly, I'd suggest that classes meant to be singletons should implement a Singleton (or NonSwappable or whatever) interface to prevent them from ever being reloaded. By the way - I think this is a problem for ALL the alternatives, not just this one. ALT3 - From a client perspective, this looks just like ALT2. The client does a lookup that obtains a read lock while release does the unlock. Since the Singleton thing makes no sense to me anyway, I'd say use ALT2. Ralph, what about when you want to hotswap your singleton to a new version? -- Stefano.
Re: [Kernel22] How to develop a component?
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 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?
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 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?
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. 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?
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?
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?
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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
RE: [Kernel22] How to develop a component?
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?
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 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?
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?
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 Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [Kernel22] How to develop a component?
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?
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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [Kernel22] How to develop a component?
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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [Kernel22] How to develop a component?
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?
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 Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [Kernel22] How to develop a component?
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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
RE: [Kernel22] How to develop a component?
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?
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. smime.p7s Description: S/MIME Cryptographic Signature
RE: [Kernel22] How to develop a component?
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?
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 [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [Kernel22] How to develop a component?
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?
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. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Kernel22] How to develop a component?
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 [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
RE: [Kernel22] How to develop a component?
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 uses proxies etc? /LS
Re: [Kernel22] How to develop a component?
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?
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. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Kernel22] How to develop a component?
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?
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?
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. smime.p7s Description: S/MIME Cryptographic Signature
