You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by ed_ruder <er...@hi5.com> on 2008/06/19 00:35:16 UTC
Re: Route matching too liberal?
James,
I'm not very familiar with Abdera, but I have browsed the source a bit after
hitting the same limitation that Jim reported, while working on Shindig. I
*think* that a simple change in RouteManager could alleviate some (and for
me, I think, all) of the limitation.
When resolving a route, Rails walks through its routes in the order that
they are defined. RouteManager walks through the targets.entrySet, which is
unordered. If RouteManager kept a targets List<> instead of a targets Map<>,
it could walk through the routes in order. (There would need to be a new
class defined, to hold both the Route and TargetType, but it would be very
simple.)
To work around the limitation Jim describes, a client would define a
/base/:collection/:entry route before the /base/:collection route.
WDYT?
Ed
James M Snell wrote:
>
> Ruby matching can span segments if a default value for the missing
> variables is provided. We, however, don't have default values for our
> variables. It would make sense for us to tighten up the matching rules.
>
> - James
>
> Jim Ancona wrote:
>> I have run into some problems with my Routes matching unexpectedly.
>> Before filing a bug, I thought I'd ask for feedback on whether the
>> current behavior is correct.
>>
>> The current algorithm attempts to match the non-variable parts of the
>> pattern, setting the variable to whatever is in between.
>>
>> So the pattern "/base/:collection/" matches both "/base/test/" and
>> "/base/test/123/". In the second case, the value of the collection
>> variable is "test/123". In my opinion, not allowing matches to span URI
>> segments would be less prone to unintuitive results.
>>
>> FWIW, a quick glance at some docs on Ruby Routes seems to indicate that
>> they do not span URI path segments.
>>
>> Thoughts?
>>
>> Jim
>>
>
>
--
View this message in context: http://www.nabble.com/Route-matching-too-liberal--tp15348853p17993519.html
Sent from the abdera-dev mailing list archive at Nabble.com.
Re: Route matching too liberal?
Posted by David Calavera <da...@gmail.com>.
Ohh sure, I don't know what I was thinking on. I have to see if we'll lose
other capabilities with the change becouse currently I'm not sure.
On Thu, Jun 19, 2008 at 1:15 AM, ed_ruder <er...@hi5.com> wrote:
>
> David,
>
> I don't think that's right.
>
> sortedMap keeps the map ordered by the natural ordering of its keys. The
> key
> of the targets map is a Route--I don't think this enhancement/change should
> affect the nature of the Route class, do you?
>
> Ed
>
>
> David Calavera wrote:
> >
> > I think it makes more sense that the Map was a sortedMap, thus the
> > entrySet
> > will be a sortedSet and I suppose your problem will be solved.
> >
> > If you are agree I can change it.
> >
> > On Thu, Jun 19, 2008 at 12:35 AM, ed_ruder <er...@hi5.com> wrote:
> >
> >>
> >> James,
> >>
> >> I'm not very familiar with Abdera, but I have browsed the source a bit
> >> after
> >> hitting the same limitation that Jim reported, while working on Shindig.
> >> I
> >> *think* that a simple change in RouteManager could alleviate some (and
> >> for
> >> me, I think, all) of the limitation.
> >>
> >> When resolving a route, Rails walks through its routes in the order that
> >> they are defined. RouteManager walks through the targets.entrySet, which
> >> is
> >> unordered. If RouteManager kept a targets List<> instead of a targets
> >> Map<>,
> >> it could walk through the routes in order. (There would need to be a new
> >> class defined, to hold both the Route and TargetType, but it would be
> >> very
> >> simple.)
> >>
> >> To work around the limitation Jim describes, a client would define a
> >> /base/:collection/:entry route before the /base/:collection route.
> >>
> >> WDYT?
> >>
> >> Ed
> >>
> >>
> >> James M Snell wrote:
> >> >
> >> > Ruby matching can span segments if a default value for the missing
> >> > variables is provided. We, however, don't have default values for our
> >> > variables. It would make sense for us to tighten up the matching
> >> rules.
> >> >
> >> > - James
> >> >
> >> > Jim Ancona wrote:
> >> >> I have run into some problems with my Routes matching unexpectedly.
> >> >> Before filing a bug, I thought I'd ask for feedback on whether the
> >> >> current behavior is correct.
> >> >>
> >> >> The current algorithm attempts to match the non-variable parts of the
> >> >> pattern, setting the variable to whatever is in between.
> >> >>
> >> >> So the pattern "/base/:collection/" matches both "/base/test/" and
> >> >> "/base/test/123/". In the second case, the value of the collection
> >> >> variable is "test/123". In my opinion, not allowing matches to span
> >> URI
> >> >> segments would be less prone to unintuitive results.
> >> >>
> >> >> FWIW, a quick glance at some docs on Ruby Routes seems to indicate
> >> that
> >> >> they do not span URI path segments.
> >> >>
> >> >> Thoughts?
> >> >>
> >> >> Jim
> >> >>
> >> >
> >> >
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Route-matching-too-liberal--tp15348853p17993519.html
> >> Sent from the abdera-dev mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > --
> > David Calavera
> > http://www.thinkincode.net
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Route-matching-too-liberal--tp15348853p17994070.html
> Sent from the abdera-dev mailing list archive at Nabble.com.
>
>
--
David Calavera
http://www.thinkincode.net
Re: Route matching too liberal?
Posted by ed_ruder <er...@hi5.com>.
David,
I don't think that's right.
sortedMap keeps the map ordered by the natural ordering of its keys. The key
of the targets map is a Route--I don't think this enhancement/change should
affect the nature of the Route class, do you?
Ed
David Calavera wrote:
>
> I think it makes more sense that the Map was a sortedMap, thus the
> entrySet
> will be a sortedSet and I suppose your problem will be solved.
>
> If you are agree I can change it.
>
> On Thu, Jun 19, 2008 at 12:35 AM, ed_ruder <er...@hi5.com> wrote:
>
>>
>> James,
>>
>> I'm not very familiar with Abdera, but I have browsed the source a bit
>> after
>> hitting the same limitation that Jim reported, while working on Shindig.
>> I
>> *think* that a simple change in RouteManager could alleviate some (and
>> for
>> me, I think, all) of the limitation.
>>
>> When resolving a route, Rails walks through its routes in the order that
>> they are defined. RouteManager walks through the targets.entrySet, which
>> is
>> unordered. If RouteManager kept a targets List<> instead of a targets
>> Map<>,
>> it could walk through the routes in order. (There would need to be a new
>> class defined, to hold both the Route and TargetType, but it would be
>> very
>> simple.)
>>
>> To work around the limitation Jim describes, a client would define a
>> /base/:collection/:entry route before the /base/:collection route.
>>
>> WDYT?
>>
>> Ed
>>
>>
>> James M Snell wrote:
>> >
>> > Ruby matching can span segments if a default value for the missing
>> > variables is provided. We, however, don't have default values for our
>> > variables. It would make sense for us to tighten up the matching
>> rules.
>> >
>> > - James
>> >
>> > Jim Ancona wrote:
>> >> I have run into some problems with my Routes matching unexpectedly.
>> >> Before filing a bug, I thought I'd ask for feedback on whether the
>> >> current behavior is correct.
>> >>
>> >> The current algorithm attempts to match the non-variable parts of the
>> >> pattern, setting the variable to whatever is in between.
>> >>
>> >> So the pattern "/base/:collection/" matches both "/base/test/" and
>> >> "/base/test/123/". In the second case, the value of the collection
>> >> variable is "test/123". In my opinion, not allowing matches to span
>> URI
>> >> segments would be less prone to unintuitive results.
>> >>
>> >> FWIW, a quick glance at some docs on Ruby Routes seems to indicate
>> that
>> >> they do not span URI path segments.
>> >>
>> >> Thoughts?
>> >>
>> >> Jim
>> >>
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Route-matching-too-liberal--tp15348853p17993519.html
>> Sent from the abdera-dev mailing list archive at Nabble.com.
>>
>>
>
>
> --
> David Calavera
> http://www.thinkincode.net
>
>
--
View this message in context: http://www.nabble.com/Route-matching-too-liberal--tp15348853p17994070.html
Sent from the abdera-dev mailing list archive at Nabble.com.
Re: Route matching too liberal?
Posted by David Calavera <da...@gmail.com>.
I think it makes more sense that the Map was a sortedMap, thus the entrySet
will be a sortedSet and I suppose your problem will be solved.
If you are agree I can change it.
On Thu, Jun 19, 2008 at 12:35 AM, ed_ruder <er...@hi5.com> wrote:
>
> James,
>
> I'm not very familiar with Abdera, but I have browsed the source a bit
> after
> hitting the same limitation that Jim reported, while working on Shindig. I
> *think* that a simple change in RouteManager could alleviate some (and for
> me, I think, all) of the limitation.
>
> When resolving a route, Rails walks through its routes in the order that
> they are defined. RouteManager walks through the targets.entrySet, which is
> unordered. If RouteManager kept a targets List<> instead of a targets
> Map<>,
> it could walk through the routes in order. (There would need to be a new
> class defined, to hold both the Route and TargetType, but it would be very
> simple.)
>
> To work around the limitation Jim describes, a client would define a
> /base/:collection/:entry route before the /base/:collection route.
>
> WDYT?
>
> Ed
>
>
> James M Snell wrote:
> >
> > Ruby matching can span segments if a default value for the missing
> > variables is provided. We, however, don't have default values for our
> > variables. It would make sense for us to tighten up the matching rules.
> >
> > - James
> >
> > Jim Ancona wrote:
> >> I have run into some problems with my Routes matching unexpectedly.
> >> Before filing a bug, I thought I'd ask for feedback on whether the
> >> current behavior is correct.
> >>
> >> The current algorithm attempts to match the non-variable parts of the
> >> pattern, setting the variable to whatever is in between.
> >>
> >> So the pattern "/base/:collection/" matches both "/base/test/" and
> >> "/base/test/123/". In the second case, the value of the collection
> >> variable is "test/123". In my opinion, not allowing matches to span URI
> >> segments would be less prone to unintuitive results.
> >>
> >> FWIW, a quick glance at some docs on Ruby Routes seems to indicate that
> >> they do not span URI path segments.
> >>
> >> Thoughts?
> >>
> >> Jim
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Route-matching-too-liberal--tp15348853p17993519.html
> Sent from the abdera-dev mailing list archive at Nabble.com.
>
>
--
David Calavera
http://www.thinkincode.net
Re: Route matching too liberal?
Posted by David Primmer <da...@gmail.com>.
This 'route stacking' approach is used in python Routes.
http://routes.groovie.org/manual.html#search-order
What we're experiencing is called "minimization" of routes and happens
when you have ordered routes and the longest ones that you want are
not 'first'. Apparently some devs overlooked the possibility when
stacking their routes.
http://routes.groovie.org/manual.html#minimum-urls
One of the goals of the Routes rewrite in python is to :
Eliminate "minimization gotcha" where an earlier route unexpectedly
matches a URL due to minimization.
http://www.groovie.org/2007/08/29/routes-planning-and-the-road-to-routes-2-0
Here's some rules from the new routes 2 spec:
http://wiki.pylonshq.com/display/routes/Routes+2+Spec
# The path may include variable placeholders like this: "{year}".
These will be returned in the match dict. The value may not contain a
slash. Matching is greedy.
# The path may include wildcard placeholders like this: "{*url}".
These work like variable placeholders except the value may contain
slashes. Matching is greedy. (Or should it be non-greedy?)
Some interesting things they're doing: changing syntax away from the
:varname to {varname} and adding the ability for the route to be used
only for URL generation.
Just some background from a group that is working through these issues
with a larger user base than ours.
davep
On Wed, Jun 18, 2008 at 3:35 PM, ed_ruder <er...@hi5.com> wrote:
>
> James,
>
> I'm not very familiar with Abdera, but I have browsed the source a bit after
> hitting the same limitation that Jim reported, while working on Shindig. I
> *think* that a simple change in RouteManager could alleviate some (and for
> me, I think, all) of the limitation.
>
> When resolving a route, Rails walks through its routes in the order that
> they are defined. RouteManager walks through the targets.entrySet, which is
> unordered. If RouteManager kept a targets List<> instead of a targets Map<>,
> it could walk through the routes in order. (There would need to be a new
> class defined, to hold both the Route and TargetType, but it would be very
> simple.)
>
> To work around the limitation Jim describes, a client would define a
> /base/:collection/:entry route before the /base/:collection route.
>
> WDYT?
>
> Ed
>
>
> James M Snell wrote:
>>
>> Ruby matching can span segments if a default value for the missing
>> variables is provided. We, however, don't have default values for our
>> variables. It would make sense for us to tighten up the matching rules.
>>
>> - James
>>
>> Jim Ancona wrote:
>>> I have run into some problems with my Routes matching unexpectedly.
>>> Before filing a bug, I thought I'd ask for feedback on whether the
>>> current behavior is correct.
>>>
>>> The current algorithm attempts to match the non-variable parts of the
>>> pattern, setting the variable to whatever is in between.
>>>
>>> So the pattern "/base/:collection/" matches both "/base/test/" and
>>> "/base/test/123/". In the second case, the value of the collection
>>> variable is "test/123". In my opinion, not allowing matches to span URI
>>> segments would be less prone to unintuitive results.
>>>
>>> FWIW, a quick glance at some docs on Ruby Routes seems to indicate that
>>> they do not span URI path segments.
>>>
>>> Thoughts?
>>>
>>> Jim
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Route-matching-too-liberal--tp15348853p17993519.html
> Sent from the abdera-dev mailing list archive at Nabble.com.
>
>
Re: Route matching too liberal?
Posted by David Calavera <da...@gmail.com>.
you are right ed, I didn't think in create a class, I'm applying your patch
On Fri, Jun 20, 2008 at 7:12 PM, ed_ruder <er...@hi5.com> wrote:
>
> David,
>
> I don't think there's a need to maintain a separate Collection--rather, the
> targets Map just needs to be changed to a targets List. See the attached
> patch (I hope it comes through OK).
>
> Sorry, I would have created a ticket and submitted a patch yesterday, but I
> was figuring out EasyMock to implement a unit test. I think my unit test is
> now working, so if this patch looks good, I'll submit it.
>
> Ed
> http://www.nabble.com/file/p18033920/routemanager.patch.txt
> routemanager.patch.txt
>
> David Calavera wrote:
> >
> > well, I've added a routes collection thus the resolve method can iterate
> > over the ordered routes, but I agree that we should look at the pylons
> > routes implementation in order to improve RoutesManaget, I also like
> their
> > syntax approach.
> >
>
> --
> View this message in context:
> http://www.nabble.com/Route-matching-too-liberal--tp15348853p18033920.html
> Sent from the abdera-dev mailing list archive at Nabble.com.
>
>
--
David Calavera
http://www.thinkincode.net
Re: Route matching too liberal?
Posted by ed_ruder <er...@hi5.com>.
David,
I don't think there's a need to maintain a separate Collection--rather, the
targets Map just needs to be changed to a targets List. See the attached
patch (I hope it comes through OK).
Sorry, I would have created a ticket and submitted a patch yesterday, but I
was figuring out EasyMock to implement a unit test. I think my unit test is
now working, so if this patch looks good, I'll submit it.
Ed
http://www.nabble.com/file/p18033920/routemanager.patch.txt
routemanager.patch.txt
David Calavera wrote:
>
> well, I've added a routes collection thus the resolve method can iterate
> over the ordered routes, but I agree that we should look at the pylons
> routes implementation in order to improve RoutesManaget, I also like their
> syntax approach.
>
--
View this message in context: http://www.nabble.com/Route-matching-too-liberal--tp15348853p18033920.html
Sent from the abdera-dev mailing list archive at Nabble.com.
Re: Route matching too liberal?
Posted by David Calavera <da...@gmail.com>.
well, I've added a routes collection thus the resolve method can iterate
over the ordered routes, but I agree that we should look at the pylons
routes implementation in order to improve RoutesManaget, I also like their
syntax approach.
On Thu, Jun 19, 2008 at 11:14 PM, ed_ruder <er...@hi5.com> wrote:
>
> Yeehaw! "mvn install" builds successfully after applying both patches!
>
> Thanks for the pointers, Christopher!
>
> Ed
>
>
> Hi,
>
> See the patch in ABDERA-178, which probably fixes that failure. (BTW,
> the patch in ABDERA-176 probably fixes the test failure in the
> features extension.)
>
> --
> Christopher Elkins
>
> On Jun 19, 2008, at 12:32 PM, ed_ruder wrote:
>
> >
> > James,
> >
> > Sure.
> >
> > I've downloaded the Abdera source (as of yesterday), but "mvn install"
> > doesn't build successfully--it fails running tests for "Abdera
> > Server". Is
> > this a known problem? Building using "ant -f build/build.xml"
> > succeeds. "ant
> > f build/build.xml test" says it succeeds, but several tests fail
> > (throwing
> > exceptions). It would be nice to be able to count on the tests, not to
> > mention be able to add some of my own for this change.
> >
> > Maybe there's something I've not set up correctly?
> >
> > Ed
> >
> > P.S. I ran "mvn clean" then "mvn -fae install" and this was the
> > summary:
> >
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Reactor Summary:
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Apache Abdera ......................................... SUCCESS
> > [4.413s]
> > [INFO] I18N Libraries ........................................ SUCCESS
> > [3.467s]
> > [INFO] Abdera Core ........................................... SUCCESS
> > [1.264s]
> > [INFO] Abdera Parser ......................................... SUCCESS
> > [6.538s]
> > [INFO] Abdera Client ......................................... SUCCESS
> > [1.832s]
> > [INFO] Abdera Server ......................................... FAILED
> > [2.590s]
> > [INFO] Abdera Spring Integration ............................. SKIPPED
> > (dependency build failed or was skipped)
> > [INFO] Abdera Adapters ....................................... SKIPPED
> > (dependency build failed or was skipped)
> > [INFO] Abdera JCR Adapter .................................... SKIPPED
> > (dependency build failed or was skipped)
> > [INFO] Abdera CouchDB Adapter ................................ SKIPPED
> > (dependency build failed or was skipped)
> > [INFO] Abdera Filesystem Adapter ............................. SKIPPED
> > (dependency build failed or was skipped)
> > [INFO] Abdera JDBC Adapter ................................... SKIPPED
> > (dependency build failed or was skipped)
> > [INFO] Abdera Security ....................................... SKIPPED
> > (dependency build failed or was skipped)
> > [INFO] Abdera Extensions - GData ............................. SUCCESS
> > [0.648s]
> > [INFO] Abdera Extensions - Geo ............................... SUCCESS
> > [0.514s]
> > [INFO] Abdera Extensions - HTML .............................. SUCCESS
> > [0.522s]
> > [INFO] Abdera Extensions - Main .............................. SUCCESS
> > [1.130s]
> > [INFO] Abdera Extensions - JSON .............................. SKIPPED
> > (dependency build failed or was skipped)
> > [INFO] Abdera Extensions - Media ............................. SUCCESS
> > [1.770s]
> > [INFO] Abdera Extensions - OAuth ............................. SUCCESS
> > [1.205s]
> > [INFO] Abdera Extensions - OpenSearch ........................ SUCCESS
> > [0.978s]
> > [INFO] Abdera Extensions - Serializer ........................ SKIPPED
> > (dependency build failed or was skipped)
> > [INFO] Abdera Extensions - Sharing ........................... SUCCESS
> > [1.254s]
> > [INFO] Abdera Extensions - WSSE .............................. SUCCESS
> > [0.733s]
> > [INFO] Abdera Bundle Jar ..................................... SKIPPED
> > (dependency build failed or was skipped)
> > [INFO] Abdera Extensions - Features .......................... FAILED
> > [1.017s]
> > [INFO] Abdera Extensions ..................................... SUCCESS
> > [0.031s]
> > [INFO] Abdera Examples ....................................... SKIPPED
> > (dependency build failed or was skipped)
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Error for project: Abdera Server (during install)
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] There are test failures.
> >
> > Please refer to /Users/edruder/Dev/hi5/abdera/server/target/surefire-
> > reports
> > for the individual test results.
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Error for project: Abdera Extensions - Features (during
> > install)
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] There are test failures.
> --
> View this message in context:
> http://www.nabble.com/Route-matching-too-liberal--tp15348853p18018341.html
> Sent from the abdera-dev mailing list archive at Nabble.com.
>
>
--
David Calavera
http://www.thinkincode.net
Re: Route matching too liberal?
Posted by ed_ruder <er...@hi5.com>.
Yeehaw! "mvn install" builds successfully after applying both patches!
Thanks for the pointers, Christopher!
Ed
Hi,
See the patch in ABDERA-178, which probably fixes that failure. (BTW,
the patch in ABDERA-176 probably fixes the test failure in the
features extension.)
--
Christopher Elkins
On Jun 19, 2008, at 12:32 PM, ed_ruder wrote:
>
> James,
>
> Sure.
>
> I've downloaded the Abdera source (as of yesterday), but "mvn install"
> doesn't build successfully--it fails running tests for "Abdera
> Server". Is
> this a known problem? Building using "ant -f build/build.xml"
> succeeds. "ant
> f build/build.xml test" says it succeeds, but several tests fail
> (throwing
> exceptions). It would be nice to be able to count on the tests, not to
> mention be able to add some of my own for this change.
>
> Maybe there's something I've not set up correctly?
>
> Ed
>
> P.S. I ran "mvn clean" then "mvn -fae install" and this was the
> summary:
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Apache Abdera ......................................... SUCCESS
> [4.413s]
> [INFO] I18N Libraries ........................................ SUCCESS
> [3.467s]
> [INFO] Abdera Core ........................................... SUCCESS
> [1.264s]
> [INFO] Abdera Parser ......................................... SUCCESS
> [6.538s]
> [INFO] Abdera Client ......................................... SUCCESS
> [1.832s]
> [INFO] Abdera Server ......................................... FAILED
> [2.590s]
> [INFO] Abdera Spring Integration ............................. SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera Adapters ....................................... SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera JCR Adapter .................................... SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera CouchDB Adapter ................................ SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera Filesystem Adapter ............................. SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera JDBC Adapter ................................... SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera Security ....................................... SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera Extensions - GData ............................. SUCCESS
> [0.648s]
> [INFO] Abdera Extensions - Geo ............................... SUCCESS
> [0.514s]
> [INFO] Abdera Extensions - HTML .............................. SUCCESS
> [0.522s]
> [INFO] Abdera Extensions - Main .............................. SUCCESS
> [1.130s]
> [INFO] Abdera Extensions - JSON .............................. SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera Extensions - Media ............................. SUCCESS
> [1.770s]
> [INFO] Abdera Extensions - OAuth ............................. SUCCESS
> [1.205s]
> [INFO] Abdera Extensions - OpenSearch ........................ SUCCESS
> [0.978s]
> [INFO] Abdera Extensions - Serializer ........................ SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera Extensions - Sharing ........................... SUCCESS
> [1.254s]
> [INFO] Abdera Extensions - WSSE .............................. SUCCESS
> [0.733s]
> [INFO] Abdera Bundle Jar ..................................... SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera Extensions - Features .......................... FAILED
> [1.017s]
> [INFO] Abdera Extensions ..................................... SUCCESS
> [0.031s]
> [INFO] Abdera Examples ....................................... SKIPPED
> (dependency build failed or was skipped)
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Error for project: Abdera Server (during install)
> [INFO]
> ------------------------------------------------------------------------
> [INFO] There are test failures.
>
> Please refer to /Users/edruder/Dev/hi5/abdera/server/target/surefire-
> reports
> for the individual test results.
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Error for project: Abdera Extensions - Features (during
> install)
> [INFO]
> ------------------------------------------------------------------------
> [INFO] There are test failures.
--
View this message in context: http://www.nabble.com/Route-matching-too-liberal--tp15348853p18018341.html
Sent from the abdera-dev mailing list archive at Nabble.com.
Re: Route matching too liberal?
Posted by Christopher Elkins <ch...@esha.com>.
Hi,
See the patch in ABDERA-178, which probably fixes that failure. (BTW,
the patch in ABDERA-176 probably fixes the test failure in the
features extension.)
--
Christopher Elkins
On Jun 19, 2008, at 12:32 PM, ed_ruder wrote:
>
> James,
>
> Sure.
>
> I've downloaded the Abdera source (as of yesterday), but "mvn install"
> doesn't build successfully--it fails running tests for "Abdera
> Server". Is
> this a known problem? Building using "ant -f build/build.xml"
> succeeds. "ant
> f build/build.xml test" says it succeeds, but several tests fail
> (throwing
> exceptions). It would be nice to be able to count on the tests, not to
> mention be able to add some of my own for this change.
>
> Maybe there's something I've not set up correctly?
>
> Ed
>
> P.S. I ran "mvn clean" then "mvn -fae install" and this was the
> summary:
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Apache Abdera ......................................... SUCCESS
> [4.413s]
> [INFO] I18N Libraries ........................................ SUCCESS
> [3.467s]
> [INFO] Abdera Core ........................................... SUCCESS
> [1.264s]
> [INFO] Abdera Parser ......................................... SUCCESS
> [6.538s]
> [INFO] Abdera Client ......................................... SUCCESS
> [1.832s]
> [INFO] Abdera Server ......................................... FAILED
> [2.590s]
> [INFO] Abdera Spring Integration ............................. SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera Adapters ....................................... SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera JCR Adapter .................................... SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera CouchDB Adapter ................................ SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera Filesystem Adapter ............................. SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera JDBC Adapter ................................... SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera Security ....................................... SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera Extensions - GData ............................. SUCCESS
> [0.648s]
> [INFO] Abdera Extensions - Geo ............................... SUCCESS
> [0.514s]
> [INFO] Abdera Extensions - HTML .............................. SUCCESS
> [0.522s]
> [INFO] Abdera Extensions - Main .............................. SUCCESS
> [1.130s]
> [INFO] Abdera Extensions - JSON .............................. SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera Extensions - Media ............................. SUCCESS
> [1.770s]
> [INFO] Abdera Extensions - OAuth ............................. SUCCESS
> [1.205s]
> [INFO] Abdera Extensions - OpenSearch ........................ SUCCESS
> [0.978s]
> [INFO] Abdera Extensions - Serializer ........................ SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera Extensions - Sharing ........................... SUCCESS
> [1.254s]
> [INFO] Abdera Extensions - WSSE .............................. SUCCESS
> [0.733s]
> [INFO] Abdera Bundle Jar ..................................... SKIPPED
> (dependency build failed or was skipped)
> [INFO] Abdera Extensions - Features .......................... FAILED
> [1.017s]
> [INFO] Abdera Extensions ..................................... SUCCESS
> [0.031s]
> [INFO] Abdera Examples ....................................... SKIPPED
> (dependency build failed or was skipped)
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Error for project: Abdera Server (during install)
> [INFO]
> ------------------------------------------------------------------------
> [INFO] There are test failures.
>
> Please refer to /Users/edruder/Dev/hi5/abdera/server/target/surefire-
> reports
> for the individual test results.
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Error for project: Abdera Extensions - Features (during
> install)
> [INFO]
> ------------------------------------------------------------------------
> [INFO] There are test failures.
>
>
>
> James M Snell wrote:
>>
>> Works for me. Would you be interested in writing up a patch and
>> submitting it to jira? If not, I could work up the change but it may
>> take a few days longer as I'm trying disparately to get caught up on
>> some day job stuff.
>>
>> - James
>>
>> ed_ruder wrote:
>>> James,
>>>
>>> I'm not very familiar with Abdera, but I have browsed the source a
>>> bit
>>> after
>>> hitting the same limitation that Jim reported, while working on
>>> Shindig.
>>> I
>>> *think* that a simple change in RouteManager could alleviate some
>>> (and
>>> for
>>> me, I think, all) of the limitation.
>>>
>>> When resolving a route, Rails walks through its routes in the
>>> order that
>>> they are defined. RouteManager walks through the targets.entrySet,
>>> which
>>> is
>>> unordered. If RouteManager kept a targets List<> instead of a
>>> targets
>>> Map<>,
>>> it could walk through the routes in order. (There would need to be
>>> a new
>>> class defined, to hold both the Route and TargetType, but it would
>>> be
>>> very
>>> simple.)
>>>
>>> To work around the limitation Jim describes, a client would define a
>>> /base/:collection/:entry route before the /base/:collection route.
>>>
>>> WDYT?
>>>
>>> Ed
>>>
>>>
>>> James M Snell wrote:
>>>> Ruby matching can span segments if a default value for the missing
>>>> variables is provided. We, however, don't have default values
>>>> for our
>>>> variables. It would make sense for us to tighten up the matching
>>>> rules.
>>>>
>>>> - James
>>>>
>>>> Jim Ancona wrote:
>>>>> I have run into some problems with my Routes matching
>>>>> unexpectedly.
>>>>> Before filing a bug, I thought I'd ask for feedback on whether the
>>>>> current behavior is correct.
>>>>>
>>>>> The current algorithm attempts to match the non-variable parts
>>>>> of the
>>>>> pattern, setting the variable to whatever is in between.
>>>>>
>>>>> So the pattern "/base/:collection/" matches both "/base/test/" and
>>>>> "/base/test/123/". In the second case, the value of the collection
>>>>> variable is "test/123". In my opinion, not allowing matches to
>>>>> span URI
>>>>> segments would be less prone to unintuitive results.
>>>>>
>>>>> FWIW, a quick glance at some docs on Ruby Routes seems to
>>>>> indicate that
>>>>> they do not span URI path segments.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Jim
Re: Route matching too liberal?
Posted by ed_ruder <er...@hi5.com>.
James,
Sure.
I've downloaded the Abdera source (as of yesterday), but "mvn install"
doesn't build successfully--it fails running tests for "Abdera Server". Is
this a known problem? Building using "ant -f build/build.xml" succeeds. "ant
f build/build.xml test" says it succeeds, but several tests fail (throwing
exceptions). It would be nice to be able to count on the tests, not to
mention be able to add some of my own for this change.
Maybe there's something I've not set up correctly?
Ed
P.S. I ran "mvn clean" then "mvn -fae install" and this was the summary:
[INFO]
------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
------------------------------------------------------------------------
[INFO] Apache Abdera ......................................... SUCCESS
[4.413s]
[INFO] I18N Libraries ........................................ SUCCESS
[3.467s]
[INFO] Abdera Core ........................................... SUCCESS
[1.264s]
[INFO] Abdera Parser ......................................... SUCCESS
[6.538s]
[INFO] Abdera Client ......................................... SUCCESS
[1.832s]
[INFO] Abdera Server ......................................... FAILED
[2.590s]
[INFO] Abdera Spring Integration ............................. SKIPPED
(dependency build failed or was skipped)
[INFO] Abdera Adapters ....................................... SKIPPED
(dependency build failed or was skipped)
[INFO] Abdera JCR Adapter .................................... SKIPPED
(dependency build failed or was skipped)
[INFO] Abdera CouchDB Adapter ................................ SKIPPED
(dependency build failed or was skipped)
[INFO] Abdera Filesystem Adapter ............................. SKIPPED
(dependency build failed or was skipped)
[INFO] Abdera JDBC Adapter ................................... SKIPPED
(dependency build failed or was skipped)
[INFO] Abdera Security ....................................... SKIPPED
(dependency build failed or was skipped)
[INFO] Abdera Extensions - GData ............................. SUCCESS
[0.648s]
[INFO] Abdera Extensions - Geo ............................... SUCCESS
[0.514s]
[INFO] Abdera Extensions - HTML .............................. SUCCESS
[0.522s]
[INFO] Abdera Extensions - Main .............................. SUCCESS
[1.130s]
[INFO] Abdera Extensions - JSON .............................. SKIPPED
(dependency build failed or was skipped)
[INFO] Abdera Extensions - Media ............................. SUCCESS
[1.770s]
[INFO] Abdera Extensions - OAuth ............................. SUCCESS
[1.205s]
[INFO] Abdera Extensions - OpenSearch ........................ SUCCESS
[0.978s]
[INFO] Abdera Extensions - Serializer ........................ SKIPPED
(dependency build failed or was skipped)
[INFO] Abdera Extensions - Sharing ........................... SUCCESS
[1.254s]
[INFO] Abdera Extensions - WSSE .............................. SUCCESS
[0.733s]
[INFO] Abdera Bundle Jar ..................................... SKIPPED
(dependency build failed or was skipped)
[INFO] Abdera Extensions - Features .......................... FAILED
[1.017s]
[INFO] Abdera Extensions ..................................... SUCCESS
[0.031s]
[INFO] Abdera Examples ....................................... SKIPPED
(dependency build failed or was skipped)
[INFO]
------------------------------------------------------------------------
[INFO] Error for project: Abdera Server (during install)
[INFO]
------------------------------------------------------------------------
[INFO] There are test failures.
Please refer to /Users/edruder/Dev/hi5/abdera/server/target/surefire-reports
for the individual test results.
[INFO]
------------------------------------------------------------------------
[INFO] Error for project: Abdera Extensions - Features (during install)
[INFO]
------------------------------------------------------------------------
[INFO] There are test failures.
James M Snell wrote:
>
> Works for me. Would you be interested in writing up a patch and
> submitting it to jira? If not, I could work up the change but it may
> take a few days longer as I'm trying disparately to get caught up on
> some day job stuff.
>
> - James
>
> ed_ruder wrote:
>> James,
>>
>> I'm not very familiar with Abdera, but I have browsed the source a bit
>> after
>> hitting the same limitation that Jim reported, while working on Shindig.
>> I
>> *think* that a simple change in RouteManager could alleviate some (and
>> for
>> me, I think, all) of the limitation.
>>
>> When resolving a route, Rails walks through its routes in the order that
>> they are defined. RouteManager walks through the targets.entrySet, which
>> is
>> unordered. If RouteManager kept a targets List<> instead of a targets
>> Map<>,
>> it could walk through the routes in order. (There would need to be a new
>> class defined, to hold both the Route and TargetType, but it would be
>> very
>> simple.)
>>
>> To work around the limitation Jim describes, a client would define a
>> /base/:collection/:entry route before the /base/:collection route.
>>
>> WDYT?
>>
>> Ed
>>
>>
>> James M Snell wrote:
>>> Ruby matching can span segments if a default value for the missing
>>> variables is provided. We, however, don't have default values for our
>>> variables. It would make sense for us to tighten up the matching rules.
>>>
>>> - James
>>>
>>> Jim Ancona wrote:
>>>> I have run into some problems with my Routes matching unexpectedly.
>>>> Before filing a bug, I thought I'd ask for feedback on whether the
>>>> current behavior is correct.
>>>>
>>>> The current algorithm attempts to match the non-variable parts of the
>>>> pattern, setting the variable to whatever is in between.
>>>>
>>>> So the pattern "/base/:collection/" matches both "/base/test/" and
>>>> "/base/test/123/". In the second case, the value of the collection
>>>> variable is "test/123". In my opinion, not allowing matches to span URI
>>>> segments would be less prone to unintuitive results.
>>>>
>>>> FWIW, a quick glance at some docs on Ruby Routes seems to indicate that
>>>> they do not span URI path segments.
>>>>
>>>> Thoughts?
>>>>
>>>> Jim
>>>>
>>>
>>
>
>
--
View this message in context: http://www.nabble.com/Route-matching-too-liberal--tp15348853p18016416.html
Sent from the abdera-dev mailing list archive at Nabble.com.
Re: Route matching too liberal?
Posted by James M Snell <ja...@gmail.com>.
Works for me. Would you be interested in writing up a patch and
submitting it to jira? If not, I could work up the change but it may
take a few days longer as I'm trying disparately to get caught up on
some day job stuff.
- James
ed_ruder wrote:
> James,
>
> I'm not very familiar with Abdera, but I have browsed the source a bit after
> hitting the same limitation that Jim reported, while working on Shindig. I
> *think* that a simple change in RouteManager could alleviate some (and for
> me, I think, all) of the limitation.
>
> When resolving a route, Rails walks through its routes in the order that
> they are defined. RouteManager walks through the targets.entrySet, which is
> unordered. If RouteManager kept a targets List<> instead of a targets Map<>,
> it could walk through the routes in order. (There would need to be a new
> class defined, to hold both the Route and TargetType, but it would be very
> simple.)
>
> To work around the limitation Jim describes, a client would define a
> /base/:collection/:entry route before the /base/:collection route.
>
> WDYT?
>
> Ed
>
>
> James M Snell wrote:
>> Ruby matching can span segments if a default value for the missing
>> variables is provided. We, however, don't have default values for our
>> variables. It would make sense for us to tighten up the matching rules.
>>
>> - James
>>
>> Jim Ancona wrote:
>>> I have run into some problems with my Routes matching unexpectedly.
>>> Before filing a bug, I thought I'd ask for feedback on whether the
>>> current behavior is correct.
>>>
>>> The current algorithm attempts to match the non-variable parts of the
>>> pattern, setting the variable to whatever is in between.
>>>
>>> So the pattern "/base/:collection/" matches both "/base/test/" and
>>> "/base/test/123/". In the second case, the value of the collection
>>> variable is "test/123". In my opinion, not allowing matches to span URI
>>> segments would be less prone to unintuitive results.
>>>
>>> FWIW, a quick glance at some docs on Ruby Routes seems to indicate that
>>> they do not span URI path segments.
>>>
>>> Thoughts?
>>>
>>> Jim
>>>
>>
>