I can do that. Although, I would still prefer that it go in the spring module. Then the Maven POM stuff works correctly. Otherwise we need to declare the spring-web dependency as optional and then people need to pull it in themselves. Minor point though I guess.
- Dan On 8/10/07, James M Snell <[EMAIL PROTECTED]> wrote: > > Ok, then I guess I'm fine with this. Would it be possible to have you > make two tweaks to the patch? > > 1. Collect all the spring stuff into: > org.apache.abdera.protocol.server.spring.* > > We can just drop it in as part of the server module > > 2. Provide the ant build and deps.properties patches necessary > to build the spring stuff. > > If you can't do the second, no problem, I can do it if you can provide > me with the proper url to download the right version of spring. > > - James > > Dan Diephouse wrote: > > 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
