David Primmer wrote:
I'll try to point out the biggies issues for Abdera since the issue is
getting 'muddy'.
We extend DefaultProvider with our provider. It uses a RouteManager,
that is setup within the code of our provider. After setting up about
10 routes, I took a look at the code and it smelled. So I tried to
move some of the route managment and setup out of the provider class
and into an enum that defined the basic arguments to .addRoute(name,
pattern, type,collectionAdapter)
With you so far...
At the same time, there was a move toward dependency injection, we'd
like to take a lot of this initialization code completely out of our
provider as I mentioned in the jira issue. The provider has a
setTargetResolver method that would allow us to inject a RouteManager
that has been setup with targets and CollectionAdapters, however, you
need to have the adapters initialized in order to call addRoute and
wire up the route to adapter connection. Adapters get initialized in
our provider so it's appears to be a chicken-n-egg thing. However,
maybe I'm just not able to see how it's done with our DI system,
Guice.
Adapters are not tied to the Provider. You should be able to init them
independently of the Provider, then add some kind of addAdapter method
to your provider or rely on the routes to pass those in.
So now, as a work around to the fact that the only way to use
RouteManager seems to be via addRoute in the provider, we have
externalized the route2ca map in our own map and the routes map in our
enum and on and on it seems until we've re-written the routemanager.
In addition to that, with Cassie's new changes, we've perpetuated this
system seem to need a more functionality that allows us to have
'default' routes that are in essence 'hardcoded' into our server, and
another system to allow people to extend our default routes with
optional routes. This is where I feel like we need to stop with the
workarounds.
Shouldn't we just be able to subclass RouteManager, implement some
hardcoded default routes and a route2ca map and inject on
setTargetResolver or is the order of invocation going to get us?
Yes, that's all you *should* have to do. If there are specific
limitations in the current code that make that impossible, submit a
patch and we'll get it fixed.
- James
davep
On Tue, May 27, 2008 at 3:36 PM, David Primmer <[EMAIL PROTECTED]> wrote:
it's a long discussion thread with 3 patches attached that affect
multiple files. I think jira was down when you tried. It was down for
me.
It's kinda hard to summarize. AND I wanted you to personally weigh in
an influence the shindig devs -- something that I have not been able
to do.
Let me know if it's still a problem. Our jira should be open to all.
davep
On Tue, May 27, 2008 at 2:32 PM, James M Snell <[EMAIL PROTECTED]> wrote:
Hey Dave, for some reason I'm not able to pull up that jira issue. Can you
provide a bit more context?
- James
David Primmer wrote:
https://issues.apache.org/jira/browse/SHINDIG-268
Cassie Doll and I are going back and forth trying to figure out a
cleaner way to use dependency injection with the DefaultProvider and
the RouteManager. I'd like to ask your opinion on these issues and see
if there isn't a way we can design Abdera to make it more flexible.
svn head of shiding has a system that does not have the
useGuiceForRoutes.patch applied and that's what we're debating.
thanks
davep
