abdera-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James M Snell <jasn...@gmail.com>
Subject Re: Advice on implementing an APP server
Date Wed, 21 Feb 2007 16:09:50 GMT
Documentation for the server code has been on my todo list for quite
some time.

Adam Constabaris wrote:
> I'm working my way through the server example, and I figured while I'm
> working out how to do it, I might as well try to write some
> documentation.  I'm fairly new to this part of the framework, so I'm
> looking to clear some stuff up:
> 1. Configuration precedence order:
> - hard coded defaults
> - META-INF/services
> - abdera.properties
> - system properties
> - (for Abdera Servlet) servlet config parameters

Generally yes.  You can see the progression in the
getConfigurationOption method on the AbderaConfiguration class. The
first place Abdera will look for configuration options are the system
properties. Failing that, it will look in the abdera.properties resource
bundle.  Not all of the configuration properties have defaults, but
those that do will use those defaults if neither the option is set via
the system properties or abdera.properties.

Abdera Servlet is a bit different because of the need to conform to the
standard servlet way of initializing properties.  For that, servlet init
params are used.

> 2. As with parsers etc, default (non-abstract) implementations are
> provided for all the factories and workhorse classes used in the server
> framework one needs /except/ ProviderManager and Provider; a minimalist
> working setup requires creating PM and P implementations, plus
> specifying a TargetResolver.

A Provider is the main workhorse of an Abdera server implementation.  It
provides the bridge from the APP interface to whatever underlying data
store you're using.

The absolute minimum you need to get an APP server up and running with
Abdera is a Provider implementation, a ProviderManager, a TargetResolver
and a Service Context.  This can be seen in the examples module [1]

The Service Context tells the AbderaServlet implementation which
Provider Manager and Target Resolver to use.

  package org.apache.abdera.examples.appserver;
  import org.apache.abdera.protocol.server.DefaultServiceContext;
  public class SimpleServiceContext
    extends DefaultServiceContext {
    protected String getDefaultProviderManager() {
      return SimpleProviderManager.class.getName();
    protected String getDefaultTargetResolver() {
      return SimpleTargetResolver.class.getName();

Via the Service Context, you can also plug in custom implementations of
the Request Handler and Subject Resolver.  The Request Handler is the
piece that handles the dirty details of the APP protocol, mapping the
servlet API to the Provider API.  You can completely customize that
mapping although doing so is just a bit nonobvious at the moment :-).
The subject resolver is used to map authenticated users into Java
Subject class instances.


> While I'm on (2) (and this is nearer to my immediate concerns, but seems
> like a ripe subject for documentation): suppose my APP server is part of
> an existing application that uses Spring with JPA/Hibernate/JDO/iBatis
> for data access (or just that I really like Spring IoC and I want to use
> it behind my new APP server).  I've got this juicy set of services just
> sitting there, already initialized, and now I need to instantiate a
> ProviderManager and give it access to those things.  I can't use Spring
> to inject those services into the ProviderManager instance, because as
> long as I'm using the stock AbderaServlet, creation of the protocol's
> factory objects is controlled by the Abdera framework.  Since there

AbderaServlet [2] really does not do that much.  It would be a simple
matter to create a new Servlet implementation that better meshes with


> doesn't seem to be a way to access the servlet context (where a
> reference to the Spring context can be held) through the framework
> classes, it looks like the cleanest approach is to subclass

Yeah, this is annoying me also. I'm going to fix that.

> AbderaServlet, which can inject the Spring-managed dependencies into the
> Abdera factory classes.  Mutatis mutandis if I'm working with
> EJB3/Servlets 2.5 and I want to inject container-managed JPA
> EntityManagers into my Abdera-based classes.
> Is the gist of the above paragraph generally supportable, or am I
> missing some cleaner way(s) of doing Spring/EJB3-backed data integration?

This is pretty much right on.  Assuming I have the time later this week
I'll write up some detailed notes and I will be making some changes to
that code to make it easier to use / configure / customize.

- James

View raw message