Hi Ken, sorry this will become a long answer, first of all:
http://people.apache.org/~werpu/testinck4040.tar.gz
is the download of the small sample project I did, you need maven to run
it you can deploy directly once you have setup the project by using
mvn gae:deploy and you can run locally by using mvn gae:run.
You also can run it into a standard jetty stack by running it via mvn
jetty:run-exploded or mvn jetty:run.
Secondly, I assume half of your problems are mapping problems, I ran
into with the auto assumption GAE does on the mapping if you dont
explicitely redirect and use an ending pattern instead of a path pattern.
Secondly to the session, I dont think my assumption is invalid in fact
it just fills a little bit of the gaps the link leave in the understanding.
I will give you a more detailed example why I recommended to use some
kind of keepalive to keep the session alive.
The session is not a classical session as app servers do it, but more
along the lines of a mem cache with a rather short timeout period, and
supportive to it some serialisation into the cloud. As it seems either
due to a bug or something else, the session bombs out after 5 minutes if
nothing is done, and that is reproducable, ignoring the timeout settings
in the web.xml. I am not sure if this is a problem of the implementation
of the session or one of the jetty version used. But I assume it is a
problem of the implementation being a cache based one.
Now what the link says is, that you should use set and getAttributes to
keep the sesssion alive. Now if you trigger a refresh directly against
the server by using an ajax call at least with server side state saving
exactly this happens by restoring the component tree from the session
object. With client side state saving you probably need to trigger a
keepalive code on the server which keeps the session fresh.
So in the end we run into two issues, first, there is some weird mapping
bug or redirection bug in GAE which can be resolved by using file ending
pattern mappings and redirects on the index.jsp, secondly
we deal with a short session time which cannot be altered, we need to
set some keepalive code which triggers the session.getAttribte and
setAttribute one way or the other very often periodically to keep the
cache in "ram - this is fluent in the cloud", third, make sure that all
which goes into the session is serialisable and also make sure that if
you have transient data in the serialisable objects, that those are
properly restored because the serialisation can happen any time.
Third you have a session limit, which from what I can gather should be
big enough to deal with jsf, but nevertheless if you run into issues,
then switch over to client side state saving.
(The golden rule client side only does not apply anymore)
I am not sure how well all those restrictions play in conjunction with
the more complex ajax component frameworks, but nevertheless, GAE is
somewhat outside of what you can expect from a classical JEE container
point of view and if you want to build a startup on top of that chain,
then give it a proper testing upfront.
Honestly spoken I could not give any recommendation blindly to go with a
JSF GAE combination, before doing so I would be testing the entire
stack at least for a few mandays to know what to expect, but even before
spending time on that, I would probably go for a more conservative
proven stack and pay the webhoster for hosting my JEE infrastructure.
After all GAE is more or less a one way street, sure you have the APIs
but as soon as you bind yourself to the data store in the cloud it will
be hard to move back, and add to that that there is a load of bugs in
the JDO and JPA connectors from what I could gather, so it probably
might be better simply to use the native cloud storage apis instead of
going for their JDO and JPA high level layers.
Werner
Am 10.12.10 05:25, schrieb ken keller:
Werner,
Thx for digging into this.
I think you're incorrect about how httpsession works. Here is an article
about gae httpsession:
http://blog.comtaste.com/2010/07/managing_session_data_in_gae_a.html
If you want a consistent behaviour you need to invoke setAttribute again
after having modified the Person object in the session.
http://code.google.com/appengine/docs/java/config/appconfig.html#Enabling_Sessions
Because App Engine stores session data in the *datastore and memcache*, all
values stored in the session must implement the java.io.Serializable
interface.
<http://blog.comtaste.com/2010/07/managing_session_data_in_gae_a.html>Thing
is I was getting the ViewExpiredException even w/ client-side state saving.
(I consider this option a great scalability advantage of jsf. wicket seems
to use httpsession.)
Here's a thoughtful article which recommends jsf2 over wicket because of the
active component libs:
http://www.theserverside.com/discussions/thread.tss?thread_id=60755
<http://www.theserverside.com/discussions/thread.tss?thread_id=60755>Any
opinions on the pros/cons of richfaces, primefaces, icefaces?
On Thu, Dec 9, 2010 at 5:01 PM, Werner Punz<[email protected]> wrote:
Ok I have to add something, another issue is, that google does not adhere
to the session-timeout values given in the web.xml.
Currently google handles the session in the app cache, and drops it after a
view minutes no matter what, not sure what you can do about that. One
strategy might be to apply some kind of keepalive to the browser which sends
a keepalive ajax request periodically to keep the cache alive. Also if
possible shift the state saving to client as recommended earlier. The
keepalive itself might work out well to keep the app alive but probably both
measures have to be added.
What I assume now is that you ran into a bunch of those issues, literally
all on the App Engine side. If you are aware of them you can work around
them if not oh well.
Werner
Am 10.12.10 01:43, schrieb Werner Punz:
Ok took me a while to get everything together, since this is my first
App Engine Project project. But I think i have all info now.
First it seems that both server and client side state handling now works
(since 1.4 that is).
Secondly, MyFaces works fine with GAE so does the MyFaces Ajax.
here is my example: http://testinck4040.appspot.com/
The MyFaces configuration also is correct, you have to add:
<!--
We need to set annotation lifecycyle provider manually as
org.apache.myfaces.config.annotation.NoInjectionAnnotationLifecycleProvider.
Other providers use some classes that are restricted on Google App Engine.
-->
<context-param>
<param-name>org.apache.myfaces.config.annotation.LifecycleProvider</param-name>
<param-value>org.apache.myfaces.config.annotation.NoInjectionAnnotationLifecycleProvider</param-value>
</context-param>
<!--
Need to set a secret to avoid javax.crypto.BadPaddingException.
"param-value" must be Base64 encoded.
More details: http://wiki.apache.org/myfaces/Secure_Your_Application
-->
<context-param>
<param-name>org.apache.myfaces.SECRET</param-name>
<param-value>NzY1NDMyMTA=</param-value>
</context-param>
To the web.xml and also have to enable sesssion handling on the gae side
as documented.
One thing I noticed however is following, if you do not redirect
properly to a real jsf page, you will get the ViewExpired exception you
were getting hence I set my welcome file to index.jsp
with a simple redirect on the jsp side so that the jsf page is properly
accessed:
<body>
<% response.sendRedirect("welcome.jsf"); %>
<body>
The funny stuff was that in the original setting GAE was picking up my
original index.xhtml file but was doing some jsf remapping for one
reason or the other (otherwise I would not have gotten the view expired
exception), but for some strange kind of reason everything went haywire
because it was not passing down the proper view but triggering jsf due
to some internal path mapping probably. Either way doing the proper jsf
ending mapping and redirection resolves that.
Either way outside of that the view id must point properly to the jsf
page I could not find any pitfall, I will give you a download link to
the full project tomorrow, so that you can try it out yourself. As you
can see in the demo ajax works fine.
Here are quick links to my web.xml files and appenging-web.xml files,
the full download will follow tomorrow.
http://www.pastie.org/1363893
http://www.pastie.org/1363894
Werner
Am 10.12.10 00:50, schrieb Werner Punz:
Ok Ken, so far I have setup my testproject and on ajax I run into the
same crypto exception you have been reporting (state saving method
server) this points towards a bug in the non ajax part somewhere, I will
keep you informed about my results.
Werner
Am 09.12.10 23:05, schrieb Werner Punz:
Ok another hint, there is a config param which has to be set to prevent
the crypto exception which you face:
see https://issues.apache.org/jira/browse/MYFACES-2606
see also http://myfaces.apache.org/core20/googleappenginesupport.html
Werner
Am 09.12.10 22:10, schrieb ken keller:
I use both of those.
I've started playing with wicket because Gavin recommends JSF or wicket
(both have component models). wicket doesn't appear to have active
component
libs like richfaces, primefaces, icefaces.
I'm surprised that richfaces adores mojarra. The lists
http://java.net/projects/javaserverfaces/lists have low activity.
Issues
http://java.net/jira/browse/JAVASERVERFACES/ seem to get resolved.
I can only dream of a framework:
* Reliable on gae.
* Several component lib developers conforming to an open look&feel std
like
nimbus.
* Client-side validation first to avoid server load& bandwidth for
silly
mistakes like not filling in a required field.
On Thu, Dec 9, 2010 at 12:21 PM, Werner Punz<[email protected]>
wrote:
Ok here is a hint which could indicate to the root of your problems,
apparently GAE has session handling disabled you have to enable it.
<sessions-enabled>true</sessions-enabled
in the appeninge-web.xml file to enable it.
Also some links indicate you should only use state saving client.
Werner
Am 09.12.10 20:42, schrieb Werner Punz:
Ok this could be an indication to the viewstate issue you are facing
http://java.dzone.com/news/jsf2-configuration-google-app
seems like GAE has its fair share of problems or the underlying
container of GAE that is.
All I can say, if it is just for learning purposes try to program
your
program locally and when it comes to deployment find a hoster which
allows you to use your own app stack. As for the ajax stuff, I will
give
GAE a try as I said, but I assume your problem is related to the
other
session scope problems GAE seems to have.
Werner
Am 09.12.10 20:38, schrieb Werner Punz:
Ok I cannot really help with the viewExpired Problem except for
that it
indicates a problem on GAEs side.
But I ran your Ajax problem quickly through and for me it works
locally
here. So I assume you run into a GAE related issue here as well.
I will do a GAE testsetup as my scarce time permits to run this
through,
but I really assume a gae related problem or a deployment related
problem here.
It would be interesting to know if in the ajax case the browser
throws
any errors. What does the browser error console say?
Werner
Am 24.10.10 20:14, schrieb ken keller:
Yesterday evening I noticed java.io.InvalidObjectException stopped
being
thrown. I don't know why but I hope it is related to switching from
eclipse
to intellij& not due to gae. (I also learned facelets is built into
jsf2 so
a separate jar isn't required.)
I have two new problems which only happen on live gae--not dev gae:
1) I'm testing jsf-basics.zip on
http://www.coreservlets.com/JSF-Tutorial/jsf2/code/.
* open bank-lookup.jsf
* fill in form
* click [Show Current Balance]
* the correct jsf page is displayed
* click chrome's Back
* javax.faces.application.ViewExpiredException is thrown (whether
using
client or server state saving):
org.apache.myfaces.shared_impl.util.StateUtils reconstruct: View
State
cannot be reconstructed
javax.faces.FacesException:
javax.faces.application.ViewExpiredException
at
org.apache.myfaces.shared_impl.util.StateUtils.decrypt(StateUtils.java:
490)
at
org.apache.myfaces.shared_impl.util.StateUtils.reconstruct(StateUtils.java:
378)
at
org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getSavedState(Ht
mlResponseStateManager.java:
213)
at
org.apache.myfaces.renderkit.html.HtmlResponseStateManager.getState(HtmlRes
ponseStateManager.java:
160)
at
org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.res
toreView
(DefaultFaceletsStateManagementStrategy.java:
140)
at
org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspState
ManagerImpl.java:
388)
at
org.apache.myfaces.shared_impl.view.ViewDeclarationLanguageBase.restoreView
(ViewDeclarationLanguageBase.java:
106)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.restoreView
(FaceletViewDeclarationLanguage.java:
1277)
....
This doesn't happen if I submit the form with errors, fix them,&
click
[Show Current Balance] button:
* open bank-lookup.jsf
* click [Show Current Balance] button
* validation errors are shown (post back)
* correct errors
* click [Show Current Balance] button
* click Back button
2) A simple use of<f:ajax> doesn't update:
<h:selectOneMenu id="menu" value="#{bankingBean.customerId}">
<f:ajax event="change" execute="@this" render="register"/>
<f:selectItems value="#{bankingBean.customerIds}"/>
</h:selectOneMenu>
<h:outputText id="register" value="#{bankingBean.customerId}"/>
On Thu, Oct 21, 2010 at 9:32 PM, ken keller<[email protected]>
wrote:
I'm a JSF2/myfaces rookie. I have it working w/ Eclipse Helios& gae
Eclipse plugin. When I deploy it& visit my test page, a blank
page is
displayed& the log entry is appended to this message. It
appears to
be a
session deserialization problem. Thx. for your help.
javax.servlet.ServletException: java.lang.RuntimeException:
java.io.InvalidObjectException: enum constant attributes does not
exist in class javax.faces.component.UIComponent$PropertyKeys
at
com.google.apphosting.runtime.jetty.AppVersionHandlerMap.handle(AppVersionHandlerMap.java:240)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
at
com.google.apphosting.runtime.jetty.RpcRequestParser.parseAvailable(RpcRequestParser.java:76)
at
org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
com.google.apphosting.runtime.jetty.JettyServletEngineAdapter.serviceRequest(JettyServletEngineAdapter.java:135)
at
com.google.apphosting.runtime.JavaRuntime.handleRequest(JavaRuntime.java:261)
at
com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:8486)
at
com.google.apphosting.base.RuntimePb$EvaluationRuntime$6.handleBlockingRequest(RuntimePb.java:8484)
at
com.google.net.rpc.impl.BlockingApplicationHandler.handleRequest(BlockingApplicationHandler.java:24)
at
com.google.net.rpc.impl.RpcUtil.runRpcInApplication(RpcUtil.java:418)
at
com.google.net.rpc.impl.Server$RpcTask.runInContext(Server.java:572)
at
com.google.tracing.TraceContext$TraceContextRunnable$1.run(TraceContext.java:448)
at
com.google.tracing.TraceContext.runInContext(TraceContext.java:688)
at
com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContextNoUnref(TraceContext.java:326)
at
com.google.tracing.TraceContext$AbstractTraceContextCallback.runInInheritedContext(TraceContext.java:318)
at
com.google.tracing.TraceContext$TraceContextRunnable.run(TraceContext.java:446)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
Caused by: java.lang.RuntimeException:
java.io.InvalidObjectException: enum constant attributes does not
exist in class javax.faces.component.UIComponent$PropertyKeys
at
com.google.apphosting.runtime.jetty.SessionManager.deserialize(SessionManager.java:413)
at
com.google.apphosting.runtime.jetty.SessionManager.createSessionFromEntity(SessionManager.java:376)
at
com.google.apphosting.runtime.jetty.SessionManager.loadSession(SessionManager.java:314)
at
com.google.apphosting.runtime.jetty.SessionManager.getSession(SessionManager.java:284)
at
org.mortbay.jetty.servlet.AbstractSessionManager.getHttpSession(AbstractSessionManager.java:237)
at
org.mortbay.jetty.servlet.SessionHandler.setRequestedId(SessionHandler.java:246)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:136)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at
com.google.apphosting.runtime.jetty.AppVersionHandlerMap.handle(AppVersionHandlerMap.java:238)
... 21 more
Caused by: java.io.InvalidObjectException: enum constant
attributes
does not exist in class
javax.faces.component.UIComponent$PropertyKeys
at java.io.ObjectInputStream.readEnum(ObjectInputStream.java:1721)
at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1343)
at
java.io.ObjectInputStream.readArray(ObjectInputStream.java:1684)
at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1340)
at
java.io.ObjectInputStream.readArray(ObjectInputStream.java:1684)
at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1340)
at
java.io.ObjectInputStream.readArray(ObjectInputStream.java:1684)
at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1340)
at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:368)
at java.util.HashMap.readObject(HashMap.java:1047)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:991)
at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1865)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1770)
at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1346)
at
java.io.ObjectInputStream.readArray(ObjectInputStream.java:1684)
at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1340)
at
java.io.ObjectInputStream.skipCustomData(ObjectInputStream.java:1928)
at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1890)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1770)
at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1346)
at
java.io.ObjectInputStream.skipCustomData(ObjectInputStream.java:1928)
at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1890)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1770)
at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1346)
at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:368)
at java.util.HashMap.readObject(HashMap.java:1047)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:991)
at
java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1865)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1770)
at
java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1346)
at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:368)
at
com.google.apphosting.runtime.jetty.SessionManager.deserialize(SessionManager.java:411)
... 30 more
Caused by: java.lang.IllegalArgumentException: No enum const class
javax.faces.component.UIComponent$PropertyKeys.attributes
at java.lang.Enum.valueOf(Enum.java:214)
at java.io.ObjectInputStream.readEnum(ObjectInputStream.java:1719)
... 69 more
