Mailing-List: contact abdera-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: abdera-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of jasnell@gmail.com designates
 66.249.82.232 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=N7vhEa48yfMX0whCKVETdp8wa9cMCKZl8o1EUTInfzPrNZ6rfjOCX3cv8XU6M7FCMDQTpAEJMv7z8MqTka58nyoGmZIneFkiG/oG3xOc/74IajNt8wvdyKhAZYpbns3D+8YF8DKGS9KEl7vvjCHt+lFQDRvUwJRJHuwYdEgbdFA=
Message-ID: <46BCF9AE.6040907@gmail.com>
Date: Fri, 10 Aug 2007 16:50:06 -0700
From: James M Snell <jasnell@gmail.com>
User-Agent: Thunderbird 2.0.0.0 (X11/20070326)
MIME-Version: 1.0
To: abdera-dev@incubator.apache.org
Subject: Re: [jira] Created: (ABDERA-56) Spring Integration
References: <6111626.1186689702547.JavaMail.jira@brutus>
	 <46BCF0D8.5050809@gmail.com>
 <7b774c950708101644j3ef01778pf0a93c036d27c744@mail.gmail.com>
 <46BCF98A.7030204@gmail.com>
In-Reply-To: <46BCF98A.7030204@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

"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
>>>>
>>
>>
>