[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] Authentication when using DS for Remote Services?
- From: Scott Lewis <slewis@xxxxxxxxxxxxx>
- Date: Thu, 24 Jul 2014 19:12:17 -0700
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
I've created a two new example bundles (one customizing the remote
service host to do authentication, the other customizing the remote
service consumer/client to do the sending of the authentication
information (i.e. username/password). See  for details.
Mea culpa: I was a incorrect below in describing the procedure for
passing authentication information (username/password) in the
connectData for the remote service consumer. Rather than overriding
getConnectContext(), it involved defining and setting an
IConnectInitiatorPolicy instance upon consumer container creation. This
is shown in the consumer example code (in this class in the example:
On 7/21/2014 11:25 AM, Scott Lewis wrote:
Sorry about the slow reply...over past two weeks I've been completely
focused on testing ECF 3.9 against the OSGi R6 CT (compatibility test
I've asked you some high-level questions on the bug ...about the
desire for the example you requested for setting up ECF generic
A couple of quick responses below. If you would like to contact me
directly for support please just email me at slewis at composent.com.
On 7/15/2014 9:48 PM, J Langley wrote:
I believe that I am a bit closer to getting this to work using the
hello remote services example. I am using zeroconf for discovery.
On the host side, I have registered a service for
IHostContainerSelector. It extends the HostContainerSelector,
overriding the createContainer method to use the parent to actually
create the container, but then sets an IConnectHandlerPolicy policy
on the container before returning it. I have verified that the
policy is called when the consumer is connected, but the connectData
is always null.
On the client side, I have registered a service for
IConsumerContainerSelector. It extends the
ConsumerContainerSelector, overriding the getConnectContext and
connectContainer methods. However, these methods are never called.
I believe that this is because the connectTargetID parameter in the
ConsumerContainerSelector::selectConsumerContainer method is always
So far, I think that it is because the endpoint discovery has not
occurred at this point.
Yes, this seems right to me. The
IConsumerContainerSelector.selectConsumerContainer is called when the
RSA.importService method is called, and with the BasicTopologyManager,
importService is called upon endpoint discovery. So the sequence
typically looks like this:
1. <network discovery occurs>
-> creates EndpointDescription instance (ed)
2. Topology Manager (BasicTopologyManager) takes ed and calls
3. <ECF's RSA impl>
-> Gets IConsumerContainerSelector and calls
-> Creates TCPClientSOContainer, calls connect after calling
The reason I say 'typically' is that the RSA spec makes it possible
have/use a custom topology manager. As a compliant impl, ECF supports
this topology manager customization, it's possible for others to
create/use a custom topology manager...and not use the
BasicTopologyManager (which is the ECF default topology manager). But
the upshot is that you are right, with the BasicTopologyManager the
endpoint description discovery triggers the RSA.importService, which
calls the IConsumerContainerSelector.
I was finally able to override the selectConsumerContainer and set
the context for authentication on the adapter. Now when I have a
breakpoint at SOContext.connect - I see the connect context that I
set for the adapter.
Ok, that seems right. Please let me know how/if I can help further.
Please also feel free to use bug  if you wish.
I am still receiving null on the host side though. Also, it doesn't
appear that the return value from the IConnectHandlerPolicy is being
used. I will update tomorrow with any progress.
ecf-dev mailing list
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit