Bugzilla – Full Text Bug Listing
| Summary: | [RemoteSvcs] Wildcard causes IRemoteServiceContainerAdapter.registerRemoteService(String[], Object, Dictionary) to fail | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [RT] ECF | Reporter: | Markus Kuppe <bugs.eclipse.org> | ||||||
| Component: | ecf.providers | Assignee: | Markus Kuppe <bugs.eclipse.org> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | slewis | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | 3.3.0RC1 | ||||||||
| Hardware: | PC | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 319313 | ||||||||
| Attachments: |
|
||||||||
|
Description
Markus Kuppe
Attached context shows the classes/methods involved Created attachment 173651 [details]
mylyn/context/zip
Please describe/detail the input parameters used for this call. One of the test that fails because of this issue is GenericRemoteServiceRegisterTest(AbstractRemoteServiceRegisterTest).testRegisterOnCreatedServer() line: 81
The problem is in org.eclipse.ecf.provider.remoteservice.generic.RegistrySharedObject.checkServiceClass(String[], Object) if called
with String[]{"*"} which fails with a ClassNotFoundException for "*". We might have to add logic to accept "*" in org.eclipse.ecf.provider.remoteservice.generic.RegistrySharedObject.checkServiceClass(String[], Object)
Alternatively we might want to change org.eclipse.ecf.internal.osgi.services.distribution.EventHookImpl.handleRegisteredServiceEvent(ServiceReference, Collection) to resolve "*" to the actual service interface(s) in org.eclipse.ecf.internal.osgi.services.distribution.EventHookImpl.getExportedInterfaces(ServiceReference). After some more investigation the underlying problem might be relatively simple. org.eclipse.ecf.internal.osgi.services.distribution.EventHookImpl.getExportedInterfaces(ServiceReference) does not handle a service wildcard nested inside a String[]. (In reply to comment #6) > After some more investigation the underlying problem might be relatively > simple. > org.eclipse.ecf.internal.osgi.services.distribution.EventHookImpl.getExportedInterfaces(ServiceReference) > does not handle a service wildcard nested inside a String[]. Yeah. It does handle "*" (i.e. rather than new String[] { "*" }). As I *remember*, the specification (for remote services) specifies the "*" String as indicating the wildcard...I don't recall it saying anything about new String[] { "*" }. So...in the current implementation new String[] { "*" } isn't supported (as you've found). We could pretty easily support it...although I'm not sure if that would be specification compliant or not. Unless I'm misremembering (which is possible, since I don't have the spec committed to memory yet :) I think the spec is ambiguous about new String[] { "*" }. Created attachment 173680 [details]
Handle String[]{"*"}
(In reply to comment #8) > Created an attachment (id=173680) [details] > Handle String[]{"*"} Although this patch certainly allows us to support new String[] { "*" }, I think we need to determine (somehow) whether this is going to introduce a problem WRT remote service spec compliance. One reason...*now* the impl will also accept (e.g.): new String[] { "IFoo", "*" }; and this might be considered a problem (by some). In any event, it's not a big deal to me, but I just don't want to introduce things without checking that might get us dinged on spec compliance (no matter how trivial). Removing R-OSGi tag as this also affects other remote service containers Released a change in org.eclipse.ecf.tests.osgi.services.distribution.AbstractRemoteServiceAccessTest.getServiceProperties() to HEAD that replaces the String[]{SERVICE_EXPORTED_INTERFACES_WILDCARD} from the service properties with just SERVICE_EXPORTED_INTERFACES_WILDCARD.
Fixed in HEAD (as per previous comment) Does this need a backport for 3.3.1? (In reply to comment #13) > Does this need a backport for 3.3.1? Yes. Please apply this fix to the Release_3_3 stream, and I'll do another Release_3_3 sdk build for our contribution to Helios maintenance build on Monday next (9/13). Please just let me know on this bug when it's been applied to Release_3_3 stream. (In reply to comment #14) > Yes. Please apply this fix to the Release_3_3 stream, and I'll do another > Release_3_3 sdk build for our contribution to Helios maintenance build on > Monday next (9/13). Please just let me know on this bug when it's been applied > to Release_3_3 stream. Backported to Release_3_3 and spun off a new test build https://build.ecf-project.org/hudson/job/L-Release_3_3-sdk.tests.feature/16/ Changing target milestone |