Re: [RT] Resources Accessible Via Subsitemaps To Enable Better Re-Use
Adrien Guillon wrote: What is the official design reason for resources not being accessible by child site maps ? I guess originally this has just been forgotten to be implemented. Any suggestions would be greatly appreciated! With 2.2 we will have a different solution, the virtual sitemap components which can be compared to resources and which are inherited to sub sitemaps. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Resources Accessible Via Subsitemaps To Enable Better Re-Use
Carsten Ziegeler wrote: Adrien Guillon wrote: What is the official design reason for resources not being accessible by child site maps ? I guess originally this has just been forgotten to be implemented. Any suggestions would be greatly appreciated! With 2.2 we will have a different solution, the virtual sitemap components which can be compared to resources and which are inherited to sub sitemaps. Also, bear in mind that if you use the cocoon: protocol, the serialiser will likely be skipped. You could call the sub-pipeline with something that tells it how to use another pipeline as its generator. So there are ways you could achieve what you are after with the current setup. Regards, Upayavira
Cannot compile trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Don't know if others have that too. Cannot compile trunk as the cocoon-forms-impl block seems to miss dependency on different commons jars (jxpath, lang, ...). Anyone else? And I had to locally fix the OSGiSpringECMFactory.java class which seems to miss the containsLocalBean method (is this because Carsten upgraded Spring to 1.2.7?) - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEWcY6LNdJvZjjVZARAgliAJ9OO6S0JfLdz/H7GpItGcp1kAxXTwCg3BFX 3QNOuvTcKDuypJ7HCpS7K6Y= =arNQ -END PGP SIGNATURE-
Re: Cannot compile trunk
Giacomo Pati schrieb: Don't know if others have that too. Cannot compile trunk as the cocoon-forms-impl block seems to miss dependency on different commons jars (jxpath, lang, ...). Anyone else? And I had to locally fix the OSGiSpringECMFactory.java class which seems to miss the containsLocalBean method (is this because Carsten upgraded Spring to 1.2.7?) Yupp, I reverted to 1.2.6 and fixed another problem I introduced yesterday in the scratchpad block. Apart from that, it's working for me - did you try a clean build and removed all org/apache/cocoon artifacts from your local repository. That's the way I usually build Cocoon. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Cannot compile trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 4 May 2006, Carsten Ziegeler wrote: Date: Thu, 04 May 2006 12:19:09 +0200 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Cannot compile trunk Giacomo Pati schrieb: Don't know if others have that too. Cannot compile trunk as the cocoon-forms-impl block seems to miss dependency on different commons jars (jxpath, lang, ...). Anyone else? And I had to locally fix the OSGiSpringECMFactory.java class which seems to miss the containsLocalBean method (is this because Carsten upgraded Spring to 1.2.7?) Yupp, I reverted to 1.2.6 and fixed another problem I introduced yesterday in the scratchpad block. If the fix mentioned above is all we have to do (couldn't get it to compile ATM and thus don't know if that's all) it would be easy to upgrade to 1.2.7. Apart from that, it's working for me - did you try a clean build and removed all org/apache/cocoon artifacts from your local repository. That's the way I usually build Cocoon. Ok, thanks. That's what I'm doing right now. - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEWddMLNdJvZjjVZARAlAZAJ91KO5aGoEBSzyrJV2t0hUv5VvXZACdEnwO Xeah4ObvlUe5ptqyaKuTHTM= =Eg7t -END PGP SIGNATURE-
Re: Cannot compile trunk
Giacomo Pati wrote If the fix mentioned above is all we have to do (couldn't get it to compile ATM and thus don't know if that's all) it would be easy to upgrade to 1.2.7. I guess the mentioned fix should be all and imho it makes sense to upgrade to 1.2.7 if possible (use always the latest and greatest :) ) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Created: (COCOON-1842) LDAPTransformer: ClassCastException with Binary fields
LDAPTransformer: ClassCastException with Binary fields
--
Key: COCOON-1842
URL: http://issues.apache.org/jira/browse/COCOON-1842
Project: Cocoon
Type: Bug
Components: Blocks: Naming
Versions: 2.1.9
Reporter: Nicola Scendoni
Attachments: LDAPTransformer.java.patch
Search operation throws a ClassCastException when ldap results contain binary
values in attributes
For example when the ldap has an entry like:
dn: cn=name,dc=eposse,dc=it
userPassword:: e1NIQX1XNnBoNU1tNVB6OEdnaVVMYlBnekczN21qOWc9
objectClass: top
objectClass: person
sn: surname
cn: name
The search result is the following xml:
!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
LDAPUSER xmlns:ldap=http://apache.org/cocoon/LDAP/1.0;
LDAP xmlns=http://apache.org/cocoon/LDAP/1.0;
LDAPSET
userPassword
ELEMENT[LDAPTransformer] Error in LDAP-Query: java.lang.ClassCastException:
[B/ELEMENT
/LDAPUSER
With my patch the same search has the following form:
!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
LDAPUSER xmlns:ldap=http://apache.org/cocoon/LDAP/1.0;
LDAP xmlns=http://apache.org/cocoon/LDAP/1.0;
LDAPSET
userPassword{Base64}e1NIQX1XNnBoNU1tNVB6OEdnaVVMYlBnekczN21qOWc9
/userPassword
objectClasstop/objectClass
objectClassperson/objectClass
snsurname/sn
cnname/cn
/LDAPSET
/LDAP
/LDAPUSER
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: Cannot compile trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 4 May 2006, Giacomo Pati wrote: Date: Thu, 4 May 2006 12:28:25 +0200 (CEST) From: Giacomo Pati [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Cannot compile trunk --[PinePGP]--[begin]-- On Thu, 4 May 2006, Carsten Ziegeler wrote: Date: Thu, 04 May 2006 12:19:09 +0200 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Cannot compile trunk Giacomo Pati schrieb: Don't know if others have that too. Cannot compile trunk as the cocoon-forms-impl block seems to miss dependency on different commons jars (jxpath, lang, ...). Hmm, I've removed my $HOME/.m2 and rebuild a fresh trunk but still getting lots of compile errors in cocoon-forms-impl regarding missing commons-jxpath, excalibur-xml and others: /home/giacomo/svn/apache/cocoon-2.2/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/Form.java:[31,43] package org.apache.commons.collections.list does not exist /home/giacomo/svn/apache/cocoon-2.2/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/Form.java:[32,31] package org.apache.commons.lang does not exist /home/giacomo/svn/apache/cocoon-2.2/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/Form.java:[33,31] package org.apache.commons.lang does not exist /home/giacomo/svn/apache/cocoon-2.2/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/formmodel/AbstractWidgetDefinition.java:[32,36] package org.apache.excalibur.xml.sax does not exist Anybody any idea? - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEWeOILNdJvZjjVZARAmHyAKDl4B5EC9a7d5FnUAP4wHxOP9rw7QCfTDvL p4GXRXcSUeTuGAXZ7J+VlTg= =7ZTW -END PGP SIGNATURE-
Re: Cannot compile trunk
Giacomo Pati wrote Anybody any idea? Strange! I'm using latest m2 (2.0.4) and I have a mirror setup in my settings.xml: mirror idsunsite.dk/id urlhttp://mirrors.sunsite.dk/maven2/url mirrorOfcentral/mirrorOf /mirror Don't know if that makes a difference. What about others? Are Giacomo and I the only ones trying to build 2.2? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Cannot compile trunk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 4 May 2006, Carsten Ziegeler wrote: Date: Thu, 04 May 2006 15:06:19 +0200 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: Cannot compile trunk Giacomo Pati wrote Anybody any idea? Strange! I'm using latest m2 (2.0.4) and I have a mirror setup in my Ok, switching to 2.0.4 solved my problems (transient deps semmed to be ignored on 2.0.1?) Thanks settings.xml: mirror idsunsite.dk/id urlhttp://mirrors.sunsite.dk/maven2/url mirrorOfcentral/mirrorOf /mirror Don't know if that makes a difference. What about others? Are Giacomo and I the only ones trying to build 2.2? Carsten - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEWf58LNdJvZjjVZARAivPAKDLC4d0vjE3n2R07y2CxU9qDD/0ZwCgqlRH YZt/IPTPAHRBxrdEvjddGCM= =LFzg -END PGP SIGNATURE-
[jira] Created: (COCOON-1843) LDAPTransformer: add-entry tag doesn't work
LDAPTransformer: add-entry tag doesn't work --- Key: COCOON-1843 URL: http://issues.apache.org/jira/browse/COCOON-1843 Project: Cocoon Type: Bug Components: Blocks: Naming Versions: 2.1.9 Reporter: Nicola Scendoni Attachments: LDAPTransformer.java.patch When I try to add an entry, i've got the following xml: ?xml version=1.0 encoding=ISO-8859-1?LDAPUSER xmlns:ldap=http://apache.org/cocoon/LDAP/1.0; exec-element xmlns=http://apache.org/cocoon/LDAP/1.0/ /LDAPUSER And the entry isnt't added to ldap server. I made a patch to solve this problem. I use the filter and the attribute (in the existing dtd) tag to describe the dn and the attributes to be added. The following xml add an entry: LDAPUSER ldap:execute-add ldap:initializercom.sun.jndi.ldap.LdapCtxFactory/ldap:initializer ldap:authenticationsimple/ldap:authentication ldap:version3/ldap:version ldap:serverurlldap://localhost/ldap:serverurl ldap:port389/ldap:port ldap:scopeOBJECTS_SCOPE/ldap:scope ldap:searchbaseo=neworganization,dc=eposse,dc=it/ldap:searchbase ldap:rootdncn=update,dc=eposse,dc=it/ldap:rootdn ldap:passwordsecret/ldap:password ldap:debugTRUE/ldap:debug ldap:deref-linkTRUE/ldap:deref-link ldap:count-limit0/ldap:count-limit ldap:time-limit0/ldap:time-limit ldap:filter cn=Nicola Scendoni,o=neworganization,dc=eposse,dc=it /ldap:filter ldap:doc-elementLDAP/ldap:doc-element ldap:row-elementLDAPSET/ldap:row-element ldap:error-elementERROR/ldap:error-element ldap:attribute name=snScendoni/ldap:attribute ldap:attribute name=cnNicola Scendoni/ldap:attribute ldap:attribute name=objectclasstop/ldap:attribute ldap:attribute name=objectclassperson/ldap:attribute /ldap:execute-add /LDAPUSER and return the folloring xml: LDAPUSER add_element dn cn=nicola Scendoni,o=neworganization,dc=eposse,dc=it /dn snScendoni/sn cnnicola Scendoni/cn objectclasstop/objectclass objectclassperson/objectclass /add_element /LDAPUSER -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RT] Resources Accessible Via Subsitemaps To Enable Better Re-Use
I will investigate the virtual sitemap components, and see what I can see... thanks for the pointers. Cocoon is pretty crazy... how does one normally find out about all these nifty features? AJ On 4 May 2006 4:12 am, Upayavira wrote: Carsten Ziegeler wrote: Adrien Guillon wrote: What is the official design reason for resources not being accessible by child site maps ? I guess originally this has just been forgotten to be implemented. Any suggestions would be greatly appreciated! With 2.2 we will have a different solution, the virtual sitemap components which can be compared to resources and which are inherited to sub sitemaps. Also, bear in mind that if you use the cocoon: protocol, the serialiser will likely be skipped. You could call the sub-pipeline with something that tells it how to use another pipeline as its generator. So there are ways you could achieve what you are after with the current setup. Regards, Upayavira
Re: [RT] Resources Accessible Via Subsitemaps To Enable Better Re-Use
Another problem... you mentioned this is in 2.2... I'm still on 2.1.9. Is there a method by which I could take the Virtual Sitemap Components and put that functionality into 2.1.9? As in, is it just a plain old transformer that I can take, or would this be too difficult a thing to do ? Thanks, AJ On 4 May 2006 9:38 am, Adrien Guillon wrote: I will investigate the virtual sitemap components, and see what I can see... thanks for the pointers. Cocoon is pretty crazy... how does one normally find out about all these nifty features? AJ
Re: [RT] Resources Accessible Via Subsitemaps To Enable Better Re-Use
Adrien Guillon wrote: Another problem... you mentioned this is in 2.2... I'm still on 2.1.9. Is there a method by which I could take the Virtual Sitemap Components and put that functionality into 2.1.9? As in, is it just a plain old transformer that I can take, or would this be too difficult a thing to do ? I think it's too difficult - it affects some parts in the core of Cocoon which have changed between 2.1.x and 2.2 - so unless you want to port the whole core from 2.2 to 2.1.9 :), I think it's too much work :( Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [jira] Commented: (COCOON-1685) Additional ProcessingPhase.READ_FROM_REQUEST_VALUE event sent
Thanks David. Best Regards, Antonio Gallardo. David Crossley escribió: Antonio Gallardo wrote: Pier ping! :-) There are other people here who can do that. Simone, i found that you have two Jira usernames s.gianni and [EMAIL PROTECTED] The latter only had one issue, so i moved it to the other user. However, i could not delete the [EMAIL PROTECTED] user because it has a stack of filters. Anyway, i added them both to the cocoon-developers group. -David
Re: [RT] Simplifying setup
Daniel Fagerstrom wrote: What I mean is that the tree processor currently get the path to the sitemap.xmap from the configuration file. If the tree processor stop being a managed component and just is setup in the SitemapServlet, it will still need to get the sitemap path from somewhere. IMO a servlet config init parameter would be a reasonable place to set the sitemap path. Ah, ok. Now, since this is about simplifying setup: is it even useful to have a configurable sitemap path? Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [RT] Simplifying setup
Sylvain Wallez skrev: Daniel Fagerstrom wrote: What I mean is that the tree processor currently get the path to the sitemap.xmap from the configuration file. If the tree processor stop being a managed component and just is setup in the SitemapServlet, it will still need to get the sitemap path from somewhere. IMO a servlet config init parameter would be a reasonable place to set the sitemap path. Ah, ok. Now, since this is about simplifying setup: is it even useful to have a configurable sitemap path? Don't know if it is useful, a default value should be enough in the vast majority of use cases. /Daniel
Re: Cannot compile trunk
Carsten Ziegeler wrote: What about others? Are Giacomo and I the only ones trying to build 2.2? nope :) I had actually spotted the spring compilation the day after you committed it and was wondering why continuum hadn't notified us of this. It turns out that CI uses incremental compilation in order to speed up the builds. Additionnaly it also doesn't force a complete compile when the pom dependencies have changed, which IMO it should. Anyway, I'll commit some pom changes over the weekend to change the default build target from install to clean install when run in a continuum environment, that should at least give us a better build quality. Regards Jorg
Re: [RT] Resources Accessible Via Subsitemaps To Enable Better Re-Use
How difficult would it be to alter 2.1.9 instead, to allow access to resources defined in parent sitemaps from children sitemaps? If I can do that, I can easily change the resource access methods to the virtual sitemap components when 2.2 rolls out... AJ On 4 May 2006 10:03 am, Carsten Ziegeler wrote: Adrien Guillon wrote: Another problem... you mentioned this is in 2.2... I'm still on 2.1.9. Is there a method by which I could take the Virtual Sitemap Components and put that functionality into 2.1.9? As in, is it just a plain old transformer that I can take, or would this be too difficult a thing to do ? I think it's too difficult - it affects some parts in the core of Cocoon which have changed between 2.1.x and 2.2 - so unless you want to port the whole core from 2.2 to 2.1.9 :), I think it's too much work :( Carsten
Re: [RT] Resources Accessible Via Subsitemaps To Enable Better Re-Use
Adrien Guillon schrieb: How difficult would it be to alter 2.1.9 instead, to allow access to resources defined in parent sitemaps from children sitemaps? If I can do that, I can easily change the resource access methods to the virtual sitemap components when 2.2 rolls out... That shouldn't be too hard I think. You have to dig into the tree processor code and find out how it works. At least it should be much easier to do that than to implement the virtual sitemap components in 2.1.9 :) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Resources Accessible Via Subsitemaps To Enable Better Re-Use
Okay, I really prefer this solution... porting my code from resources to virtual sitemap components in the future will be very easy from what I have seen. Could you please direct me to a few classes to look at and documentation? Maybe any pointers you could give for how to proceed? This is my first dive into the guts of Cocoon :-) I really do not want to sacrifice a good design because I'm missing components. Also, I would be very interested in taking a better look at the new way that 2.2 does things, perhaps I will have some relevant input as I look at this rather complex project I am working on. Thanks for the help! AJ On 4 May 2006 2:34 pm, Carsten Ziegeler wrote: Adrien Guillon schrieb: How difficult would it be to alter 2.1.9 instead, to allow access to resources defined in parent sitemaps from children sitemaps? If I can do that, I can easily change the resource access methods to the virtual sitemap components when 2.2 rolls out... That shouldn't be too hard I think. You have to dig into the tree processor code and find out how it works. At least it should be much easier to do that than to implement the virtual sitemap components in 2.1.9 :) Carsten
Re: [RT] Resources Accessible Via Subsitemaps To Enable Better Re-Use
Take a look at http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106649931022515w=2 for a description on how the treeprocessor works. The function of the virtual sitemap components is described here http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111316710610638w=2. I don't know if the VPCs work anymore, haven't tested them for quite a while. For the understanding the resource handling (or other parts of the treeprocessor), it is a good idea to start looking at http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/treeprocessor/treeprocessor-builtins.xml, which configure all the execution element of the sitemap. Where you can see that a resource definition is handled by a NamedContainerNodeBuilder, and that calling a resource is handled by a CallNodeBuilder. IIRC, there are a few subtle things involved in the resource handling code, so be prepared to that you might need to spend some time learning how it works ;) /Daniel Adrien Guillon skrev: Okay, I really prefer this solution... porting my code from resources to virtual sitemap components in the future will be very easy from what I have seen. Could you please direct me to a few classes to look at and documentation? Maybe any pointers you could give for how to proceed? This is my first dive into the guts of Cocoon :-) I really do not want to sacrifice a good design because I'm missing components. Also, I would be very interested in taking a better look at the new way that 2.2 does things, perhaps I will have some relevant input as I look at this rather complex project I am working on. Thanks for the help! AJ On 4 May 2006 2:34 pm, Carsten Ziegeler wrote: Adrien Guillon schrieb: How difficult would it be to alter 2.1.9 instead, to allow access to resources defined in parent sitemaps from children sitemaps? If I can do that, I can easily change the resource access methods to the virtual sitemap components when 2.2 rolls out... That shouldn't be too hard I think. You have to dig into the tree processor code and find out how it works. At least it should be much easier to do that than to implement the virtual sitemap components in 2.1.9 :) Carsten
Re: [RT] Resources Accessible Via Subsitemaps To Enable Better Re-Use
Daniel Fagerstrom wrote: Take a look at http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106649931022515w=2 for a description on how the treeprocessor works. The function of the virtual sitemap components is described here http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111316710610638w=2. I don't know if the VPCs work anymore, haven't tested them for quite a while. For the understanding the resource handling (or other parts of the treeprocessor), it is a good idea to start looking at http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/components/treeprocessor/treeprocessor-builtins.xml, which configure all the execution element of the sitemap. Where you can see that a resource definition is handled by a NamedContainerNodeBuilder, and that calling a resource is handled by a CallNodeBuilder. IIRC, there are a few subtle things involved in the resource handling code, so be prepared to that you might need to spend some time learning how it works ;) Views and resources are handled similarily as things that are purely internal to a sitemap. They are therefore looked up and hard-linked as part of the processing node tree building phase. Having inheritable resources means: 1 - they should be stored into a location that's visible from child sitemaps. Either the sitemap-specific service manager or Avalon context object should fine (I prefer the latter). 2 - they should not be looked up at build time but at execution time. However, that's probably not enough, as the URL resolution in inherited resources will be relative to the context of the sitemap that called the resource. Solving this, well, is very close to virtual sitemap components and is not trivial. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [RT] Resources Accessible Via Subsitemaps To Enable Better Re-Use
Sylvain Wallez skrev: Daniel Fagerstrom wrote: ... IIRC, there are a few subtle things involved in the resource handling code, so be prepared to that you might need to spend some time learning how it works ;) Views and resources are handled similarily as things that are purely internal to a sitemap. They are therefore looked up and hard-linked as part of the processing node tree building phase. Having inheritable resources means: 1 - they should be stored into a location that's visible from child sitemaps. Either the sitemap-specific service manager or Avalon context object should fine (I prefer the latter). 2 - they should not be looked up at build time but at execution time. However, that's probably not enough, as the URL resolution in inherited resources will be relative to the context of the sitemap that called the resource. Solving this, well, is very close to virtual sitemap components and is not trivial. Yes, thinking more about it, it will be much easier to back port the VPCs than make resources callable from subsitemaps. I'm not saying that it will be simple to backport the VPCs though ;) Besides the problems that Sylvain describe you also have the problem that if you want to use the resource as a VPC transformer (I got that impression from your original post), you also need a mechanism that switch between the different contexts that the transformer and the sitemap components before and after are supposed to be executed in, and this need to be done for every SAX event. --- o0o --- Before you jump in into all this work, I would suggest that you seriously consider choosing another design. I did lots of complicated stuff in the sitemap before, but my experience is that it doesn't scale that well and is rather hard to support and understand. Today I much prefer doing the complicated stuff in Java and just use the sitemap for the presentation layer. My impression is that most Cocoon developers consider complicated sitemaps an anti-pattern. /Daniel
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 05 May 12:24 AM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2006-05-05 12:02:11 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: fetch-plugins-descriptors: [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] . [get] last modified = Fri Feb 24 09:07:16 GMT+00:00 2006 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] . [get] last modified = Thu Apr 06 07:54:56 GMT+00:00 2006 [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] -- Installing plugin: org.apache.forrest.plugin.output.pdf -- check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir. Trying to update it... init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: [echo] Trying to find the description of org.apache.forrest.plugin.output.pdf in the different descriptor files [echo] Using the descriptor file /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml... [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-local-unversioned-plugin: get-local: [echo] Trying to locally get org.apache.forrest.plugin.output.pdf [echo] Looking in local /export/opt/forrest-trunk/plugins [echo] Found ! init-build-compiler: echo-init: init: compile: jar: local-deploy: [echo] Locally deploying org.apache.forrest.plugin.output.pdf build: [echo] Plugin org.apache.forrest.plugin.output.pdf deployed ! Ready to configure fetch-remote-unversioned-plugin-version-forrest: fetch-remote-unversioned-plugin-unversion-forrest: has-been-downloaded: downloaded-message: uptodate-message: not-found-message: [echo] Fetch-plugin Ok, installing ! unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 files to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] -- Installing plugin: org.apache.forrest.plugin.input.projectInfo -- check-plugin: [echo] org.apache.forrest.plugin.input.projectInfo is not available in the build dir. Trying to fetch it... init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin:
