Mailing-List: contact abdera-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: abdera-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <7b774c950708101652j4723e37ak1601c6ed72e500b4@mail.gmail.com>
Date: Fri, 10 Aug 2007 19:52:02 -0400
From: "Dan Diephouse" <dan@envoisolutions.com>
To: abdera-dev@incubator.apache.org
Subject: Re: [jira] Created: (ABDERA-56) Spring Integration
In-Reply-To: <46BCF9AE.6040907@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_29997_1259159.1186789922590"
References: <6111626.1186689702547.JavaMail.jira@brutus>
	 <46BCF0D8.5050809@gmail.com>
	 <7b774c950708101644j3ef01778pf0a93c036d27c744@mail.gmail.com>
	 <46BCF98A.7030204@gmail.com> <46BCF9AE.6040907@gmail.com>

------=_Part_29997_1259159.1186789922590
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_29997_1259159.1186789922590--