You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/11/03 14:57:32 UTC
Fortress Conversion Stalled
I'll be honest with you, I remembered the last time I got involved in the COcoon
internals, and based on the state of the project at that time, I could easily
upgrade to Fortress. However things are much different now, and there are a
number of places that Cocoon is deeply wed to ECM.
I no longer have the time to really devote to it, and I don't want to hold up
development on Cocoon Blocks. I'm sure that it is just as frustrating to you as
it is to me that I was more confident than I should have been. At this time
though, we can rollback any changes that I have made, and you have only lost
a couple of weeks.
As Cocoon 2.2 development moves forward, I highly recommend that you more firmly
separate the concepts of container and component so that an upgrade would be
much easier.
There are a number of weaknesses in the ECM system that are addressed in
Fortress, with the net result of better scalability and performance. The
problem is that the way Cocoon is structured is truly dependent on the thinking
that went into ECM. It will take time to properly separate things, and such
changes are best done in small increments instead of forced changes. Cocoon
has some work to do before migration to Fortress or Merlin is only a matter
of a small increment.
I will be more than happy to help guide the smaller refactorings that would be
necessary, but I cannot commit to doing the job at this time. I am swamped with
work at work, and I am swamped with home improvements at home. I have no spare
time. Now if anyone wants to hire me so that I can work on it full time, then
there will be no excuse ;P
For the moment though, I can't really make the conversion yet.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re:
Fortress Conversion Stalled)
Posted by Giacomo Pati <gi...@apache.org>.
Antonio Gallardo wrote:
> Then who cares if 2.2 will take 2 years or more? Nobody!.
Nah,careful! Alot of people care of the new features and also case about
the time they will be ready to be used. Waiting for a 2.2 release which
happens in two years will throw us back to the 2.0 times and doesn't
seem that we've learned about it (release often and early).
> So lets
> continue. I think the new features discused for cocoon 2.2 are cool.
> Including the internals changes. Please continue.
If I understand Berin correctly he isn't able to continue. So, it's up
to us to bring the migration to an end.
--
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re: Fortress Conversion Stalled)
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Nov 5, 2003, at 14:58 Europe/Rome, Berin Loritsch wrote:
> Stefano Mazzocchi wrote:
>
>
>> I'm all for continuing the migration. Even better: the more hands do
>> the porting, the more people will know the internals, the better
>> shape the tree ends up being.
>> I think we should make a serious effort to finish this migration
>> rather than throw away what Berin did.
>> But this cannot drag along too much for the reason above.
>
> That is why I chose to "fail early" instead of dragging on and on.
I understood this and, believe me, I highly appreciated the move. So
far, in fact, that I'm now more than willing to keep going exactly to
honor your work and the respect you showed us in doing it and admitting
your problems so early and so honestly.
--
Stefano.
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re:
Fortress Conversion Stalled)
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
>
> I'm all for continuing the migration. Even better: the more hands do the
> porting, the more people will know the internals, the better shape the
> tree ends up being.
>
> I think we should make a serious effort to finish this migration rather
> than throw away what Berin did.
>
> But this cannot drag along too much for the reason above.
That is why I chose to "fail early" instead of dragging on and on.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re: Fortress Conversion Stalled)
Posted by Stefano Mazzocchi <st...@apache.org>.
On Monday, Nov 3, 2003, at 22:59 Europe/Rome, Antonio Gallardo wrote:
> Berin Loritsch dijo:
>> It only makes sense to roll back and start concentrating on Cocoon
>> Blocks at this time.
>>
>> I do highly recommend refactoring Cocoon bit by bit to remove ECM
>> assumptions wherever they exist so that the actual upgrade to Fortress
>> or Merlin will be much simpler.
>>
>> +1 from me.
>
>
> -1
>
> We cannot simply throw away the current work. Before starting we
> discused
> about the new features including the use of Fortress, etc and I think
> we
> can continue the road we made.
>
> Who said the road is easy, plain and nice? Nobody!
>
> Then who cares if 2.2 will take 2 years or more? Nobody!
Dead wrong. I believe that if cocoon doesn't get real block support in
less than 6 months, we will face somebody that will clone the cocoon
ideas and reimplement them in a much lighter version of a framework.
> . So lets
> continue. I think the new features discused for cocoon 2.2 are cool.
> Including the internals changes. Please continue.
I'm all for continuing the migration. Even better: the more hands do
the porting, the more people will know the internals, the better shape
the tree ends up being.
I think we should make a serious effort to finish this migration rather
than throw away what Berin did.
But this cannot drag along too much for the reason above.
--
Stefano.
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re: Fortress Conversion Stalled)
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Berin Loritsch dijo:
> It only makes sense to roll back and start concentrating on Cocoon
> Blocks at this time.
>
> I do highly recommend refactoring Cocoon bit by bit to remove ECM
> assumptions wherever they exist so that the actual upgrade to Fortress
> or Merlin will be much simpler.
>
> +1 from me.
-1
We cannot simply throw away the current work. Before starting we discused
about the new features including the use of Fortress, etc and I think we
can continue the road we made.
Who said the road is easy, plain and nice? Nobody!
Then who cares if 2.2 will take 2 years or more? Nobody!. So lets
continue. I think the new features discused for cocoon 2.2 are cool.
Including the internals changes. Please continue.
Best Regards,
Antonio Gallardo
Re: Jelly as treepressor was: rollback Cocoon 2.2 and do Fortress merge later
Posted by peter royal <pr...@apache.org>.
On Nov 4, 2003, at 5:03 AM, Stephan Michels wrote:
> But I see following problems:
>
> 1. Every tag seems to produce some XML content:
>
> // pass the output of the script somewhere
> Writer someWriter = new FileWriter( "output.xml" );
> XMLOutput output = XMLOutput.createXMLOutput( someWriter );
>
> // now run a script using a URL
> JellyContext context = new JellyContext();
> context.runScript( "foo.jelly", output );
> -------
> public class FooTag extends TagSupport {
>
> public void doTag(XMLOutput output) {
> ...
> }
> }
That's only an option. You can pass what is essentially a NoopXmlOutput
that doesn't output anything.
> 2. We configure components in the sitemap, which
> means we have some XML code, which should be processed.
> IHMO, its not a bad move to get rid of the configurations.
> Most cases can be solve by using Parameterizable.
That can still be captured and turned into a Configuration object, as
it is currently.
> 3. Jelly seems to need a <jelly> root element.
You can have your own root element.
-pete
Jelly as treepressor was: rollback Cocoon 2.2 and do Fortress merge
later
Posted by Stephan Michels <st...@apache.org>.
On Mon, 3 Nov 2003, Antonio Gallardo wrote:
> peter royal dijo:
> > On Nov 3, 2003, at 4:33 PM, Berin Loritsch wrote:
> >> Anyhoo, the basic solution is to either build a tree/graph of pure
> >> components
> >> or a tree/graph of pure beans. Either solution will work. We need to
> >> get rid
> >> of the need for the LifecycleHelper type class. I would lean more
> >> toward the
> >> bean approach for assembling the actual pipelines. It might make
> >> things a bit
> >> simpler, even to make custom hard-coded sitemaps.
> >
> > Anyone:
> >
> > Any thoughts about using Jelly as the builder for the sitemap?
> >
> > Its usage can be completely hidden, but as a tag processor, it might
> > work very well. We could use it to construct a bean-graph to model the
> > sitemap.
>
> Great! That also means usage of JXPath for retrieve the tags?
Yes, the idea is very interesting.
But I see following problems:
1. Every tag seems to produce some XML content:
// pass the output of the script somewhere
Writer someWriter = new FileWriter( "output.xml" );
XMLOutput output = XMLOutput.createXMLOutput( someWriter );
// now run a script using a URL
JellyContext context = new JellyContext();
context.runScript( "foo.jelly", output );
-------
public class FooTag extends TagSupport {
public void doTag(XMLOutput output) {
...
}
}
2. We configure components in the sitemap, which
means we have some XML code, which should be processed.
IHMO, its not a bad move to get rid of the configurations.
Most cases can be solve by using Parameterizable.
3. Jelly seems to need a <jelly> root element.
After all I see a great chance to refactor and clean up
the treeprocessor.
BTW, the Berin's idea to use a command queue
is also great. I like the idea very much.
request -> addCommand(process uri)
process uri -> addCommand(process flow)
process flow -> addCommand(process pipeline)
addCommand(release components);
addCommand(finish transactions);
Stephan.
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re: Fortress Conversion Stalled)
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
peter royal dijo:
> On Nov 3, 2003, at 4:33 PM, Berin Loritsch wrote:
>> Anyhoo, the basic solution is to either build a tree/graph of pure
>> components
>> or a tree/graph of pure beans. Either solution will work. We need to
>> get rid
>> of the need for the LifecycleHelper type class. I would lean more
>> toward the
>> bean approach for assembling the actual pipelines. It might make
>> things a bit
>> simpler, even to make custom hard-coded sitemaps.
>
> Anyone:
>
> Any thoughts about using Jelly as the builder for the sitemap?
>
> Its usage can be completely hidden, but as a tag processor, it might
> work very well. We could use it to construct a bean-graph to model the
> sitemap.
Great! That also means usage of JXPath for retrieve the tags?
Antonio Gallardo
Re: Migrating TreeProcessor to Fortress
Posted by Sylvain Wallez <sy...@apache.org>.
Unico Hommes wrote:
>
>
>
> Sylvain Wallez wrote:
>
>> Ryan Hoegg wrote:
>>
>>> peter royal wrote:
>>>
>>>> Anyone:
>>>>
>>>> Any thoughts about using Jelly as the builder for the sitemap?
>>>>
>>>> Its usage can be completely hidden, but as a tag processor, it
>>>> might work very well. We could use it to construct a bean-graph to
>>>> model the sitemap.
>>>>
>>>> -pete
>>>
>>>
>>>
>>>
>>> Sounds sensible. Is jelly in use anywhere else in Cocoon? It
>>> sounds like a great fit.
>>
>>
>>
>>
>> Jelly is not currently used in Cocoon. The idea is interesting, but
>> it also means a rewrite of a large part of the sitemap engine, and
>> doesn't give an immediate answer to the mixing between components and
>> container outlined by Berin.
>>
>> Note that I don't state this to protect the current treeprocessor,
>> but to minimize the work required to move to Fortress. Now I
>> recognize I don't know Jelly and thus how hard this would be.
>>
>
> I agree with this. Tonight I have been looking at the treeprocessor
> code and think it would be quite straightforward to move things to
> Fortress if we hold on to the idea of nodes as components. Proper
> components that is, as opposed to what has been previously dubbed
> 'pseudo components'. For this ProcessingNode and ProcessingNodeBuilder
> should be merged.
>
> The only thing that was not immediately clear to me was how to build
> the component graph structure. It seems that from a container POV the
> sitemap node elements perform two seperate functions.
>
> Consider the following snippet:
>
> <pipeline>
> <match pattern="...">
> ...
> </match>
> </pipeline>
>
> Here the match element both represents a component declaration of a
> MatchNode to the container _and_ a configuration element representing
> a child node to the PipelineNode.
Nope: the component declaration is in the <map:matcher> declaration in
the <map:components> section. This is where its class, configuration and
all the component declaration stuff is.
A <map:match> is a _use_ of that component. Sure, it can be transformed
in a component declaration by merging in the configuration that's in
<map:components> for each use of a particular component, but you'll end
up with as many different independent components as there are sitemap
_statements_, which will be a huge memory eater.
Or did I miss something?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: Migrating TreeProcessor to Fortress (was: Re: [VOTE] rollback Cocoon 2.2 ... )
Posted by Stefano Mazzocchi <st...@apache.org>.
On 9 Nov 2003, at 21:57, Unico Hommes wrote:
>
>
>
> Sylvain Wallez wrote:
>
>> Ryan Hoegg wrote:
>>> peter royal wrote:
>>>
>>>> Anyone:
>>>>
>>>> Any thoughts about using Jelly as the builder for the sitemap?
>>>>
>>>> Its usage can be completely hidden, but as a tag processor, it
>>>> might work very well. We could use it to construct a bean-graph to
>>>> model the sitemap.
>>>>
>>>> -pete
>>>
>>>
>>>
>>> Sounds sensible. Is jelly in use anywhere else in Cocoon? It
>>> sounds like a great fit.
>> Jelly is not currently used in Cocoon. The idea is interesting, but
>> it also means a rewrite of a large part of the sitemap engine, and
>> doesn't give an immediate answer to the mixing between components and
>> container outlined by Berin.
>> Note that I don't state this to protect the current treeprocessor,
>> but to minimize the work required to move to Fortress. Now I
>> recognize I don't know Jelly and thus how hard this would be.
>
> I agree with this. Tonight I have been looking at the treeprocessor
> code and think it would be quite straightforward to move things to
> Fortress if we hold on to the idea of nodes as components. Proper
> components that is, as opposed to what has been previously dubbed
> 'pseudo components'. For this ProcessingNode and ProcessingNodeBuilder
> should be merged.
>
> The only thing that was not immediately clear to me was how to build
> the component graph structure. It seems that from a container POV the
> sitemap node elements perform two seperate functions.
>
> Consider the following snippet:
>
> <pipeline>
> <match pattern="...">
> ...
> </match>
> </pipeline>
>
> Here the match element both represents a component declaration of a
> MatchNode to the container _and_ a configuration element representing
> a child node to the PipelineNode.
>
> This means that from a container POV the sitemap is a more human
> readable view on the 'actual' container configuration which looks more
> like:
>
> <pipeline id="p1">
> <childnode id-ref="m1" />
> </pipeline>
> <match id="m1" pattern="...">
> ...
> </match>
>
> Where the 'childnode' element now is a proper configuration element
> and match is a proper component declaration. Sitemap container
> configuration is then a transformation of the sitemap to a default
> container configuration.
>
> ParentProcessingNodes obtain their children by reading the reference
> id's to their child nodes during configuration phase and a simple
> lookup on the service manager during the service phase.
>
> I think we can use this approach nicely with view and resource lookups
> and sitemap component lookups as well:
>
> <sitemap>
> <components>
> <generators>
> <generator name="file" />
> ...
> <pipelines>
> ...
> <generate type="file" />
>
> becomes:
>
> <sitemap>
> <generator id="file-generator" />
> ...
> <generate ref-id="file-generator" />
> ...
> </sitemap>
>
>
> WDYT?
I agree with your vision. The sitemap describes things and uses them in
a sort of id/idref pairing but in different ways, depending of the
place (this was done to allow the sitemap to feel less programmable and
more "usable").
Now, what I don't get is what you're tring to do with this. I hope you
are not implying that we change the sitemap syntax in order to be more
fortress friendly, are you?
--
Stefano.
Migrating TreeProcessor to Fortress (was: Re: [VOTE] rollback Cocoon
2.2 ... )
Posted by Unico Hommes <un...@hippo.nl>.
Sylvain Wallez wrote:
> Ryan Hoegg wrote:
>
>> peter royal wrote:
>>
>>> Anyone:
>>>
>>> Any thoughts about using Jelly as the builder for the sitemap?
>>>
>>> Its usage can be completely hidden, but as a tag processor, it might
>>> work very well. We could use it to construct a bean-graph to model
>>> the sitemap.
>>>
>>> -pete
>>
>>
>>
>> Sounds sensible. Is jelly in use anywhere else in Cocoon? It sounds
>> like a great fit.
>
>
>
> Jelly is not currently used in Cocoon. The idea is interesting, but it
> also means a rewrite of a large part of the sitemap engine, and doesn't
> give an immediate answer to the mixing between components and container
> outlined by Berin.
>
> Note that I don't state this to protect the current treeprocessor, but
> to minimize the work required to move to Fortress. Now I recognize I
> don't know Jelly and thus how hard this would be.
>
I agree with this. Tonight I have been looking at the treeprocessor code
and think it would be quite straightforward to move things to Fortress
if we hold on to the idea of nodes as components. Proper components that
is, as opposed to what has been previously dubbed 'pseudo components'.
For this ProcessingNode and ProcessingNodeBuilder should be merged.
The only thing that was not immediately clear to me was how to build the
component graph structure. It seems that from a container POV the
sitemap node elements perform two seperate functions.
Consider the following snippet:
<pipeline>
<match pattern="...">
...
</match>
</pipeline>
Here the match element both represents a component declaration of a
MatchNode to the container _and_ a configuration element representing a
child node to the PipelineNode.
This means that from a container POV the sitemap is a more human
readable view on the 'actual' container configuration which looks more like:
<pipeline id="p1">
<childnode id-ref="m1" />
</pipeline>
<match id="m1" pattern="...">
...
</match>
Where the 'childnode' element now is a proper configuration element and
match is a proper component declaration. Sitemap container configuration
is then a transformation of the sitemap to a default container
configuration.
ParentProcessingNodes obtain their children by reading the reference
id's to their child nodes during configuration phase and a simple lookup
on the service manager during the service phase.
I think we can use this approach nicely with view and resource lookups
and sitemap component lookups as well:
<sitemap>
<components>
<generators>
<generator name="file" />
...
<pipelines>
...
<generate type="file" />
becomes:
<sitemap>
<generator id="file-generator" />
...
<generate ref-id="file-generator" />
...
</sitemap>
WDYT?
Unico
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re: Fortress Conversion Stalled)
Posted by peter royal <pr...@apache.org>.
On Nov 4, 2003, at 2:28 AM, Sylvain Wallez wrote:
> Jelly is not currently used in Cocoon. The idea is interesting, but it
> also means a rewrite of a large part of the sitemap engine, and
> doesn't give an immediate answer to the mixing between components and
> container outlined by Berin.
To further my line of thought... The current object model or the
sitemap would be converted from pseudo-objects to a more bean-like
structure. Jelly would just replace the XXXBuilder objects, and also
take care of managing what elements could be nested inside of others,
etc.
> Note that I don't state this to protect the current treeprocessor, but
> to minimize the work required to move to Fortress. Now I recognize I
> don't know Jelly and thus how hard this would be.
Now that I brought this up, I just might have to see how easy it will
be :)
-pete
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re:
Fortress Conversion Stalled)
Posted by Sylvain Wallez <sy...@apache.org>.
Ryan Hoegg wrote:
> peter royal wrote:
>
>> Anyone:
>>
>> Any thoughts about using Jelly as the builder for the sitemap?
>>
>> Its usage can be completely hidden, but as a tag processor, it might
>> work very well. We could use it to construct a bean-graph to model
>> the sitemap.
>>
>> -pete
>
>
> Sounds sensible. Is jelly in use anywhere else in Cocoon? It sounds
> like a great fit.
Jelly is not currently used in Cocoon. The idea is interesting, but it
also means a rewrite of a large part of the sitemap engine, and doesn't
give an immediate answer to the mixing between components and container
outlined by Berin.
Note that I don't state this to protect the current treeprocessor, but
to minimize the work required to move to Fortress. Now I recognize I
don't know Jelly and thus how hard this would be.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re:
Fortress Conversion Stalled)
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
peter royal wrote:
> Anyone:
>
> Any thoughts about using Jelly as the builder for the sitemap?
>
> Its usage can be completely hidden, but as a tag processor, it might
> work very well. We could use it to construct a bean-graph to model the
> sitemap.
>
> -pete
Sounds sensible. Is jelly in use anywhere else in Cocoon? It sounds
like a great fit.
--
Ryan Hoegg
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re: Fortress Conversion Stalled)
Posted by peter royal <pr...@apache.org>.
On Nov 3, 2003, at 4:33 PM, Berin Loritsch wrote:
> Anyhoo, the basic solution is to either build a tree/graph of pure
> components
> or a tree/graph of pure beans. Either solution will work. We need to
> get rid
> of the need for the LifecycleHelper type class. I would lean more
> toward the
> bean approach for assembling the actual pipelines. It might make
> things a bit
> simpler, even to make custom hard-coded sitemaps.
Anyone:
Any thoughts about using Jelly as the builder for the sitemap?
Its usage can be completely hidden, but as a tag processor, it might
work very well. We could use it to construct a bean-graph to model the
sitemap.
-pete
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re:
Fortress Conversion Stalled)
Posted by Berin Loritsch <bl...@apache.org>.
Bruno Dumon wrote:
> On Mon, 2003-11-03 at 22:33, Berin Loritsch wrote:
>
>>Sylvain Wallez wrote:
>>
>>
>>>Sure I will. It would clearly be a bad thing to trash the time and
>>>effort Bering has put there. I may not have the required time to do it
>>>by myself, but I'm ready to answer questions. So maybe with the combined
>>>support of Berin and me we can turn this into a deeper knowledge of the
>>>sitemap engine for the whole group.
>>>
>>>Berin, what's the major wall you hit in the TreeProcessor? AFAIU,
>>>Recomposable is a problem, but also something we can easily remove from
>>>the code with some light refactoring.
>>>
>>>What are the other difficult points?
>>
>>The TreeProcessor has a bunch of psuedo-components that are managed differently
>>than the regular container. <snip/>
>
>
> Just wondering: when does a component become a pseudo-component? As long
> as there is some code taking care of its lifecycle, I guess that would
> be enough?
>
Its the unclear management of the component. THe "psuedo-component" ascribes
to certain parts of the component contract, but not all of them. Also in this
case it is created by other components and then handed off to the tree processor
to manage. A true component will support all the component contracts and be
completely managed by the container.
That is the cheif difference. So with the TreeProcessor there is no complete
picture of management--i.e. one entity to create a component and destroy the
component as opposed to several entities to create components and one to destroy
them.
If all of these things act like a Singleton, then the "bean" approach would
work quite nicely. All we need to do is allow the beans to lookup and release
the components as necessary.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was
Re: Fortress Conversion Stalled)
Posted by Bruno Dumon <br...@outerthought.org>.
On Mon, 2003-11-03 at 22:33, Berin Loritsch wrote:
> Sylvain Wallez wrote:
>
> >
> > Sure I will. It would clearly be a bad thing to trash the time and
> > effort Bering has put there. I may not have the required time to do it
> > by myself, but I'm ready to answer questions. So maybe with the combined
> > support of Berin and me we can turn this into a deeper knowledge of the
> > sitemap engine for the whole group.
> >
> > Berin, what's the major wall you hit in the TreeProcessor? AFAIU,
> > Recomposable is a problem, but also something we can easily remove from
> > the code with some light refactoring.
> >
> > What are the other difficult points?
>
> The TreeProcessor has a bunch of psuedo-components that are managed differently
> than the regular container. <snip/>
Just wondering: when does a component become a pseudo-component? As long
as there is some code taking care of its lifecycle, I guess that would
be enough?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re:
Fortress Conversion Stalled)
Posted by Sylvain Wallez <sy...@apache.org>.
Berin Loritsch wrote:
> Sylvain Wallez wrote:
>
>>
>> Sure I will. It would clearly be a bad thing to trash the time and
>> effort Bering has put there. I may not have the required time to do
>> it by myself, but I'm ready to answer questions. So maybe with the
>> combined support of Berin and me we can turn this into a deeper
>> knowledge of the sitemap engine for the whole group.
>>
>> Berin, what's the major wall you hit in the TreeProcessor? AFAIU,
>> Recomposable is a problem, but also something we can easily remove
>> from the code with some light refactoring.
>>
>> What are the other difficult points?
>
Thanks for continuing the discussion, Berin.
> The TreeProcessor has a bunch of psuedo-components that are managed
> differently than the regular container. If these were all
> "threadsafe" components, there would be less of an issue here.
>
> We should either make them regular components, and provide
> "configuration" snippets, or make them beans and provide the full
> configuration. THe problem areas might be where we need to access a
> component. For those, we might need to use a "Component Proxy" that
> gets the type of component we are looking for from a typed interface
> like this:
>
> SitemapComponentProxy {
> Generator getGenerator(String type);
> Transformer getTransformer(String type);
> Serializer getSerializer(String type);
> Reader getReader(String type);
> Action getAction(String type);//NOTE: sets can simply be a
> //special action type with the same
> interface.
> }
>
> Anyhoo, the basic solution is to either build a tree/graph of pure
> components or a tree/graph of pure beans. Either solution will work.
> We need to get rid of the need for the LifecycleHelper type class. I
> would lean more toward the bean approach for assembling the actual
> pipelines. It might make things a bit simpler, even to make custom
> hard-coded sitemaps.
Processing nodes are organized in a tree and need to have some features
devoted to components such as accessing the CM/SM or needing to perform
some cleanup and thus being disposable.
This led to the current architecture since I considered that components
could only be have a flat organisation. Now maybe I was wrong, and would
like to know how we can build a clean tree of components (we're likely
to need this in Woody as well).
I'll be out of office tomorrow and it's currently late here (11:30pm),
but I will continue this thread as soon as time permits.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re:
Fortress Conversion Stalled)
Posted by Berin Loritsch <bl...@apache.org>.
Sylvain Wallez wrote:
>
> Sure I will. It would clearly be a bad thing to trash the time and
> effort Bering has put there. I may not have the required time to do it
> by myself, but I'm ready to answer questions. So maybe with the combined
> support of Berin and me we can turn this into a deeper knowledge of the
> sitemap engine for the whole group.
>
> Berin, what's the major wall you hit in the TreeProcessor? AFAIU,
> Recomposable is a problem, but also something we can easily remove from
> the code with some light refactoring.
>
> What are the other difficult points?
The TreeProcessor has a bunch of psuedo-components that are managed differently
than the regular container. If these were all "threadsafe" components, there
would be less of an issue here.
We should either make them regular components, and provide "configuration"
snippets, or make them beans and provide the full configuration. THe problem
areas might be where we need to access a component. For those, we might need
to use a "Component Proxy" that gets the type of component we are looking for
from a typed interface like this:
SitemapComponentProxy {
Generator getGenerator(String type);
Transformer getTransformer(String type);
Serializer getSerializer(String type);
Reader getReader(String type);
Action getAction(String type);//NOTE: sets can simply be a
//special action type with the same interface.
}
Anyhoo, the basic solution is to either build a tree/graph of pure components
or a tree/graph of pure beans. Either solution will work. We need to get rid
of the need for the LifecycleHelper type class. I would lean more toward the
bean approach for assembling the actual pipelines. It might make things a bit
simpler, even to make custom hard-coded sitemaps.
Also, another thing that will emmensely help the issues with RequestLifecycle
components is to refactor it so that there is an Environment.done() or .close()
method that signals the end of processing so that any request-based components
are released as is.
A very nice solution is to add a set of Commands to a "CommandQueue" that is
attached to the Request. The customized fortress container will then add the
release command to the request as needed. When the whole request is done, the
system will add all the commands to the central command queue so that it is
processed in the background. This solution will also allow you to add some
other clean up commands as needed.
The Servlet and Main systems would need to be modified to always close() the
environment to make that happen.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re:
Fortress Conversion Stalled)
Posted by Sylvain Wallez <sy...@apache.org>.
Torsten Curdt wrote:
>>> Berin, is it more the lack of time or more the tight
>>> coupling with ECM?
>>>
>>> I was so glad to see this effort and I am wondering
>>> ...how much ...and what is left to do? Maybe you
>>> could give a summary of what you came across?
>>>
>>> Maybe you just need some more helping hands?
>>
>>
>> Here is what is left to do:
>>
>> * Make the TreeBuilder system work with Fortress instead of ECM.
>> * Make the Main class work with the new bean.
>> * Get rid of the old bean.
>> * Incorporate the meta-generation into the ANT build
>
>
> I think this sounds doable! No reasons for a rollback!
> So the major obstacle is the treeprocessor...
>
>> * Test and make sure everything works.
>
>
> It's the new branch... no worries ;)
>
>> I have no more time, and the TreeBuilder is very tightly integrated.
>
>
> I am sure Sylvain will support anyone that will give it a try :)
Sure I will. It would clearly be a bad thing to trash the time and
effort Bering has put there. I may not have the required time to do it
by myself, but I'm ready to answer questions. So maybe with the combined
support of Berin and me we can turn this into a deeper knowledge of the
sitemap engine for the whole group.
Berin, what's the major wall you hit in the TreeProcessor? AFAIU,
Recomposable is a problem, but also something we can easily remove from
the code with some light refactoring.
What are the other difficult points?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re:
Fortress Conversion Stalled)
Posted by Christian Haul <ha...@informatik.tu-darmstadt.de>.
Torsten Curdt wrote:
>>> Berin, is it more the lack of time or more the tight
>>> coupling with ECM?
>>>
>>> I was so glad to see this effort and I am wondering
>>> ...how much ...and what is left to do? Maybe you
>>> could give a summary of what you came across?
>>>
>>> Maybe you just need some more helping hands?
>>
>>
>>
>> Here is what is left to do:
>>
>> * Make the TreeBuilder system work with Fortress instead of ECM.
>> * Make the Main class work with the new bean.
>> * Get rid of the old bean.
>> * Incorporate the meta-generation into the ANT build
>
>
> I think this sounds doable! No reasons for a rollback!
> So the major obstacle is the treeprocessor...
I too would like to see the migration first and don't like the rollback
idea. But then, I too have currently very little time for cocoon myself
(started a new job which ATM entails 3hrs commuting per day --
unfortunatly only small chunks so booting the laptop hardly makes sense).
OK, let's all spend some brain cycles with the treeprocessor!
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re:
Fortress Conversion Stalled)
Posted by Torsten Curdt <tc...@vafer.org>.
>> Berin, is it more the lack of time or more the tight
>> coupling with ECM?
>>
>> I was so glad to see this effort and I am wondering
>> ...how much ...and what is left to do? Maybe you
>> could give a summary of what you came across?
>>
>> Maybe you just need some more helping hands?
>
>
> Here is what is left to do:
>
> * Make the TreeBuilder system work with Fortress instead of ECM.
> * Make the Main class work with the new bean.
> * Get rid of the old bean.
> * Incorporate the meta-generation into the ANT build
I think this sounds doable! No reasons for a rollback!
So the major obstacle is the treeprocessor...
> * Test and make sure everything works.
It's the new branch... no worries ;)
> I have no more time, and the TreeBuilder is very tightly integrated.
I am sure Sylvain will support anyone that will give it a try :)
Currently I am also busy ...but maybe this would also be something
for an online programming session like on friday.
This week I cannot spend much more time on cocoon than fixing some
bugs on friday ...but maybe next week?!
> I think I have done the hard stuff OK (the support for Request Lifestyle
> and company).
>
> I can lend written/verbal support, but I have not time to devote to
> actual coding anymore. :(
Thats fair enough! Thanks for you efforts so far!
--
Torsten
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re:
Fortress Conversion Stalled)
Posted by Berin Loritsch <bl...@apache.org>.
Torsten Curdt wrote:
> Berin Loritsch wrote:
>
>> It only makes sense to roll back and start concentrating on Cocoon Blocks
>> at this time.
>>
>> I do highly recommend refactoring Cocoon bit by bit to remove ECM
>> assumptions
>> wherever they exist so that the actual upgrade to Fortress or Merlin
>> will be
>> much simpler.
>>
>> +1 from me.
>
>
> Berin, is it more the lack of time or more the tight
> coupling with ECM?
>
> I was so glad to see this effort and I am wondering
> ...how much ...and what is left to do? Maybe you
> could give a summary of what you came across?
>
> Maybe you just need some more helping hands?
Here is what is left to do:
* Make the TreeBuilder system work with Fortress instead of ECM.
* Make the Main class work with the new bean.
* Get rid of the old bean.
* Incorporate the meta-generation into the ANT build
* Test and make sure everything works.
I have no more time, and the TreeBuilder is very tightly integrated.
I think I have done the hard stuff OK (the support for Request Lifestyle
and company).
I can lend written/verbal support, but I have not time to devote to
actual coding anymore. :(
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re:
Fortress Conversion Stalled)
Posted by Torsten Curdt <tc...@vafer.org>.
Berin Loritsch wrote:
> It only makes sense to roll back and start concentrating on Cocoon Blocks
> at this time.
>
> I do highly recommend refactoring Cocoon bit by bit to remove ECM
> assumptions
> wherever they exist so that the actual upgrade to Fortress or Merlin
> will be
> much simpler.
>
> +1 from me.
Berin, is it more the lack of time or more the tight
coupling with ECM?
I was so glad to see this effort and I am wondering
...how much ...and what is left to do? Maybe you
could give a summary of what you came across?
Maybe you just need some more helping hands?
--
Torsten
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re:
Fortress Conversion Stalled)
Posted by Stephen McConnell <mc...@apache.org>.
Joerg Heinicke wrote:
> On 03.11.2003 17:18, Berin Loritsch wrote:
>
>> It only makes sense to roll back and start concentrating on Cocoon
>> Blocks
>> at this time.
>>
>> I do highly recommend refactoring Cocoon bit by bit to remove ECM
>> assumptions
>> wherever they exist so that the actual upgrade to Fortress or Merlin
>> will be
>> much simpler.
>>
>> +1 from me.
>
>
> -1
>
> I would like to see first the refactoring and the move to Fortress and
> afterwards the blocks even if I can not help much more than
> "Composable => Serviceable" (which is maybe not even needed for the
> move).
Migration from Composable --> Servicable is not mandatory but is *very*
highly recommended. The Composiable contract creates an artifical lock
that forces any service to use the Component interface. While this can
be deal with using proxies and the like - its just plain bad.
Serviceable and ServiceManager eliminate this issue completely.
Cheers, Steve.
>
>
> Joerg
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re:
Fortress Conversion Stalled)
Posted by Joerg Heinicke <jh...@virbus.de>.
On 03.11.2003 17:18, Berin Loritsch wrote:
> It only makes sense to roll back and start concentrating on Cocoon Blocks
> at this time.
>
> I do highly recommend refactoring Cocoon bit by bit to remove ECM
> assumptions
> wherever they exist so that the actual upgrade to Fortress or Merlin
> will be
> much simpler.
>
> +1 from me.
-1
I would like to see first the refactoring and the move to Fortress and
afterwards the blocks even if I can not help much more than "Composable
=> Serviceable" (which is maybe not even needed for the move).
Joerg
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re: Fortress Conversion Stalled)
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Lundi, 3 nov 2003, à 17:18 Europe/Zurich, Berin Loritsch a écrit :
> It only makes sense to roll back and start concentrating on Cocoon
> Blocks
> at this time....
+1
>> ...Now if anyone wants to hire me so that I can work on it full time,
>> then
>> there will be no excuse ;P...
This would be even better than the above proposal though ;-)
-Bertrand
RE: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re: Fortress Conversion Stalled)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Berin Loritsch [mailto:bloritsch@apache.org] wrote:
>
> It only makes sense to roll back and start concentrating on Cocoon Blocks
> at this time.
>
> I do highly recommend refactoring Cocoon bit by bit to remove ECM
> assumptions
> wherever they exist so that the actual upgrade to Fortress or
> Merlin will be
> much simpler.
>
> +1 from me.
>
But we have to be careful with this rollback as already other changes
have taken place (e.g. my environment handling changes).
However, afaik, a rollback would mean Resetable->Recyclable and reinstalling
the CocoonComponentManager, right?
Carsten
[VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re: Fortress
Conversion Stalled)
Posted by Berin Loritsch <bl...@apache.org>.
It only makes sense to roll back and start concentrating on Cocoon Blocks
at this time.
I do highly recommend refactoring Cocoon bit by bit to remove ECM assumptions
wherever they exist so that the actual upgrade to Fortress or Merlin will be
much simpler.
+1 from me.
Berin Loritsch wrote:
> I'll be honest with you, I remembered the last time I got involved in
> the COcoon
> internals, and based on the state of the project at that time, I could
> easily
> upgrade to Fortress. However things are much different now, and there
> are a
> number of places that Cocoon is deeply wed to ECM.
>
> I no longer have the time to really devote to it, and I don't want to
> hold up
> development on Cocoon Blocks. I'm sure that it is just as frustrating
> to you as
> it is to me that I was more confident than I should have been. At this
> time
> though, we can rollback any changes that I have made, and you have only
> lost
> a couple of weeks.
>
> As Cocoon 2.2 development moves forward, I highly recommend that you
> more firmly
> separate the concepts of container and component so that an upgrade
> would be
> much easier.
>
> There are a number of weaknesses in the ECM system that are addressed in
> Fortress, with the net result of better scalability and performance. The
> problem is that the way Cocoon is structured is truly dependent on the
> thinking
> that went into ECM. It will take time to properly separate things, and
> such
> changes are best done in small increments instead of forced changes.
> Cocoon
> has some work to do before migration to Fortress or Merlin is only a matter
> of a small increment.
>
> I will be more than happy to help guide the smaller refactorings that
> would be
> necessary, but I cannot commit to doing the job at this time. I am
> swamped with
> work at work, and I am swamped with home improvements at home. I have
> no spare
> time. Now if anyone wants to hire me so that I can work on it full
> time, then
> there will be no excuse ;P
>
> For the moment though, I can't really make the conversion yet.
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin