I know that the general consensus is to use one or the other, but we have a specific task where we would like to use our spring services from within a stateless ejb timer.
Is there a standard way of getting a spring service from outside the normal flow of my web app? (Note I'm using the stripes framework and it has built in spring support and I'm using this built in support to access my spring services normally)
According to the Spring manual you can configure an EJB 3 injection interceptor that will take care of injecting #Autowired springbeans into your EJB Session Beans.
Related
I have a multi module Maven project. One of the modules is Spring backend that has DAOs, transactional services and REST controllers for some angular clients (Ionic framework)
Now I find the need to add a new Wicket module for a web client. This module uses the first module as a dependency. When I start the Wicket application the Spring context gets started from the dependency and the REST interface is available for the ionic clients. My issue is that I cannot tie the Wicket application to that existing Spring context. Wicket just wants to start a new Spring context with the same beans.
Now I can access the beans through some static methods from the spring context, but I want to use the #SpringBean annotation as in a regular Wicket+Spring application.
Is there a solution for this?
Thank you!
Wicket does not start any Spring context, as long as you don't instruct it to do so. Are you using the filter init-param "contextConfigLocation"?
When you just register a Spring injector inside your application, it should pick up the default Spring web context (it uses Spring's WebApplicationContextUtils#getRequiredWebApplicationContext()):
getComponentInstantiationListeners().add(new SpringComponentInjector(this));
If I understand correctly, your Spring backend is a web application, not just a java module. You cannot not (should not) have this web application as a dependency to an other web application (your new Wicket module).
You should probably move your shared business logic in a new java module. This new java module can be a dependency of your 2 web applications (Spring backend and Wicket).
An other solution would be to have 3 web applications. Spring facade, Wicket facade and Spring backend. Spring facade and Wicket facade, would just be some simple REST Controller which would redirect the request to the Spring backend to execute the business logic.
I am trying to learn Spring Framework, before that I used to create application with EJBs
[Web services]->[Business Layer]->[DAO Layer] | [Database]
in following way
WebServices: Restful API using Jersey with url mappings, that support both JSON and XML format( news/list.json, news/list.xml). Once a request is received by an endpoint(url-mapped-method) it is forwarded to a relevant EJB through lookup(remote, local). EJB process every thing, apply business rules and return result as DTO(Data transfer object),Service then transform the result into required format (JSON, XML)
Business Layer: Business Layer (Facade) implemented in EJB with remote and local interfaces, these EJBs can call other EJBs. WebService layer(and/or Timer service and MDBs) can also call any of the EJBs). For timer service related functionality I used EJB Timer Service and for Messages used Message Drive Bean and interceptor for logging and auditing.
DAO Layer: All the Database related functions(add,edit, delete, search) JPA/Hibernate using EntityManager are written here (Entity beans and HQL).
Seamless Transaction support, each EJB's method (lookup-based) call is treated as a separate transaction and calling methods of DAO layer are part of same transaction(provided that no extra configuration is provided). multiple operations are carried out in a single transaction If one db operation fails all others are roll backed automatically. Each Table is mapped as an entity class with relations etc.
I have worked on Spring MVC but could not map/understand correctly for above architecture
I know bit about AOP and that I think is a perfect replacement for Interceptors (or at least it work for me)
Now my question is how all these could be replaced in Spring framework?
Jersey (RestAPi) alternative in Spring>
EJB alternative in Spring (as EJB supports remoting, each lookup call to a method is treated as a transaction, calls to EJB's method could be intercepted and it comes with state-full and stateless flavors)?
Timer Service alternative in Spring?
Message Drive Bean alternative in Spring?
Interceptor alternative is AOP in Spring (As per my experience and that serve my purpose)
JPA(entity manager) alternative in spring?
Jersey (RestAPi) alternative in Spring?
Spring MVC does this perfectly fine, in my opinion. Just annotate your methods in your controller as the REST apis you want to use.
EJB alternative in Spring (as EJB supports remoting, each lookup call to a method is treated as a transaction, calls to EJB's method could be intercepted and it comes with state-full and stateless flavors)?
There is no full alternative. There are several techniques that implement this in parts: Spring remoting for remote calls, Spring transactions as transactions, Spring AOP interceptors for intercepting calls. However, for example XA transactions on remote calls are something you don't get as such in Spring. Spring however works fine with EJBs, so if you prefer them, you can still have them and use Spring in other parts of your software.
Timer Service alternative in Spring?
Spring task scheduling
Message Drive Bean alternative in Spring?
Message Listener Containers
Interceptor alternative is AOP in Spring (As per my experience and that serve my purpose)
There are several levels of interceptors in spring. There are handler interceptors in mvc, there are bean call interceptors like the SpringAutowiringInterceptor, and there are AOP-based interceptors that can be used in multiple layers.
JPA(entity manager) alternative in spring?
Spring has multiple of these as well. It's actually quite straightforward to just use JPA with Spring-Data, it's designed to integrate to JPA. There are Spring JDBC and other data layer alternatives though if Spring Data is not what you want.
Jersey (RestAPi) alternative in Spring ⇨ it's rest api (in spring with #Path annotation) or spring mvc if you want to use controllers (#Controller annotation)!
EJB alternative in Spring ⇨ Spring doesn't give statefull bean out of a box but you can use #Service annotation (or #Repository for DAO) but you have to handle transactions manually (with annotations for example)
Message Drive Bean alternative ⇨ There is no equivalent out of the box in Spring, you could use injection and librairies of Spring to get it working (package org.springframework.jms should contains what you need)!
JPA(entity manager) alternative is not ejb ⇨ so it can be used in Spring.
Spring is a lighweight library so you can do all you do with EJB but it's more configurable so you will have more work to do the same that EJB do. But this configuration brings you some advantages: you have the hand on it!
This explains Spring and Java EE (which is what you would have used EJBs in) side by side: http://www.slideshare.net/reza_rahman/java-ee-and-spring-sidebyside-34320697
Jersey offers Spring solutions too - see their website
Spring does support remote calls through, e.g., RMI; It also supports transactions; AFAIK, no explicit stateful/stateless Spring Components - it depends on how you use it
AFAIK nothing as awesome as TimerService, however, you could use Quartz
Spring offers MDPs (Message-Driven POJOs)
Spring does support JPA - see first link.
Another cool comparison slideshare: http://www.slideshare.net/kelapure/java-e-evsspringshootout
Can or should a Service layer be a Spring bean?
If so, how should it be got from a calling application, a consumer of a service?
Because the consumer must be aware that such a bean exists, so it in any case must use Spring
to make use of Service methods.
Of course. The service layer is the part of your application that is visible to other users (e.g. a Web layer) so it needs to be configured and setup somewhere. Imho a Spring configuration is the best place to put this configuration in. The Service Layer user then has to take care of instantiating that context and getting the Service Objects he needs.
An alternative - if it needs to run standalone - would be for your service class(es) implementing the Service Layer interface(s) to instantiate the Spring application context themselves.
By making your consumers also spring beans, and inject the service bean with dependency injection.
Yes, It is always nice to configure service beans as spring beans. In the web layer you need to take care of instantiating the needed service objects. Another option is to make the web layer classes also as spring beans and inject the necessary service layer spring beans. From the testing point of view also, this type of design is very helpful when we use Spring testing framework.
I am using Spring to manage my DAO & Services. And JSF for UI. I want to use dependency injection in my JSF backing-bean. There is an article that explained how I can do that.
But I have two separate projects: one for Service and one for UI. The Spring configuration file is located in Service project.
How can I connect both project with Spring? I want to annotate my JSF pages for DI.
You can achieve this by using Spring Web Flow.
Spring have examples which show:
A JSF centric approach where your Spring and JSF beans are managed/configured the JSF way (faces-config) and a
Spring centric approach where your beans (including ManagedBeans) are managed in the Spring Context.
See Spring Flow Web Home
If you mean that you have one WAR with web services defined in it, and another separate WAR with the JSF stuff, I think it's really two separate projects each with their own Spring configuration.
The web service WAR will use either Spring web services or perhaps HTTP remoting to expose your service interfaces to clients via HTTP. This will have one set of application context configuration, either XML or annotations.
The JSF WAR will have the JSPs and controllers. The controllers will be injected with clients that will interact with the remote services to accomplish what you wish. That's all they need to know about the service WAR. There doesn't need to be any duplication of configuration at all.
It's actually a nice design, because it completely decouples the view from the rest of the problem.
Thank for everyone I did it. My mistake was with bean initialization. I tried to access my injected bean in constructor, but must must did in #PostConstruct method. And all that time i tried to find mistake in my config file. But it was in such simply place :)
I find some solution one:
Sample Application using JSF, Spring 2.5, and Java Persistence APIs with Glassfish v2
. But I have problem with it.
I can post this problem hear or must create new topic? Sorry for stupid question, i'm newbie her.
What role is Spring taking in Struts + Spring + Hibernate?
Spring provides many different "modules" and different programmers will use different parts of Spring.
However, commonly in this sort of stack, you will see Spring being used as a provider of
An inversion of control container for dependency injection
An abstraction to Hibernate called "HibernateTemplate"
Framework classes for simplifying Aspect Oriented Programming
Transaction support, often "declaratively" via the IoC container and AOP.
Well, Hibernate handles the persistence part, JSP handles your GUI, Struts controls the flow between pages/actions/etc, and Spring can manage all your beans which contain the main business logic, instead of using EJB. Plus it can simplify the coding of your Hibernate DAO's and transaction managing.
Instead of having to code your Locator to obtain some EJB through JNDI and all that stuff, you can just get the Spring ApplicationContext and ask for the bean you need. All the beans defined in Spring can be interconnected. If you have to connect one of your beans to an external EJB through JNDI you can even do so without any code (Spring offers a JNDI proxy object which obtains the reference you give it and returns it as an object with the interface you specify). This can help you simplify unit testing of all those beans and change the config without recoding anything; you can use one of Spring's PlatformTransactionManagers to manage a DataSource or point it to a J2EE container's JTA manager; define your own pooled DataSource or use your container's DataSource published through JNDI, etc.
Well to add;
(Views and Controllers) Struts for its extensive JSP features with Struts tags and web request handling features
(Service and application management) Spring to handle the ORM and service layers with its excellent dependency injections,etc.
(ORM with db independence) Hibernate for well proven ORM