im using Hazelcast HttpSession Clustering with two Glassfish 3.1.2.2 instance. Im using #EJB or #Inject annotation to inject EJB(s) in managed beans. In #ViewScoped and #SessionScoped managed beans, im getting
com.hazelcast.nio.HazelcastSerializationException:
java.io.NotSerializableException:
com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate Exception.
When i marked the #EJB field with transient keyword, hence, i didnt get SerializationException. But, after deserialization, my ejbs didnt re-inject and then, im getting a NullPointerException.
How can i handle this problem? (Note: Hazel vers: 2.4)
Have you tried making your EJB classes implement Serializable?
Besides your EJB classes, make sure all objects nested in them are Serializable as well.
There's a VM option to add details to the exception. It will show the root and nested classes failing to serialize and help you figure out what you're missing:
-Dsun.io.serialization.extendedDebugInfo=true
You might also want to check that you define serialVersionUID for every Serializable class includding superclasses (if they're Serializable)
Note: your code may run without serialVersionUID sometimes but read the last paragraph in Serializable's javadoc to understand why it will be a problem depending on the environment.
Related
I'm wondering if changing the EL resolver so a bean can use public fields in jsf could cause issues with the proxies? [That's why it isn't a duplicate.] Aall managed bean fields have to be private in the framework, because that's how the EL resolver does things. However it's a bit cumbersome and looks useless most of the time.
#Named
#RequestScoped
public class myBean{
public int age;
}
So would it cause issue with proxies trying to intercept things or whatnot?
This guy in this question apparently changed the el resolver so it's doable
Unfortunately yes, it will mess with CDI.
Why? Because public field access is impossible when bean is proxied. With Weld during startup you will get a definition error:
WELD-000075: Normal scoped managed bean implementation class has a public field ...
It's going to work fine only for non-proxied scopes (#Singleton and #Dependant).
I agree it's a bit cumbersome and looks useless sometimes, so you have two solutions:
Use IDE to generate them automatically.
Use lombok project.
But none of them is perfect.
I am using SpringFramework for web server.
Sometimes I need to do asynchronous task to implement certain function.
Usually, I prefer to use
#Inject #Component(which is implements Runnable) in #Service.
But I am not sure is it OK or not.
So I got a question just like the title.
'#Inject thread bean in #Service'
OR
'#Inject service bean in #Component'
I want to know which way is more frequently uses.
Thanks in advance:D
Have a good Day!
EDIT:
Based on edited question and commentary the answer has been changed.
#Component is generic
#Service is specific
#Inject is replaced by #Autowired
You always want to use #Autowired #Service instead of other combinations.
For architectural differences you will only get information from the API documents themselves.
for further detail check this out:
What's the difference between #Component, #Repository & #Service annotations in Spring?
I have two beans. First bean languageOfSystem:
#Named(value = "languageOfSystem")
#SessionScoped
public class LanguageOfSystem implements Serializable {
#Inject private JsfUtils eeJsfUtils;
and the second bean, userBb:
#Named(value = "userBb")
#SessionScoped
public class UserBb implements Serializable, LangUpdInterface {
#EJB
private EjbUtils ejbUtils;
#EJB
private PuserFacade puserFacade;
#Inject
private Direction direction;
#Inject
private PortfelDao portfelDao;
#Inject
private LanguageOfSystem languageOfSystem;
I inject languageOfSystem into userBb, and NetBeans IDE gives me warning in line with that injection:
no enabled eligible for injection beans are found
But I'm able to call methods from languageOfSystem in userBb and it works fine. So is this warning important and should I change smth?
And the second question. I use in this case observer design pattern, where userBb is dependent and languageOfSystem is the subject which has a list of dependents. I register userBb in subject list by calling appropriate method from languageOfSystem. Is it right when it comes to the two session beans?
But I'm able to call methods from languageOfSystem in userBb and it
works fine.
Your code does not look wrong - and it works. So this seems to be a Netbeans issues.
And the second question. I use in this case observer design pattern,
where userBb is dependent and languageOfSystem is the subject which
has a list of dependents. I register userBb in subject list by calling
appropriate method from languageOfSystem. Is it right when it comes to
the two session beans?
Are you aware that the CDI spec includes a powerful and typesafe implementation of the observer pattern? You definitely should check this out.
And two more things to mention here:
#Named(value = "languageOfSystem")
#Named(value = "userBb")
The value you are providing is already default. So you can leave it
out and simply write #Named instead.
Regarding the code you are posting: #Named is not required at all -
all it does is providing an EL name for use in JSF. Your code will
work just as good if you skip #Named altogether...
As to your first question:
This is a known netbeans bug (see here and here). However, the discussion in the first link indicates that it is rather an issue of the weld implementation and Netbeans' warning is according to the specification.
Nevertheless the bugzilla file says it will be fixed in Netbeans v7.2.
Until then you can still disable the warning (Tools --> Options --> Editor --> Hints)
I hesitate to ask yet another question on the same topic, but at least now I'm reading, I think, the right docs.
So, this class:
class FacesContextProducer {
#Produces #RequestScoped FacesContext getFacesContext() {
return FacesContext.getCurrentInstance();
}
}
From the weld docs this method does, in fact, apply to Glassfish through: GlassFish is using WELD as the reference implementation for JSR-299: Java Contexts and Dependency Injection for the Java EE platform (CDI).
For the above class, where would it be used? Why do you need a separate class which #Produces a FacesContext?
For the above class, where would it be used? Why is he trying to inject FacesContext?
I think it is done either for
consistency; or
testing.
ad 1. If one tries to do pure CDI, it looks nice when you're not using other dependency lookup mechanisms (as getCurrentInstace() static method). Note that it is really not needed to define a producer and use injection. It is just convenient and consistent with usage of CDI.
ad 2. is explained by blog McDowell links to, just imagine the injection is done with CDI.
Why do you need a separate class which #Produces a FacesContext?
This does not need to be a separate class, you can have single class producing multiple beans. It just helps the clarity of the code to have it separate.
You might want to inject the FacesContext to avoid direct reliance on the static getCurrentInstance() method to make mocking and unit testing simpler.
I've written a bit about that for JSF's own dependency injection mechanisms here.
I've first seen annotating Seam entity classes here
http://www.developer.com/java/ejb/article.php/10931_3715171_5/Introducing-JBossreg-Seam.htm
and for whatever reason I've been doing so ever since:
#Entity
#Table (name= "GADGET")
#Name("gadget")
public class GadgetBean implements Serializable {
private String mDescription = "";
private String mType = "";
...
}
However, I do not use "entity components" like this anywhere in my views. Can anyone explain the use of this and what this gains? Is it a non-practice?
If you are not using any of these entity components in your views, you should remove the #Name annotation.
Seam is great, but seam components come with overhead in the way of interceptors firing every time you access a method in that class. Since you are not accessing these attributes in your view, there is no need to make them into seam components. You are incurring the interceptor overhead every time you use a getter or setter from your entity beans.
Seam-gen, the tool used to create seam projects, can also generate entities that are reverse-engineered from your database tables. By default, the seam-gen entity generator does NOT add the #Name annotation to these classes. That should tell you something!
Hope this helps.