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:49:30 GMT
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