[DISCUSS] EJB container as CDI Extension

[Mark Struberg]

Hi folks!

Yesterday I gave a presentation about CDI and testing.
It’s still pretty hard and costly to test projects which use EJBs in business projects as Arquillian is not a good fit for those most of the times.
And once again the idea popped up that it would be easy to just start a CDI container and use portable Extensions to ‚re-route‘ @Stateless, @Singleton etc and implement them as CDI features. Same could be done for @Asynchronous etc.
The Transaction handling could be done by dynamically adding @Transactional with a @TransactionScoped EntityManager
@Resource etc injection could be handled via Extensions as well.

This is NOT an attempt to implement a fully fledged and compatible EJB server. This is purely intended for having a quick way to test EJB projects with a very fast bootstrap.
I know this has been done many times already, thus it’s finally time to start a joint effort imo ;)

Any ideas, feedback?

LieGrue,
strub

[Romain Manni-Bucau]

why not using openejb then? sounds it is already there.


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-12-11 10:20 GMT+01:00 Mark Struberg <[hidden email]>:

> Hi folks!
>
> Yesterday I gave a presentation about CDI and testing.
> It’s still pretty hard and costly to test projects which use EJBs in
> business projects as Arquillian is not a good fit for those most of the
> times.
> And once again the idea popped up that it would be easy to just start a
> CDI container and use portable Extensions to ‚re-route‘ @Stateless,
> @Singleton etc and implement them as CDI features. Same could be done for
> @Asynchronous etc.
> The Transaction handling could be done by dynamically adding
> @Transactional with a @TransactionScoped EntityManager
> @Resource etc injection could be handled via Extensions as well.
>
> This is NOT an attempt to implement a fully fledged and compatible EJB
> server. This is purely intended for having a quick way to test EJB projects
> with a very fast bootstrap.
> I know this has been done many times already, thus it’s finally time to
> start a joint effort imo ;)
>
> Any ideas, feedback?
>
> LieGrue,
> strub
>
>
>
>

[Gerhard Petracek]

hi @ all,

i agree with romain - with deltaspike-cdictrl-openejb (+ CdiTestRunner)
it's easy to do that (see e.g. [1]).

regards,
gerhard

[1] https://github.com/os890/ee6-ds-demo



2015-12-11 10:38 GMT+01:00 Romain Manni-Bucau <[hidden email]>:

> why not using openejb then? sounds it is already there.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-12-11 10:20 GMT+01:00 Mark Struberg <[hidden email]>:
>
> > Hi folks!
> >
> > Yesterday I gave a presentation about CDI and testing.
> > It’s still pretty hard and costly to test projects which use EJBs in
> > business projects as Arquillian is not a good fit for those most of the
> > times.
> > And once again the idea popped up that it would be easy to just start a
> > CDI container and use portable Extensions to ‚re-route‘ @Stateless,
> > @Singleton etc and implement them as CDI features. Same could be done for
> > @Asynchronous etc.
> > The Transaction handling could be done by dynamically adding
> > @Transactional with a @TransactionScoped EntityManager
> > @Resource etc injection could be handled via Extensions as well.
> >
> > This is NOT an attempt to implement a fully fledged and compatible EJB
> > server. This is purely intended for having a quick way to test EJB
> projects
> > with a very fast bootstrap.
> > I know this has been done many times already, thus it’s finally time to
> > start a joint effort imo ;)
> >
> > Any ideas, feedback?
> >
> > LieGrue,
> > strub
> >
> >
> >
> >
>

[Mark Struberg]

Well there have been some JBoss users out there who asked for it.
Probably because JBoss STILL don’t support an embedded version of wildfly?
Or is there something we could use and finally add a cdictrl backend for them?

LieGrue,
strub

> Am 11.12.2015 um 10:38 schrieb Romain Manni-Bucau <[hidden email]>:
>
> why not using openejb then? sounds it is already there.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-12-11 10:20 GMT+01:00 Mark Struberg <[hidden email]>:
>
>> Hi folks!
>>
>> Yesterday I gave a presentation about CDI and testing.
>> It’s still pretty hard and costly to test projects which use EJBs in
>> business projects as Arquillian is not a good fit for those most of the
>> times.
>> And once again the idea popped up that it would be easy to just start a
>> CDI container and use portable Extensions to ‚re-route‘ @Stateless,
>> @Singleton etc and implement them as CDI features. Same could be done for
>> @Asynchronous etc.
>> The Transaction handling could be done by dynamically adding
>> @Transactional with a @TransactionScoped EntityManager
>> @Resource etc injection could be handled via Extensions as well.
>>
>> This is NOT an attempt to implement a fully fledged and compatible EJB
>> server. This is purely intended for having a quick way to test EJB projects
>> with a very fast bootstrap.
>> I know this has been done many times already, thus it’s finally time to
>> start a joint effort imo ;)
>>
>> Any ideas, feedback?
>>
>> LieGrue,
>> strub
>>
>>
>>
>>

