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.

gmazza (30) [Avatar] Offline
#1
p. 52: "...while step (2) ensures imported packages are not split across the exporting and importing bundles." Actually, no, Step (2) is just ensuring that the internal bundle class path is not used when trying to find imported packages. ("exporting and importing bundles" is also a confusing term, it would have been better to say "imported and within-bundle packages".)

p. 54: The wrong question is being asked here. Instead of "Is there any advantage to separating the shape implementations into separate bundles?", and then packaging each shape implementation into a separate bundle, the first modularization shown should be "Is there any advantage to separating the shape implementations into separate -->packages<--?" and then showing how org.foo.shape.circle, org.foo.shape.square, etc., can be separately exported from the ShapeImpl bundle and separately imported by the Paint bundle.

Splitting into separate *bundles* is another topic that should be discussed only after you explain splitting into separate *packages* above.

Also, the below paragraph needs rewriting, from:

"There is a price to pay for the flexibility afforded by dividing our application into multiple bundles. Lots of bundles mean you have lots of artifacts which are versioning independently, creating lots dependencies and configurations to manage. So, it is probably not a good idea to create a bundle out of each of your project's packages, for example."

[Bundles are *not* being versioned--it is *packages* that are being independently versioned.]

to

"There is a price to pay for the flexibility afforded by dividing functionality into multiple packages. Lots of packages mean you have lots of artifacts which are versioning independently, creating lots [of] dependencies and configurations to manage. So, it is probably not a good idea to create a separate package for each class exported by your bundle."

p. 54: "We can now bundle each of these shapes separately; the following metadata captures the circle bundle:"

Actually, you just need to move the each shape implementation into a separate package, it is *not* necessary to place them in separate bundles to gain the flexibility you're looking for. Moving them into separate bundles is confusing the matter, implying that you have to do that in order to gain granularity.

While there may be a separate space-saving advantage to splitting out circle, square, and triangle into separate bundles, it is not necessary for the paint program. You can have these three in the same bundle but just different packages, allowing the paint program to import whatever subset of the three it wants, and also, to import the trapezoid shape offered by a third party from a second bundle (i.e., all four shapes can be found in two bundles, it is not necessary to have four.)


p. 58: "When an importing bundle is wired to an exporting bundle, the importing class loader is given a reference to the exporting class loader so it can delegate requests for classes in the exported package to it."

This sentence could use rewriting. "When a bundle imports a package from a bundle that exports it..." So far as described in the book, bundles are *not* wired to other bundles but to specific packages (which could be found in multiple bundles).

p. 59 the "System class path delegation" sidebar should clarify something, if the JRE already contains javax.swing (as nearly all do), will the OSGi framework *automatically* import it by default (i.e., so we don't need the separate Swing bundle) or, via this "system class path delegation", is there something separately we must explicitly do in order for the javax.swing in the JRE to be detected? This is an important point that can be clarified in a sentence or two--it should not wait until Chapter 12, because there are many javax.* classes and people need to know off-the-bat whether their javax.* classes are automatically available.

p. 62, problem in the text: "If the servlet API was already
resolved, then the framework would choose it to resolve the web application's dependency, even though it is not exporting the highest version. Why? It has to do with maximizing the potential for collaboration. Bundles can only collaborate if they are using the same version of a shared package."

There's additional reasons you might wish to mention: increase performance and reduce memory footprint by not resolving/keeping in memory additional bundles and not risking an exception occurring due to the second bundle not being able to be resolved due to its imports not being available.

Also, recommend changing this sentence: "Bundles can only collaborate if they are using the same version of a shared package." to "Bundles can only collaborate if they are using the same version of a shared package, as will be shown shortly." (I was confused what you meant by collaborate but you give a good example in the next section.)