[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [equinox-dev] Running Equinox 3.2.0 embedded
|
Glad you are up and running. Its
good that you push on these usecases. We are reviewing how the osgi and
startup jars are sturctured in an effort to simplify things so knowing
(remembering) about these kinds of scenarios is useful.
Jeff
Hal Hildebrand <hal.hildebrand@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
09/09/2006 06:59 PM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx> |
|
To
| Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| Re: [equinox-dev] Running Equinox 3.2.0
embedded |
|
Well, I was all set to write a long email
detailing how I was indeed running the framework from a jar and that the
source was in a separate project, out of the class path. I was going
to tell you how I had refactored the system to separate out the knopflerfish
and equinox support into separate Maven modules to ensure that the classpath
was uncorrupted and yet I still had the same problem.
But then I thought, what the heck. Why don’t I just try the Main
class that Jeff suggested. After all, I was running this through
Junit, maybe that was doing something wacky. Strangely enough, it
did work. So, I turned the Main into a Junit test and it still
worked. So, what was different about the working version and the
way I was trying to invoke it?
Turns out it was a System property name that I was using to indicate the
class name of the framework implementation: “osgi.framework”
(D’oh!). Changing this property name to “junit.osgi.framework”
made everything peachy and all is now right with the world. :)
Thanks!
On 9/8/06 7:22 PM, "Jeff McAffer" <Jeff_McAffer@xxxxxxxxxx>
wrote:
Hal,
In the Spring-OSGi list I pointed you at the Quickstart guide (http://eclipse.org/equinox/quickstart.html)
but then I read your message more carefully and realized that that response
was not particularly useful as it does not cover what you are really trying
to do. So I did a bit of investigation and found that the following
class works for me with no errors (the presence of -clean does not change
anything. see below re -args).
public class
Main {
public
static
void
main(String[] args) throws
Exception {
BundleContext bc = EclipseStarter.startup(new
String[]{}, null);
System.out.println(bc);
}
}
Can you check that you are running with osgi as a JAR (as opposed to being
in your workspace). That is the thing that I noticed made a difference.
If you are still having a problem, please send along details on how
to reproduce. A bug report in Eclipse/Equinox/Framework would be
great.
Jeff
Full details and observations made along the way.
- some of the command line arguments are processed by Main in startup.jar.
The launching technique outlined here does not run that code so some
of that setup may have to be done by your code (note that this generally
means that you might have to set a system property rather than passing
a command line option). The details are shown in the Eclipse Help
http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.isv/reference/misc/runtime-options.html
There any of the -arguments that have (Main) after them are processed by
startup.jar. Lookup the corresponding system property and use that
rather than the -argument. For example, rather than passing -clean, use
System.setProperty("osgi.clean", true) before starting the framework.
- When I first started to reproduce your situation I had problems similar
to what you were seeing. In the end it turned out to be an issue
with having the org.eclipse.osgi project checked out in my workspace AND
set on the classpath of my Main class. Basically the setup in the
workspace is subtlely different from that which is in the built jar. In
particular, the hookconfigurators.properties file was not being found and
the osgi.framework system property was set incorrectly.
For the hookconfigurators.properties file, the framework has no choice
but ot look on the current classloader for the resource. The way
we are launching here, the classloader is the appclassloader and the classpath
includes the *bin* dir for the Main project and the org.eclipse.osgi project.
The hookconfigurators.properties file is in the root of the osgi
jar. This is normally on the class path when launching with startup
jar since startup.jar constructs its onw classloader and is smart enough
to know that we are in "dev" mode.
Similarly, the framework location (osgi.framework) is derived from the
classpaht entry that supplies the framework classes. In this scenario
it is the org.eclipse.osgi/bin dir. When launching using startup.jar
in dev mode, the osgi.framework property is set explicitly to be the org.eclipse.osgi
dir (no bin).
So, you don't likely care about all that but I wanted to outline what was
happening. Basically I just changed the Main project to have an osgi.jar
on the classpath rather than the org.eclipse.osgi project and everything
worked. Alternatively, I got it to work by copying the hookconfigurators.properties
file into the classpath in the Main project and setting the osgi.framework
property to be an absolute file: URL to the org.eclipse.osgi project dir
in the workpace.
Hal Hildebrand <hal.hildebrand@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
09/08/2006 05:30 PM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
<equinox-dev@xxxxxxxxxxx>
[equinox-dev] Running Equinox 3.2.0 embedded
I’m trying to develop a multi-framework vendor test harness for the Spring/OSGi
integration effort. This test harness already works with Knopflerfish
and I’m trying to get this to work with Equinox. After an examination
of the Equinox code base, the effort did not appear to be too hard. However,
I'm running into trouble and any help would be appreciated.
I’m using Equinox version 3.2.0, and to start up the Equinox framework
I'm simply doing:
BundleContext bc = EclipseStarter.startup(new String[]{"-clean"},
null);
This throws the IllegalStateException below.
Not really sure what I should be doing to make this go away. Note
that if I add the command line argument to the above such as “-configuration”
and the location, where the configuration location is a directory and the
directory contains an empty “config.ini” file, I get the same IllegalStateException
thrown, but I do get an org.eclipse.osgi/manager directory under this location
with a .fileTableLock file in it.
Again, I’m just trying to get a minimal startup of Eclipse – I’ll use
the BundleContext returned by startup() to install and start the bundles
I need.
java.lang.IllegalStateException
at org.eclipse.osgi.internal.baseadaptor.BaseStorage.getBundleContent(BaseStorage.java:590)
at org.eclipse.osgi.internal.baseadaptor.BaseStorage.createBundleFile(BaseStorage.java:600)
at org.eclipse.osgi.baseadaptor.BaseAdaptor.createBundleFile(BaseAdaptor.java:491)
at org.eclipse.osgi.baseadaptor.BaseData.getBundleFile(BaseData.java:367)
at org.eclipse.osgi.baseadaptor.BaseData.getEntry(BaseData.java:93)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.getEntry(AbstractBundle.java:1281)
at org.eclipse.osgi.framework.internal.core.Framework.findVMProfile(Framework.java:393)
at org.eclipse.osgi.framework.internal.core.Framework.loadVMProfile(Framework.java:312)
at org.eclipse.osgi.framework.internal.core.Framework.initialize(Framework.java:187)
at org.eclipse.osgi.framework.internal.core.Framework.<init>(Framework.java:112)
at org.eclipse.osgi.framework.internal.core.OSGi.createFramework(OSGi.java:90)
at org.eclipse.osgi.framework.internal.core.OSGi.<init>(OSGi.java:31)
at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:286)
at org.springframework.osgi.testing.client.equinox.EquinoxFramework.start(EquinoxFramework.java:38)
at org.springframework.osgi.testing.client.HarnessClient.run(HarnessClient.java:143)
at org.springframework.osgi.testing.client.AbstractHarnessTest.frameworkTest(AbstractHarnessTest.java:35)
at org.springframework.osgi.testing.client.EquinoxTest.testEquinox(EquinoxTest.java:14)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:32)
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev