Furthermore, I'm aware of the existance of the @PostConstruct annotation,
but as you are aware, I'm limited to a non-J2EE 5 server.
Some weeks ago I tried using a PhaseListener and then through the
VariableResolver get to the beans to initialize them in the right moment.
This solution presented two problems. The first has to do with having to
know the bean names in advance. The second and most important is that the
variable resolver would instantiate beans if they did not exist, which would
then be initialized needlessly.
Probably I missed something in the PhaseListener solution?
I've also looked at some existing solutions that involve tight coupling
between the page names and the bean names. This would not be suitable for
the application I'm developing though.
Does anyone know of other solutions for this - or more proper forms of the
presented solutions?
On 6/11/07, Francisco Passos <[EMAIL PROTECTED]> wrote:
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
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>
