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 FreeA 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.
Example Generation
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.
Separating Domains
First, if you look at the image, you see that some beans are grouped. You could easily extract such domains with tree roots: beanWithConfigurationProperties
and 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
Now we have three slightly cleaner images: beanWithConfigurationProperties.png
, beanWithCallbackMethods.png
and otherStuff.png
.
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 --no-group-by-file
:
./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.
Exclusion
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.
Let's exclude 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
.
Conclusion
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.
Trending
-
Batch Request Processing With API Gateway
-
Measuring Service Performance: The Whys and Hows
-
Guide To Selecting the Right GitOps Tool - Argo CD or Flux CD
-
Reducing Network Latency and Improving Read Performance With CockroachDB and PolyScale.ai
Comments