[
https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12624370#action_12624370
]
Grzegorz Kossakowski commented on COCOON-2216:
----------------------------------------------
Hi Imran,
I worked on this issue for a few hours but this turned out to be even more
complicated than I thought so I have no working code yet and tomorrow I won't
be able to work on this. :(
As I said, the idea is to create custom bean factory, I've started to write a
prototype of it:
package org.apache.cocoon.components.pipeline.spring;
import java.util.Stack;
public class ObjectModelFactoryBean implements
FactoryBean {
private InheritableThreadLocal<Stack<ObjectModel>> objectModelStack = new
InheritableThreadLocal<Stack<ObjectModel>>() {
protected Stack<ObjectModel> initialValue() {
Stack<ObjectModel> newStack = new Stack<ObjectModel>();
newStack.push(createObjectModel());
return newStack;
};
protected Stack<ObjectModel> childValue(Stack<ObjectModel> parentValue)
{
Stack<ObjectModel> newStack = new Stack<ObjectModel>();
try {
newStack.push((ObjectModel)parentValue.peek().clone());
} catch (CloneNotSupportedException e) {
// TODO Have to add some logging
e.printStackTrace();
}
return newStack;
};
};
public Object getObject() throws Exception {
synchronizeStack();
return objectModelStack.get().peek();
}
public Class<ObjectModel> getObjectType() {
return ObjectModel.class;
}
public boolean isSingleton() {
return false;
}
/**
* This method is heart of this class.
* It's purpose is to synchronize its own internal stack with stack
maintained by Servlet Service Framework
* for servlet: calls and stack maintained by Cocoon Core for cocoon:
calls.
*/
protected void synchronizeStack() {
//no implementation at the moment
}
protected ObjectModel createObjectModel() {
//here we'll need to create ObjectModelImpl instance
//and inject all initial values
return null;
}
}
Only once I started to write it I realized that there is a problem with cyclic
dependencies caused by this class. The point is that, synchronizeStack must
have an access to both Cocoon Core and Servlet Service Framework classes and
itself must be placed in Cocoon Core.
But, by design, Cocoon core cannot depend on SSF. If I decide to put it
somewhere then cyclic dependencies are starting to appear. I have some ideas
how to create two different object factories and design whole thing in layered
why so layers can be independent but this will take me some time.
On the other hand, this issue has got a higher priority for me because my
company that I'm working at want to have it fixed as well so at least you can
be sure that it will get fixed sooner or later.
I'll continue my work on this issue on monday and I'll have to fix it until
Friday because later on I'll be busy with completely Cocoon-unrelated stuff.
> IncludeCacheManager can not perfom parallel includes
> ----------------------------------------------------
>
> Key: COCOON-2216
> URL: https://issues.apache.org/jira/browse/COCOON-2216
> Project: Cocoon
> Issue Type: Bug
> Components: - Components: Sitemap
> Affects Versions: 2.2-dev (Current SVN)
> Reporter: Christoph Gaffga
> Assignee: Grzegorz Kossakowski
> Attachments: cocoon-trunk.patch,
> ParallelInclusionProblem-cocoon_TRUNK.patch, test-block.zip, test-webapp.zip
>
>
> Since we migrated from cocoon 2.1 to 2.2 a generator that merges multiple
> sources from other cocoon pipelines into one (similar to the aggregator) is
> not working anymore.
> We also posted our problem to the mailing list, got little feedback but it
> brought us on the right way...
> see also: http://www.mail-archive.com/[EMAIL PROTECTED]/msg42173.html
> I found out that it's a problem with the DefaultIncludeCacheManager, that can
> not do parallel inclusion of cocoon-pipelines anymore. I checked several
> classes where inclusion is used. In the aggregator parallel inclusion is not
> an option anymore, in CIncludeTransformer the IncludeCacheManager is used,
> but it can't do parallel inclusion. In the new IncludeTransfomer parallel
> inclusion is supported, but it does not use caching as it does not use the
> IncludeCacheManager...
> But we needed caching AND parallel processing, so I tried to find out what's
> broken in the DefaultIncludeCacheManager:
> and it seems that the ThreadLocal variables are not initialized for the child
> threads that do the inclusion. Neither the spring context nor the old
> environment stuff was initialized. And all the source resolving was done
> outside the child thread and that way using the wrong thread context.
> We were able to fix that issue by small changes to DefaultIncludeCacheManager
> and IncludeCacheManagerSession. It would be great if somebody could apply
> this patch so we don'T have to patch every cocoon version again and again...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
