Home » Archived » Eclipse Communications Framework (ECF) » Setting up a generic server nightmare
|
| Re: Setting up a generic server nightmare [message #618610 is a reply to message #618609] |
Mon, 21 May 2007 01:36   |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Abby,
abby wrote:
> Hi,
> I tried following the instructions on the wiki to set up the server,
> but have been unsuccessful so far. I was not able to start the ecf
> generic server as the last point asks to do so. Where to run the start
> command from?
What has to happen is that the plugin org.eclipse.ecf.generic.server
plugin has to be started, via either the OSGi console (see 'help' in the
OSGi console) or via some other method, depending upon how one has
setup/configured equinox. Number 6 in the wiki says:
6) Start the org.eclipse.ecf.server.generic bundle. This can be done via
the server console (with 'start org.eclipse.ecf.server.generic') or can
be setup to start automatically via the
<appserverhome>webapps/bridge/WEB-INF/platform/configuration/config.ini
file.
This plugin (org.eclipse.ecf.server.generic.bundle) reads the extension
point described on the wiki page and loads any other bundles necessary
(including new ones that provide extensions for the extension point).
Is there a war which can just be deployed.
No, the equinox server deploys in terms of bundles, rather than wars.
This doesn't really have anything to do with ECF, per se but it's the
way of this world (Equinox).
How do i deploy
> the plugin created with the extension. Does dropping in bridge suffice?
No, the plugin that you've created must be added to the 'plugins'
directory of wherever you've installed the Equinox server and the ECF
plugins. So basically it goes wherever org.eclipse.ecf.server.generic
goes (and where all the other ECF plugins go).
This is again more an aspect of the Equinox server per se, we're just
using the Equinox runtime to run our bundles. Also BTW, there's a lot
of work planned to go on with Equinox to add server provisioning
(deploy/install/configure/etc) to Equinox. If you are interested in
this please see http://www.eclipse.org/equinox/incubator/provisioning/
> I guess something more detailed would be helpful to someone who has not
> worked with ecf before.
I agree we need to improve both the deploy/install/configure part of ECF
for servers (generic and otherwise) and the documentation. If you file
a bug to this effect it would be appreciated.
We are contributing to the Equinox provisioning work in this area as
well...as much of what ECF can/would depend upon...or will at least
use...Equinox improvements (e.g. the deploy/install/update/start).
If you would file a bug/enhancement request to this effect (improve th e
ECF server deploy/install/configure process) here it would be most
appreciated, and we can use this to track the work. We can't promise to
get to it immediately, but especially since we are involved with the
planned provisioning work it will not go unattended.
>It is a great framework and due to the troubles
> with running provided exmaples and less documentation makes it a little
> discomforting. Any help?
Sure. Hopefully this has been of some help. If you want more please
feel free to ask here, or on ecf-dev@eclipse.org. Also if you want
direct help please feel free to ask me at slewis@composent.com and I'll
help you directly if desired/necessary.
Thanks,
Scott
|
|
|
| Re: Setting up a generic server nightmare [message #618783 is a reply to message #618610] |
Tue, 03 July 2007 19:23 |
Alex McCarrier
Messages: 2
Registered: July 2009 |
Junior Member |
|
|
I think I'm having the same problem as the original poster of this
question. First of all, I am a java developer, I am not an eclipse
plug-in developer. After installing Europa I became really excited about
the collaboration features it said it provided. I would like to provide
that functionality to my team.
That said, I was referred to the wiki where it takes me through this long
process of creating a plug-in project (?) and deploying it to something
called Equinox? I had never heard of equinox until now, so I'm just now
getting a vague impression of what that is.
What it sounds like, is that in order to be able to use collaboration, I
have to become an eclipse plug-in developer, and write my own plugin for
Equinox, which it sounds like is some kind of eclipse-based server
platform? That sounds really messed up. I'm not saying the project is
messed up, I think it's a great idea, and I can't wait to see it work. I
have goofed around on the public ecf server and it's really cool stuff, I
just think it should be easier for USERS to set up their own servers in
house.
When you get that defect created, if there is a voting mechanism, I would
very much like to vote for a more user-oriented server set-up system.
Meanwhile, I'll see about becoming an eclipse plug-in developer and see if
I can't get this thing figured out. :)
|
|
| |
| Re: Setting up a generic server nightmare [message #618785 is a reply to message #618784] |
Wed, 04 July 2007 20:49 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Alex (Blewitt and M),
I'm applying this patch right now (7/4/2007). Doing a little clean up
and adding a few things.
I'm getting a strange exception though, when I go to run or debug:
java.lang.IllegalStateException: Unable to acquire application service.
Ensure that the org.eclipse.core.runtime bundle is resolved and started
(see config.ini).
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:72)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:363)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:176)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
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)
at org.eclipse.equinox.launcher.Main.main(Main.java:1144)
I don't think this has anything to do with the program itself, and must
be my environment (eclipse 3.3 release, windows xp, my workspace), but I
can't figure out what's going on. Anyone recognize this? I haven't
changed config.ini from what came with Eclipse 3.3.
I looked quickly in both bugs.eclipse.org and Google and didn't see
anything obvious/new (I'm assuming this has to just be me as it's too
central to be an unfound bug at this point).
And further question for both Alex's: How would you like me to
distribute this? It can/will be part of ECF 1.0.1 (probably in a week
or so), and you two can get build it yourselves if you want (in
org.eclipse.ecf.provider project/bundle). But let me know please with
comment on bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=195088
Thanks,
Scott
Alex Blewitt wrote:
> I put together a patch which would provide a mechanism to start up an ECF server from the command-line with an -application switch. It's just a prototype at present, but you might want to Cc yourself onto https://bugs.eclipse.org/bugs/show_bug.cgi?id=195088 and if it works out, it should be possible to drop a fragment onto the ECF bundle that would give this functionality.
>
> Alex.
|
|
|
| Re: Setting up a generic server nightmare [message #618786 is a reply to message #618785] |
Wed, 04 July 2007 21:56 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Alex B, Alex M,
I found the problem I was having. When the "thread" property is set to
"any" it's possible to have the application started and run before the
thread that loads/starts the application service has had a chance to do
so. If I change it to this (thread="main") it seems to work fine:
<extension
id="ECFTCPServer"
point="org.eclipse.core.runtime.applications">
<application
cardinality="*"
thread="main">
<run
class="org.eclipse.ecf.provider.app.ECFTCPServer"/>
</application>
</extension>
I'll checkin the code (after changes cleanup and testing this evening
7/4/2007).
Thanks,
Scott
Scott Lewis wrote:
> Hi Alex (Blewitt and M),
>
> I'm applying this patch right now (7/4/2007). Doing a little clean up
> and adding a few things.
>
> I'm getting a strange exception though, when I go to run or debug:
>
> java.lang.IllegalStateException: Unable to acquire application service.
> Ensure that the org.eclipse.core.runtime bundle is resolved and started
> (see config.ini).
> at
> org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:72)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:363)
>
> at
> org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:176)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl.java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:585)
> 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)
> at org.eclipse.equinox.launcher.Main.main(Main.java:1144)
>
>
> I don't think this has anything to do with the program itself, and must
> be my environment (eclipse 3.3 release, windows xp, my workspace), but I
> can't figure out what's going on. Anyone recognize this? I haven't
> changed config.ini from what came with Eclipse 3.3.
>
> I looked quickly in both bugs.eclipse.org and Google and didn't see
> anything obvious/new (I'm assuming this has to just be me as it's too
> central to be an unfound bug at this point).
>
> And further question for both Alex's: How would you like me to
> distribute this? It can/will be part of ECF 1.0.1 (probably in a week
> or so), and you two can get build it yourselves if you want (in
> org.eclipse.ecf.provider project/bundle). But let me know please with
> comment on bug:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=195088
>
> Thanks,
>
> Scott
>
>
> Alex Blewitt wrote:
>> I put together a patch which would provide a mechanism to start up an
>> ECF server from the command-line with an -application switch. It's
>> just a prototype at present, but you might want to Cc yourself onto
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=195088 and if it works
>> out, it should be possible to drop a fragment onto the ECF bundle that
>> would give this functionality.
>> Alex.
|
|
| | | |
| server IApplication id change (please read if you are using ECF generic server IApplication) [message #619049 is a reply to message #618794] |
Mon, 03 September 2007 20:02 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Folks,
As described on this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=202100
It seems like it's going to be necessary to change the application id
for the ECF generic server (there are actually two of them now:
org.eclipse.ecf.provider.GenericServer and
org.eclipse.ecf.provider.AppGenericServer because of bug in Equinox).
The reason for this change is that it would be very desirable to get the
generic server app classes *out* of org.eclipse.ecf.provider plugin (so
that we can set it's execution environment to cdc foundation 1.1). The
natural place for these classes (and the IApplication extension point)
is in org.eclipse.ecf.server.generic.
So why not just make this change?...well, one reason is that it will
mean a change in the generic server application ids that people are
using and therefore a change in the public API...requiring to change
their server invocation. Fairly small change I would say but will break
existing apps.
So my suggestion to resolving 202100 is that this week (prior to 1.1)
that I
1) move the classes from org.eclipse.ecf.provider.app.* to
org.eclipse.ecf.server.generic.app.*.
2) change the app ids to org.eclipse.ecf.server.generic.GenericServer
3) Eliminate the two IApplications...i.e. go to just GenericServer and
remove AppGenericServer (this will require that people use Equinox 3.3.1
to get appropriate behavior as described in bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=193596 We knew we were
going to do this eventually once the Equinox bug is fixed, and if we do
it now hopefully that will prevent any further changes.
So please, if you have any criticisms or concerns about this approach
please let all know via the bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=202100
Scott
Scott Lewis wrote:
> For everyone's info...
>
> The mentioned bug has been fixed and will be in 1.0.1 (7/13/2007).
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=195088
>
> And new Wiki page documenting this way of starting ECF generic server:
> http://wiki.eclipse.org/ECF_Servers
>
> Scott
>
>
> Alex Blewitt wrote:
>> Scott,
>>
>> Let's move the conversation to the bug report, not the forum.
>>
>> BTW please don't set 'main'. If you do that, you will only be able to
>> run a single server from the Equinox console, and you might not even
>> be able to do that within an application running on the main thread
>> (e.g. the IDE).
>>
>> The solution is to add a dependency on to the org.eclispe.runtime
>> bundle, which will ensure that that is started prior to the ECF one.
>>
>> But like I said, let's discuss this on the bug, not here.
|
|
|
| |
  |
Goto Forum:
Current Time: Fri Apr 26 21:08:59 GMT 2024
Powered by FUDForum. Page generated in 0.03741 seconds |
] 
Search
Help
Register
Login
Home