[Gerhard Petracek]

hi mark,

imo the chance that you create useful tests with openejb is way higher
(independent of the server used for the real application).
what you suggest is what we used several years ago.
(back then there was nothing like deltaspike-cdictrl-openejb +
CdiTestRunner -> back then it was way better than the other alternatives,
but you had to pay attention to several limitations. today it doesn't make
a lot of sense to use those old workarounds any longer.)

regards,
gerhard



2015-12-11 13:15 GMT+01:00 Mark Struberg <[hidden email]>:

> Well there have been some JBoss users out there who asked for it.
> Probably because JBoss STILL don’t support an embedded version of wildfly?
> Or is there something we could use and finally add a cdictrl backend for
> them?
>
> LieGrue,
> strub
>
>
> > Am 11.12.2015 um 10:38 schrieb Romain Manni-Bucau <[hidden email]
> >:
> >
> > why not using openejb then? sounds it is already there.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com>
> >
> > 2015-12-11 10:20 GMT+01:00 Mark Struberg <[hidden email]>:
> >
> >> Hi folks!
> >>
> >> Yesterday I gave a presentation about CDI and testing.
> >> It’s still pretty hard and costly to test projects which use EJBs in
> >> business projects as Arquillian is not a good fit for those most of the
> >> times.
> >> And once again the idea popped up that it would be easy to just start a
> >> CDI container and use portable Extensions to ‚re-route‘ @Stateless,
> >> @Singleton etc and implement them as CDI features. Same could be done
> for
> >> @Asynchronous etc.
> >> The Transaction handling could be done by dynamically adding
> >> @Transactional with a @TransactionScoped EntityManager
> >> @Resource etc injection could be handled via Extensions as well.
> >>
> >> This is NOT an attempt to implement a fully fledged and compatible EJB
> >> server. This is purely intended for having a quick way to test EJB
> projects
> >> with a very fast bootstrap.
> >> I know this has been done many times already, thus it’s finally time to
> >> start a joint effort imo ;)
> >>
> >> Any ideas, feedback?
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>
>
>

[Romain Manni-Bucau]

JBoss should have EJBContainer as well. That said how the initial proposal
- reimplementing if I understood - solves the JBoss users need better than
using openejb?


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2015-12-11 13:15 GMT+01:00 Mark Struberg <[hidden email]>:

> Well there have been some JBoss users out there who asked for it.
> Probably because JBoss STILL don’t support an embedded version of wildfly?
> Or is there something we could use and finally add a cdictrl backend for
> them?
>
> LieGrue,
> strub
>
>
> > Am 11.12.2015 um 10:38 schrieb Romain Manni-Bucau <[hidden email]
> >:
> >
> > why not using openejb then? sounds it is already there.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com>
> >
> > 2015-12-11 10:20 GMT+01:00 Mark Struberg <[hidden email]>:
> >
> >> Hi folks!
> >>
> >> Yesterday I gave a presentation about CDI and testing.
> >> It’s still pretty hard and costly to test projects which use EJBs in
> >> business projects as Arquillian is not a good fit for those most of the
> >> times.
> >> And once again the idea popped up that it would be easy to just start a
> >> CDI container and use portable Extensions to ‚re-route‘ @Stateless,
> >> @Singleton etc and implement them as CDI features. Same could be done
> for
> >> @Asynchronous etc.
> >> The Transaction handling could be done by dynamically adding
> >> @Transactional with a @TransactionScoped EntityManager
> >> @Resource etc injection could be handled via Extensions as well.
> >>
> >> This is NOT an attempt to implement a fully fledged and compatible EJB
> >> server. This is purely intended for having a quick way to test EJB
> projects
> >> with a very fast bootstrap.
> >> I know this has been done many times already, thus it’s finally time to
> >> start a joint effort imo ;)
> >>
> >> Any ideas, feedback?
> >>
> >> LieGrue,
> >> strub
> >>
> >>
> >>
> >>
>
>

[Mark Struberg]

