The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

gchii (7) [Avatar] Offline
#1
I applaud both the content of your book and the process you are using to write it. Great job.

I do not yet comprehend this sentence in section 3.7: "This symbiotic relationship creates a chicken and egg situation when you want to use your modules; to use your bundle you have to install it, but to install a bundle you must be a bundle to use the lifecycle layer to install it."

Frankly, I'm stumped. From the context, it seems like this is an important point but I'm missing it. You have already demonstrated that a bundle can install other bundles in chapter 2. I thought that to "install a bundle," I can use the "install" command. But, now you are saying that "to install a bundle you must be a bundle". I can't imagine a bundle capable of installing itself.

Are you trying to say that a bundle cannot install itself? It seems unlikely.

A classic question from philosophy is "Which came first, the chicken or the egg?" Thus, a "chicken and egg" situation describes something of a paradox, where one thing must exist both before and after another, which seems impossible.
richard.hall (87) [Avatar] Offline
#2
Re: Section 3.7, p. 112
In reality, the point is probably not too important, but I will try to explain it differently here and you can tell me what you think. smilie

OSGi only defines one way to install a bundle, which is BundleContext.installBundle().

Ok. So we need a BundleContext instance to install a bundle, so how do we get one? A BundleContext instance is passed into a bundle's BundleActivator instance when it is started.

Ok. So when is it possible for the framework to start a bundle? A framework can only start an installed bundle.

Hmm. So, to install bundles, we must use BundleContext.installBundle(), but a BundleContext object is only given to an already installed bundle when it is started. This is the paradox. Perhaps this is more of a catch-22?
gchii (7) [Avatar] Offline
#3
Re: Section 3.7, p. 112
To install a bundle using the framework, the framework must be up and running (right?). This strongly suggests that we want to start our framework and keep it up and running for a long time. We are trying to break the tradition that we must shut down an application in order to perform routine maintenance. Therefore, BundleContext.installBundle() is focused on installing a bundle while the framework is running.

I guess that an OSGi-compatible framework always depends upon some kind of preparation, a pre-installation step, outside the framework. We must take a few steps outside the framework to get to the point where we almost never have to stop our framework again. This must occur before we start our framework for the first time. Using features of my favorite operating system, I assume we can install the framework itself without starting Java, without starting the OSGi framework.

You have pointed out that there is a problem. I think I see a puzzle. Now what do we do?

The IBM Installation Manager, for example, is an OSGi-based application. It installs and upgrades other OSGi-based applications. To break out of the chicken and egg problem, "installed" bundles are distributed on CD-ROM. The cache is read-only. A "launcher" starts the OSGi framework. Is this the best practice for resolving this paradox? If not, what is?
richard.hall (87) [Avatar] Offline
#4
Re: Section 3.7, p. 112
> You have pointed out that there is a problem. I think
> I see a puzzle. Now what do we do?
>
> The IBM Installation Manager, for example, is an
> OSGi-based application. It installs and upgrades
> other OSGi-based applications. To break out of the
> chicken and egg problem, "installed" bundles are
> distributed on CD-ROM. The cache is read-only. A
> "launcher" starts the OSGi framework. Is this the
> best practice for resolving this paradox? If not,
> what is?

Before R4.2, most frameworks devised some non-standard way to allow us to install bundles. Usually, this involved some combination of a configuration file with a list of bundles to install/start on framework startup and/or a command-line/GUI shell.

However, R4.2 introduces a new standard API for launching frameworks. With this API you can use the META-INF/services approach to get a framework factory and create a framework instance. The returned framework instance is of type Framework, which is a subtype of Bundle. Using this instance, you can "prepare" the framework (i.e., Framework.init()) and get the system bundle context Framework.getBundleContext(). This solves the dilemma in a standard way.

This is the approach our generic bundle launcher uses in the book. We will discuss this in the launching and embedding chapter of the book, which I will hopefully start writing this week.
gchii (7) [Avatar] Offline
#5
Re: Section 3.7, p. 112
To follow up on this issue, the chapter on launching and embedding answers my questions. Just for fun, I created a program to launch an arbitrary framework using nothing but reflection. The OSGi framework itself was not on the classpath. I loaded the framework by creating a class loader at runtime. It works with Equinox, Felix and Knopflerfish. I have learned something!

I only worked through a few examples from the source code. I have more work ahead.

OSGi is nothing short of a revolution. It makes obsolete much of the Java code that I have already written. While I identified the problem with Java years ago, my solutions have not been as comprehensive nor as extreme as OSGi. It is going to take a while for me to understand how it fits in to what I do.

Thanks again for your book.
richard.hall (87) [Avatar] Offline
#6
Re: Section 3.7, p. 112
Great, we're glad you got something out of our efforts. It's been a difficult process and we're all happy to have the finish product almost complete!