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 = ...
. . .
}
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 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.
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'm running a CDI based application on JBoss AS 7.1.1 which uses Conversation Scoped Beans.
I need to invoke one of these beans from a RESTeasy Service. Unfortunately when I invoke the Conversation Scoped Bean
#Inject
private ConversationBean service;
#GET
#Produces("text/html")
#Path("/book")
public void bookTicket(Long l) {
service.book(l);
. . . .
}
the following error is returned:
Caused by: org.jboss.weld.context.ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.ConversationScoped
Is there any workaround for this issue ?
Thanks!
I know I've answered this question before (or maybe it was #SessionScoped, same thing really). The Conversation is tied to a Session in CDI. As there are no Sessions in JAX-RS there are no conversations. In the spec section 6.7.4 it states that the Conversation scope is only active during JSF requests.
If you would like to create your own Scope and Context that acts like the conversation one and make it available to JAX-RS requests, that's certainly doable, but you'd have to have some location to store the scope and also associate it with a request.
Im a new SEAM developer and for sure im really enjoying the platform.
im wondering wether a stateless session bean plus conversation scope has the same semantic by stateful session bean ?
the EJB Client in this context is the seam, right ? so using conversation scope, the ejb bean used by the client ( seam component ) will be the same during the conversation, this way the state will be preserved until the conversation finish.
is it correct ?
No. Stateless session beans always live in the stateless context.
I think Stateless session bean is always in Stateless scope, no way to set to Conversation scope.