You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2003/11/03 20:43:01 UTC
Re: [VOTE] rollback Cocoon 2.2 and do Fortress merge later (was Re:
Fortress Conversion Stalled)
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: 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