abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Diephouse" <...@envoisolutions.com>
Subject Re: [jira] Created: (ABDERA-56) Spring Integration
Date Fri, 10 Aug 2007 23:44:05 GMT
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
> >
>



-- 
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message