We use a mixed OSGi and non-OSGi environment.
Therefore all our produced JARs are Bundles, to enable deployment and runtime both inside and outside of the OSGi container. Therefore, all our are written without any OSGi API integration, and we use a single OSGi extender bundle to register all services as OSGi services.
I would like to use a single DI solution (i.e. the same configuration file(s)) when wiring the system together both inside and outside of the OSGi container. This, rather effectively, prevents me from using simple blueprint DI.
What would you recommend here?
Is there any best practices collected for this kind of scenario?
I suggest looking at pojosr
A service registry that enables OSGi style service registry programs without using an OSGi framework.
The idea is to create something that would make the service and parts of the life cycle layer of OSGi available in environments where it typically isn't.
This allows you to use the normal OSGi Service Registry and Declarative Services, even outside an official OSGi framework, unless you need more than what is offered by Declarative Services
A couple of options;
Google Guice will work both inside (implicitly and explicitly using Peaberry) and outside.
Apache Camel - Camel's bean binding will work in OSGi, spring, (AFAIK) all EJB containers (even JBoss) and also will work nicely with Guice.
As it's likely you're running across multiple JVMs, with a mix of nice new OSGi and legacy, Camel's EIP might be a really good fit. But you can always get started with Guice and integrate Camel later.
Whatever you decide, it would be wise to ensure any Jars built include an OSGi manifest.
Use Spring.
It will obviously work outside of OSGi, and you can use Spring dm to adapt it to work inside of OSGi. It simply requires the addition of an osgi context file to bind beans to/from the service registry.
We have used it in multiple projects for several years for Eclipse RCP apps. It can be used to bind things at the UI level in this particular case as well.
Related
I am working on a POC where I had to containerize a part of application for eg - I need to containerize "add to cart" functionality in an e-commerce website, I see a various example https://dzone.com/articles/docker-for-devs-containerizing-your-application to containerize whole application,but how to do for a part of it where my functionalities has dependency on other code parts as well.
Any pointers will be very helpful as I am totally stuck and don't see similar query anywhere else.
Thanks
IMHO, the first thing you need to do is read more about the concept of microservices and how it works.
Basically, the idea is decouple your monolithic application into as many services as your want and deploy it separate of each other. Each of this parts will comminicate with other parts by API calls.
There are a lot of benefits of using microservices architecture, and there is no the "better way" to do this, it will depends of how your application works and how your team is engaged.
I can recommend you a couple of link about microservices:
https://medium.com/hashmapinc/the-what-why-and-how-of-a-microservices-architecture-4179579423a9
https://opensource.com/resources/what-are-microservices
https://en.wikipedia.org/wiki/Microservices
If the application is not build as microservices, it wont actually work. The POC you should be striving for is to decouple it in another seperate application.... Which I guess its much harder and larger scope of the original POC
This is how I'd do it:
create a new java/gradle module called "addToCart"
extract all functionality related to "add to cart" functionality to this single gradle, spring boot module (add relevant dependencies to build.gradle and update settings.gradle to include the new module. And use compile("module") to have dependencies on existing modules brought into your new spring-boot module (note: you can't depend on a module that is a spring boot application - this will fail because spring-boot modules are compiled differently to lib modules without the spring boot plugin).
extract any dependencies this new module has on existing code out to another new library module that can be pulled in using a gradle dependency (you're aiming to end up with a Gradle multiproject build). This is required so that existing projects/modules as well as the new one can maintain the same dependencies.
use a gradle docker plugin like https://github.com/palantir/gradle-docker OR https://github.com/bmuschko/gradle-docker-plugin to create a docker image/container for you (instructions on website). You can do this part manually also.
If you're feeling particularly adventurous you could look into building GraalVM "native images" that are container friendly. Native images start incredibly fast. Because they start so fast you don't actually need to have them running all the time, which can lower your costs. There are trade-offs though. There's a talk from Devoxx Belgium 2019 that goes into details about it here: https://youtu.be/3eoAxphAUIg?t=978
When modularizing a grails application, when does it make sense to add the module as a plugin vs gradle dependency?
For Example:
akaDomain contains all the domain objects.
akaWebsites contains all the presentation logic.
akaService1 contains some services.
akaService2 contains some other services.
All the websites and services share akaDomain.
Can the domain classes present in akaDomain be used for scaffolding controllers and views in another application like akaService and akaWebsite?
Can this be achieved using plugins or dependency or both.
Please explain what am I missing if I don't make a plugin of akaDomain.
This answer uses plugin to explain how to modularize grails app.
You can definitely use the domains defined in one plugin as the basis for scaffolding in another plugin or in a main application. There are several practical considerations when doing so however:
If you choose to implement UI in a plugin, then you are committing to a UI look and feel that is to be shared across multiple applications. This is often very difficult when doing custom / contract development where every customer wants their own personal look and feel. You will want to think about selecting a UI abstraction as well that allows flexibility on theme support at least. We use Twitter Bootstrap for this purpose but there are several others that fit the bill.
You must manage the dependencies between the "domain/service" and the "UI" plugins. This is true of any plugin ecosystem, but once you commit to abstraction, this discipline is very important or you end up with dependency dead ends or cycles. It is a lot of work, but the pay off for productivity is very high.
As for the question on Grails Plugins vs Gradle dependencies:
Plugins are in fact Gradle dependencies (in Grails 3.x at least). That is, plugin dependency management is implemented on top of Gradle. Plugins provide additional support for integrating into a Grails application that include things like:
Automated spring bean registration and initialization at startup.
Participation in application component reloading.
Artefact definitions and initialization at startup.
So, implement using plugins and you get the best of both worlds.
I understand how to implement a StructureMap registry, my question concerns the fact that every project that contains a StructureMap registry requires a static reference to the StructureMap assembly. Is there a best practice for how to structure the configuration for a large number of projects (30+) without forcing each project to take this dependency?
The alternative, I suppose, would be to create a bootstrapper assembly that could be referenced by the host process. The bootstrapper would perform all wire-up. In this scenario, the bootstrap assembly, instead, would have references to all of the projects. This has the upside of centralizing the reference to StructureMap so that all of the projects are unaware of StructureMap.
Using XML-based configuration is not an option for me.
Are there any other options for configuration that minimize the number of static references the projects in the solution must take? I'm guessing that there isn't, but thought I'd solicit some other opinions.
Technically, you only need a single project to reference the container framework, and that is the top-level application project. It references all the other projects and specifies the configuration of the components.
This puts the entire graph configuration out of the hands of each project, opting instead to define graphs only where they are used. This gives each application the complete freedom to configure components, rather than assuming the components will be used in the same way every time (as is implied by the registries which are inherent to each project).
An aside that may or may not be useful: in quantum physics, when we observe a particle, we collapse it from every possible state into a particular one. Frameworks are similar, in that they don't exist in a single state until they are observed, which here means "put to use in an application." This frames the application as the observer, which is the context in which the framework collapses into a single form.
Now, I generally wouldn't want the application be responsible for both being a running application and also configuring that runtime. For this reason, I tend to have a Composition project which references the others as well as the container framework. The actual application project can then reference the Composition project. This externalizes the registries from each project, including the application project, producing a cohesive assembly whose sole purpose is to define the composition of a particular application.
When using a dependency injection container, missing dependencies are detected when you execute resolve. This is at runtime.
This article describes a partial solution. It would help simplify test, debug, and maintenance, but it still requires tests to be executed to validate your behavior (especially if you use the abstract factory sub-solution for runtime resolution):
http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx
When using dependency injection containers, is there a way to determine at statically that all of your dependencies will be resolved?
The Managed Extensibility Framework (MEF) can do this. There are some best practices that you need to adhere to in order for the analysis to be accurate, but the results are otherwise good.
To analyse a set of assemblies a command-line tool is used - see http://blogs.msdn.com/b/nblumhardt/archive/2009/08/28/analyze-mef-assemblies-from-the-command-line.aspx. This can be run from Visual Studio or a build script in a continuous integration server - http://blogs.msdn.com/b/nblumhardt/archive/2009/09/24/debug-composition-from-within-visual-studio.aspx.
You can do it visually (again over a set of assemblies) using the MefContrib project's Visual MEFX - see http://xamlcoder.com/blog/2010/04/10/updated-visual-mefx/
MEF supports this functionality by being both very declarative (standard attributes for configuration) and by using an underlying composition model that works lazily (it can build the graph without creating any instances... Takes a bit to wrap your head around.)
Short answer: no, it can't be done.
Doing this would require being able to represent all components and their dependencies (the container metadata) as a graph, in order to analyze it. Problem is, the more sophisticated the container, the harder it gets to achieve this. Take for example Windsor. Its numerous extension points make the dependencies too dynamic to be represented as a graph. Lazy component loaders, handler selectors, factories, componentmodel contributors, subresolvers, all participate in the process and they can be arbitrary user code, which makes it impossible to analyze statically.
A static analysis might be feasible for a trivial container, but then this hypothetical container would be pretty useless for real-world projects.
So as usual it's a trade-off, and the best we can do is have some tests that exercise the actual resolution of all registered components in the container. StructureMap has a AssertConfigurationIsValid() method to do just that.
Even so, there could be more subtle errors that are not caught by this, such as lifestyle issues.
In addition to what Mauricio said, Windsor 2.5 has a feature that you might find useful when diagnosing issues with missing dependencies or just looking through the components in the container.
I blogged about beta version of it here. It's now quite more useful and as everything in Windsor - it's extensible so you can out your own items on that list.
Maybe not with a dependency injection container. However, you can do dependency injection manually, without a container. For example:
var foo = new Foo();
var bar = new Bar(foo);
var program = new Program(bar);
program.Run();
If it compiles then all the dependencies are there.
However, trouble looms as soon as the dependency graph grows large enough that you can't keep it entirely in your head (espcially with some circular dependencies thrown in the mix). If you do refactorings that involve rearranging of dependencies, then it will become hard work to adapt the order of constructor calls.
Can anyone point me towards some good documentation / code examples on how best to manage the configuration of a DI container in a scenario where you need different configuations sets?
We have a layered, distributed application that has multiple entry points (ie; a website, winforms app, office plugin etc). Depending on how you are using the solution (through a UI vs. an automated workflow for example), it needs to be configured slightly differently.
We are using Windsor, and it's fluent configuration capabilities.
You should have one container per application, so at that level you must configure each container for each application separately.
However, having a common base configuration for a family of applications is a normal requirement, and most DI Containers support that by providing a way in which you can package configurations.
In Castle Windsor, you do that by defining one or more classes that implement the IWindsorInstaller interface.
Example:
public class MyWindsorInstaller : IWindsorInstaller
{
public void Install(IWindsorContainer container, IConfigurationStore store)
{
container.AddComponent<IFoo, Foo>();
// etc.
}
}
We are supporting the "multiple configurations" situation by using XML configuration files. If you are ready to let go of fluent configuration, the XML configuration file set is pretty straight-forward to manage and deploy.