Mailing-List: contact dev-help@oltu.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@oltu.apache.org
Received-SPF: pass (athena.apache.org: domain of asanso@adobe.com designates
 64.18.1.237 as permitted sender)
From: Antonio Sanso <asanso@adobe.com>
To: "dev@oltu.apache.org" <dev@oltu.apache.org>
Date: Wed, 15 May 2013 13:13:26 +0100
Subject: Re: An experimental approach for domain models
Thread-Topic: An experimental approach for domain models
Thread-Index: Ac5RZZq+SrYLFdrUR9et7x5bIv+7XA==
Message-ID: <DE5AE65A-3DB5-4C02-B1D6-E7DEBA7D9A33@adobe.com>
References: 
 <CAAqLGLPULdXOPNKc7D0HAKWs48RVqFFr-aRk75YCoN6_+sPs-Q@mail.gmail.com>
In-Reply-To: 
 <CAAqLGLPULdXOPNKc7D0HAKWs48RVqFFr-aRk75YCoN6_+sPs-Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Simone,

thanks a lot for your effort. Looks great to me!

On May 14, 2013, at 12:38 PM, Simone Tripodi wrote:

> Hi all mates,
>=20
> while providing some help in JWT, I noticed that the model shares a
> common "pattern" with commons library (and with the OAuth1.a
> implementation I was trying to give at the Amber early days):
>=20
> * each model has known, established set of parameters/fields;
> * each model has an auxiliary set of parameters;
> * each model should be immutable;
> * each model requires a Builder to be built;
> * each model requires validation of required/optional fields;
> * each model could have the need to be (un)marshalled from/to JSON;
> * each model could have the need to be (un)marshalled from/to
> x-www-form-urlencoded;
>=20
> I think we all agree that doing that work for each model is a boring,
> redundant task, indeed the actual codebase brings a set of utilities
> to work with JSON format, by parsing json string to json object of
> jettison library, access and get to model properties by name...
> In JWT I tried to adopt a different approach, where known properties
> are not referred by name but by Builder setters and entity getters,
> JSON (un)marshalling by properties names.
>=20
> So, since adopting that pattern in all model entity could be
> time-consuming and repetitively boring, in my public whiteboard[1],
> taking inspiration from Codehaus Modello[2] (the tool used by Maven to
> generate the domain model), I started experimenting a KISS approach to
> generate all that boilerplate code.
> What I achieved is that, given a set of model properties, such as the
> JWT ClaimsSet[3] I can obtain a complete immutable POJO, with nested
> Builder, and json marshaller/unmarshaller, built on top of Jackson
> StAX-alike APIs. You can see the result on this gist[4].
>=20


I definitely like this "builder" approach as you have done in JWT.=20


> So, there is enough space IMHO ti discuss the different options:
>=20
> 1) generate the entities at built-time, package them in an artifact
> and deploying it;
>=20
> OR
>=20
> 2) generate the entities "offline" and commit them where it is required;

My +1 goes here. I'd rally prefer to keep to have the java files (no matter=
 is autogenerated).

>=20
> OR
>=20
> 3) ignore all of that and going ahead as is.
>=20
> WDYT?


Another think I would "tackle" in our client side API is simplifying a bit =
the usage.
Taking as example the server side flow as in [5] I think that we should sim=
plify the building of the Authorization Request and the Token Endpoint requ=
est.

What I would suggest, but I will open a different thread is to do our first=
 Oltu release with the current codebase and after that start with new impro=
vements.

Regards

Antonio

[5] https://cwiki.apache.org/confluence/display/OLTU/OAuth+2.0+Client+Quick=
start


> best,
> -Simo
>=20
> [1] http://svn.apache.org/repos/asf/oltu/whiteboard/simonetripodi/oltu-co=
mmons/
> [2] http://modello.codehaus.org/index.html
> [3] http://svn.apache.org/repos/asf/oltu/whiteboard/simonetripodi/oltu-co=
mmons/src/main/mdo/org/apache/oltu/jwt/ClaimsSet.xml
> [4] https://gist.github.com/anonymous/5574938
>=20
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/