Thanks for taking the time to look it over James. Why the contrib module?
My position would be that: - This is an important feature and one very likely to increase Abdera's user base. User's shouldn't have to build it on their own (which is what the contrib module seems to imply - forgive me if I'm wrong here). - Contrib stuff isn't built with the regular build, so its likely to get out of date. - My preference would be for it to be outside the server module as there is the potential for some client related stuff as well in the future. - I'll happily write up some docs to ensure that people use it - right now there are absolutely no server side docs and its quite hard to get started writing APP server stuff. The only change in the commit which I feel may be controversial is the one regarding the contextPath and Resolvers. I kind of feel that I as a user shouldn't have to worry about the context path when I set up a Resolver. So I made Abdera set the contextPath. It'd be nice if we could somehow get rid of this requirement altogether, but I'm not familiar enough with abdera to comment on how that should be done. - Dan On 8/10/07, James M Snell <[EMAIL PROTECTED]> wrote: > > Dan, at first glance this looks good. The other committers might have a > different opinion, but I think the spring stuff should likely go into > the contrib module as opposed to becoming its own module or being > dropped into the server module. Does that work for you? > > I'll have to go through the rest of the changes later this weekend. > > - James > > Dan Diephouse (JIRA) wrote: > > Spring Integration > > ------------------ > > > > Key: ABDERA-56 > > URL: https://issues.apache.org/jira/browse/ABDERA-56 > > Project: Abdera > > Issue Type: New Feature > > Reporter: Dan Diephouse > > Fix For: 0.3.0 > > Attachments: spring.patch > > > > I've written a spring module for Abdera which providers an AbderaServlet > which works with Spring as well as some XML parsers. With this creating an > Abdera Provider becomes as simple as this: > > > > <a:serviceContext> > > > > <a:provider> > > <ref bean="provider"/> > > </a:provider> > > > > <a:targetResolver> > > <a:regexTargetResolver> > > <a:collection>/atom/feed(\\?[^#]*)?</a:collection> > > <a:entry>/atom/feed/([^/#?]+)(\\?[^#]*)?</a:entry> > > <a:service>/atom(\\?[^#]*)?</a:service> > > </a:regexTargetResolver> > > </a:targetResolver> > > > > </a:serviceContext> > > > > <bean id="provider" class="org.apache.abdera.spring.TestProvider"> > > </bean> > > > > The only code you need to write then is the TestProvider class. > > > > This patch does make two other changes. > > > > 1. It modifies the Resolver interface to add a > initializeContextPath(String context) method. This makes it so you can > create target resolvers and not have to worry about the context path when > you initialize it - Abdera will just initialize it later. I'm not sure that > what I came up with is the best way to do that though. Any other > suggestions? Maybe Resolver.resolve should take contextPath as a > parameter? Maybe the request URI should come without the context path in it? > > > > 2. Uses the correct groupId for Woodstox in MAven > > > -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
