In this blog post Mark Seemann explains the different approaches to configure dependencies with a dependency injection framework. Convention over Configuration is one of this approaches. In the .NET world there are multiple DI frameworks which offers this feature (e.g. NInject, MEF 2). I'm searching for a DI framework with Convention over Configuration in the Java world. I looked at Spring and Guice but neither of them seems to offer this feature.
I would argue that hk2 has a convention over configuration like feature with automatic service population. It requires that you use the hk2-inhabitant-generator at build time to put some metadata into your built jar files. However, after that it becomes very simple to populate hk2 with your services. This is how GlassFish uses DI, where classloading at the start of the server had to be kept to a minimum in order to increase boot performance.
There's one for JavaFX by using afterburner.fx is JavaFX MVP framework based on Convention over Configuration and Dependency Injection.
Related
I have seen a Spring application, and it uses spring dependency injection in addition to that some places I find Java Dependency injection. I am not sure why Java DI is used. I googled it, however, I can’t find an exact answer.
Anybody can explain why Java DI is used in addition to Spring DI?
Dependency Injection in Java is a way to achieve Inversion of control (IoC) in our application by moving objects binding from compile time to runtime. We can achieve IoC through Factory Pattern, Template Method Design Pattern, Strategy Pattern and Service Locator pattern too.
Spring Dependency Injection, Google Guice and Java EE CDI frameworks facilitate the process of dependency injection through use of Java Reflection API and java annotations. All we need is to annotate the field, constructor or setter method and configure them in configuration xml files or classes.
This link may help you more
To be simple, If you need Dependency Injection through Java you need to implement using some Design Patterns, which is time consuming. Frameworks like Spring helps to implement DI using annotations and configurations which are developed using specific design patterns. As a developer we need not worry about DI, we can just concentrate on our business logic.
Spring Framework provides a wonderful abstraction layer for low-level resource access in Java (the Resource and ResourceLoader interfaces). I'm developing a library which should not be dependent on Spring, and am looking for an equivalent for this capability in a stand-alone Java library. Anyone familiar with one?
Why not just use the one from Spring by itself? It doesn't look like it has any dependencies on the rest of Spring.
Edit
Not sure I understand the problem - you want something that does exactly the same thing, but doesn't come from Spring? Is it a licensing issue?
You only need half a dozen classes from it, if you don't want to add them as an extra jar, move them to your own namespace (good idea anyway, in case you do use Spring at some point, after all) and distribute with your library. Again, assuming your licensing allows it.
If licensing isn't the problem, can you be more specific about why you can't use the Spring implementation in your own library?
You can use Jsr-303 (DI) to match your requirments. The most known implementation is Google Guice. It's a javaEE standard (maybe JavaSE).
I'm working on a 10-year-old Java webapp, and I would like to introduce some new technology into the project. One of the things I would like to start doing is dependency injection. I know the Spring Framework has the capability to do dependency injection, but I am having a hard time integrating the framework into the old project.
Could someone provide an example of what I would have to change in my web.xml, other files I would have to add, and other changes I would need to make? I want the smallest Spring footprint while still being bale to do dependency injection.
There are a lot of examples online about starting a new project using Spring, but I can't find any about integrating Spring into an old project.
Thanks.
You'll have to start by adding a context loader listener into your web.xml, along with the locations of the Spring configuration XML files.
You should configure the Spring DispatcherServlet to accept all URLs that you wish for it to handle.
You should write Controllers to bind and validate HTTP requests, call services, add data to ModelAndView for rendering, and map JSPs to success/failure views as needed.
You should put interfaces in front of your service and persistence tiers. Move implementations into implementation classes that Spring can inject.
Leverage Spring AOP for security and transactions and logging as needed.
Throwing new technology at a project wont make it faster\better, unless you introduce the new technology to all parts of the project. The idea behind DI is to lose dependencies between objects. The project probably is tightly coupled, so you'd have to rewrite at least parts of the thing. Depending on the size, this can be a monster to beat - ask yourself if this is worth it, if it has any positive effect on the project other than introducing new technology.
The reason why there are little to none tutorials about integrating DI container into an old project is quite simple: it usually doesn't make any sense. Either you use the pattern in all places, or none at all. The bastard child that would be creating by mixing both would be a horror to maintain. I'd really advise you think about why you want to introduce a DI container into that 10 year project. Unless there is a real good reason for doing it (and you are happy with rewriting a lot of code) don't do it.
we have a frontend application that that uses Swing. We use Spring framework, but currently it is used just to autowire few beans...
What are reasonable next steps to use Spring more often?
Is it worth for non web application?
What would be advantages and disadvantages?
The advantages of using Spring (or any other dependency-injection) framework, is that you get a (hopefully) loosely coupled system, i.e you classes does not create instances of their collaborators, so you can easily change the implementation.
This is widely known as the Inversion-of-control principle (IoC, also the I in SOLID), and this is a good principle to follow. This means that spring is not limited to web applications, but can be used in any application that want to use an IoC-container (which is basically what spring-core is).
Disadvantages:
This really depends on how you look at things. There is more code (you have to define a entry-point for the injected collaborators), but that also makes the code more testable (the entry-points are seams which you can use to inject mocks and stubs in testing).
Also, you can't look at the code and immediately see which implementation of the collaborators that are used. But that also makes for good code, since you depend on interfaces, not implementations.
You get more config: either in an xml-file (old-style spring), or with annotations. Up until recently you had to rely on non-standard spring annotations to inject (#Autowired) resources, but now you can use the standard java dependency injection annotations, which means that you can switch out spring as your IoC-container without changing your code.
There are probably alot more advantages and disadvantages to using spring in your application, but this should get you started on deciding if using Dependency Inversion is a good thing for your application
More to the point of your question about Swing and Spring. In an application I have been working on we have been using spring to wire up the whole application. The different dialogs get their logic injected (no application logic should (in my opinion) be located together with gui logic). We are using JPA/hibernate as the database-layer, so we use spring spring to create and inject the entitymanager to our DAOs, and set up transactional settings.
I've written swing UI's that are backed by spring.
cons
the startup can be slower but you have to have a large app for that to happen.
and a splashscreen is a good idea in those situations.
its easy to "overbean" or over-zealously make everything a bean, which gets messy.
pros
spring works fine behind a GUI.
it provides a lot of services you can use
the obvious dependency injection and decoupling
a global event system, simpifying some of your own event listeners, for events that will only ever be fired by one source
resource accessing
database access is eays in 2 tier apps
rpc for 3 tier apps is easy
There are other services the spring application context provides, but that I haven't used.
If you go this direction, also look into the java-based configuration for spring, which is new in 3.0. I find that helpful as well, as it makes my spring configuration type-safe.
One disadvantage of using Spring in a Swing application is that Spring DI will make startup slower.
well one would be , if you ever decide to migrate to a web app , all you need ( well almost) to change would be the views. That's the beauty of MVC applications.
For instance, I am using JSF + custom framework developed in our company. Now I want to use a third party validation framework that can be used as an plug-in and it should not create any dependency what ever may be the technical stack.
So my question is does spring provide any framework of that sort or if it's available how can I use that?
I am expecting a validation framework something like, which is configurable through XML.
Spring does have a validation framework, but if you want minimal dependencies, then I'd suggest that you go with a Bean validation provider. It's a new(ish) official validation standard, defined in JSR-303.
There are several implementations at the moment. I'd give Hibernate Validator a look.
I disagree. Hibernate Validator is an awful piece of software (at least the versions that were current about a year ago). Spring Validation is a nice piece of software, that goes together well with the BeanWrapper interface.
But it's true: Spring Hibernate resides inside the Spring Context jar, which is unnecessary overhead. Hopefully there will be a separate version sometime.