Hi Florent, we made the same experience in our implementation with Abdera. The CMIS model and the ideas of Abdera are not fitting very well together. The areas where Abdera tries to simplify your life with Atom are often not very helpful when implementing CMIS (where most of the logic lies in the extensions). On the other side Abdera makes reusing code between the various bindings more difficult. For example I spent an evening to hook into the XML serialization process but neither understood the design nor got it to work. Another real pain is that Abdera prevents hot deployment in Tomcat (some resources get locked, might be Windows specific). These difficulties were the main reason why we decided to migrate to a plain XML interface within our latest refactoring. So you are definitely not alone with your thoughts.
Jens -----Original Message----- From: Florent Guillaume [mailto:[email protected]] Sent: Montag, 22. Juni 2009 19:35 To: [email protected] Subject: Re: code status update Hi all, Here's another update about the Chemistry code. I checked in code that provides the AtomPub server bindings using a JAX-RS Resource. This is actually something very useful to have beyond a simple servlet, and that we do use in the Nuxeo backend. (Note that the Nuxeo backend, in our code repository, is now working and interoperating with Chemistry.) The JAX-RS code is unit-tested with CXF for now, and is working inside Nuxeo with RESTEasy (and Nuxeo WebEngine on top). The AtomPub servlet code has also been cleaned a bit, to properly deal with non-empty servlet contexts and/or servlet paths. There's now a simplistic implementation of the query method for the in- memory implementation (just "SELECT * FROM sometype" is working) which allows unit tests of the protocols to cover the query parts -- this was quite useful to debug POSTing. Finally a remark about Abdera. As I've had to do a lot of step-by-step debugging in it, I have to say I'm less and less fond of using Abdera for the server part. I feel it's really overkill for a fixed-scope implementation like Chemistry. The levels of wrapping of a simple StAX parser it's doing (StAX -> AXIOM + Abdera FOMElement -> Abdera ElementWrapper) really have a cost. Also, the Abdera model of collections and workspace managers is cumbersome to use in our setting where there's an undetermined number of collections (one for each folder) which aren't all workspaces. And there's more stuff like that. At this point I feel I would have lost less time by coding directly a StAX parser for the parts of AtomPub we're interested in. So I'm seriously thinking about not using Abdera in a next version of the server. This wouldn't prevent us from providing Abdera Element implementations for those that wish to use it. Anyway, before that there's more work to do on queries, and fleshing out the implementations. Cheers, Florent On 16 Jun 2009, at 16:56, Florent Guillaume wrote: > Here's a quick status update on the code I committed in the last few > days. > > My goal was to have a basic framework working for the AtomPub > client, and this is now achieved. > > The AtomPub client and the AtomPub server can be plugged together, > with the simple in-memory implementation as a backend for the > server. Then I can run the same basic tests either on the direct in- > memory implementation, or on the AtomPub client+server stack. This > provides a very easy way to ensure that the AtomPub stack works well. > > Of course for now the tests are still extremely limited in coverage, > but the plumbing is there to add more easily. > > Next steps for me is to update by Nuxeo backend for Chemistry (not > in Apache's repository). -- Florent Guillaume, Head of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
