Comment 1 Martin Petzold 2011-02-17 07:35:27 EST

Hi Ahmed,

can you reproduce the bug? I don't have a simple test case at the moment but could create one. For me this happens somehow just with a second remote service registration.

Comment 2 Ahmed Aadel 2011-02-17 07:53:30 EST

(In reply to comment #1)
> Hi Ahmed,
> 
> can you reproduce the bug? I don't have a simple test case at the moment but
> could create one. For me this happens somehow just with a second remote service
> registration.

Hi Martin,
Unfortunately not. I can't even figure out the relation with zooDiscovery given the output.

Comment 3 Martin Petzold 2011-02-17 08:30:17 EST

It comes up in EndpointDescriptionAdvertiser while service publication with
zoodiscovery:

protected IStatus doDiscovery(EndpointDescription endpointDescription,
        boolean advertise) {
    Assert.isNotNull(endpointDescription);
    String messagePrefix = advertise ? "Advertise" : "Unadvertise";
//$NON-NLS-1$ //$NON-NLS-2$
    List<IStatus> statuses = new ArrayList<IStatus>();
    // First get serviceInfoFactory
    IServiceInfoFactory serviceInfoFactory = getServiceInfoFactory();
    if (serviceInfoFactory == null)
        return createErrorStatus(messagePrefix
                + " endpointDescription=" //$NON-NLS-1$
                + endpointDescription
                + ".  No IServiceInfoFactory is available.  Cannot unpublish
endpointDescription=" //$NON-NLS-1$
                + endpointDescription);
    IDiscoveryAdvertiser[] discoveryAdvertisers = getDiscoveryAdvertisers();
    if (discoveryAdvertisers == null || discoveryAdvertisers.length == 0)
        return createErrorStatus(messagePrefix
                + " endpointDescription=" //$NON-NLS-1$
                + endpointDescription
                + ".  No endpointDescriptionLocator advertisers available. 
Cannot unpublish endpointDescription=" //$NON-NLS-1$
                + endpointDescription);
    for (int i = 0; i < discoveryAdvertisers.length; i++) {
        IServiceInfo serviceInfo = (advertise ? serviceInfoFactory
                .createServiceInfo(discoveryAdvertisers[i],
                        endpointDescription) : serviceInfoFactory
                .removeServiceInfo(discoveryAdvertisers[i],
                        endpointDescription));
        if (serviceInfo == null) {
            statuses.add(createErrorStatus(messagePrefix
                    + " endpointDescription=" //$NON-NLS-1$
                    + endpointDescription
                    + ".  Service Info is null.  Cannot publish
endpointDescription=" //$NON-NLS-1$
                    + endpointDescription));
            continue;
        }
        // Now actually unregister with advertiser
        statuses.add(doDiscovery(discoveryAdvertisers[i], serviceInfo,
                advertise));
    }
    return createResultStatus(statuses, messagePrefix
            + " endpointDesription=" + endpointDescription //$NON-NLS-1$
            + ".  Problem in unadvertise"); //$NON-NLS-1$
}

Comment 4 Martin Petzold 2011-02-17 08:38:50 EST

I'm using the actual master classes (error did not occur before)! So this is about testing the RSA and your bug fixes with zoodiscovery.

Here...

for (int i = 0; i < discoveryAdvertisers.length; i++) {

...all IDiscoveryAdvertiser are called, in my case this is a ZooDiscovery container!

This returns null (advertise=true):

IServiceInfo serviceInfo = (advertise ? serviceInfoFactory		.createServiceInfo(discoveryAdvertisers[i], endpointDescription) : serviceInfoFactory.removeServiceInfo(discoveryAdvertisers[i],endpointDescription));

So this bug is about createServiceInfo(...), there a discoveryAdvertisers[i] and an endpoint desciption is given:

EndpointDescription[containerID=r-osgi://jumper:9279,connectTargetID=null,idFilter=null,rsFilter=null,properties={devsosgi.model.component.id=devsosgi.model.crossing_0_0, devsosgi.node.id=6da34691-c780-4507-a2dc-88757c53cf5d, ecf.endpoint.id.ns=ecf.namespace.r_osgi, endpoint.framework.uuid=c9de3e50-eb76-4d57-8df3-b26dc4c2e64a, endpoint.id=r-osgi://jumper:9279, endpoint.service.id=66, objectClass=[Ljava.lang.String;@154ebadd, remote.configs.supported=[Ljava.lang.String;@7b41a32f, remote.intents.supported=[Ljava.lang.String;@1240a1e1, service.id=65, service.imported=true, service.imported.configs=[Ljava.lang.String;@7b41a32f}]

Comment 5 Ahmed Aadel 2011-02-17 09:02:20 EST

(In reply to comment #4)
> I'm using the actual master classes (error did not occur before)! So this is
> about testing the RSA and your bug fixes with zoodiscovery.
> 
> Here...
> 
> for (int i = 0; i < discoveryAdvertisers.length; i++) {
> 
> ...all IDiscoveryAdvertiser are called, in my case this is a ZooDiscovery
> container!
> 
> This returns null (advertise=true):
> 
> IServiceInfo serviceInfo = (advertise ? serviceInfoFactory       
> .createServiceInfo(discoveryAdvertisers[i], endpointDescription) :
> serviceInfoFactory.removeServiceInfo(discoveryAdvertisers[i],endpointDescription));
> 
> So this bug is about createServiceInfo(...), there a discoveryAdvertisers[i]
> and an endpoint desciption is given:
> 
> EndpointDescription[containerID=r-osgi://jumper:9279,connectTargetID=null,idFilter=null,rsFilter=null,properties={devsosgi.model.component.id=devsosgi.model.crossing_0_0,
> devsosgi.node.id=6da34691-c780-4507-a2dc-88757c53cf5d,
> ecf.endpoint.id.ns=ecf.namespace.r_osgi,
> endpoint.framework.uuid=c9de3e50-eb76-4d57-8df3-b26dc4c2e64a,
> endpoint.id=r-osgi://jumper:9279, endpoint.service.id=66,
> objectClass=[Ljava.lang.String;@154ebadd,
> remote.configs.supported=[Ljava.lang.String;@7b41a32f,
> remote.intents.supported=[Ljava.lang.String;@1240a1e1, service.id=65,
> service.imported=true, service.imported.configs=[Ljava.lang.String;@7b41a32f}]

The bug you mentioned (https://bugs.eclipse.org/bugs/show_bug.cgi?id=335419) was about passing all serviceInfo properties as-is, which is now done. The code you're referring to is neither in ZooDiscovery nor I can relate to, hence, my sayings about not being able to figure this bug's whereabouts. AFAIK, works are still bing done on implementing RSA in ECF, so maybe somebody now busy with it(Scott?) can help figuring this out.  I'll gladly help fixing it should something be changed in zooDiscovery.

Comment 6 Martin Petzold 2011-02-17 09:05:11 EST

@Scott: You should have a look at this, could be about RSA

In: org.eclipse.ecf.osgi.services.remoteserviceadmin.ServiceInfoFactory

existingServiceInfo (Line 74) is *not* null for the second service publication.
Instead of null the ServiceInfo object of the *first* service is returned from
the "serviceInfos" HashMap:

----- (first Service is an INode, second one is an ISimulator)

ServiceInfo[uri=ecf.osgirsvc://jumper:9279/osgirsvc_66OKTAtrZYvi4tEhDju30roiIfI=;id=ServiceID[type=ServiceTypeID[typeName=_ecf.osgirsvc._default.default._iana];location=ecf.osgirsvc://jumper:9279/osgirsvc_66OKTAtrZYvi4tEhDju30roiIfI=;full=_ecf.osgirsvc._default.default._iana@ecf.osgirsvc://jumper:9279/osgirsvc_66OKTAtrZYvi4tEhDju30roiIfI=];priority=0;weight=0;props=ServiceProperties[{endpoint.service.id=60,
devsosgi.node.id=5e34273c-a2db-404d-bb0e-598ec4bc9a32,
objectClass=devsosgi.node.INode,
endpoint.framework.uuid=031f89d0-07a0-4ba7-9919-0fc496bd9ba1,
remote.intents.supported=passByValue exactlyOnce ordered,
ecf.endpoint.id.ns=ecf.namespace.r_osgi,
remote.configs.supported=ecf.r_osgi.peer, endpoint.id=r-osgi://jumper:9279,
service.imported.configs=ecf.r_osgi.peer}]]

-----

So the ServiceInfoKey equals the ServiceInfoKey of the first service
publication.

So this is either about the equals of the ServiceInfoKey class or about
zoodiscovery namespace!

Comment 7 Martin Petzold 2011-02-17 09:22:19 EST

In: ServiceInfoKey. If I change:

private int hashCode = 7;

To:

private int hashCode = new Random().nextInt(15514551);

This error does not occur anymore...

...*but* now my first service INode is published again, a second time (instead of the second one ISimulator).

I think it's about the equals method of the EndpointDesciption that is not correct.

Comment 8 Scott Lewis 2011-02-17 10:43:41 EST

(In reply to comment #7)
> In: ServiceInfoKey. If I change:
> 
> private int hashCode = 7;
> 
> To:
> 
> private int hashCode = new Random().nextInt(15514551);
> 
> This error does not occur anymore...
> 
> ...*but* now my first service INode is published again, a second time (instead
> of the second one ISimulator).
> 
> I think it's about the equals method of the EndpointDesciption that is not
> correct.

equals and hashCode of EndpointDescription are determined by the OSGi spec and impl of EndpointDescription so if this is the case it's a bug in the spec.

I will have a look at this today...but I need to understand your use case better...i.e. what is the sequence of calls to advertise?  (i.e. is it advertising the same service twice? or is it advertising two different services)?

Comment 9 Martin Petzold 2011-02-17 11:46:35 EST

(In reply to comment #8)
> (In reply to comment #7)
> > In: ServiceInfoKey. If I change:
> > 
> > [...]
> (i.e. is it
> advertising the same service twice? or is it advertising two different
> services)?

I did not have the error with ECF 3.4, it comes up with master and RSA. I haven't changed implementation since then.

It's:

1. Register ServiceA
2. Register ServiceB

So two different Remote Services are registered from the same host (framework).

In Activator.start():

// Create and register a remote service
final Properties propsA = new Properties();
propsA.put("service.exported.interfaces", "*");
propsA.put("service.exported.configs", "ecf.r_osgi.peer");
Activator.getContext().registerService(ServiceA.class.getName(),
	new ServiceAImpl(), propsA);

Thread.sleep(2000);
		
// Create and register a remote service
final Properties propsB = new Properties();
propsB.put("service.exported.interfaces", "*");
propsB.put("service.exported.configs", "ecf.r_osgi.peer");
Activator.getContext().registerService(ServiceB.class.getName(),
	new ServiceBImpl(), propsB);

Comment 10 Martin Petzold 2011-02-17 11:48:38 EST

Removed [zoodiscovery] from topic, it's also with jmdns reproducable.

Comment 11 Scott Lewis 2011-02-17 11:59:49 EST

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > In: ServiceInfoKey. If I change:
> > > 
> > > [...]
> > (i.e. is it
> > advertising the same service twice? or is it advertising two different
> > services)?
> 
> I did not have the error with ECF 3.4, it comes up with master and RSA. I
> haven't changed implementation since then.
> 
> It's:
> 
> 1. Register ServiceA
> 2. Register ServiceB
> 
> So two different Remote Services are registered from the same host (framework).
> 
> In Activator.start():
> 
> // Create and register a remote service
> final Properties propsA = new Properties();
> propsA.put("service.exported.interfaces", "*");
> propsA.put("service.exported.configs", "ecf.r_osgi.peer");
> Activator.getContext().registerService(ServiceA.class.getName(),
>     new ServiceAImpl(), propsA);
> 
> Thread.sleep(2000);
> 
> // Create and register a remote service
> final Properties propsB = new Properties();
> propsB.put("service.exported.interfaces", "*");
> propsB.put("service.exported.configs", "ecf.r_osgi.peer");
> Activator.getContext().registerService(ServiceB.class.getName(),
>     new ServiceBImpl(), propsB);


Hmm.  Martin...if you can, would you run this sequence in the Eclipse debugger...and turn on tracing for the 
org.eclipse.ecf.osgi.services.remoteserviceadmin/debug/topologymanager and report what it outputs from line 138 of AbstractTopologyManager?

Comment 12 Martin Petzold 2011-02-17 13:40:18 EST

Very interesting feature, I'm learning a lot from you =) thanks again!

[...] (more trace if needed)

(TRACE)[02/17/11;19:35:33:962]TRACING org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManager#advertiseEndpointDescription(advertising endpointDescription=EndpointDescription[containerID=r-osgi://jumper:9279,connectTargetID=null,idFilter=null,rsFilter=null,properties={ecf.endpoint.id.ns=ecf.namespace.r_osgi, endpoint.framework.uuid=3e8c1709-2272-49d2-a3aa-74b4d758735f, endpoint.id=r-osgi://jumper:9279, endpoint.service.id=62, objectClass=[Ljava.lang.String;@35de7497, remote.configs.supported=[Ljava.lang.String;@4268cc6, remote.intents.supported=[Ljava.lang.String;@7ee41d4a, service.id=61, service.imported=true, service.imported.configs=[Ljava.lang.String;@4268cc6}] with advertiser=org.eclipse.ecf.osgi.services.remoteserviceadmin.EndpointDescriptionAdvertiser@9be1041) 

(TRACE)[02/17/11;19:35:35:613]TRACING org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManager#advertiseExportedRegistration(Advertise endpointDesription=EndpointDescription[containerID=r-osgi://jumper:9279,connectTargetID=null,idFilter=null,rsFilter=null,properties={ecf.endpoint.id.ns=ecf.namespace.r_osgi, endpoint.framework.uuid=3e8c1709-2272-49d2-a3aa-74b4d758735f, endpoint.id=r-osgi://jumper:9279, endpoint.service.id=62, objectClass=[Ljava.lang.String;@35de7497, remote.configs.supported=[Ljava.lang.String;@4268cc6, remote.intents.supported=[Ljava.lang.String;@7ee41d4a, service.id=61, service.imported=true, service.imported.configs=[Ljava.lang.String;@4268cc6}].  Problem in unadvertise)

...and after this the ERROR

Comment 13 Martin Petzold 2011-02-17 13:41:53 EST

That was from the *second* service, the following is from the *first* service:

(TRACE)[02/17/11;19:35:20:675]TRACING org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManager#advertiseEndpointDescription(advertising endpointDescription=EndpointDescription[containerID=r-osgi://jumper:9279,connectTargetID=null,idFilter=null,rsFilter=null,properties={ecf.endpoint.id.ns=ecf.namespace.r_osgi, endpoint.framework.uuid=3e8c1709-2272-49d2-a3aa-74b4d758735f, endpoint.id=r-osgi://jumper:9279, endpoint.service.id=57, objectClass=[Ljava.lang.String;@75088a1b, remote.configs.supported=[Ljava.lang.String;@4268cc6, remote.intents.supported=[Ljava.lang.String;@7ee41d4a, service.id=54, service.imported=true, service.imported.configs=[Ljava.lang.String;@4268cc6}] with advertiser=org.eclipse.ecf.osgi.services.remoteserviceadmin.EndpointDescriptionAdvertiser@9be1041)

Comment 14 Scott Lewis 2011-02-17 15:09:46 EST

(In reply to comment #13)
> That was from the *second* service, the following is from the *first* service:
> 
> (TRACE)[02/17/11;19:35:20:675]TRACING
> org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManager#advertiseEndpointDescription(advertising
> endpointDescription=EndpointDescription[containerID=r-osgi://jumper:9279,connectTargetID=null,idFilter=null,rsFilter=null,properties={ecf.endpoint.id.ns=ecf.namespace.r_osgi,
> endpoint.framework.uuid=3e8c1709-2272-49d2-a3aa-74b4d758735f,
> endpoint.id=r-osgi://jumper:9279, endpoint.service.id=57,
> objectClass=[Ljava.lang.String;@75088a1b,
> remote.configs.supported=[Ljava.lang.String;@4268cc6,
> remote.intents.supported=[Ljava.lang.String;@7ee41d4a, service.id=54,
> service.imported=true, service.imported.configs=[Ljava.lang.String;@4268cc6}]
> with
> 


Thanks Martin...this is great.  What I was looking for was the value of endpoint.service.id=<value> in the endpoint descriptions.  The two distinct values above (57 and 62) are right/correct...as these are two distinct services.

In looking at the implementation of public equals(Object) in org.osgi.services.remoteserviceadmin.EndpointDescription, I was surprised to see that it *only* uses the EndpointDescription.getId() value to test equality...which means that two separate EndpointDescriptions with same ecf containerID...i.e. r-osgi://jumper:9279 ... will return 'true'.  This is why you are seeing what you are seeing.

The reason I was surprised by this aspect of the OSGi EndpointDescription class is that obviously the container ID name (i.e. r-osgi://jumper:9279) isn't the only thing that matters for determining the equality of EndpointDescriptions...i.e. as you have two endpoint descriptions...for two different services, with the same value returned from getId() (and so equals returns true).  This aspect of the OSGi EndpointDescription class equals implementation seems wrong to me, and I'll probably initiate a discussion with the spec authors over the current impl of equals (and isSameService) when I can.

So given this, I'm either going to:

a) amend the ServiceInfoKey.equals (and hashCode) implementation to take into account the endpoint.service.id...and the frameworkUUID...for determining whether the endpoint descriptions are equal (along with the existing test using EndpointDescription.equals)

or

b) change the ECF EndpointDescription.equals to override OSGi's EndpointDescription.equals to incorporate/use the endpoint.service.id (and frameworkUUID if present) in equality testing of EndpointDescriptions.  

I need to give some thought to a and b to decide which is better/right, but approach either will fix this bug.  I'll notify here when the fix is released to master.

Comment 15 Martin Petzold 2011-02-17 15:41:43 EST

Please consider also my (still old) problems I have with containers on consumer side while container creation. Event though this might be nothing about this bug, a correct equals of EndpointDescription could be importand in several uses...

Comment 16 Scott Lewis 2011-02-17 15:44:40 EST

(In reply to comment #15)
> Please consider also my (still old) problems I have with containers on consumer
> side while container creation. Event though this might be nothing about this
> bug, a correct equals of EndpointDescription could be importand in several
> uses...

Yeah, I agree that a correct equals of EndpointDescription is essential...and I'm almost done with it/ready to commit...but I'm not sure if I understand what you mean by the connection to the old problems about containers on consumer side...?

Comment 17 Martin Petzold 2011-02-17 15:54:34 EST

It's still about topology management/container selection. There was a bug/problem with multiple services (same type) from different hosts. This is still my main problem of running my simulation environment. You told me a lot about this.

If this bug is fixed I can go on and implement a consumer container selecteor for my use case (if the problem is still present with your new RSA impl). There I get an EndpointDescription and select/create based...this is the connection/other use where people could be addicted to correct equals.

I will work patient on all the problems until it works, because my simulation implementation based on ECF is really nice and perhaps it could be an app for marketplace.

Comment 18 Scott Lewis 2011-02-17 17:50:16 EST

(In reply to comment #17)
> It's still about topology management/container selection. There was a
> bug/problem with multiple services (same type) from different hosts. This is
> still my main problem of running my simulation environment. You told me a lot
> about this.
> 
> If this bug is fixed I can go on and implement a consumer container selecteor
> for my use case (if the problem is still present with your new RSA impl). 

I don't think I understand your use case, but it sounds as if implementing your own consumer container selector might be what you want/need.

>There
> I get an EndpointDescription and select/create based...this is the
> connection/other use where people could be addicted to correct equals.

One thing I want to point out Martin:  The RSA specification doesn't describe the required behavior for a topology manager...ECF's 'BasicTopologyManager' (class: org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManager) is a topology manager that implements the remote services (chap 13) specification in the broadest possible way.   With the IHostContainerSelector and IConsumerContainerSelector services (and others...like the IEndpointDescriptionAdvertiser or IServiceInfoFactory) you can customize the ECF RSA impl pretty easily... if you have a use case that dictates that.

But another option available to you is to implement your own topology manager...for the consumer and/or the host...using the ECF RSA impl as the base (e.g. AbstractTopologyManager, etc).  Doing this would allow you to control very precisely what/how remote services were exported by the host...and how imported by the consumer.  This flexibility (creating your own topology managers) is flexibility introduced by the RSA specification.  ECF's impl just happens to also have flexibility in other areas...e.g. the I*ContainerSelector, IEndpointDescriptionAdvertiser, IServiceInfoFactory etc...these are services that I introduced so that the ECF impl could be customized easily by others...when the use case dictates it (for example, wanting to export a set of services on one container, or multiple containers, or some specific set of containers, etc).

Now I know that all these things (like RSA spec, ECF's impl, ECF's RSA customization) are all new...and it will take time to document them, and debug them.  But they do allow for a good degree of control of remote service export/import and the handling of a lot more sophisticated use cases for remote services that the basic remote services specification.

> 
> I will work patient on all the problems until it works, because my simulation
> implementation based on ECF is really nice and perhaps it could be an app for
> marketplace.

That's great...I would love to see your app in the marketplace.  If you do this and would like me to blog about it I'm happy to do so.  Please let all of the ecf community know...via blog postings (and please notify on ecf-dev mailing list about anything that you are saying publicly).

Comment 19 Scott Lewis 2011-02-17 18:01:10 EST

Fix released to master:  http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/commit/?id=1016cc66766c3271984c19f0057f0b2ebdcfdadb

Resolving as fixed.

Martin, please test with your system to verify...and reopen if you find any problems.

Comment 20 Martin Petzold 2011-02-17 18:06:30 EST

(In reply to comment #18)
> (In reply to comment #17)
> > [...]  The RSA specification doesn't describe
> the required behavior for a topology manager...ECF's 'BasicTopologyManager'
> (class:
> org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManager) is a
> topology manager that implements the remote services (chap 13) specification in
> the broadest possible way.   With the IHostContainerSelector and
> IConsumerContainerSelector services (and others...like the
> IEndpointDescriptionAdvertiser or IServiceInfoFactory) you can customize the
> ECF RSA impl pretty easily... if you have a use case that dictates that.
> 
> But another option available to you is to implement your own topology
> manager...for the consumer and/or the host...using the ECF RSA impl as the base

Ah okay, this is slightly new to me. I have not read all of the RSA specs yet.
So we need to distinct these two things precisely: RSA vs. ECF specific in the
docs. I will have to implement one of them for me and will document. Perhaps I
should give back the job of Javadocs about AbstractContainerSelector etc. to
you though.

Comment 21 Scott Lewis 2011-02-17 18:19:15 EST

(In reply to comment #20)
<stuff deleted>
> 
> Ah okay, this is slightly new to me. I have not read all of the RSA specs yet.

No, I wouldn't expect you to.

> So we need to distinct these two things precisely: RSA vs. ECF specific in the
> docs. 

Yes, that's right.  Generally, the classes that are subclasses of an OSGi class (e.g. EndpointDescription) or implementations of OSGi interfaces (e.g. RemoteServiceAdmin) are ECF implementations of the RSA spec.  The interfaces that are in the ECF remoteserviceadmin area (i.e. I*.class in org.eclipse.ecf.services.remoteserviceadmin package) are ECF-specific services, that allow customization of the ECF RSA impl (e.g. IHostContainerSelector).

>I will have to implement one of them for me and will document. 

You should probably take a look at this class:  org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManager

BTW...I'm completely open to implementing other topology managers also...I just have limited resources to do so...given that there's so much documentation to do, etc.

>Perhaps I
> should give back the job of Javadocs about AbstractContainerSelector etc. to
> you though.

Ok, that sounds fine...I have been doing javadocs on the I* services in the RSA impl, as well as ECF's EndpointDescription class and RemoteConstants...and am nearly ready to begin working on documenting the Abstract* classes.

Would you please add a comment to that effect on bug 329124 for coordination?

Comment 22 Martin Petzold 2011-02-20 17:46:26 EST

[log;+0100 2011.02.20 23:35:20:552;ERROR;org.eclipse.ecf.provider.jmdns;handleRuntimeException]
java.lang.IllegalArgumentException: Missing attr: )
	at org.osgi.service.remoteserviceadmin.EndpointDescription.matches(EndpointDescription.java:591)
	at org.eclipse.ecf.osgi.services.remoteserviceadmin.EndpointDescriptionLocator.isMatch(EndpointDescriptionLocator.java:610)
	at org.eclipse.ecf.osgi.services.remoteserviceadmin.EndpointDescriptionLocator.getMatchingEndpointListenerHolders(EndpointDescriptionLocator.java:599)
	at org.eclipse.ecf.osgi.services.remoteserviceadmin.EndpointDescriptionLocator.getMatchingEndpointListenerHolders(EndpointDescriptionLocator.java:555)
	at org.eclipse.ecf.osgi.services.remoteserviceadmin.EndpointDescriptionLocator.queueEndpointDescription(EndpointDescriptionLocator.java:416)
	at org.eclipse.ecf.osgi.services.remoteserviceadmin.EndpointDescriptionLocator$LocatorServiceListener.handleEndpointDescription(EndpointDescriptionLocator.java:846)
	at org.eclipse.ecf.osgi.services.remoteserviceadmin.EndpointDescriptionLocator$LocatorServiceListener.handleOSGiServiceEndpoint(EndpointDescriptionLocator.java:827)
	at org.eclipse.ecf.osgi.services.remoteserviceadmin.EndpointDescriptionLocator$LocatorServiceListener.handleService(EndpointDescriptionLocator.java:817)
	at org.eclipse.ecf.osgi.services.remoteserviceadmin.EndpointDescriptionLocator$LocatorServiceListener.serviceDiscovered(EndpointDescriptionLocator.java:800)
	at org.eclipse.ecf.discovery.AbstractDiscoveryContainerAdapter.fireServiceDiscovered(AbstractDiscoveryContainerAdapter.java:156)
	at org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryContainer.fireDiscovered(JMDNSDiscoveryContainer.java:366)
	at org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryContainer$2.run(JMDNSDiscoveryContainer.java:327)
	at org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryContainer$1.run(JMDNSDiscoveryContainer.java:125)
	at java.lang.Thread.run(Unknown Source)
Caused by: org.osgi.framework.InvalidSyntaxException: Missing attr: )
	at org.osgi.framework.FrameworkUtil$FilterImpl$Parser.parse_attr(FrameworkUtil.java:1465)
	at org.osgi.framework.FrameworkUtil$FilterImpl$Parser.parse_item(FrameworkUtil.java:1386)
	at org.osgi.framework.FrameworkUtil$FilterImpl$Parser.parse_filtercomp(FrameworkUtil.java:1328)
	at org.osgi.framework.FrameworkUtil$FilterImpl$Parser.parse_filter(FrameworkUtil.java:1293)
	at org.osgi.framework.FrameworkUtil$FilterImpl$Parser.parse(FrameworkUtil.java:1267)
	at org.osgi.framework.FrameworkUtil$FilterImpl.newInstance(FrameworkUtil.java:377)
	at org.osgi.framework.FrameworkUtil.createFilter(FrameworkUtil.java:76)
	at org.osgi.service.remoteserviceadmin.EndpointDescription.matches(EndpointDescription.java:588)
	... 13 more

Comment 23 Scott Lewis 2011-02-20 17:59:28 EST

(In reply to comment #22)
> [log;+0100 2011.02.20
> 23:35:20:552;ERROR;org.eclipse.ecf.provider.jmdns;handleRuntimeException]
> java.lang.IllegalArgumentException: Missing attr: )
>     at
<stuff deleted>

I think for this issue it would probably be better to reopen bug 337653 and re-close this bug, as I think this has more to do with the introduction of bug 337653 than this issue.

One question though that I would like you to add to reopening 337653:  Are you setting allowLoopbackReferences=true, or allowing it to be false/default?  I would expect it to be the latter, and this bug is being caused by a trivial syntax issue...which I will address right now.

Comment 24 Martin Petzold 2011-02-20 18:04:19 EST

Closed. see #23.