I agree and had the same arguments. Especially as Weld-embedded behaves totally different than Wildfly when it comes to BDAs. And this is actually the main functional difference between Weld and OWB used in OpenEJB.
In that regard it btw also doesn’t help to test with Arquillian in my experience. Not sure what to tell them…

LieGrue,
strub

> Am 11.12.2015 um 14:01 schrieb Romain Manni-Bucau <[hidden email]>:
>
> JBoss should have EJBContainer as well. That said how the initial proposal
> - reimplementing if I understood - solves the JBoss users need better than
> using openejb?
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-12-11 13:15 GMT+01:00 Mark Struberg <[hidden email]>:
>
>> Well there have been some JBoss users out there who asked for it.
>> Probably because JBoss STILL don’t support an embedded version of wildfly?
>> Or is there something we could use and finally add a cdictrl backend for
>> them?
>>
>> LieGrue,
>> strub
>>
>>
>>> Am 11.12.2015 um 10:38 schrieb Romain Manni-Bucau <[hidden email]
>>> :
>>>
>>> why not using openejb then? sounds it is already there.
>>>
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>>> <http://rmannibucau.wordpress.com> | Github <
>> https://github.com/rmannibucau> |
>>> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>> <http://www.tomitribe.com>
>>>
>>> 2015-12-11 10:20 GMT+01:00 Mark Struberg <[hidden email]>:
>>>
>>>> Hi folks!
>>>>
>>>> Yesterday I gave a presentation about CDI and testing.
>>>> It’s still pretty hard and costly to test projects which use EJBs in
>>>> business projects as Arquillian is not a good fit for those most of the
>>>> times.
>>>> And once again the idea popped up that it would be easy to just start a
>>>> CDI container and use portable Extensions to ‚re-route‘ @Stateless,
>>>> @Singleton etc and implement them as CDI features. Same could be done
>> for
>>>> @Asynchronous etc.
>>>> The Transaction handling could be done by dynamically adding
>>>> @Transactional with a @TransactionScoped EntityManager
>>>> @Resource etc injection could be handled via Extensions as well.
>>>>
>>>> This is NOT an attempt to implement a fully fledged and compatible EJB
>>>> server. This is purely intended for having a quick way to test EJB
>> projects
>>>> with a very fast bootstrap.
>>>> I know this has been done many times already, thus it’s finally time to
>>>> start a joint effort imo ;)
>>>>
>>>> Any ideas, feedback?
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>>
>>>>
>>
>>

[Harald Wellmann]

Am 11.12.2015 um 13:15 schrieb Mark Struberg:
> Probably because JBoss STILL don’t support an embedded version of wildfly?

There *is* an embedded version of WildFly:
org.wildfly.core.embedded.EmbeddedServerFactory.

This is used e.g. by the Pax Exam WildFly test container, another method
to test EJB + CDI + anything else from Java EE stack in an embedded
environment.

Regards,

Harald

[Mark Struberg]

Thanks Harald!
I also got in touch with Ken Wills from JBoss and Rafael and I will try to make a cdictrl backend real.

LieGrue,
strub

> Am 11.12.2015 um 19:42 schrieb Harald Wellmann <[hidden email]>:
>
> Am 11.12.2015 um 13:15 schrieb Mark Struberg:
>> Probably because JBoss STILL don’t support an embedded version of wildfly?
>
> There *is* an embedded version of WildFly: org.wildfly.core.embedded.EmbeddedServerFactory.
>
> This is used e.g. by the Pax Exam WildFly test container, another method to test EJB + CDI + anything else from Java EE stack in an embedded environment.
>
> Regards,
>
> Harald
>
>
>

[Mark Struberg]

Oh, when I think about it…

Would you have an hour to hack this? We could also do a hangout session and kind of pair programming with you Rafael and I (and whoever likes to join).
The problem we face at the moment is that the code we got pointed to by the wildfly team is obviously LGPL. So we cannot just take it and use it for DeltaSpike.
This would first require a formal grant from JBoss, etc. And while I’m pretty sure they would not object - it is still some days of work to get the paperwork sorted…

Would be easier if you would help us as your pax integration is ALv2 already?

LieGrue,
strub

> Am 11.12.2015 um 19:47 schrieb Mark Struberg <[hidden email]>:
>
> Thanks Harald!
> I also got in touch with Ken Wills from JBoss and Rafael and I will try to make a cdictrl backend real.
>
> LieGrue,
> strub
>
>
>> Am 11.12.2015 um 19:42 schrieb Harald Wellmann <[hidden email]>:
>>
>> Am 11.12.2015 um 13:15 schrieb Mark Struberg:
>>> Probably because JBoss STILL don’t support an embedded version of wildfly?
>>
>> There *is* an embedded version of WildFly: org.wildfly.core.embedded.EmbeddedServerFactory.
>>
>> This is used e.g. by the Pax Exam WildFly test container, another method to test EJB + CDI + anything else from Java EE stack in an embedded environment.
>>
>> Regards,
>>
>> Harald
>>
>>
>>
>

