You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Dominik Przybysz <al...@gmail.com> on 2017/04/05 17:18:10 UTC
OSGi and JMS
Hi,
Messaging is `must have` in microservices world, so...
Is there any framework for using JMS (or AMQP) with OSGi?
Do you think we should create something like jms-whiteboard in aries?
--
Pozdrawiam / Regards,
Dominik Przybysz
Re: OSGi and JMS
Posted by Christian Schneider <ch...@die-schneider.net>.
I agree.
On 06.04.2017 12:00, Dominik Przybysz wrote:
> The best option for me is to use whiteboard pattern for message consuming
> and inject sender service for sending messages.
>
> 2017-04-06 11:48 GMT+02:00 Guillaume Nodet <gn...@apache.org>:
>
>> I'm not really sure how your example really differs from the camel one:
>> http://camel.apache.org/pojo-messaging-example.html
>>
>> The main difference is that the Camel one is actually working, whereas
>> yours is just an idea.
>> I guess it depends if Dominik is looking at writing such an abstraction
>> layer or if he wants to use something in the short term.
>>
>>
>> 2017-04-06 9:02 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
>>
>>> I think we will need an abstraction for this. In my opinion it would be
>>> bad if the user code has to directly depend on camel.
>>> Some time ago I experimented a bit with an API for events. It is
>> unrelated
>>> to push streams though.
>>>
>>> See
>>> https://github.com/cschneider/typesafe-eventing
>>>
>>> The idea was to look into ways to abstract the process of sending and
>>> receiving type safe events. In the code the Starter does the plumbing but
>>> the idea is of course to let a DI framework do the plumbing.
>>>
>>> One idea is to use the java.util.function.Consumer interface for sending
>>> and receiving typesafe messages.
>>> In OSGi we could use something like this on the sender side:
>>>
>>> @Reference(filter="(topic=mytopic)")
>>> Consumer<Customer> sender;
>>>
>>> Even nicer would be something like:
>>> @Topic("mytopic")
>>> @Reference
>>> Consumer<Customer> sender;
>>>
>>> The user code would send simply by doing:
>>> sender.accept(customer)
>>>
>>> On the receiver side the obvious pattern would be:
>>> @Component(property="topic=mytopic")
>>> class MyReceiver implements Consumer<Customer> {
>>> public void accept(Customer customer) { ... };
>>> }
>>>
>>> I also experimented a bit with things like:
>>>
>>> class MyReceiver {
>>> @Transactional
>>> @Topic("mytopic")
>>> public void receive(Customer customer) { ... };
>>> }
>>>
>>> The problem with this approach is that it requires introspection and a
>>> injection framework that allows extensions and some kind of aop. So it
>>> would be less useful for DS but could be nice for CDI. It is also similar
>>> to eventing
>>> in plain CDI.
>>>
>>> Another question is of course how to combine this with push streams or
>>> another reactive programming model. I also think we need two levels of
>>> this. One level is a kind of whiteboard model based on OSGi services
>> which
>>> could be common for the whole platform. The other level is the
>> integration
>>> with different DI systems which could be different for DS, blueprint and
>>> CDI.
>>>
>>> To be honest I am not sure my approach is a good idea but I think it is
>>> important we discuss about different approaches to find a good solution.
>>>
>>> Christian
>>>
>>>
>>>
>>> On 06.04.2017 08:26, Guillaume Nodet wrote:
>>>
>>>> The PushStream is a streaming api. It focuses on defining a pipeline,
>> but
>>>> the implementation is not related to any distribution mechanism.
>>>>
>>>> If you want to send messages across VMs on your network, you really
>> should
>>>> focus on ActiveMQ.
>>>> There's no real OSGi specific facade I know of, so my best bet would be
>>>> Camel too, as others have said.
>>>> You can just show the minimum of camel, just what is needed to actually
>>>> consume the JMS message from a pojo or to send messages from a pojo.
>> You
>>>> don't have to look at everything Camel can do.
>>>>
>>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> http://www.talend.com
>>>
>>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>>
>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: OSGi and JMS
Posted by Dominik Przybysz <al...@gmail.com>.
The best option for me is to use whiteboard pattern for message consuming
and inject sender service for sending messages.
2017-04-06 11:48 GMT+02:00 Guillaume Nodet <gn...@apache.org>:
> I'm not really sure how your example really differs from the camel one:
> http://camel.apache.org/pojo-messaging-example.html
>
> The main difference is that the Camel one is actually working, whereas
> yours is just an idea.
> I guess it depends if Dominik is looking at writing such an abstraction
> layer or if he wants to use something in the short term.
>
>
> 2017-04-06 9:02 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
>
> > I think we will need an abstraction for this. In my opinion it would be
> > bad if the user code has to directly depend on camel.
> > Some time ago I experimented a bit with an API for events. It is
> unrelated
> > to push streams though.
> >
> > See
> > https://github.com/cschneider/typesafe-eventing
> >
> > The idea was to look into ways to abstract the process of sending and
> > receiving type safe events. In the code the Starter does the plumbing but
> > the idea is of course to let a DI framework do the plumbing.
> >
> > One idea is to use the java.util.function.Consumer interface for sending
> > and receiving typesafe messages.
> > In OSGi we could use something like this on the sender side:
> >
> > @Reference(filter="(topic=mytopic)")
> > Consumer<Customer> sender;
> >
> > Even nicer would be something like:
> > @Topic("mytopic")
> > @Reference
> > Consumer<Customer> sender;
> >
> > The user code would send simply by doing:
> > sender.accept(customer)
> >
> > On the receiver side the obvious pattern would be:
> > @Component(property="topic=mytopic")
> > class MyReceiver implements Consumer<Customer> {
> > public void accept(Customer customer) { ... };
> > }
> >
> > I also experimented a bit with things like:
> >
> > class MyReceiver {
> > @Transactional
> > @Topic("mytopic")
> > public void receive(Customer customer) { ... };
> > }
> >
> > The problem with this approach is that it requires introspection and a
> > injection framework that allows extensions and some kind of aop. So it
> > would be less useful for DS but could be nice for CDI. It is also similar
> > to eventing
> > in plain CDI.
> >
> > Another question is of course how to combine this with push streams or
> > another reactive programming model. I also think we need two levels of
> > this. One level is a kind of whiteboard model based on OSGi services
> which
> > could be common for the whole platform. The other level is the
> integration
> > with different DI systems which could be different for DS, blueprint and
> > CDI.
> >
> > To be honest I am not sure my approach is a good idea but I think it is
> > important we discuss about different approaches to find a good solution.
> >
> > Christian
> >
> >
> >
> > On 06.04.2017 08:26, Guillaume Nodet wrote:
> >
> >> The PushStream is a streaming api. It focuses on defining a pipeline,
> but
> >> the implementation is not related to any distribution mechanism.
> >>
> >> If you want to send messages across VMs on your network, you really
> should
> >> focus on ActiveMQ.
> >> There's no real OSGi specific facade I know of, so my best bet would be
> >> Camel too, as others have said.
> >> You can just show the minimum of camel, just what is needed to actually
> >> consume the JMS message from a pojo or to send messages from a pojo.
> You
> >> don't have to look at everything Camel can do.
> >>
> >>
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Open Source Architect
> > http://www.talend.com
> >
> >
>
>
> --
> ------------------------
> Guillaume Nodet
>
--
Pozdrawiam / Regards,
Dominik Przybysz
Re: OSGi and JMS
Posted by Christian Schneider <ch...@die-schneider.net>.
My starting point was actually the camel pojo messaging. I like the way
camel can abstract away the messaging handling. The problem with camel
though is that the user
code needs a dependency to camel and it also needs to setup camel. This
is where we need something in between.
Like Dominik wrote a whiteboard approach could help with receiving
messages and a sender could be injected.
We need to make sure the the user code only needs to depend on a very
small API for this. Then behind it we can use camel to implement the
actual sending and receiving but we can then also
use other implementations.
In my example I experimented with possible ways to define this API.
Christian
On 06.04.2017 11:48, Guillaume Nodet wrote:
> I'm not really sure how your example really differs from the camel one:
> http://camel.apache.org/pojo-messaging-example.html
>
> The main difference is that the Camel one is actually working, whereas
> yours is just an idea.
> I guess it depends if Dominik is looking at writing such an abstraction
> layer or if he wants to use something in the short term.
>
>
> 2017-04-06 9:02 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
>
>> I think we will need an abstraction for this. In my opinion it would be
>> bad if the user code has to directly depend on camel.
>> Some time ago I experimented a bit with an API for events. It is unrelated
>> to push streams though.
>>
>> See
>> https://github.com/cschneider/typesafe-eventing
>>
>> The idea was to look into ways to abstract the process of sending and
>> receiving type safe events. In the code the Starter does the plumbing but
>> the idea is of course to let a DI framework do the plumbing.
>>
>> One idea is to use the java.util.function.Consumer interface for sending
>> and receiving typesafe messages.
>> In OSGi we could use something like this on the sender side:
>>
>> @Reference(filter="(topic=mytopic)")
>> Consumer<Customer> sender;
>>
>> Even nicer would be something like:
>> @Topic("mytopic")
>> @Reference
>> Consumer<Customer> sender;
>>
>> The user code would send simply by doing:
>> sender.accept(customer)
>>
>> On the receiver side the obvious pattern would be:
>> @Component(property="topic=mytopic")
>> class MyReceiver implements Consumer<Customer> {
>> public void accept(Customer customer) { ... };
>> }
>>
>> I also experimented a bit with things like:
>>
>> class MyReceiver {
>> @Transactional
>> @Topic("mytopic")
>> public void receive(Customer customer) { ... };
>> }
>>
>> The problem with this approach is that it requires introspection and a
>> injection framework that allows extensions and some kind of aop. So it
>> would be less useful for DS but could be nice for CDI. It is also similar
>> to eventing
>> in plain CDI.
>>
>> Another question is of course how to combine this with push streams or
>> another reactive programming model. I also think we need two levels of
>> this. One level is a kind of whiteboard model based on OSGi services which
>> could be common for the whole platform. The other level is the integration
>> with different DI systems which could be different for DS, blueprint and
>> CDI.
>>
>> To be honest I am not sure my approach is a good idea but I think it is
>> important we discuss about different approaches to find a good solution.
>>
>> Christian
>>
>>
>>
>> On 06.04.2017 08:26, Guillaume Nodet wrote:
>>
>>> The PushStream is a streaming api. It focuses on defining a pipeline, but
>>> the implementation is not related to any distribution mechanism.
>>>
>>> If you want to send messages across VMs on your network, you really should
>>> focus on ActiveMQ.
>>> There's no real OSGi specific facade I know of, so my best bet would be
>>> Camel too, as others have said.
>>> You can just show the minimum of camel, just what is needed to actually
>>> consume the JMS message from a pojo or to send messages from a pojo. You
>>> don't have to look at everything Camel can do.
>>>
>>>
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> http://www.talend.com
>>
>>
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: OSGi and JMS
Posted by Guillaume Nodet <gn...@apache.org>.
I'm not really sure how your example really differs from the camel one:
http://camel.apache.org/pojo-messaging-example.html
The main difference is that the Camel one is actually working, whereas
yours is just an idea.
I guess it depends if Dominik is looking at writing such an abstraction
layer or if he wants to use something in the short term.
2017-04-06 9:02 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
> I think we will need an abstraction for this. In my opinion it would be
> bad if the user code has to directly depend on camel.
> Some time ago I experimented a bit with an API for events. It is unrelated
> to push streams though.
>
> See
> https://github.com/cschneider/typesafe-eventing
>
> The idea was to look into ways to abstract the process of sending and
> receiving type safe events. In the code the Starter does the plumbing but
> the idea is of course to let a DI framework do the plumbing.
>
> One idea is to use the java.util.function.Consumer interface for sending
> and receiving typesafe messages.
> In OSGi we could use something like this on the sender side:
>
> @Reference(filter="(topic=mytopic)")
> Consumer<Customer> sender;
>
> Even nicer would be something like:
> @Topic("mytopic")
> @Reference
> Consumer<Customer> sender;
>
> The user code would send simply by doing:
> sender.accept(customer)
>
> On the receiver side the obvious pattern would be:
> @Component(property="topic=mytopic")
> class MyReceiver implements Consumer<Customer> {
> public void accept(Customer customer) { ... };
> }
>
> I also experimented a bit with things like:
>
> class MyReceiver {
> @Transactional
> @Topic("mytopic")
> public void receive(Customer customer) { ... };
> }
>
> The problem with this approach is that it requires introspection and a
> injection framework that allows extensions and some kind of aop. So it
> would be less useful for DS but could be nice for CDI. It is also similar
> to eventing
> in plain CDI.
>
> Another question is of course how to combine this with push streams or
> another reactive programming model. I also think we need two levels of
> this. One level is a kind of whiteboard model based on OSGi services which
> could be common for the whole platform. The other level is the integration
> with different DI systems which could be different for DS, blueprint and
> CDI.
>
> To be honest I am not sure my approach is a good idea but I think it is
> important we discuss about different approaches to find a good solution.
>
> Christian
>
>
>
> On 06.04.2017 08:26, Guillaume Nodet wrote:
>
>> The PushStream is a streaming api. It focuses on defining a pipeline, but
>> the implementation is not related to any distribution mechanism.
>>
>> If you want to send messages across VMs on your network, you really should
>> focus on ActiveMQ.
>> There's no real OSGi specific facade I know of, so my best bet would be
>> Camel too, as others have said.
>> You can just show the minimum of camel, just what is needed to actually
>> consume the JMS message from a pojo or to send messages from a pojo. You
>> don't have to look at everything Camel can do.
>>
>>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
--
------------------------
Guillaume Nodet
Re: OSGi and JMS
Posted by Christian Schneider <ch...@die-schneider.net>.
I think we will need an abstraction for this. In my opinion it would be
bad if the user code has to directly depend on camel.
Some time ago I experimented a bit with an API for events. It is
unrelated to push streams though.
See
https://github.com/cschneider/typesafe-eventing
The idea was to look into ways to abstract the process of sending and
receiving type safe events. In the code the Starter does the plumbing
but the idea is of course to let a DI framework do the plumbing.
One idea is to use the java.util.function.Consumer interface for sending
and receiving typesafe messages.
In OSGi we could use something like this on the sender side:
@Reference(filter="(topic=mytopic)")
Consumer<Customer> sender;
Even nicer would be something like:
@Topic("mytopic")
@Reference
Consumer<Customer> sender;
The user code would send simply by doing:
sender.accept(customer)
On the receiver side the obvious pattern would be:
@Component(property="topic=mytopic")
class MyReceiver implements Consumer<Customer> {
public void accept(Customer customer) { ... };
}
I also experimented a bit with things like:
class MyReceiver {
@Transactional
@Topic("mytopic")
public void receive(Customer customer) { ... };
}
The problem with this approach is that it requires introspection and a
injection framework that allows extensions and some kind of aop. So it
would be less useful for DS but could be nice for CDI. It is also
similar to eventing
in plain CDI.
Another question is of course how to combine this with push streams or
another reactive programming model. I also think we need two levels of
this. One level is a kind of whiteboard model based on OSGi services
which could be common for the whole platform. The other level is the
integration with different DI systems which could be different for DS,
blueprint and CDI.
To be honest I am not sure my approach is a good idea but I think it is
important we discuss about different approaches to find a good solution.
Christian
On 06.04.2017 08:26, Guillaume Nodet wrote:
> The PushStream is a streaming api. It focuses on defining a pipeline, but
> the implementation is not related to any distribution mechanism.
>
> If you want to send messages across VMs on your network, you really should
> focus on ActiveMQ.
> There's no real OSGi specific facade I know of, so my best bet would be
> Camel too, as others have said.
> You can just show the minimum of camel, just what is needed to actually
> consume the JMS message from a pojo or to send messages from a pojo. You
> don't have to look at everything Camel can do.
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: OSGi and JMS
Posted by Guillaume Nodet <gn...@apache.org>.
The PushStream is a streaming api. It focuses on defining a pipeline, but
the implementation is not related to any distribution mechanism.
If you want to send messages across VMs on your network, you really should
focus on ActiveMQ.
There's no real OSGi specific facade I know of, so my best bet would be
Camel too, as others have said.
You can just show the minimum of camel, just what is needed to actually
consume the JMS message from a pojo or to send messages from a pojo. You
don't have to look at everything Camel can do.
2017-04-06 7:48 GMT+02:00 Dominik Przybysz <al...@gmail.com>:
> Hmm,
> it is difficult to understand for me...
> Could you explain how it will be works, for example, with ActiveMQ?
>
> 2017-04-06 5:31 GMT+02:00 Raymond Auge <ra...@liferay.com>:
>
> > OSGi R6 provides the Asynchronous Services specification which Aries
> > implements [1].
> >
> > Aries Async also directly implements R6 Promises which can be used to
> great
> > effect (same url).
> >
> > Finally, R7 updates RSA [2] (see chapter 100, Section 3.2.1) to support
> the
> > following async return types on service methods:
> >
> > org.osgi.util.promise.Promise
> > java.util.concurrent.Future
> > java.util.concurrent.CompletionStage
> > java.util.concurrent.CompletableFuture
> >
> > [1] http://aries.apache.org/modules/async-svcs.html
> > [2] https://osgi.org/download/osgi.enterprise-7.0.0-early-
> > draft-2017-03.pdf
> >
> > - Ray
> >
> >
> >
> > On Wed, Apr 5, 2017 at 5:37 PM, Christian Schneider <
> > chris@die-schneider.net
> > > wrote:
> >
> > > I am also very interested in some good async communication mechanism
> for
> > > OSGi. It would be great to have something like in RSA where you can
> plug
> > in
> > > transports.
> > >
> > > Christian
> > >
> > > 2017-04-05 21:50 GMT+02:00 Raymond Auge <ra...@liferay.com>:
> > >
> > > > On Wed, Apr 5, 2017 at 2:32 PM, Dominik Przybysz <
> alien11689@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > RFC looks great, especially `The solution MUST allow the sending of
> > > > > asynchronous messages to remote recipients.`
> > > > >
> > > > > But I do not see anything connected with sending events between VMs
> > in
> > > > > Specification Draft or in aries repo
> > > > > https://github.com/apache/aries/tree/trunk/pushstream ... Does it
> > work
> > > > > only
> > > > > on one VM?
> > > > >
> > > >
> > > > Hmm... This is where Tim Ward would be better qualified to answer. I
> > > can't
> > > > remember if in his demos he paired it with Async/RSA or some other
> > > > remoting...
> > > >
> > > > @Tim?
> > > >
> > > > - Ray
> > > >
> > > >
> > > > >
> > > > > 2017-04-05 20:10 GMT+02:00 Raymond Auge <raymond.auge@liferay.com
> >:
> > > > >
> > > > > > Oh, and the Push Stream Spec - Chapter 706 is included in the
> > public
> > > > > review
> > > > > > draft [1]
> > > > > >
> > > > > > [1] https://osgi.org/download/osgi.enterprise-7.0.0-early-
> > > > > > draft-2017-03.pdf
> > > > > >
> > > > > > On Wed, Apr 5, 2017 at 2:06 PM, Raymond Auge <
> > > raymond.auge@liferay.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > FYI, the state of Push Stream Spec is 95% complete and stable.
> > The
> > > > OSGi
> > > > > > CT
> > > > > > > is effectively complete, and the RI (Apache Aries Push Stream)
> is
> > > > also
> > > > > > > effectively done, stable, and passes the CT.
> > > > > > >
> > > > > > > The spec is only waiting for the release of OSGi R7 Compendium,
> > so
> > > > what
> > > > > > > you see there now should be stable and what comes out at
> release.
> > > > > > >
> > > > > > > - Ray
> > > > > > >
> > > > > > > On Wed, Apr 5, 2017 at 2:02 PM, Dominik Przybysz <
> > > > alien11689@gmail.com
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > >> @Raymond It look promising. I will check it.
> > > > > > >>
> > > > > > >> I was looking for something like that
> > > > > > >> https://github.com/ops4j/org.ops4j.pax.jms but the last
> commit
> > > was
> > > > in
> > > > > > >> 2013
> > > > > > >> and it was never released...
> > > > > > >>
> > > > > > >> 2017-04-05 19:54 GMT+02:00 Dominik Przybysz <
> > alien11689@gmail.com
> > > >:
> > > > > > >>
> > > > > > >> > Yeah,
> > > > > > >> > I know camel, but I need something more easier to use and
> show
> > > to
> > > > > new
> > > > > > >> ones.
> > > > > > >> >
> > > > > > >> > 2017-04-05 19:45 GMT+02:00 Karabo Molema <
> komolema@gmail.com
> > >:
> > > > > > >> >
> > > > > > >> >> Hi,
> > > > > > >> >>
> > > > > > >> >> You could look into using Apache camel, it integrates well
> > with
> > > > JMS
> > > > > > and
> > > > > > >> >> AMQP
> > > > > > >> >>
> > > > > > >> >> On Wednesday, April 5, 2017, Dominik Przybysz <
> > > > > alien11689@gmail.com>
> > > > > > >> >> wrote:
> > > > > > >> >> > Hi,
> > > > > > >> >> > Messaging is `must have` in microservices world, so...
> > > > > > >> >> > Is there any framework for using JMS (or AMQP) with OSGi?
> > > > > > >> >> > Do you think we should create something like
> jms-whiteboard
> > > in
> > > > > > aries?
> > > > > > >> >> >
> > > > > > >> >> > --
> > > > > > >> >> > Pozdrawiam / Regards,
> > > > > > >> >> > Dominik Przybysz
> > > > > > >> >> >
> > > > > > >> >>
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > --
> > > > > > >> > Pozdrawiam / Regards,
> > > > > > >> > Dominik Przybysz
> > > > > > >> >
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> --
> > > > > > >> Pozdrawiam / Regards,
> > > > > > >> Dominik Przybysz
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > *Raymond Augé* <http://www.liferay.com/web/ra
> ymond.auge/profile>
> > > > > > > (@rotty3000)
> > > > > > > Senior Software Architect *Liferay, Inc.* <
> > http://www.liferay.com>
> > > > > > > (@Liferay)
> > > > > > > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> > > > > > > (@OSGiAlliance)
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > > > > > (@rotty3000)
> > > > > > Senior Software Architect *Liferay, Inc.* <
> http://www.liferay.com>
> > > > > > (@Liferay)
> > > > > > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> > > > > > (@OSGiAlliance)
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Pozdrawiam / Regards,
> > > > > Dominik Przybysz
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > > > (@rotty3000)
> > > > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> > > > (@Liferay)
> > > > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> > > > (@OSGiAlliance)
> > > >
> > >
> > >
> > >
> > > --
> > > --
> > > Christian Schneider
> > > http://www.liquid-reality.de
> > > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba5
> > > 2bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
> > >
> > > Open Source Architect
> > > http://www.talend.com
> > > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba5
> > > 2bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
> > >
> >
> >
> >
> > --
> > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > (@rotty3000)
> > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> > (@Liferay)
> > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> > (@OSGiAlliance)
> >
>
>
>
> --
> Pozdrawiam / Regards,
> Dominik Przybysz
>
--
------------------------
Guillaume Nodet
Re: OSGi and JMS
Posted by Dominik Przybysz <al...@gmail.com>.
Hmm,
it is difficult to understand for me...
Could you explain how it will be works, for example, with ActiveMQ?
2017-04-06 5:31 GMT+02:00 Raymond Auge <ra...@liferay.com>:
> OSGi R6 provides the Asynchronous Services specification which Aries
> implements [1].
>
> Aries Async also directly implements R6 Promises which can be used to great
> effect (same url).
>
> Finally, R7 updates RSA [2] (see chapter 100, Section 3.2.1) to support the
> following async return types on service methods:
>
> org.osgi.util.promise.Promise
> java.util.concurrent.Future
> java.util.concurrent.CompletionStage
> java.util.concurrent.CompletableFuture
>
> [1] http://aries.apache.org/modules/async-svcs.html
> [2] https://osgi.org/download/osgi.enterprise-7.0.0-early-
> draft-2017-03.pdf
>
> - Ray
>
>
>
> On Wed, Apr 5, 2017 at 5:37 PM, Christian Schneider <
> chris@die-schneider.net
> > wrote:
>
> > I am also very interested in some good async communication mechanism for
> > OSGi. It would be great to have something like in RSA where you can plug
> in
> > transports.
> >
> > Christian
> >
> > 2017-04-05 21:50 GMT+02:00 Raymond Auge <ra...@liferay.com>:
> >
> > > On Wed, Apr 5, 2017 at 2:32 PM, Dominik Przybysz <alien11689@gmail.com
> >
> > > wrote:
> > >
> > > > RFC looks great, especially `The solution MUST allow the sending of
> > > > asynchronous messages to remote recipients.`
> > > >
> > > > But I do not see anything connected with sending events between VMs
> in
> > > > Specification Draft or in aries repo
> > > > https://github.com/apache/aries/tree/trunk/pushstream ... Does it
> work
> > > > only
> > > > on one VM?
> > > >
> > >
> > > Hmm... This is where Tim Ward would be better qualified to answer. I
> > can't
> > > remember if in his demos he paired it with Async/RSA or some other
> > > remoting...
> > >
> > > @Tim?
> > >
> > > - Ray
> > >
> > >
> > > >
> > > > 2017-04-05 20:10 GMT+02:00 Raymond Auge <ra...@liferay.com>:
> > > >
> > > > > Oh, and the Push Stream Spec - Chapter 706 is included in the
> public
> > > > review
> > > > > draft [1]
> > > > >
> > > > > [1] https://osgi.org/download/osgi.enterprise-7.0.0-early-
> > > > > draft-2017-03.pdf
> > > > >
> > > > > On Wed, Apr 5, 2017 at 2:06 PM, Raymond Auge <
> > raymond.auge@liferay.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > FYI, the state of Push Stream Spec is 95% complete and stable.
> The
> > > OSGi
> > > > > CT
> > > > > > is effectively complete, and the RI (Apache Aries Push Stream) is
> > > also
> > > > > > effectively done, stable, and passes the CT.
> > > > > >
> > > > > > The spec is only waiting for the release of OSGi R7 Compendium,
> so
> > > what
> > > > > > you see there now should be stable and what comes out at release.
> > > > > >
> > > > > > - Ray
> > > > > >
> > > > > > On Wed, Apr 5, 2017 at 2:02 PM, Dominik Przybysz <
> > > alien11689@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > >> @Raymond It look promising. I will check it.
> > > > > >>
> > > > > >> I was looking for something like that
> > > > > >> https://github.com/ops4j/org.ops4j.pax.jms but the last commit
> > was
> > > in
> > > > > >> 2013
> > > > > >> and it was never released...
> > > > > >>
> > > > > >> 2017-04-05 19:54 GMT+02:00 Dominik Przybysz <
> alien11689@gmail.com
> > >:
> > > > > >>
> > > > > >> > Yeah,
> > > > > >> > I know camel, but I need something more easier to use and show
> > to
> > > > new
> > > > > >> ones.
> > > > > >> >
> > > > > >> > 2017-04-05 19:45 GMT+02:00 Karabo Molema <komolema@gmail.com
> >:
> > > > > >> >
> > > > > >> >> Hi,
> > > > > >> >>
> > > > > >> >> You could look into using Apache camel, it integrates well
> with
> > > JMS
> > > > > and
> > > > > >> >> AMQP
> > > > > >> >>
> > > > > >> >> On Wednesday, April 5, 2017, Dominik Przybysz <
> > > > alien11689@gmail.com>
> > > > > >> >> wrote:
> > > > > >> >> > Hi,
> > > > > >> >> > Messaging is `must have` in microservices world, so...
> > > > > >> >> > Is there any framework for using JMS (or AMQP) with OSGi?
> > > > > >> >> > Do you think we should create something like jms-whiteboard
> > in
> > > > > aries?
> > > > > >> >> >
> > > > > >> >> > --
> > > > > >> >> > Pozdrawiam / Regards,
> > > > > >> >> > Dominik Przybysz
> > > > > >> >> >
> > > > > >> >>
> > > > > >> >
> > > > > >> >
> > > > > >> >
> > > > > >> > --
> > > > > >> > Pozdrawiam / Regards,
> > > > > >> > Dominik Przybysz
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Pozdrawiam / Regards,
> > > > > >> Dominik Przybysz
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > > > > > (@rotty3000)
> > > > > > Senior Software Architect *Liferay, Inc.* <
> http://www.liferay.com>
> > > > > > (@Liferay)
> > > > > > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> > > > > > (@OSGiAlliance)
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > > > > (@rotty3000)
> > > > > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> > > > > (@Liferay)
> > > > > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> > > > > (@OSGiAlliance)
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Pozdrawiam / Regards,
> > > > Dominik Przybysz
> > > >
> > >
> > >
> > >
> > > --
> > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > > (@rotty3000)
> > > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> > > (@Liferay)
> > > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> > > (@OSGiAlliance)
> > >
> >
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba5
> > 2bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
> >
> > Open Source Architect
> > http://www.talend.com
> > <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba5
> > 2bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
> >
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>
--
Pozdrawiam / Regards,
Dominik Przybysz
Re: OSGi and JMS
Posted by Raymond Auge <ra...@liferay.com>.
OSGi R6 provides the Asynchronous Services specification which Aries
implements [1].
Aries Async also directly implements R6 Promises which can be used to great
effect (same url).
Finally, R7 updates RSA [2] (see chapter 100, Section 3.2.1) to support the
following async return types on service methods:
org.osgi.util.promise.Promise
java.util.concurrent.Future
java.util.concurrent.CompletionStage
java.util.concurrent.CompletableFuture
[1] http://aries.apache.org/modules/async-svcs.html
[2] https://osgi.org/download/osgi.enterprise-7.0.0-early-draft-2017-03.pdf
- Ray
On Wed, Apr 5, 2017 at 5:37 PM, Christian Schneider <chris@die-schneider.net
> wrote:
> I am also very interested in some good async communication mechanism for
> OSGi. It would be great to have something like in RSA where you can plug in
> transports.
>
> Christian
>
> 2017-04-05 21:50 GMT+02:00 Raymond Auge <ra...@liferay.com>:
>
> > On Wed, Apr 5, 2017 at 2:32 PM, Dominik Przybysz <al...@gmail.com>
> > wrote:
> >
> > > RFC looks great, especially `The solution MUST allow the sending of
> > > asynchronous messages to remote recipients.`
> > >
> > > But I do not see anything connected with sending events between VMs in
> > > Specification Draft or in aries repo
> > > https://github.com/apache/aries/tree/trunk/pushstream ... Does it work
> > > only
> > > on one VM?
> > >
> >
> > Hmm... This is where Tim Ward would be better qualified to answer. I
> can't
> > remember if in his demos he paired it with Async/RSA or some other
> > remoting...
> >
> > @Tim?
> >
> > - Ray
> >
> >
> > >
> > > 2017-04-05 20:10 GMT+02:00 Raymond Auge <ra...@liferay.com>:
> > >
> > > > Oh, and the Push Stream Spec - Chapter 706 is included in the public
> > > review
> > > > draft [1]
> > > >
> > > > [1] https://osgi.org/download/osgi.enterprise-7.0.0-early-
> > > > draft-2017-03.pdf
> > > >
> > > > On Wed, Apr 5, 2017 at 2:06 PM, Raymond Auge <
> raymond.auge@liferay.com
> > >
> > > > wrote:
> > > >
> > > > > FYI, the state of Push Stream Spec is 95% complete and stable. The
> > OSGi
> > > > CT
> > > > > is effectively complete, and the RI (Apache Aries Push Stream) is
> > also
> > > > > effectively done, stable, and passes the CT.
> > > > >
> > > > > The spec is only waiting for the release of OSGi R7 Compendium, so
> > what
> > > > > you see there now should be stable and what comes out at release.
> > > > >
> > > > > - Ray
> > > > >
> > > > > On Wed, Apr 5, 2017 at 2:02 PM, Dominik Przybysz <
> > alien11689@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > >> @Raymond It look promising. I will check it.
> > > > >>
> > > > >> I was looking for something like that
> > > > >> https://github.com/ops4j/org.ops4j.pax.jms but the last commit
> was
> > in
> > > > >> 2013
> > > > >> and it was never released...
> > > > >>
> > > > >> 2017-04-05 19:54 GMT+02:00 Dominik Przybysz <alien11689@gmail.com
> >:
> > > > >>
> > > > >> > Yeah,
> > > > >> > I know camel, but I need something more easier to use and show
> to
> > > new
> > > > >> ones.
> > > > >> >
> > > > >> > 2017-04-05 19:45 GMT+02:00 Karabo Molema <ko...@gmail.com>:
> > > > >> >
> > > > >> >> Hi,
> > > > >> >>
> > > > >> >> You could look into using Apache camel, it integrates well with
> > JMS
> > > > and
> > > > >> >> AMQP
> > > > >> >>
> > > > >> >> On Wednesday, April 5, 2017, Dominik Przybysz <
> > > alien11689@gmail.com>
> > > > >> >> wrote:
> > > > >> >> > Hi,
> > > > >> >> > Messaging is `must have` in microservices world, so...
> > > > >> >> > Is there any framework for using JMS (or AMQP) with OSGi?
> > > > >> >> > Do you think we should create something like jms-whiteboard
> in
> > > > aries?
> > > > >> >> >
> > > > >> >> > --
> > > > >> >> > Pozdrawiam / Regards,
> > > > >> >> > Dominik Przybysz
> > > > >> >> >
> > > > >> >>
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > Pozdrawiam / Regards,
> > > > >> > Dominik Przybysz
> > > > >> >
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Pozdrawiam / Regards,
> > > > >> Dominik Przybysz
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > > > > (@rotty3000)
> > > > > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> > > > > (@Liferay)
> > > > > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> > > > > (@OSGiAlliance)
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > > > (@rotty3000)
> > > > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> > > > (@Liferay)
> > > > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> > > > (@OSGiAlliance)
> > > >
> > >
> > >
> > >
> > > --
> > > Pozdrawiam / Regards,
> > > Dominik Przybysz
> > >
> >
> >
> >
> > --
> > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > (@rotty3000)
> > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> > (@Liferay)
> > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> > (@OSGiAlliance)
> >
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba5
> 2bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
>
> Open Source Architect
> http://www.talend.com
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba5
> 2bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
Re: OSGi and JMS
Posted by Christian Schneider <ch...@die-schneider.net>.
I am also very interested in some good async communication mechanism for
OSGi. It would be great to have something like in RSA where you can plug in
transports.
Christian
2017-04-05 21:50 GMT+02:00 Raymond Auge <ra...@liferay.com>:
> On Wed, Apr 5, 2017 at 2:32 PM, Dominik Przybysz <al...@gmail.com>
> wrote:
>
> > RFC looks great, especially `The solution MUST allow the sending of
> > asynchronous messages to remote recipients.`
> >
> > But I do not see anything connected with sending events between VMs in
> > Specification Draft or in aries repo
> > https://github.com/apache/aries/tree/trunk/pushstream ... Does it work
> > only
> > on one VM?
> >
>
> Hmm... This is where Tim Ward would be better qualified to answer. I can't
> remember if in his demos he paired it with Async/RSA or some other
> remoting...
>
> @Tim?
>
> - Ray
>
>
> >
> > 2017-04-05 20:10 GMT+02:00 Raymond Auge <ra...@liferay.com>:
> >
> > > Oh, and the Push Stream Spec - Chapter 706 is included in the public
> > review
> > > draft [1]
> > >
> > > [1] https://osgi.org/download/osgi.enterprise-7.0.0-early-
> > > draft-2017-03.pdf
> > >
> > > On Wed, Apr 5, 2017 at 2:06 PM, Raymond Auge <raymond.auge@liferay.com
> >
> > > wrote:
> > >
> > > > FYI, the state of Push Stream Spec is 95% complete and stable. The
> OSGi
> > > CT
> > > > is effectively complete, and the RI (Apache Aries Push Stream) is
> also
> > > > effectively done, stable, and passes the CT.
> > > >
> > > > The spec is only waiting for the release of OSGi R7 Compendium, so
> what
> > > > you see there now should be stable and what comes out at release.
> > > >
> > > > - Ray
> > > >
> > > > On Wed, Apr 5, 2017 at 2:02 PM, Dominik Przybysz <
> alien11689@gmail.com
> > >
> > > > wrote:
> > > >
> > > >> @Raymond It look promising. I will check it.
> > > >>
> > > >> I was looking for something like that
> > > >> https://github.com/ops4j/org.ops4j.pax.jms but the last commit was
> in
> > > >> 2013
> > > >> and it was never released...
> > > >>
> > > >> 2017-04-05 19:54 GMT+02:00 Dominik Przybysz <al...@gmail.com>:
> > > >>
> > > >> > Yeah,
> > > >> > I know camel, but I need something more easier to use and show to
> > new
> > > >> ones.
> > > >> >
> > > >> > 2017-04-05 19:45 GMT+02:00 Karabo Molema <ko...@gmail.com>:
> > > >> >
> > > >> >> Hi,
> > > >> >>
> > > >> >> You could look into using Apache camel, it integrates well with
> JMS
> > > and
> > > >> >> AMQP
> > > >> >>
> > > >> >> On Wednesday, April 5, 2017, Dominik Przybysz <
> > alien11689@gmail.com>
> > > >> >> wrote:
> > > >> >> > Hi,
> > > >> >> > Messaging is `must have` in microservices world, so...
> > > >> >> > Is there any framework for using JMS (or AMQP) with OSGi?
> > > >> >> > Do you think we should create something like jms-whiteboard in
> > > aries?
> > > >> >> >
> > > >> >> > --
> > > >> >> > Pozdrawiam / Regards,
> > > >> >> > Dominik Przybysz
> > > >> >> >
> > > >> >>
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Pozdrawiam / Regards,
> > > >> > Dominik Przybysz
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Pozdrawiam / Regards,
> > > >> Dominik Przybysz
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > > > (@rotty3000)
> > > > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> > > > (@Liferay)
> > > > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> > > > (@OSGiAlliance)
> > > >
> > >
> > >
> > >
> > > --
> > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > > (@rotty3000)
> > > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> > > (@Liferay)
> > > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> > > (@OSGiAlliance)
> > >
> >
> >
> >
> > --
> > Pozdrawiam / Regards,
> > Dominik Przybysz
> >
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>
--
--
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
Re: OSGi and JMS
Posted by Raymond Auge <ra...@liferay.com>.
On Wed, Apr 5, 2017 at 2:32 PM, Dominik Przybysz <al...@gmail.com>
wrote:
> RFC looks great, especially `The solution MUST allow the sending of
> asynchronous messages to remote recipients.`
>
> But I do not see anything connected with sending events between VMs in
> Specification Draft or in aries repo
> https://github.com/apache/aries/tree/trunk/pushstream ... Does it work
> only
> on one VM?
>
Hmm... This is where Tim Ward would be better qualified to answer. I can't
remember if in his demos he paired it with Async/RSA or some other
remoting...
@Tim?
- Ray
>
> 2017-04-05 20:10 GMT+02:00 Raymond Auge <ra...@liferay.com>:
>
> > Oh, and the Push Stream Spec - Chapter 706 is included in the public
> review
> > draft [1]
> >
> > [1] https://osgi.org/download/osgi.enterprise-7.0.0-early-
> > draft-2017-03.pdf
> >
> > On Wed, Apr 5, 2017 at 2:06 PM, Raymond Auge <ra...@liferay.com>
> > wrote:
> >
> > > FYI, the state of Push Stream Spec is 95% complete and stable. The OSGi
> > CT
> > > is effectively complete, and the RI (Apache Aries Push Stream) is also
> > > effectively done, stable, and passes the CT.
> > >
> > > The spec is only waiting for the release of OSGi R7 Compendium, so what
> > > you see there now should be stable and what comes out at release.
> > >
> > > - Ray
> > >
> > > On Wed, Apr 5, 2017 at 2:02 PM, Dominik Przybysz <alien11689@gmail.com
> >
> > > wrote:
> > >
> > >> @Raymond It look promising. I will check it.
> > >>
> > >> I was looking for something like that
> > >> https://github.com/ops4j/org.ops4j.pax.jms but the last commit was in
> > >> 2013
> > >> and it was never released...
> > >>
> > >> 2017-04-05 19:54 GMT+02:00 Dominik Przybysz <al...@gmail.com>:
> > >>
> > >> > Yeah,
> > >> > I know camel, but I need something more easier to use and show to
> new
> > >> ones.
> > >> >
> > >> > 2017-04-05 19:45 GMT+02:00 Karabo Molema <ko...@gmail.com>:
> > >> >
> > >> >> Hi,
> > >> >>
> > >> >> You could look into using Apache camel, it integrates well with JMS
> > and
> > >> >> AMQP
> > >> >>
> > >> >> On Wednesday, April 5, 2017, Dominik Przybysz <
> alien11689@gmail.com>
> > >> >> wrote:
> > >> >> > Hi,
> > >> >> > Messaging is `must have` in microservices world, so...
> > >> >> > Is there any framework for using JMS (or AMQP) with OSGi?
> > >> >> > Do you think we should create something like jms-whiteboard in
> > aries?
> > >> >> >
> > >> >> > --
> > >> >> > Pozdrawiam / Regards,
> > >> >> > Dominik Przybysz
> > >> >> >
> > >> >>
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Pozdrawiam / Regards,
> > >> > Dominik Przybysz
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Pozdrawiam / Regards,
> > >> Dominik Przybysz
> > >>
> > >
> > >
> > >
> > > --
> > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > > (@rotty3000)
> > > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> > > (@Liferay)
> > > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> > > (@OSGiAlliance)
> > >
> >
> >
> >
> > --
> > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > (@rotty3000)
> > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> > (@Liferay)
> > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> > (@OSGiAlliance)
> >
>
>
>
> --
> Pozdrawiam / Regards,
> Dominik Przybysz
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
Re: OSGi and JMS
Posted by Dominik Przybysz <al...@gmail.com>.
RFC looks great, especially `The solution MUST allow the sending of
asynchronous messages to remote recipients.`
But I do not see anything connected with sending events between VMs in
Specification Draft or in aries repo
https://github.com/apache/aries/tree/trunk/pushstream ... Does it work only
on one VM?
2017-04-05 20:10 GMT+02:00 Raymond Auge <ra...@liferay.com>:
> Oh, and the Push Stream Spec - Chapter 706 is included in the public review
> draft [1]
>
> [1] https://osgi.org/download/osgi.enterprise-7.0.0-early-
> draft-2017-03.pdf
>
> On Wed, Apr 5, 2017 at 2:06 PM, Raymond Auge <ra...@liferay.com>
> wrote:
>
> > FYI, the state of Push Stream Spec is 95% complete and stable. The OSGi
> CT
> > is effectively complete, and the RI (Apache Aries Push Stream) is also
> > effectively done, stable, and passes the CT.
> >
> > The spec is only waiting for the release of OSGi R7 Compendium, so what
> > you see there now should be stable and what comes out at release.
> >
> > - Ray
> >
> > On Wed, Apr 5, 2017 at 2:02 PM, Dominik Przybysz <al...@gmail.com>
> > wrote:
> >
> >> @Raymond It look promising. I will check it.
> >>
> >> I was looking for something like that
> >> https://github.com/ops4j/org.ops4j.pax.jms but the last commit was in
> >> 2013
> >> and it was never released...
> >>
> >> 2017-04-05 19:54 GMT+02:00 Dominik Przybysz <al...@gmail.com>:
> >>
> >> > Yeah,
> >> > I know camel, but I need something more easier to use and show to new
> >> ones.
> >> >
> >> > 2017-04-05 19:45 GMT+02:00 Karabo Molema <ko...@gmail.com>:
> >> >
> >> >> Hi,
> >> >>
> >> >> You could look into using Apache camel, it integrates well with JMS
> and
> >> >> AMQP
> >> >>
> >> >> On Wednesday, April 5, 2017, Dominik Przybysz <al...@gmail.com>
> >> >> wrote:
> >> >> > Hi,
> >> >> > Messaging is `must have` in microservices world, so...
> >> >> > Is there any framework for using JMS (or AMQP) with OSGi?
> >> >> > Do you think we should create something like jms-whiteboard in
> aries?
> >> >> >
> >> >> > --
> >> >> > Pozdrawiam / Regards,
> >> >> > Dominik Przybysz
> >> >> >
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Pozdrawiam / Regards,
> >> > Dominik Przybysz
> >> >
> >>
> >>
> >>
> >> --
> >> Pozdrawiam / Regards,
> >> Dominik Przybysz
> >>
> >
> >
> >
> > --
> > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> > (@rotty3000)
> > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> > (@Liferay)
> > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> > (@OSGiAlliance)
> >
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>
--
Pozdrawiam / Regards,
Dominik Przybysz
Re: OSGi and JMS
Posted by Raymond Auge <ra...@liferay.com>.
Oh, and the Push Stream Spec - Chapter 706 is included in the public review
draft [1]
[1] https://osgi.org/download/osgi.enterprise-7.0.0-early-draft-2017-03.pdf
On Wed, Apr 5, 2017 at 2:06 PM, Raymond Auge <ra...@liferay.com>
wrote:
> FYI, the state of Push Stream Spec is 95% complete and stable. The OSGi CT
> is effectively complete, and the RI (Apache Aries Push Stream) is also
> effectively done, stable, and passes the CT.
>
> The spec is only waiting for the release of OSGi R7 Compendium, so what
> you see there now should be stable and what comes out at release.
>
> - Ray
>
> On Wed, Apr 5, 2017 at 2:02 PM, Dominik Przybysz <al...@gmail.com>
> wrote:
>
>> @Raymond It look promising. I will check it.
>>
>> I was looking for something like that
>> https://github.com/ops4j/org.ops4j.pax.jms but the last commit was in
>> 2013
>> and it was never released...
>>
>> 2017-04-05 19:54 GMT+02:00 Dominik Przybysz <al...@gmail.com>:
>>
>> > Yeah,
>> > I know camel, but I need something more easier to use and show to new
>> ones.
>> >
>> > 2017-04-05 19:45 GMT+02:00 Karabo Molema <ko...@gmail.com>:
>> >
>> >> Hi,
>> >>
>> >> You could look into using Apache camel, it integrates well with JMS and
>> >> AMQP
>> >>
>> >> On Wednesday, April 5, 2017, Dominik Przybysz <al...@gmail.com>
>> >> wrote:
>> >> > Hi,
>> >> > Messaging is `must have` in microservices world, so...
>> >> > Is there any framework for using JMS (or AMQP) with OSGi?
>> >> > Do you think we should create something like jms-whiteboard in aries?
>> >> >
>> >> > --
>> >> > Pozdrawiam / Regards,
>> >> > Dominik Przybysz
>> >> >
>> >>
>> >
>> >
>> >
>> > --
>> > Pozdrawiam / Regards,
>> > Dominik Przybysz
>> >
>>
>>
>>
>> --
>> Pozdrawiam / Regards,
>> Dominik Przybysz
>>
>
>
>
> --
> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
> (@rotty3000)
> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
> (@Liferay)
> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
> (@OSGiAlliance)
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
Re: OSGi and JMS
Posted by Raymond Auge <ra...@liferay.com>.
FYI, the state of Push Stream Spec is 95% complete and stable. The OSGi CT
is effectively complete, and the RI (Apache Aries Push Stream) is also
effectively done, stable, and passes the CT.
The spec is only waiting for the release of OSGi R7 Compendium, so what you
see there now should be stable and what comes out at release.
- Ray
On Wed, Apr 5, 2017 at 2:02 PM, Dominik Przybysz <al...@gmail.com>
wrote:
> @Raymond It look promising. I will check it.
>
> I was looking for something like that
> https://github.com/ops4j/org.ops4j.pax.jms but the last commit was in 2013
> and it was never released...
>
> 2017-04-05 19:54 GMT+02:00 Dominik Przybysz <al...@gmail.com>:
>
> > Yeah,
> > I know camel, but I need something more easier to use and show to new
> ones.
> >
> > 2017-04-05 19:45 GMT+02:00 Karabo Molema <ko...@gmail.com>:
> >
> >> Hi,
> >>
> >> You could look into using Apache camel, it integrates well with JMS and
> >> AMQP
> >>
> >> On Wednesday, April 5, 2017, Dominik Przybysz <al...@gmail.com>
> >> wrote:
> >> > Hi,
> >> > Messaging is `must have` in microservices world, so...
> >> > Is there any framework for using JMS (or AMQP) with OSGi?
> >> > Do you think we should create something like jms-whiteboard in aries?
> >> >
> >> > --
> >> > Pozdrawiam / Regards,
> >> > Dominik Przybysz
> >> >
> >>
> >
> >
> >
> > --
> > Pozdrawiam / Regards,
> > Dominik Przybysz
> >
>
>
>
> --
> Pozdrawiam / Regards,
> Dominik Przybysz
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
Re: OSGi and JMS
Posted by Dominik Przybysz <al...@gmail.com>.
@Raymond It look promising. I will check it.
I was looking for something like that
https://github.com/ops4j/org.ops4j.pax.jms but the last commit was in 2013
and it was never released...
2017-04-05 19:54 GMT+02:00 Dominik Przybysz <al...@gmail.com>:
> Yeah,
> I know camel, but I need something more easier to use and show to new ones.
>
> 2017-04-05 19:45 GMT+02:00 Karabo Molema <ko...@gmail.com>:
>
>> Hi,
>>
>> You could look into using Apache camel, it integrates well with JMS and
>> AMQP
>>
>> On Wednesday, April 5, 2017, Dominik Przybysz <al...@gmail.com>
>> wrote:
>> > Hi,
>> > Messaging is `must have` in microservices world, so...
>> > Is there any framework for using JMS (or AMQP) with OSGi?
>> > Do you think we should create something like jms-whiteboard in aries?
>> >
>> > --
>> > Pozdrawiam / Regards,
>> > Dominik Przybysz
>> >
>>
>
>
>
> --
> Pozdrawiam / Regards,
> Dominik Przybysz
>
--
Pozdrawiam / Regards,
Dominik Przybysz
Re: OSGi and JMS
Posted by Dominik Przybysz <al...@gmail.com>.
Yeah,
I know camel, but I need something more easier to use and show to new ones.
2017-04-05 19:45 GMT+02:00 Karabo Molema <ko...@gmail.com>:
> Hi,
>
> You could look into using Apache camel, it integrates well with JMS and
> AMQP
>
> On Wednesday, April 5, 2017, Dominik Przybysz <al...@gmail.com>
> wrote:
> > Hi,
> > Messaging is `must have` in microservices world, so...
> > Is there any framework for using JMS (or AMQP) with OSGi?
> > Do you think we should create something like jms-whiteboard in aries?
> >
> > --
> > Pozdrawiam / Regards,
> > Dominik Przybysz
> >
>
--
Pozdrawiam / Regards,
Dominik Przybysz
Re: OSGi and JMS
Posted by Raymond Auge <ra...@liferay.com>.
Have you considered Apache Aries Push Stream [1], an implementation of RFC
216 [2].
It's super cool!
- Ray
[1]
https://repository.apache.org/content/groups/snapshots/org/apache/aries/pushstream/pushstream/0.0.1-SNAPSHOT/
[2] https://github.com/osgi/design/tree/master/rfcs/rfc0216
On Wed, Apr 5, 2017 at 1:45 PM, Karabo Molema <ko...@gmail.com> wrote:
> Hi,
>
> You could look into using Apache camel, it integrates well with JMS and
> AMQP
>
> On Wednesday, April 5, 2017, Dominik Przybysz <al...@gmail.com>
> wrote:
> > Hi,
> > Messaging is `must have` in microservices world, so...
> > Is there any framework for using JMS (or AMQP) with OSGi?
> > Do you think we should create something like jms-whiteboard in aries?
> >
> > --
> > Pozdrawiam / Regards,
> > Dominik Przybysz
> >
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
Re: OSGi and JMS
Posted by Karabo Molema <ko...@gmail.com>.
Hi,
You could look into using Apache camel, it integrates well with JMS and AMQP
On Wednesday, April 5, 2017, Dominik Przybysz <al...@gmail.com> wrote:
> Hi,
> Messaging is `must have` in microservices world, so...
> Is there any framework for using JMS (or AMQP) with OSGi?
> Do you think we should create something like jms-whiteboard in aries?
>
> --
> Pozdrawiam / Regards,
> Dominik Przybysz
>