Try this. Edit the faces-config.xml file in the
impl\src\main\resources\META-INF directly and add the following lines
after the :
<bridge:excluded-attribute>com.sun.faces.*</bridge:excluded-attribute>
<bridge:excluded-attribute>org.apache.myfaces.application.jsp.JspStateManagerImpl.*</bridge:excluded-attribute>
<bridge:excluded-attribute>org.apache.myfaces.el.unified.resolver.managedbean.*</bridge:excluded-attribute>
<bridge:excluded-attribute>org.apache.myfaces.shared_impl.renderkit.RendererUtils.*</bridge:excluded-attribute>
<bridge:excluded-attribute>org.apache.myfaces.application.DefaultViewHandlerSupport.*</bridge:excluded-attribute>
<bridge:excluded-attribute>jsf_sequence</bridge:excluded-attribute>
Its really only the last one that impacts view restoration but its good
to exlcude the others as well as they don't need to be managed.
Rebuild the bridge/rebuild/rerun the demo. Let me know if this fixes
your problem. If it does I will actually commit this change (I have had
it sitting around for sometime now but didn't want to commit it as part
of the alpha3 work which was already done). I knew that it impacted
refresh in MyFaces but if it fixes you there are other refresh cases
that are easy to hit. Technically its not a bug/something that the
Bridge should worry about -- excluding attributes is something that the
offending system should do (i.e. Myfaces) and or the application -- but
the bridge does have a spirit of excluding for common uses.
-Mike-
Leonardo Uribe 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.
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>
