Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 326122 - DefaultHostContainerFinder creates a container if "service.exported.configs" is null
Summary: DefaultHostContainerFinder creates a container if "service.exported.configs" ...
Status: RESOLVED WONTFIX
Alias: None
Product: ECF
Classification: RT
Component: ecf.remoteservices (show other bugs)
Version: 3.3.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Markus Kuppe CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 326053
Blocks:
  Show dependency tree
 
Reported: 2010-09-24 03:46 EDT by Markus Kuppe CLA
Modified: 2010-09-25 03:40 EDT (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Kuppe CLA 2010-09-24 03:46:44 EDT 
As described in bug #326053#c5 DefaultHostContainerFinder shows inconsistent behavior WRT to container instantiation. If "service.exported.configs" is null, it creates a (default) container for the first service registered. For a second service registered however, it fails to match config types and subsequently tries to create a second container. This causes a container exception in turn due to a port conflict.

Possible solutions are:

a) Fix AbstractHostContainerFinder.matchExistingHostContainer so that the second service reuses the existing container
b) Add a condition to line 44 in DefaultHostContainerFinder.findHostContainers(ServiceReference, String[], String[], String[]) that checks for "service.exported.configs" == null
Comment 1 Markus Kuppe CLA 2010-09-25 03:40:32 EDT 
Going to implement a) as part of bug #326053. Closing this one as WONTFIX.