[Harald Wellmann]

I'm afraid I won't have a lot of spare time for coding before Christmas,
and I'm not much of an authority on WildFly Embedded either, I'm just
using it a lot (via Pax Exam) for most integration tests of my daytime
projects.

Have a look at [1] for the Pax Exam WildFly Container - if there are any
questions on that, I'm happy to help.

Yes, Pax Exam is ASLv2, so you can copy and reuse whatever you like.

Once you start coding on a branch or fork, just send me a link...

[1]
https://github.com/ops4j/org.ops4j.pax.exam2/blob/exam-reactor-4.7.0/containers/pax-exam-container-wildfly90/src/main/java/org/ops4j/pax/exam/wildfly90/WildFly90TestContainer.java

Regards,
Harald


Am 11.12.2015 um 19:56 schrieb Mark Struberg:

> Oh, when I think about it…
>
> Would you have an hour to hack this? We could also do a hangout session and kind of pair programming with you Rafael and I (and whoever likes to join).
> The problem we face at the moment is that the code we got pointed to by the wildfly team is obviously LGPL. So we cannot just take it and use it for DeltaSpike.
> This would first require a formal grant from JBoss, etc. And while I’m pretty sure they would not object - it is still some days of work to get the paperwork sorted…
>
> Would be easier if you would help us as your pax integration is ALv2 already?
>
> LieGrue,
> strub
>
>
>> Am 11.12.2015 um 19:47 schrieb Mark Struberg <[hidden email]>:
>>
>> Thanks Harald!
>> I also got in touch with Ken Wills from JBoss and Rafael and I will try to make a cdictrl backend real.
>>
>> LieGrue,
>> strub
>>
>>
>>> Am 11.12.2015 um 19:42 schrieb Harald Wellmann <[hidden email]>:
>>>
>>> Am 11.12.2015 um 13:15 schrieb Mark Struberg:
>>>> Probably because JBoss STILL don’t support an embedded version of wildfly?
>>>
>>> There *is* an embedded version of WildFly: org.wildfly.core.embedded.EmbeddedServerFactory.
>>>
>>> This is used e.g. by the Pax Exam WildFly test container, another method to test EJB + CDI + anything else from Java EE stack in an embedded environment.
>>>
>>> Regards,
>>>
>>> Harald
>>>
>>>
>>>
>>
>

[Rafael Pestano]

Hi Mark,

Although i'm not an expert in the area I'm also interested in this, if I
could help some how (e.g write deltaspike example tests using the new
integration) just let me know.

2015-12-11 17:25 GMT-02:00 Harald Wellmann <[hidden email]>:

> I'm afraid I won't have a lot of spare time for coding before Christmas,
> and I'm not much of an authority on WildFly Embedded either, I'm just using
> it a lot (via Pax Exam) for most integration tests of my daytime projects.
>
> Have a look at [1] for the Pax Exam WildFly Container - if there are any
> questions on that, I'm happy to help.
>
> Yes, Pax Exam is ASLv2, so you can copy and reuse whatever you like.
>
> Once you start coding on a branch or fork, just send me a link...
>
> [1]
> https://github.com/ops4j/org.ops4j.pax.exam2/blob/exam-reactor-4.7.0/containers/pax-exam-container-wildfly90/src/main/java/org/ops4j/pax/exam/wildfly90/WildFly90TestContainer.java
>
> Regards,
> Harald
>
>
>
> Am 11.12.2015 um 19:56 schrieb Mark Struberg:
>
>> Oh, when I think about it…
>>
>> Would you have an hour to hack this? We could also do a hangout session
>> and kind of pair programming with you Rafael and I (and whoever likes to
>> join).
>> The problem we face at the moment is that the code we got pointed to by
>> the wildfly team is obviously LGPL. So we cannot just take it and use it
>> for DeltaSpike.
>> This would first require a formal grant from JBoss, etc. And while I’m
>> pretty sure they would not object - it is still some days of work to get
>> the paperwork sorted…
>>
>> Would be easier if you would help us as your pax integration is ALv2
>> already?
>>
>> LieGrue,
>> strub
>>
>>
>> Am 11.12.2015 um 19:47 schrieb Mark Struberg <[hidden email]>:
>>>
>>> Thanks Harald!
>>> I also got in touch with Ken Wills from JBoss and Rafael and I will try
>>> to make a cdictrl backend real.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>> Am 11.12.2015 um 19:42 schrieb Harald Wellmann <[hidden email]>:
>>>>
>>>> Am 11.12.2015 um 13:15 schrieb Mark Struberg:
>>>>
>>>>> Probably because JBoss STILL don’t support an embedded version of
>>>>> wildfly?
>>>>>
>>>>
>>>> There *is* an embedded version of WildFly:
>>>> org.wildfly.core.embedded.EmbeddedServerFactory.
>>>>
>>>> This is used e.g. by the Pax Exam WildFly test container, another
>>>> method to test EJB + CDI + anything else from Java EE stack in an embedded
>>>> environment.
>>>>
>>>> Regards,
>>>>
>>>> Harald
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

