Do you need to use the Servlet Service? I'm not fully up to speed on 2.2 yet
so I imagine you are using this as a datasource and you just want to add an
extra HTTP header. Can you use one of the Proxy generators instead? I have
some code for a SOAP Proxy Transformer or a Simple HTTP Proxy Transformer
that might fit the bill... I know it steps outside of the XML pluggable
ideal but it might be what you need if you could say a little bit more about
WHAT you are trying to achieve rather than just the HOW you are trying to do
it:)

All the George (best),

Warrell

2008/8/20 Heather Rankin <[EMAIL PROTECTED]>

> Thanks Warrell and Luca,
>
> Just for some background, going the xml entity route wasn't my initial
> preference. I've tried multiple approaches including map:mount and
> servlet service - all to no avail.
>
> Map:mount doesn't let me send parameters to the mounted sitemap (aside
> from global ones which aren't an option here) and Servlet Service
> doesn't allow me to carry out Actions for some reason. Servlet Service
> still feels like the most sensible option here but I need the action
> carried out - maybe someone could help with this.
>
> In my block1 sitemap I have this:
>
> <map:generate type="request"/>
> <map:transform type="servletService">
> <map:parameter name="service"
> value="servlet:CentralConfigurationBlock:/method-NA/GET"/>
> </map:transform>
> <map:serialize />
>
> In my CentralConfigurationBlock sitemap I have this:
>
> <map:pipeline>
> <map:match pattern="method-NA/*">
> <map:generate type="file" src="content/methodNotAllowed.xhtml"/>
> <map:transform type="xslt2" src="transforms/addMethods.xsl">
> <map:parameter name="METHODS" value="{1}"/>
> </map:transform>
> <map:act type="addHttpHeader">
> <map:parameter name="Allow" value="{1}"/>
> </map:act>
> <map:serialize type="application/xhtml+xml" status-code="405"
> label="Method Not Allowed"/>
> </map:match>
> </map:pipeline>
>
> Everything works fine except for the addHttpHeader action which is
> defined as:
>
> <map:action name="addHttpHeader"
> src="org.apache.cocoon.acting.HttpHeaderAction"/>
>
> It doesn't do anything. If I call the centralConfigurationBlock pipeline
> directly - ie not through servlet service - the action does what its
> supposed to and sets the Allow header with the appropriate value.
>
> Does anyone have any idea why this wouldn't work with servlet service?
> The xml entity route was just meant to be a temporary workaround - but
> even that's not working so I'd like to go with a more solid approach if
> possible.
>
> Heather
>
>
> ________________________________
>
> From: warrell harries [mailto:[EMAIL PROTECTED]
> Sent: 20 August 2008 14:09
> To: users@cocoon.apache.org; [EMAIL PROTECTED]
> Subject: Re: External Entity in sitemap
>
>
> Hi Heather,
>
> You should certainly follow the tutorial on how to use catalogs to make
> the XML Entity known to Cocoon. This worked for me with some large DTDs
> that I needed to make available to Cocoon 2.1x.
>
> On the related question of how to get an XML fragment into your sitemap
> you could invoke a matcher in another block with cocoon://block/matcher
> but this would need to be used as the src for a generator or as part of
> an aggregation at the generator stage and the matcher would have to
> serialize xml at the end of its pipeline.
>
> Hope this helps,
>
> Warrell
>
>
> 2008/8/20 Luca Morandini <[EMAIL PROTECTED]>
>
>
>        Heather Rankin wrote:
>
>
>
>                I'm using 2.2 and want to include an xml fragment in my
> sitemap using
>                entities. The xml fragment I want to include sits inside
> another block.
>                Can I use something like blockcontext:/ to access it?
>
>
>
>        I would be rather surprised if this was the case.
>        AFAIK, external entities are dealt with by the XML parser
> (Xerces) before the Cocoon sitemap engine kicks in.
>
>        Regards,
>
>        --------------------
>          Luca Morandini
>        www.lucamorandini.it
>        --------------------
>
>
>
>
> ---------------------------------------------------------------------
>        To unsubscribe, e-mail: [EMAIL PROTECTED]
>        For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
>
> http://www.bbc.co.uk/
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in reliance
> on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to