RE: [RT] Separation of Blocks and Avalon
Berin Loritsch wrote: > > Carsten Ziegeler wrote: > > > Berin Loritsch wrote > > > >> > >>We can do it whenever you like. I just need to know when you > >>guys want it. When I have the green light, I will start working on it. > >> > > > > Great, Berin! In the meantime, we had discussed that we don't want > > to do blocks and fortress at the same time, but one after the other. > > So, we have just to decide the order, I guess. > > > > I have the perception, that you Berin, can start right now. Is > this right? > > essentially. I'll have a brief refamiliarization period though. > Yes, of course. But "right now" I meant "as soon as you well you can do it". Regards Carsten
Re: [RT] Separation of Blocks and Avalon
Reinhard Poetz wrote: ... ...if anybody thinks Berin shouldn't do it he should speak *now*! :-$ ;-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Separation of Blocks and Avalon
Carsten Ziegeler wrote: Berin Loritsch wrote We can do it whenever you like. I just need to know when you guys want it. When I have the green light, I will start working on it. Great, Berin! In the meantime, we had discussed that we don't want to do blocks and fortress at the same time, but one after the other. So, we have just to decide the order, I guess. I have the perception, that you Berin, can start right now. Is this right? essentially. I'll have a brief refamiliarization period though. And I also have the perception that blocks could in theory start right now but perhaps need some more pollishing before really touching code. So from my POV: fortress first then blocks. What do others think? Carsten -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin
Re: [RT] Separation of Blocks and Avalon
Reinhard Poetz wrote: The 2.2 CVS repository already exists (cocoon-2.2) - currently the rights are not set correctly. Stefano has already written a mail to Apache infrastructure to solve this issue. PMC Chairs should be able to administer their own repository's AVAIL info -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin
Re: [RT] Separation of Blocks and Avalon
On Tuesday, Oct 14, 2003, at 16:12 Europe/Rome, Carsten Ziegeler wrote: Berin Loritsch wrote We can do it whenever you like. I just need to know when you guys want it. When I have the green light, I will start working on it. Great, Berin! In the meantime, we had discussed that we don't want to do blocks and fortress at the same time, but one after the other. So, we have just to decide the order, I guess. I have the perception, that you Berin, can start right now. Is this right? And I also have the perception that blocks could in theory start right now but perhaps need some more pollishing before really touching code. So from my POV: fortress first then blocks. What do others think? +1 Let me remind you that work on all the block infrastructure *outside* cocoon can happen at the very same time. Look at the phases plan on the wiki: once we have the object model, we can start working on the block deployment tool (which lives completely outside cocoon) and on the block librarian (which is going to be itself a cocoon web app, but may be implemented without any block-specific feature). SoC at work! -- Stefano.
Re: [RT] Separation of Blocks and Avalon
On Tuesday, Oct 14, 2003, at 15:29 Europe/Rome, Berin Loritsch wrote: Stefano Mazzocchi wrote: Potentially possible, but I wouldn't do it, we need to be able to keep the 2.1 tree clean. Berin, how long would you think it would take you to do the migration? The simple migration will be fairly quick. For instance, it would take a couple of hours. The additional features, however, would take a bit more time. 90% could be worked around initially just by taking advantage of the way current Servlet containers work. Can you be more precise on this? I'm not sure I'm following you. do you have a list of things that worry you most? With help, I think we can migrate and stablize Cocoon 2.2 rather quickly. Cocoon would still need to extend Fortress a little to get the dynamically compiled generators (XSP) and such. XSP will probably be moved into a block, we might want to focus on the core stuff first. We also might need to create a new LifecycleHandler for Request bound components. The thing is passing the request object to the handler. We could do this with a more dynamic Context object, or we could use the Lifecycle Extensions API, or we could do a bit more like current ECM is operating. I'd like to follow the lifecycle extensions, if that was an option. from what I recall, it was implemented more or less exactly for those situations. These things will take some time to shake out the details for a better/pure environment, but Cocoon would be usable after the initial port. The XSP might be a disabled for a day or two, though. this is *not* a problem. the 2.2 tree can stay up in the air for as long as it takes. this is the reason why we made a different module. the day 2 day work continues on cocoon-2.1 BTW, why can't we do the migration *after* we implement the blocks? We can do it whenever you like. I just need to know when you guys want it. When I have the green light, I will start working on it. You have green light from me. I mean, we have a system that works and a design that improves. cocoon needs block far more than it needs a migration to a more modern avalon container. :) You know, I have a feeling that the more modern Avalon container will open up the doors to things you may not have thought possible beforehand. True I think you will find the new container and blocks will have a symbiotic relationship. Whichever you choose to implement first is up to you. Up to *US*, please. :-) Anyway, I think your volunteering deserves trust. for me: go! [please keep up posted with progess and, in case, request for help] -- Stefano.
RE: [RT] Separation of Blocks and Avalon
Berin Loritsch wrote > > We can do it whenever you like. I just need to know when you > guys want it. When I have the green light, I will start working on it. > Great, Berin! In the meantime, we had discussed that we don't want to do blocks and fortress at the same time, but one after the other. So, we have just to decide the order, I guess. I have the perception, that you Berin, can start right now. Is this right? And I also have the perception that blocks could in theory start right now but perhaps need some more pollishing before really touching code. So from my POV: fortress first then blocks. What do others think? Carsten
RE: [RT] Separation of Blocks and Avalon
From: Berin Loritsch > Reinhard Poetz wrote: > > > From: Berin Loritsch > > > > > > > >>We can do it whenever you like. I just need to know when you > >>guys want it. When I have the green light, I will start > working on it. > > > > > > We already voted on this > > > (http://marc.theaimsgroup.com/?l=xml-> cocoon-dev&m=106217462427048&w=2) > > and we had some talks at the GetTogether in Gent. > > There has been no -1 (and I didn't meet anybody in Gent who was > > against > > it) so just do it! > > > > ...if anybody thinks Berin shouldn't do it he should speak *now*! > > The only thing raised is when to start. The Cocoon community > has not yet voted to open up the Cocoon 2.2 repository--if > they have, I missed it. I know I should wait until the Cocoon > 2.2 is set up as a clean slate. The 2.2 CVS repository already exists (cocoon-2.2) - currently the rights are not set correctly. Stefano has already written a mail to Apache infrastructure to solve this issue. HTH Reinhard
Re: [RT] Separation of Blocks and Avalon
Reinhard Poetz wrote: From: Berin Loritsch We can do it whenever you like. I just need to know when you guys want it. When I have the green light, I will start working on it. We already voted on this (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106217462427048&w=2) and we had some talks at the GetTogether in Gent. There has been no -1 (and I didn't meet anybody in Gent who was against it) so just do it! ...if anybody thinks Berin shouldn't do it he should speak *now*! The only thing raised is when to start. The Cocoon community has not yet voted to open up the Cocoon 2.2 repository--if they have, I missed it. I know I should wait until the Cocoon 2.2 is set up as a clean slate. -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin
RE: [RT] Separation of Blocks and Avalon
From: Berin Loritsch > We can do it whenever you like. I just need to know when you > guys want it. When I have the green light, I will start working on it. We already voted on this (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106217462427048&w=2) and we had some talks at the GetTogether in Gent. There has been no -1 (and I didn't meet anybody in Gent who was against it) so just do it! ...if anybody thinks Berin shouldn't do it he should speak *now*! Cheers, Reinhard
Re: [RT] Separation of Blocks and Avalon
Geoff Howard wrote: Berin has expressed several times a confidence that the migration to Fortress could be relatively quick (though apparently he's suffered a minor back injury and is not completely convinced of his own sanity!). I am much better now. The pain is mostly gone, and I am only a bit stiff. How about this proposal: If Berin feels the migration can be quick (1 week?) we start a 2.2 repo, and let that be the only work that happens for that quick time frame in the 2.2 repo. If possible we should all help with aspects of the migration so we don't "come home to a strange house" so to speak. Absolutely. I can outline what would need to be done to the components so that the Roles file will not be necessary at all. That way you guys can take care of that detail while I work on the core infrastructure. If it bogs down, reveals nightmarish problems, etc. we have the option of wiping clean, moving on with blocks immediately on ECM and worry about the migration later. True. In any case, we have to (don't we?) regard the migration off ECM as inevitable and a little pain now is better than a lot of pain later. A lot of pain now is not better than the same amount of pain later. Which case we're in should be apparent if we try the path proposed above. Fortress does get you further away from a whitebox kernel, and closer to a more modular system. For more complex things like Cocoon that has customized ECM a bit, it isn't fully black box yet. We will get there though. -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin
Re: [RT] Separation of Blocks and Avalon
Stefano Mazzocchi wrote: Potentially possible, but I wouldn't do it, we need to be able to keep the 2.1 tree clean. Berin, how long would you think it would take you to do the migration? The simple migration will be fairly quick. For instance, it would take a couple of hours. The additional features, however, would take a bit more time. 90% could be worked around initially just by taking advantage of the way current Servlet containers work. do you have a list of things that worry you most? With help, I think we can migrate and stablize Cocoon 2.2 rather quickly. Cocoon would still need to extend Fortress a little to get the dynamically compiled generators (XSP) and such. We also might need to create a new LifecycleHandler for Request bound components. The thing is passing the request object to the handler. We could do this with a more dynamic Context object, or we could use the Lifecycle Extensions API, or we could do a bit more like current ECM is operating. These things will take some time to shake out the details for a better/pure environment, but Cocoon would be usable after the initial port. The XSP might be a disabled for a day or two, though. BTW, why can't we do the migration *after* we implement the blocks? We can do it whenever you like. I just need to know when you guys want it. When I have the green light, I will start working on it. I mean, we have a system that works and a design that improves. cocoon needs block far more than it needs a migration to a more modern avalon container. :) You know, I have a feeling that the more modern Avalon container will open up the doors to things you may not have thought possible beforehand. I think you will find the new container and blocks will have a symbiotic relationship. Whichever you choose to implement first is up to you. -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin
Re: [RT] Separation of Blocks and Avalon
Carsten Ziegeler wrote: Stephen McConnell wrote: The million little details that cocoon assumes on top of ECM is also the thing that scares me the most. Me, too. And I'm really wondering if we can keep our nice little additions if we move away from ECM. You may be able to, but they will be done differently. For instance, Merlin and Fortress use the Lifecycle Extensions API which can be used for most of the special things you are doing. Is there someone who provide the breakdown of what Cocoon is doing over and above ECM? However things roll out - one of the biggest obsticles I see is that we need to move away from ECM/Fortress extension and to a solution where Cocoon does not need to access container APIs. With that information the Avalon crowd can address how to addres these requirements in a way that makes the concern indpendent of the container implementaiton. We extend the ECM with our CocoonComponentManager, you can have a look at that class. All the features (hacks?) in there have to be somehow available using fortress, merlin or whatever. We have another lifecycle type, the request lifecycle component. This is an extension to poolable and means that per request only one instance of this component is used. So if two other components lookup this request lifecycle component, they get the same instance. The implementation of this extension is a little bit difficult as we have sub requests that run in the same thread but have a different set of request lifecycle components. In addition it's possible to process on request multi threaded which makes this even more difficult. You might be able to get around this with a PerThread model, as I am not aware of any Java Servlet container that shares the same thread between multiple requests. We will have to look at what options are available to implement this. There are some other important extensions like the environment handling for the source resolver and the sitemap configurable components. They use more or less the same technique used for the request lifecycle components. Right. I'm more and more thinking that we should do one thing after the other: first creating our blocks and than moving to fortress or merlin. Or the other way round, if someone things that it makes more sense. But we should avoid doing both at the same time. I mean, we are currently happy with ECM - it works, it's stable and the only real concern we have is the big cocoon.xconf which is solved with blocks anyway. (I don't want to say that fortress/merlin are not stable with this). ECM is ok when you already have an infrastructure built with it. However, maintaining the roles file and the component source code can let things get out of sync--esp. if you are refactoring. Fortress and Merlin will allow you to change EVERYTHING about the implementated component--including the package it resides in--without requiring changes anywhere else. Try that with ECM. It opens up the doors to refactoring a bit wider. -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin
RE: [RT] Separation of Blocks and Avalon
Reinhard Poetz wrote: > > PLEASE, don't start this discussion over and over again. We > > have (after > > a long painful discussion period) decided (or better reassured) that > > we create a new repository for 2.2. And Stefano wanted to contact > > infrastructure to create the 2.2 one. > > I hope my comment wasn't misleading. I support fully the community > decision to create new repositories instead of branches and I'm not > interested in leading this discussion again and again. > No, your comment wasn't misleading and as we talked at the GT about this I know your opinion. I just want to avoid starting this discussion again, perhaps I shoudn't have quoted you which had made things clearer. Sorry! Carsten
RE: [RT] Separation of Blocks and Avalon
From: Carsten Ziegeler > > Reinhard Poetz wrote: > > > > we need the 2.1 repository to be able to do 2.1.x releases. > > > Otherwise > > > > we would ship alpha code and I think people building their > > > > applications upon 2.1 wouldn't be very happy with this. > > > > > > That's one reason why CVS has branches. > > > > a new branch or a new repository? IIRC we decided *not* to > create any > > branches but to create new repositories instead. > > > > PLEASE, don't start this discussion over and over again. We > have (after > a long painful discussion period) decided (or better reassured) that > we create a new repository for 2.2. And Stefano wanted to contact > infrastructure to create the 2.2 one. I hope my comment wasn't misleading. I support fully the community decision to create new repositories instead of branches and I'm not interested in leading this discussion again and again. Reinhard
Re: [RT] Separation of Blocks and Avalon
Giacomo Pati wrote: On Fri, 10 Oct 2003, Geoff Howard wrote: How about this proposal: If Berin feels the migration can be quick (1 week?) we start a 2.2 repo, I would give him even 2 weeks ;-) :) Clarification: - We give _it_ x amount of time not him. I think we ought to be as involved as possible. - 1 week was really tossed out as a question to the one(s) who are in a position to guess what it will take and to start to define what "quick" would mean. 6 months of hard work is not quick. 1 day is quick. In-between is a judgement call we'll have to make and that's where I'd expect it to be. Geoff
RE: [RT] Separation of Blocks and Avalon
Reinhard Poetz wrote: > > > we need the 2.1 repository to be able to do 2.1.x releases. > > Otherwise > > > we would ship alpha code and I think people building their > > > applications upon 2.1 wouldn't be very happy with this. > > > > That's one reason why CVS has branches. > > a new branch or a new repository? IIRC we decided *not* to create any > branches but to create new repositories instead. > PLEASE, don't start this discussion over and over again. We have (after a long painful discussion period) decided (or better reassured) that we create a new repository for 2.2. And Stefano wanted to contact infrastructure to create the 2.2 one. Carsten
RE: [RT] Separation of Blocks and Avalon
Giacomo Pati wrote: > > > We extend the ECM with our CocoonComponentManager, you can have a look > > at that class. All the features (hacks?) in there have to be somehow > > available using fortress, merlin or whatever. > > We have another lifecycle type, the request lifecycle component. This is > > an extension to poolable and means that per request only one instance > > of this component is used. So if two other components lookup this > > request lifecycle component, they get the same instance. > > The implementation of this extension is a little bit difficult as we > > have sub requests that run in the same thread but have a different > > set of request lifecycle components. > > In addition it's possible to process on request multi threaded which > > makes this even more difficult. > > IIRC Fortress can handle this with a special Handler we have to supply > (instead of subclassing the hole Container class). Remeber that in > Fortress Object handling is separated into meta data instead of > additional marker interfaces. There is no Poolable, ThreadSafe, etc. any > more but ThreadSafeComponentHandler, PoolableComponentHandler instead. > Yes, I know - and I saw the handlers of fortress and it should work. > > There are some other important extensions like the environment handling > > for the source resolver and the sitemap configurable components. They > > use more or less the same technique used for the request lifecycle > > components. > > I'm sure there is a way for this also and with the help of a Handler it > can be made with IOC in mind. I'm not sure for the source resolver part. The other things should work, yes. > > Yes, but the world is still spinning and there are alot of other > Component out there that don't follow the ECM style because it's > deprecaded for long time now and every time we want to use such a > component we have to extend the working interface to make it a > 'Component' for ECM and extend the implementation to have our interface > implemented (do you remember the Cornerstone Scheduler?). That's ugly! > Definitly. Ok, that's a point. > As a side note: I got the impression (and that supprises me alot) there > is too little knowledge around here what Avalon is doing and where it is > moving in the so central Component Container discipline. This IMHO led > to this 'we think Avalon cannot supply what we want' situation and so we > are ignoring the helping hand Avalon people put forth several times now. > At least for me it's not the 'we think Avalon cannot supply what we want' that I fear of. It's more a "can the Avalon community support the version for us and for how long". Carsten
RE: [RT] Separation of Blocks and Avalon
From: [EMAIL PROTECTED] > > > In that case, is it possible to incrementally develop the > blocks in > > > the 2.1 repository while Berin works on the container in the > > > soon-to-be 2.2 > > > repository? > > > > -1 > > we need the 2.1 repository to be able to do 2.1.x releases. > Otherwise > > we would ship alpha code and I think people building their > > applications upon 2.1 wouldn't be very happy with this. > > That's one reason why CVS has branches. a new branch or a new repository? IIRC we decided *not* to create any branches but to create new repositories instead. Reinhard
RE: [RT] Separation of Blocks and Avalon
On Fri, 10 Oct 2003, Reinhard Poetz wrote: > > > From: Ryan Hoegg > > > > > > Stefano Mazzocchi wrote: > > > > > > > > On Friday, Oct 10, 2003, at 09:44 Europe/Rome, Carsten > > Ziegeler wrote: > > > > > >> I'm more and more thinking that we should do one thing after the > > >> other: first creating our blocks and than moving to fortress or > > >> merlin. Or the other way round, if someone things that it > > makes more > > >> sense. But we should avoid doing both at the same time. > > > > > > > > > +1000 > > > > > In that case, is it possible to incrementally develop the > > blocks in the > > 2.1 repository while Berin works on the container in the > > soon-to-be 2.2 > > repository? > > -1 > we need the 2.1 repository to be able to do 2.1.x releases. Otherwise we > would ship alpha code and I think people building their applications > upon 2.1 wouldn't be very happy with this. That's one reason why CVS has branches. -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: [RT] Separation of Blocks and Avalon
On Fri, 10 Oct 2003, Geoff Howard wrote: > How about this proposal: > > If Berin feels the migration can be quick (1 week?) we start a 2.2 repo, I would give him even 2 weeks ;-) > and let that be the only work that happens for that quick time frame in > the 2.2 repo. If possible we should all help with aspects of the > migration so we don't "come home to a strange house" so to speak. +1! > If it bogs down, reveals nightmarish problems, etc. we have the option > of wiping clean, moving on with blocks immediately on ECM and worry > about the migration later. Yes. > In any case, we have to (don't we?) regard the migration off ECM as > inevitable and a little pain now is better than a lot of pain later. A Exactly! > lot of pain now is not better than the same amount of pain later. Which > case we're in should be apparent if we try the path proposed above. -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
RE: [RT] Separation of Blocks and Avalon
On Fri, 10 Oct 2003, Carsten Ziegeler wrote: > Stephen McConnell wrote: > > > > The million little details that cocoon assumes on top of ECM is also the > > thing that scares me the most. Absolutely right! IMHO we've ridden our own train for too long and am now in the situation where we are far from what Avalon can supply to Cocoon in the Container arena. > > > Me, too. And I'm really wondering if we can keep our nice little additions > if we move away from ECM. See below. > > Is there someone who provide the breakdown of what Cocoon is doing over > > and above ECM? However things roll out - one of the biggest obsticles I > > see is that we need to move away from ECM/Fortress extension and to a > > solution where Cocoon does not need to access container APIs. With that > > information the Avalon crowd can address how to addres these > > requirements in a way that makes the concern indpendent of the container > > implementaiton. > > > We extend the ECM with our CocoonComponentManager, you can have a look > at that class. All the features (hacks?) in there have to be somehow > available using fortress, merlin or whatever. > We have another lifecycle type, the request lifecycle component. This is > an extension to poolable and means that per request only one instance > of this component is used. So if two other components lookup this > request lifecycle component, they get the same instance. > The implementation of this extension is a little bit difficult as we > have sub requests that run in the same thread but have a different > set of request lifecycle components. > In addition it's possible to process on request multi threaded which > makes this even more difficult. IIRC Fortress can handle this with a special Handler we have to supply (instead of subclassing the hole Container class). Remeber that in Fortress Object handling is separated into meta data instead of additional marker interfaces. There is no Poolable, ThreadSafe, etc. any more but ThreadSafeComponentHandler, PoolableComponentHandler instead. > There are some other important extensions like the environment handling > for the source resolver and the sitemap configurable components. They > use more or less the same technique used for the request lifecycle > components. I'm sure there is a way for this also and with the help of a Handler it can be made with IOC in mind. > I'm more and more thinking that we should do one thing after the other: > first creating our blocks and than moving to fortress or merlin. My hope was that the hole Classloader stuff could be delegated to one of the new Containers. > Or the other way round, if someone things that it makes more sense. > But we should avoid doing both at the same time. > I mean, we are currently happy with ECM - it works, it's stable and the > only real concern we have is the big cocoon.xconf which is solved with > blocks anyway. (I don't want to say that fortress/merlin are not stable > with this). Yes, but the world is still spinning and there are alot of other Component out there that don't follow the ECM style because it's deprecaded for long time now and every time we want to use such a component we have to extend the working interface to make it a 'Component' for ECM and extend the implementation to have our interface implemented (do you remember the Cornerstone Scheduler?). That's ugly! As a side note: I got the impression (and that supprises me alot) there is too little knowledge around here what Avalon is doing and where it is moving in the so central Component Container discipline. This IMHO led to this 'we think Avalon cannot supply what we want' situation and so we are ignoring the helping hand Avalon people put forth several times now. -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: [RT] Separation of Blocks and Avalon
Stefano Mazzocchi wrote: On Friday, Oct 10, 2003, at 10:44 Europe/Rome, Ryan Hoegg wrote: Stefano Mazzocchi wrote: On Friday, Oct 10, 2003, at 09:44 Europe/Rome, Carsten Ziegeler wrote: I'm more and more thinking that we should do one thing after the other: first creating our blocks and than moving to fortress or merlin. Or the other way round, if someone things that it makes more sense. But we should avoid doing both at the same time. +1000 In that case, is it possible to incrementally develop the blocks in the 2.1 repository while Berin works on the container in the soon-to-be 2.2 repository? Potentially possible, but I wouldn't do it, we need to be able to keep the 2.1 tree clean. Berin, how long would you think it would take you to do the migration? do you have a list of things that worry you most? BTW, why can't we do the migration *after* we implement the blocks? I mean, we have a system that works and a design that improves. cocoon needs block far more than it needs a migration to a more modern avalon container. Well, there is still the hope that a new container will solve some of our problems for us and the danger that solving them ourselves will make the migration more painful. I think no one knows whether either will happen because those who know Avalon best are a little shaky on Cocoon and vice-versa. Berin has expressed several times a confidence that the migration to Fortress could be relatively quick (though apparently he's suffered a minor back injury and is not completely convinced of his own sanity!). How about this proposal: If Berin feels the migration can be quick (1 week?) we start a 2.2 repo, and let that be the only work that happens for that quick time frame in the 2.2 repo. If possible we should all help with aspects of the migration so we don't "come home to a strange house" so to speak. If it bogs down, reveals nightmarish problems, etc. we have the option of wiping clean, moving on with blocks immediately on ECM and worry about the migration later. In any case, we have to (don't we?) regard the migration off ECM as inevitable and a little pain now is better than a lot of pain later. A lot of pain now is not better than the same amount of pain later. Which case we're in should be apparent if we try the path proposed above. Geoff
RE: [RT] Separation of Blocks and Avalon
> From: Ryan Hoegg > > > Stefano Mazzocchi wrote: > > > > > On Friday, Oct 10, 2003, at 09:44 Europe/Rome, Carsten > Ziegeler wrote: > > > >> I'm more and more thinking that we should do one thing after the > >> other: first creating our blocks and than moving to fortress or > >> merlin. Or the other way round, if someone things that it > makes more > >> sense. But we should avoid doing both at the same time. > > > > > > +1000 > > > In that case, is it possible to incrementally develop the > blocks in the > 2.1 repository while Berin works on the container in the > soon-to-be 2.2 > repository? -1 we need the 2.1 repository to be able to do 2.1.x releases. Otherwise we would ship alpha code and I think people building their applications upon 2.1 wouldn't be very happy with this. Cheers, Reinhard
Re: [RT] Separation of Blocks and Avalon
Stefano Mazzocchi wrote: BTW, why can't we do the migration *after* we implement the blocks? I mean, we have a system that works and a design that improves. cocoon needs block far more than it needs a migration to a more modern avalon container. -- Stefano. This sounds like a good idea, since we seem to have a much more mature idea of what the blocks implementation entails than the container change. One reason we might consider a new container first is that it might simplify the block design. One thread that is still active talks about how to expose classes to other blocks. This requirement might go away completely if blocks can access java in other blocks only through the avalon container, and we decide that any java code the block wants to provide must be packaged using a standard format. The risk is that the container upgrade is very complex and time consuming, causing all the good ideas about blocks to be put on hold. Of course ultimately the people doing the work will make the decision :) -- Ryan Hoegg
RE: [RT] Separation of Blocks and Avalon
Stefano Mazzocchi wrote: > >> > > In that case, is it possible to incrementally develop the blocks in > > the 2.1 repository while Berin works on the container in the > > soon-to-be 2.2 repository? > > Potentially possible, but I wouldn't do it, we need to be able to keep > the 2.1 tree clean. > > Berin, how long would you think it would take you to do the migration? > do you have a list of things that worry you most? > > BTW, why can't we do the migration *after* we implement the blocks? > > I mean, we have a system that works and a design that improves. cocoon > needs block far more than it needs a migration to a more modern avalon > container. > Amen :) Carsten
Re: [RT] Separation of Blocks and Avalon
On Friday, Oct 10, 2003, at 10:44 Europe/Rome, Ryan Hoegg wrote: Stefano Mazzocchi wrote: On Friday, Oct 10, 2003, at 09:44 Europe/Rome, Carsten Ziegeler wrote: I'm more and more thinking that we should do one thing after the other: first creating our blocks and than moving to fortress or merlin. Or the other way round, if someone things that it makes more sense. But we should avoid doing both at the same time. +1000 In that case, is it possible to incrementally develop the blocks in the 2.1 repository while Berin works on the container in the soon-to-be 2.2 repository? Potentially possible, but I wouldn't do it, we need to be able to keep the 2.1 tree clean. Berin, how long would you think it would take you to do the migration? do you have a list of things that worry you most? BTW, why can't we do the migration *after* we implement the blocks? I mean, we have a system that works and a design that improves. cocoon needs block far more than it needs a migration to a more modern avalon container. -- Stefano.
Re: [RT] Separation of Blocks and Avalon
Stefano Mazzocchi wrote: On Friday, Oct 10, 2003, at 09:44 Europe/Rome, Carsten Ziegeler wrote: I'm more and more thinking that we should do one thing after the other: first creating our blocks and than moving to fortress or merlin. Or the other way round, if someone things that it makes more sense. But we should avoid doing both at the same time. +1000 In that case, is it possible to incrementally develop the blocks in the 2.1 repository while Berin works on the container in the soon-to-be 2.2 repository?
Re: [RT] Separation of Blocks and Avalon
On Friday, Oct 10, 2003, at 09:44 Europe/Rome, Carsten Ziegeler wrote: I'm more and more thinking that we should do one thing after the other: first creating our blocks and than moving to fortress or merlin. Or the other way round, if someone things that it makes more sense. But we should avoid doing both at the same time. +1000 I mean, we are currently happy with ECM - it works, it's stable and the only real concern we have is the big cocoon.xconf which is solved with blocks anyway. (I don't want to say that fortress/merlin are not stable with this). Amen. -- Stefano.
RE: [RT] Separation of Blocks and Avalon
Stephen McConnell wrote: > > The million little details that cocoon assumes on top of ECM is also the > thing that scares me the most. > Me, too. And I'm really wondering if we can keep our nice little additions if we move away from ECM. > Is there someone who provide the breakdown of what Cocoon is doing over > and above ECM? However things roll out - one of the biggest obsticles I > see is that we need to move away from ECM/Fortress extension and to a > solution where Cocoon does not need to access container APIs. With that > information the Avalon crowd can address how to addres these > requirements in a way that makes the concern indpendent of the container > implementaiton. > We extend the ECM with our CocoonComponentManager, you can have a look at that class. All the features (hacks?) in there have to be somehow available using fortress, merlin or whatever. We have another lifecycle type, the request lifecycle component. This is an extension to poolable and means that per request only one instance of this component is used. So if two other components lookup this request lifecycle component, they get the same instance. The implementation of this extension is a little bit difficult as we have sub requests that run in the same thread but have a different set of request lifecycle components. In addition it's possible to process on request multi threaded which makes this even more difficult. There are some other important extensions like the environment handling for the source resolver and the sitemap configurable components. They use more or less the same technique used for the request lifecycle components. I'm more and more thinking that we should do one thing after the other: first creating our blocks and than moving to fortress or merlin. Or the other way round, if someone things that it makes more sense. But we should avoid doing both at the same time. I mean, we are currently happy with ECM - it works, it's stable and the only real concern we have is the big cocoon.xconf which is solved with blocks anyway. (I don't want to say that fortress/merlin are not stable with this). Carsten
Re: [RT] Separation of Blocks and Avalon
Stefano Mazzocchi wrote: On Thursday, Oct 9, 2003, at 17:15 Europe/Rome, Ryan Hoegg wrote: Rather than have cocoon blocks extend avalon blocks, I think cocoon blocks could use avalon blocks. Ok, I see your point. Instead of having a /COB-INF and a /BLOCK-inf, perhaps we include avalon blocks in /COB-INF/lib and delegate their deployment to the avalon container. This could even allow cocoon blocks to provide avalon blocks to the container, as well as require them. I would not know how to do this! I'm not scared by merlin, I'm scared about the million little details that cocoon assumes on top of ECM and that are now considered deprecated by the "modern" containers. The million little details that cocoon assumes on top of ECM is also the thing that scares me the most. if Fortress was there, admittedly, things would be easier... but then again, lots of talks, but nobody is able, wants or has time/energy/braveness to do the migration. Is there someone who provide the breakdown of what Cocoon is doing over and above ECM? However things roll out - one of the biggest obsticles I see is that we need to move away from ECM/Fortress extension and to a solution where Cocoon does not need to access container APIs. With that information the Avalon crowd can address how to addres these requirements in a way that makes the concern indpendent of the container implementaiton. It may help to distinguish between different types of dependencies: 1. Block dependency. As described in http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition and specified in http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring . What we (I think) have been talking about in several threads. 2a. Avalon dependency by block. This would be some avalon service/component that is required by the block, and would be explicitly declared. An example might be a Transformer or the Flow engine. 2b. Avalon dependency by avalon block/component/service. This would be some avalon service that is required by an avalon service or block that is included with the cocoon block. For example, I have a UserManager service that depends on a UserRepository service, which could be implemented by an OJBUserRepository. If the cocoon block included the UserManager block, it might ask the Parent Component Manager for a UserManager, and might be provided with the OJBUserRepository. I fear the complexity of such a move. Break the complexity down into managable chunks. 1. migrate from Component to Object 2. migrate from roles files to meta Just achiving the above opens up a much broader spectrum of possibilities and the question become much more concrete and substantive (from both sides of the equation). We have been discussing this over on Avalon land - subjects such as transition vehicles, migration tools, etc. these are way up on the agenda. Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED]
Re: [RT] Separation of Blocks and Avalon
Berin Loritsch wrote: Stefano Mazzocchi wrote: if Fortress was there, admittedly, things would be easier... but then again, lots of talks, but nobody is able, wants or has time/energy/braveness to do the migration. Huh? I have offered, and have been told to wait until Cocoon 2.2. So, is the repository ready? A can take care of it fairly quickly if so. I'll offer my help here, if there's something I can help with. Feel free to e-mail me personally, Berin. -- Ryan Hoegg
Re: [RT] Separation of Blocks and Avalon
On Thursday, Oct 9, 2003, at 22:52 Europe/Rome, Berin Loritsch wrote: Stefano Mazzocchi wrote: if Fortress was there, admittedly, things would be easier... but then again, lots of talks, but nobody is able, wants or has time/energy/braveness to do the migration. Huh? I have offered, and have been told to wait until Cocoon 2.2. So, is the repository ready? A can take care of it fairly quickly if so. no, it's not, but it's time we start. I'll ask infrastructure to create it, then start to move stuff around (from the server, so we don't loose CVS history). I'll ring the bell when I'm done and the repository is ready. -- Stefano.
Re: [RT] Separation of Blocks and Avalon
Stefano Mazzocchi wrote: if Fortress was there, admittedly, things would be easier... but then again, lots of talks, but nobody is able, wants or has time/energy/braveness to do the migration. Huh? I have offered, and have been told to wait until Cocoon 2.2. So, is the repository ready? A can take care of it fairly quickly if so. -- "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin
Re: [RT] Separation of Blocks and Avalon
Stefano Mazzocchi wrote: ... if Fortress was there, admittedly, things would be easier... but then again, lots of talks, but nobody is able, wants or has time/energy/braveness to do the migration. My impression is that Berin is willing, but he's just waiting on the 2.2 repository. Regards, Upayavira
Re: [RT] Separation of Blocks and Avalon
On Thursday, Oct 9, 2003, at 17:15 Europe/Rome, Ryan Hoegg wrote: Rather than have cocoon blocks extend avalon blocks, I think cocoon blocks could use avalon blocks. Ok, I see your point. Instead of having a /COB-INF and a /BLOCK-inf, perhaps we include avalon blocks in /COB-INF/lib and delegate their deployment to the avalon container. This could even allow cocoon blocks to provide avalon blocks to the container, as well as require them. I would not know how to do this! I'm not scared by merlin, I'm scared about the million little details that cocoon assumes on top of ECM and that are now considered deprecated by the "modern" containers. if Fortress was there, admittedly, things would be easier... but then again, lots of talks, but nobody is able, wants or has time/energy/braveness to do the migration. It may help to distinguish between different types of dependencies: 1. Block dependency. As described in http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition and specified in http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring . What we (I think) have been talking about in several threads. 2a. Avalon dependency by block. This would be some avalon service/component that is required by the block, and would be explicitly declared. An example might be a Transformer or the Flow engine. 2b. Avalon dependency by avalon block/component/service. This would be some avalon service that is required by an avalon service or block that is included with the cocoon block. For example, I have a UserManager service that depends on a UserRepository service, which could be implemented by an OJBUserRepository. If the cocoon block included the UserManager block, it might ask the Parent Component Manager for a UserManager, and might be provided with the OJBUserRepository. I fear the complexity of such a move. 2b is the situation in which I think we could leverage the work being done by the various avalon containers. We would not have to explicitly define transitive avalon dependencies, as the avalon container can infer those from the avalon block that we give to it. True and what you describe is a sane and balanced proposal. I just think that we should keep going with the design with have and with the use of the component model that we are used to and move on incrementally. The machinery required to implement a component manager that is block-aware is very simple, probably a few lines on top of what we already have. even classloading should be trivial since dependencies are explicit. but changing the way cocoon works in respect of component model, well, that's touching every single class!!! most of the cocoon developers are scared by this (me included), as this is the main reason why it didn't happen yet. I'm willing to implement blocks, even if this means to rewrite some code that is already somewhere else. I might be wrong, but the implementation should be relatively easy (Sylvain and I discussed things in detail). But moving from ECM to Fortress and from Fortress to Merlin for the entire cocoon component model? well, that scares the crap out of me in terms of number of lines of code to modify and potential bugs to introduce. But if someone more knowledgble wants to do the transition, I'd be more than happy to be proven wrong and have cocoon move to a technology that is supported actively and not considered obsolete by the community around it. Note, also, that your proposal is orthogonal to the implementation of cocoon blocks: today we use ECM and we keep use the same approach for java components provided by the cocoon blocks. if in the future we change to a different java component model, we change it everywhere, including blocks. if the migration is painless for cocoon own components (as it should be), it will be for blocks too. the two things are, IMO, independent and can happen at different times. -- Stefano.
Re: [RT] Separation of Blocks and Avalon
Stefano Mazzocchi wrote: On Wednesday, Oct 8, 2003, at 19:22 Europe/Rome, Ryan Hoegg wrote: Hi, I've been following the block design discussion and wiki evolution with great interest for a couple months now (blame Geoff). Blocks look wonderful, and I can't wait to develop my cocoon based applications as blocks. I have a concern about the bundling of exposed avalon services with blocks. Specifically, in the recent thread about "Finishing the First Phase of Block Design" and on http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition I see some duplicated effort. As Stephen McConnell noticed, some of this functionality is already built, tested, and maintained in several avalon containers. Why not package avalon blocks/services/components in the way the container expects, and include them somewhere like /COB-INF/lib or /COB-INF/public/lib? Or, even cleaner separation can be had in some cases by deploying them to the avalon container independently. If things are done this way, the problem noted in the thread I mentioned above could be completely avoided. There would be no need to expose classes through the block interface because all java would be exposed as avalon services. I think this would simplify the block design greatly, and allow us to focus on cocoon-specific aspects. Let me see if I get this right: you are proposing that we make cocoon blocks somewhat extend avalon blocks and we have /block-inf/ for information on the java components and /cob-inf/ for all the remainding cocoon-specific things, in order to be able to reuse existing avalon code? But how can I describe dependencies if one part uses implicit ones and the rest uses explicit ones? -- Stefano. Rather than have cocoon blocks extend avalon blocks, I think cocoon blocks could use avalon blocks. Instead of having a /COB-INF and a /BLOCK-inf, perhaps we include avalon blocks in /COB-INF/lib and delegate their deployment to the avalon container. This could even allow cocoon blocks to provide avalon blocks to the container, as well as require them. It may help to distinguish between different types of dependencies: 1. Block dependency. As described in http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition and specified in http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring . What we (I think) have been talking about in several threads. 2a. Avalon dependency by block. This would be some avalon service/component that is required by the block, and would be explicitly declared. An example might be a Transformer or the Flow engine. 2b. Avalon dependency by avalon block/component/service. This would be some avalon service that is required by an avalon service or block that is included with the cocoon block. For example, I have a UserManager service that depends on a UserRepository service, which could be implemented by an OJBUserRepository. If the cocoon block included the UserManager block, it might ask the Parent Component Manager for a UserManager, and might be provided with the OJBUserRepository. 2b is the situation in which I think we could leverage the work being done by the various avalon containers. We would not have to explicitly define transitive avalon dependencies, as the avalon container can infer those from the avalon block that we give to it. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net
Re: [RT] Separation of Blocks and Avalon
On Wednesday, Oct 8, 2003, at 19:22 Europe/Rome, Ryan Hoegg wrote: Hi, I've been following the block design discussion and wiki evolution with great interest for a couple months now (blame Geoff). Blocks look wonderful, and I can't wait to develop my cocoon based applications as blocks. I have a concern about the bundling of exposed avalon services with blocks. Specifically, in the recent thread about "Finishing the First Phase of Block Design" and on http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition I see some duplicated effort. As Stephen McConnell noticed, some of this functionality is already built, tested, and maintained in several avalon containers. Why not package avalon blocks/services/components in the way the container expects, and include them somewhere like /COB-INF/lib or /COB-INF/public/lib? Or, even cleaner separation can be had in some cases by deploying them to the avalon container independently. If things are done this way, the problem noted in the thread I mentioned above could be completely avoided. There would be no need to expose classes through the block interface because all java would be exposed as avalon services. I think this would simplify the block design greatly, and allow us to focus on cocoon-specific aspects. Let me see if I get this right: you are proposing that we make cocoon blocks somewhat extend avalon blocks and we have /block-inf/ for information on the java components and /cob-inf/ for all the remainding cocoon-specific things, in order to be able to reuse existing avalon code? But how can I describe dependencies if one part uses implicit ones and the rest uses explicit ones? -- Stefano.