Home » Archived » Eclipse Communications Framework (ECF) » JMS Provider?
|
| Re: JMS Provider? [message #587423 is a reply to message #587399] |
Fri, 09 September 2005 17:32   |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Jason,
In answer to your first question...yes, a jms plugin is available for
use. I can provide a pointer to the plugin zip and/or CVS access for
people that request it. If you would like a copy, please just send me
an email (slewis@composent.com) stating so and I'll point you at the zip.
Our strong desire and intention is to release this and some other
as-yet-unreleased plugins via the eclipse.org website as soon as
possible. The holdup is that these plugins include/use libraries
produced by third parties...in this case the activemq jms implementation
(www.activemq.com).
As an Eclipse foundation project we (the ECF team) are required to have
a review of the activemq licensing and code provenance for compatibility
with the Eclipse Public License...which is the license that we the ECF
team are bound to use for distributing ECF plugins via eclipse.org.
Although this will take some additional time for the foundation to
complete (several weeks), given that the activemq implementation is
governed by the Apache 2 license, and Apache 2-licensed code is already
redistributed in many parts of eclipse itself (e.g. tomcat
implementation, etc) there should/will be no problem with redistributing
the jms plugin including the activemq libraries under the EPL via the
eclipse.org website. It just might take a few weeks to do so.
So in the mean time, please contact us directly at the email address
above and I'll make the zip available directly to anyone that asks.
Thanks,
Scott
Jason Parrott wrote:
> Hey,
> I was wondering if the JMS provider was available for use, and where I
> might find it. Also, when is it expected to be put in as part of the
> standard distro? Thanks
>
> -Jason
>
>
|
|
|
| Re: JMS Provider? [message #587454 is a reply to message #587423] |
Sun, 11 September 2005 11:38 |
John Smith
Messages: 20
Registered: July 2009 |
Junior Member |
|
|
Hi Scott,
As long as I know, JMS does not define a wire protocol used internally
making it impossible to mix different JMS providers. However, the API is
well defined and it does not depend on JMS provider used. Have you
considered to use other JMS implementations like UberMQ? Do you mean
that plugin is hardly bound to ActiveMQ implementation?
Thanks
Scott Lewis wrote:
> Hi Jason,
>
> In answer to your first question...yes, a jms plugin is available for
> use. I can provide a pointer to the plugin zip and/or CVS access for
> people that request it. If you would like a copy, please just send me
> an email (slewis@composent.com) stating so and I'll point you at the zip.
>
> Our strong desire and intention is to release this and some other
> as-yet-unreleased plugins via the eclipse.org website as soon as
> possible. The holdup is that these plugins include/use libraries
> produced by third parties...in this case the activemq jms implementation
> (www.activemq.com).
>
> As an Eclipse foundation project we (the ECF team) are required to have
> a review of the activemq licensing and code provenance for compatibility
> with the Eclipse Public License...which is the license that we the ECF
> team are bound to use for distributing ECF plugins via eclipse.org.
> Although this will take some additional time for the foundation to
> complete (several weeks), given that the activemq implementation is
> governed by the Apache 2 license, and Apache 2-licensed code is already
> redistributed in many parts of eclipse itself (e.g. tomcat
> implementation, etc) there should/will be no problem with redistributing
> the jms plugin including the activemq libraries under the EPL via the
> eclipse.org website. It just might take a few weeks to do so.
>
> So in the mean time, please contact us directly at the email address
> above and I'll make the zip available directly to anyone that asks.
>
> Thanks,
>
> Scott
>
>
>
> Jason Parrott wrote:
>
>> Hey,
>> I was wondering if the JMS provider was available for use, and where
>> I might find it. Also, when is it expected to be put in as part of the
>> standard distro? Thanks
>>
>> -Jason
>>
|
|
|
| Re: JMS Provider? [message #587484 is a reply to message #587454] |
Mon, 12 September 2005 02:53 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi John,
John Smith wrote:
> Hi Scott,
>
> As long as I know, JMS does not define a wire protocol used internally
> making it impossible to mix different JMS providers. However, the API is
> well defined and it does not depend on JMS provider used.
True.
Have you
> considered to use other JMS implementations like UberMQ?
Yes, I have considered it. The only reason we haven't actually done
multiple implementations of the ECF JMS provider is because we are
currently short on resources and long on desired features and desired
additional providers (e.g. SIP, file transfer, etc).
Do you mean
> that plugin is hardly bound to ActiveMQ implementation?
The plugin is (currently) written to use the ActiveMQ implementation.
This is not at all required, however, and with a small amount of
refactoring this plugin could easily support pluggble JMS
implementations. Specifically, there is only one place in the ECF
client plugin where the active mq classes are referenced directly...and
that's the org.eclipse.ecf.provider.jms.channel.Channel class. It
references the ActiveMQConnectionFactory to create a Connection
instance. Everything else references the jms interfaces and classes
rather than the activemq classes directly.
Generalizing this so that it can use some other implementation, or even
exposing an extension point that allows other plugins to substitute
their own JMS implementations would not be at all complex.
I don't think ECF can take such a task on, however, without some
assistance, given the amount and variety of demands on this very small
team (7 committers...all very part time). John would you be at all
interested in participating or even leading this? Would others be
interested in such a thing (a JMS provider that had the ability to
plugin multiple JMS implementations)? If so, *how* interested? Would
you be willing to participate in this by providing development
resources, etc?
Thanks,
Scott
|
|
|
| Re: JMS Provider? [message #587500 is a reply to message #587484] |
Tue, 13 September 2005 14:08 |
Eclipse User |
|
|
|
Originally posted by: dummy666.mail.ru
Hi Scott,
First of all I'd like to apologize for subscribing with wrong name, John
Smith, which was simply a default value.
I'm not familiar yet with ECF so I would need some time to catch up. If
that is only about making it possible to use pluggable factory class,
that should not be a big deal to implement. The only thing I need to
know for that to implement is what configuration method is used across
ECF, is that single properties file, separate properties files for each
class or something more advanced?
I'm not sure how much time I can dedicate to that. However, I'd like to
be involved in that process. Especially because it should be not too far
from what I'm doing as my full-time job.
Cheers
Alexander
Scott Lewis wrote:
> Hi John,
>
> John Smith wrote:
>
>> Hi Scott,
>>
>> As long as I know, JMS does not define a wire protocol used internally
>> making it impossible to mix different JMS providers. However, the API
>> is well defined and it does not depend on JMS provider used.
>
>
> True.
>
> Have you
>
>> considered to use other JMS implementations like UberMQ?
>
>
> Yes, I have considered it. The only reason we haven't actually done
> multiple implementations of the ECF JMS provider is because we are
> currently short on resources and long on desired features and desired
> additional providers (e.g. SIP, file transfer, etc).
>
> Do you mean
>
>> that plugin is hardly bound to ActiveMQ implementation?
>
>
> The plugin is (currently) written to use the ActiveMQ implementation.
> This is not at all required, however, and with a small amount of
> refactoring this plugin could easily support pluggble JMS
> implementations. Specifically, there is only one place in the ECF
> client plugin where the active mq classes are referenced directly...and
> that's the org.eclipse.ecf.provider.jms.channel.Channel class. It
> references the ActiveMQConnectionFactory to create a Connection
> instance. Everything else references the jms interfaces and classes
> rather than the activemq classes directly.
>
> Generalizing this so that it can use some other implementation, or even
> exposing an extension point that allows other plugins to substitute
> their own JMS implementations would not be at all complex.
>
> I don't think ECF can take such a task on, however, without some
> assistance, given the amount and variety of demands on this very small
> team (7 committers...all very part time). John would you be at all
> interested in participating or even leading this? Would others be
> interested in such a thing (a JMS provider that had the ability to
> plugin multiple JMS implementations)? If so, *how* interested? Would
> you be willing to participate in this by providing development
> resources, etc?
>
> Thanks,
>
> Scott
>
|
|
|
| Re: JMS Provider? [message #587511 is a reply to message #587500] |
Wed, 14 September 2005 21:28 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Alexander,
Thanks for your offer of help...we'll certainly take you up on it. I
think you and I should correspond directly about the mechanics of this
arrangement...could you send an email to me at slewis@composent.com and
we'll hook up directly? Thanks.
Some answers to your question:
Alexander Kulakov wrote:
> Hi Scott,
>
> First of all I'd like to apologize for subscribing with wrong name, John
> Smith, which was simply a default value.
>
> I'm not familiar yet with ECF so I would need some time to catch up. If
> that is only about making it possible to use pluggable factory class,
> that should not be a big deal to implement. The only thing I need to
> know for that to implement is what configuration method is used across
> ECF, is that single properties file, separate properties files for each
> class or something more advanced?
What I would prefer would be that you and I could define an extension
point for the org.eclipse.ecf.provider.jms plugin that allows other
plugins to implement jms connection factories using whatever JMS
implementation is desired. This way the org.eclipse.ecf.provider.jms
plugin would not have to be modified to support additional jms
implementations...they would be simply loaded and used by the
org.eclipse.ecf.provider.jms plugin when it was accessed.
>
> I'm not sure how much time I can dedicate to that. However, I'd like to
> be involved in that process. Especially because it should be not too far
> from what I'm doing as my full-time job.
OK. If you want to coordinate with me in direct emails we'll see how
best to proceed.
Scott
>
> Cheers
> Alexander
>
> Scott Lewis wrote:
>
>> Hi John,
>>
>> John Smith wrote:
>>
>>> Hi Scott,
>>>
>>> As long as I know, JMS does not define a wire protocol used
>>> internally making it impossible to mix different JMS providers.
>>> However, the API is well defined and it does not depend on JMS
>>> provider used.
>>
>>
>>
>> True.
>>
>> Have you
>>
>>> considered to use other JMS implementations like UberMQ?
>>
>>
>>
>> Yes, I have considered it. The only reason we haven't actually done
>> multiple implementations of the ECF JMS provider is because we are
>> currently short on resources and long on desired features and desired
>> additional providers (e.g. SIP, file transfer, etc).
>>
>> Do you mean
>>
>>> that plugin is hardly bound to ActiveMQ implementation?
>>
>>
>>
>> The plugin is (currently) written to use the ActiveMQ implementation.
>> This is not at all required, however, and with a small amount of
>> refactoring this plugin could easily support pluggble JMS
>> implementations. Specifically, there is only one place in the ECF
>> client plugin where the active mq classes are referenced
>> directly...and that's the org.eclipse.ecf.provider.jms.channel.Channel
>> class. It references the ActiveMQConnectionFactory to create a
>> Connection instance. Everything else references the jms interfaces
>> and classes rather than the activemq classes directly.
>>
>> Generalizing this so that it can use some other implementation, or
>> even exposing an extension point that allows other plugins to
>> substitute their own JMS implementations would not be at all complex.
>>
>> I don't think ECF can take such a task on, however, without some
>> assistance, given the amount and variety of demands on this very small
>> team (7 committers...all very part time). John would you be at all
>> interested in participating or even leading this? Would others be
>> interested in such a thing (a JMS provider that had the ability to
>> plugin multiple JMS implementations)? If so, *how* interested? Would
>> you be willing to participate in this by providing development
>> resources, etc?
>>
>> Thanks,
>>
>> Scott
>>
|
|
|
| |
  |
Goto Forum:
Current Time: Tue Apr 23 07:52:01 GMT 2024
Powered by FUDForum. Page generated in 0.04814 seconds |
] 
Search
Help
Register
Login
Home
