You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2016/08/21 16:38:26 UTC
Re: Handling errors retrieving a for
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Javier
On 6/1/16 3:19 PM, Javier Puerto wrote:
> Hi Christopher,
>
> I more used to version 2.2 but it should be the same. By you
> description I think about creating a new pipeline with a matcher to
> handle the external request with a specific error handler[1] that
> contains a reader with an empty file.
>
> It should be something like:
>
> <map:pipeline type="caching">
>
> <map:match pattern="remote-handler/**"> <map:reader
> src="http://remote-server/{1}"/> </map:match>
>
> <map:handle-errors> <map:reader src="empty.xml"/>
> </map:handle-errors>
>
> </map:pipeline>
>
> Then you could substitute all your calls to external resources
> that needs to produce an empty XML in case of error to call to the
> new matcher. This way you can tune up the external pipeline for
> caching if it's needed.
I tried:
<map:pipeline>
<map:match pattern="/foo">
<map:aggregate element="aggregated-stuff">
<map:part src="available-resource" />
<map:part src="unavailable-resource" /><!-- No route to host -->
</map:aggregate>
<map:transform /><!-- ... -->
<map:serialize /><!-- ... -->
</map:match>
<map:handle-errors>
<map:generate src="/dev/null" />
</map:handle-errors>
</map:pipeline>
When I get a "no route to host" error from the unavailable-resource, I
get the standard Cocoon error page with a stack trace. I would have
expected the <map:part> from the unavailable resource to simply
provide no content to aggregate with the other sources.
Do I need a more complicated handle-errors section? All of the
examples in the docs have a <map:select> in them to check the
exception type.
Thanks,
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJXudkCAAoJEBzwKT+lPKRY5NIP/2j5npsvm4VZEXDkCPYDrZCv
Zk8mfShffDkf0Xh1lOUnbXiwezv3YkQIq7gRa1rhWnR69lriAJQku1vsSsnagADH
Re4BzJXxWhJ8a+x7Hv8Ibhvjzl53qxxVl9U/cop8R4u9tQAH4aVWPaLUrkxtnFGh
0G+MEnOr8x62NG1RHSVuhNfXgFTxVaXDkxcS3w47Vq/Ts+ulU7Hm0XXfPUJB5XG/
/sREax46fY0/9Qweb82QbG5CHaI22Uv/xnxq4t+HHA1I3DJtZDpiHHcueF02Hn5R
LtRq4gDvYqAriGSy31W+roNCT+ItT2yThQ9EdcRg4Dc2meN/0s7jTdbIhF1YU2ut
GjfW1504z5GoPYO1kaS5pSFH5zIaOaKUp3SYCHrkCAhEY5u5u10NIqleHUnj8g6z
latO8gp26UgdlBMZwaVXc2TOIX3BbKhZTveEjwc9wCd1EyrrryoLr6xT5hKUctaf
u1oGOaQcgHVNAskztwDNAYzyeep+lRAIPPGQ1irhXrPA66nOuyHW6+I4EBiboQ8J
RUi0djAUZg/srOxpWvC5ww+FyGleH+a0bJe3qz6BhSPVqy+VddjUl4SnqeT+1m6t
yU/K+q8i3TPGHGDJwDQeGqkesB5e3okT9UJuj2SqOMOQ7yHe0aR0JOepP4Y9oNuI
sTgQuM/AzAsTpO60ML1v
=ewdz
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Handling errors retrieving a for
Posted by Javier Puerto <jp...@gmail.com>.
2016-08-21 18:38 GMT+02:00 Christopher Schultz <chris@christopherschultz.net
>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Javier
>
> On 6/1/16 3:19 PM, Javier Puerto wrote:
> > Hi Christopher,
> >
> > I more used to version 2.2 but it should be the same. By you
> > description I think about creating a new pipeline with a matcher to
> > handle the external request with a specific error handler[1] that
> > contains a reader with an empty file.
> >
> > It should be something like:
> >
> > <map:pipeline type="caching">
> >
> > <map:match pattern="remote-handler/**"> <map:reader
> > src="http://remote-server/{1}"/> </map:match>
> >
> > <map:handle-errors> <map:reader src="empty.xml"/>
> > </map:handle-errors>
> >
> > </map:pipeline>
> >
> > Then you could substitute all your calls to external resources
> > that needs to produce an empty XML in case of error to call to the
> > new matcher. This way you can tune up the external pipeline for
> > caching if it's needed.
>
> I tried:
>
> <map:pipeline>
> <map:match pattern="/foo">
> <map:aggregate element="aggregated-stuff">
> <map:part src="available-resource" />
> <map:part src="unavailable-resource" /><!-- No route to host -->
> </map:aggregate>
> <map:transform /><!-- ... -->
> <map:serialize /><!-- ... -->
> </map:match>
> <map:handle-errors>
> <map:generate src="/dev/null" />
> </map:handle-errors>
> </map:pipeline>
>
> When I get a "no route to host" error from the unavailable-resource, I
> get the standard Cocoon error page with a stack trace. I would have
> expected the <map:part> from the unavailable resource to simply
> provide no content to aggregate with the other sources.
>
The exception will be handled at pipeline level so if the source fails, the
handle-errors that you defined will be triggered.
>
> Do I need a more complicated handle-errors section? All of the
> examples in the docs have a <map:select> in them to check the
> exception type.
>
The problem is that you want that your resources return an empty content in
case that the application can not get the data in the middle of the
process. So you need to declare another pipeline with a matcher that will
accept any URL and retrieves it for you, this matcher will have the
"handle-errors" tag that will read an empty XML file.
Create a new pipeline like I send previously and just call the resources in
the aggregator to resolve the internal pipeline.
<map:aggregate element="aggregated-stuff">
<map:part src="cocoon:/remote-handler/available-resource" />
<map:part src="cocoon:/remote-handler/unavailable-resource" /><!-- No
route to host -->
</map:aggregate>
Notice the protocol and the internal pipeline matcher path preffix. You
should get what you expect with this change.
> Thanks,
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJXudkCAAoJEBzwKT+lPKRY5NIP/2j5npsvm4VZEXDkCPYDrZCv
> Zk8mfShffDkf0Xh1lOUnbXiwezv3YkQIq7gRa1rhWnR69lriAJQku1vsSsnagADH
> Re4BzJXxWhJ8a+x7Hv8Ibhvjzl53qxxVl9U/cop8R4u9tQAH4aVWPaLUrkxtnFGh
> 0G+MEnOr8x62NG1RHSVuhNfXgFTxVaXDkxcS3w47Vq/Ts+ulU7Hm0XXfPUJB5XG/
> /sREax46fY0/9Qweb82QbG5CHaI22Uv/xnxq4t+HHA1I3DJtZDpiHHcueF02Hn5R
> LtRq4gDvYqAriGSy31W+roNCT+ItT2yThQ9EdcRg4Dc2meN/0s7jTdbIhF1YU2ut
> GjfW1504z5GoPYO1kaS5pSFH5zIaOaKUp3SYCHrkCAhEY5u5u10NIqleHUnj8g6z
> latO8gp26UgdlBMZwaVXc2TOIX3BbKhZTveEjwc9wCd1EyrrryoLr6xT5hKUctaf
> u1oGOaQcgHVNAskztwDNAYzyeep+lRAIPPGQ1irhXrPA66nOuyHW6+I4EBiboQ8J
> RUi0djAUZg/srOxpWvC5ww+FyGleH+a0bJe3qz6BhSPVqy+VddjUl4SnqeT+1m6t
> yU/K+q8i3TPGHGDJwDQeGqkesB5e3okT9UJuj2SqOMOQ7yHe0aR0JOepP4Y9oNuI
> sTgQuM/AzAsTpO60ML1v
> =ewdz
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>