In an MDB application, Can the EJB3 Interceptor be configured to log the Non bean class methods, which are inturn invoked by the bean method (OnMessage)?
Thanks in advance
No, EJB interceptors are only applicable to business methods. For non-business methods, you need to use an aspect-oriented programming technology.
Related
I am developing Spring MVC app, i need to implement singleton pattern for some kind of utilities, ex: imageuploader and others.
My question is: in what way to implement singleton for this utilities, to initialize beans for these classes and inject where i need like Controllers, Services, DAO?, or to use static field implementation of singleton to keep instance of this class?
First, try to avoid singleton as it's considered to be a bad practice. Also their interactions with other instances are difficult to test and validate, compared to non-singleton instances.
If you absolutely need it, I'd suggest you use a Spring bean so you can exploit the autowiring mechanism and Spring's bean lifecycle.
See the Beans section of the Spring reference doc for more info.
Using a Spring bean as will allow you to easily inject a mock in unit tests. However, you will only be able to access it from other Spring beans (or objects created by Spring beans that pass in a reference to it).
Also see this discussion in this question: Difference between static class and singleton pattern?
Traditionally, you'd use PropertyPlaceholderConfigurer to inject config from properties files into a Spring web-app. This blog discusses a variety of newer ways to do this with Spring.
I'm new to Spring and a little confused about how it works. I get that I can use the application context to instantiate beans and have them populated. However, is the idea that I should be able to just write Bean b = new Bean() and then have Spring to somehow automagically populate that Bean?
I'm experimenting with Spring in a web application, and as far as I can see I need to inject the ApplicationContext into, say, the servlets to be able to instantiate other beans (services, daos etc.) from there. It's a bit cumbersome, but probably works.
However, is Spring meant to be able to hook into any object instantiation which happens on classes defined as beans in applicationContext.xml?
Spring is an Inversion of Control container. A bean is an object whose life cycle is managed by Spring. If you want Spring to populate an object, it needs to go through Spring, ie. it needs to be bean.
is Spring meant to be able to hook into any object instantiation
which happens on classes defined as beans in applicationContext.xml?
Spring doesn't hook into anything. You configure your beans and the relationships between them with Spring and Spring handles creating the instances and linking them up.
For domain objects, Spring provides a solution via the #Configurable annotation: http://docs.spring.io/spring/docs/4.0.0.RELEASE/spring-framework-reference/htmlsingle/#aop-atconfigurable
It requires compile- or load-time-weaving and, thus, introduces some additional complexity but having the convenience of using the standard new Bean() syntax plus Spring's autowiring is worth it in my opinion.
Alternatively, you could define your domain objects as beans with prototype scope and use some factory to create them using the Spring ApplicationContext.getBean() method. With a scope of prototype a new instance will be returned every time and since you go through the ApplicationContext, Spring will do all the dependency injection magic as usual.
As for services and other beans with singleton scope, you would typically NOT retrieve them by first injecting the ApplicationContext and using it but instead you would inject them via either a constructor, setter or annotation-based strategy. The documentation covers that in detail: http://docs.spring.io/spring/docs/4.0.0.RELEASE/spring-framework-reference/htmlsingle/#beans-factory-collaborators
In case of REST implementations in Spring, spring Controllers are singleton. I want to know why spring controllers are singleton apart from thread-safety issue. Please help in resolving this issue.
This has nothing to do with REST.
Spring beans are, by default, singleton scoped. Since component scanning a #Controller annotated class simply generates a bean, that bean will be singleton scoped.
For reasons why a #Controller bean should be stateless, read any and all of the following:
Are Spring MVC Controllers Singletons?
Controller's life-cycle in Spring MVC
To follow up on the REST question, REST is meant to be stateless. In other words, each request contains all the information it needs for the server to handle it. Knowing that, it's pointless for the server (or #Controller) to keep any information after it's finished handling the request in instance fields and the like. Therefore a singleton is the way to go.
I'm in the process of converting a Java EE 6 application to Spring + non-EE Container (for example Jetty) and I'm looking for an alternative to Java EE's Singleton Session Bean (usually implemented by using the #Singleton annotation).
The Singleton aspect of it is easily handled by Spring. But the #Singleton annotation also implies concurrency guarantees: By default, all methods of a Singleton Session Bean are strictly serialized by a write-lock. (The behavior is can be changed by using the #Lockannotation.)
Is there any (ideally drop-in) equivalent in Spring? The #Lock customization feature is not necessary, I'm just looking for a better alternative than manually synchronizing every method of every Singleton Session Bean.
There seems to be no equivalent in Spring. I ended up using manual synchronization where necessary.
In EJB because of performance reasons beans should be stateless, then application server can maintain pool of beans and assign them to requesting clients.
What is Spring equivalent for such type of beans? In Spring we've got other scopes of beans: singleton, prototype, request, session, global session.
Each Spring bean should be implemented statelessly as a singleton. Do not introduce state into a singleton bean. There is no real benefit from pooling in such an architecture.