[DISCUSS] CDI Backed Client Library for Artemis

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] CDI Backed Client Library for Artemis

John D. Ament-2
All,

I wanted to run this POC by you guys to see your thoughts.  Obviously I
have a mixed background at this point, so it kind of makes sense to bring
two of my interests together.  I started hacking together a CDI backed
client against Artemis Core/JMS.  Looking at Artemis and its integrations
with Vert.x, Aerogear and Spring, it makes sense to support another
runtime.  In addition, the JMS 2 spec mandates support for some injection
points via CDI.  I wanted to take it a step further.

- If running locally, bootstrap an embedded server.
- Connect to a locally running server, or a configured remote cluster.
- Provide some injection points to work with said server (e.g.
ConnectionFactory, JMSContext)

I wouldn't call it complete, but I've created a simple POC that does these
things, which you can find at
https://github.com/johnament/activemq-artemis/commit/8430136d9ea648a1f089747da434d945de1d7fa2
I still want to add some XA support, but even this adds a huge step forward
to be able to connect a simple local process to a remote server, without
needing full containers to do injection points.

So what do you guys think? Worth adding to Artemis?

John
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] CDI Backed Client Library for Artemis

John D. Ament-2
Sorry, meant to link here -
https://github.com/johnament/activemq-artemis/tree/cdi-client

John

On Sun, Jul 31, 2016 at 11:09 PM John D. Ament <[hidden email]>
wrote:

> All,
>
> I wanted to run this POC by you guys to see your thoughts.  Obviously I
> have a mixed background at this point, so it kind of makes sense to bring
> two of my interests together.  I started hacking together a CDI backed
> client against Artemis Core/JMS.  Looking at Artemis and its integrations
> with Vert.x, Aerogear and Spring, it makes sense to support another
> runtime.  In addition, the JMS 2 spec mandates support for some injection
> points via CDI.  I wanted to take it a step further.
>
> - If running locally, bootstrap an embedded server.
> - Connect to a locally running server, or a configured remote cluster.
> - Provide some injection points to work with said server (e.g.
> ConnectionFactory, JMSContext)
>
> I wouldn't call it complete, but I've created a simple POC that does these
> things, which you can find at
> https://github.com/johnament/activemq-artemis/commit/8430136d9ea648a1f089747da434d945de1d7fa2
> I still want to add some XA support, but even this adds a huge step
> forward to be able to connect a simple local process to a remote server,
> without needing full containers to do injection points.
>
> So what do you guys think? Worth adding to Artemis?
>
> John
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] CDI Backed Client Library for Artemis

clebertsuconic
Looks really nice.. Very well done.

There is a test Dejan wrote for CDI called
org.apache.activemq.artemis.tests.integration.kara.ArtemisFeatureTest

Can you verify the test still works?


And how this would affect that Karaf integration?


@Dejan can you take a look given you did a lot of work with this before?

On Sun, Jul 31, 2016 at 11:11 PM, John D. Ament <[hidden email]> wrote:

> Sorry, meant to link here -
> https://github.com/johnament/activemq-artemis/tree/cdi-client
>
> John
>
> On Sun, Jul 31, 2016 at 11:09 PM John D. Ament <[hidden email]>
> wrote:
>
>> All,
>>
>> I wanted to run this POC by you guys to see your thoughts.  Obviously I
>> have a mixed background at this point, so it kind of makes sense to bring
>> two of my interests together.  I started hacking together a CDI backed
>> client against Artemis Core/JMS.  Looking at Artemis and its integrations
>> with Vert.x, Aerogear and Spring, it makes sense to support another
>> runtime.  In addition, the JMS 2 spec mandates support for some injection
>> points via CDI.  I wanted to take it a step further.
>>
>> - If running locally, bootstrap an embedded server.
>> - Connect to a locally running server, or a configured remote cluster.
>> - Provide some injection points to work with said server (e.g.
>> ConnectionFactory, JMSContext)
>>
>> I wouldn't call it complete, but I've created a simple POC that does these
>> things, which you can find at
>> https://github.com/johnament/activemq-artemis/commit/8430136d9ea648a1f089747da434d945de1d7fa2
>> I still want to add some XA support, but even this adds a huge step
>> forward to be able to connect a simple local process to a remote server,
>> without needing full containers to do injection points.
>>
>> So what do you guys think? Worth adding to Artemis?
>>
>> John
>>



--
Clebert Suconic
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] CDI Backed Client Library for Artemis

John D. Ament-2
That test looks like its focused on Karaf (OSGi) integration.  Definitely
something that should be there.  There's one guy I know who does OSGi and
CDI really well, but the market just isn't there.  Both leverage JSR-330
(AtInject) but ultimately are two different service models.

This being its own JAR shouldn't impact any of that.

John

On Mon, Aug 1, 2016 at 10:16 AM Clebert Suconic <[hidden email]>
wrote:

