On Tue, Oct 21, 2008 at 6:13 PM, Leonardo Uribe <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
The problem only happens when server state saving is used. On
client side state saving everything works well.
I'll try add the params to faces-config.xml and see what happens.
Checking myfaces core 1.2.x code, class JspViewHandlerImpl there is
this code:
public void writeState(FacesContext facesContext) throws IOException
{
StateManager stateManager =
facesContext.getApplication().getStateManager();
if (stateManager.isSavingStateInClient(facesContext))
{
// Only write state marker if javascript view state is disabled
ExternalContext extContext = facesContext.getExternalContext();
if (!(JavascriptUtils.isJavascriptAllowed(extContext) &&
MyfacesConfig.getCurrentInstance(extContext).isViewStateJavascript())) {
facesContext.getResponseWriter().write(FORM_STATE_MARKER);
}
}
else
{
stateManager.writeState(facesContext, new Object[2]);
}
}
Myfaces core 1.2.x does not write any marker on server side state
saving (I suppose jsf ri does) and the inner class
JspViewHandlerImpl.StateMarkerAwareWriter (this class is responsible
to change the marker) is only used on client side state saving, but
portlet bridge always assume that some marker is written.
On Tue, Oct 21, 2008 at 5:57 PM, michael freedman
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
wrote:
The main thing to note here is that this message is always
written to the log when running this Myfaces config (for all
your browsers) and hence is non-indicative of the problem.
FYI -- we can't determine that its correct (for all cases)
that we didn't find the Token which is why we write a log message.
-Mike-
Scott O'Bryan wrote:
Hey Leo, this could be related to the state-saving issue
with MyFaces that I posted to the dev list about a month
ago. I havn't had time to fix it (or even write a JIRA
ticket) but, essentially, there are times that MyFaces
does not generate a state-saving token when maybe it
should. On the previous attempt for alpha-3, we were
generating an exception. This has changed into a stern
warning which is what you're seeing in the logs.
Are you seeing a functional issue? If so, then I suppose
I can try and tackle the MyFaces issue in my copious
amounts of free time to see if we can resolve the issue
from the MyFaces side.
Scott
Leonardo Uribe wrote:
On Tue, Oct 21, 2008 at 5:18 PM, Leonardo Uribe
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>>
wrote:
On Tue, Oct 21, 2008 at 4:50 PM, michael freedman
<[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
<mailto:[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> <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>
<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]>
<mailto:[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>
<http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>
