You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oltu.apache.org by Simone Tripodi <si...@apache.org> on 2013/05/14 12:38:48 UTC
An experimental approach for domain models
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].
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;
OR
3) ignore all of that and going ahead as is.
WDYT?
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/
Re: An experimental approach for domain models
Posted by Tommaso Teofili <to...@gmail.com>.
Hi Simo, all,
2013/5/14 Simone Tripodi <si...@apache.org>
> 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].
>
it looks awesome! :)
>
> 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;
>
>
I'm ok with both 1 and 2, usually I prefer 1 but I can understand 2 is
probably simpler and more immediate for newcomers to undersand where all
the stuff is :)
> OR
>
> 3) ignore all of that and going ahead as is.
>
> WDYT?
>
Great job (as usual) !
Thanks,
Tommaso
> 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/
>
Re: An experimental approach for domain models
Posted by Stein Welberg <st...@innovation-district.com>.
Hi Guys,
My 2 cents, see inline.
On 15 mei 2013, at 14:13, Antonio Sanso <as...@adobe.com> wrote:
> 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.
I like it too. reads easier.
>
>
>> 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 auto generated).
I agree with Antionio that it is better to have the java files. so +1 :)
>
>>
>> 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.
I agree.
I would also like to suggest a server side implementation that is even further "done" out of the box. Now there is still A LOT of room for spec incompatibilities and vulnerabilities. I think we could present the community with two flavors of Oltu:
1. Hardcore Oltu: OAuthTokenRequest class as is .This gives a lot of flexibility but also expects that the user reads the spec on how OAuth works.
2. Easy to use Oltu: A more grown solution which e.g. provides interfaces for the client and access token models. It delivers an abstract implementation of an OAuth Authorization server (the actual response creation still has to be done (so it's still compliant with both servlets or Jax-rs). There should be a number of abstract methods so it is easy to extent for instance the TokenResponse with additional attributes or to add support for your own custom grant type. This implementation will also use the OAuthTokenRequest under the hood but a developer has to have far less knowledge of OAuth to be able to create a spec compliant solution.
Regards,
Stein
>
> 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/
>
Re: An experimental approach for domain models
Posted by Antonio Sanso <as...@adobe.com>.
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/