OSGi Blueprint Visualization
OSGi Blueprint Visualization
If you like using blueprints to visualize your dependency injection, a simple script can help you see if your beans or domains are getting too unruly.
Join the DZone community and get the full member experience.Join For Free
The CMS developers love. Open Source, API-first and Enterprise-grade. Try BloomReach CMS for free.
A blueprint is a dependency injection framework for OSGi bundles. It could be written by hand or generated using the Blueprint Maven Plugin. A blueprint file is just an XML file describing beans, services, and references. Each OSGi bundle could have one or more blueprint files.
Blueprint files represent the architecture of our bundle. Let's visualize it using Groovy and graphviz, available in my GitHub repository and analyze.
All you need is Groovy and graphviz installed on your OS. I am working mostly with bundles with generated blueprints, so I will use a blueprint file generated from Blueprint Maven Plugin as an example. All examples are included in the GitHub repository.
Generation could be invoked by running
run.sh with a given destination file prefix (in this case, a PNG extension will be added to it) and the path to the blueprint file:
mkdir -p target ./run.sh target/fullBlueprint fullBlueprint.xml
The visualization is available here, or you can click on the thumbnail below to enlarge it.
First, if you look at the image, you see that some beans are grouped. You could easily extract such domains with tree roots:
beanWithCallbackMethods to separate blueprint files and bundles in the future and generate images from them:
./run.sh target/beanWithCallbackMethods example/firstCut/beanWithCallbackMethods.xml ./run.sh target/beanWithConfigurationProperties example/firstCut/beanWithConfigurationProperties.xml ./run.sh target/otherStuff example/firstCut/otherStuff.xml
We also could generate images from more than one blueprint:
./run.sh target/joinFirstCut example/firstCut/otherStuff.xml example/firstCut/beanWithConfigurationProperties.xml example/firstCut/beanWithCallbackMethods.xml
And the result is here. (That's another big one. Click on the link to see the image.) The image contains beans grouped by file, but if you do not like that, you could force generation without such separation using
./run.sh target/joinFirstCutGrouped example/firstCut/otherStuff.xml example/firstCut/beanWithConfigurationProperties.xml example/firstCut/beanWithCallbackMethods.xml --no-group-by-file
It will generate an image with all beans from all files.
Sometimes, it is difficult to spot and extract other domains. It will be easier to do some experiments on a blueprint. For example, bean
my1 is a dependency for too many other beans. You could consider converting
my1 to an OSGi service and extracting it to another bundle.
my1 bean from generation via
-e and see what happens:
./run.sh target/otherStuffWithoutMy example/firstCut/otherStuff.xml -e my1
The result is available here. Now we see that trees with root bean
myFactoryBeanAsService could be separated and
my1 could be injected to it as an OSGi service in another bundle.
You could exclude more than one bean adding the
-e switch for each of them, for example,
-e my1 -e m2 -e myBean123.
Blueprints are great for dependency injection for OSGi bundles, but it is easy to create a big context containing many domains. It is much easier to recognize or search for such domains using a blueprint visualizer script.
Published at DZone with permission of Dominik Przybysz . See the original article here.
Opinions expressed by DZone contributors are their own.