Mailing-List: contact abdera-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: abdera-user@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Reply-To: <remy@arrova.ca>
From: "Remy Gendron" <remy@arrova.ca>
To: <abdera-user@incubator.apache.org>
References: <6EB4C6A50DE34B0CAF5F0583BFAF6C24@ArrovaL001>
 <47D097B8.4090207@mulesource.com>
In-Reply-To: <47D097B8.4090207@mulesource.com>
Subject: RE: Abdera / Spring sample application
Date: Fri, 7 Mar 2008 09:30:49 -0500
Organization: Le Groupe Arrova Inc.
Message-ID: <DE20D00ECE224B98A77F59C8787DC3DC@ArrovaL001>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1250"
Content-Transfer-Encoding: 7bit
Thread-Index: Ach/8TrGfMygdNgXTR2D1H7RslI9YgAbFuYg

Hi Dan,

This example is part of an actual project here. This is why some classes are
there as place holders for more things to come.

I just didn't want to depend too much on the Abdera Spring package as at
first, I didn't knew too much where I was going. Moreover, I (maybe
mistakenly) thought that some refactoring would change this package after
the big 0.4.0 Abdera refactoring.

Service interface and ServiceBean are there as place holder as I will surely
be moving generic behaviors up into these classes as I move forward with my
real project.

Again, I agree with you, this code could be cleaned up and simplified if
provided as an official demo. However, someone on the mailing list requested
a few weeks ago an example Spring implementation and I wanted to make this
available in its current, but unfinished state.

But, using interfaces over domain objects goes a long way into preventing UI
developers from introducing BRs into the screens. I think we could leave
that part in the demo. And it aligns with Spring philosophy of coding to
interfaces.

HierarchicalDependencyConstraint is for used with the JDepend library in my
unit test. JDepend comes with a constraint class that can validate
dependencies. However, you have to explicitly list all of a class
dependencies to use it. I wanted to check generic layer dependencies such
as: the service layer cannot access the presentation layer, the presentation
layer must access the service layer thru the service api package only, the
presentation layer cannot access the persistence/dao layer directly.

I'll port my code to the official 0.4.0 tag when it's out and thereafter
I'll cleanup the demo for official inclusion in Abdera and the wiki.

R.


-----Original Message-----
From: Dan Diephouse [mailto:dan.diephouse@mulesource.com] 
Sent: March 06, 2008 20:18
To: abdera-dev@incubator.apache.org
Cc: abdera-user@incubator.apache.org
Subject: Re: Abdera / Spring sample application

Hi Remy,

Thanks for submitting this!

Some thoughts:

    * Couldn't you use the bundled SpringAbderaServlet? Other than the
      logging I don't see any functional differences.
    * I like that this goes from the frontend to the db
    * Are the Service/ServiceContext/ServiceBean clases necessary for
      the demo? It'd be nice to simplify things for a demo's sake.
      Granted you may introduce some tighter coupling by making Movie a
      concrete class instead of an interface and may not be able mock
      it, but at the same time we aren't trying to show the world those
      two things either :-) If I'm not wrong, this would allow some of
      the classes in the iex.rest package to go to.
    * It'd be nice if we could at least provide a parallel configuration
      which showed how to use the spring xml config support that we bundle.
    * What is HierarchicalDependencyConstraint for?

Dan

Remy Gendron wrote:
> Hello all,
>
> I have put together an Abdera server sample application that serves
movies,
> actors and roles (data taken from IMDB).
>
> The com.lacapitale.iex package is the glue code (or framework) part. The
> com.lacapitale.imdb is the example application.
>
> It demonstrates the following:
>
> * Application layering
>   * DAO
>   * Services
>   * Services APIs
>   * REST
> * Domain objects
>   * Domain objects used as DTOs
>   * Clients of the service layer only access the domain objects thru
> interfaces that restricts access to certain fields, thus preventing
business
> rules from being coded in the UI.
> * Spring integration:
>   * Auto discovery of adapters.
>   * Auto wiring of all dependencies.
>   * An example (ServiceContextBean) of a request scoped bean that
decouples
> the services layer from Abdera.
>   * Jdbc templates.
>   * MySQL DAOs to come later. DAO type selection would be done by a Spring
> auto discovery filter.
> * Abdera
>   * Automatic construction of the entry.content element thru reflection of
> the domain objects' implemented interfaces.
>   * Collection paging. 
> * Unit testing
>   * In memory HSQLDB.
>   * Jetty container.
>   * Base REST test class that starts HSQLDB, loads the test db scripts,
> starts Jetty/Spring/Abdera/IMDB.
>   * Base adapter test class that provides around 15 generic feed tests.
>   * Abstract DB unit test wrapper to load test data from sql scripts
(MySQL
> support to come).
>   * Unit tests for good application dependencies enforcement between the
> layers.
> * Misc
>   * Java configuration instead of XML or properties.
>
> This is a work in progress. No Javadoc yet. Any comments are welcome.
> I don't suggest providing a Spring integration with Abdera, the way to do
it
> depends to much on individual taste.
> However, this could become part of the Wiki.
>
> You can get the project here: http://arrova.ca/files/imdb.rar
>
> Remy
>
> The dependencies are not included. Spring 2.5.1 was used. Here's my
> dependencies folder content:
>
> abdera-i18n-0.4.0-incubating-SNAPSHOT.jar
> abdera.client.0.4.0-incubating-SNAPSHOT.jar
> abdera.core.0.4.0-incubating-SNAPSHOT.jar
> abdera.parser.0.4.0-incubating-SNAPSHOT.jar
> abdera.protocol.0.4.0-incubating-SNAPSHOT.jar
> abdera.security.0.4.0-incubating-SNAPSHOT.jar
> abdera.server.0.4.0-incubating-SNAPSHOT.jar
> abdera.spring.0.4.0-incubating-SNAPSHOT.jar
> axiom-api-1.2.5.jar
> axiom-impl-1.2.5.jar
> bcprov-jdk15-137.jar
> commons-codec-1.3.jar
> commons-el.jar
> commons-httpclient-3.1.jar
> commons-logging-1.0.4.jar
> geronimo-activation_1.0.2_spec-1.1.jar
> geronimo-servlet_2.4_spec-1.0.jar
> hsqldb.jar
> htmlparser-1.0.5.jar
> jaxen-1.1.1.jar
> jdepend-2.9.jar
> jetty-6.1.3.jar
> jetty-util-6.1.3.jar
> json-1.0.jar
> junit-4.4.jar
> log4j-1.2.14.jar
> myfaces-api.jar
> myfaces-impl.jar
> ojdbc14.jar
> serializer.jar
> spring-test.jar
> spring.jar
> stax-api-1.0.1.jar
> tomahawk.jar
> wstx-asl-3.2.1.jar
> xmlsec-1.4.1.jar
> xpp3_min-1.1.4c.jar
> xstream-1.3.jar
>
>
>
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition. 
> Version: 7.5.516 / Virus Database: 269.21.6/1315 - Release Date:
2008.03.06
> 09:07
>  
>
>   


-- 
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com 

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.21.6/1315 - Release Date: 2008.03.06
09:07
 

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.21.6/1317 - Release Date: 2008.03.07
08:15