You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by "Jim Ancona (JIRA)" <ji...@apache.org> on 2008/01/30 16:46:34 UTC
[jira] Created: (ABDERA-95) DefaultProvider doesn't properly handle
parameters in base routes
DefaultProvider doesn't properly handle parameters in base routes
-----------------------------------------------------------------
Key: ABDERA-95
URL: https://issues.apache.org/jira/browse/ABDERA-95
Project: Abdera
Issue Type: Bug
Reporter: Jim Ancona
I spent some time trying to debug this last night, but didn't find the solution. I will attach a unit test patch that reproduces the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ABDERA-95) DefaultProvider doesn't properly handle
parameters in base routes
Posted by "Jim Ancona (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ABDERA-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jim Ancona updated ABDERA-95:
-----------------------------
Attachment: RouteManager.patch
Here's a patch that covers all the bases. Thanks, James!
> DefaultProvider doesn't properly handle parameters in base routes
> -----------------------------------------------------------------
>
> Key: ABDERA-95
> URL: https://issues.apache.org/jira/browse/ABDERA-95
> Project: Abdera
> Issue Type: Bug
> Reporter: Jim Ancona
> Attachments: CustomerAdapterTest.patch, RouteManager.patch, RouteManager_workaround.patch
>
>
> I spent some time trying to debug this last night, but didn't find the solution. I will attach a unit test patch that reproduces the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (ABDERA-95) DefaultProvider doesn't properly handle
parameters in base routes
Posted by "Dan Diephouse (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ABDERA-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dan Diephouse closed ABDERA-95.
-------------------------------
Resolution: Fixed
Fix Version/s: 0.4.0
> DefaultProvider doesn't properly handle parameters in base routes
> -----------------------------------------------------------------
>
> Key: ABDERA-95
> URL: https://issues.apache.org/jira/browse/ABDERA-95
> Project: Abdera
> Issue Type: Bug
> Reporter: Jim Ancona
> Fix For: 0.4.0
>
> Attachments: CustomerAdapterTest.patch, RouteManager.patch, RouteManager_workaround.patch
>
>
> I spent some time trying to debug this last night, but didn't find the solution. I will attach a unit test patch that reproduces the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ABDERA-95) DefaultProvider doesn't properly
handle parameters in base routes
Posted by "Dan Diephouse (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ABDERA-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564487#action_12564487 ]
Dan Diephouse commented on ABDERA-95:
-------------------------------------
Actually I think this is the right fix. I just applied it. Thanks again.
Is everything working for you now? Does this provide the same/better functionality that the servicesPattern stuff did?
> DefaultProvider doesn't properly handle parameters in base routes
> -----------------------------------------------------------------
>
> Key: ABDERA-95
> URL: https://issues.apache.org/jira/browse/ABDERA-95
> Project: Abdera
> Issue Type: Bug
> Reporter: Jim Ancona
> Attachments: CustomerAdapterTest.patch, RouteManager_workaround.patch
>
>
> I spent some time trying to debug this last night, but didn't find the solution. I will attach a unit test patch that reproduces the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Route.expand (was Re: [jira] Commented: (ABDERA-95) DefaultProvider
doesn't properly handle parameters in base routes)
Posted by Jim Ancona <ji...@anconafamily.com>.
James M Snell wrote:
> There should already be code there to do that. Context implements
> Iterable<String> to iterate over the variables it supports.
So it does. Sorry, I missed that. Dan would you like me to submit a patch?
Jim
Re: Route.expand (was Re: [jira] Commented: (ABDERA-95) DefaultProvider
doesn't properly handle parameters in base routes)
Posted by James M Snell <ja...@gmail.com>.
There should already be code there to do that. Context implements
Iterable<String> to iterate over the variables it supports.
- James
Jim Ancona wrote:
> James M Snell wrote:
>> Accepting a Context allows us to use custom resolvers for variable
>> values... such as the ObjectContext will provides the ability to use
>> java getters for the values. I'd suggest that we go ahead and keep it.
>
> Then what's needed is a way to combine/merge two Contexts (into a new
> one, I assume, since they're immutable). Any thoughts on the right way
> to do that? I assume it will require that the interface add a way to
> iterate the Context's contents.
>
> Jim
>
>>
>> - James
>>
>> Dan Diephouse wrote:
>>> I'm looking at this code again. Does Route.expand really need to take
>>> a Context? It seems like all it should ever really need is a Map.
>>>
>>> James - thoughts?
>>> - Dan
>>>
>>> Jim Ancona (JIRA) wrote:
>>>> [
>>>> https://issues.apache.org/jira/browse/ABDERA-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564498#action_12564498
>>>> ]
>>>> Jim Ancona commented on ABDERA-95:
>>>> ----------------------------------
>>>>
>>>> The problem with my fix is that the third parameter to
>>>> RouteManager.urlFor() is an Object and my fix only handles the case
>>>> where it is a Map. If you look at RouteManager.getContext(), you'll
>>>> see that it handles two other cases (Contaxt and Object). I couldn't
>>>> see a general way to add the extra parameters to the Context.
>>>> (Contexts don't even have the equivalent of Map.getKeys(), so you
>>>> can't find out what in them in order to merge them.) My code will
>>>> work in the current case, but would fail if a caller passed
>>>> something other than a Map to RouteManager.urlFor() .
>>>>
>>>> This look to me to be better than the servicesPattern approach. I
>>>> had tried an approach using code that I wrote to parse a URI
>>>> according to a URI template, but as James said, you can't do it in
>>>> the general case, and besides the Principle of Least Power[1]
>>>> applies: Routes are less powerful than templates but still solve the
>>>> problem cleanly and therefore are more desirable in this case.
>>>>
>>>> [1] - http://www.w3.org/2001/tag/doc/leastPower.html
>>>>
>>>>
>>>>> DefaultProvider doesn't properly handle parameters in base routes
>>>>> -----------------------------------------------------------------
>>>>>
>>>>> Key: ABDERA-95
>>>>> URL: https://issues.apache.org/jira/browse/ABDERA-95
>>>>> Project: Abdera
>>>>> Issue Type: Bug
>>>>> Reporter: Jim Ancona
>>>>> Attachments: CustomerAdapterTest.patch,
>>>>> RouteManager_workaround.patch
>>>>>
>>>>>
>>>>> I spent some time trying to debug this last night, but didn't find
>>>>> the solution. I will attach a unit test patch that reproduces the
>>>>> problem.
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Dan Diephouse
>>> MuleSource
>>> http://mulesource.com | http://netzooid.com/blog
>>>
>
>
Re: Route.expand (was Re: [jira] Commented: (ABDERA-95) DefaultProvider
doesn't properly handle parameters in base routes)
Posted by Jim Ancona <ji...@anconafamily.com>.
James M Snell wrote:
> Accepting a Context allows us to use custom resolvers for variable
> values... such as the ObjectContext will provides the ability to use
> java getters for the values. I'd suggest that we go ahead and keep it.
Then what's needed is a way to combine/merge two Contexts (into a new
one, I assume, since they're immutable). Any thoughts on the right way
to do that? I assume it will require that the interface add a way to
iterate the Context's contents.
Jim
>
> - James
>
> Dan Diephouse wrote:
>> I'm looking at this code again. Does Route.expand really need to take
>> a Context? It seems like all it should ever really need is a Map.
>>
>> James - thoughts?
>> - Dan
>>
>> Jim Ancona (JIRA) wrote:
>>> [
>>> https://issues.apache.org/jira/browse/ABDERA-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564498#action_12564498
>>> ]
>>> Jim Ancona commented on ABDERA-95:
>>> ----------------------------------
>>>
>>> The problem with my fix is that the third parameter to
>>> RouteManager.urlFor() is an Object and my fix only handles the case
>>> where it is a Map. If you look at RouteManager.getContext(), you'll
>>> see that it handles two other cases (Contaxt and Object). I couldn't
>>> see a general way to add the extra parameters to the Context.
>>> (Contexts don't even have the equivalent of Map.getKeys(), so you
>>> can't find out what in them in order to merge them.) My code will
>>> work in the current case, but would fail if a caller passed something
>>> other than a Map to RouteManager.urlFor() .
>>>
>>> This look to me to be better than the servicesPattern approach. I had
>>> tried an approach using code that I wrote to parse a URI according to
>>> a URI template, but as James said, you can't do it in the general
>>> case, and besides the Principle of Least Power[1] applies: Routes are
>>> less powerful than templates but still solve the problem cleanly and
>>> therefore are more desirable in this case.
>>>
>>> [1] - http://www.w3.org/2001/tag/doc/leastPower.html
>>>
>>>
>>>> DefaultProvider doesn't properly handle parameters in base routes
>>>> -----------------------------------------------------------------
>>>>
>>>> Key: ABDERA-95
>>>> URL: https://issues.apache.org/jira/browse/ABDERA-95
>>>> Project: Abdera
>>>> Issue Type: Bug
>>>> Reporter: Jim Ancona
>>>> Attachments: CustomerAdapterTest.patch,
>>>> RouteManager_workaround.patch
>>>>
>>>>
>>>> I spent some time trying to debug this last night, but didn't find
>>>> the solution. I will attach a unit test patch that reproduces the
>>>> problem.
>>>>
>>>
>>>
>>
>>
>> --
>> Dan Diephouse
>> MuleSource
>> http://mulesource.com | http://netzooid.com/blog
>>
Re: Route.expand (was Re: [jira] Commented: (ABDERA-95) DefaultProvider
doesn't properly handle parameters in base routes)
Posted by James M Snell <ja...@gmail.com>.
Accepting a Context allows us to use custom resolvers for variable
values... such as the ObjectContext will provides the ability to use
java getters for the values. I'd suggest that we go ahead and keep it.
- James
Dan Diephouse wrote:
> I'm looking at this code again. Does Route.expand really need to take a
> Context? It seems like all it should ever really need is a Map.
>
> James - thoughts?
> - Dan
>
> Jim Ancona (JIRA) wrote:
>> [ https://issues.apache.org/jira/browse/ABDERA-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564498#action_12564498 ]
>>
>> Jim Ancona commented on ABDERA-95:
>> ----------------------------------
>>
>> The problem with my fix is that the third parameter to RouteManager.urlFor() is an Object and my fix only handles the case where it is a Map. If you look at RouteManager.getContext(), you'll see that it handles two other cases (Contaxt and Object). I couldn't see a general way to add the extra parameters to the Context. (Contexts don't even have the equivalent of Map.getKeys(), so you can't find out what in them in order to merge them.) My code will work in the current case, but would fail if a caller passed something other than a Map to RouteManager.urlFor() .
>>
>> This look to me to be better than the servicesPattern approach. I had tried an approach using code that I wrote to parse a URI according to a URI template, but as James said, you can't do it in the general case, and besides the Principle of Least Power[1] applies: Routes are less powerful than templates but still solve the problem cleanly and therefore are more desirable in this case.
>>
>> [1] - http://www.w3.org/2001/tag/doc/leastPower.html
>>
>>
>>> DefaultProvider doesn't properly handle parameters in base routes
>>> -----------------------------------------------------------------
>>>
>>> Key: ABDERA-95
>>> URL: https://issues.apache.org/jira/browse/ABDERA-95
>>> Project: Abdera
>>> Issue Type: Bug
>>> Reporter: Jim Ancona
>>> Attachments: CustomerAdapterTest.patch, RouteManager_workaround.patch
>>>
>>>
>>> I spent some time trying to debug this last night, but didn't find the solution. I will attach a unit test patch that reproduces the problem.
>>>
>>
>>
>
>
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com/blog
>
[jira] Commented: (ABDERA-95) DefaultProvider doesn't properly
handle parameters in base routes
Posted by "Jim Ancona (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ABDERA-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564498#action_12564498 ]
Jim Ancona commented on ABDERA-95:
----------------------------------
The problem with my fix is that the third parameter to RouteManager.urlFor() is an Object and my fix only handles the case where it is a Map. If you look at RouteManager.getContext(), you'll see that it handles two other cases (Contaxt and Object). I couldn't see a general way to add the extra parameters to the Context. (Contexts don't even have the equivalent of Map.getKeys(), so you can't find out what in them in order to merge them.) My code will work in the current case, but would fail if a caller passed something other than a Map to RouteManager.urlFor() .
This look to me to be better than the servicesPattern approach. I had tried an approach using code that I wrote to parse a URI according to a URI template, but as James said, you can't do it in the general case, and besides the Principle of Least Power[1] applies: Routes are less powerful than templates but still solve the problem cleanly and therefore are more desirable in this case.
[1] - http://www.w3.org/2001/tag/doc/leastPower.html
> DefaultProvider doesn't properly handle parameters in base routes
> -----------------------------------------------------------------
>
> Key: ABDERA-95
> URL: https://issues.apache.org/jira/browse/ABDERA-95
> Project: Abdera
> Issue Type: Bug
> Reporter: Jim Ancona
> Attachments: CustomerAdapterTest.patch, RouteManager_workaround.patch
>
>
> I spent some time trying to debug this last night, but didn't find the solution. I will attach a unit test patch that reproduces the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ABDERA-95) DefaultProvider doesn't properly
handle parameters in base routes
Posted by "Dan Diephouse (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ABDERA-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564213#action_12564213 ]
Dan Diephouse commented on ABDERA-95:
-------------------------------------
I'll be taking a look at this later tonight or tomorrow. Thanks again for the patches/feedback.
> DefaultProvider doesn't properly handle parameters in base routes
> -----------------------------------------------------------------
>
> Key: ABDERA-95
> URL: https://issues.apache.org/jira/browse/ABDERA-95
> Project: Abdera
> Issue Type: Bug
> Reporter: Jim Ancona
> Attachments: CustomerAdapterTest.patch, RouteManager_workaround.patch
>
>
> I spent some time trying to debug this last night, but didn't find the solution. I will attach a unit test patch that reproduces the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ABDERA-95) DefaultProvider doesn't properly handle
parameters in base routes
Posted by "Jim Ancona (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ABDERA-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jim Ancona updated ABDERA-95:
-----------------------------
Attachment: RouteManager_workaround.patch
Further analysis show that the problem occurs when calling AbstractCollectionAdapter.getHref(RequestContext request), which calls request.urlFor("feed", hrefParams). Because hrefParams doesn't contain the parameters for the base part of the URI, the wrong href is returned.
This patch is a workaround. I have RouteManager add the missing parameters to the HashMap before building the context. This only works when the params are in a HashMap (which they are in this case). I can't figure out how to handle the other cases properly.
Perhaps this will help you find a better solution.
> DefaultProvider doesn't properly handle parameters in base routes
> -----------------------------------------------------------------
>
> Key: ABDERA-95
> URL: https://issues.apache.org/jira/browse/ABDERA-95
> Project: Abdera
> Issue Type: Bug
> Reporter: Jim Ancona
> Attachments: CustomerAdapterTest.patch, RouteManager_workaround.patch
>
>
> I spent some time trying to debug this last night, but didn't find the solution. I will attach a unit test patch that reproduces the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ABDERA-95) DefaultProvider doesn't properly handle
parameters in base routes
Posted by "Jim Ancona (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ABDERA-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jim Ancona updated ABDERA-95:
-----------------------------
Attachment: CustomerAdapterTest.patch
Patch for CustomerAdapterTest that demonstrates the problem
> DefaultProvider doesn't properly handle parameters in base routes
> -----------------------------------------------------------------
>
> Key: ABDERA-95
> URL: https://issues.apache.org/jira/browse/ABDERA-95
> Project: Abdera
> Issue Type: Bug
> Reporter: Jim Ancona
> Attachments: CustomerAdapterTest.patch
>
>
> I spent some time trying to debug this last night, but didn't find the solution. I will attach a unit test patch that reproduces the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.