Skip to main content

[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>

To

<equinox-dev@xxxxxxxxxxx>

cc
Subject

[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


Back to the top