-
1. Re: Simple Backing Bean Question
asookazian Aug 12, 2009 5:22 PM (in response to mgbowman)I'm pretty sure that you don't need @BypassInterceptors, that is a performance optimization tactic which turns off bijection, for example.
The default scope for JavaBean is EVENT and for entity class is CONVERSATION.
How are you injecting the EntityManager?
It seems to me that even with the default settings, this should work w/o @BypassInterceptors.
So you're saying that the insert is committing to the db and you see a new record but the setter values are null?
What are the values for the relevant properties in the entity class prior to persist() call?
-
2. Re: Simple Backing Bean Question
mgbowman Aug 13, 2009 12:12 PM (in response to mgbowman)If I log the properties - i.e. log.info("applicant.firstName='{0}'", applicant.getFirstName()); - the values are those submitted via the form.
However, running JBoss in debug mode and putting a breakpoint on the #{applicationSubmitAction.submit} action, I can see the injected applicant instance has been proxied / intercepted for some reason - it's not just a POJO.
In Eclipse, it's class type is listed as Applicant_$$_javassist_seam_5 which is a sure sign the original class was
instrumented
using javassist. Inspecting the instance, the firstName and lastName properties are set to null and it has an additional property handler which points to an instance of org.jboss.seam.intercept.JavaBeanInterceptor. The interceptor has a bean property which appears to be the instance from the form (because it's firstName and lastName properties are the values from the form). It's beanClass property is the Class instance of my Applicant class.Why is javassist coming into play on a simple form submission? The only thing I can think of is it has something to do with my configuration and the fact I'm using ICEfaces instead of RichFaces.
Thanks in advance,
--mgbowman
-
3. Re: Simple Backing Bean Question
jguglielmin Aug 13, 2009 3:46 PM (in response to mgbowman)Just a note that partialSubmit defaults to false, so if you don't want it, just leave it out. (then things act like regular jsf). When you bypass the interceptors, that just means that any injection on the methods and attributes of a class (basically annotations from Seam like In, Out, DataModel, etc) are not available to you. It really doesn't have much to do with the jsf lifecycle. Last poster is correct, since you are setting the entity values within your manager class (with an instance of your entity there), you will only have it available there in the scope of your manager class. Also, it's nice to debug with ICEfaces by having partialSubmit to true on your input components and don't bother with a submit button. You can then see immediately what the input from that component does within the app with a blur (tab out, enter,..) on that component.