Is there any way to initialize Named Bean annotaded by javax.inject.Named/javax.enterprise.context.ApplicationScoped like #ManagedBean(eager=true) from javax.faces package?
#Named
#ApplicationScoped
public Mail() { ... }
I want to load this class when application starts, not when webapplication refers to this bean.
ps. JSF 2.1
Bean Injected by Glassfish 3.1
You can create a CDI extension that has the #Observes AfterBeanDiscovery parameter on one of his methods. There you can instantiate the bean and thus initialize it when the container starts up.
CODI has made those things easier for you, see https://cwiki.apache.org/confluence/display/EXTCDI/Core+Usage#CoreUsage-Startup
Related
Given the EJB below, will the container be intelligent enough to only create the object that is used?
#Stateless
public class MyBean {
#EJB
Clazz1 obj1;
#EJB
Clazz2 obj2;
public void run(int x) {
if (x == 1)
obj1.printCode();
else
obj2.printCode();
}
}
The container will have to resolve all dependencies of the bean (instantiate them first) before instantiating the bean itself.
Now what truly happens when you invoke a method might differ...
You are using purely EJB here, there isn't any speck of CDI in your code!
#EJB is an EJB annotation for dependency injection and #Stateless is an EJB annotation for a "scope".
If you were to use CDI and had Weld as its implementation (all EE servers apart from tomee) then you would get lazy instantiation for any normal scoped beans. That would mean that you in fact inject an "empty" proxy object and it will only be instantiated upon first access.
Now, what I mean by CDI injection - use #Inject instead of #EJB.
You can still have your bean #Stateless, CDI, if it's running in your app, then wraps it with it's own scope.
I also said that you need normal scoped beans - that means beans which use proxies.
Those are pretty much all CDI scopes except #Dependent. Therefore it's #RequestScoped, #SessionScoped, #ApplicationScoped. The dependencies of your bean would have to have those scopes to achieve lazy init.
I made a simple xhtml page for upload file by using <h:inputFile> component. And everything works fine. And in managed bean I used dependency injection for the Logger. I used a factory class and createLogger() method in, to enable injection for object of Logger class.
Everything is ok but, nothing works without a #Model annotation in managed bean.
Can somebody explain the meaning of the #Model annotation.
I can not find on internet proper explanation. A founded explanation of other annotation like as #Session, #Request, #Application etc.
What does the #Model annotation do?
Hej vmaric,
#Model == #RequestScoped + #Named
It exposes the Backing Bean directly to your JSF 2 or JSP and its context will be destroyed after the end of the servlet request.
So it should not be used for entities.
Here is a hint from the Weld Reference Guide:
Notice the controller bean is request-scoped and named. Since this combination is so common in web applications, there's a built-in annotation for it in CDI that we could have used as a shorthand. When the (stereotype) annotation #Model is declared on a class, it creates a request-scoped and named bean.
I want to inject an EJB3 into a java class which is not an EJB.
these classes are both on the same server and application.
Is that possible ...and if yes ..then how ?
Thanks,
Perhaps you should supply more information about your work environment. The usage of CDI changes the whole specturm. You can inject it when you use CDI, otherwise you can only inject it into other EJB's and servlets (if your application server supports it).
Otherwise you can do a lookup using
Context ctx = new InitialContext();
MyEjb ejb = (MyEjb) ctx.lookup("java:comp/env/myEjb");
You can supply a name in the #EJB annotation you supply together with your #Stateless/#Stateful annotation.
#Stateless
#EJB(name="myEjb", beanInterface=MyEjb.class)
public class myEjbImpl implements MyEjb{
// code goes here
}
You can't inject it, but you can make a lookup for that EJB:
Look here:
http://www.roseindia.net/ejb/ejb-lookup.shtml
During the deploymentprocess of your EJB you may see, the Name of your Bean.
If I create an EJB3 bean (say a stateless session bean) in an application using Spring 2.5 for DI, how should I inject dependencies from Spring into the bean without coupling the bean to Spring?
I don't know if you consider applying an interceptor as coupling but that's to my knowledge the standard approach. From the Chapter 18. Enterprise Java Beans (EJB) integration of the documentation:
18.3.2. EJB 3 injection interceptor
For EJB 3 Session Beans and
Message-Driven Beans, Spring provides
a convenient interceptor that resolves
Spring 2.5's #Autowired annotation
in the EJB component class:
org.springframework.ejb.interceptor.SpringBeanAutowiringInterceptor.
This interceptor can be applied
through an
#Interceptors
annotation in the EJB component class,
or through an interceptor-binding XML
element in the EJB deployment
descriptor.
#Stateless
#Interceptors(SpringBeanAutowiringInterceptor.class)
public class MyFacadeEJB implements MyFacadeLocal {
// automatically injected with a matching Spring bean
#Autowired
private MyComponent myComp;
// for business method, delegate to POJO service impl.
public String myFacadeMethod(...) {
return myComp.myMethod(...);
}
...
}
SpringBeanAutowiringInterceptor by
default obtains target beans from a
ContextSingletonBeanFactoryLocator,
with the context defined in a bean
definition file named
beanRefContext.xml. By default, a
single context definition is expected,
which is obtained by type rather than
by name. However, if you need to
choose between multiple context
definitions, a specific locator key is
required. The locator key (i.e. the
name of the context definition in
beanRefContext.xml) can be
explicitly specified either through
overriding the
getBeanFactoryLocatorKey method in a
custom
SpringBeanAutowiringInterceptor
subclass.
The only other option I'm aware of (extending the EJB 2.x support classes) is much worse from a coupling point of view (and thus doesn't answer your question).
See also
Default Injecting Spring bean to EJB3 SLSB without #Autowired Annotation
I've got a NullPointerException using EJB3 in a J2SE environment (without EJB3 container)
Briefly, I've got a stateless bean implementing an interface.
When I call it in another class like in a main, a NullPointerException is triggered.
Sample:
#stateless
#Local(IMyInterface.class)
public class myBean implements IMyInterface{...}
public class Main{
#EJB
IMyInterface myInterface;
public static void main(String[] args){
Result result = myInterface.myBeanMethod(); // Exception happens here
}
}
I guess I miss some initialization stuff because the EJB is null when I first try to use it...
Thanks for your help,
EJBs can't work without a container. The dependencies (#EJB) are injected if the beans are instantiated by the container. If you are the one instantiating them, it is your responsibility to set the dependencies.
Furthermore, you are trying to use a non-static variable from a a static method - this won't even compile.
While you can use JPA (which is part of EJB 3) "Entity Beans" (actually, POJOs) in a J2SE environment, you can't use Session Beans without a container and you can't benefit from injection of resources using the #Resource or the more specialized #EJB and #WebServiceRef annotations in a non-managed environment, i.e. a container. In other words, only managed components support injection (Servlets, JSF Managed beans, EJB components, etc).
So, in your case, you'll need to:
Deploy your Session Bean in a Java EE container (like JBoss, GlassFish, WebLogic, etc)
Lookup the remote EJB using explicitly its global JNDI name. The code will look like that:
Foo foo = (Foo) new InitialContext().lookup("FooEJB");
A few additional remarks:
With EJB 3.0, the global JNDI name is container dependent so I can't tell you what it will be exactly (EJB 3.1 finally introduced "portable global JNDI names").
You'll need to set up the JNDI environment (which is container dependent) for the lookup either by providing a jndi.properties on the class path or by using the InitialContext(Hashtable) constructor.
You'll need to provide the application server "client library" on the class path of the client (which is obviously specific to each product).
Search for previous questions or open a new one if you need more specific guidance.