[
https://issues.apache.org/jira/browse/FOR-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Crossley updated FOR-770:
-------------------------------
Description:
With the introduction of the locationmap it can be unclear which sitemap
pipeline is handling a request. Prior to the locationmap, exceptions would tell
us where in the sitemap we were working. However, this can sometimes get lost
in the interaction with the locationmap.
This makes it very difficult to debug some locationmap problems. For example, I
recently had a situation in which the locationmap was being queried for
"project.foo". In this hint the "project." part was being added by the
sitemaps, but the error reported was not showing where. I knew this meant some
match was intercepting the request before my plugin sitemap got hold of it, but
the error messages would not tell me which. I had to trace the process
manually, which took an age. In the end it was a catchall match in the raw.xmap
If the LM logs could report where the request is coming from, I would have
known in seconds what the problem was, rather than hours. We need a log entry
something like:
"Examining Locationmap for "project.foo" on behald of /raw.xmap (line XYZ)"
was:
With the introduction of the locationmap it can be unclear which sitemap
pipeline is handling a request. Prior to the locationmap exceptions would tell
us where in the sitemap we were working. However, this can sometimes get lost
in the interaction with the locationmap.
This makes it very difficult to debug some locationmap problems. For example, I
recently had a situation in which the locationmap was being queried for
"proect.foo". In this hint the "project." part was being added by the sitemaps,
but the error reported was not showing where. I knew this meant some match was
intercepting the request before my plugin sitemap got hold of it, but the error
messages would not tell me which. I had to trace the process manually, which
took an age. In the end it was a catchall match in the raw.xmap
If the LM logs could report where the request is coming from, I would have
known in seconds what the problem was, rather than hours. We need a log entry
something like:
"Examining Locationmap for "project.foo" on behald of /raw.xmap (line XYZ)"
Affects Version/s: 0.9-dev
Summary: Locationmap logs should show which sitemap the request
is coming from (was: Locationmaplogs should show which sitemap the request is
coming from)
Edited description which had a confusing typo. Set Fix-version to 0.9-dev
> Locationmap logs should show which sitemap the request is coming from
> ---------------------------------------------------------------------
>
> Key: FOR-770
> URL: https://issues.apache.org/jira/browse/FOR-770
> Project: Forrest
> Issue Type: Improvement
> Components: Locationmap
> Affects Versions: 0.8, 0.9-dev
> Reporter: Ross Gardler
> Fix For: 0.9-dev
>
>
> With the introduction of the locationmap it can be unclear which sitemap
> pipeline is handling a request. Prior to the locationmap, exceptions would
> tell us where in the sitemap we were working. However, this can sometimes get
> lost in the interaction with the locationmap.
> This makes it very difficult to debug some locationmap problems. For example,
> I recently had a situation in which the locationmap was being queried for
> "project.foo". In this hint the "project." part was being added by the
> sitemaps, but the error reported was not showing where. I knew this meant
> some match was intercepting the request before my plugin sitemap got hold of
> it, but the error messages would not tell me which. I had to trace the
> process manually, which took an age. In the end it was a catchall match in
> the raw.xmap
> If the LM logs could report where the request is coming from, I would have
> known in seconds what the problem was, rather than hours. We need a log entry
> something like:
> "Examining Locationmap for "project.foo" on behald of /raw.xmap (line XYZ)"
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
