Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Darn it.. Yeah, sorry. I'll close the release today. Everything is basically in place and I was allowing a few days for people to look at the new license, but it's been open long enough. Scott Leonardo Uribe wrote: On Thu, Nov 27, 2008 at 7:50 AM, Leonardo Uribe [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi Just a question: I would like to see portlet bridge artifacts released soon, for include it on myfaces archetypes (and release it too). Since we have a positive consensus, when could be this artifacts released? Any idea about when this artifacts could be released? If no idea, I'll start release procedure for myfaces archetypes the next days. regards Leonardo Uribe regards Leonardo Uribe On Mon, Nov 24, 2008 at 6:57 PM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: All, okay, I am changing my vote on this back to +1. I'm sorry for the delay but our minor legal issue has been fixed. It required Oracle to change their license on the JSR-301 final draft and required us to add a clause to the notice of the api and impl which says the code is not yet based on a final spec. I've updated the artifacts and will hold this vote open for a few more days to let people review the changes to the notices if they want. Since there was no real code change though, I don't see a need to redo the vote alltogether. If you disagree, let me know. Scott Scott O'Bryan wrote: I am actually going to have to change my vote to -1 right now. There arose a minor legal issue dealing with the liscense of the public draft for 301 which I think we'll need to fix before release. I'm going to hold the vote open for a bit longer the required because we're fairly confident we can get it sorted out pretty quick. The only artifact this will change will likely be the notice. :) Thanks, Scott Scott O'Bryan wrote: +1 Leonardo Uribe wrote: +1 regards Leonardo Uribe On Mon, Oct 27, 2008 at 11:23 AM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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 have applied the changes needed by PORTLETBRIDGE-51, regenerated all of the artifacts, and deployed them to my private Apache account ([1]). I'm am now restarting the vote for the latest R.I. [ ] +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
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
On Thu, Nov 27, 2008 at 7:50 AM, Leonardo Uribe [EMAIL PROTECTED] wrote: Hi Just a question: I would like to see portlet bridge artifacts released soon, for include it on myfaces archetypes (and release it too). Since we have a positive consensus, when could be this artifacts released? Any idea about when this artifacts could be released? If no idea, I'll start release procedure for myfaces archetypes the next days. regards Leonardo Uribe regards Leonardo Uribe On Mon, Nov 24, 2008 at 6:57 PM, Scott O'Bryan [EMAIL PROTECTED]wrote: All, okay, I am changing my vote on this back to +1. I'm sorry for the delay but our minor legal issue has been fixed. It required Oracle to change their license on the JSR-301 final draft and required us to add a clause to the notice of the api and impl which says the code is not yet based on a final spec. I've updated the artifacts and will hold this vote open for a few more days to let people review the changes to the notices if they want. Since there was no real code change though, I don't see a need to redo the vote alltogether. If you disagree, let me know. Scott Scott O'Bryan wrote: I am actually going to have to change my vote to -1 right now. There arose a minor legal issue dealing with the liscense of the public draft for 301 which I think we'll need to fix before release. I'm going to hold the vote open for a bit longer the required because we're fairly confident we can get it sorted out pretty quick. The only artifact this will change will likely be the notice. :) Thanks, Scott Scott O'Bryan wrote: +1 Leonardo Uribe wrote: +1 regards Leonardo Uribe On Mon, Oct 27, 2008 at 11:23 AM, Scott O'Bryan [EMAIL PROTECTED]mailto: [EMAIL PROTECTED] 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 have applied the changes needed by PORTLETBRIDGE-51, regenerated all of the artifacts, and deployed them to my private Apache account ([1]). I'm am now restarting the vote for the latest R.I. [ ] +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-3http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3 http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Hi Just a question: I would like to see portlet bridge artifacts released soon, for include it on myfaces archetypes (and release it too). Since we have a positive consensus, when could be this artifacts released? regards Leonardo Uribe On Mon, Nov 24, 2008 at 6:57 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: All, okay, I am changing my vote on this back to +1. I'm sorry for the delay but our minor legal issue has been fixed. It required Oracle to change their license on the JSR-301 final draft and required us to add a clause to the notice of the api and impl which says the code is not yet based on a final spec. I've updated the artifacts and will hold this vote open for a few more days to let people review the changes to the notices if they want. Since there was no real code change though, I don't see a need to redo the vote alltogether. If you disagree, let me know. Scott Scott O'Bryan wrote: I am actually going to have to change my vote to -1 right now. There arose a minor legal issue dealing with the liscense of the public draft for 301 which I think we'll need to fix before release. I'm going to hold the vote open for a bit longer the required because we're fairly confident we can get it sorted out pretty quick. The only artifact this will change will likely be the notice. :) Thanks, Scott Scott O'Bryan wrote: +1 Leonardo Uribe wrote: +1 regards Leonardo Uribe On Mon, Oct 27, 2008 at 11:23 AM, Scott O'Bryan [EMAIL PROTECTED]mailto: [EMAIL PROTECTED] 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 have applied the changes needed by PORTLETBRIDGE-51, regenerated all of the artifacts, and deployed them to my private Apache account ([1]). I'm am now restarting the vote for the latest R.I. [ ] +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-3http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3 http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
All, okay, I am changing my vote on this back to +1. I'm sorry for the delay but our minor legal issue has been fixed. It required Oracle to change their license on the JSR-301 final draft and required us to add a clause to the notice of the api and impl which says the code is not yet based on a final spec. I've updated the artifacts and will hold this vote open for a few more days to let people review the changes to the notices if they want. Since there was no real code change though, I don't see a need to redo the vote alltogether. If you disagree, let me know. Scott Scott O'Bryan wrote: I am actually going to have to change my vote to -1 right now. There arose a minor legal issue dealing with the liscense of the public draft for 301 which I think we'll need to fix before release. I'm going to hold the vote open for a bit longer the required because we're fairly confident we can get it sorted out pretty quick. The only artifact this will change will likely be the notice. :) Thanks, Scott Scott O'Bryan wrote: +1 Leonardo Uribe wrote: +1 regards Leonardo Uribe On Mon, Oct 27, 2008 at 11:23 AM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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 have applied the changes needed by PORTLETBRIDGE-51, regenerated all of the artifacts, and deployed them to my private Apache account ([1]). I'm am now restarting the vote for the latest R.I. [ ] +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
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
I am actually going to have to change my vote to -1 right now. There arose a minor legal issue dealing with the liscense of the public draft for 301 which I think we'll need to fix before release. I'm going to hold the vote open for a bit longer the required because we're fairly confident we can get it sorted out pretty quick. The only artifact this will change will likely be the notice. :) Thanks, Scott Scott O'Bryan wrote: +1 Leonardo Uribe wrote: +1 regards Leonardo Uribe On Mon, Oct 27, 2008 at 11:23 AM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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 have applied the changes needed by PORTLETBRIDGE-51, regenerated all of the artifacts, and deployed them to my private Apache account ([1]). I'm am now restarting the vote for the latest R.I. [ ] +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
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
This hasn't yet been resolved in the 301 EG. I have held off on these last few portlet 1.0 issues while finishing up the first draft of the portlet 2.0 bridge spec. I will turn back to these soon. -Mike- Scott O'Bryan wrote: Cool, thanks Felix. Like Mike said, your totally correct about spec compliance of this code, we just want to address this issue in 301 and have the R.I. follow suit. Sent from my iPhone On Oct 28, 2008, at 7:52 PM, Felix Roethenbacher [EMAIL PROTECTED] wrote: Hi Scott, Mike I updated PORTLETBRIDGE-48 https://issues.apache.org/jira/browse/PORTLETBRIDGE-48 with information about the origin of the call to setRequestCharacterEncoding(). Hth, Felix Scott O'Bryan wrote: Wow. for some reason it truncated by response. Here it is again.. Good catch Felix, I think this is going to have to wait till the next release (and I'm hoping we'll have it in main soon - Mike can speak more to this). Here is the issue. The intention of Alpha-3 is to conform to the public review of the JSR-301 spec. The next release will incorporate changes regarding the feedback we've had from the review period - including this issue. Reading the bug, Mike indicated that this change needed to be added to the spec and is not a simple implementation detail. Mike, I don't recall what the resolution was from the EG on this issue. Do we have it resolved? If so, do we have an ETA on when this can be moved into main? Scott On Tue, Oct 28, 2008 at 6:16 PM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Good catch Felix, I think this is going to have to wait till the next release (and I'm hoping we'll have it in main soon - Mike can speak more to this). Here is the issue. The intention of Alpha-3 is to conform to the public review of the JSR-301 spec. The next release will incorporate changes regarding the feedback we've had from the review period - including this issue. Reading the bug, Mike indicated that this change needed to be added to the spec and is not a simple implementation detail. I think that Mike raised the issue that this needs to be addressed in the spec so Felix Roethenbacher wrote: What is the status of PORTLETBRIDGE-48? There is a patch available to fix an issue with setting the character encoding. Thanks, Felix 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 have applied the changes needed by PORTLETBRIDGE-51, regenerated all of the artifacts, and deployed them to my private Apache account ([1]). I'm am now restarting the vote for the latest R.I. [ ] +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 Attention: This email may contain information intended for the sole use of the original recipient. Please respect this when sharing or disclosing this email's contents with any third party. If you believe you have received this email in error, please delete it and notify the sender or [EMAIL PROTECTED] as soon as possible. The content of this email does not necessarily reflect the views of Solnet Solutions Ltd.
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
+1 On Mon, Oct 27, 2008 at 9:01 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: +1 Leonardo Uribe wrote: +1 regards Leonardo Uribe On Mon, Oct 27, 2008 at 11:23 AM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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 have applied the changes needed by PORTLETBRIDGE-51, regenerated all of the artifacts, and deployed them to my private Apache account ([1]). I'm am now restarting the vote for the latest R.I. [ ] +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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
+1 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 have applied the changes needed by PORTLETBRIDGE-51, regenerated all of the artifacts, and deployed them to my private Apache account ([1]). I'm am now restarting the vote for the latest R.I. [ ] +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
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
What is the status of PORTLETBRIDGE-48? There is a patch available to fix an issue with setting the character encoding. Thanks, Felix 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 have applied the changes needed by PORTLETBRIDGE-51, regenerated all of the artifacts, and deployed them to my private Apache account ([1]). I'm am now restarting the vote for the latest R.I. [ ] +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 Attention: This email may contain information intended for the sole use of the original recipient. Please respect this when sharing or disclosing this email's contents with any third party. If you believe you have received this email in error, please delete it and notify the sender or [EMAIL PROTECTED] as soon as possible. The content of this email does not necessarily reflect the views of Solnet Solutions Ltd.
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Wow. for some reason it truncated by response. Here it is again.. Good catch Felix, I think this is going to have to wait till the next release (and I'm hoping we'll have it in main soon - Mike can speak more to this). Here is the issue. The intention of Alpha-3 is to conform to the public review of the JSR-301 spec. The next release will incorporate changes regarding the feedback we've had from the review period - including this issue. Reading the bug, Mike indicated that this change needed to be added to the spec and is not a simple implementation detail. Mike, I don't recall what the resolution was from the EG on this issue. Do we have it resolved? If so, do we have an ETA on when this can be moved into main? Scott On Tue, Oct 28, 2008 at 6:16 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Good catch Felix, I think this is going to have to wait till the next release (and I'm hoping we'll have it in main soon - Mike can speak more to this). Here is the issue. The intention of Alpha-3 is to conform to the public review of the JSR-301 spec. The next release will incorporate changes regarding the feedback we've had from the review period - including this issue. Reading the bug, Mike indicated that this change needed to be added to the spec and is not a simple implementation detail. I think that Mike raised the issue that this needs to be addressed in the spec so Felix Roethenbacher wrote: What is the status of PORTLETBRIDGE-48? There is a patch available to fix an issue with setting the character encoding. Thanks, Felix 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 have applied the changes needed by PORTLETBRIDGE-51, regenerated all of the artifacts, and deployed them to my private Apache account ([1]). I'm am now restarting the vote for the latest R.I. [ ] +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-3http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3 Attention: This email may contain information intended for the sole use of the original recipient. Please respect this when sharing or disclosing this email's contents with any third party. If you believe you have received this email in error, please delete it and notify the sender or [EMAIL PROTECTED] as soon as possible. The content of this email does not necessarily reflect the views of Solnet Solutions Ltd.
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Hi Scott, Mike I updated PORTLETBRIDGE-48 https://issues.apache.org/jira/browse/PORTLETBRIDGE-48 with information about the origin of the call to setRequestCharacterEncoding(). Hth, Felix Scott O'Bryan wrote: Wow. for some reason it truncated by response. Here it is again.. Good catch Felix, I think this is going to have to wait till the next release (and I'm hoping we'll have it in main soon - Mike can speak more to this). Here is the issue. The intention of Alpha-3 is to conform to the public review of the JSR-301 spec. The next release will incorporate changes regarding the feedback we've had from the review period - including this issue. Reading the bug, Mike indicated that this change needed to be added to the spec and is not a simple implementation detail. Mike, I don't recall what the resolution was from the EG on this issue. Do we have it resolved? If so, do we have an ETA on when this can be moved into main? Scott On Tue, Oct 28, 2008 at 6:16 PM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Good catch Felix, I think this is going to have to wait till the next release (and I'm hoping we'll have it in main soon - Mike can speak more to this). Here is the issue. The intention of Alpha-3 is to conform to the public review of the JSR-301 spec. The next release will incorporate changes regarding the feedback we've had from the review period - including this issue. Reading the bug, Mike indicated that this change needed to be added to the spec and is not a simple implementation detail. I think that Mike raised the issue that this needs to be addressed in the spec so Felix Roethenbacher wrote: What is the status of PORTLETBRIDGE-48? There is a patch available to fix an issue with setting the character encoding. Thanks, Felix 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 have applied the changes needed by PORTLETBRIDGE-51, regenerated all of the artifacts, and deployed them to my private Apache account ([1]). I'm am now restarting the vote for the latest R.I. [ ] +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 Attention: This email may contain information intended for the sole use of the original recipient. Please respect this when sharing or disclosing this email's contents with any third party. If you believe you have received this email in error, please delete it and notify the sender or [EMAIL PROTECTED] as soon as possible. The content of this email does not necessarily reflect the views of Solnet Solutions Ltd.
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Cool, thanks Felix. Like Mike said, your totally correct about spec compliance of this code, we just want to address this issue in 301 and have the R.I. follow suit. Sent from my iPhone On Oct 28, 2008, at 7:52 PM, Felix Roethenbacher [EMAIL PROTECTED] wrote: Hi Scott, Mike I updated PORTLETBRIDGE-48 https://issues.apache.org/jira/browse/PORTLETBRIDGE-48 with information about the origin of the call to setRequestCharacterEncoding(). Hth, Felix Scott O'Bryan wrote: Wow. for some reason it truncated by response. Here it is again.. Good catch Felix, I think this is going to have to wait till the next release (and I'm hoping we'll have it in main soon - Mike can speak more to this). Here is the issue. The intention of Alpha-3 is to conform to the public review of the JSR-301 spec. The next release will incorporate changes regarding the feedback we've had from the review period - including this issue. Reading the bug, Mike indicated that this change needed to be added to the spec and is not a simple implementation detail. Mike, I don't recall what the resolution was from the EG on this issue. Do we have it resolved? If so, do we have an ETA on when this can be moved into main? Scott On Tue, Oct 28, 2008 at 6:16 PM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Good catch Felix, I think this is going to have to wait till the next release (and I'm hoping we'll have it in main soon - Mike can speak more to this). Here is the issue. The intention of Alpha-3 is to conform to the public review of the JSR-301 spec. The next release will incorporate changes regarding the feedback we've had from the review period - including this issue. Reading the bug, Mike indicated that this change needed to be added to the spec and is not a simple implementation detail. I think that Mike raised the issue that this needs to be addressed in the spec so Felix Roethenbacher wrote: What is the status of PORTLETBRIDGE-48? There is a patch available to fix an issue with setting the character encoding. Thanks, Felix 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 have applied the changes needed by PORTLETBRIDGE-51, regenerated all of the artifacts, and deployed them to my private Apache account ([1]). I'm am now restarting the vote for the latest R.I. [ ] +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 Attention: This email may contain information intended for the sole use of the original recipient. Please respect this when sharing or disclosing this email's contents with any third party. If you believe you have received this email in error, please delete it and notify the sender or [EMAIL PROTECTED] as soon as possible. The content of this email does not necessarily reflect the views of Solnet Solutions Ltd.
[VOTE] Release of Portlet Bridge 1.0.0-alpha-3
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 have applied the changes needed by PORTLETBRIDGE-51, regenerated all of the artifacts, and deployed them to my private Apache account ([1]). I'm am now restarting the vote for the latest R.I. [ ] +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
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
+1 regards Leonardo Uribe On Mon, Oct 27, 2008 at 11:23 AM, Scott O'Bryan [EMAIL PROTECTED] 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 have applied the changes needed by PORTLETBRIDGE-51, regenerated all of the artifacts, and deployed them to my private Apache account ([1]). I'm am now restarting the vote for the latest R.I. [ ] +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-3http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
+1 Leonardo Uribe wrote: +1 regards Leonardo Uribe On Mon, Oct 27, 2008 at 11:23 AM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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 have applied the changes needed by PORTLETBRIDGE-51, regenerated all of the artifacts, and deployed them to my private Apache account ([1]). I'm am now restarting the vote for the latest R.I. [ ] +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
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
I'll add the patch to alpha-3 and regenerate the artifacts. Thanks Leonardo. Scott Leonardo Uribe wrote: On Wed, Oct 22, 2008 at 12:54 PM, Leonardo Uribe [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Wed, Oct 22, 2008 at 12:13 PM, Michael Freedman [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Can you send a description of the exact steps to reproduce the problem. I.e. Run app, fill in X, Click Y then you will notice Z? Also can you send a more thorough description of the problem you are seeing. I.e On all other platforms the app behaves like X when you do Y but in this platform/browser the app behaves like Z when you do Y? Did you run with the excluded attributes I suggested? Not excluding jsf_sequence will cause incorrect view state/view restoration in certain circumstances. However, as Scott says, the bridge injects no markup into the response hence running in a different browser/platform should be unrelated to the Bridge. -Mike- I tried adding the attributes to faces-config.xml of portlet-impl and the problem is still present. I'll fill a issue about this with all necessary info. I rerun all tests to see if I loose some detail (yesterday I worked a lot and maybe I was too tired). I made a mistake adding this params to faces-config.xml. bridge:excluded-attributeorg.apache.myfaces.application.jsp.JspStateManagerImpl.*/bridge:excluded-attribute bridge:excluded-attributeorg.apache.myfaces.el.unified.resolver.managedbean.*/bridge:excluded-attribute bridge:excluded-attributeorg.apache.myfaces.shared_impl.renderkit.RendererUtils.*/bridge:excluded-attribute bridge:excluded-attributeorg.apache.myfaces.application.DefaultViewHandlerSupport.*/bridge:excluded-attribute bridge:excluded-attributejsf_sequence/bridge:excluded-attribute If you add this params to portlet bridge faces-config.xml the problem disappear and the application works correctly (I tried several times to be sure). So, it could be good to add it for release portlet bridge 1.0.0-alpha-3. I'll create a jira issue for this. regards Leonardo Uribe Leonardo Uribe wrote: 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:
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Wow, it's beginning to sound like a JVM or OS error to meet. None of the code we have in the bridge SHOULD be OS dependent. Plus, it's working fine on my machine although, admittedly, I'm running 1.6_10. I'll try to downgrade to 1.5 and see if I can reproduce the issue. Scott Leonardo Uribe wrote: 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:
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Can you send a description of the exact steps to reproduce the problem. I.e. Run app, fill in X, Click Y then you will notice Z? Also can you send a more thorough description of the problem you are seeing. I.e On all other platforms the app behaves like X when you do Y but in this platform/browser the app behaves like Z when you do Y? Did you run with the excluded attributes I suggested? Not excluding jsf_sequence will cause incorrect view state/view restoration in certain circumstances. However, as Scott says, the bridge injects no markup into the response hence running in a different browser/platform should be unrelated to the Bridge. -Mike- Leonardo Uribe wrote: On Tue, Oct 21, 2008 at 7:40 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: On Tue, Oct 21, 2008 at 6:52 PM, Scott O'Bryan [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 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
[VOTE] Release of Portlet Bridge 1.0.0-alpha-3
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
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
+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
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
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 and the demo is running fine for me. So please send me more info on reproducing. As for running with the RI there are potentially two issues: first the command is now: mvn clean -PjettyConfig -Djsf=ri-provided jetty:run 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-7fd3javax.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
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
On Tue, Oct 21, 2008 at 4:50 PM, michael freedman [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 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 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-7fd3javax.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]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-3http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3 http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
On Tue, Oct 21, 2008 at 5:18 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: On Tue, Oct 21, 2008 at 4:50 PM, michael freedman [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 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 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-7fd3javax.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]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-3http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3 http://people.apache.org/%7Esobryan/portlet-bridge/1.0.0-alpha-3
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
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] 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-7fd3javax.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]
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
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-7fd3javax.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
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
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] 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-7fd3javax.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
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
On Tue, Oct 21, 2008 at 6:13 PM, Leonardo Uribe [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] 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] 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-7fd3javax.faces.
ViewState=qpZU311sohuneMJrlpRjNB4K2cfv0ubhRgzMYD5Kf4V1pkzHlFXyeKdNfb5408dPXMeN1u
tp3qg5cWArexFYziMyJAzgTwOQ8GFyqxDCz8Y%3D
2008-10-21
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
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.
Scott
Leonardo Uribe wrote:
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
Re: [VOTE] Release of Portlet Bridge 1.0.0-alpha-3
Argh, you're right Cagatay. There was one piece of functionality added since the last time I checked to comply with a recent edition of the public review. It broke things. Let me see if I can fix it an regenerate the artifacts. It fails when running with jetty as well. Good Catch. Cagatay Civici wrote: I'm using Pluto 1.1.6 with tomcat6 as the test environment. After replacing alpha-2 jars with alpha-3 jars for my portlet, I got; Caused by: java.io.IOException: Unable to process response. Failed to locate SAVESTATE_FIELD_MARKER at org.apache.myfaces.portlet.faces.application.PortletViewHandlerImpl$StringBuilderWriter.determineSaveStateFieldMarker(PortletViewHandlerImpl.java:459) at org.apache.myfaces.portlet.faces.application.PortletViewHandlerImpl$StringBuilderWriter.write(PortletViewHandlerImpl.java:419) at org.apache.myfaces.portlet.faces.application.PortletViewHandlerImpl.renderView(PortletViewHandlerImpl.java:271) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRender(BridgeImpl.java:668) at org.apache.myfaces.portlet.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:526) ... 65 more Switched back to alpha-2 lib, my portlet worked and the exception disappeared, so my vote is -1 for now. Cagatay On Wed, Aug 27, 2008 at 10:03 AM, Matthias Wessendorf [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: +1 On Wed, Aug 27, 2008 at 4:48 AM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi, I'm trying to release the MyFaces Portlet Bridge Master 1.0.0-alpha-3. This pom file 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 -- Matthias Wessendorf Need JSF and Web 2.0? http://code.google.com/p/facesgoodies further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
