This certainly explains why it doesn't work now.
I've no idea why it worked in JSF 1.2 - I'm a bit
skeptical of that, to be honest.
-- Adam
On 6/8/07, Francisco Passos <[EMAIL PROTECTED]> wrote:
Placed this before calling isPostBack:
try {
throw new Exception("------when am i calling isPostback?------");
} catch(Exception e) {
e.printStackTrace();
}
Here's the result:
java.lang.Exception: ------when am i calling isPostback?------
at
pt.dgaiec.stp.beans.GenericBean.adfIsPostback(GenericBean.java:59)
at
pt.dgaiec.stp.beans.GenericBean.isPostback(GenericBean.java
:40)
at
pt.dgaiec.stp.beans.GenericBean.setInitialization(GenericBean.java:110)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.commons.beanutils.PropertyUtils.setSimpleProperty
(PropertyUtils.java:1789)
at
com.sun.faces.config.ManagedBeanFactory.setPropertiesIntoBean(ManagedBeanFactory.java:564)
at
com.sun.faces.config.ManagedBeanFactory.newInstance(ManagedBeanFactory.java:234)
at
com.sun.faces.application.ApplicationAssociate.createAndMaybeStoreManagedBeans(ApplicationAssociate.java:253)
at
com.sun.faces.el.VariableResolverImpl.resolveVariable(VariableResolverImpl.java:78)
at
org.apache.myfaces.trinidadinternal.el.TrinidadVariableResolver.resolveVariable(TrinidadVariableResolver.java:54)
at
com.sun.facelets.el.LegacyELContext$LegacyELResolver.getType(LegacyELContext.java
:107)
at
com.sun.el.parser.AstIdentifier.setValue(AstIdentifier.java:96)
at
com.sun.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:255)
at com.sun.facelets.el.TagValueExpression.setValue
(TagValueExpression.java:93)
at
com.sun.facelets.el.LegacyValueBinding.setValue(LegacyValueBinding.java:68)
at
org.apache.myfaces.custom.savestate.UISaveState.restoreState(UISaveState.java:101)
at
javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:999)
at
org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:96)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState
(UIXComponentBase.java:816)
at
javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1011)
at
org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:96)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:816)
at
org.apache.myfaces.trinidad.component.TreeState.restoreState(TreeState.java:96)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState(UIXComponentBase.java:816)
at
javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1011)
at
org.apache.myfaces.trinidadinternal.application.StateManagerImpl.restoreView
(StateManagerImpl.java:486)
at
com.sun.faces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:246)
at
com.sun.facelets.FaceletViewHandler.restoreView(FaceletViewHandler.java:317)
at
org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:265)
at
com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:157)
at com.sun.faces.lifecycle.LifecycleImpl.phase
(LifecycleImpl.java:200)
at
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:90)
at
javax.faces.webapp.FacesServlet.service(FacesServlet.java:197)
at
weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run
(StubSecurityHelper.java:225)
at
weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:127)
at
weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:283)
at
weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter
(ExtensionsFilter.java:147)
at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
at
pt.dgaiec.stp.filters.TimeoutFilter.doFilter(TimeoutFilter.java:53)
at
weblogic.servlet.internal.FilterChainImpl.doFilter
(FilterChainImpl.java:42)
at
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3212)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java
:321)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at
weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:1983)
at
weblogic.servlet.internal.WebAppServletContext.execute
(WebAppServletContext.java:1890)
at
weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1344)
at
weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
at weblogic.work.ExecuteThread.run (ExecuteThread.java:181)
Does this help?
Anyway, it worked with JSF1.2. Can I use JSF 1.2 safely in a container that
doesn't support JSP 2.1 - weblogic 9.2? Is there any way (context params,
etc.) to tell JSF that it is in such a container? Or is there a way I can
program safely around unsupported calls?
On 6/5/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> I'd suggest seeing a stacktrace to find out what phase this is
> being invoked in. RequestContext.isPostback() doesn't work
> until the end of Restore View phase, and I suspect your
> code is being called during Restore View.
>
> -- Adam
>
>
>
>
> On 6/4/07, Francisco Passos < [EMAIL PROTECTED]> wrote:
> > Actually yes, I was using JSF 1.2 but since my application server
(Weblogic 9.2) doesn't support J2EE 5, I decided to switch to 1.1 for full
compatibility.
> >
> > The full scenario is this: I have request-scoped beans that need to be
initialized (load properties from database). I'm using t:saveState to keep
the values between subsequent requests.
> >
> > In order for my init method to be called for these beans, I created an
abstract bean (which my concrete beans extend) with the following:
> >
> >
> > protected boolean initialized = false;
> >
> > public abstract void init() throws Exception;
> >
> > public final void setInitialization(String value) {
> > if (!isPostback()) {
> > initialize();
> > }
> > }
> >
> > public final void initialize() {
> > if (!initialized) {
> > try {
> > init();
> > initialized = true;
> > } catch (Exception e) {
> > ...
> > }
> > }
> > }
> >
> > protected final boolean isPostback() {
> > RequestContext context =
RequestContext.getCurrentInstance();
> > if (context == null) {
> > return false;
> > }
> > return context.isPostback();
> > }
> >
> > The entry point is the setInitialization method. To ensure it gets
called, I created a managed-property in each of my beans (in
faces-config.xml).
> >
> > I don't know which phase it gets called in, but a while ago it worked
extremely well and in conjunction with Tomahawk's saveState, for subsequent
requests only the first would be initialized, whereas now, all of them are
:(
> >
> > Should I switch back to 1.2? Is there anything I can do to use 1.2 in a
non-J2EE compliant app-server with any degree of confidence?
> >
> > Thank you,
> > Francisco
> >
> >
> >
> > On 6/1/07, Adam Winer <[EMAIL PROTECTED]> wrote:
> > > I don't think there've been any changes in Trinidad. Have
> > > you changed the version of JSF you're using? At
> > > what point in the JSF lifecycle are you calling
> > > isPostback()?
> > >
> > > -- Adam
> > >
> > >
> > > On 6/1/07, Francisco Passos < [EMAIL PROTECTED]> wrote:
> > > > Good afternoon.
> > > >
> > > > Have there been any changes to the underlying mechanism of
> > > > RequestContext.isPostback since version 1.0.0-incubating?
> > > >
> > > > I've noticed that returning null after executing an action triggered
by a
> > > > button, for instance, is no longer considered a postback. Is this
true and
> > > > if true, is it intended?
> > > >
> > > > By the way, having a <tr:commandButton text="simulate postback" />
is no
> > > > longer detected as one :S and it doesn't even define the action...
> > > >
> > > > Thank you,
> > > > Francisco
> > > >
> > >
> >
> >
>
>
