abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James M Snell <jasn...@gmail.com>
Subject Re: [jira] Created: (ABDERA-56) Spring Integration
Date Fri, 10 Aug 2007 23:50:06 GMT
"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 <jasnell@gmail.com> 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

View raw message