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.
Related
I am creating a cache with a CacheStoreFactory implementation and a CacheStoreSessionListener. If I set the CacheConfiguration with these fields and then call createCache but in an INSTANCE method I get this exception:
Exception in thread "main" javax.cache.CacheException: class
org.apache.ignite.IgniteCheckedException: Failed to validate cache
configuration (make sure all objects in cache configuration are
serializable): LongCache
In a static method, this does not occur. This can be easily reproduced by modifying the CacheJdbcStoreExample.java in examples. This is happening under Ignite 1.30
Most likely you declared the factory or the listener as an anonymous class. Anonymous classes always contain reference to the parent class (LongCache in your case). So if the factory is serialized in the context of LongCache instance, this instance is also serialized. In case of static method this instance doesn't exist, therefore everything works.
I would recommend to convert anonymous classes to private static classes. This will give you more control on what is serialized.
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 = ...
. . .
}
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.
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.
I'm using JBoss 7.1.1 and I have to pass an argument between two session beans.
Is it possible to pass arguments by reference from a local stateful session bean to a local stateless one?
Thanks!
That's how it works between local client and local client view. It is not only possible, but it is the way how it's specified to work. I do not try to rephrase in details, because this is quite nicely written in EJB 3.1 specification:
Session beans may have local clients. A local client is a client that
is collocated in the same JVM with the session bean that provides the
local client view and which may be tightly coupled to the bean. A
local client of a session bean may be another enterprise bean or a web
component.
...
The arguments and results of the methods of the local client view are
passed “by reference”[1]. Enterprise beans that provide a local client
view should therefore be coded to assume that the state of any Java
object that is passed as an argument or result is potentially shared
by caller and callee.
[1] More literally, references are passed by value in the JVM: an
argument variable of primitive type holds a value of that primitive
type; an argument variable of a reference type hold a reference to the
object.