That's great news for me, I'm using facelets.
Back on topic, I've just tried switching back to JSF1.2 and it seems there's
good reason for you to be skeptic Adam.
It still doesn't work. Which is a major bore, since a couple of weeks back I
had a working version. Guess I'll have to go back to work on that area.
So this is what I want to do.
a) be able to initialize beans (retrieving data from database) - right now,
I'm calling initialization from a managed-property setter (I know, it's kind
of ugly)
b) be able to keep the retrieved data using only request-scoped beans - i'm
fond of Tomahawk's saveState component - and thus avoiding to hit the
database if the data's already here
The problem seems to be that the managed property setter is called BEFORE
the bean is restored by t:saveState. Otherwise the initialization logic
would detect the bean was already initialized and would not hit the
database.
So I'm looking for a way to ensure that the previous bean state is restored
before the managed-property setter is called.
Or if that is not possible, I'm looking for a way to satisfy a) and b) -
initializing a bean when it is not initialized, keeping it in request and
avoid reinitialization.
On 6/8/07, Adam Winer <[EMAIL PROTECTED]> wrote:
On 6/8/07, Francisco Passos <[EMAIL PROTECTED]> wrote:
> 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.
With Facelets, yes, with JSP, no.
-- Adam
>
>
> 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.1for
> 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
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
>
>
