James M Snell wrote:
By the way, I'm not totally agreed with Dan when he says that the
default
regex target resolver should distinguish the target based on the content
type too. I understand the requirement but I think this could be a
job for a
more specific resolver like StructuredResolver.
Yeah, I'm not convinced either. The resolver design was intended to
allow varying approaches and I have no problem if
StructuredTargetResolver wants to use the content type, but the
regextargetresolver likely should not.
When building generic stores such as the JCR one this is a requirement.
You don't know if someone is going to post an atom entry or a media
entry. So you need a way to distinguish IMO. It'd be great if there is a
clean way to do this. But I understand what you're saying.
On the other hand, what happens with the Spring extension? Dan, are you
going to refactor it too? When you finish the server refactor I'd
like to
take a look to the spring extension in order to rewrite my abdera
implementation, so I will be glad to contribute.
Dan has already done some refactoring. I don't know if he was
planning to do more. Since I don't use spring, it would definitely be
good to have more eyes looking at it to see what else needs to change
I've already done this. Check out:
http://svn.apache.org/repos/asf/incubator/abdera/java/branches/server_refactor_all/spring/src/test/resources/org/apache/abdera/spring/beans.xml
- Dan
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com/blog
