"shipping it" == shipping spring, not your patch :-) - James
James M Snell wrote: > 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 >>>> >> >> >
