You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "David Primmer (JIRA)" <ji...@apache.org> on 2008/05/15 03:09:56 UTC
[jira] Created: (SHINDIG-268) Refactor Route managment in the
provider
Refactor Route managment in the provider
----------------------------------------
Key: SHINDIG-268
URL: https://issues.apache.org/jira/browse/SHINDIG-268
Project: Shindig
Issue Type: Improvement
Components: RESTful API (Java)
Reporter: David Primmer
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-268) Refactor Route managment in the
provider
Posted by "David Primmer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599463#action_12599463 ]
David Primmer commented on SHINDIG-268:
---------------------------------------
In general, I get the feeling that he work we're doing to try to fix the initialization of the route system is working around the design problems in abdera. The route system is very new and has few implementations and I feel like we should get the abdrea devs, namely Dan Diephouse and James Snell involved in reviewing what we're trying to do and suggesting ways to change the framework. The RouteManager object itself, if you look at it, encompasses almost all the things we're trying to do and we're duplicating its internal structure in the enum.
It has a map for route2ca, that is designed so that it cannot be set other than through one addRoute method. We're doing a lot of code pushups to try to get everything just right to use this interface when we should be able to just use/inject the RouteManager and all it's internal objects, like the list of targets and the route2ca map. I looked into this for a day or so and there appeared to be some bootstrap issues around the Provider that required it to be setup before the RouteManager could be initialized but I can't remember what those were now. I'll try to get the abdera devs attention on this one.
> Refactor Route managment in the provider
> ----------------------------------------
>
> Key: SHINDIG-268
> URL: https://issues.apache.org/jira/browse/SHINDIG-268
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: David Primmer
> Attachments: shindig-268_refactor_route_managment.patch, useGuiceForRoutes.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-268) Refactor Route managment in the
provider
Posted by "David Primmer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600312#action_12600312 ]
David Primmer commented on SHINDIG-268:
---------------------------------------
Cassie,
regarding descriptions:
you said "the code is using the description field (provided from abdera) to convert the description text into enums. before, the descriptions were hand typed as a lowercase space separated version of the enum.toString. this seemed super super sketchy so that's why i made it automated."
I think I understand you here. You're saying that when the routename is provided by abdera, it was translated by this hand-typed connection. However that routename is set when the route is added with the result of the .toString() method. This closes the loop and makes it a fine string reference that cannot go wrong unless the value is changed midway through the request. I don't think it is going to happen. In other words, it doesn't come from abdera, it comes from the enum.
The point I was trying to make is that there are two issues with the description field-
1 a round-trip identifier for the route that can be passed into addRoute and out of getRoute. So far, the only candidates are route name and pattern. I chose route name but they're both considered immutable once the routes are initialized. I was using the contents of the description field in the enum for this purpose.
2 a way for implementers of shindig to control the display of the human-readable titles of their collections and make those titles localized. I was pointing to this with the description field and suggesting that it could also be a resource package. In any case, I suppose the 'getDescription()' interface should be maintained on the enum and the internal structure could change. I just thought the shortcut you took of pulling the description field out and changing the constructor made it harder to see the way forward since the enum didn't have a description field.
I've since realized that having decent descriptions for the collections would involve using info from the token and some sort of templating system to get "Friends of Cassie in the group 'dancers'", so I'm less attached to the plain generic strings we're providing.
btw, jira is super flaky all day. work on this issue may be delayed.
> Refactor Route managment in the provider
> ----------------------------------------
>
> Key: SHINDIG-268
> URL: https://issues.apache.org/jira/browse/SHINDIG-268
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: David Primmer
> Attachments: exampleUsage.txt, shindig-268_refactor_route_managment.patch, useGuiceForRoutes.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SHINDIG-268) Refactor Route managment in the
provider
Posted by "David Primmer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Primmer updated SHINDIG-268:
----------------------------------
Attachment: shindig-268_move_routestuff_out_of_provider.patch
the patch moves the route initialization out of the SocialApiProvider and into the SocialRouteManager. it cleans up the Guice stuff by removing the need for an initialize() method. next step is to reduce the addRoute code by injecting routes and the route2ca map directly. ....or something like that....
> Refactor Route managment in the provider
> ----------------------------------------
>
> Key: SHINDIG-268
> URL: https://issues.apache.org/jira/browse/SHINDIG-268
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: David Primmer
> Attachments: exampleUsage.txt, shindig-268_move_routestuff_out_of_provider.patch, shindig-268_refactor_route_managment.patch, useGuiceForRoutes.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-268) Refactor Route managment in the
provider
Posted by "David Primmer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599458#action_12599458 ]
David Primmer commented on SHINDIG-268:
---------------------------------------
I'll have more comments, but the first one is about the description. I'd intended that to be container-set and probably localized so I'm not sure that the current way of just lowercasing the enum name is what we want. I don't think it gets us close to that end than the other code anyhow.
I don't agree with removing the url template property. It's true that it's not used right now, but It could be used to generate the discovery doc or answering a specific api call for endpoint info. in the future and it is a useful point of documentation / link to the spec.
> Refactor Route managment in the provider
> ----------------------------------------
>
> Key: SHINDIG-268
> URL: https://issues.apache.org/jira/browse/SHINDIG-268
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: David Primmer
> Attachments: shindig-268_refactor_route_managment.patch, useGuiceForRoutes.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-268) Refactor Route managment in the
provider
Posted by "David Primmer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600319#action_12600319 ]
David Primmer commented on SHINDIG-268:
---------------------------------------
Regarding URL templates
I agree that the info needed to be manually copied from the spec, and since it was not being used in the codepath, had a chance of getting out of date.
I'm not such a fan of auto-generating it. URL templates are not the same thing as the Route patterns. I suppose as a way of specifying the static parts of the url and basic variable names you could do some sort of : > {} thing but that's little help in the end.
I put the url templates into the enum for two reasons: documentation and for generating the discovery doc.
1 docs. Ok. this is a rather lame one but I thought that for people new to the routes style templates, there would be some confusion about how they related to the url templates in the spec, so I wanted the url template from the spec to be there. Now I realize that those templates are just examples of how you could implement the spec, and the discovery doc takes care of "explaining" the server implementation's relation to the spec, so it's really about the discovery doc.
2 generating the discovery doc. This one is getting more relevant now that it was added to the spec and there are a number of ways we could use a central place to record the url patterns and configure the server. (Abdera does this for an atom service doc). The disco doc's url templates will have much more info than the collection urls, as they include optional params, so having them in the enum does not get us all the way there for generating this doc. So I'm torn. I'd originally just had the url templates in code comments so I'd be happy with them going back into comments. Are you worried about them getting out of date in the comments?
davep
> Refactor Route managment in the provider
> ----------------------------------------
>
> Key: SHINDIG-268
> URL: https://issues.apache.org/jira/browse/SHINDIG-268
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: David Primmer
> Attachments: exampleUsage.txt, shindig-268_refactor_route_managment.patch, useGuiceForRoutes.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-268) Refactor Route managment in the
provider
Posted by "Cassie Doll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597029#action_12597029 ]
Cassie Doll commented on SHINDIG-268:
-------------------------------------
David - I have some further refactoring thoughts for this piece.
First, we could move the TargetType value from the SocialApiProvider into the RequestUrlTemplate enum. After we do that then we can simply have the SocialApiProvider get one variable injected - a Map<RequestUrlType, CollectionsAdapter>. Then, we can just cycle through all the map entries and put them in the routeManager. The provider of the map, call it a RouteFactory or something can then be overridden for containers that want custom restful url additions. That is all easy enough with guice (and is similar to what the GadgetDataHandler does)
Checking in this first refactoring now and then we can continue on this later.
> Refactor Route managment in the provider
> ----------------------------------------
>
> Key: SHINDIG-268
> URL: https://issues.apache.org/jira/browse/SHINDIG-268
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: David Primmer
> Attachments: shindig-268_refactor_route_managment.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-268) Refactor Route managment in the
provider
Posted by "Cassie Doll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600746#action_12600746 ]
Cassie Doll commented on SHINDIG-268:
-------------------------------------
In order for this patch to work I had to set the routeManager field in the SocialApiProvider as well as call setRouteManagers in the SocialApiProviderTestFixture. I also made several style fixes. Committing now.
> Refactor Route managment in the provider
> ----------------------------------------
>
> Key: SHINDIG-268
> URL: https://issues.apache.org/jira/browse/SHINDIG-268
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: David Primmer
> Attachments: exampleUsage.txt, shindig-268_move_routestuff_out_of_provider.patch, shindig-268_refactor_route_managment.patch, useGuiceForRoutes.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-268) Refactor Route managment in the
provider
Posted by "David Primmer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600339#action_12600339 ]
David Primmer commented on SHINDIG-268:
---------------------------------------
In reponse to your general comment above:
I don't share your lack of faith in Abdera. It's been hard to get interest in this particular subject, but they've been very responsive throughout this project to our needs and fixed bugs and changed functionality within a day or so of our requests. James Snell was trying to work on this today when Jira blew up.
So I don't agree that we should add this code in addition to the many hours of workarounds we've already done on this issue before a cursory look from James. Much of the work I've done on this project has been around this RouteManager object and I know it pretty well now and when I originally proposed the enum, I had a feeling that it really should have been a fix for the RouteManager but took the quick path. From my perspective, we're doing hacks on top of hacks for this particular feature. If we spent just a few of the brain cycles we've spent on writing this new shindig only Route Managment system instead of improving the fairly simple Abdera Route system, there's be a lot less code checked into Shindig and abdera would be more useful.
It seems from your comment that removing old code is the primary driver for this. Can't we focus on some new features for a few days instead?
> Refactor Route managment in the provider
> ----------------------------------------
>
> Key: SHINDIG-268
> URL: https://issues.apache.org/jira/browse/SHINDIG-268
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: David Primmer
> Attachments: exampleUsage.txt, shindig-268_refactor_route_managment.patch, useGuiceForRoutes.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SHINDIG-268) Refactor Route managment in the
provider
Posted by "David Primmer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Primmer updated SHINDIG-268:
----------------------------------
Attachment: shindig-268_refactor_route_managment.patch
this patch is mostly a code cleanup, with no functionality change. I've moved the route enum to its own file and added some more info to it that will allow us to use it for other lookups. I've extended RouteManager to do an addRoute using this new enum. this allows the code in the provider to be shorter and more readable.
I'd also attempted (but didn't succeed) to use guice to wire up all this stuff. the provider has a setTargetResolver method that would allow us to inject a RouteManager, however, you need to have the adapters initialized in order to call addRoute and wire up the route to adapter connection. I may revisit this later, but it's partway injectable now.
> Refactor Route managment in the provider
> ----------------------------------------
>
> Key: SHINDIG-268
> URL: https://issues.apache.org/jira/browse/SHINDIG-268
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: David Primmer
> Attachments: shindig-268_refactor_route_managment.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SHINDIG-268) Refactor Route managment in the
provider
Posted by "Cassie Doll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cassie Doll updated SHINDIG-268:
--------------------------------
Attachment: exampleUsage.txt
btw - here is a sample usage which replaces StateFileDataHandler - its not too bad looking and we can refactor more later.
(this is not intended as a final patch. at a minimum SimpleJsonAdapter would be moved to the abdera package)
> Refactor Route managment in the provider
> ----------------------------------------
>
> Key: SHINDIG-268
> URL: https://issues.apache.org/jira/browse/SHINDIG-268
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: David Primmer
> Attachments: exampleUsage.txt, shindig-268_refactor_route_managment.patch, useGuiceForRoutes.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SHINDIG-268) Refactor Route managment in the
provider
Posted by "Cassie Doll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cassie Doll updated SHINDIG-268:
--------------------------------
Attachment: useGuiceForRoutes.patch
This patch uses guice to inject a RouteProvider. The RouteProvider is then asked for a series of RouteData to Adapter mappings.
Refactored the RequestUrlTemplate to remove unused properties and do an auto mapping from description to enum (safer that way). Also pushed the targetType into the enum.
With this patch we should be able to add the setStateFile and dumpStateFile methods into rest which will move us further along the path of removing the json wire format.
Lemme know what you think.
> Refactor Route managment in the provider
> ----------------------------------------
>
> Key: SHINDIG-268
> URL: https://issues.apache.org/jira/browse/SHINDIG-268
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: David Primmer
> Attachments: shindig-268_refactor_route_managment.patch, useGuiceForRoutes.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-268) Refactor Route managment in the
provider
Posted by "James M Snell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600375#action_12600375 ]
James M Snell commented on SHINDIG-268:
---------------------------------------
I definitely think that would be the ideal approach. You'll have to look at the init order for routes and collectionadapters but, given that both are independent of the provider, they can be init'd separately and injected into your custom provider implementation. We can tweak Abdera if there are any bits that just aren't fitting together properly or just aren't working.
> Refactor Route managment in the provider
> ----------------------------------------
>
> Key: SHINDIG-268
> URL: https://issues.apache.org/jira/browse/SHINDIG-268
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: David Primmer
> Attachments: exampleUsage.txt, shindig-268_refactor_route_managment.patch, useGuiceForRoutes.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-268) Refactor Route managment in the
provider
Posted by "David Primmer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600333#action_12600333 ]
David Primmer commented on SHINDIG-268:
---------------------------------------
comment on
exampleUsage.txt and useGuiceForRoutes.patch
I'm trying to figure out what your new adapter in exampleUsage.txt does and I *think* it's some sort of rpc-oriented interface that the 'container' supports that you'd like to have served by the abdera-based rest server. However, if I'm puzzled about all these servers and what requests they handle, then I'm sure others have no chance of figuring it out.
Some of the confusion results from us perpetuating the use of the word 'container' in too many different contexts. I have come to loath it. Your example has a comment for a class called SampleContainerRouteProvider and has an enum of SampleContainerUrls with a comment on an enum like this:
/**
* Lists all of the restful urls specific to the samplecontainer
*/
First, these urls do not appear to be RESTful at all. Second, I can never figure out what this samplecontainer thing is and how it differs from a container and shindig. Is it a legacy server that is going away? A legacy api that is going away? Is it the thowaway social data part of shindig? A permanent piece of functionality from another part of shindig that is now in social-api land?
Maybe you could explain the inheritance used here? It doesn't seem useful to have so much but I'm also not sure where shindig starts and ends. Your comment about default and optional routes has something to do with this I'm sure. Exactly how the inheritance works is somewhat constrained by abdera. However, I don't think we agree on the 'fix abdera' thing so I'll comment on that next.
> Refactor Route managment in the provider
> ----------------------------------------
>
> Key: SHINDIG-268
> URL: https://issues.apache.org/jira/browse/SHINDIG-268
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: David Primmer
> Attachments: exampleUsage.txt, shindig-268_refactor_route_managment.patch, useGuiceForRoutes.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-268) Refactor Route managment in the
provider
Posted by "Cassie Doll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599860#action_12599860 ]
Cassie Doll commented on SHINDIG-268:
-------------------------------------
replying to your comments:
description - the code is using the description field (provided from abdera) to convert the description text into enums. before, the descriptions were hand typed as a lowercase space separated version of the enum.toString. this seemed super super sketchy so that's why i made it automated. if we want descriptions and enum names to diverge later on thats fine, we'll just need to make a static map from description to enum and use that for getValue instead. (btw - if we keep relying on the description field in the adapter code we will never be able to localize.. so we should prob fix that code)
url template - i don't care if we have url templates are not it was just another case of duplicate info bothering me. if someone changed the url pattern for abdera and forgot to change the template then the code would be buggy and we would never know. if we really need this field then we should auto generate it. for example, it looks simple to go from url template to pattern (ie replace { with : and remove }). how does that sound?
general comment - so, i mean its great if abdera wants to change its structure in order to make this a cleaner integration. however, i don't want shindig to have to wait on them. this functionality is important for removing the old json wire format code and should be done as soon as we can. so - i think we should get something in and then we can iterate on it with the abdera guys. also, even if we just injected the entire RouteManager I still think we would need two levels of injection so that Shindig could provide more specific interfaces for our particular use cases. (ie we would always add the JsonFilter and ValidRequestFilter etc. we may also want to always include the defaultRoutes and only let people inject the optional routes.. dunno about that yet though)
code wise this means that i think everything should be left as is for now.
and in the very next cl i can add back in the url template if we like (next patch only to reduce complications in this patch) although i don't think we should add it until we actually use it because less unused code is always better.
what do you think?
> Refactor Route managment in the provider
> ----------------------------------------
>
> Key: SHINDIG-268
> URL: https://issues.apache.org/jira/browse/SHINDIG-268
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: David Primmer
> Attachments: shindig-268_refactor_route_managment.patch, useGuiceForRoutes.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (SHINDIG-268) Refactor Route managment in the
provider
Posted by "Cassie Doll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Cassie Doll closed SHINDIG-268.
-------------------------------
Resolution: Fixed
Assignee: Cassie Doll
> Refactor Route managment in the provider
> ----------------------------------------
>
> Key: SHINDIG-268
> URL: https://issues.apache.org/jira/browse/SHINDIG-268
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: David Primmer
> Assignee: Cassie Doll
> Attachments: exampleUsage.txt, shindig-268_move_routestuff_out_of_provider.patch, shindig-268_refactor_route_managment.patch, useGuiceForRoutes.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-268) Refactor Route managment in the
provider
Posted by "David Primmer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12600365#action_12600365 ]
David Primmer commented on SHINDIG-268:
---------------------------------------
After comments form James Snell, I think we should do away with the enum and just create a subclassed RouteManager and set up our reasonable defaults. We should replace the enum with a bunch of Route objects. There's no reason not to use the existing route2ca map in that class. It should be easy for others to add optional routes with the RouteManager and if not, we can add functionality to Abdera via a patch.
If you'd like me to work up this idea in a patch I can do that, but the basic idea, as I stated in the first comment is to actually bind the adapters to the our subclassed RouteManager (don't know if we'll need to move setAdapters() or if it can be done some other way), not the Provider, and then inject the RouteManager object we create on both setTargetResolver and setTargetBuilder in our SocialApiProvider. We already have SocialRouteManager checked in, why not just re-use that?
> Refactor Route managment in the provider
> ----------------------------------------
>
> Key: SHINDIG-268
> URL: https://issues.apache.org/jira/browse/SHINDIG-268
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: David Primmer
> Attachments: exampleUsage.txt, shindig-268_refactor_route_managment.patch, useGuiceForRoutes.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SHINDIG-268) Refactor Route managment in the
provider
Posted by "David Primmer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597038#action_12597038 ]
David Primmer commented on SHINDIG-268:
---------------------------------------
Ok. That's the direction i was going. I guess I wasn't brave enough to inject all the adapters at once.
And BTW, one thing I noticed about how this got put in was on line 79 on the provider. I took out the comment about the {uid} and replaced it with "// This section creates mappings between the urls and the adapters."
Also, i realize now that this todo is no longer valid. we have the changes to abdera now to do one adapter per entity and not per url. It needs to be removed.
* TODO: Create one CollectionAdapter per URL. There is currently logic in the
* People and Activities Adapters that allows them to be multi-purpose, but
* this will need to change.
> Refactor Route managment in the provider
> ----------------------------------------
>
> Key: SHINDIG-268
> URL: https://issues.apache.org/jira/browse/SHINDIG-268
> Project: Shindig
> Issue Type: Improvement
> Components: RESTful API (Java)
> Reporter: David Primmer
> Attachments: shindig-268_refactor_route_managment.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.