|
The Eclipse Corona project is using ECF from an
OSGI bundle on a server. The code runs in Equiniox, without the need of
the servlet bridge. The code required to do this is
minimal.
The Corona project allows for Collaboration between Eclipse
Workbenches. ECF is used on both the client and server sides for
communication.
Hi Jeff,
Jeff McAffer wrote:
I'm sure Simon Kaegi or me or
someone else on the Equinox team would be happy to help get this setup.
Feels like a wiki/web page in the making. Would be good to start
with some pointers to the plugins that contain your content/servlets/... and
the other things you need to run the server.
I
agree. We've got a placeholder wiki page for 'ECF Servers' work:
http://wiki.eclipse.org/index.php/ECF_Servers
In
answer to your question about what's needed WRT ECF...all that's really needed
is the ECF SDK plugins available here: http://www.eclipse.org/ecf/downloads.html
Of
course this may be more than is needed (there are example client app plugins,
etc which are not needed, of course). We can/should just define some new
features that have other sets of plugins relevant to server
installations.
There is currently a trivial entry point server plugin
(org.eclipse.ecf.server) that upon plugin activation reads from a
org.eclipse.ecf/server/conf/server.xml config file to determine how many
connectors (ports) and how many groups to setup/start. By default the
server.xml has nothing in it so it sets up nothing (e.g. in normal Eclipse
installation), but the server.xml can be easily modified to startup arbitrary
ECF generic server(s). And it would be also easy to add other entry point
server plugins (e.g. for JMS-based servers, or other
protocols).
Scott
Jeff
Hi Jeff,
Jeff McAffer wrote:
Ken,
my servlet comments were wrt Scott's message about the way they are
running the server now. He said they have Tomcat with the servlet
bridge. I always ask people why they do that. Not that it is wrong
but that I like to hear about hte usecases.
Well there are are at least two non-answers to why
use tomcat and servlet bridge ;-)
Answer 1: It's there (and I
wanted to verify that it was working correctly, and could be used)
Answer
2: It's easy/understood how to install/setup/configure and admin (for me
as well as others)
That being said, I would have no objections at all
to using Equinox only and/or Jetty servlet container. In fact, it would
be a great idea to do so for other ECF server installations...just to
demonstrate the ease/flexibility.
Scott
Jeff
Hi Jeff,
I suspect that
most of the stuff listed is being dragged in by having included
org.eclipse.core.runtime. There I suspect you are doing that because you
have an Eclipse application etc.
You are
correct. I used the "add required plugins" magic in the equinox runtime
profile to determine the dependencies for my bundle.
With a bit of Import-Package work you may well be able to reduce
the list quite a bit.
That sounds great.
Coming from an embedded perspective, every byte counts!
as a point of interest, why run the server as
embedded in tomcat rather than standalone using the Equinox HTTP service (or
the Jetty based one that is coming). Bascially you get the same
function/setup but eliminate some buck passing and bulk.
What do you mean by bulk? My embedded system does
not have a servlet container. I assumed that running equinox plain-jane
would be the lightest approach. How is a servlet saving me space?
Thanks for your help!
Ken
On Jun 6, 2006, at 8:57
PM, Jeff McAffer wrote:
This
is very interesting to me. It would actually be quite interesting to see
if you can trim down the list of bundles that are needed. I suspect that
most of the stuff listed is being dragged in by having included
org.eclipse.core.runtime. There I suspect you are doing that because you
have an Eclipse application etc. This is cool and certainly works.
Going forward we are trying to continue our refactoring of the runtime
so, for example, you wont have to have content types just cause you wanted to
have an application. With a bit of Import-Package work you may well be
able to reduce the list quite a bit.
In any event, you asked about ways of adding
all the bundles in a dir rather than having to list them. The answer is
yes. There are two ways you can do this right now.
1) include
org.eclipse.update.configurator in your osgi.bundles like pretty much like we
do in the normal Eclipse config.ini. "configurators" are responsible for
discovering and installing bundles in various ways. the Update
configurator does this by looking in the plugins dir etc and then installing
everything it finds. you have to have it in the osgi.bundles list and
ensure it is started. Again, look at the standard file in the Eclipse
SDK drops.
2)
we did a "simple configurator" in Equinox at one point. I don't know the
complete state of it but take a look at
http://dev.eclipse.org/viewcvs/index.cgi/equinox-incubator/org.eclipse.core.simpleConfigurator/
and see what you think.
I think it does (or could easily be modified to do) whole directories.
Again, you would have to include the simple configurator on the
osgi.bundles list and ensure it is started.
Jeff
Hello ECFers,
I'm doing some
investigation into ECF as messaging infrastructure for portable devices.
Using the equinox tooling available in 3.2, and by taking the code
straight from ServerApp.java (in org.eclipse.ecf.provider) I was able create
an equinox runtime that boots up an ECF collab server. These are my
bundles:
com.buglabs.bugnet.bug_1.0.0.jar
configuration
org.eclipse.core.contenttype_3.2.0.v20060511.jar
org.eclipse.core.jobs_3.2.0.v20060511.jar
org.eclipse.core.runtime.compatibility.auth_3.2.0.v20060511.jar
org.eclipse.core.runtime.compatibility.registry_3.2.0.v20060426
org.eclipse.core.runtime_3.2.0.v20060511.jar
org.eclipse.ecf.datashare_0.8.4
org.eclipse.ecf.provider.datashare_0.8.4
org.eclipse.ecf.provider_0.8.4
org.eclipse.ecf_0.8.4
org.eclipse.equinox.common_3.2.0.v20060512.jar
org.eclipse.equinox.preferences_3.2.0.v20060511.jar
org.eclipse.equinox.registry_3.2.0.v20060511.jar
org.eclipse.osgi_3.2.0.v20060510.jar
The top bundle is where I put the code from ServerApp.java. Here
is my config.ini:
osgi.bundles=org.eclipse.equinox.common@start,org.eclipse.core.runtime@start, org.eclipse.core.contenttype@start,
org.eclipse.core.jobs@start,
org.eclipse.core.runtime.compatibility.auth@start,
org.eclipse.core.runtime.compatibility.registry,
org.eclipse.equinox.preferences@start, org.eclipse.equinox.registry@start,
org.eclipse.ecf@start, org.eclipse.ecf.datashare@start,
org.eclipse.ecf.provider@start, org.eclipse.ecf.provider.datashare@start,
com.buglabs.bugnet.bug@start
And, as you can see
here, when I start up Equinox, I get the good old ECF server message:
lurcher vbug # java -jar
org.eclipse.osgi_3.2.0.v20060510.jar -console
osgi> Hello World!!
Creating ECF server
container...success!
Waiting for JOIN requests at
'ecftcp://localhost:3282/server'...
<ctrl>-c to stop server
Worked exactly as expected. Is there any interest in
creating equinox/osgi-specific releases of ECF? Also, does anyone know
if it's possible to specify a "plugins" directory in the config.ini that the
osgi runtime will look in for bundle dependencies, rather than having to
explicitly define them?
cheers
ken
_______________________________________________
ecf-dev
mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev
mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing
list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing
list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing
list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
|
