Re: [DISCUSS] EJB container as CDI Extension

[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 :

> 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 :
>>>
>>> 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 :

 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




>>>
>>
>


-- 
Att,

Rafael M. Pestano

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

Re: [DISCUSS] EJB container as CDI Extension

[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 :
> 
> 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 :
> 
>> 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 :
 
 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 :
> 
> 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
> 
> 
> 
> 
 
>>> 
>> 
> 
> 
> -- 
> Att,
> 
> Rafael M. Pestano
> 
> Desenvolvedor Java Cia. de Processamento de Dados do Rio Grande do Sul
> http://rpestano.wordpress.com/
> @realpestano 

Re: [DISCUSS] EJB container as CDI Extension

[Romain Manni-Bucau]

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


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Github  |
LinkedIn  | Tomitriber


2015-12-11 10:20 GMT+01:00 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
>
>
>
>

Re: [DISCUSS] EJB container as CDI Extension

[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 :

> why not using openejb then? sounds it is already there.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Tomitriber
> 
>
> 2015-12-11 10:20 GMT+01:00 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
> >
> >
> >
> >
>

Re: [DISCUSS] EJB container as CDI Extension

[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  |  Blog
 | Github  |
LinkedIn  | Tomitriber


2015-12-11 13:15 GMT+01:00 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  >:
> >
> > why not using openejb then? sounds it is already there.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Tomitriber
> > 
> >
> > 2015-12-11 10:20 GMT+01:00 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
> >>
> >>
> >>
> >>
>
>

Re: [DISCUSS] EJB container as CDI Extension

[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 :

> 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  >:
> >
> > why not using openejb then? sounds it is already there.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Github <
> https://github.com/rmannibucau> |
> > LinkedIn  | Tomitriber
> > 
> >
> > 2015-12-11 10:20 GMT+01:00 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
> >>
> >>
> >>
> >>
>
>

Re: [DISCUSS] EJB container as CDI Extension

[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 :
> 
> 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  |  Blog
>  | Github  |
> LinkedIn  | Tomitriber
> 
> 
> 2015-12-11 13:15 GMT+01:00 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 >> :
>>> 
>>> why not using openejb then? sounds it is already there.
>>> 
>>> 
>>> Romain Manni-Bucau
>>> @rmannibucau  |  Blog
>>>  | Github <
>> https://github.com/rmannibucau> |
>>> LinkedIn  | Tomitriber
>>> 
>>> 
>>> 2015-12-11 10:20 GMT+01:00 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
 
 
 
 
>> 
>> 

[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

Re: [DISCUSS] EJB container as CDI Extension

[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 :

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 :

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

Re: [DISCUSS] EJB container as CDI Extension

[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 :
> 
> 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
> 
> 
> 

Re: [DISCUSS] EJB container as CDI Extension

[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 :
> 
> 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 :
>> 
>> 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
>> 
>> 
>> 
> 

Re: [DISCUSS] EJB container as CDI Extension

[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