Community
Participate
Working Groups
It would be great to have an IApplication startup point to allow an ECF server to be brought up at runtime, rather than having to hand-craft an ExtensionRegistry each time.
Created attachment 72903 [details] Provides a simple IApplication startup point Using this, you can do 'apps' in the console, and run with -application on the command line. You can also do 'startApp org.eclipse.ecf.provider.ECFTCPServer 9999 foohost test' to bring up a server on ecftcp://foohost:9999/test Forgive the obvious coding errors in the ECFTCP stuff ... I was making it up as I went along, so it could certainly use beefing up. However, it sets a good starting point that people could build upon if they wanted. I'm not sure if the start() of the IApplication should block (the return value has a tendancy of shutting it down) but there might be a better return code/value that could be used instead. Note that you can also run multiple ECFTCPServers, simply by starting more entries.
Re: 'the application service has not been started' -- I found that I got that message when I ran from the 'run as application' inside Eclipse, but when I ran e.g. a product (org.eclipse.sdk) and launched it from the -console (startApp org.eclipse....) then it worked. I'm guessing that by default, the -application startup doesn't bring up a necessary service for the application to work. I noted that if the plugins in the startup aren't selected on the application service, it doesn't start. I'm guessing if you select all of them, it will come up. I've not tried from the command-line ...
OK, a bit more success. It's missing a dependency on org.eclipse.core.runtime, which is what starts the application service. Miss that bundle out, and the application service doesn't start. (I put Require-bundle org.eclipse.core.runtime to get it to work) However, fix that issue and another appears. The PDE launcher adds -pdelaunch to the arguments, yet this isn't stripped out of the launcher that tries to get rid of this flag. I forget where exactly it is, but there's something that gets rid of the Eclipse-specific args. As a result, the server app does start, but then my code tries to parse -pdelaunch as a number and fails. java.lang.NumberFormatException: For input string: "-pdelaunch" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:447) at java.lang.Integer.parseInt(Integer.java:497) at org.eclipse.ecf.provider.app.ECFTCPServer.start(ECFTCPServer.java:42) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:153) at org.eclipse.equinox.internal.app.AnyThreadAppLauncher.run(AnyThreadAppLauncher.java:26) at java.lang.Thread.run(Thread.java:613) You'll note it's in the ECFTCPServer start at this point. If we get it to skip out on args beginning with -, then we'd probably fix it. OTOH starting from the OSGi console should not have this problem, nor should running as the command line. I'm tempted to blame PDE/Equinox arg parsing for this one.
See also bug 195454 where I've raised the issue regarding the -pdelaunch flag being incorrectly supplied to -application launches.
Don't set it to 'main'. If you do that, you can only run one from the -console at a time.
(In reply to comment #5) > Don't set it to 'main'. If you do that, you can only run one from the -console > at a time. > OK. Thanks Alex for tracking this down. I'll add the necessary check to the ECFTCPServer class (for -pdelaunch param and for other ECF params which I want to add) and test, then checkin. Shouldn't be too much of a problem to work around the pdelaunch stuff. It's kind of problematic that using this requires adding dependency on org.eclipse.core.runtime...i.e. why should there be a dependency on org.eclipse.core.runtime if I'm starting a non-eclipse app (?). Especially since we were just asked to *remove* dependencies on org.eclipse.core.runtime from core plugins (including org.eclipse.ecf.provider) in bug #164890. Do you know if there is any other way to have this application service started in a timely way?
Agreed that it brings in a lot of crap, but if you have 'Import-Package' on something, it doesn't bring in the services (since it doesn't start the package), whereas if you have Require-Bundle, I believe that it does start it. It might be better to extract out the ECFTCPServer (and feel free to give it a better name :-) into a fragment, so that only the fragment has dependencies on o.e.c.runtime. This seems like it's going to be a problem for anyone running applications who doesn't have a dependency on that, and who is using 'any'. There's basically a race condition, and 'main' doesn't solve it, it just hides it. I'll raise a separate bug about that, and do some digging to find out what's going on.
Urgh. This is ugly. The Equinox application launcher basically fails when the thread is 'any'. The org.eclipse.core.runtime dependency doesn't change anything, so it's not needed. I suspect that the most common case would be to launch a server from a command line, so it might be better to default to 'main' for now. I've got some test code which demonstrates the problem ... basically, using 'any' works, but then the Equinox launcher fails to notice that the app has started, and so complains vigourously. You'll notice that if you launch the app, you can see the output of it running in the Console, but then the framework thinks that it's not there, and forcefully kills the VM. I'll put a new bug report for the equinox launcher, but for now it might be better to run with 'main', since that will solve the goal of getting the app up.
I've raised bug 195546 for the issue regarding the thread="main" issue.
(In reply to comment #9) > I've raised bug 195546 for the issue regarding the thread="main" issue. > Thanks Alex. I'll leave at thread="main" for the time being and add myself to the bug 195546. RE: distribution of this application...sounds like you would prefer a fragment so that this IApplication can be added onto the existing 1.0.0 codebase...is that right? Otherwise, I'm inclined to have it be in 1.0.1 of ECF along with some other small fixes. But do let us know about your inclination here...we'll do whatever's needed.
I mentioned a fragment if adding the dependency on org.eclipse.core.runtime was needed, which it looks like it probably isn't. I think I was chasing a red herring there, owing to 195546. I think including it in ECF 1.0.1 is a reasonable idea. Plus, I'm not sure if you can define any plugin.xml content in the fragment :-) If anyone wants it sooner than that, it shouldn't be too hard to take the attachment I provided and convert it into a new bundle for their use, or indeed, the same with yours. Can you start the app with -console, and do 'startApp org.eclipse.ecf...ECFTCPServer 1234' to bring up a 2nd (or 3rd) instance of the server with the thread=main attribute? That was the thing I was mostly concerned about being able to do.
I've checked in a new class GenericServer with application id: org.eclipse.ecf.provider.GenericServer To start this server application (with 1.0.1 version of org.eclipse.ecf.provider plugin), eclipse.exe -application org.eclipse.ecf.provider.GenericServer This will start a server with hostname=localhost, port=3282, groupname=server...i.e. id=ecftcp://localhost:3282/server. The output upon startup looks like this: Putting server localhost:3282 on the air... Creating container with id=ecftcp://localhost:3282/server keepAlive=30000 GenericServer localhost:3282 on the air. It's also possible to provide the port hostname groupname and keepAlive (ms) For example: eclipse.exe -application org.eclipse.ecf.provider.GenericServer 3285 ecf.eclipse.org mygroup 20000 Putting server ecf.eclipse.org:3285 on the air... Creating container with id=ecftcp://ecf.eclipse.org:3285mygroup keepAlive=20000 GenericServer ecf.eclipse.org:3285 on the air. or eclipse.exe -application org.eclipse.ecf.provider.GenericServer 3333 Putting server localhost:3333 on the air... Creating container with id=ecftcp://localhost:3333/server keepAlive=30000 GenericServer localhost:3333 on the air. Another way to start a number of servers and groups is to create a file with the server configuration...for example: <server> <connector protocol="ecftcp" hostname="localhost" port="3282" timeout="30000"> <group name="server"/> <group name="foobar"/> </connector> <connector protocol="ecftcp" hostname="localhost" port="3283" timeout="30000"> <group name="server"/> <group name="foobar"/> </connector> </server> If this content is in file ./server.xml Then the command line would be: eclipse.exe -application org.eclipse.ecf.provider.GenericServer -config server.xml And the output would be: Putting server localhost:3282 on the air... Creating container with id=ecftcp://localhost:3282/server keepAlive=30000 Creating container with id=ecftcp://localhost:3282/foobar keepAlive=30000 GenericServer localhost:3282 on the air. Putting server localhost:3283 on the air... Creating container with id=ecftcp://localhost:3283/server keepAlive=30000 Creating container with id=ecftcp://localhost:3283/foobar keepAlive=30000 GenericServer localhost:3283 on the air. This will be in 1.0.1 release (probably sometime week of July 9).
Also put instructions for using this in wiki: http://wiki.eclipse.org/ECF_Servers Marking as resolved. Not yet released (ETA 7/13/2007 for 1.0.1 release).
IMHO isn't it more likely that people will want to change the group rather than the host? I.e. wouldn't swapping the group/host arguments be sensible? In addition, does this allow the ECF server to be started as an Eclipse App? For example, you could do: java -jar org.eclipse.osgi -console -noExit osgi> startApp org.eclipse.ecf.provider.GenericServer 1234 osgi> startApp org.eclipse.ecf.provider.GenericServer 5678 to launch two simultaneously. This is as long as the thread="main' doesn't get in the way ...
Hi Alex, (In reply to comment #14) > IMHO isn't it more likely that people will want to change the group rather than > the host? I.e. wouldn't swapping the group/host arguments be sensible? Sure, seems reasonable. I've made the change in the source and updated the docs here: http://wiki.eclipse.org/ECF_Servers and in the usage/help output for the GenericServer IApplication. > > In addition, does this allow the ECF server to be started as an Eclipse App? > For example, you could do: > > java -jar org.eclipse.osgi -console -noExit > osgi> startApp org.eclipse.ecf.provider.GenericServer 1234 > osgi> startApp org.eclipse.ecf.provider.GenericServer 5678 > > to launch two simultaneously. This is as long as the thread="main' doesn't get > in the way ... > Yes, this should work fine. I haven't tried it out yet, but have updated the docs. If you could try this out and let everyone know on this bug it would be appreciated.
I didn't have much luck with this. You made the visible="false" flag on the runtime, so I'm not sure if it would even show up. There also seems to be a bug in the application launching code; when you launch an app, it only shows you the applications defined in the bundle whose application is running, so unless you start up with -application ...GenericServer, you won't even see these application points. I'm not sure if that's a bug or by design, but it seems a bit of an odd design decision if that's the case. Will raise another bug for that issue. Alex.
NB looks like bug 195982 has the answer; put eclipse.application.registerDescriptors=true in the startup (system property or config.ini). I'll check it out with the 1.0.1 later (with my new-and-improved checkout from CVS :-) and report back here; perhaps it's worth a note on the FAQ page.
(In reply to comment #16) > I didn't have much luck with this. You made the visible="false" flag on the > runtime, so I'm not sure if it would even show up. There also seems to be a bug > in the application launching code; when you launch an app, it only shows you > the applications defined in the bundle whose application is running, so unless > you start up with -application ...GenericServer, you won't even see these > application points. I'm not sure if that's a bug or by design, but it seems a > bit of an odd design decision if that's the case. Will raise another bug for > that issue. > > Alex. > The visible flag wasn't set at all in the application declaration previously, I've now set it to 'true'.
I'm reopening this because there's some weird things in the -console case. I've tried it with the -application flag (and it's fine), but from the console, if you do startApp org.eclipse.ecf.provider.Genericserver from the console, it doesn't print out "on the air" and you can't connect to the given port. BTW the magic incantation to get a console with multiple starting apps is to get rid of the 'eclipse.ignoreApp=true' that PDE insists on applying, and 'eclipse.application.registerDescriptors=true'. Obviously. It's possible to have 2 application descriptors; one with a 'main' thread, and one with an 'any' thread, pointing to the same class. That way, you can run one from the command line and one from the console if you want. If you have an extra application, it might Can we add an extra config to allow the console to run on the 'any' thread? It might be a good idea to have the GenericServer start on the 'any' thread, and have GenericServerMain as the 'main' thread. The fix might be in Equinox 3.3.1. Something like this: <extension id="MainGenericServer" point="org.eclipse.core.runtime.applications"> <application cardinality="*" thread="main" visible="true"> <run class="org.eclipse.ecf.provider.app.GenericServer"/> </application> </extension> <extension id="GenericServer" point="org.eclipse.core.runtime.applications"> <application cardinality="*" thread="any" visible="true"> <run class="org.eclipse.ecf.provider.app.GenericServer"/> </application> </extension> Note: there's another bug where if you have an app which is a substring of another app (e.g. Main, MainOne) then you can't stop/start the shorter one. So don't have GenericServer and GenericServerMain :-)
(In reply to comment #19) > I'm reopening this because there's some weird things in the -console case. I've > tried it with the -application flag (and it's fine), but from the console, if > you do startApp org.eclipse.ecf.provider.Genericserver from the console, it > doesn't print out "on the air" and you can't connect to the given port. > > BTW the magic incantation to get a console with multiple starting apps is to > get rid of the 'eclipse.ignoreApp=true' that PDE insists on applying, and > 'eclipse.application.registerDescriptors=true'. Obviously. > > It's possible to have 2 application descriptors; one with a 'main' thread, and > one with an 'any' thread, pointing to the same class. That way, you can run one > from the command line and one from the console if you want. If you have an > extra application, it might > > Can we add an extra config to allow the console to run on the 'any' thread? It > might be a good idea to have the GenericServer start on the 'any' thread, and > have GenericServerMain as the 'main' thread. The fix might be in Equinox 3.3.1. > Something like this: > > <extension > id="MainGenericServer" > point="org.eclipse.core.runtime.applications"> > <application > cardinality="*" > thread="main" > visible="true"> > <run > class="org.eclipse.ecf.provider.app.GenericServer"/> > </application> > </extension> > <extension > id="GenericServer" > point="org.eclipse.core.runtime.applications"> > <application > cardinality="*" > thread="any" > visible="true"> > <run > class="org.eclipse.ecf.provider.app.GenericServer"/> > </application> > </extension> > > Note: there's another bug where if you have an app which is a substring of > another app (e.g. Main, MainOne) then you can't stop/start the shorter one. So > don't have GenericServer and GenericServerMain :-) > If you could submit as a patch I'll apply/test checkin. Sort of ugly to have two applications, but I guess with current Equinox issues we can't get around it any other way. Could I ask one more thing, Alex? Could you provide some documentation of the right incantation for here: http://wiki.eclipse.org/ECF_Servers If you can't, that's fine...I will get to it...but probably have to consult with you as haven't been able to do the parallel testing. Thanks.
Let me supply a patch and update the wiki, or attach text to this bug.
Created attachment 73492 [details] Provides 2 application extension points; AppGenericServer (main) and GenericServer (any) We need these 2 separate ones, because the server doesn't like starting 'any' threads on the main thread in 3.3.0; hopefully, it will be fixed in 3.3.1. The workaround in the meantime is to have 2 app descriptors.
Updated wiki as requested.
(In reply to comment #23) > Updated wiki as requested. > Thank you kindly Alex...for both the patch and the wiki docs update. I've applied given patch and checked in. I've also updated IP log for project to include this contribution. I'll try resolving bug again.
Checked out HEAD, checked out the wiki, added an extra parameter for the wiki ;-) Closing
I haven't tried this on Windows but on Linux, I did a fresh install of Eclipse Europa and the ECF plugins from the Europa discovery site. Launched eclipse and confirmed the the ECF functionality was working properly. I then ran the following command from the command-line: ./eclipse -application org.eclipe.ecf.provider.AppGenericServer I got the following message in the log file. !SESSION 2007-07-13 21:25:14.996 ----------------------------------------------- eclipse.buildId=I20070625-1500 java.version=1.6.0_01 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US Framework arguments: -application org.eclipse.ecf.provider.AppGenericServer Command-line arguments: -os linux -ws gtk -arch x86 -application org.eclipse.ecf.provider.AppGenericServer !ENTRY org.eclipse.osgi 4 0 2007-07-13 21:25:17.035 !MESSAGE Application error !STACK 1 java.lang.RuntimeException: Application "org.eclipse.ecf.provider.AppGenericServer" could not be found in the registry. The applications available are: org.eclipse.help.base.infocenterApplication, org.eclipse.help.base.helpApplication, org.eclipse.help.base.indexTool, org.eclipse.ui.ide.workbench, org.eclipse.update.core.standaloneUpdate, org.eclipse.update.core.siteOptimizer, org.eclipse.equinox.app.error, org.eclipse.ant.core.antRunner, org.eclipse.ecf.example.clients.chatroomrobot, org.eclipse.ecf.example.clients.chatsorobot, org.eclipse.ecf.example.clients.chatrobot, org.eclipse.ecf.presence.bot.chatRoomRobot, org.eclipse.ecf.presence.bot.imRobot. at org.eclipse.equinox.internal.app.EclipseAppContainer.startDefaultApp(EclipseAppContainer.java:236) at org.eclipse.equinox.internal.app.EclipseAppContainer.start(EclipseAppContainer.java:92) at org.eclipse.equinox.internal.app.Activator.addingService(Activator.java:129) at org.osgi.util.tracker.ServiceTracker$Tracked.trackAdding(ServiceTracker.java:1064) at org.osgi.util.tracker.ServiceTracker$Tracked.track(ServiceTracker.java:1042) at org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:967) at org.eclipse.osgi.framework.internal.core.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:94) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:1224) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:195) at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:141) at org.eclipse.osgi.framework.internal.core.Framework.publishServiceEventPrivileged(Framework.java:1603) at org.eclipse.osgi.framework.internal.core.Framework.publishServiceEvent(Framework.java:1578) at org.eclipse.osgi.framework.internal.core.ServiceRegistrationImpl.<init>(ServiceRegistrationImpl.java:103) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.createServiceRegistration(BundleContextImpl.java:657) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:609) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:675) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:359) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:504) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443) at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
This bug fix has occurred since the June 29 Europa release, and the Europa update site can't be updated. We will be doing a build and deploy to ECF update site on 7/14/2007 or 7/15/2008 with these changes. (In reply to comment #26) > I haven't tried this on Windows but on Linux, I did a fresh install of Eclipse > Europa and the ECF plugins from the Europa discovery site. Launched eclipse and > confirmed the the ECF functionality was working properly. > > I then ran the following command from the command-line: > > ./eclipse -application org.eclipe.ecf.provider.AppGenericServer > > I got the following message in the log file. > > !SESSION 2007-07-13 21:25:14.996 > ----------------------------------------------- > eclipse.buildId=I20070625-1500 > java.version=1.6.0_01 > java.vendor=Sun Microsystems Inc. > BootLoader constants: OS=linux, ARCH=x86, WS=gtk, NL=en_US > Framework arguments: -application org.eclipse.ecf.provider.AppGenericServer > Command-line arguments: -os linux -ws gtk -arch x86 -application > org.eclipse.ecf.provider.AppGenericServer > > !ENTRY org.eclipse.osgi 4 0 2007-07-13 21:25:17.035 > !MESSAGE Application error > !STACK 1 > java.lang.RuntimeException: Application > "org.eclipse.ecf.provider.AppGenericServer" could not be found in the registry. > The applications available are: org.eclipse.help.base.infocenterApplication, > org.eclipse.help.base.helpApplication, org.eclipse.help.base.indexTool, > org.eclipse.ui.ide.workbench, org.eclipse.update.core.standaloneUpdate, > org.eclipse.update.core.siteOptimizer, org.eclipse.equinox.app.error, > org.eclipse.ant.core.antRunner, org.eclipse.ecf.example.clients.chatroomrobot, > org.eclipse.ecf.example.clients.chatsorobot, > org.eclipse.ecf.example.clients.chatrobot, > org.eclipse.ecf.presence.bot.chatRoomRobot, > org.eclipse.ecf.presence.bot.imRobot. > at > org.eclipse.equinox.internal.app.EclipseAppContainer.startDefaultApp(EclipseAppContainer.java:236) > at > org.eclipse.equinox.internal.app.EclipseAppContainer.start(EclipseAppContainer.java:92) > at > org.eclipse.equinox.internal.app.Activator.addingService(Activator.java:129) > at > org.osgi.util.tracker.ServiceTracker$Tracked.trackAdding(ServiceTracker.java:1064) > at > org.osgi.util.tracker.ServiceTracker$Tracked.track(ServiceTracker.java:1042) > at > org.osgi.util.tracker.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:967) > at > org.eclipse.osgi.framework.internal.core.FilteredServiceListener.serviceChanged(FilteredServiceListener.java:94) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.dispatchEvent(BundleContextImpl.java:1224) > at > org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:195) > at > org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:141) > at > org.eclipse.osgi.framework.internal.core.Framework.publishServiceEventPrivileged(Framework.java:1603) > at > org.eclipse.osgi.framework.internal.core.Framework.publishServiceEvent(Framework.java:1578) > at > org.eclipse.osgi.framework.internal.core.ServiceRegistrationImpl.<init>(ServiceRegistrationImpl.java:103) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.createServiceRegistration(BundleContextImpl.java:657) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:609) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl.registerService(BundleContextImpl.java:675) > at > org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:359) > at > org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:176) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:504) > at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443) > at org.eclipse.equinox.launcher.Main.run(Main.java:1169) >
