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>
