I'm looking how I could get an Injector using Guice in a web application. I already found a solution using ServletContext, but I'm not really satisfied by this solution, because it breaks the layer architecture of the application. I'm not okay with using a ServletContext in the deeper layers of the app. Do you know another way?
An obvious solution would be to create my own singleton to host the Injector, but it seems to be that Guice should offer some out-of-the-box way to do this. I just can't find one yet...
Assuming you're using Guice Servlet and assuming the class you want the Injector in is injected itself, just inject the Injector.
Your application lifecycle is fully controlled by the servlet container, so the usage of a context listener to start the initialization process of your application is the logical result of that fact. Thus I wouldn’t say that that fact in itself is not breaking the layered architecture, just like a web request starting activity in the model layer neither breaks the layered architecture.
But in order to not break the layered architecture, the servlet context listener shouldn’t involve itself with the details of the other layers, it should only initiate the initialization. Thus all Guice related code, for example a Guice injector factory, should be located in its own layer. The role of the context listener should be limited to a call that starts the initialization (for example: MyGuiceFactory.init() or MyApp.init()).
Related
I'd like to extend usage of CDI in the app I develop. What I need is something like application context/scope but I need to handle multiple instances of beans based on how many records are in the database/configuration.
To be more specific, in our database, there's a table called PODs and for each record in this table, I need a separate group of beans (services, repositories, etc. - a whole object graph). There's no need for dynamic behaviour - it's OK to restart application when a record is created/deleted in this PODs table. But ideally items defined within this PodContext for a specific POD should be able to inject beans within the context of the same PodContext.
The obvious problem here is how to specify for which POD a bean instance should be created/injected.
That leads me to a question if a custom CDI context is actually suited for such a use case but without losing all the CDI goodies and building all the object graphs manually, I don't see a good way out :(
Update: My colleague suggested a solution for Spring Framework - we could have a parent context with all the shared application-wide beans, and also one child context for each POD, which would define beans for that specific POD. It's possible because Spring allows such context hierarchies. Is there anything similar in CDI?
Currently I have a Spring project that uses Spring JPA to work with data objects and my database. All of it's functionality can be accessed by calling a single facade bean. I want to make a web application based on this data model, but I don't want to extend this project any further. Instead I would like to separate my persistence and service layers from an actual web application layer. That said, I want to package this project into a ".war" file and deploy it on my Tomcat instance. Upon demand from any other application working on Tomcat I would like to have this other application to be injected with the facade bean from my ".war".
I'm sort of new to Tomcat, and googling doesn't really help me much. So here are problems and questions that I have with this concept:
Is this the right way to do what I want? What I mean is I want behavior provided by my current Spring application to be accessible and reusable by different web applications working on one server. This might be a common case and I would like to know if this is ok as a solution.
If I have this facade bean in XML context or in annotation context of my project, how can I make this bean visible to any other application working on the same Tomcat instance upon being deployed? What should I write in my web applications to have them wired with this bean? If I want this bean to be a singleton and have all calls to it's functionality synchronized, should I do this through my code/context, or can I have Tomcat somehow take care of this for me?
Thanks in advance.
You might want to consider a REST API approach. You can't do "cross application injection" with Spring and JNDI can be cumbersome to use.
Webapps (the things that run in a servlet container like tomcat) are isolated from each other, by design. Sharing may well be a bad idea. However, to share, you can use JNDI. Setting up JNDI in tomcat 7 is described here. You will need a custom resource factory.
Establishing connections to external systems (databases etc) as part of the spring context construction seems like bad idea. Does the framework contain any method for actual application lifecycle management ? Since I'm running in embedded-mode, my best suggestion yet is to use a ListableBeanFactory to get all the beans and make an interface with start/stop/isRunning on all the application beans. Do I have to roll my own or is there something within spring I can use ?
Spring has the Lifecycle interface which you can implement. This interface provides basic start, stop and isRunning methods.
You could also implement the SmartLifecycle interface which allows for a little more control over when something is invoked due the the additional Phased interface.
See also How does Lifecycle interface work in Spring? What are "top-level singleton beans"? and Load spring context in phases.
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.
I'm looking at this java web application that is using hibernate, jsp's, and spring framework. (from what I can tell!)
the file layout is like this:
classes/com/example/project1
inside project1
/dao
_entity_Dao.java
/dao/hibernate/
_entity_DaoHibernate.java
/factory
DaoFactory.java
DaoFactoryImpl.java
/managers
_entity_Manager.java
/managers/impl
_entity_ManagerImpl.java
/model
_entity_.java
/service
_xxxx_Service.java
/service/impl/
_xxxx_ServiceImpl.java
Have you guys read about this sort of layout somewhere? Is it considered best-practice?
What is the difference between a Factory and a Manager and a Service? (high level)
For typical layout of an application built with Spring I'd look at the example web applications that ship with it (meaning Spring).
Using things like DaoFactory is definitely not be a best-practice, the Daos should get injected instead. In general you should not need factories with Spring except for some unusual cases. Injecting is done when the web application starts up, spring reads the configuration information and constructs all the objects and plugs them in according to configuration xml and/or annotations (this is assuming singleton-scope for your objects, which is usual for stateless things like daos and services, things scoped as prototypes get new copies created as the application asks for them).
In Spring applications a service is similar to a Stateless Session Bean, it is a transactional layer encompassing application logic for a use case. So if your user takes an action that has the effect of causing several different tables to get updated you can inject the daos into that service, have a method on that service do the updates on the daos, and configure Spring to wrap that service in a proxy that makes that method transactional.
I've seen manager used as another name for what I described as service. Here I don't know what they're doing with it.
I don't like the idea of combining your interfaces and impls in one project. Just because you want to consume the interface doesn't mean you want to consume the impl and it's cumbersome transitive dependencies. The main reason is because there will be more than one impl (hypothetically, i.e. JPA/JDBC/Hibernate, or Axis2/CXF, etc.). The interfaces should not be bound to the implementation, otherwise the point is lost. This also allows for easy dependency injection as the impls simply reside on the classpath, then something like a Proxy or Spring (e.g.) can inject the implementations.
In all likelihood, all you need is a:
Interface Project
dao
EntityDao
types
Entity
HibernateImpl Project
dao
EntityHibernateDao
src/main/resources/
EntityMapping.cfg.xml