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 16:26:55 GMT
On 8/11/07, Brian Moseley <bcm@osafoundation.org> wrote:
> On 8/10/07, James M Snell <jasnell@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message