oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Sanso <asa...@adobe.com>
Subject Re: An experimental approach for domain models
Date Wed, 15 May 2013 12:13:26 GMT
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,
> 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):
> * 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;
> 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.
> 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].

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

> So, there is enough space IMHO ti discuss the different options:
> 1) generate the entities at built-time, package them in an artifact
> and deploying it;
> OR
> 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).

> OR
> 3) ignore all of that and going ahead as is.

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 simplify the building
of the Authorization Request and the Token Endpoint request.

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 improvements.



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

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

View raw message