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.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
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
