You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-user@incubator.apache.org by Laurie Harper <la...@holoweb.net> on 2006/08/23 06:09:21 UTC
Possible bug in tr:table sorting
I just tracked down the cause of an exception raised during sorting
of a tr:table component in my application, and it seems to be a
Trinidad bug. Here's the problem markup:
<tr:column noWrap="true">
<tr:panelGroupLayout><!-- FIXME: why do we need this
here? -->
<tr:commandLink action="edit" text="edit"
rendered="${not empty row.id}"/>
 
<tr:commandLink action="edit" text="delete"
rendered="${not empty row.id}"/>
 
<tr:commandLink action="edit" text="split"
rendered="${not empty row.id}"/>
</tr:panelGroupLayout>
</tr:column>
The tr:panelGroupLayout is there because otherwise each link is
wrapped in a <div> element (even if I set separateRows="false"; is
that correct??); the   (non-breakig space) entities are there
because otherwise the links run into each other -- that may be a
function of Facelets' stripping of element-only whitespace.
When I sort any column in the table, I get a nasty IndexOutOfBounds
exception. It turns out to be the non-breaking space entities; if I
change those to
<tr:outputText value=" "/>
the exception goes away. Since (I think) Facelets turns template text
into UIText components, I'm not sure why the raw character entity is
a problem? Here's the root stack trace, in case it helps at all ;-)
java.lang.IndexOutOfBoundsException: Index: 4, Size: 4
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at
org.apache.myfaces.trinidad.component.UIXCollection.restoreStampState
(UIXCollection.java:820)
at
org.apache.myfaces.trinidad.component.UIXTable.restoreStampState
(UIXTable.java:320)
at
org.apache.myfaces.trinidad.component.StampState.restoreChildStampState(
StampState.java:152)
at
org.apache.myfaces.trinidad.component.UIXTable.restoreStampState
(UIXTable.java:317)
at
org.apache.myfaces.trinidad.component.UIXCollection._restoreStampState
(UIXCollection.java:1094)
at
org.apache.myfaces.trinidad.component.UIXCollection.postRowDataChange
(UIXCollection.java:712)
at
org.apache.myfaces.trinidad.component.UIXCollection.setRowIndex
(UIXCollection.java:405)
at
org.apache.myfaces.trinidad.component.UIXTable._processStamps
(UIXTable.java:391)
at
org.apache.myfaces.trinidad.component.UIXTable.processFacetsAndChildren(
UIXTable.java:265)
at
org.apache.myfaces.trinidad.component.UIXCollection.decodeChildrenImpl
(UIXCollection.java:155)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren
(UIXComponentBase.java:874)
at
org.apache.myfaces.trinidad.component.UIXCollection.processDecodes
(UIXCollection.java:149)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImp
l(UIXComponentBase.java:890)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren
(UIXComponentBase.java:874)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes
(UIXComponentBase.java:725)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImp
l(UIXComponentBase.java:890)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren
(UIXComponentBase.java:874)
at
org.apache.myfaces.trinidad.component.UIXForm.processDecodes
(UIXForm.java:60)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImp
l(UIXComponentBase.java:890)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren
(UIXComponentBase.java:874)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes
(UIXComponentBase.java:725)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImp
l(UIXComponentBase.java:890)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren
(UIXComponentBase.java:874)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes
(UIXComponentBase.java:725)
at javax.faces.component.UIComponentBase.processDecodes
(UIComponentBase.java:397)
at javax.faces.component.UIViewRoot.processDecodes
(UIViewRoot.java:131)
at
org.apache.myfaces.lifecycle.LifecycleImpl.applyRequestValues
(LifecycleImpl.java:200)
at org.apache.myfaces.lifecycle.LifecycleImpl.execute
(LifecycleImpl.java:71)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:
106)
at org.mortbay.jetty.servlet.ServletHolder.handle
(ServletHolder.java:442)
at org.mortbay.jetty.servlet.ServletHandler
$CachedChain.doFilter(ServletHandler.java:1051)
at
com.foo.projility.web.auth.UserAuthenticationFilter.doFilter
(UserAuthenticationFilter.java:80)
at org.mortbay.jetty.servlet.ServletHandler
$CachedChain.doFilter(ServletHandler.java:1042)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFil
terInternal(OpenSessionInViewFilter.java:174)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter
(OncePerRequestFilter.java:76)
at org.mortbay.jetty.servlet.ServletHandler
$CachedChain.doFilter(ServletHandler.java:1042)
at org.apache.shale.faces.ShaleApplicationFilter.doFilter
(ShaleApplicationFilter.java:271)
at org.mortbay.jetty.servlet.ServletHandler
$CachedChain.doFilter(ServletHandler.java:1042)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoF
ilter(TrinidadFilterImpl.java:327)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterI
mpl(TrinidadFilterImpl.java:291)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter
(TrinidadFilterImpl.java:214)
at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter
(TrinidadFilter.java:90)
at org.mortbay.jetty.servlet.ServletHandler
$CachedChain.doFilter(ServletHandler.java:1042)
at org.mortbay.jetty.servlet.ServletHandler.handle
(ServletHandler.java:355)
at org.mortbay.jetty.servlet.SessionHandler.handle
(SessionHandler.java:226)
at org.mortbay.jetty.handler.ContextHandler.handle
(ContextHandler.java:615)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle
(ContextHandlerCollection.java:150)
at org.mortbay.jetty.handler.HandlerCollection.handle
(HandlerCollection.java:123)
at org.mortbay.jetty.handler.HandlerWrapper.handle
(HandlerWrapper.java:141)
at org.mortbay.jetty.Server.handle(Server.java:272)
at org.mortbay.jetty.HttpConnection.handlerRequest
(HttpConnection.java:396)
at org.mortbay.jetty.HttpConnection$RequestHandler.content
(HttpConnection.java:666)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:613)
at org.mortbay.jetty.HttpParser.parseAvailable
(HttpParser.java:198)
at org.mortbay.jetty.HttpConnection.handle
(HttpConnection.java:311)
at org.mortbay.jetty.nio.HttpChannelEndPoint.run
(HttpChannelEndPoint.java:270)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run
(BoundedThreadPool.java:475)
--
Laurie Harper
Open Source advocate, Java geek: http://www.holoweb.net/laurie
Founder, Zotech Software: http://www.zotechsoftware.com/
Re: Trinidad session handling & replication, configuration issues
Posted by Adam Winer <aw...@gmail.com>.
Frank,
If you're using Trinidad with a recent-ish (1.1 line) Facelets, you might
try looking at adding the following experimental parameter to web.xml:
<context-param>
<param-name>facelets.BUILD_BEFORE_RESTORE</param-name>
<param-value>true</param-value>
</context-param>
I'm not really sure what explains the 300K vs. 30K difference,
as MyFaces and Trinidad are basically saving the same raw
information. It could be a difference in the number of views
saved (I think Trinidad defaults to 10, don't know what MyFaces
is doing), or behavior where MyFaces is pre-serializing (by default),
while Trinidad isn't, etc. (If it were an issue of pre-serializing
vs. not, then it wouldn't matter for actual replication!)
BTW, if you're interested in the *why* of session state being
so darn large, I wrote a blog entry that touched on this:
http://sfjsf.blogspot.com/2006/01/should-jsf-go-stateless.html
... and some about the BUILD_BEFORE_RESTORE option:
http://sfjsf.blogspot.com/2006/03/how-were-going-to-fix-jsf-state-saving.html
http://sfjsf.blogspot.com/2006/03/fixing-jsf-state-saving-progress.html
http://sfjsf.blogspot.com/2006/03/fixing-jsf-state-saving-save-vs.html
I need to get back to blogging...
-- Adam
On 8/23/06, Frank Felix Debatin <ff...@gmx.net> wrote:
>
> We're in process of trying different setups to determine a
> good production environment that shall include session
> REPLICATION. We use load tests (based on JMeter) to check
> the setup.
>
> We currenty use Trinidad & Facelets. Faces implementations
> we tried are RI 1.1, RI 1.2, MyFaces 1.1.x. For Trinidad
> we're using a version from before the renaming activities
> started.
>
> Now we got lost in the jungle of faces implementations and
> session/view handling. I also admit that although we got a
> very large app running, we don't understand the JSF/Trinidad
> session/view handling completely (and we don't want too
> unless we must).
>
> Here is my basic question:
> *** What is the best combination of faces implementation
> and session state configuration for a production environment
> with session replication? We're looking for a "reasonable"
> size of the serialized session.
>
> All hints/observations/recommendations/explanations are
> welcome!!!
>
> Some notes we made see below.
>
> Hoping for feedback
> Frank Felix
>
>
>
> 1) VALID COMBINATIONS
>
> For Trinidad, we use the default settings (token
> mechanism?).
>
> We found:
> * JSF RI 1.1, 1.2: work only with state saving set to client
>
>
> * MyFaces: there was Adam's recent comment
> >>>
> When you use Trinidad with MyFaces, because of how things
> are set up, the only options are MyFaces server-side and
> Trinidad client-side. Trinidad doesn't provide a
> server-side version, and overrides the client-side version
> entirely (RI or MyFaces).
> <<<
> We (without any reasoning) always had JSF state-setting set
> to "client" in development, with MyFaces 1.1.0. Worked fine.
>
>
> Now, we have MyFaces 1.1.3 with "server", and have several
> problems (date popup windows don't work, back-button issues,
> and so on). Probably due to 1.1.3 problems, I read that this
> release is not considered to be a "good one".
>
> 2) SESSION SERIALIZATION IN REPLICATION
>
> We are concerned about the size of the session after
> serialization. When state saving is set to "client",
> Trinidad (rather old version) writes a token cache with
> ~300K to the session. With server side state saving, Myfaces
> 1.1.0 writes nothing, Myfaces 1.1.3 a serialized view
> collection (~30K).
>
> Now 300K is too much, and still 30K sounds a lot to us.
> Session failover is a very exceptional case, and it wouldn't
> be a serious issue if - in the failover case - the user
> experience "falls below the usual level". I can't imagine
> that there are 30K-300K of really critical data.
>
>
>
>
>
>
>
Trinidad session handling & replication, configuration issues
Posted by Frank Felix Debatin <ff...@gmx.net>.
We're in process of trying different setups to determine a
good production environment that shall include session
REPLICATION. We use load tests (based on JMeter) to check
the setup.
We currenty use Trinidad & Facelets. Faces implementations
we tried are RI 1.1, RI 1.2, MyFaces 1.1.x. For Trinidad
we're using a version from before the renaming activities
started.
Now we got lost in the jungle of faces implementations and
session/view handling. I also admit that although we got a
very large app running, we don't understand the JSF/Trinidad
session/view handling completely (and we don't want too
unless we must).
Here is my basic question:
*** What is the best combination of faces implementation
and session state configuration for a production environment
with session replication? We're looking for a "reasonable"
size of the serialized session.
All hints/observations/recommendations/explanations are
welcome!!!
Some notes we made see below.
Hoping for feedback
Frank Felix
1) VALID COMBINATIONS
For Trinidad, we use the default settings (token
mechanism?).
We found:
* JSF RI 1.1, 1.2: work only with state saving set to client
* MyFaces: there was Adam's recent comment
>>>
When you use Trinidad with MyFaces, because of how things
are set up, the only options are MyFaces server-side and
Trinidad client-side. Trinidad doesn't provide a
server-side version, and overrides the client-side version
entirely (RI or MyFaces).
<<<
We (without any reasoning) always had JSF state-setting set
to "client" in development, with MyFaces 1.1.0. Worked fine.
Now, we have MyFaces 1.1.3 with "server", and have several
problems (date popup windows don't work, back-button issues,
and so on). Probably due to 1.1.3 problems, I read that this
release is not considered to be a "good one".
2) SESSION SERIALIZATION IN REPLICATION
We are concerned about the size of the session after
serialization. When state saving is set to "client",
Trinidad (rather old version) writes a token cache with
~300K to the session. With server side state saving, Myfaces
1.1.0 writes nothing, Myfaces 1.1.3 a serialized view
collection (~30K).
Now 300K is too much, and still 30K sounds a lot to us.
Session failover is a very exceptional case, and it wouldn't
be a serious issue if - in the failover case - the user
experience "falls below the usual level". I can't imagine
that there are 30K-300K of really critical data.