On Wed, Sep 21, 2011 at 4:54 PM, James Snell <[email protected]> wrote: > Ok, so I've checked in the initial run at a proposed Abdera 2.0... > there are quite a few changes in this package so I thought it would be > good to summarize things for those of you checking things out. > > 1. First off, all of the dependencies have been updated to the latest, > greatest versions. In several cases (such as the upgrade to Apache > HTTP Client 4.x) this meant making major changes to the code. In fact, > the entire Client code component has been overhauled and improved. The > basic API will still be familiar to those familiar with Abdera 1.x > tho. > > 2. Second, the java package layout has been rearranged significantly. > Because of the many non-backwards compatible changes that have been > introduced, the base java package for abdera 2.0 is now > org.apache.abdera2.*. With the exception of possible differences in > configuration files, both the 1.x and 2.x versions can sit within the > same classpath without conflicting. > > 3. Many of the "common" utility classes have been updated. For > instance, org.apache.abdera.model.AtomDate has been moved to > org.apache.abdera2.common.date.DateTime and has been expanded to > support ISO8601 Duration and Intervals as well. The URI Template > library has been overhauled to support the latest version of the URI > Templates specification. The Lang tag implementation has been > simplified. Language tag validation code has been removed. The > language tag registry has grown significantly and the code just wasn't > keeping pace with it so it was better, and more scalable just to > remove the validation code. The new org.apache.abdera2.common.http.* > package contains a number of utilities for working directly with > various HTTP Header values.. these include EntityTags, Q-value > qualified tokens (e.g. for content negotiation), custom Authentication > headers, cache controls and web links > (http://tools.ietf.org/html/rfc5988). > > 4. A very important change is that the NamedWriter and NamedParser > mechanism has been revamped. In fact, the NamedWriter and NamedParser > interfaces have been dropped completely and replaced with just Writer > and Parser implementations that use the @Name annotation from > org.apache.abdera2.common.anno.* package. The functionality for > supporting named writers and parsers is still there, but if you've > implemented a NamedWriter and NamedParser, then you'll have to port > those over when moving to Abdera2 > > 5. There is now a DefaultImplementation annotation that can be used > with the classpath discovery mechanism for specifying the default > implementation of an interface. > > 6. There is a new Selector interface that provides a mechanism of > filtering requested lists. New methods have been added to the Feed > Object Model API to support the use of selectors... For instance, > entry.getLinks(new MySelector()) ... the Selector interface can > greatly simplify the code necessary for iterating through a list of > elements and can improve overall performance since the FOM method > implementations will apply the selector internally when it is building > the list to return, avoiding the need to iterate through the list > multiple times. > > 7. There is an experimental new Pusher interface. This is essentially > a pub/sub style interface for pushing objects (e.g. atom entries or > activities) to a collection of listeners. It can, for instance, be > used to implement a long-polling async servlet based on the new > Servlet 3.0 asynchronous request support. An experimental long polling > servlet has been included in the > org.apache.abdera2.common.protocol.servlet.async package. The default > implementation of the Pusher interface is based on a > ConcurrentLinkedQueue and mechanisms from the java.util.concurrent.* > package, but alternative implementations can be plugged in using the > usual Abdera classpath discovery model. You could, for instance, back > it up with a message queue for a more enterprisey implementation > approach. > > 8. The Unicode stuff has been completely replaced with ICU4J. This > should have happened a long time ago but I'd never gotten around to > it. > > 9. An implementation of http://tools.ietf.org/html/rfc5987 has been > added to the org.apache.abdera2.common.test.Codec class and has been > made the default encoding for HTTP Headers that include non-ascii > characters. Q and B Codec support is still included as a fallback. > > 10. ExtensionFactory implementations that extend from > AbstractExtensionFactory have been simplified using Annotations. > Whereas before you had to call a number of methods in the constructor > to register the namespace and extension implementation classes handled > by the ExtensionFactory, now you can use a number of simple > annotations. For instance, > > @Namespace({"http://example.org/foo/ns"}) > @Impls({@Impl(Foo.class)}) > public final class MyExtensionFactory extends AbstractExtensionFactory {} > > @QName(value="foo", ns="http://example.org/foo/ns";) > public class Foo extends ElementWrapper { ... } > > And that's it... configuration of ExtensionFactory impls using > classpath discovery remains unchanged. > > 11. The ExtensionFactoryMap implementation has been improved. Before, > when an extension needed to be created, it would iterate through ALL > of the extension factories until it found one that could create the > extension, regardless of whether the extensionfactory was capable of > handling extensions of that particular namespace. This caused a > significant performance lag and really was a bug that should have been > fixed a long time ago. Now it checks first to see if the > extensionfactory is capable of handling the namespace before it > attempts to create the element. > > 12. Performance in the FOMFactory implementation has been greatly > improved by building an internal hashmap of QName to Constructor > pairs. That is, whenever the factory needed to create an element, it > would go through and check the qname of the element being created > against each of the known core QNames. Each one of these was an > equals(...) check that would be performed sequentially every time, > causing poor linear performance as we were parsing. Obviously, when > dealing with large amounts of elements, it was enough to really slow > things down. So instead, when the FOMFactory class is created, a > static mapping of QNames to the appropriate Constructor methods on > their respective classes is created and cached in memory. When a > request to create an element instance of received, we simply need to > do a constant time lookup of the appropriate constructor, call > newInstance(...) on it and off we go. The performance improvement is > significant. > > 13. the ListParseFilter has been changed to a SetParseFilter... using > Set internally for that just made more sense and generally improves > performance. > > 14. The server code has undergone a major overhaul, primarily to > support the addition of the Activity Streams component that I'll talk > about in a minute. Basically, in Abdera 1.x, the server assumed the > use of the Atom format throughout every layer. The Feed Object Model > was baked in to nearly every class. In Abdera2, the core of the Abdera > Server Framework has been abstracted out so as to not depend or assume > any specific data format. This allows us, for instance, to create a > publishing service for JSON Activity Streams that uses the Activity > Streams format as a direct replacement for an Atom Feed. This > essentially gives us an out of the box mechanism for working with > Activity Streams the same way we work with Atompub > > 15. The major new addition to Abdera2 is the Activities Streams > component. This is based entirely on the JSON Activity Streams > specification and does not include support for the Atom-based > Activities Streams specification (the Atom-based flavor can be added > later within the extensions module if necessary). The activities > module includes support for producing and consuming activity streams, > provides a rich api for interacting with the various Activity Streams > objects, include a Client and Server implementation based on the exact > same model used for Atompub, and provides a number of utilities and > extensions to the core spec. A rich set of examples are included. > > 16. I'm sure there are other things that I'm missing and haven't > mentioned. Overall, there are a number of API changes throughout that > I will continue to work on documenting. Example documentation will > need to be updated. > > Things yet to be done... > > 1. I did not port any of the existing Adapters or the Spring module > over to the new code. This is primarily because the dependencies for > those have changed significantly as well and I'm just not an expert in > each of those specific components. I'm also not sure which backend > data storage mechanisms we should be primarily targeting right now. It > would be great if we could get some others to start taking a look at > those. > > 2. The Servlet 3.0 support is still highly experimental. The basic > servlet works fine, but the async servlet stuff needs work and > testing. Right now there's a bad memory leak in the default > implementation that I haven't had a chance to track down yet. > > 3. Extensive testing and even more testing. I've run through all the > test cases and have them working with a few minor exceptions for the > async servlet stuff, but given how many changes have gone into this, > it needs to be thoroughly put through it's paces. >
Hi James, I've not had the time to look in any detail at this yet sorry, it does all look interesting and it sounds like you've done a lot of work on it. We've not had much new development in Abdera for a while so i guess i'd be happy with going on with this as Abdera v2 and continuing the existing v1 trunk for maintenance. I do get some compile errors when trying to build which i've not had a chance to debug yet, this type of thing: [ERROR] \Abdera\svn\abdera2\server\src\main\java\org\apache\abdera2\protocol\server\impl\AbstractAtompubWorkspaceProvider.java:[72,24] type parameters of <S>S cannot be determined; no unique maximal instance exists for type variable S with upper bounds S,org.apache.abdera2.common.protocol.ResponseContext ...ant
