after some experimenting, I have been able to inject my GET-parameters into an #ManagedBean (thus, a JSF) bean using #ManagedProperty and some EL.
Now, except the approach from reading the parameter map from FacesContext.getCurrentInstance().getExternalContext(), I have not been able to inject my GET-parameters into an #Named (thus, a CDI-) bean.
And so, I have been reading about advantages and disadvantages of JSF beans and CDI beans.
In short, I am stuck with two questions:
1st. Will I experience any disadvantages in using JSF beans over CDI beans?
2nd. If so, is there a clean way to inject my GET-parameters into a CDI bean?
I hope that I don't start a flamewar here, but it's certainly safe to say that CDI scopes and dependency-injection mechanisms cover far more ground than JSF scopes do. Generally speaking, you are better off with CDI scopes - but one could go into almost arbitrary details here.
Concerning you problem: Seam Solder brings - among many other things - http-parameter-injection. Check this out.
Update:
Should you be afraid of integrating Solder into your project (don't be!), take a look at the relevant source-code which does the magic. You can easily copy it into your project - it's just that the developers behind Solder had a few more cornercases in their mind than you would probably come up with on the spot.
Related
There is lot of information about Stateless, Stateful and Sigleton beans everywhere but almost nothing about javax.annotation.ManagedBean. At a first look I assumed that It's be similar to Spring's #Component but I can't use it without complete information.
If I annotate a class with #javax.annotation.ManagedBean will it be singleton or it will have instance pool like stateless?
Will the methods inside such class be concurrent? I should make sure as in a singleton they are synchronized by default.
I was thinking of annotating my DAO class with this but the #javax.enterprise.context.*; scopes put me doubt. I think #Stateless will be better. Any comments?
If not on DAO or service classes, where does this annotation fit in?
This answer gives very good explanation but doesn't answer the above questions.
Neither. They are per lookup/injection instances, more like stateful.
No, there is no container-managed concurrency.
(and 4.) Do you need transaction, security, or other EJB capabilities? Then #Stateless is probably better. Otherwise, I would just use CDI since it is better than the #javax.annotation.ManagedBean annotation in nearly all ways, and it is enabled by default in EE 7, so it is clearly the forward direction for EE.
As a bit of background, the #javax.annotation.ManagedBean annotation was added late in the development of the EE 6 cycle, and it is not widely used. The managed bean spec was intended to unify the lifecycle, injection, and naming behaviors of the EJB, CDI, and JSF managed bean component models. That was useful, but in my opinion, the #javax.annotation.ManagedBean annotation was just an afterthought to allow developers to access the minimal component model functionality without the overhead/complexity (real or perceived) of the other component models (EJB necessarily has a fixed set of required services and associated overhead, CDI is better in nearly all ways but is clearly more complex, and JSF managed beans are tied to WAR). However, this "common denominator" is then a quite limited component model with just #PostConstruct, #Resource (and other EE injection), and #Interceptors. There's no security, transaction, scoping/lifecycle (as in EJB or CDI), #PreDestroy, tight integration with the web tier, etc.
I am coming at this question from many years of using spring and just starting to look at JEE7 and CDI.
In the Spring world you have to stick #Component on a bean to turn into spring bean that spring will inject with dependencies but in CDI it seems that there is no equivalent of #Component.
To me CDI seems to imply that every class in my web application will be considered a CDI bean which seems undesirable because I have lot of java classes that are not using injection and I would not want some one to just stick #Inject in those classes and have CDI do its magic.
Two questions:
How to restrict what CDI considers to be a managed bean in a jar file?
What is the benefit for CDI to consider every bean to be a managed bean?
Please see the documentation for bean-discovery-mode in beans.xml. This attribute was only made available in JEE7 and is not available in JEE6.
I've seen quite a bit of discussion on the injection of EJBs into ViewScoped JSF-managed beans. It seems acceptable practice to do so.
I'm attempting to change one of the beans in my application from RequestScoped to ViewScoped to add some additional needed functionality.
I've modified the EJB classes to ensure that everything is serializable. When my JSF bean is created, the EJBs are initially accessible. However, when a user action fires a method in the bean that tries to invoke an EJB method, a NullPointerException is thrown.
As soon as I switch the bean from ViewScoped back to RequestScoped, everything works fine.
Could this be a fault in the implementation of JSF being used? This application is using MyFaces 2.1.12 and runs on Websphere 7.0.
Thanks.
CDI as a framework on its own doesn't know anything about Views. Thus injecting in a #ViewScoped bean won't work.
This is one of the major disadvantages of using JSF and CDI together. But you are not the first one to encounter this problem.
If you are stuck with JSF 2.1 Implementations, frameworks like Apache CODI or Seam 3 will extend your CDI in a way so you can also #Inject in #ViewScoped beans.
If you are able to upgrade to JSF 2.2 (which I would recommended you to do), this CDI extension will be a native part of the JSF implementation and you are able to use both together without further ado. See this explanation.
I've done some research on this, but still only have a vague understanding of it at best. Can anyone who is knowledgable on this give me a simple (or as simple as possible) description that someone with a basic understanding of programming could understand? Thanks for any help.
Spring was built on top of the idea of dependency injection and inversion of control. In normal words - instead of having a bunch of classes creating each other and passing each other from one place to another you have a bag of beans. Each bean declares its dependencies (what services do I need to work?) and Spring container resolves this requirements by automatically and automagically wiring everything together.
You have a Service that says (through XML, annotations, constructor signature...) I need DAO interface to work! and Spring is kind enough to find some bean that implements that interface, create it first and pass where it is required.
On that foundation multiple other services were provided (mostly in terms of data access and AOP), but the injection is the core concept.
If you want a quick and simple explanation then I can tell you that the heart of the Spring framework is the Inversion of control (IoC).
Naturally is reductive talk about Spring in 3 lines, but understand the IoC and you understand Spring. Everything is build around it in Spring.
We are starting a new project based on EJB 3.0. I have a "spring" based background (and love it), so for me loose coupling and testability is a big must have. This post should not be about "ejb vs. spring". It would be perfect if you already have real project experience with this.
here is some example code to demonstrate the problem:
client -> ejb -> collaborator 1 -> collaborator .. -> collaborator n
<!-- language: java -->
#Stateless
public class SampleService {
// or #Inject via CDI
// or #Autowired via Spring
#EJB // or just use a stateless session bean via EJB 3.0
private Bank bank;
// same for this component
#EJB
private Calculator calc;
// both collaborators must be settable from outside, to make everything testable (and mockable)
/**
* sample "business service" called from client
*/
public void debit(BigDecimal amount){
calc.calculate(amount.subtract(new BigDecimal(100)));
bank.debit(amount);
}
}
// or via #Component (Spring), or CDI?
#Stateless // or Stateless Session bean with optional #Service/#Singleton annotation?
public class Calculator {
public void calculate(BigDecimal subtract) {
// calculate stuff....
}
}
// or via #Component (Spring), or CDI?
#Stateless // or Stateless Session bean with optional #Service/#Singleton annotation?
public class Bank {
public void debit(BigDecimal amount) {
// ...
}
}
i want to know what is the best way to implement dependency injection for all the collaborators and their collaborators in ejb 3.0? collaborators in this sense can be very very small dedicated classes.
we have discussed the the following options so far and like always don't have a proper conclusion yet :)
only use the ejb standard with everything beeing a stateless session bean and all consequences (like pooling, resource handling etc.)
use stateless session beans as "business components" (entry points) and from there on
a) spring wired dependencies (via "jboss snowdrop" integration)
b) CDI wired dependencies (via WELD for ejb 3.0 and jboss eap 5.1)
i don't need to know how i can use the beans in a unit test. the answer i am after is what is the best approach to wire up all the dependencies inside the running appserver (spring vs. guice vs. CDI vs. EJB). i only need to know the graph from the outer EJB ("business entry point") downwards. so everything outside (servlets, frontend etc.) is not scope of this question :)
please, assume EJB 3.0 and jboss eap 5.1 are set for the project :)
looking forward to your answers and hopefully some project based knowledge.
If you need method level transaction management, security, concurrency management or any other services that a session bean can offer then make them EJB session beans. You can start out with managed beans and then make them session beans as and when you need to.
If you want to inject these session beans into managed beans (which in CDI is anything in a jar file that contains a beans.xml file in the meta-inf directory) then use #EJB. If you want to inject a plain managed bean into a session bean use #Inject.
If you want to inject remote session beans (or any Java EE remote resource) then this link explains how you can do this via an adapter class. Essentially it keeps all of your nasty strings for lookups etc in one place and allows you then to treat these remote resources just like any other injectable bean (via the #Produces annotation on the adapter member variables). You don't have to do this but it is recommended.
Typesafe resource injection
I would definitely vote against mixing frameworks.
I'm working on a project that is hooked on EJB, Spring and JBoss Seam (and also has half-Flex, half-JSF front-end). A true technology zoo!
Anyway, wiring it all together is not the worst part, those frameworks have flexible injection capabilities. Testing is also more or less bearable.
The most painful was to get rid of memory leaks caused by different lifecylce models, synchronize transaction, and clean up threading behavior.
Now we're moving to pure Java EE 6 (getting rid of Spring, Flex and shifting from Seam to CDI). So far we're really pleased with the results.
BTW, I'm not criticizing Spring. Stick with either Java EE or Spring stack, mixing them is just asking for trouble.
Well in general in Java there are "too many choices," so certainly in this area as well. I would not describe EJB as a general purpose Dependency Injection framework, rather they use DI for their purposes. If that is how you want to code, you should look to add a framework for this purpose. If you know and like Spring, go for it. I have used Guice with EJB's (here is a nice cookbook) to good effect as well, if you needed yet another framework to figure out how to do this.
If your main goal is to allow dependency injection for testing I would recommend just letting those values be settable via changing them to protected or giving them setters. I'm a fan of using Mockito to stub everything in Java EE EJB 3.0 and when doing any testing outside of integration testing to just allow Mockito to stub the methods for me, but if you are looking for full dependency injection like the capability to have several different beans based off of the same class, but with different dependencies I would recommend as Yishai said and going with Spring on top.