RCL plug-in and different classloaders issues
Hi, I'm just playing around with Cocoon's RCL plug-in in some more complicated scenario and stumbled upon a problem when the same class is loaded by two different classloaders. In brief, following steps are performed: 1. Class from my block is loaded using ResourceStoreClassLoader. Let's call this class MAIN. 2. This class accesses some static method of another class loaded by ResourceStoreClassLoader (because this class comes from my block as well) and sets some value on static field. Let's call this class STATIC 3. Then another class (3RDPARTY) is being loaded which is not part of my block, it's from third-party jar. It's loaded by parent classloader to ResourceStoreClassLoader. As part of configuration of this class I pass a name of class which is some kind of extension point and is implemented by class coming from my block; let's call this class EXTENSION. 4. 3RDPARTY creates new instance of EXTENSION class (and this class is again not loaded by ResourceStoreClassLoader but by parent), but in EXTENSION class one tries to access field set in STATIC. 5. While EXTENSION tries to access STATIC, STATIC is being loaded again, using parent classloader. The value in STATIC is gone, obviously. So the basic problem is that, this STATIC class is loaded by two different classloaders. I'm wondering if there is any kind of general solution to such problems. The only one I can think of is to enforce loading of 3RDPARTY class by ResourceStoreClassLoader so everything stays within one classloader and even reflection tricks are not dangerous. However, that would mean that one needs to modify commons-jci project. Is there any simpler method? -- Grzegorz Kossakowski
Re: svn commit: r685792 - in /cocoon/trunk/core: cocoon-core/ cocoon-core/src/main/java/org/apache/cocoon/spring/ cocoon-core/src/main/resources/META-INF/cocoon/spring/ cocoon-servlet-service/cocoon-s
Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
Author: reinhard Date: Thu Aug 14 00:43:31 2008 New Revision: 685792
URL: http://svn.apache.org/viewvc?rev=685792view=rev Log: The
BlockPathPropertyPlaceholderConfigurer module is *usually* only useful
if the SSF is used
together with Cocoon. In this case you always need the SSF-components.
Hence it's best to move it
to into this module so that Cocoon 2.2 can still be run in the
'classic' mode.
Somehow agreed. It looks like nobody is going to use SSF+Blocks
infrastructure without Cocoon Core, right? :-)
(I can't help myself but somehow the
BlockPathPropertyPlaceholderConfigurer seems to be a hack
anyway ...)
What do you mean by that? What makes it hacky?
I'm still not convinced that we should expose block resources directly.
But there are use cases for it
(http://cocoon.markmail.org/message/vr72n4vr7lfpppfe) and we've already
introduced this contract so it probably doesn't make much sense to
discuss this again.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
Re: RCL plug-in and different classloaders issues
In brief, following steps are performed: 1. Class from my block is loaded using ResourceStoreClassLoader. Let's call this class MAIN. 2. This class accesses some static method of another class loaded by ResourceStoreClassLoader (because this class comes from my block as well) and sets some value on static field. Let's call this class STATIC Just a quick comment: static + classloader == evil ;-) 3. Then another class (3RDPARTY) is being loaded which is not part of my block, it's from third-party jar. It's loaded by parent classloader to ResourceStoreClassLoader. As part of configuration of this class I pass a name of class which is some kind of extension point and is implemented by class coming from my block; let's call this class EXTENSION. 4. 3RDPARTY creates new instance of EXTENSION class (and this class is again not loaded by ResourceStoreClassLoader but by parent), but in EXTENSION class one tries to access field set in STATIC. 5. While EXTENSION tries to access STATIC, STATIC is being loaded again, using parent classloader. The value in STATIC is gone, obviously. So the basic problem is that, this STATIC class is loaded by two different classloaders. I'm wondering if there is any kind of general solution to such problems. The only one I can think of is to enforce loading of 3RDPARTY class by ResourceStoreClassLoader so everything stays within one classloader and even reflection tricks are not dangerous. Well, if you think about it: with this setup there is no other way around to have the parent classloader know of the static class to have this problem resolved. As you can't (?) modify the parent classloader your only chance is to have the EXTENSION loaded by the RSCL as well. I would take a step back and re-think the situation. This static stuff smells like wants to be replaced ;-) However, that would mean that one needs to modify commons-jci project. Why? How? cheers -- Torsten
Re: RCL plug-in and different classloaders issues
Torsten Curdt pisze: Just a quick comment: static + classloader == evil ;-) :-) Yes, I thought the same but is there any other solution in scenario I outlined when it's thirdparty class that creates a new instance of your class, which in turn needs to access some of your resources? 3. Then another class (3RDPARTY) is being loaded which is not part of my block, it's from third-party jar. It's loaded by parent classloader to ResourceStoreClassLoader. As part of configuration of this class I pass a name of class which is some kind of extension point and is implemented by class coming from my block; let's call this class EXTENSION. 4. 3RDPARTY creates new instance of EXTENSION class (and this class is again not loaded by ResourceStoreClassLoader but by parent), but in EXTENSION class one tries to access field set in STATIC. 5. While EXTENSION tries to access STATIC, STATIC is being loaded again, using parent classloader. The value in STATIC is gone, obviously. So the basic problem is that, this STATIC class is loaded by two different classloaders. I'm wondering if there is any kind of general solution to such problems. The only one I can think of is to enforce loading of 3RDPARTY class by ResourceStoreClassLoader so everything stays within one classloader and even reflection tricks are not dangerous. Well, if you think about it: with this setup there is no other way around to have the parent classloader know of the static class to have this problem resolved. As you can't (?) modify the parent classloader your only chance is to have the EXTENSION loaded by the RSCL as well. But how this can be enforced? I mean, 3RDPARTY is loaded by parent and 3RDPARTY, when tries to create a new instance of EXTENSION uses it's own classloader thus uses parent. The only solution I can see here is that I load 3RDPARTY using classloader coming from JCI so then EXTENSION will be loaded with this classloader as well. Am I missing something? I would take a step back and re-think the situation. This static stuff smells like wants to be replaced ;-) If I knew how to do it, I would go with that direction immediately. :-P Basically, the problem is that one wants to access Spring's application context within EXTENSION's constructor. Any suggestion how to do it without using static class? However, that would mean that one needs to modify commons-jci project. Why? How? I was thinking to enforce ResourceStoreClassLoader to load everything but I know that it's not the best idea... -- Grzegorz Kossakowski
Re: svn commit: r685792 - in /cocoon/trunk/core: cocoon-core/ cocoon-core/src/main/java/org/apache/cocoon/spring/ cocoon-core/src/main/resources/META-INF/cocoon/spring/ cocoon-servlet-service/cocoon-s
Reinhard Pötz pisze: Grzegorz Kossakowski wrote: [EMAIL PROTECTED] pisze: Author: reinhard Date: Thu Aug 14 00:43:31 2008 New Revision: 685792 URL: http://svn.apache.org/viewvc?rev=685792view=rev Log: The BlockPathPropertyPlaceholderConfigurer module is *usually* only useful if the SSF is used together with Cocoon. In this case you always need the SSF-components. Hence it's best to move it to into this module so that Cocoon 2.2 can still be run in the 'classic' mode. Somehow agreed. It looks like nobody is going to use SSF+Blocks infrastructure without Cocoon Core, right? :-) (I can't help myself but somehow the BlockPathPropertyPlaceholderConfigurer seems to be a hack anyway ...) What do you mean by that? What makes it hacky? I'm still not convinced that we should expose block resources directly. But there are use cases for it (http://cocoon.markmail.org/message/vr72n4vr7lfpppfe) and we've already introduced this contract so it probably doesn't make much sense to discuss this again. Ah, thanks to bringing this thread back to my mind! :-) Yes, I agree that in 99% cases one should not expose block's resources but still there might be some egde-cases were it's needed. The real task to be done is to make people more aware of servlet: protocol... -- Grzegorz Kossakowski
[jira] Closed: (COCOON-2236) Servlet Service Framework 1.1.0 is incompatible with Cocoon Core 2.2
[ https://issues.apache.org/jira/browse/COCOON-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski closed COCOON-2236. Resolution: Fixed Fixed in r686261. Servlet Service Framework 1.1.0 is incompatible with Cocoon Core 2.2 Key: COCOON-2236 URL: https://issues.apache.org/jira/browse/COCOON-2236 Project: Cocoon Issue Type: Bug Components: - Servlet service framework Affects Versions: 2.2 Reporter: Grzegorz Kossakowski Assignee: Grzegorz Kossakowski Fix For: 2.2 Servlet Service Framework was refactored because there was hidden dependency on CocoonSourceResolver (in a fact, there was a hidden cyclic dependency) which was of course a bad situation because SSF is meant to be completely independent from Cocoon. However, these refactorings introduced some back-incompatibility (which is just a bug). In order to handle different protocols in context-path property of servlet bean, SSF installs JNet handlers using AOP from Spring. The problematic part is that this interceptor is disabled for init() method of every bean, including servlet beans. SitemapServlet does some serious work in its init() method and requires protocols (like block-context:) to be working properly so JNet handler must be installed. The solution for this problem will be to manually install JNet handler in ServletFactoryBean where init method is called. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r685792 - in /cocoon/trunk/core: cocoon-core/ cocoon-core/src/main/java/org/apache/cocoon/spring/ cocoon-core/src/main/resources/META-INF/cocoon/spring/ cocoon-servlet-service/cocoon-s
Grzegorz Kossakowski wrote:
Reinhard Pötz pisze:
Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
Author: reinhard Date: Thu Aug 14 00:43:31 2008 New Revision: 685792
URL: http://svn.apache.org/viewvc?rev=685792view=rev Log: The
BlockPathPropertyPlaceholderConfigurer module is *usually* only useful
if the SSF is used
together with Cocoon. In this case you always need the SSF-components.
Hence it's best to move it
to into this module so that Cocoon 2.2 can still be run in the
'classic' mode.
Somehow agreed. It looks like nobody is going to use SSF+Blocks
infrastructure without Cocoon Core, right? :-)
(I can't help myself but somehow the
BlockPathPropertyPlaceholderConfigurer seems to be a hack
anyway ...)
What do you mean by that? What makes it hacky?
I'm still not convinced that we should expose block resources directly.
But there are use cases for it
(http://cocoon.markmail.org/message/vr72n4vr7lfpppfe) and we've already
introduced this contract so it probably doesn't make much sense to
discuss this again.
Ah, thanks to bringing this thread back to my mind! :-)
Yes, I agree that in 99% cases one should not expose block's resources
but still there might be some egde-cases were it's needed.
The real task to be done is to make people more aware of servlet:
protocol...
Yep, and thanks to JNet the servlet protocol also works for java.net.URL
objects which wasn't the case when this feature was added.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
Staging releases are gone?
Hi, I just wanted to finish release process of Forms 1.0.0 and Template 1.0.0 and discovered that releases I've prepared and deployed into our staging repository are gone: http://people.apache.org/builds/cocoon/org/apache/cocoon/ Now I can see only Reinhard's releases. This leads me to question: How clean up of this repository is performed? I'll have to recreate my artifacts ( :-( ) but still would like to know how this works. -- Grzegorz Kossakowski
Re: Staging releases are gone?
On Aug 15, 2008, at 12:47 PM, Grzegorz Kossakowski wrote: I just wanted to finish release process of Forms 1.0.0 and Template 1.0.0 and discovered that releases I've prepared and deployed into our staging repository are gone: http://people.apache.org/builds/cocoon/org/apache/cocoon/ Now I can see only Reinhard's releases. This leads me to question: How clean up of this repository is performed? I'll have to recreate my artifacts ( :-( ) but still would like to know how this works. This is the directory for automated test builds (nightly builds, nightlies). As such it should contain only build performed on previous night (or few previous nights). If we were using, say, ant, we could have this builds performed automatically by infrastructure's scripts (no idea about maven). Best place for release candidate builds (files to be voted on) is your private (~yourname) directory. After vote is done, you can clean it up. Vadim
[HEAD-UPS] Welcome Java 1.5 and Maven 2.0.9 in trunk!
Hi, Welcome Java 1.5 and Maven 2.0.9 in trunk, please! :-) I think that I've checked everything when it comes to our infrastructure for compliance with Java 1.5 and Maven 2.0.9. To sum things up: 1. I've switched us to Java 1.5, Maven 2.0.9 profile in Continuum (seems to work correctly) 2. I checked our zone: a) nightly documentation building -- here everything looked fine b) demos start up -- here I had to point demos to Java 1.5 as there were still using 1.4 3. Finally, I've updated our parent pom to reflect result of our vote. I tested if trunk builds on my machine (Java 1.6, openSUSE 11.0) and tried to import projects into Eclipse to see if compiler settings are correct. They are. I hope that I didn't miss anything but if anyone encounters any problem it's the best to report it to this thread. Thanks for patience, we've made it. 8-) -- Best regards, Grzegorz Kossakowski
[jira] Assigned: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grzegorz Kossakowski reassigned COCOON-2216: Assignee: Grzegorz Kossakowski 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.
[jira] Commented: (COCOON-2216) IncludeCacheManager can not perfom parallel includes
[ https://issues.apache.org/jira/browse/COCOON-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12622964#action_12622964 ] Grzegorz Kossakowski commented on COCOON-2216: -- Sorry for big delay but I was busy with other tasks which got a higher priority. Finally I'm finished and I have some free time to spend on this issue which (to be honest) is not the easiest one. Now I'll at least try to reproduce your problem and try to estimate how much of work is needed to fix this in proper way. 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.
