You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@abdera.apache.org by "Dan Diephouse (JIRA)" <ji...@apache.org> on 2007/08/09 22:01:42 UTC
[jira] Created: (ABDERA-56) Spring Integration
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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (ABDERA-56) Spring Integration
Posted by Brian Moseley <bc...@osafoundation.org>.
On 8/11/07, Adam Constabaris <ad...@clownsinmycoffee.net> wrote:
> Maven2's "optional" dependencies are provided precisely for this use
> case: some of the functionality in your project depends on X, but you
> recognize that some users won't need that functionality. So what it
> means that, for those who are pulling in Abdera from the maven
> repositories and their project uses Spring, they'll have to explicitly
> declare Spring as a dependency. Everybody else will be able to ignore it.
gotcha. it's likely that everybody who'd want to use abdera with
spring would already have spring declared as a dependency in their
project anyway, so this doesn't seem like a hardship at all.
Re: [jira] Created: (ABDERA-56) Spring Integration
Posted by Adam Constabaris <ad...@clownsinmycoffee.net>.
Brian Moseley wrote:
> On 8/10/07, James M Snell <ja...@gmail.com> wrote:
>
>> Well, my concern regarding distribution is mainly with the ant build.
>> We use the ant build to build the release. The maven build is provided
>> primarily as a convenience for developers who prefer to work with that
>> tool. I'm sure the folks who actually use maven can speak up for
>> themselves, but I would not see any problem with spring not being
>> optional in the maven pom so long as it's not included in the release
>> zip created by the ant build.
>>
>
> i'm not familiar enough with maven2 to understnad what an optional
> dependency is, but it certainly would remove some of the benefit of
> using maven to have to bring spring into the build manually. i assume
> that whatever spring jars the build would depend on are marked as
> build-only dependencies though?
>
Maven2's "optional" dependencies are provided precisely for this use
case: some of the functionality in your project depends on X, but you
recognize that some users won't need that functionality. So what it
means that, for those who are pulling in Abdera from the maven
repositories and their project uses Spring, they'll have to explicitly
declare Spring as a dependency. Everybody else will be able to ignore it.
http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
AC
Re: [jira] Created: (ABDERA-56) Spring Integration
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 8/13/07, Brian Moseley <bc...@osafoundation.org> wrote:
>
> On 8/11/07, Dan Diephouse <da...@envoisolutions.com> wrote:
>
> > The xml handling part of it it really orthogonal to the spring
> > AbderaServlet. The XML handling part is for configuring a
> ServiceContext.
> > The HttpRequestHandlerServlet approach, as I understand, it can't really
> > replace this - it could only replace the AbderaServlet which is pretty
> > simple itself. Does that make sense or am I off in my understanding of
> what
> > you're describing?
>
> nope, that's the way i understood it. seems a bit redundant to
> introduce an abdera-specific servlet that does pretty much exactly
> what HRHS does, but as you point out, that's not a large part of the
> patch.
I see your point. I'm on the fence about it - I suppose if you already have
HRHS declared, then its probably less work to do it that way. Otherwise its
probably less work to do it the AbderaSpringServlet way.
i suppose the xml stuff is just a convenience for making the
> configuration more compact and readable, yes? i have no objection to
> that, other than noting how much java code we have to provide to
> reduce the number of xml situps we have to do ;)
>
Yeah, the spring people certainly don't make it easy on us in that regard.
Most of that code is boiler plate from other projects that I've written, so
it may be a bit more verbose than it needs to be.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: [jira] Created: (ABDERA-56) Spring Integration
Posted by Brian Moseley <bc...@osafoundation.org>.
On 8/11/07, Dan Diephouse <da...@envoisolutions.com> wrote:
> The xml handling part of it it really orthogonal to the spring
> AbderaServlet. The XML handling part is for configuring a ServiceContext.
> The HttpRequestHandlerServlet approach, as I understand, it can't really
> replace this - it could only replace the AbderaServlet which is pretty
> simple itself. Does that make sense or am I off in my understanding of what
> you're describing?
nope, that's the way i understood it. seems a bit redundant to
introduce an abdera-specific servlet that does pretty much exactly
what HRHS does, but as you point out, that's not a large part of the
patch.
i suppose the xml stuff is just a convenience for making the
configuration more compact and readable, yes? i have no objection to
that, other than noting how much java code we have to provide to
reduce the number of xml situps we have to do ;)
Re: [jira] Created: (ABDERA-56) Spring Integration
Posted by James M Snell <ja...@gmail.com>.
Dan Diephouse wrote:
> [snip]
> Inside the spring module that I created, they're marked as required. This
> has the benefit of when people declare abdera-spring in their maven build it
> pulls in the dependencies automatically.
>
> However, at the moment its probably not that big of deal. I'll change the
> patch to put it in the server module with an optional dependency. In the
> future though, I may bring this issue back up again though as there may be
> both client & server related spring code. In which case I'd want to share
> stuff like AbstractSingleBeanDefinitionParser between the two modules. Which
> would imply the need for a separate spring module.
>
I'm not deadset against a separate module if that makes the most sense
and it does make sense to bundle the client and server spring code
together. It's easy to make it optional in ant using the same logic we
use for the Security module (e.g. the user has to turn on an environment
variable to build the security stuff)...
Ok, I think I just convinced myself to change my mind ;-) ... a separate
spring module would likely be the best way to go.
> [snip]
> The xml handling part of it it really orthogonal to the spring
> AbderaServlet. The XML handling part is for configuring a ServiceContext.
> The HttpRequestHandlerServlet approach, as I understand, it can't really
> replace this - it could only replace the AbderaServlet which is pretty
> simple itself. Does that make sense or am I off in my understanding of what
> you're describing?
>
Btw, can you please rename this to SpringAbderaServlet to avoid
confusion with the existing AbderaServlet?
- James
Re: [jira] Created: (ABDERA-56) Spring Integration
Posted by Dan Diephouse <da...@envoisolutions.com>.
On 8/11/07, Brian Moseley <bc...@osafoundation.org> wrote:
> On 8/10/07, James M Snell <ja...@gmail.com> wrote:
> > Well, my concern regarding distribution is mainly with the ant build.
> > We use the ant build to build the release. The maven build is provided
> > primarily as a convenience for developers who prefer to work with that
> > tool. I'm sure the folks who actually use maven can speak up for
> > themselves, but I would not see any problem with spring not being
> > optional in the maven pom so long as it's not included in the release
> > zip created by the ant build.
>
> i'm not familiar enough with maven2 to understnad what an optional
> dependency is, but it certainly would remove some of the benefit of
> using maven to have to bring spring into the build manually. i assume
> that whatever spring jars the build would depend on are marked as
> build-only dependencies though?
Inside the spring module that I created, they're marked as required. This
has the benefit of when people declare abdera-spring in their maven build it
pulls in the dependencies automatically.
However, at the moment its probably not that big of deal. I'll change the
patch to put it in the server module with an optional dependency. In the
future though, I may bring this issue back up again though as there may be
both client & server related spring code. In which case I'd want to share
stuff like AbstractSingleBeanDefinitionParser between the two modules. Which
would imply the need for a separate spring module.
>
> re the AbderaServlet and all the bean resolvers and factories and so
forth:
>
> here's an alternate approach i've taken for cosmo's webdav protocol
> handler. i use spring's HttpRequestHandlerServlet, configured in
> servlet.xml with servlet-name dav. HRHS simply looks up a spring bean
> with that same id, which it expects to implement the
> HttpRequestHandler interface, and delegates to that bean's
> handleRequest(request, response) method.
>
> i wonder if there's an opportunity to re-use these utilities and maybe
> cut down on the complexity of the spring patch. i'm not too familiar
> with spring 2's new xml configuration stuff which you're obviously
> making extensive use of in your patch, so i can't tell how much of
> that would be applicable to both the AbderaServlet and
> HttpRequestHandlerServlet approaches and how much HRHS might obsolete,
> but maybe the patch could shrink a bit? :D
The xml handling part of it it really orthogonal to the spring
AbderaServlet. The XML handling part is for configuring a ServiceContext.
The HttpRequestHandlerServlet approach, as I understand, it can't really
replace this - it could only replace the AbderaServlet which is pretty
simple itself. Does that make sense or am I off in my understanding of what
you're describing?
Cheers,
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com | http://netzooid.com/blog
Re: [jira] Created: (ABDERA-56) Spring Integration
Posted by Brian Moseley <bc...@osafoundation.org>.
On 8/10/07, James M Snell <ja...@gmail.com> wrote:
> Well, my concern regarding distribution is mainly with the ant build.
> We use the ant build to build the release. The maven build is provided
> primarily as a convenience for developers who prefer to work with that
> tool. I'm sure the folks who actually use maven can speak up for
> themselves, but I would not see any problem with spring not being
> optional in the maven pom so long as it's not included in the release
> zip created by the ant build.
i'm not familiar enough with maven2 to understnad what an optional
dependency is, but it certainly would remove some of the benefit of
using maven to have to bring spring into the build manually. i assume
that whatever spring jars the build would depend on are marked as
build-only dependencies though?
re the AbderaServlet and all the bean resolvers and factories and so forth:
here's an alternate approach i've taken for cosmo's webdav protocol
handler. i use spring's HttpRequestHandlerServlet, configured in
servlet.xml with servlet-name dav. HRHS simply looks up a spring bean
with that same id, which it expects to implement the
HttpRequestHandler interface, and delegates to that bean's
handleRequest(request, response) method.
i wonder if there's an opportunity to re-use these utilities and maybe
cut down on the complexity of the spring patch. i'm not too familiar
with spring 2's new xml configuration stuff which you're obviously
making extensive use of in your patch, so i can't tell how much of
that would be applicable to both the AbderaServlet and
HttpRequestHandlerServlet approaches and how much HRHS might obsolete,
but maybe the patch could shrink a bit? :D
whatever route we decide to go, i'll be glad to see better spring
support in abdera!
Re: [jira] Created: (ABDERA-56) Spring Integration
Posted by James M Snell <ja...@gmail.com>.
Well, my concern regarding distribution is mainly with the ant build.
We use the ant build to build the release. The maven build is provided
primarily as a convenience for developers who prefer to work with that
tool. I'm sure the folks who actually use maven can speak up for
themselves, but I would not see any problem with spring not being
optional in the maven pom so long as it's not included in the release
zip created by the ant build.
(I certainly hope that makes sense... it's been a long day :-) )
- James
Dan Diephouse wrote:
> 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 <ja...@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 <ja...@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 <ja...@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
>>>>>>>>
>>>
>>>
>
>
>
Re: [jira] Created: (ABDERA-56) Spring Integration
Posted by Dan Diephouse <da...@envoisolutions.com>.
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 <ja...@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 <ja...@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 <ja...@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
Re: [jira] Created: (ABDERA-56) Spring Integration
Posted by James M Snell <ja...@gmail.com>.
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 <ja...@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 <ja...@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
>>>>>>
>>>>
>
>
>
Re: [jira] Created: (ABDERA-56) Spring Integration
Posted by Dan Diephouse <da...@envoisolutions.com>.
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 <ja...@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 <ja...@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
Re: [jira] Created: (ABDERA-56) Spring Integration
Posted by James M Snell <ja...@gmail.com>.
"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 <ja...@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
>>>>
>>
>>
>
Re: [jira] Created: (ABDERA-56) Spring Integration
Posted by James M Snell <ja...@gmail.com>.
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 <ja...@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
>>>
>
>
>
Re: [jira] Created: (ABDERA-56) Spring Integration
Posted by Dan Diephouse <da...@envoisolutions.com>.
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 <ja...@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
Re: [jira] Created: (ABDERA-56) Spring Integration
Posted by James M Snell <ja...@gmail.com>.
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
>
[jira] Updated: (ABDERA-56) Spring Integration
Posted by "Dan Diephouse (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ABDERA-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dan Diephouse updated ABDERA-56:
--------------------------------
Attachment: spring-server.patch
This patch includes the spring stuff in the server module... Since James changed his mind I'll also attach a standalone patch as well.
> 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-server.patch, 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ABDERA-56) Spring Integration
Posted by "James M Snell (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ABDERA-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James M Snell resolved ABDERA-56.
---------------------------------
Resolution: Fixed
checked in
> 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-module.patch, spring-server.patch, 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Updated: (ABDERA-56) Spring Integration
Posted by Dan Diephouse <da...@envoisolutions.com>.
Thanks :-)
On 8/11/07, James M Snell <ja...@gmail.com> wrote:
>
> Since I changed my mind after you had already gone through the trouble
> of merging it into the server module I'll take care of the ant stuff :-)
>
> - James
>
> Dan Diephouse (JIRA) wrote:
> > [
> https://issues.apache.org/jira/browse/ABDERA-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
> >
> > Dan Diephouse updated ABDERA-56:
> > --------------------------------
> >
> > Attachment: spring-module.patch
> >
> > This is the spring stuff I wrote included as a separate module. I didn't
> have time to do the ant stuff today, so someone else may have to do that or
> I'll revisit sometime soon.
> >
> >> 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-module.patch, spring-server.patch,
> 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
Re: [jira] Updated: (ABDERA-56) Spring Integration
Posted by James M Snell <ja...@gmail.com>.
Since I changed my mind after you had already gone through the trouble
of merging it into the server module I'll take care of the ant stuff :-)
- James
Dan Diephouse (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/ABDERA-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Dan Diephouse updated ABDERA-56:
> --------------------------------
>
> Attachment: spring-module.patch
>
> This is the spring stuff I wrote included as a separate module. I didn't have time to do the ant stuff today, so someone else may have to do that or I'll revisit sometime soon.
>
>> 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-module.patch, spring-server.patch, 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
>
[jira] Updated: (ABDERA-56) Spring Integration
Posted by "Dan Diephouse (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ABDERA-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dan Diephouse updated ABDERA-56:
--------------------------------
Attachment: spring-module.patch
This is the spring stuff I wrote included as a separate module. I didn't have time to do the ant stuff today, so someone else may have to do that or I'll revisit sometime soon.
> 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-module.patch, spring-server.patch, 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (ABDERA-56) Spring Integration
Posted by James M Snell <ja...@gmail.com>.
Yep, I was actually planning to look at integrating this today.
- James
Dan Diephouse (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/ABDERA-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521113 ]
>
> Dan Diephouse commented on ABDERA-56:
> -------------------------------------
>
> Was just wondering - are there still plans to integrate this into Abdera? (Not trying to rush you here, just don't want it to get out of date and fall off the roadmap)
>
>> 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-module.patch, spring-server.patch, 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
>
[jira] Commented: (ABDERA-56) Spring Integration
Posted by "Dan Diephouse (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ABDERA-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521113 ]
Dan Diephouse commented on ABDERA-56:
-------------------------------------
Was just wondering - are there still plans to integrate this into Abdera? (Not trying to rush you here, just don't want it to get out of date and fall off the roadmap)
> 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-module.patch, spring-server.patch, 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ABDERA-56) Spring Integration
Posted by "Dan Diephouse (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ABDERA-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dan Diephouse updated ABDERA-56:
--------------------------------
Attachment: spring.patch
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.