16 Jun 2010, 03:30
Generic-user-small

Michael Craig Walls (2 posts)

I’ve been working through the errata and the examples for a 2nd printing (not 2nd edition) of Modular Java and have found some interesting things.

First, I assure you that, despite what some have suggested, I did work through my own examples…a half-dozen times or more…before the book was printed. Despite my best efforts, some glitches have still arisen.

The newest versions of Pax Construct use newer versions of Pax Runner which do not automatically provision the OSGi compendium bundle. Consequently, the Pax Logging bundles, which depend on the compendium bundle, do not work on their own. They did work with the version of Pax Construct/Runner I was using when writing the book, but things changed and the OSGi world kept moving. The fix for that has been mentioned elsewhere in this forum.

As a last minute decision, in order to save some space and shorten some lines, we decided to repackage the code from being under a com.dudewheresmyjar base package to being in a dude base package and then settled on a dwmj base package. This last minute change took place after much of the book was typeset, so the changes had to be done manually by the typesetter. Whether I failed to tell the typesetter of all of the places to change it or the typesetter missed a few, the end result was that some places show the wrong package name. I’m recommending changes to fix that for the 2nd printing.

Since the book was printed, the OSGi Blueprint specification has been made final…and it looks almost nothing like what I wrote about in Appendix C. I suppose that’s the danger of writing about stuff that’s still being spec’d out. I hope (no guarantees) to be able to update Appendix C completely for the 2nd printing to reflect the actual final Blueprint spec.

There are also some goodies in the new version of Pax Runner that I hope to slide into the 2nd printing. Profiles, specifically, are a new Pax Runner feature that are very valuable. Rather than manually add several bundles to support Spring-DM and its web extender, specifying a “–profiles=spring.webmvc” option when running Pax Runner will automatically include Spring-DM, Spring MVC, and Jetty…no need to add the bundles individually. I hope to be able to work at least a new sidebar into the 2nd printing to discuss this feature. (Again…it’s a 2nd printing, not a 2nd edition, so no guarantees on how much new stuff I’ll get to add.)

And there are several other quirks and gotchas along the way that are largely due to the book representing the state of OSGi at a specific point in time, while the tools and frameworks have continued to evolve.

Anyhow, I just wanted to chime in to let you know that I’m working to resolve the issues.

16 Jun 2010, 12:50
Generic-user-small

Michael Craig Walls (2 posts)

Oh and I forgot to mention that nasty stack trace that Compass spits out. Actually, if you look closer at it, Compass is logging that at DEBUG level…because it’s not really a problem.

Compass has two strategies for reflecting over classes it’s dealing with: Plain and ASM-based (as I understand it). It favors the ASM-based approach, but falls back on the Plain if it can’t for some reason, use ASM. But before it falls back to Plain, it barfs out a stack trace to let you know that it couldn’t use ASM.

Again, this isn’t really a problem…just annoying. The code still works. There are a handful of ways of dealing with it, though: Ignore it, set your logging to something more restrictive than DEBUG, or another post in this forum indicates, configuring Compass to use Plain reflection by default.

18 Apr 2014, 20:28
Me_pragsmall

David Kowis (6 posts)

Just curious, is this second printing still in the works? It’s been like 4 years :)

  You must be logged in to comment