When you say the state isn't restored when you click a button or link
can you be more specific? there are two views -- the first view asks
you to enter your name. Is the problem on navigating from this page?
I.e. the second view doesn't say "hello <name>". Or is there a problem
when you hit return in the 2nd view to return to the first view? I.e.
the name isn't displayed in the first view ? If the later: note that
this is the correct behavior. When you navigate back to the first view
it should show an empty field. The "exlcude-attribute" problem I
referenced in my other e-mail concerns what happens if you hit refresh
in the 2nd view. Without the excluded-attributes you are returned to
the first view (and the name is preserved) -- with the
exlcuded-attributes the 2nd view is refreshed with the name preserved.
-Mike-
Leonardo Uribe wrote:
On Tue, Oct 21, 2008 at 5:18 PM, Leonardo Uribe <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
On Tue, Oct 21, 2008 at 4:50 PM, michael freedman
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
wrote:
What do you mean by the "demo app stops running"? Does it run
at all? If so how far do you get before you run into the
problem? The error message you are seeing is written into the
log, right? If so, all this is telling you is that Myfaces is
running in a configuration where it writes the state directly
into the rendition versus using the cache/replace model of the
SAVESTATE_FIELD_MARKER. FYI ... I also am using Firefox
2.0.0.17 <http://2.0.0.17> and the demo is running fine for
me. So please send me more info on reproducing.
I just run the demo like this:
mvn clean -PjettyConfig jetty:run (according to the pom myfaces
core 1.2.2 is used)
and then try the demo several times. Sometimes works but others do
not and the message is on the log. I'm just run the demo as is,
without any modification. I don't know if there is some special
configuration to make it work correctly with myfaces core. If this
is true, it could be good to use profiles to define several
web.xml files for configure and test it.
One last note: stops running means when you click a button or link the
state is not restored and the request is readed as it was new.
As for running with the RI there are potentially two issues:
first the command is now:
mvn clean -PjettyConfig -Djsf=ri-provided jetty:run
Ok, thanks, it works and does not have the problem with firefox.
The other problem is you need to make sure its not trying to
run with the prior MyFaces TLD -- generally the clean should
do this, though.
-Mike-
Leonardo Uribe wrote:
I tried to run the demo module and on firefox 2.0.0.17
<http://2.0.0.17> sometimes I have this (the demo app stops
running):
2008-10-21 15:51:40.318:/portlet-bridge-demo:INFO: History
for mode: view : /he
lloworld/index.jsp?javax.portlet.faces.PortletMode=view&__jpfbReqScopeId=portlet
-bridge-demo%3Ayd3exguy3te2%3Aview%3A24d73b2a%3A11d21270f21%3A-7fd3&javax.faces.
ViewState=qpZU311sohuneMJrlpRjNB4K2cfv0ubhRgzMYD5Kf4V1pkzHlFXyeKdNfb5408dPXMeN1u
tp3qg5cWArexFYziMyJAzgTwOQ8GFyqxDCz8Y%3D
2008-10-21 15:51:40.318:/portlet-bridge-demo:INFO: Unable to
locate a SAVESTATE
_FIELD_MARKER in response. This could be because your Faces
environment doesn't
write such a marker or because the bridge doesn't know the
marker in use. If t
he later, configure the appropriate application init
parameter javax.portlet.fac
es.SAVESTATE_FIELD_MARKER.
In opera 9 and IE 7 everything works fine.
Also when I tried to run
mvn clean -PjettyConfig -Djsf=ri jetty:run
throws this error:
2008-10-21 15:52:51.809::WARN: failed portlet-bridge-demo
java.lang.NoClassDefFoundError: javax/faces/FacesException
at java.lang.ClassLoader.defineClass1(Native Method)
at
java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:12
4)
at
java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at
java.net.URLClassLoader.access$000(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native
Method)
at
java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at
org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoade
r.java:366)
at
org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoade
r.java:337)
maybe this is not blocking but it could be good to have a
fast way to test it.
On Tue, Oct 21, 2008 at 12:28 PM, Scott O'Bryan
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
+1
Scott O'Bryan wrote:
Sorry, I forgot the word [VOTE] in the subject.
Scott O'Bryan wrote:
Hi,
I'm trying to release the MyFaces Portlet Bridge
Master 1.0.0-alpha-3. This release was created
in order to support the latest JSR-301 Public
Review so that it may be tested by developers
during the review process. This is still an
alpha release because there is currently no
testing of the R.I.
I was running the needed tasks to get the
1.0.0-alpha-3 release of the Apache MyFaces
Portlet Bridge out. The artifacts are deployed to
my private Apache account ([1]).
Please take a look at the
"portlet-bridge-master-pom-1" artifacts and vote
------------------------------------------------
[ ] +1 for community members who have reviewed
the bits
[ ] +0
[ ] -1 for fatal flaws that should cause these
bits not to be released,
and why..............
------------------------------------------------
Thanks,
Scott
[1]
http://people.apache.org/~sobryan/portlet-bridge/1.0.0-alpha-3
<http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>
<http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>