As the title suggests, I'm having problems with OSGI + Spring DM.
In my project design, i have a bundle A that requires a service svB and exports service svA. Bundle B requires svA and exports svB (among other things, of course). This seems to be causing a deadlock, as it appears both bundles are waiting for the other to go online. Is that sort of deadlock possible with Spring DM? Is there a solution to this?
This doesn't sound like a problem with Spring-DM, rather you have set yourself up for this deadlock: A depends on B, B depends on A, thus no-one can get any work done. To break out of this, you probably need to change your design, and enable either one of A or B to start without the other. Meanwhile, the other one should have some lazy-loading logic built into it (this would be your job) and continue it's start-up sequence when the other one has come online on it's own.
With OSGi Declarative Services, you are able to declare a dependency on a service but allow it to be absent at the time you are going to start (do this using the cardinality option.)
Related
My project has requirement to deploy a Java Based application as an operating system Job (and not use any container). The application need to have following capabilities:-
Scheduling
Few HTTPS based services
Ability to make JMX calls
Storage: Data for last 5 to 10 minutes of transactions (not more than 600 rows X 20 columns). Something like embedded H2 or in-memory options
Decision Tree: Something like Drools..
My manager wants to write this application as a core Java with OSGized Jetty version. I am suggesting to use Spring Boot with embedded Jetty(which will give me ready to use capabilities for Scheduling, JMX Integration and REST Services).
His bend towards core Java is emerging from the requirement that this application needs to be extremely efficient, fast and self-contained. He wants to reduce dependency on any open source. I have never worked directly on OSGI but have used products coming out of it - like eclipse.
Can somebody guide how OSGI based development might benefit over SpringBoot?
For many people, OSGi is superfluous, because they don't see the value in being modular. Not being worth the trouble.
Think about the application lifecycle, more or less being plan-develop-test-deploy.
How many developers you have? If many, OSGi helps a lot, because being modular make the boundaries very clear. You can delegate things very easily.
If outsourcing is your thing, you can just handle the module APIs and tell them to develop against it. They will never know how the rest was implemented, no fear of secrets being leaked.
Unit tests are so easy. You obviously see what you can test, every else you mock/stub/spy/fake. Unit tests can be can be reused in Integration tests, of course that isn't news, but the trick is running Unit tests outside the OSGi container, and Integration tests inside. So if you decide OSGi was not worth it, your code stills works fine (unit tests being the proof).
You can make your app a collection of modules, and every module having independent versioning and source repositories. Makes easier to handle and find bugs. For example, the current app crashed, you find out that sub-module-1.2 is throwing errors, try with version sub-module-1.1(still bad), then version 1.0(good), bug was introduced in 1.1 (avoids bisecting the source code). Programmers don't need to be perfectly synchronized with each other if they are working in different modules.
How do you plan to update the app? Most frameworks are of the all-or-nothing approach, where you have to stop the world, update, then restart the app. If you make things modular, you just need to update that thing. Making the downtime very small, and sometimes even zero.
If you need to make a big change in your app, but can't afford to refactor everything right now. With OSGi you can run the system with both my-module-1.0 and my-module-2.0. You can even adapt my-module-1.0 to redirect calls to my-module-2.0, but that is a kind of last resort hack (just saying that you can, if you want to).
I can do everything you say without OSGi, right? Well, probably you can, but in the end, would be something like OSGi.
I love the Dependency Injection of my framework. No problem, OSGi have something like that.
I hate Dependency Injection, it kills my app perfomance. No problem, you can use something like osgi.getService(MyService.class);. The OSGi container isn't concerned about intercepting every call of your app.
OSGi is like Java++, Java plus modules.
You can mix Spring Boot with OSGi, can't say if this is good or bad. There are many libraries and frameworks that fit your list, many will work out-of-the-box with OSGi.
I would like to know what is "Activate this plug-in when one of its classes is loaded" check-box in Eclipse manifest editor useful for.
I thought Eclipse always use "lazy initialization" approach. Does have this option a relation to the BundleActivator class of the plugin? is initialization something different to activation?
Here is a similar question, but I don't understand it entirely.
Ticking the box causes the following header to be set in the manifest:
Bundle-ActivationPolicy: lazy
I'll start with how "pure" OSGi deals with this. IF the bundle is started with the START_ACTIVATION_POLICY flag then the bundle enters the STARTING state but the activator's start() method is not invoked and a ClassLoader is not allocated for the bundle. The bundle stays in STARTING until, for whatever reason, a class needs to be loaded from the bundle. At that point a ClassLoader is allocated and the activator (if any) is instantiated and its start() method is invoked before the requested class is loaded.
However Eclipse layers additional semantics on the top. As background, Eclipse always tries to avoid starting bundles in order to keep its start-up time minimal. A very small core set of bundles is started by default (the list is in configuration/config.ini) and one of these is called the p2 "simpleconfigurator". The simpleconfigurator looks for bundles that have the Bundle-ActivationPolicy:lazy header and it starts them with the START_ACTIVATION_POLICY flag... therefore these bundles will be "lazily" started as described above.
The important point is that all other bundles that do not contain the header will not be started at all under Eclipse. They will stay in RESOLVED state, their activators will not be invoked, and if they contain any Declarative Services component they will not be loaded. This is because Declarative Services only ever looks at bundles that are in ACTIVE or STARTING state.
Therefore the main reason to use the header is if we want to write a bundle containing Declarative Services components that need to work under Eclipse.
In other environments there is no need to use the header. Most normal OSGi apps simply start all bundles, rather than trying to selectively start a subset of bundles. Note that this doesn't mean OSGi apps don't worry about lazy loading! Declarative Services already supports lazy loading without messing around with bundle class loading triggers. In my opinion Eclipse gets this wrong and has added unnecessary complexity to the bundle lifecycle. Nevertheless if you are running in Eclipse then you have no choice but to understand and work with its limitation.
Is it possible to add declarative services using some kind of api?
A little background:
I have a server application based on dynamic scripts (they can be added, edited or removed at any time).
Those scripts have dependencies to OSGi services and possibly each other. Whenever a script gets
edited, the script gets compiled to javascript, and its dependencies are detected.
At that point, I'd like to (re)register it as a declarative service, so it will be activated / deactivated when its
dependencies come and go.
Is this even possible? Or is there something major I'm missing?
If it isn't possible with an OSGi standard, is there a specific solution for Felix or Equinox?
Can you do that in the other frameworks, like iPojo or blueprint?
There is no API to imperatively add declarative services. You can use the normal OSGi api to register and use services. Perhaps that is what you want?
You may want to checkout the Dependency Manager which may provide an API model giving you the dependency support you want.
We are writing a new set of services and have decided to make them share a common interface... calling it a BaseService. The idea is that whenever anyone wants to develop a new service in our organization, they should be just able to extend and use this BaseService.
We have written a few other classes which also form a part of this base jar, it does things like handle transactions and connect to database using hibernate etc.
Right now all the services that extend the BaseService are a part of the same project (Eclipse + Maven), and some of the services are dependent on each other, but because they are in the same project we don't have a problem with dependencies.However, we expect 40-50 services to be written which would extend base service and would also be interdependent.
I am worried that the size of the base project would be huge and that just because when someone has to use one service they might have to depend on my base jar which has 50 services.
Is there a way that we can make some projects dynamically dependent on others?
Lets say I have a service A which depends on service B, when I build/compile Service A,it should be able to realize that it has a dependency on service B and automatically use the Service B jar.
I have heard of OSGi, will it solve my problem or is there a way I can do it with Maven or is there a simpler solution ?
Sorry about the long post !
Thanks in advance for your suggestions
It doesn't make any sense to "dynamically" manage project dependencies, since build dependencies are by definition not dynamic.
Your question, at least for the moment, seems to be entirely about how to build your code rather than about how to run it. If you are interested in creating a runtime system in which new service implementations can be dynamically added then OSGi may be the solution to look at. An extra advantage here would be that you could enforce the separation of API from implementation, and prevent the implementing services from invalidly depending on parts of your core module that you do not want them to have visibility of.
You could also use OSGi to manage evolution of your core service API through versioning; for example how do you communicate the fact that a non-breaking change has been made to the API versus a breaking change etc.
I would say there are two options depending if i understand your question correct. First one. You have already defined an interface (java term) and now you have different implementations of that. The simple solution for Maven would be to a have a module which is called for example: service-api and than this will be released and can be used by others as dependencies. On their side they simply implement the interface. No problem with the dependencies. If you are more talking about OSGi than you should take a look to maven-tycho.
I'm having a problem discovering services that are provided by some OSGi bundles that are not being activated. Let me describe the situation:
Bundle A defines interface X
Bundles B, C, and D provide services that implement interface X
These bundles' services are registered via Spring DM, so they are only created when the bundle is activated and Spring DM initialized the application context defined in the bundle
Bundle A is activated and at some point asks the service registry for services for interface X. It doesn't find any, because bundles B, C, and D haven't been moved into the ACTIVE state (they are only RESOLVED).
I cannot seem to get bundles B, C, or D to start, and therefore register their services. Forcing them to start by adding them to the config.ini is not an option, because there can be any number of bundles that are installed in the application (via an Eclipse p2-like update mechanism) that implement interface X.
The application is an Eclipse 3.5-based RCP app, using Spring 2.5.6 and Spring DM 1.2.1.
How do I force these bundles to be activated?
What you really have is a dependency hierarchy problem, your proposed hacky solution is really just a band-aid over the underlying issue.
What you should really consider is the architecture of your system, as effectively what you have is a circular dependency (re: discussion in comments your original post). You have (like it or not) A requires services from (and in some sense depends on) B and C. Meanwhile, B and C directly depend on A, and as such, cannot start until A comes up.
In the best case, you can write code in B and C to listen for the existence of A, but this at best masks (as I mentioned) the underlying issue. What you should really consider is splitting A into two bundles, let's call them A1 and A2.
A1 should provide the interface which B and C require (depend on). A2 should have listeners for the services B and C depend on. At startup, if B and C are required services, A1 must be run, but A2 may start any time later, and everything should work.
I think I've found the solution to this problem, though it feels a bit hackish.
I ran across this thread where Adrian Colyer implied that an external "bundle watcher" could be responsible for activating bundles when they are installed into the framework.
So, my solution was to:
Add a custom header to bundle B, C, and D's respective manifests, e.g., "MyApp-AutoStart: true"
Create a bundle listener that responds when a bundle is moved into the RESOLVED state, and looks for the header
If the header's value is "true," the bundle listener calls bundle.start()
Using this method, the bundles I want to be started are started without having to resort to using config.ini, and they can come and go as they please, but their services are available when queried.
Also have a look at felix fileinstall, which watches a directory for bundles and automatically installs and starts them. When a file is deleted, the bundle is stopped and uninstalled as well.