I have CDI RequestScoped bean and much more java class that are not beans. in any of these java classes, I want to use my bean but it can be injected (why? I do not know) one possible way is using this code :
final Hashtable jndiProperties = new Hashtable();
jndiProperties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
final Context context = new InitialContext(jndiProperties);
EntityManagment em = (EntityManagment) context.lookup("java:app/drools-guvnor/EntityManagment");
that work well if my bean is stateless and localbean. what I can do for none stateless and localbeans?
There is no JNDI-Name for CDI given.
You could either register them yourself or you create an EJB that has been injected with your object. Then you can lookup this EJB and get your injected object from there.
Related
I've 2 packages. In Package A, There is bean
#Bean(name = BEAN_NAME)
public PkgA getPkgA_Bean() {
return new JobReasonCodesFetcherImpl(componentConfiguration.component());
}
So In package B, I've dagger 2.
So how should I use this bean in package B. So that it injects PkgA through bean name ?
Can anyone please help me to understand how to fix this ?
Hello i think you are using Spring term instead of dagger
You want to use #Produce inside a module instead of #Bean
For using name in dager you can use #Named
And be careful dagger2 is using code generation instead of reflection for spring. In consequence some things can be easy to do in spring can't be done with dagger. Like classpath analysis
With spring cloud config, when I update a configuration and call refresh on any clients, is there a way that I can have a notification that this happened? If I am constructing objects based on some #ConfigurationProperties, I will want to refresh these objects with the new state of those hierarchical properties. I would rather not perform lookups each time I need to reference the config props; in my case it is best to refresh certain objects at the time of config changes. So, is there a way to hook into that refresh lifecycle?
Edit: Ideally, if I could have a #Configuration class know about the refresh event, and re-bind/re-instantiate some relevant Spring #Beans, that would be quite ideal!
Ok, so when I posted this question a month ago, I was obviously pretty new to this, and pretty naive. I have since learned that #ConfigurationProperties get updated when spring cloud config clients are refreshed. Say that you have a bean (lombok to reduce boilerplate, of course):
#Data
public class ClientSettings {
private List<String> list1 = new ArrayList<>();
private List<String> list2 = new ArrayList<>();
private List<String> list3 = new ArrayList<>();
}
And you have a #Configuration class like this:
#Configuration
public class PropsConfig {
#Bean
#RefreshScope
#ConfigurationProperties(prefix = "settings")
public ClientSettings clientSettings() {
return new ClientSettings();
}
}
If you update the config file that the spring cloud config server is serving, and then call the refresh actuator endpoint on the client, the underlying bean will be updated, and any services that have this bean wired will have an updated bean after it was refreshed.
So, bravo to Spring for implementing this magic voodoo wizardry so well! All kidding aside, the autowired bean is proxied, so it makes sense that if the bean registry is updated with new values, that the services with the injected singleton will have the updated values. That brings up the question of what would happen if the same #Configuration #Bean method added #Scope(SCOPE_PROTOTYPE). Since #RefreshScope is a specialized scope for spring cloud config, and since the annotation is not repeatable, I am not sure what would happen.
I have a stateful session bean that inject extended entity manager. When I deploy the application for some time, an exception occur indicating that extended Entity manager is not serialized. after some search I found that passivation of the bean might be the cause of this exception.
Is there a way to stop passivation in glassfish (I found that there is an issue but can't find a way)?
Is it right for container to try to serialize entity manager when passivating the sfsb?
Could there be another reason for this exception to occur?
Note: please don't ask about the code it is just a stateful bean with extended entity manager called by an application scope cdi bean.
You must set passivationCapable to false.
passivationCapable Specifies whether this stateful session bean is passivation capable
#Stateful(passivationCapable=false)
public class HelloBean {
private NonSerializableType ref = ...
. . .
}
Im trying to migrate a stateful session bean from EJB 2.1 to EJB 3.0, the home interface of the bean which extends EJBHome has a create method with two args and the corresponding bean has a matching args ejbcreate method and one more no arg ejbcreate method.
My question is-
1. do I need to create two constructors one no arg and one arg to migrate this stateful session bean?
2. The ejbcreate method code is throwing "CreateException" and a run time exception, as of now ejbcreate defines throws "CreateException", do i need to define thorws CreateException" on the constructor or can I skip the create exception throwing part in the code of the constructor.
Other alternative I see posted in one blog is creating a method and annotating with #init, though not sure if this is the way as they were talking about EJB2 client view for a EJB3 bean.
There is unfortunately no way to specify arguments while creating a stateful session bean using EJB 3, so you'll need to add an initialize(arg1, arg2) method and call it after obtaining in instance via JNDI.
Only the no-arg constructor can be used in EJB 3.
Yes, #Init is the equivalent of ejbCreate when using annotations to define the EJB 2 client view when using EJB 3 style bean definition.
I want to inject a Singleton EJB into my POJO class.
With the new EJB 3.1 spec, is it possible to inject an EJB into a POJO?
I know in EJB 3.0, the #EJB annotation could be used to inject an EJB, but this did not work on simple POJOs.
#javax.inject.Inject is also not working for me.
One more thing is, what is the difference between a container and a non-container resource?
How do I achieve it, I am using JBoss AS 7.1.1.
EE is designed around the idea of component classes (EJBs, servlets, etc.). An EE container can only perform injection when it controls the creation of the object, which does not apply for POJO, so you cannot use EE injection on POJO objects.
For CDI to work, you need to add META-INF/beans.xml to your archive. Even then, you cannot create the POJO instance using new. You always have to let the container create the instance, so either #Inject the POJO, which can then #Inject the EJB, or use javax.enterprise.inject.spi.BeanManager.
#EJB won't work for you so you have only two options - JNDI lookup or using CDI. Something like
#Inject
private MyEJB ejb;
should work for you. Also check that you have beans.xml in the WEB-INF folder in order to activate CDI container.
And for the difference - it is almost the same (while it's recommended to use #Inject) with only exception - you still have to use #EJB for injecting remote beans.
Reason why you can't use service = new ServiceClass(); is that service object will not be managed by the container - that means that no injections will be peformed after creation of this class because container is no longer in control of this object. Very naively said, if you do
#Inject
ServiceClass service;
container will create new instance, then perform injections and return it to you.