While I think the EventAdmin maps well to JMS for distribution of events,
I'm not sure that JMS maps well onto the EventAdmin.  We have a similar need
to integrate JMS into an OSGi environment.  The overriding problem from my
point of view is not the lack of an API, but the inherent difficulty of
introducing the prerequisites for different vendor implementations into the
OSGi framework.  It seems to me that if a provider bundle published regular
JMS connection factories into OSGi, that would provide an adequate API for
any consumers.  The implementation can create the factories using any
mechanism it favors behind the scenes, whether that be through JNDI, direct
instantiation, or whatever.  So I guess my questions would be:
- Are the existing JMS APIs deficient or inadequate?
- Would this proposed API hide the JMS API altogether in favor of a new
model?


On Thu, Jan 7, 2010 at 2:30 PM, Richard S. Hall <[email protected]>wrote:

> Are you aware of:
>
>    http://fusesource.com/wiki/display/LIGHTSABRE/Home ?
>
> Not exactly the same, but related. I am not familiar enough with JMS to say
> whether or not a new API is needed or if the EventAdmin API could be
> commandeered for this purpose. I do think there is potential, but let's see
> what others have to say.
>
> -> richard
>
>
> On 1/7/10 17:05, Geert Schuring wrote:
>
>> Hey all,
>>
>> I'm using Felix in a security software integration environment, and it
>> supprised me that I couldn't find a messaging service that would handle JMS
>> messaging for me. Did I miss something? If not, I would like to develop and
>> contribute the "Felix Messaging Service". I have an API bundle in mind with
>> several implementation bundles like ActiveMQ, WebsphereMQ, OpenJMS,
>> Microsoft MQ, etc.
>>
>> Let me know what you think.
>>
>> Greets,
>> Geert Schuring.
>>
>>
>

Reply via email to