> Looks really nice.. Very well done.
>
> There is a test Dejan wrote for CDI called
> org.apache.activemq.artemis.tests.integration.kara.ArtemisFeatureTest
>
> Can you verify the test still works?
>
>
> And how this would affect that Karaf integration?
>
>
> @Dejan can you take a look given you did a lot of work with this before?
>
> On Sun, Jul 31, 2016 at 11:11 PM, John D. Ament <[hidden email]>
> wrote:
> > Sorry, meant to link here -
> > https://github.com/johnament/activemq-artemis/tree/cdi-client
> >
> > John
> >
> > On Sun, Jul 31, 2016 at 11:09 PM John D. Ament <[hidden email]>
> > wrote:
> >
> >> All,
> >>
> >> I wanted to run this POC by you guys to see your thoughts.  Obviously I
> >> have a mixed background at this point, so it kind of makes sense to
> bring
> >> two of my interests together.  I started hacking together a CDI backed
> >> client against Artemis Core/JMS.  Looking at Artemis and its
> integrations
> >> with Vert.x, Aerogear and Spring, it makes sense to support another
> >> runtime.  In addition, the JMS 2 spec mandates support for some
> injection
> >> points via CDI.  I wanted to take it a step further.
> >>
> >> - If running locally, bootstrap an embedded server.
> >> - Connect to a locally running server, or a configured remote cluster.
> >> - Provide some injection points to work with said server (e.g.
> >> ConnectionFactory, JMSContext)
> >>
> >> I wouldn't call it complete, but I've created a simple POC that does
> these
> >> things, which you can find at
> >>
> https://github.com/johnament/activemq-artemis/commit/8430136d9ea648a1f089747da434d945de1d7fa2
> >> I still want to add some XA support, but even this adds a huge step
> >> forward to be able to connect a simple local process to a remote server,
> >> without needing full containers to do injection points.
> >>
> >> So what do you guys think? Worth adding to Artemis?
> >>
> >> John
> >>
>
>
>
> --
> Clebert Suconic
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] CDI Backed Client Library for Artemis

dejanb
Hi guys,

I’m heading out for vacation in an hour, so I won’t be able to take a look
at it immediately. I’ll dig into it as soon as I’m back. But, yeah this is
a completely new integration, so it won’t affect any of the existing stuff.


Regards
--
Dejan Bosanac
http://sensatic.net/about

On Mon, Aug 1, 2016 at 4:24 PM, John D. Ament <[hidden email]> wrote:

> That test looks like its focused on Karaf (OSGi) integration.  Definitely
> something that should be there.  There's one guy I know who does OSGi and
> CDI really well, but the market just isn't there.  Both leverage JSR-330
> (AtInject) but ultimately are two different service models.
>
> This being its own JAR shouldn't impact any of that.
>
> John
>
> On Mon, Aug 1, 2016 at 10:16 AM Clebert Suconic <[hidden email]
> >
> wrote:
>
> > Looks really nice.. Very well done.
> >
> > There is a test Dejan wrote for CDI called
> > org.apache.activemq.artemis.tests.integration.kara.ArtemisFeatureTest
> >
> > Can you verify the test still works?
> >
> >
> > And how this would affect that Karaf integration?
> >
> >
> > @Dejan can you take a look given you did a lot of work with this before?
> >
> > On Sun, Jul 31, 2016 at 11:11 PM, John D. Ament <[hidden email]>
> > wrote:
> > > Sorry, meant to link here -
> > > https://github.com/johnament/activemq-artemis/tree/cdi-client
> > >
> > > John
> > >
> > > On Sun, Jul 31, 2016 at 11:09 PM John D. Ament <[hidden email]>
> > > wrote:
> > >
> > >> All,
> > >>
> > >> I wanted to run this POC by you guys to see your thoughts.  Obviously
> I
> > >> have a mixed background at this point, so it kind of makes sense to
> > bring
> > >> two of my interests together.  I started hacking together a CDI backed
> > >> client against Artemis Core/JMS.  Looking at Artemis and its
> > integrations
> > >> with Vert.x, Aerogear and Spring, it makes sense to support another
> > >> runtime.  In addition, the JMS 2 spec mandates support for some
> > injection
> > >> points via CDI.  I wanted to take it a step further.
> > >>
> > >> - If running locally, bootstrap an embedded server.
> > >> - Connect to a locally running server, or a configured remote cluster.
> > >> - Provide some injection points to work with said server (e.g.
> > >> ConnectionFactory, JMSContext)
> > >>
> > >> I wouldn't call it complete, but I've created a simple POC that does
> > these
> > >> things, which you can find at
> > >>
> >
> https://github.com/johnament/activemq-artemis/commit/8430136d9ea648a1f089747da434d945de1d7fa2
> > >> I still want to add some XA support, but even this adds a huge step
> > >> forward to be able to connect a simple local process to a remote
> server,
> > >> without needing full containers to do injection points.
> > >>
> > >> So what do you guys think? Worth adding to Artemis?
> > >>
> > >> John
> > >>
> >
> >
> >
> > --
> > Clebert Suconic
> >
>