Develop Reference

ejb - Details requried on javax.annotation.ManagedBean

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.

How to limit what CDI considers to be managed beans?

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.

Injecting parameters into Beans, CDI bean VS JSF bean

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.

Emulating jsf 2.0 view scope in JSF 1.2 with Spring beans

I'm working on a project using JSF 1.2 deploying a portlet to WebSphere Portal Server 6.1 on top of WAS 7. For various contractual/political reasons, we're stuck with JSF 1.2.
However. we are using Spring beans throughout our application in order to get AoP logging.
It is somewhat annoying that we can't use JSF 2.0. In particular, view scope would be ideal for our app. It will be a high usage site and keeping all the page beans in session scope is wasteful and I'm sure will cause raised eyebrows from our non-functional testing team later on.
It occurred to me that I could emulate View Scope by using Spring's custom scope and a custom JSF component that simply maintains a map of active beans set by the Spring scope and attaching this component on our pages. Together with a custom variable resolver that can find beans in this map, we should be able to emulate view scope
(Our journey is only four pages, but each page has a few postbacks to the same page)
How does this approach sound? I want to be sure I'm not somehow shooting myself in the foot before I present this to my project colleagues and dash off and start ripping apart the bean code we've already written.

Not sure about Spring, but for JSF 1.2 managed beans, the Tomahawk's <t:saveState> was the way to let a JSF 1.2 request scoped bean behave (almost) exactly like JSF 2.0 view scoped bean. Almost, because the destroying of the view and the state saving is a bit more efficient in JSF 2.x. But the effect is ultimately the same.
All you need to do is referencing the bean by that tag elsewhere in the view:
<t:saveState value="#{bean}" />

Understanding managed beans/backing beans [duplicate]

This question already has answers here:
Difference between managed bean and backing bean
(11 answers)
Closed 7 years ago.
I am learning Java EE 6 and I am trying to grasp the overall image of it. I am reading about JSF and how adding components. I am setting/reading values from the components to a bean which has the #ManagedBean annotation.
I have some trouble understanding it properly. What is Managedbeans? Is it just just objects that holds the state of the components? And they can have other methods as well? Where does the EJBs fit in? Does the managed beans invoked methods on the EJBs?

What is Managedbeans? Is it just just objects that holds the state of
the components?
A JSF Managed bean is like any other Java bean except that if it managed by JSF. In other words it is a bean that is created and destroyed by JSF as needed.
Hortsman Core JSF 2 book states.
The JSF implementation does the following:
Creates and discards beans as needed (hence the term “managed
beans”)
Reads bean properties when displaying a web page
Sets bean properties when a form is posted
And they can have other methods as well?
Yes they can have as many methods as you may want.However you would (and should) ideally like to have your managed bean as lean as possible.For example it might have a search method but you should not be doing actually search inside this method but this search methods sole purpose should be to delegate the task to the business layer (which may or may not be EJB based) . I other words no heavy lifting .
Where does the EJBs fit in?
EJB is your Business tier , they have big biceps and do all the heavy lifting. Since EJB3 JPA was introduced and that is also part of EJB. JPA however is the persistence tier. All EJBs except for JPA run in inside an EJB container. All Java EE complaint server provide these .
In a typical 3 tier architecture (these days however it is mostly more than 3 but 3 tiered is easier to explain. JSF is your Web tier , EJBs are your business tier and JPA which is also part of EJB specification but does not need EJB container is your ORM or Persistence tier.
Do not worry about word container too much you will get used to it quickly and rarely you will have to worry about it. If you are using a Java EE server it's all setup for you.
Does the managed beans invoked methods on the EJBs?
Yes as explained above already . All the heavy lifting here. However it is not mandatory to use EJB with JSF. You could use any other framework e.g Spring or could even write simple pojos but thats an other area of discussion.

From this link JSF - Managed Beans
Managed Bean :
Managed Bean is a regular Java Bean class registered with JSF. In other words, Managed Beans is a java bean managed by JSF framework.
From this link Creating and Using a Backing Bean for a Web Page
Backing Bean :
In JSF, backing beans are JavaBeans used mainly to provide UI logic and to manage data between the web tier and the business tier of the application (similar to a data transfer object). Typically you have one backing bean per JSF page. The backing bean contains the logic and properties for the UI components used on the page.
NB:
For a backing bean to be available when the application starts, you
register it as a managed bean with a name and scope