--
<http://www.advancedit.com.br/>Att,

Rafael M. Pestano

Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul
http://rpestano.wordpress.com/
@realpestano <https://twitter.com/realpestano>

[Mark Struberg]

Sure, thanks!
And thanks Harald, totally understand.
Next step will be to check what parts we can reuse from JBoss. Rafael Benevides is working on that.

LieGrue,
strub

> Am 13.12.2015 um 13:42 schrieb Rafael Pestano <[hidden email]>:
>
> Hi Mark,
>
> Although i'm not an expert in the area I'm also interested in this, if I
> could help some how (e.g write deltaspike example tests using the new
> integration) just let me know.
>
> 2015-12-11 17:25 GMT-02:00 Harald Wellmann <[hidden email]>:
>
>> I'm afraid I won't have a lot of spare time for coding before Christmas,
>> and I'm not much of an authority on WildFly Embedded either, I'm just using
>> it a lot (via Pax Exam) for most integration tests of my daytime projects.
>>
>> Have a look at [1] for the Pax Exam WildFly Container - if there are any
>> questions on that, I'm happy to help.
>>
>> Yes, Pax Exam is ASLv2, so you can copy and reuse whatever you like.
>>
>> Once you start coding on a branch or fork, just send me a link...
>>
>> [1]
>> https://github.com/ops4j/org.ops4j.pax.exam2/blob/exam-reactor-4.7.0/containers/pax-exam-container-wildfly90/src/main/java/org/ops4j/pax/exam/wildfly90/WildFly90TestContainer.java
>>
>> Regards,
>> Harald
>>
>>
>>
>> Am 11.12.2015 um 19:56 schrieb Mark Struberg:
>>
>>> Oh, when I think about it…
>>>
>>> Would you have an hour to hack this? We could also do a hangout session
>>> and kind of pair programming with you Rafael and I (and whoever likes to
>>> join).
>>> The problem we face at the moment is that the code we got pointed to by
>>> the wildfly team is obviously LGPL. So we cannot just take it and use it
>>> for DeltaSpike.
>>> This would first require a formal grant from JBoss, etc. And while I’m
>>> pretty sure they would not object - it is still some days of work to get
>>> the paperwork sorted…
>>>
>>> Would be easier if you would help us as your pax integration is ALv2
>>> already?
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>> Am 11.12.2015 um 19:47 schrieb Mark Struberg <[hidden email]>:
>>>>
>>>> Thanks Harald!
>>>> I also got in touch with Ken Wills from JBoss and Rafael and I will try
>>>> to make a cdictrl backend real.
>>>>
>>>> LieGrue,
>>>> strub
>>>>
>>>>
>>>> Am 11.12.2015 um 19:42 schrieb Harald Wellmann <[hidden email]>:
>>>>>
>>>>> Am 11.12.2015 um 13:15 schrieb Mark Struberg:
>>>>>
>>>>>> Probably because JBoss STILL don’t support an embedded version of
>>>>>> wildfly?
>>>>>>
>>>>>
>>>>> There *is* an embedded version of WildFly:
>>>>> org.wildfly.core.embedded.EmbeddedServerFactory.
>>>>>
>>>>> This is used e.g. by the Pax Exam WildFly test container, another
>>>>> method to test EJB + CDI + anything else from Java EE stack in an embedded
>>>>> environment.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Harald
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
> --
> <http://www.advancedit.com.br/>Att,
>
> Rafael M. Pestano
>
> Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul
> http://rpestano.wordpress.com/
> @realpestano <https://twitter.com/realpestano>