I would too, if I hadn't lost several days trying to get proper bean
initialization and statekeeping to work :)
As soon as I get some time for this, I'm going back to 1.2 and check it.
I'll let you know.
One of my doubts prevails though: is it possible to run JSF 1.2 safely on a
non J2EE 5 container such as weblogic 9.2? I believe it isn't, but either
way, I'd like to know from someone that, unlike me, has a greater grasp of
the implications.
On 6/8/07, Adam Winer <[EMAIL PROTECTED]> wrote:
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.2in 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
> > > > >
> > > >
> > >
> > >
> >
> >
>
>
