Community
Participate
Working Groups
Taken from https://bugs.eclipse.org/229922 ------ > Scott, just to make sure that it's not a port problem, try: > -Dnet.slp.port=10427 > because the slp plugin will not run on unix-like system when eclipse is started > as an unprivilledged user. The slp protocol uses port 427 by default. > Maybe, the "The activator XYZ is invalid" is Equinox funny way of saying that > there was an exception thrown when starting the bundle. You can also verify > this by starting the bundle through the console a second time. I just found this in the logs of a 3.4 "Eclipse for RCP/Plug-in Developers", at the bottom of a long stack trace: Caused by: java.lang.RuntimeException: You have to be root to open port 427 at ch.ethz.iks.slp.impl.SLPCore.init(SLPCore.java:292) at ch.ethz.iks.slp.impl.Activator.start(Activator.java:53) I'm running on linux as a non-root user. Am I to expect this exception upon every launch of Eclipse? (kind of contradicts the notion of exception ;-) Am I supposed to configure the ports for SLP (even though I don't know what SLP _is_ in the first place)?
The problem is, that the SLP spec [1] defines 427 as the default listening port. a) Changing it to some high port > 1024 effectively renders the jSLP useless to integrate with existing infrastructure (especially as OpenSLP (most common DA) doesn't even allow to configure the port). b) Alternatively jSLP can be set to UA only mode (net.slp.uaonly=true) where it doesn't need to bind to 427. But this break service announcement with the slp provider and limits it to service discovery only. Half the functionality in org.eclipse.ecf.discovery.IDiscoveryContainerAdapter would be broken. IMO this can only be done if IDCA is split up into Locator and Announcer interfaces in 3.0. c) So the only option is to let the user decide. Either use a different port or UA only mode. Unfortunately this is currently only possible via system properties to which we have no access, nor do we have UI for it yet [2][3]. That's why one gets this monstrous and frightening although harmless stack trace upon provider activation. [1] http://tools.ietf.org/html/rfc2608 [2] https://bugs.eclipse.org/217978 [3] https://bugs.eclipse.org/217981
Another question: why is listening on port 427 initiated at launch time without any action by the user? Wouldn't it be better to remain passive until the user actively chooses to connect to some services/discovery? Since ECF is bundled in standard Eclipse packages it shouldn't be assumed that any connections are desired simply because ECF is installed. > monstrous and frightening although harmless stack I'm not that much frightened ;-) but I'd like to have a clean log so I will be effectively alerted when really important things happen.
(In reply to comment #2) > Another question: why is listening on port 427 initiated > at launch time without any action by the user? > > Wouldn't it be better to remain passive until the user > actively chooses to connect to some services/discovery? This is a tougher call than it might seem to be. For lots of things you are exactly right...it is better to remain passive...and for all of the other services that ECF provides, currently we are passive (which is considered a bug by some...e.g. not having automatic login to IM accounts). But discovery is somewhat different, as it's actually a meta-service...making access to other services easier/more automatic. So it does make sense to have such a meta-service available automatically. I agree with you, however, that we need to find a way to make such activation not result in the problems identified in this bug...i.e. requiring root access, reporting failure to log, etc. Also I believe we do need to provide some UI in Eclipse (e.g. preferences) in order to allow users to configure. Markus and others have investigated the availability of a preferences UI to the Equinox configuration API...which would be ideal I think, but last I heard that UI was not being made available by IBM via open source...and it could be much wasted effort to us (ECF) to build a new/own UI for Equinox configuration. > > Since ECF is bundled in standard Eclipse packages > it shouldn't be assumed that any connections are desired > simply because ECF is installed. In general this is true for ECF services, but as discussed above, discovery has a slightly different status among ECF services. > > > monstrous and frightening although harmless stack > > I'm not that much frightened ;-) > but I'd like to have a clean log so I will be effectively > alerted when really important things happen. > Yes, fully agreed. We do need to deal with this issue somehow.
(In reply to comment #3) > > > monstrous and frightening although harmless stack > > > > I'm not that much frightened ;-) > > but I'd like to have a clean log so I will be effectively > > alerted when really important things happen. > > > > Yes, fully agreed. We do need to deal with this issue somehow. I have had a look at this issue already and the changes necessary in jSLP can hopefully be done in the 2.1 time frame. Basically SLPCore instantiation needs to be delayed (upon service retrieval) so configuration can be applied before. The configuration itself should be done via ConfigAdmin [1]. [1] https://bugs.eclipse.org/217978
Setting target milestone to 2.1 and assigning to Markus.
http://sourceforge.net/tracker/index.php?func=detail&aid=2042842&group_id=151721&atid=781930 has been created to track this issue in upstream.
#2042842 has been fixed over at sf.net. Now we need to find way how to best consume it in ECF. We can a) Create a new CQ for jSLP 1.0.0.RC5 and piggyback it for Orbit + update code in Orbit b) Wait for the jSLP to be moved to eclipse.org/ECF. Scott? Dunno what's feasible in the 2.0.1 time frame.
(In reply to comment #7) > #2042842 has been fixed over at sf.net. Now we need to find way how to best > consume it in ECF. We can > > a) Create a new CQ for jSLP 1.0.0.RC5 and piggyback it for Orbit + update code > in Orbit > b) Wait for the jSLP to be moved to eclipse.org/ECF. Scott? If b is acceptable to everyone involved, I don't believe there is any need to wait...either Markus and/or Jan can commit the project to the ECF CVS repo...probably in the <home>/providers. I'm not sure how this would be handled WRT the EF legal...so if b is the way to go please contact them (and cc me) about how best to accomplish this. OTOH, if the CQ route is taken (a), I suspect that it will go through pretty quickly (in time for 2.0.1) if it's started immediately.
*** Bug 244383 has been marked as a duplicate of this bug. ***
CQ https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2585 has been filed for jSLP 1.0.0.RC5
With CQs [1][2] on their way, 2.0.1 should be feasible. [1] https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2585 [2] https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2586
(In reply to comment #1) > b) Alternatively jSLP can be set to UA only mode (net.slp.uaonly=true) where it > doesn't need to bind to 427. But this break service announcement with the slp > provider and limits it to service discovery only. Half the functionality in > org.eclipse.ecf.discovery.IDiscoveryContainerAdapter would be broken. IMO this > can only be done if IDCA is split up into Locator and Announcer interfaces in > 3.0. To summarize what has been done in upstream to address this bug: > Instead of using properties to set the jSLP into a specific mode at > startup, I've move the multicast socket initialization out of > SLPCore.init() into its own method which gets only called when Advertiser > functionality is used by a consumer. If binding fails, this will still > result in a BindException though. However this is acceptable as one needs > to run jSLP as root or with net.slp.port > 1024 if one wants to use SA > functionality anyway. This simply allows jSLP to work without root > privileges or port >1024 if only UA functionality is used. > The net.slp.uaonly property has been removed due to this change. This results in the jSLP provider to not crash during bundle activation anymore but the first time a consumer tries to get an Advertiser service from the Advertiser ServiceFactory with: java.lang.RuntimeException: You have to be root to open port 427 at ch.ethz.iks.slp.impl.SLPCore.initMulticastSocket(SLPCore.java:354) at ch.ethz.iks.slp.impl.Activator$1.getService(Activator.java:58) at org.eclipse.osgi.framework.internal.core.ServiceUse$1.run(ServiceUse.java:117) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.ServiceUse.getService(ServiceUse.java:115) at org.eclipse.osgi.framework.internal.core.ServiceRegistrationImpl.getService(ServiceRegistrationImpl.java:430) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.getService(BundleContextImpl.java:894) at org.osgi.util.tracker.ServiceTracker.addingService(ServiceTracker.java:419) at org.osgi.util.tracker.ServiceTracker$Tracked.trackAdding(ServiceTracker.java:1064) at org.osgi.util.tracker.ServiceTracker$Tracked.trackInitialServices(ServiceTracker.java:926) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:330) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:274) at org.eclipse.ecf.internal.provider.jslp.Activator.getAdvertiser(Activator.java:77) ... No ECF code has been changed, just the jSLP bundle in Upstream and Orbit. Btw. we need to wait for Orbit to spin off a new build.
