[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[equinox-dev] Re: equinox-dev Digest, Vol 12, Issue 10
|
What Neil has suggested here is more or less what I did when I ported a
non-Eclipse-UI application to Equinox. I had a headless bundle called
FeatureSynchronization that invoked the Update APIs to move the desired
features to the target. Then I simply started any bundle that had a bundle
activator declared in its manifest. Admittedly, this is not as general
purpose as what Neil has suggested, but this was just proof-of-concept and
was in the same vein as Neil suggestion. Then, of course, you'd need to
make sure that the FeatureSynchronization bundle was always included in
your core at startup and that it was started by one of the more traditional
mechanisms like BJ suggested earlier. In my case, my launch configuration
was starting it.
Paul VanderLei
Embedded Java Enablement Team
1750 Ridgemoor SE
Grand Rapids, MI 49506
616.975.1985
pvlei@xxxxxxxxxx
"I don't see architecture coming from you." -Jerry Seinfeld
------------------------------
Date: Mon, 10 Apr 2006 01:56:23 +0100
From: "Neil Bartlett" <neil@xxxxxxxxxxxxxx>
Subject: Re: [equinox-dev] Creating and Starting a BundleActivator
when the framework launches
To: "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx>
Message-ID:
<bb4674270604091756t10d4d00fxf526579fbc144518@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
>So, as you can see, I'm using the Eclipse platform in a way that most
people would never
>dream of
Actually, I think you'd be surprised :-)
Okay, so you do control the application that your bundles are installing
into. Here's what I would do:
1) Define a bundle header called Bundle-ImmediateActivation (or whatever).
Add it to the bundles that you want to be started on installation
2) Write a bundle (lets call it X) that sits in your core application. That
bundle registers a BundleListener.
3) The BundleListener is interested in "Bundle Install" events - when it
sees one, it gets the Bundle object from the BundleEvent, scans the headers
of the Bundle for the ImmediateActivation header, and if present calls
Bundle.start().
This will work for your application, and also would work in my hypothetical
app that _doesn't_ want the bundle started immediately - I simply leave out
the X bundle.
Now, bundle X still has to be started by something, but you can add that to
config.ini (or start it from your main IPlatformRunnable). That's not a
problem because bundle X is not installed by Update Manager, it's part of
your core application.
How does that sound?
Regards
Neil
On 4/10/06, Simon J Archer <sarcher@xxxxxxxxxx> wrote:
>
>
> Hi Neil
>
> Please don't get me wrong, I really appreciate the dialog... Yes, I have
> to admit that my scenario is a little new to the traditional Eclipse
> developer that is always thinking about an IDE running on a desktop and a
> user sitting there with a mouse. My application has none of these... let
me
> explain.
>
> The application I am building is an embedded Java application that runs
on
> an embedded Linux box, on a shelf in a factory somewhere. The
application
> is totally headless. It has TCP/IP, plus a bunch of other RFID hardware
> devices hanging off of it. The application is designed to be very self
> sufficient, checking for updates regularly, and performing all the
necessary
> care and feeding of itself to run unassisted. As for a user, the closest
I
> think of is some guy in the warehouse driving a fork-lift, but as you can
> imagine he has no idea about the application, about Eclipse, or about the
> fact that my bundles need starting. All he cares about is shifting
palettes
> through a dock-door and getting to his next coffee break.
>
> So, as you can see, I'm using the Eclipse platform in a way that most
> people would never dream of. But I must stress that this requirement is
> valuable to the IDE world too. Whenever I building plug-ins for the
Eclipse
> IDE I still like to be able to practice good design where my model
plug-ins
> are quite separate from my UI plug-ins. My model plug-ins are purely
model
> and have no dependency on the UI. The UI plug-in is an observer of the
> model and interacts with it in a very loosely coupled manner. Sure I
could
> couple these guys, but it would inhibit reuse and would make evolving the
> application significantly harder due to the dependency upon an existing
UI.
>
> Please don't stop responding, I really do appreciate it. I shall
> investigate the IPlatformRunnable interface some more.
>
> Cheers
>
> Simon <http://www.eclipsecon.org/>
>
>
>
> *"Neil Bartlett" <neil@xxxxxxxxxxxxxx>*
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
>
> 04/09/2006 07:36 PM
> Please respond to
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
> To
> "Equinox development mailing list" <equinox-dev@xxxxxxxxxxx> cc
>
> Subject
> Re: [equinox-dev] Creating and Starting a BundleActivator when the
> framework launches
>
>
>
>
>
>
> Simon,
>
> There must be a bundle somewhere that is active - and therefore has a
> BundleContext - otherwise your application is doing nothing...
>
> Do you mean that you are installing via Update Manager a set of bundles,
> and prior to the Update you don't have any of your own bundles already
> installed in the target application? If you are installing into a
completely
> clean Eclipse application such as the SDK, then yes you have a problem
> because you can't put your Bundle.start() code into any of the
> pre-existing bundles. However it's difficult to see what possible use the
> pre-existing bundles could be making of your service...
>
> How about letting the end user decide whether to start the bundles? You
> could popup a little dialog... and since that's already a UI thing there
> would be no problem using IStartup (just keep the popup code in a
separate
> bundle). In non-UI applications you can do something else, like a single
> line of code on the IPlatformRunnable...
>
> If you have implemented an IPlatformRunnable and have declared it through
> the org.eclipse.core.runtime.application extension point, then you can
get
> the Bundle and call start() on it there. However if you have the level of
> configuration control to define and start an application, why don't you
have
> the ability to modify config.ini?
>
> >All I want is to build a bundle on the Eclipse platform that starts as
> soon as it is installed; >it's really as simple as that.
>
> Okay, but that's really none of the bundle's business. It's the
> responsibility of the product assembler, or the administrator, or even
the
> end user, to decide when bundles start. Say for example I want to use
your
> bundle, but in my application I don't want it to start immediately. I'd
be
> out of luck, because your bundles think that they must always be running
no
> matter what application they are in.
>
> Sorry if I still don't seem to be getting your problem. If it's still not
> clear to me after your next reply I'll shut up and let somebody else have
a
> go!
>
> Good luck
> Neil
>
> On 4/9/06, *Simon J Archer* <*sarcher@xxxxxxxxxx* <sarcher@xxxxxxxxxx>>
> wrote:
>
> Hi Neil
>
> Thanks for the response. I am very familiar with all the tricks
available
> via the BundleContext, but until my bundle is started, and a
BundleContext
> provided to me, none are possible. The point of my posting is exactly
this:
> My model-based bundle that registers a service is never started. I hope
now
> that you understand my dilemma.
>
> Regarding IStartup, that is in a UI plugin, and sadly the extension point
> requires the BundleActivator to implement an interface in a UI plugin. I
do
> not want to create an unholy dependency upon any UI plugin, since my
bundle
> is purely headless. Requiring the Eclipse UI would be madness. All I
want
> is to build a bundle on the Eclipse platform that starts as soon as it is
> installed; it's really as simple as that.
>
> Your point regarding IPlatformRunnable is of interest to me. If my
bundle
> is not yet started, how am I to make use of IPlatformRunnable? Remember,
> I'm asking for a solution to the problem of providing one (or more)
> model-based bundles that simply register OSGi services. OSGi services
are
> not widely used yet in the Eclipse community, so I'm likey one of the few
> that is running into this problem.
>
> Thanks
>
> Simon <http://www.eclipsecon.org/>
>
>
> *"Neil Bartlett" <**neil@xxxxxxxxxxxxxx* <neil@xxxxxxxxxxxxxx>*>*
>
> Sent by: *equinox-dev-bounces@xxxxxxxxxxx
*<equinox-dev-bounces@xxxxxxxxxxx>
>
> 04/09/2006 05:33 PM
>
>
> Please respond to
> Equinox development mailing list
<*equinox-dev@xxxxxxxxxxx*<equinox-dev@xxxxxxxxxxx>
> >
>
> To
> "Equinox development mailing list"
<*equinox-dev@xxxxxxxxxxx*<equinox-dev@xxxxxxxxxxx>
> > cc
>
> Subject
> Re: [equinox-dev] Creating and Starting a BundleActivator when the
> framework launches
>
>
>
>
>
>
>
>
> Simon,
>
> Maybe I misunderstood your problem, but there are a number of easy
> solutions and I don't really see why you've dismissed all of them.
>
> Firstly, why can't you get the Bundle object? You seem to be under the
> impression that the Bundle object is only available within the bundle
that
> it describes. Actually any bundle can get the Bundle object for any other
> bundle just by calling getBundle(id) or getBundles() on its own
> BundleContext. You could even write a bundle that uses a BundleListener
to
> listen for Bundle Installed events, checks the value of some header you
> define eg "Bundle-EarlyActivation", and immediately starts those bundles.
>
> If that's no good, what's wrong with IStartup? That works in any Eclipse
> application that uses the Workbench. Is your application entirely
headless?
>
> Finally, if your application is headless (or if it isn't), you can get
the
> Bundle and start it from the IPlatformRunnable.
>
> Regards,
> Neil
>
>
>
> On 4/9/06, *Simon J Archer* <*sarcher@xxxxxxxxxx * <sarcher@xxxxxxxxxx>>
> wrote:
>
> So my choices are:
>
> - Call the Bundle object's start() method, or
> - Update a configuration file in the local filesystem.
>
> Hmmm, neither of these seem to be what I'm looking for: Calling the
> Bundle's start() method assumes that I can get the Bundle object for my
> bundle, which I usually do through the BundleContext, which is not
created
> until the BundleActivator's start has been called. The configuration
file
> is not really feasible since I'm talking about building a bundle that is
> available for installation from an update site. I would imagine that
> updating the config.ini is something you need to do by hand before
Eclipse
> is started.
>
> Here's my scenario, in a nutshell:
>
> "I wish to write a bundle that can be installed into Eclipse from a
update
> site. The bundle is "pure model" (no UI) and has a BundleActivator that
> simply creates an instance of the model class and registers it as a
service
> with the OSGi framework. To do this I shall be using the traditional
> BundleContext APIs, and NOT declarative services. Other bundles will
> acquire the imported service from the OSGi framework and therefore will
> never touch any of the bundle's classes directly. Even the service
> interface used to implement the service might be defined by another
bundle,
> for which import/export package dependencies will exist."
>
> So far I'm stumped. Surely this simple scenario should be supported by
> the Eclipse platform. Here are some possible ways that Eclipse could be
> enhanced to help:
>
> 1. Add a manifest header that informs the platform that this bundle
> should be started as soon as it is installed. Even broadening the legal
> values for Eclipse-LazyStart might suffice.
>
> 2. Add an extension point to the platform (not UI) that causes the
bundle
> to be started as soon as it is installed.
>
> 3. Enhance the platform so that when a bundle with a BundleActivator and
> an Export-Service header is installed it is automatically started. This
is
> probably my least favorite of the 3, since an Export-Service header is
> purely informational and therefore optional.
>
>
> I'm happy to file a feature request in bugzilla for this. Comments?
> Suggestions?
>
> Thanks
>
> Simon <http://www.eclipsecon.org/>
>
> *BJ Hargrave/Austin/IBM@IBMUS*
>
> Sent by: *equinox-dev-bounces@xxxxxxxxxxx
*<equinox-dev-bounces@xxxxxxxxxxx>
>
> 04/08/2006 08:09 AM
>
>
> Please respond to
> Equinox development mailing list <*equinox-dev@xxxxxxxxxxx
*<equinox-dev@xxxxxxxxxxx>
> >
>
>
> To
> Equinox development mailing list <*
equinox-dev@xxxxxxxxxxx*<equinox-dev@xxxxxxxxxxx>
> > cc
>
> Subject
> Re: [equinox-dev] Creating and Starting a BundleActivator when the
> framework launches
>
>
>
>
>
>
>
>
>
>
> If you start the bundle with Bundle.start(), then the framework will
> persistently mark it started and will restart each time the framework is
> started.
>
> If you launch the framework with -console, you can follow that with
> "install some://bundle/url start" to install and start a bundle.
>
> You can also mark it to be started in the configuration/config.ini file.
> See the osgi.bundles key:
>
> # The comma-separated list of bundles which are automatically installed
> and optionally started
> # once the system is up and running. Each entry if of the form
> # <URL | simple bundle location>[@ [<startlevel>] [":start"]]
> # If the startlevel is omitted then the framework will use the default
> start level for the bundle.
> # If the "start" tag is added then the bundle will be marked as started
> after being installed.
> # Simple bundle locations are interepreted as relative to the framework's
> parent directory.
> # The startlevel indicates the OSGi start level at which the bundle
should
>
> run.
> # If this value is not set, the system computes an appropriate default.
> osgi.bundles=org.eclipse.equinox.common@2:start,
> org.eclipse.update.configurator@3:start, org.eclipse.core.runtime@start
>
> BJ Hargrave
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the OSGi Alliance*
> **hargrave@xxxxxxxxxx* <hargrave@xxxxxxxxxx>
> Office: +1 407 849 9117 Mobile: +1 386 848 3788
>
>
>
> Simon J Archer/Raleigh/IBM@IBMUS
> Sent by: *equinox-dev-bounces@xxxxxxxxxxx**
*<equinox-dev-bounces@xxxxxxxxxxx>
> 2006-04-08 07:24 AM
> Please respond to
> Equinox development mailing list <*equinox-dev@xxxxxxxxxxx
*<equinox-dev@xxxxxxxxxxx>
> >
>
>
> To*
> **equinox-dev@xxxxxxxxxxx* <equinox-dev@xxxxxxxxxxx>
> cc
>
> Subject
> [equinox-dev] Creating and Starting a BundleActivator when the framework
> launches
>
>
>
>
>
>
>
> It is my understanding that simply having a BundleActivator class and a
> Bundle-Activator header in the MANIFEST.MF is not enough to force the
> bundle's activator to be created and started by Equinox when the
framework
>
> is launched.
>
> I have learned that adding Eclipse-LazyStart: true to the MANIFEST.MF is
> the way ensure that the bundle's activator is started when one of its
> classes is first touched by another bundle.
>
> But how am I to create a bundle that has a BundleActivator that is
created
>
> and started when the OSGi framework is launched? I am aware of the
> org.eclipse.ui.startup extension point and accompanying IStartup class,
> but I do not want to use that when my bundle is "pure model", since they
> reside in an Eclipse UI plug-in. I don't want to couple my model to
> anything UI related.
>
> I'm building plugins that will run in the Eclipse IDE rather than pure
> OSGi bundles, so I'm using an "Eclipse Application" launch configuration.
> It is curious that only the "Equinox OSGi Framework" launch
configurations
>
> allow you to specify the default start level for a bundle and whether it
> will start automatically when the framework launches.
>
> While I understand that the early creation and starting of a bundle
> activator is considered a bad thing by many Eclipse developers, it should
> still be possible and should not be this hard.
>
> Thanks
>
> Simon
> _______________________________________________
> equinox-dev mailing list*
> **equinox-dev@xxxxxxxxxxx* <equinox-dev@xxxxxxxxxxx> *
> **https://dev.eclipse.org/mailman/listinfo/equinox-dev
*<https://dev.eclipse.org/mailman/listinfo/equinox-dev>
>
>
> _______________________________________________
> equinox-dev mailing list*
> **equinox-dev@xxxxxxxxxxx* <equinox-dev@xxxxxxxxxxx> *
> **https://dev.eclipse.org/mailman/listinfo/equinox-dev
*<https://dev.eclipse.org/mailman/listinfo/equinox-dev>
>
>
> _______________________________________________
> equinox-dev mailing list*
> **equinox-dev@xxxxxxxxxxx* <equinox-dev@xxxxxxxxxxx> *
> **https://dev.eclipse.org/mailman/listinfo/equinox-dev
*<https://dev.eclipse.org/mailman/listinfo/equinox-dev>
>
>
>
>
>
> --
> Neil Bartlett
> Senior Technical Consultant, Integility Ltd
> Tel: +44 (0) 20 7043 8328
> Fax: +44 (0) 20 7043 8329
>
> LinkedIn Profile: *https://www.linkedin.com/in/neilbartlett
*<https://www.linkedin.com/in/neilbartlett>
> _______________________________________________
>
> equinox-dev mailing list*
> **equinox-dev@xxxxxxxxxxx* <equinox-dev@xxxxxxxxxxx>*
>
**https://dev.eclipse.org/mailman/listinfo/equinox-dev*<https://dev.eclipse.org/mailman/listinfo/equinox-dev>
>
>
> _______________________________________________
> equinox-dev mailing list*
> **equinox-dev@xxxxxxxxxxx* <equinox-dev@xxxxxxxxxxx>*
>
**https://dev.eclipse.org/mailman/listinfo/equinox-dev*<https://dev.eclipse.org/mailman/listinfo/equinox-dev>
>
>
>
>
>
> --
> Neil Bartlett
> Senior Technical Consultant, Integility Ltd
> Tel: +44 (0) 20 7043 8328
> Fax: +44 (0) 20 7043 8329
>
> LinkedIn Profile:
*https://www.linkedin.com/in/neilbartlett*<https://www.linkedin.com/in/neilbartlett>
> _______________________________________________
>
> 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
>
>
>
--
Neil Bartlett
Senior Technical Consultant, Integility Ltd
Tel: +44 (0) 20 7043 8328
Fax: +44 (0) 20 7043 8329
LinkedIn Profile: https://www.linkedin.com/in/neilbartlett
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://eclipse.org/pipermail/equinox-dev/attachments/20060410/1aa96ae2/attachment.html
------------------------------
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
End of equinox-dev Digest, Vol 12, Issue 10
*******************************************
