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. > > 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 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. Regards Antonio [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/
