My application has a CMT session bean invoking a BMP entity bean that uses JDBC queries to perform Database operations.the ejb-jar.xml have resource ref defined at both the session bean definition and the entity bean definition at ejb-jar.xml. is it not sufficient to place the resource references only on session beans rather that having it defined on both session and entity beans ?
The resource-refs in the ejb-jar.xml are only visible within the EJB definition that contains them.
If an EJB is not performing a JNDI lookup of a resource then it will not need the resource-ref.
Related
In a container environment (such as wildfly, jboss), are servlets treated as Managed bean? i.e. Can I inject the Servlet into any other CDI bean?
I use CdiRunner CDI-Unit to write my tests. And therefore I would like to inject Servlet into my Test class and test its (public) methods.
The lifecycle of a servlet if managed by the servlet container and not by CDI. However, CDI injection is expected to work in servlets.
A servlet container will also provide some built-in beans that can be injected using CDI:
A servlet container must provide the following built-in beans, all of
which have qualifier #Default:
a bean with bean type javax.servlet.http.HttpServletRequest, allowing
injection of a reference to the HttpServletRequest
a bean with bean type javax.servlet.http.HttpSession, allowing
injection of a reference to the HttpSession
a bean with bean type javax.servlet.ServletContext, allowing injection
of a reference to the ServletContext
If you need to inject a servlet somewhere, you are probably doing something wrong.
Questions about ejb session bean behavior when used as injected bean instances.
I'm not 100% sure how this works. I guess it from practice and from reading documents on the subject.
I want to know how #EJB annotation is processed by container in detail.
Session bean have interfaces, impl class, deployment descriptor. We package them in ejb jar.
What is putted in global JNDI by container? Static references to
business interfaces ?
How and when global JNDI is read from ?
When component JNDI ENC is populated with ejb reference ?
Is this reference in JNDI ENC (java:comp/env/beanB) is reference to
session bean component interface, session bean instance proxy or
session bean instance ? Is there difference for SLSB and SFSB ?
With #EJB annotation on field does every new ejb session bean
instance get new instance of injected ejb in the annotated field or
all ejb instances share the same injected ejb session bean instance
?
Does ejb injection by lookup (on session context) provide always new
injected ejb instance, example: calling ctx.lookup(ejbReference) in
loop ?
In EJB 3.0, the JNDI names are vendor-specific (if available at all; in theory, a container could support EJB references only), but vendors typically return an EJB reference/proxy. In EJB 3.1, the specification requires the EJB container to make specific java:global, java:app, and java:module names available, and the object returned from these lookups must be an EJB reference/proxy.
The global JNDI is accessed when you perform a JNDI lookup. The container might access the global JNDI names in other cases (e.g., when resolving #EJB(lookup="java:app/...")).
It's undefined when the container populates java:, but the contents must be available before lifecycle callback or business methods are invoked on the component instance.
#EJB/<ejb-ref>/<ejb-local-ref> ensure lookups always return an EJB reference/proxy and never an actual bean instance. The proxy ensures that all container services are performed (security, transaction, remoting, etc.) before invoking an actual bean instance. For SLSB, an arbitrary bean instance will be invoked, and the same or different actual instance might be invoked depending on the thread, concurrency, timing, vendor-specific configuration, etc. For SFSB, a bean instance with a specific identity will be invoked; you are likely to get the same bean instance, but you might not if the EJB container has passivated the actual bean instance, but reactivation should result in an instance with equivalent state. For singleton session bean in EJB 3.1, you are guaranteed the singleton bean instance will be invoked.
It's undefined whether you get the same proxy instance. For SLSB and singleton beans, injection or lookup could return a single proxy that delegates to the actual bean instance as mentioned above. For SFSB, the proxy is basically required to be a separate instance per injection or lookup since the proxy must store some state with the identity so it can invoke the specific actual bean instance.
It's undefined what the container does, but injection is typically implemented by containers using Context.lookup followed by Field.set (or Method.invoke for setter method injection). Regardless, the instance handling is as described above.
I have Stateless Entity Beans(EJB 3.x) and EJB Beans(EJB 2.x) and other classes in my project. I want to inject Entity Bean into EJB Beans. So, far I am able to inject it using JNDI way i.e (BeanName#completename) but I want to inject it using #EJB just like we inject entity beans in another entity beans without any JNDI lookup. Both of these beans are part of different modules but deployed on same server. I am using weblogic with eclipselink.
Entity beans are never injects in EJB beans. You can perform your DB operation on entity beans by using EntityManager. To work with database operation entities must be associated with EntityManager persistence context. so you can not work with your entities until it is not in persistence state.
All the transaction-scoped persistence context are configured by injecting #PersistentContext to EntityManager objects , like this,
#PersistenceContext(name="PersistentUnitName")
private EntityManager entityManager;
Are you using EJB 3 or EJB 2? EclipseLink does not support EJB 2 EntityBean, only EJB 3 Entities.
You cannot inject an Entity bean, it does not make sense, they must be queried from the database through an EntityManager. You can inject an EntityManager using #PersistenceContext.
See,
http://en.wikibooks.org/wiki/Java_Persistence/Runtime#Java_Enterprise_Edition
I was wondering... Let's say that I have two stateless beans in ejb 3.1:
#Stateless
Class1
#EJB MyUniqueInstanceBean uniqueBean1;
2.
#Stateless
Class2
#EJB MyUniqueInstanceBean uniqueBean2;
Are uniqueBean1 and uniqueBean2 guaranteed to be unique instances of MyUniqueInstanceBean?
If MyUniqueInstanceBean is Stateless it is not in your hands are calls to uniquebean1 and uniquebean2 actually calls to same instance. In EJB 3.1 specification this is told with following words:
Because all instances of a stateless session bean are equivalent,
the container can choose to delegate a client-invoked method to any
available instance. This means, for example, that the container may
delegate the requests from the same client within the same transaction
to different instances, and that the container may interleave requests
from multiple transactions to the same instance.
If MyUniqueInstanceBean is Stateful, it is guaranteed that uniquebean1 and uniquebean2 do not refer to same instance. Again from specification:
A session bean instance’s life starts when a client obtains a
reference to a stateful session bean instance through dependency
injection or JNDI lookup, or when the client invokes a create method on the session bean’s home interface. This causes
the container to invoke newInstance on the session bean class to
create a new session bean instance.
If you are using Singleton, then both refer to same instance, because there is only one instance:
A Singleton session bean is a session bean component that is
instantiated once per application. In cases where the container is
distributed over many virtual machines, each application will have one
bean instance of the Singleton for each JVM.
i integrate a flex app in a jsf-icefaces app (in a jspx site with the ice:outputmedia-tag) and want to access the same instance of a bean from flex by remote, that jsf inject.
i already connect with blazeds to a java-bean. this bean - like all other beans - get other beans by injection of jsf, but when i access the bean by remote from flex it doesnt hold the injected beans (like localizer and accesmanager, both session scoped) and i can't connect to the jsf session (FacesContext.getCurrentInstance() is null). this is because flex create a new instance of the bean and it’s not the same current instance, that jsf inject, i think.
i can connect from flex to the database by create a new entity manager in the java bean, but that's not what i want, because it's again another entity manager...i want persist and get data over the accessmanager-bean.
i know exadel fiji and flamingo, but i couldn't work with fiji, because my jsf app include the icefaces components and then it doesn't work with richfaces which fiji needs. and flamingo work only with jboss seam and spring. is it right?
i also read about the spring-flex-integration, but the jsf application did not create with spring and i don't want to integrate spring in such a large jsf app.
yesterday i read about the FlexFactory interface. this interface i have to implement in my own Factory and set it in the service-config.xml of blazeds as a factory read this. i still implement my own factory but i only get application scoped beans over the servlet context which i get over FlexContext.getServletContext().getAttribute("Bean"); and not session scoped beans...
i hope there is a chance to connect throw flex and jsf...
thanks!
FacesContext.getCurrentInstance() is null
This will only happen when the current request is not been passed through the FacesServlet. In other words, the request URL did not match the url-pattern of the FacesServlet. It's namely the one responsible for creating the threadlocal FacesContext instance.
But you actually don't need the FacesContext here. As JSF just runs on the top of the Servlet API, you can also go low level and make use of it to grab the session scoped managed bean. JSF stores session scoped managed beans as attribues of the HttpSession with the managed bean name as key.
Thus, if you for example have a session scoped managed bean with the managed bean name myBean and you have the HttpServletRequest at your hands, then you can also access it as follows:
MyBean myBean = (MyBean) request.getSession().getAttribute("myBean");