My *only* concern with the spring stuff is introducing additional dependencies. It's not that big of a deal to require spring when building but I would definitely want to make sure we're not shipping it or requiring it.
- James Dan Diephouse wrote: > 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 >>> > > >
