abdera-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ant elder <ant.el...@gmail.com>
Subject Re: Abdera2 Change Summary
Date Mon, 26 Sep 2011 07:33:19 GMT
On Wed, Sep 21, 2011 at 4:54 PM, James Snell <jasnell@gmail.com> 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


View raw message