[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ecf-dev] remote services, load balancing
|
Hi Greg,
Greg House wrote:
Hi Scott,
I got the latest code from HEAD and everything is working as expected.
This is a very nice feature because now the consumer's usage of
services is completely transparent.
Thank you!
You are most welcome. I would ask that in return for the favor, please
consider contributing back to the project some more: through additional
use cases, bug reports, code (example code, tests, or additional
providers, etc), documentation for anything...or even blog postings
about your usage and experiences (if this can be public, of course).
For example of some code things that could use contributions: our
activemq provider is currently using activemq 5.2...and it could be
moved up to a more recent version. Also, there is great need for
additional JMS and other providers...e.g. to support AMQP and/or other
messaging protocols. There are more, if people are interested.
My understanding is that some extensions has to be made to the
activemq provider in order to use ds for the service host and the servers.
Is that correct and do you have any plans to extends this provider?
Should I file a bug for this issue?
It would probably be good to create a bug/enhancement request for this
issue...as I don't have any immediate plans to add this support.
Adding this is not at all technically difficult or even extensive...and
I'll happily explain it publicly for those that are interested and
perhaps willing to contribute. Probably better to do it on the new
bug/enhancement request than here, however.
I am interested in understanding the use case driver for this...since it
seems to me that using/supporting ds (and OSGi remote services) on the
consumer is the most important usage for ds/injection (i.e. combined
with network discovery and osgi remote services). For the service host
and the servers using ds doesn't seem as necessary or even desirable to
me. But that's why I would like to understand your use case better.
Scott