I have an enterprise application built with Java 6, Spring Framework 3.1.2 and Mule-ESB 3.3.0, among other libraries not related to this question.
Our beans and services are all declared with #Named and #Inject JSR-330 annotations, respectively for automatic component scanning and for dependency injection (no EJBs, only service beans). When deployed into JBoss 4.2.3 (our test environment) everything works fine. However, when deployed into WebSphere 7, the JSR-330 annotations seem not to be working. The beans marked with #Named are just not detected, at all.
I can assure everything is configured right (since it is working in JBoss). Specifically, the <context:component-scan /> has the base-package attribute correctly defined and the scope-resolver attribute correctly configured to use Jsr330ScopeMetadataResolver (we tried without it too).
I am aware WebSphere 7 (7.0.0.23) may not support such kind of annotations. I am yet to test it with #Component and #Autowired Spring equivalents. Unfortunately, we would very much like to use JSR 330 annotations so our classes wouldn't directly depend on Spring, even though we're using Spring Framework under the hood.
Nevertheless, although I'd spent one full work's day looking for a definite statement that WebSphere 7 does not support JSR 330 annotations, I haven't found anything so far.
Further, I can't see why it would not work, since I'm assuming Spring Framework is the one doing all the work, through the <context:component-scan /> directive in the application-context.xml file.
Can anyone bring some light into this issue?
Is there a way to activate dependency injection via annotations in WebSphere 7?
If I switch back from the JSR 330 #Named / #Inject annotations to Spring's own #Component and #Autowired is it likely to work?
In a desperate attempt, can I extend Spring's ComponentScanBeanDefinitionParser so it will detect JSR 330 annotations even in WebSphere 7?
If nothing works, I will eventually fall back to plain XML configuration. That is highly undesirable, however, because there will be hundreds of beans to be manually configured in the XML.
WebSphere 8 seems to be the correct version to use; it supports EE6 (WebSphere 7 is EE5), which in turn contains CDI 1.0 (hence JSR 299).
Below is a snippet from DeveloperWorks that summarises relationship between WebSphere versions, JSR 299 and JSR 300
Dependency injection is a technology that has surfaced in various
implementations many times before making it into the Java EE world.
The Spring Framework and the Google Guice library are popular
implementations. In JSR 330, an attempt was made to include these
capabilities into the J2SE platform. JSR 299 is a specification that
used the APIs defined in JSR 330 and added more capabilities to
support Java EE needs. IBM WebSphere Application Server V8 and V8.5
(non-Liberty profiles) are fully compliant Java EE 6 containers and
implement JSR 299.
I eventually came up with a workaround by extending both Component Scan and Autowire features of Spring Framework.
First, I added an inclusion filter to the Component Scanner so that #Named annotations were also considered eligible for detection and registration to the Spring Container:
<context:component-scan base-package="com.mycompany.mysystem">
<context:include-filter type="annotation" expression="javax.inject.Named" />
</context:component-scan>
Following that, I also added a bean definition to org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcesso‌​r, extending the autowiring eligibility to #Inject annotations:
<bean class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor">
<property name="autowiredAnnotationType" value="javax.inject.Inject" />
</bean>
Initially, this worked fine as to "reactivating" the #Named and #Inject annotations. However, I still had some problems of conflicting beans on the autowire candidates resolution process. This was due to the differences in the default resolution process of Spring and of JSR-330. This was no big issue, since only a few beans fell into that scenario. They were all solved by adding some strategically placed #Qualifier annotations.
Now everything is working fine and elegantly, with few extra configurations. Nevertheless, I still don't understand why this happened. All I know is that the following 3 lines do appear when I deploy the application into JBoss 4.2.3. On the other hand, they don't appear in WebSphere:
INFO [org.springframework.context.annotation.ClassPathBeanDefinitionScanner] JSR-330 'javax.inject.Named' annotation found and supported for component scanning
and
DEBUG [org.springframework.beans.factory.support.DefaultListableBeanFactory] Creating shared instance of singleton bean 'org.springframework.context.annotation.internalAutowiredAnnotationProcessor'
DEBUG [org.springframework.beans.factory.support.DefaultListableBeanFactory] Creating instance of bean 'org.springframework.context.annotation.internalAutowiredAnnotationProcessor'
INFO [org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor] JSR-330 'javax.inject.Inject' annotation found and supported for autowiring
I still have no clue as to why this happens, since, as #Dreamer said, this should be a Spring's responsibility, and thus, out of WebSphere business.
If someone do have such a clue, please enlighten us. Im sure it would be wonderfully clarifying to everyone participating in this discussion.
Agree with duffymo, it should work on WS 7. As Spring is on top of Websphere so Spring annotation is out of webshere's business(sort of).
One thing you probably need to check on WS 7(even though you said every configuration is correct as it works on JBoss) is click your application -> click Class loading and update detection, make sure the Classes loaded with local class loader first (parent last) is checked. That would make the server to take your application's library come first followed by websphere's library.
Related
Hy,
Reading a lot about Spring AOP vs AspectJ, I still have some doubts:
1.)When using Spring AOP with classes annotated with #Aspect and using "aop:aspectj-autoproxy" tag , it can be said that we are using just the annotations of aspectj or besides that it is being used AspectJ too for the weaving?
2) Its said that AspectJ has better performance because the weaving is in compilation time, it means that the target class files are physically changed inserting the aspects in them? is it not a bit aggressive?
3)It said that Spring uses proxys for AOP, so, I undertand that when you get a bean from Spring, Spring builds a proxy in memory that has already inserted the aspects in it, right?
So why is it said that when a method from your proxy bean calls other method in the proxy, the last method will not have aspects?
Thanks
1) using aspectj-autoproxy means that #Aspectannotations are recognized, but Spring proxies are still being created, see this quote from the documentation:
Do not be misled by the name of the element:
using it will result in the creation of Spring AOP proxies. The
#AspectJ style of aspect declaration is just being used here, but the
AspectJ runtime is not involved.
2) AspectJ supports load time weaving, byte code weaving and compile time weaving. There should no difference in performance, it's just a different point in time to weave the aspect in (compilation, third party jars available, class load time), see this answer for further details.
It is actually more transparent once it's set up to have the aspects weaved at these moments, with runtime proxies there are problems when a bean calls itself using this.someMethod, the aspects don't get applied because the proxies get bypassed (#Transactional/#Secured does not work, etc.).
3) Have a look at this picture from the documentation:
With runtime proxies (non AspectJ), Spring leaves the bean class untouched. What it does is it creates a proxy that either implements the same interface as the bean (JDK proxy), or if the bean implements no interface then it dynamically creates a proxy class with CGLIB (subclass of bean).
But in both cases a proxy is created that delegates the calls to the actual bean instance. So when the bean call this.methodB() from methodA, the proxy is bypassed because the call is made directly on the bean and not on the proxy.
Spring AOP can be configured with AspectJ-sytle, ie annotations are parsed to build configuration but AspectJ compiler is not used for weaving. Only a subset of AspectJ annotations and poincut definitions can be used with Spring AOP.
Maybe, but I don't know any class that has complained. However, is possible that some classes don't allow re-weaving when modified by other bytecode tools.
Inner calls are not proxied because they call on this.method() (with this = the target bean begin proxied) and not on proxy.method() so the proxy has no chances to intercept the call. However, Spring AOP proxies usually notices when a target method return this and return itself instead, so calls like builder.withColor(Color.RED).withHat(Hat.Cowboy) will work. Note that in Spring AOP there are always two classes involved: the proxy and the target.
Is there a Java EE 6 / 7 equivalent annotation for Spring's #Configuration?
If the answer is yes then are the equivalents for its surrounding annotations, such as #ComponentScan and #EnableWebMvc?
I did, of course, look for it in Java EE 6 / 7 (I admit I skipped a paragraph here and there), in javadocs (specifically among annotations), in Spring doc, tutorials, blogs, SO and Google.
JEE CDI has also an annotation of creating bean programmatically and exposing them, so it offers bean factories, called producers:
https://dzone.com/articles/cdi-and-the-produces-annotation-for-factory
CDI offers Producer methods (annotated with #Produces) which is the equivalent of #Bean in spring. You can than implement Producers classes that are beans which contain a bunch of producer methods. However, this is by far not as powerful as a spring configuration since as far as I am aware of, there is no possibity to e.g. "import" other configurations (producer classes).
This makes it especially difficult to test CDI applications.
You can either
heavily use mocks to test a single CDI bean to totally avoid injected objects
blow up your test class just to create the instance under test with all dependencies
use testing frameworks like CDI-Unit that creates the beans for you
With 1. Test Driven Development becomes almost impossible and tests have always to be adapted when implementation changes, even if the contract does not change.
With 2. you end up in a lot compiler errors in tests as soon as dependencies between your Beans change
With 3. you need to point your testing framework to the implementation of your beans. Since there exists no Configuration that knows about all beans, the test needs to know about it. Again, if things change your tests will break.
I admit... I don't like CDI ;-P
The javax.servlet.annotation package defines a number of annotations to be used to register Servlet, Filter, and Listener classes as well as do some other configuration, for example, security.
You can also use the ServletContainerInitializer class to configure your ServletContext through Java instead of through the XML deployment descriptor. Spring provides its own implementation of ServletContainerInitializer in which case all you have to do is create a class that implements WebApplicationInitializer and does servlet, filter, and listener registration and leave that class on the classpath.
Examples abound in the javadoc.
Is there a possibility to configure spring so that it doesn't initialize beans with #Named annotations?
My current work around is to make such beans #Lazy so they don't get initialized when the application context is created, but I would prefer to have nothing related to spring in such classes.
Note this two options are not good for me:
1. Suggesting to go back to a previous version of spring that didn't support JSR-299 is not an
2. Putting JSF beans in a package that is not auto-scanned by spring.
You can try to exclude #Named using a filter when configuring component scanning (in <context:component-scan> or #ComponentScan).
See also:
4.10.3 Using filters to customize scanning
I am using a #configurable annotated Vaadin controller together with my Spring context, and it is working fine - except when I need to restart Tomcat, and the sessions are deserialized. Then I get this for my Vaadin app:
org.springframework.beans.factory.wiring.BeanConfigurerSupport BeanFactory has not been set on BeanConfigurerSupport: Make sure this configurer runs in a Spring container. Unable to configure bean of type [web.vaadin.ui.BackOfficeApplication]. Proceeding without injection.
I am thinking that this can be because the vaadin app is reserializing before the spring bean factory has a chance to?
(I am using CTW - aspectj and Spring 3.1.1.RELEASE)
Note:
It seems in the log that these errors come before the "Root WebApplicationContext: initialization started". How can it be that the beans are being autowired before the context initialization is started?
I am not an expert on (de)serialization with Spring and Tomcat, and this is not an answer but might be a workaround.
If BackOfficeApplication is your Vaadin application then there is an alternative to using #Configurable on that class. Instead, create a per-Vaadin Application Spring application context XML file and add this to it to cause your BackOfficeApplication instances to be autowired, etc.:
<bean id="backOfficeApplication"
class="org.dellroad.stuff.vaadin.ContextApplication"
factory-method="get"/>
In general, #Configurable can be more troublesome than normal bean wiring because they require the configuration to occur at object construction rather than allowing the bean factory to do the wiring later on, where it may be better able to detect loops, enforce ordering, etc.
Ideally normal bean wiring should be used for singletons that are initialized once at the beginning of the application and #Configurable should be used for "on the fly" beans created randomly during normal operation.
I would like to achieve this idealism :
To have only 1 implementation for the JSF Bean container, like to use only Spring or Weld but not both. Currently i am using Spring for my backend, so i prefer Spring.
To have only 1 annotation, to choose between #ManagedBean, #Named, #Model
To be able to use all supported scopes, like #RequestScoped, #SessionScoped, #ViewScoped, #FlashScoped, maybe also #ConversationScoped
The JSF Beans could be injected with spring-managed-services (The backend services), perhaps using #Inject or #Autowired
So far i've been finding no best combination to achieve these because as far as i know, please correct me if i am wrong, :
#ManagedBean can not be injected with spring services ?
#Named can be injected with spring services using #Inject, but #Named is using Weld. Can i just use spring to managed the #Named instead of Weld ?
#Named doesnt support #ViewScoped and FlashScope ?
Please share your thoughts and experiences.
Thank you :-)
UPDATE 15 March 2011
Found an interesting page that describes how to replace Jboss Weld with Spring as the JSR 299 CDI implementation. So basically, the question number 2 is answered. Number 1 is also answered indirectly since i can now inject spring services.
But still, the number 3 question remains. I would find very helpful if i can use the #ViewScoped and Flash Scope in the #Named, something like this article. Flash scope implementation has yet to be seen, but the closest one i can get so far is this page.
Hopefully, replacing weld with spring as the jsr 299 implementation will still enable me to use #ConversationScoped.
Gotta test things now, wish me luck :-)
UPDATE 18 MARCH 2011
Successfully make use of Spring 3 instead of weld to do the #Named, #Inject. The important thing is to set the el-resolver in the faces-config.xml.
AFAIK, Spring 3 currently doesnt support CDI yet, so bye2 #ConversationScoped.
For the scoping, i must still use #Scope("request") or #Scope("session"), but if i prefer the #RequestScoped (javax.enterprise.context.RequestScoped) and #SessionScoped, i can make use of the bridge provided from this article.
The Scope("view") for spring from this article works like magic :-)
One problem remain though, how to pass objects between Scope("view")-beans ..
Wish me luck !
update
Ahhh .. finally done ..
Passing the variables using Flash provided by JSF2 really works like magic.
I dont need an 3rd party implementation for that.
So basically, i can do without weld, but with spring, with the common scopes available, including the view scope, dan can pass between beans using the flash object.
One thing missing is the conversation scope, which isnt a major problem to me yet.
Hopefully the future spring can support this conversation scope.
Cheers :-)
I can successfully Inject Spring bean using ManagedProperty annotation like below. This is on JSF Managed Bean. Spring bean is for backend and I prefer spring for backend.
#ManagedProperty(name="userRepository", value="#{userRepository}")
private UserRepository userRepository;
//Setter and/or Getter
value is the most important thing here. It's actually the bean name of spring. I hope this helps.
Weld (actually, the reference implementation of JSR-299 Context and Dependency Injection, also known as Java EE 6 CDI) was less or more invented to supplant Spring in Java EE 6 environments. I would suggest to use Java EE 6 CDI instead of Spring. Why would you use a 3rd party framework when Java EE 6 provides the same functionality out the box?
If the Spring backend really cannot be changed, then I'd suggest to stick to it and not to intermix with Java EE 6 CDI annotations to save yourself from confusions and maintenance headache.