Oh yeah, a definite -1 to shipping any spring stuff in the distribution. If people are using the Abdera Spring stuff I think they already have Spring around. Cheers, - Dan
On 8/10/07, James M Snell <[EMAIL PROTECTED]> wrote: > > "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 > >>>> > >> > >> > > > -- Dan Diephouse Envoi Solutions http://envoisolutions.com | http://netzooid.com/blog
