2

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.

M. Deinum
  • 115,695
  • 22
  • 220
  • 224
Filipe Fedalto
  • 2,540
  • 1
  • 18
  • 21
  • 1
    I'm certain that the Spring annotations will work. I've never tried it with Named and Inject. It's no surprise that WebSphere doesn't support it - IBM's software is awful. – duffymo Feb 05 '13 at 13:36
  • All the CDI stuff I've seen for WebSphere starts at version 8, but I agree I can't find a definitive statement to that effect. It's definitely in the v8 documentation. https://ibm.biz/BdxmBv – dbreaux Feb 05 '13 at 15:38

3 Answers3

2

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.

Kurtcebe Eroglu
  • 1,934
  • 11
  • 15
2

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.

Filipe Fedalto
  • 2,540
  • 1
  • 18
  • 21
  • 1
    In the end, I found what happened. It turned out that the Spring libraries loaded by the classloader were not the ones deployed in my application. Oddly, WAS7 was loading Spring classes from an ActiveMQ Resource Adapter, which, not surprisingly, did not have javax.inject jars in it. That's why "Spring" was not finding javax.inject. This is really odd, because one might assume a RA would be isolated by default. While there is such a checkbox (which I henceforth marked), it's odd that this isn't the default behavior: to isolate resources' classloaders from the applications. – Filipe Fedalto Feb 07 '13 at 12:10
  • 1
    I upvoted your answer, it's the most explanatory one. You may edit your question to point it out. – Bruno Medeiros Jun 21 '13 at 18:10
  • I met similar problems where WebSphere 7 cannot found javax.inject.Named or any other JSR-299 annotations, the work around is to create a shared library that contains the classpath of javax-inject.jar and other missing jars, and then config my application make a reference to that shared lib – JerseyGood Jul 19 '15 at 09:22
-1

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.

Dreamer
  • 7,333
  • 24
  • 99
  • 179
  • Yet duffymo says in question "If I switch back from the JSR 330 @Named / @ Inject annotations to Spring's own @ Component and @ Autowired is it likely to work?". It seems to me he is not depending on Spring for annotations in this case. – Kurtcebe Eroglu Feb 05 '13 at 22:49
  • @Dreamer, yes, as we're also using a 3rd-party JAX-WS engine, our application was already configured to use the "Local class loader first (parent last)" – Filipe Fedalto Feb 06 '13 at 09:27
  • @kurtcebe, as strange as it may be, the switch-back to @Component/@Autowired did work. I did that only as an experience and to sort this issue out. – Filipe Fedalto Feb 06 '13 at 09:30
  • Eventually, I came up with a workaround following the "extend Spring's ComponentScanBeanDefinitionParser so it will detect JSR 330 annotations" line. I added a to the directive so that javax.inject.Named annotations were also considered eligible for detection. I also added a bean definition to org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor, extending the autowiredAnnotationType to javax.inject.Inject, in order to the framework process injections of such fields. – Filipe Fedalto Feb 06 '13 at 09:36
  • Hi Filipe, glad you've worked it out. About the previous comment, when you switch to @ Component/ @ Autowire you're processing annotations via Spring, so that seems to be expected as Dreamer pointed out. If you use @ Named/ @ Inject than you need container support. – Kurtcebe Eroglu Feb 06 '13 at 14:25