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 Sat, 11 Aug 2007 00:18:48 GMT
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
>>>>>>
>>>>
> 
> 
> 

Mime
View raw message