Administrator
|
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 |
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 > > > > |
Administrator
|
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 > > > > > > > > > |
Administrator
|
In reply to this post by Romain Manni-Bucau
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 >> >> >> >> |
Administrator
|
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 > >> > >> > >> > >> > > |
In reply to this post by Mark Struberg
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 > >> > >> > >> > >> > > |
Administrator
|
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 >>>> >>>> >>>> >>>> >> >> |
In reply to this post by Mark Struberg
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 |
Administrator
|
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 > > > |
Administrator
|
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 >> >> >> > |
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 >>> >>> >>> >> > |
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> |
Administrator
|
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> |
Free forum by Nabble | Edit this page |