On Tue, Oct 21, 2008 at 7:40 PM, Leonardo Uribe
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
On Tue, Oct 21, 2008 at 6:52 PM, Scott O'Bryan
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Leonardo,
Right. This was the problem discovered last release.
The behavior your seeing is actually expected (it
was CHANGED to do what it does because it USED to
throw an exception). What Mike discovered was that,
although there is really no need to tokenize
server-side and JS state saving, we were not actually
gaining anything by NOT tokenizing it (there are no
performance increases because of the current code
path). And in order for the bridge to automatically
determine the token being used, it needs to be present.
The way I see it, we have two choices. We can try to
work off of the implementation name of the
distribution on MyFaces (which would make the
implementation name part of the contract) OR we can
modify MyFaces to always write the token.
Alternatively, I believe if you set the token in the
init parameters of the portlet (as specified in
JSR-301) then that will also get rid of the log
entry. We were trying to let the R.I. autodetect
between the R.I. and MyFaces.
As for the excludes, if that works then we should
probably commit these changes to the alpha-3 branch
and I can regenrate.
I have made more tests about this problem. It seems the
problem is not related to write the state marker or not.
The actual code if the marker is not found it just write
it directly the response.
I have one machine with firefox 3.0.3, and the problem is
not present. The machine with firefox 2.0.0.17
<http://2.0.0.17> has the problem.
A correct request (firefox 3.0.3, opera 9 or IE 7) output
on the log (stdout) something like this:
2008-10-21 19:25:47.666:/portlet-bridge-demo:INFO:
PortletExternalContextImpl.g
etViewId: found jsf target viewId =
view:/helloworld/index.jsp
2008-10-21 19:25:47.681:/portlet-bridge-demo:INFO:
dumpScopeId: ACTION_PHASE
2008-10-21 19:25:47.681:/portlet-bridge-demo:INFO:
Elements in scope: portlet-b
ridge-demo:19hv18thfnrd9:view:-25ecdd41:11d21e77bb0:-7fdb
2008-10-21 19:25:47.681:/portlet-bridge-demo:INFO:
org.apache.myfaces.port
let.faces.includeInScope.requestParameters
2008-10-21 19:25:47.681:/portlet-bridge-demo:INFO:
org.apache.myfaces.port
let.faces.includeInScope.facesViewRoot
2008-10-21 19:25:47.681:/portlet-bridge-demo:INFO:
org.apache.myfaces.el.u
nified.resolver.managedbean.beansUnderConstruction
2008-10-21 19:25:47.713:/portlet-bridge-demo:INFO:
org.apache.myfaces.appl
ication.jsp.JspStateManagerImpl.RESTORED_SERIALIZED_VIEW
2008-10-21 19:25:47.713:/portlet-bridge-demo:INFO:
org.apache.myfaces.appl
ication.DefaultViewHandlerSupport.CACHED_SERVLET_MAPPING
2008-10-21 19:25:47.713:/portlet-bridge-demo:INFO:
jsf_sequence
2008-10-21 19:25:47.713:/portlet-bridge-demo:INFO:
namebean
2008-10-21 19:25:47.713:/portlet-bridge-demo:INFO:
org.apache.myfaces.shar
ed_impl.renderkit.RendererUtils.RenderKitImpl
2008-10-21 19:25:47.713:/portlet-bridge-demo:INFO: end
dumpScopeId
Oct 21, 2008 7:25:47 PM
org.apache.pluto.driver.PortalDriverFilter doFilter
INFO: Forwarding to realPath: /pluto/index.jsp
2008-10-21 19:25:47.744:/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.
2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:
dumpScopeId: RENDER_PHASE
2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:
Elements in scope: portlet-b
ridge-demo:19hv18thfnrd9:view:-25ecdd41:11d21e77bb0:-7fdb
2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:
org.apache.myfaces.port
let.faces.includeInScope.requestParameters
2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:
org.apache.myfaces.el.u
nified.resolver.managedbean.beansUnderConstruction
2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:
org.apache.myfaces.appl
ication.jsp.JspStateManagerImpl.RESTORED_SERIALIZED_VIEW
2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:
org.apache.myfaces.appl
ication.DefaultViewHandlerSupport.CACHED_SERVLET_MAPPING
2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:
jsf_sequence
2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:
namebean
2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO:
org.apache.myfaces.shar
ed_impl.renderkit.RendererUtils.RenderKitImpl
2008-10-21 19:25:48.760:/portlet-bridge-demo:INFO: end
dumpScopeId
A request using firefox 2.0.0.17 <http://2.0.0.17> looks
like this:
2008-10-21 19:26:46.822:/portlet-bridge-demo:INFO:
PortletExternalContextImpl.g
etViewId: found jsf target viewId =
view:/helloworld/index.jsp
2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:
dumpScopeId: ACTION_PHASE
2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:
Elements in scope: portlet-b
ridge-demo:yh4tse3ctjqw:view:-25ecdd41:11d21e77bb0:-7fda
2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:
org.apache.myfaces.port
let.faces.includeInScope.requestParameters
2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:
org.apache.myfaces.port
let.faces.includeInScope.facesViewRoot
2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:
org.apache.myfaces.el.u
nified.resolver.managedbean.beansUnderConstruction
2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:
org.apache.myfaces.appl
ication.jsp.JspStateManagerImpl.RESTORED_SERIALIZED_VIEW
2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:
org.apache.myfaces.appl
ication.DefaultViewHandlerSupport.CACHED_SERVLET_MAPPING
2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:
jsf_sequence
2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:
namebean
2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO:
org.apache.myfaces.shar
ed_impl.renderkit.RendererUtils.RenderKitImpl
2008-10-21 19:26:46.837:/portlet-bridge-demo:INFO: end
dumpScopeId
Oct 21, 2008 7:26:46 PM
org.apache.pluto.driver.PortalDriverFilter doFilter
INFO: Forwarding to realPath: /pluto/index.jsp
2008-10-21 19:26:46.869:/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.
2008-10-21 19:26:46.869:/portlet-bridge-demo:INFO:
dumpScopeId: RENDER_PHASE
2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:
Elements in scope: portlet-b
ridge-demo:yh4tse3ctjqw:view:-25ecdd41:11d21e77bb0:-7fda
2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:
org.apache.myfaces.port
let.faces.includeInScope.requestParameters
2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:
org.apache.myfaces.el.u
nified.resolver.managedbean.beansUnderConstruction
2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:
org.apache.myfaces.appl
ication.jsp.JspStateManagerImpl.RESTORED_SERIALIZED_VIEW
2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:
org.apache.myfaces.appl
ication.DefaultViewHandlerSupport.CACHED_SERVLET_MAPPING
2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:
jsf_sequence
2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:
namebean
2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO:
org.apache.myfaces.shar
ed_impl.renderkit.RendererUtils.RenderKitImpl
2008-10-21 19:26:46.884:/portlet-bridge-demo:INFO: end
dumpScopeId
Oct 21, 2008 7:26:48 PM
org.apache.pluto.driver.PortalDriverFilter doFilter
INFO: Forwarding to realPath: /pluto/index.jsp
2008-10-21 19:26:48.163:/portlet-bridge-demo:INFO:
PortletExternalContextImpl.g
etViewId: found jsf target viewId =
view:/helloworld/hello.jsp
2008-10-21 19:26:48.163:/portlet-bridge-demo:INFO:
History for mode: view : /he
lloworld/hello.jsp?javax.portlet.faces.PortletMode=view&__jpfbReqScopeId=portlet
-bridge-demo%3Ayh4tse3ctjqw%3Aview%3A-25ecdd41%3A11d21e77bb0%3A-7fda&javax.faces
.ViewState=CX8k%2BpTXi4XRIwnlHJaWVyc31c23xqtKQKd4yZOqnb9H8Xs6FKjAxuC58ztDpvj1O2O
1%2B8C%2F2gMMzdqOlEnLOB4LrckaiKM%2Bu3h3WzFSRkY%3D
2008-10-21 19:26:48.179:/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.
2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:
dumpScopeId: RENDER_PHASE
2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:
Elements in scope: portlet-b
ridge-demo:yh4tse3ctjqw:view:-25ecdd41:11d21e77bb0:-7fda
2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:
org.apache.myfaces.port
let.faces.includeInScope.requestParameters
2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:
org.apache.myfaces.el.u
nified.resolver.managedbean.beansUnderConstruction
2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:
org.apache.myfaces.appl
ication.jsp.JspStateManagerImpl.RESTORED_SERIALIZED_VIEW
2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:
org.apache.myfaces.appl
ication.DefaultViewHandlerSupport.CACHED_SERVLET_MAPPING
2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:
jsf_sequence
2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:
namebean
2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO:
org.apache.myfaces.shar
ed_impl.renderkit.RendererUtils.RenderKitImpl
2008-10-21 19:26:48.179:/portlet-bridge-demo:INFO: end
dumpScopeId
The interesting thing about this is that the
RENDER_PHASE is executed twice (there are not two
different request, just one).
I'll try modify myfaces core 1.2.x, so it writes the
marker on server state saving (yes, there are no
performance increase, but I'll take a look at it), and
see what happens. It seems to be a non blocking issue for
release if we modify myfaces core.
I apply the modification on JspViewHandlerImpl, so the marker
is always written. The result is the same, but the warning
disappear. I tried to test firefox 2.0.0.17 <http://2.0.0.17>
(windows vista) from another computer and works normal, so it
seem to be a problem on my other machine (windows xp). I
tried install firefox 3.0.3 and the problem is present too.
The strange part of all this stuff is that jsf ri does not
have the problem (and using myfaces core with client side
state saving too). The configuration that fails specifically
is windows xp, firefox, myfaces core 1.2.x and server state
saving.
Scott
Leonardo Uribe wrote:
On Tue, Oct 21, 2008 at 6:13 PM, Leonardo Uribe
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[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]>
<mailto:[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]>>
<mailto:[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]>>
<mailto:[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> <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>
<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]>>
<mailto:[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>
<http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3>
