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 Sat, 11 Aug 2007 00:25:25 GMT
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 <jasnell@gmail.com> 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 <jasnell@gmail.com> 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 <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