from:"Michael Freedman"

Michael Freedman created PORTLETBRIDGE-231:
--

 Summary: Request Threads can get stuck when Bridge removes a scope
 Key: PORTLETBRIDGE-231
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-231
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
Affects Versions: 2.0.0, 1.0.0, 3.0.0
Reporter: Michael Freedman
Assignee: Michael Freedman


During the process of removing the scopes associated with a given session when 
a session is invalidated/released, request threads can become stuck waiting on 
the scope manager lock because action of iterating over all the objects (and 
their methods) in the scope to find and then call managed bean predestroy 
methods occurs while the lock is held.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (PORTLETBRIDGE-231) Request Threads can get stuck when Bridge removes a scope


[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13468125#comment-13468125
 ] 

Michael Freedman commented on PORTLETBRIDGE-231:


Fixed in the Oracle branch by having the thread holding the lock merely push 
the scope being removed onto a queue and then notifies waiting threads.  A 
single (app wide) thread listens/waits to be notified this queue has entries 
and when its woken up, takes the scope object from the queue and executes the 
predestroy logic.

 Request Threads can get stuck when Bridge removes a scope
 -

 Key: PORTLETBRIDGE-231
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-231
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
Affects Versions: 1.0.0, 2.0.0, 3.0.0
Reporter: Michael Freedman
Assignee: Michael Freedman

 During the process of removing the scopes associated with a given session 
 when a session is invalidated/released, request threads can become stuck 
 waiting on the scope manager lock because action of iterating over all the 
 objects (and their methods) in the scope to find and then call managed bean 
 predestroy methods occurs while the lock is held.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (PORTLETBRIDGE-232) Add ability for portlet to clear current request scope.

Michael Freedman created PORTLETBRIDGE-232:
--

 Summary: Add ability for portlet to clear current request scope.
 Key: PORTLETBRIDGE-232
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-232
 Project: MyFaces Portlet Bridge
  Issue Type: New Feature
Affects Versions: 2.0.1-oracle-PS6
Reporter: Michael Freedman
Assignee: Michael Freedman


We want to provide an ability for the portlet to tell the bridge to clear the 
current scope. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (PORTLETBRIDGE-232) Add ability for portlet to clear current request scope.


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-232.


Resolution: Fixed

Bridge now recognizes the attribute 
org.apache.myfaces.portlet.faces.clearRequestScope. If the value is a Boolean 
and true then the bridge clears the current scope at the beginning of an event, 
render, or resource request.

 Add ability for portlet to clear current request scope.
 ---

 Key: PORTLETBRIDGE-232
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-232
 Project: MyFaces Portlet Bridge
  Issue Type: New Feature
Affects Versions: 2.0.1-oracle-PS6
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 2.0.1-oracle-PS6


 We want to provide an ability for the portlet to tell the bridge to clear the 
 current scope. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (PORTLETBRIDGE-231) Request Threads can get stuck when Bridge removes a scope


[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13468161#comment-13468161
 ] 

Michael Freedman commented on PORTLETBRIDGE-231:


Fixed in Oracle's PS6 branch -- consider migrating to all other branches.

 Request Threads can get stuck when Bridge removes a scope
 -

 Key: PORTLETBRIDGE-231
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-231
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
Affects Versions: 1.0.0, 2.0.0, 3.0.0
Reporter: Michael Freedman
Assignee: Michael Freedman

 During the process of removing the scopes associated with a given session 
 when a session is invalidated/released, request threads can become stuck 
 waiting on the scope manager lock because action of iterating over all the 
 objects (and their methods) in the scope to find and then call managed bean 
 predestroy methods occurs while the lock is held.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (PORTLETBRIDGE-228) supported-publishing-event and supported-processing-event ordering is incorrect according to portlet-app_2_0.xsd


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-228.


   Resolution: Fixed
Fix Version/s: 3.0.0
   2.0.1

Updated portlet.xml to switch order of the tags to give correct XML syntax

 supported-publishing-event and supported-processing-event ordering is 
 incorrect according to portlet-app_2_0.xsd
 

 Key: PORTLETBRIDGE-228
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-228
 Project: MyFaces Portlet Bridge
  Issue Type: TCK Challenge
  Components: TCK
Affects Versions: 2.0.0
 Environment: N/A
Reporter: Neil Griffin
Assignee: Michael Freedman
 Fix For: 2.0.1, 3.0.0


 [Test Challenger Name and Company] 
 Neil Griffin, Liferay, Inc. 
 [Specification Name(s) and Version(s)] 
 Portlet 2.0 Bridge for JavaServer™ Faces 1.2 
 [Test Suite Name and Version] 
 portlet-bridge-tck-main, v1.0.0 
 [Exclude List Version] 
 N/A 
 [Test Name] 
 All portlets that invoke Events based IPC.
 [Complaint (argument for why test is invalid)] 
 The portlet-bridge-tck-main/src/main/webapp/portlet.xml descriptor has the 
 following specified multiple times:
 {code}
 supported-publishing-event
   qname 
 xmlns:bridge=http://myfaces.apache.org/portlet-bridge/event_ns;bridge:myfaces.apache.org.tck.testEvent/qname
 /supported-publishing-event
 supported-processing-event
   qname 
 xmlns:bridge=http://myfaces.apache.org/portlet-bridge/event_ns;bridge:myfaces.apache.org.tck.testEvent/qname
 /supported-processing-event
 {code}
 But this is invalid according to the portlet-app_2_0.xsd XML Schema, and it 
 is causing Liferay Portal to refuse to deploy the portlet.
 The fix is to swap the order of each occurrence, so that 
 supported-processing-event appears before supported-publishing-event.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (PORTLETBRIDGE-227) Bridge Spec and TCK assume that the portlet container implements the post-redirect-get design pattern


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-227.


   Resolution: Fixed
Fix Version/s: 3.0.0
   2.0.1

Updated portlet.xml to put event tags in correct (syntax) order.

 Bridge Spec and TCK assume that the portlet container implements the 
 post-redirect-get design pattern
 -

 Key: PORTLETBRIDGE-227
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-227
 Project: MyFaces Portlet Bridge
  Issue Type: TCK Challenge
  Components: TCK
Affects Versions: 2.0.0
 Environment: Liferay Portal 6.1.x + Liferay Faces Bridge 3.1.x
Reporter: Neil Griffin
Assignee: Michael Freedman
 Fix For: 2.0.1, 3.0.0


 [Test Challenger Name and Company] 
 Neil Griffin, Liferay, Inc. 
 [Specification Name(s) and Version(s)] 
 Portlet 2.0 Bridge for JavaServer™ Faces 1.2 
 [Test Suite Name and Version] 
 portlet-bridge-tck-main, v1.0.0 
 [Exclude List Version] 
 N/A 
 [Test Name] 
 TCK TestPage151 (requestMapRequestScopeTest) 
 [Complaint (argument for why test is invalid)] 
 Portlet containers like Pluto implement the post-redirect-get design pattern 
 by having the the ACTION_PHASE and RENDER_PHASE of the portlet lifecycle 
 execute in two separate user-agent requests. The first request is a POST 
 (ActionRequest), and the second request is a GET (RenderRequest). As a 
 natural by-product of this design, request attributes that were set during 
 the ACTION_PHASE do not survive into the RENDER_PHASE. On a related note, one 
 of the requirements of the bridge-request-scope is to ensure that 
 non-excluded attributes do indeed survive into the RENDER_PHASE.
 The Liferay portlet container does not implement the post-redirect-get design 
 pattern. Instead, it executes the ACTION_PHASE and RENDER_PHASE of the 
 portlet lifecycle all within a single user-agent POST request.  Because of 
 this, the Liferay portlet container maintains request attributes that were 
 originally set on the {@link ActionRequest} such that they automatically 
 survive into the {@link RenderRequest}.
 Problem Description: The TCK TestPage151 (requestMapRequestScopeTest) 
 performs some checks to make sure that certain non-excluded request 
 attributes don't survive into the RENDER_PHASE. One of these attributes is 
 named verifyPreBridgeExclusion with value avalue. Since the Liferay 
 portlet container does not implement post-redirect-get, it is not possible 
 for the bridge to programatically determine if the verifyPreBridgeExclusion 
 attribute should be removed.
 Since the Bridge Spec assumes that the portlet container implements 
 post-redirect-get, it would be necessary for the bridge to pro-actively 
 remove non-excluded request attributes when running under Liferay Portal.
 Details of problem: The following is an example list of String-based 
 attributes that are present in the Liferay Portal RenderRequest prior to the 
 FacesContext being constructed by the requestMapRequestScopeTest:
 * 
 INVOKER_FILTER_URI=/chapter6_1_3_1TestsrequestMapRequestScopeTestportlet/invoke
 * 
 PORTLET_ID=chapter6_1_3_1TestsrequestMapRequestScopeTestportlet_WAR_bridgetckmainportlet
 * verifyPreBridgeExclusion=avalue
 In this example, the INVOKER_FILTER_URI and PORTLET_ID attributes (added by 
 the Liferay portlet container) need to be maintained, but the 
 verifyPreBridgeExclusion attribute needs to be removed. But to restate the 
 problem, it is not possible for the bridge to programatically determine which 
 one of these should be maintained and which should be removed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (PORTLETBRIDGE-226) requestProcessingNonFacesTest specifies charset in JSP


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-226.


   Resolution: Fixed
Fix Version/s: 3.0.0
   2.0.1

Changed test in the jsp to only test that the content type starts with the 
expected content type name -- this allows charset to also be reflected in the 
result.

 requestProcessingNonFacesTest specifies charset in JSP
 --

 Key: PORTLETBRIDGE-226
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-226
 Project: MyFaces Portlet Bridge
  Issue Type: TCK Challenge
  Components: TCK
Affects Versions: 2.0.0
 Environment: Liferay Portal + Liferay Faces Bridge
Reporter: Neil Griffin
Assignee: Michael Freedman
 Fix For: 2.0.1, 3.0.0


 [Test Challenger Name and Company] 
 Neil Griffin, Liferay, Inc. 
 [Specification Name(s) and Version(s)] 
 Portlet 2.0 Bridge for JavaServer™ Faces 1.2 
 [Test Suite Name and Version] 
 portlet-bridge-tck-main, v1.0.0 
 [Exclude List Version] 
 N/A 
 [Test Name] 
 requestProcessingNonFacesTest
 [Complaint (argument for why test is invalid)] 
 If the TestPage017 (requestProcessingNonFacesTest) is successful, the output 
 text should be the following:
 {code}Detail: Expected response content type is text/html, actual value is 
 text/html.{code}
 However, under Liferay Portal the test fails with the following:
 {code}Detail: Expected response content type is text/html, actual value is 
 text/html; charset=UTF-8.{code}
 The reason why is because the test contains a JSP file named 
 chapter4_2_5Result.jsp that starts with the following directive:
 %@ page contentType = text/html; charset=UTF-8 ... %
 ... and Liferay Portal has a feature that respects the contentType attribute 
 of the page directive, which ultimately calls back into the Liferay 
 implementation of 
 [MimeResponse.setContentType(String)|http://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/MimeResponse.html#setContentType(java.lang.String)].
  That's why Liferay returns an actual value of text/html; charset=UTF-8

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (PORTLETBRIDGE-223) Bridge mishandles encodings of urls with targets containing same prefix as contextpath


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-223.


   Resolution: Fixed
Fix Version/s: 3.0.0
   2.0.1

Code in ExternalContext now explicitly checks to make sure that string matches 
aren't inadvertently finding the name elsewhere in the path/target.

 Bridge mishandles encodings of urls with targets containing same prefix as 
 contextpath
 --

 Key: PORTLETBRIDGE-223
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-223
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0, 2.0.0, 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 2.0.1, 3.0.0


 If a target is prefixed with the same name/string as the context path, the 
 bridge mishandles encoding/decoding the URLs as portlet urls.  For example if 
 the contextpath is /simple and the path is /simple.jspx code in the bridge's 
 ExternalContext will break as there are several locations where the bridge 
 either needs to adds the ContextPath during encoding or strip the ContextPath 
 during decoding.  In both cases the bridge incorrectly recognizes the CP in 
 the above example (/simple.jspx) when its not there.  All tests for context 
 path must therefore not only check that string startwith the CP but in fact 
 ends with a /.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (PORTLETBRIDGE-223) Bridge mishandles encodings of urls with targets containing same prefix as contextpath

2012-07-16 Thread Michael Freedman (JIRA)

Michael Freedman created PORTLETBRIDGE-223:
--

 Summary: Bridge mishandles encodings of urls with targets 
containing same prefix as contextpath
 Key: PORTLETBRIDGE-223
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-223
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0, 1.0.0, 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman


If a target is prefixed with the same name/string as the context path, the 
bridge mishandles encoding/decoding the URLs as portlet urls.  For example if 
the contextpath is /simple and the path is /simple.jspx code in the bridge's 
ExternalContext will break as there are several locations where the bridge 
either needs to adds the ContextPath during encoding or strip the ContextPath 
during decoding.  In both cases the bridge incorrectly recognizes the CP in the 
above example (/simple.jspx) when its not there.  All tests for context path 
must therefore not only check that string startwith the CP but in fact ends 
with a /.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (PORTLETBRIDGE-221) Add explicit exclusions for trinidad in 329 branch

2011-11-22 Thread Michael Freedman (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13155497#comment-13155497
 ] 

Michael Freedman commented on PORTLETBRIDGE-221:


Fixed in 2.0 Trunk by changing implementation back to the original.  The Bridge 
no longer updates the scope in a render request, rather it leaves the existing 
scope unchanged except for attributes it maintains/manages such as the 
VIEW_STATE_PARAM.

Fixed in Oracle branch by explicitly excluding (in code) trinidad and adf 
attributes during a render phase.  Code doesn't exclude/remove trinidad/adf 
attrs that were carried forward from the action, just those added during the 
render.

3.0 work is still pending.

 Add explicit exclusions for trinidad in 329 branch 
 ---

 Key: PORTLETBRIDGE-221
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-221
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0
Reporter: Michael Freedman
Assignee: Michael Freedman

 We are running into problems with a user of the 329 branch codeline when 
 using with extra Faces (componentkit) extensions.  The problem is the bridge 
 is updating the bridge scope at the end of the render request pushing all new 
 attributes created during the render into the scope.  These extensions are 
 expecting this so numerous request scope attrs which are flags that 
 something is initialized/done are inappropriately being carried forward and 
 used causing malfunctions.  At the moment we don't want to just blanket 
 reverse the code from saving the scope at the end of the render -- instead 
 deciding the safest thing is to just exclude the specific packages that might 
 exist.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (PORTLETBRIDGE-219) NonFaces in protocol resource request fails after and action

2011-11-22 Thread Michael Freedman (Commented) (JIRA)

[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13155498#comment-13155498
]

Michael Freedman commented on PORTLETBRIDGE-219:

Fixed in the 2.0 Trunk and oracle branches by adding the distinct resource
param to hold the viewId. Work still pending in the 3.0 Trunk.

NonFaces in protocol resource request fails after and action

Key: PORTLETBRIDGE-219
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-219
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 2.0.0, 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman

Impl relies on the same render parameter to hold the viewId at the end of an
action or in a resourceURL that references a Faces resource. Hence the check
in Bridge during a resource request on whether the request is for a Faces or
NonFaces resource depends on whether this render parameter exists or not.
The problem is in that in a resource URL this isn't really a render parameter
but rather a resource parameter. The resource receives the current portlet
render parameters + its url encoded resource parameters. This means that if
an action occurs it will set the VIEWID render parameter. If in the render
following this action we create and render a resource url to a nonFaces
resource request then when this resource request is sent we will still
receive the VIEWID parameter and incorrectly think this is Faces resource
request when its a nonFaces one.
Fix is to have a distinct resource param to hold the viewId for Faces
resource URL. Then the check looks for existence/nonexistence of this param
and ignores whether the render param VIEWID is there. Note: when making
this fix will also need to update the code that resolves the view to execute
as we will need to test if we are in a resource request and pull from the
right param.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (PORTLETBRIDGE-221) Add explicit exclusions for trinidad in 329 branch

2011-10-20 Thread Michael Freedman (Created) (JIRA)

Add explicit exclusions for trinidad in 329 branch 
---

 Key: PORTLETBRIDGE-221
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-221
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0
Reporter: Michael Freedman
Assignee: Michael Freedman


We are running into problems with a user of the 329 branch codeline when using 
with extra Faces (componentkit) extensions.  The problem is the bridge is 
updating the bridge scope at the end of the render request pushing all new 
attributes created during the render into the scope.  These extensions are 
expecting this so numerous request scope attrs which are flags that something 
is initialized/done are inappropriately being carried forward and used causing 
malfunctions.  At the moment we don't want to just blanket reverse the code 
from saving the scope at the end of the render -- instead deciding the safest 
thing is to just exclude the specific packages that might exist.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (PORTLETBRIDGE-219) NonFaces in protocol resource request fails after and action

2011-08-23 Thread Michael Freedman (JIRA)

NonFaces in protocol resource request fails after and action


 Key: PORTLETBRIDGE-219
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-219
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0, 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman


Impl relies on the same render parameter to hold the viewId at the end of an 
action or in a resourceURL that references a Faces resource.  Hence the check 
in Bridge during a resource request on whether the request is for a Faces or 
NonFaces resource depends on whether this render parameter exists or not.  The 
problem is in that in a resource URL this isn't really a render parameter but 
rather a resource parameter.  The resource receives the current portlet render 
parameters + its url encoded resource parameters.  This means that if an action 
occurs it will set the VIEWID render parameter.  If in the render following 
this action we create and render a resource url to a nonFaces resource request 
then when this resource request is sent we will still receive the VIEWID 
parameter and incorrectly think this is Faces resource request when its a 
nonFaces one.  

Fix is to have a distinct resource param to hold the viewId for Faces resource 
URL.  Then the check looks for existence/nonexistence of this param and ignores 
whether the render param VIEWID is there.  Note:  when making this fix will 
also need to update the code that resolves the view to execute as we will need 
to test if we are in a resource request and pull from the right param.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (PORTLETBRIDGE-220) 329 TCK: change TCK NonFacesResourceTest to test/verify conditions that explained in PORTLETBRIDGE-219

2011-08-23 Thread Michael Freedman (JIRA)

329 TCK:  change TCK NonFacesResourceTest to test/verify conditions that 
explained in PORTLETBRIDGE-219
---

 Key: PORTLETBRIDGE-220
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-220
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: TCK
Reporter: Michael Freedman
Assignee: Michael Freedman


Modify the TCKs NonFacesResourceTest to start with a page that requires you to 
run an action to get to the actual test page.  This duplicates the situation 
where the encoderesourceURL is called in the render following an action -- and 
hence the resource request itself falls into this same context.  This is the 
situation that caused PB-219 to be raised.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (PORTLETBRIDGE-217) Test URL should be resources/myImage.jpg?javax.portlet.faces.BackLink=myBackLinkParam

2011-07-05 Thread Michael Freedman (JIRA)


[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13060037#comment-13060037
 ] 

Michael Freedman commented on PORTLETBRIDGE-217:


Wesley, is this a patch file created from the changes I made/checked into 
trunk?  I need to know if there are further updates I need to make to the TCK 
or whether this patch is here for others who prefer to pick up the released 
version?

 Test URL should be 
 resources/myImage.jpg?javax.portlet.faces.BackLink=myBackLinkParam
 ---

 Key: PORTLETBRIDGE-217
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-217
 Project: MyFaces Portlet Bridge
  Issue Type: TCK Challenge
  Components: TCK
Affects Versions: 2.0.0
Reporter: Wesley Hales
Assignee: Michael Freedman
 Attachments: pbr-tck.patch


 [Alexander Smirnov  Wesley Hales: Red Hat]
 [jsr329-1.0.0]
 [portlet_2_bridge-1_0-final-spec]
 [chapter_6/section_6_5_1/Tests#testImplicitObject,
 chapter_6/section_6_1_3_1/Tests#illegalRedirectRenderTest,
 chapter_4/section_4_2_1/InitMethodTestPortlet#init,
 /testsuite/beans/NonJSFViewBean#getUrl]
 [https://issues.jboss.org/browse/PBR-254?focusedCommentId=12611867page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12611867
 Many tests failed because of possible TCK issue, that threats URLs not 
 started with application context as internals.
 Following this logic (and given Oracle's use of encodeActionURL to encode its 
 equivalent of the OutputLink) then encodeAction should do a return 
 portletResponse.encodeURL(target) if the url begins with a / and isn't (this 
 application) context-path prefixed. I.e. we need the bridge code to give the 
 portlet container a chance to encode the server/port (construct and absolute 
 url) - typically when the portlet container is remote.
 Sound about right? I know the spec doesn't say anything about this but it 
 seems to fall out from this decision/interpretation. Does your code already 
 do this? If not should it?
 Mike
 On 6/14/2011 1:29 PM, Michael Freedman wrote:
  So what you are saying is that because ViewHandler.getResourceURL() is 
  defined and it will always append the ContextPath then the spec/impl should 
  assume that urls starting with '/' that don't contain a ContextPath must be 
  out of the application (because all in application urls would have been 
  channeled through getResourceURL? I.e. just using /xxx as a resource url 
  without a context path doesn't work in servlet based JSF. Interesting - 
  okay I see your logic. Please file a JIRA against the TCK indicating the 
  test url it should use ought to be 
  resources/myImage.jpg?javax.portlet.faces.BackLink=myBackLinkParam. If 
  possible please make the needed changes yourself and verify (and then 
  submit the jira with either the details of the code change or a patch file).
 
  I will file a bug against the RI concerning its not treating / as an 
  external url - and since we are changing the test/fixing a bug will just 
  include in the 2.0.1 release.
  Mike
 ]

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (PORTLETBRIDGE-215) EncodeResource url improperly recognizes non context path encoded urls beginning with / as being an internal url

2011-06-23 Thread Michael Freedman (JIRA)

[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Freedman resolved PORTLETBRIDGE-215.

Resolution: Fixed
Fix Version/s: 3.0.0
2.0.1
1.0.1

Both encodeActionURL and encodeResourceURL have been modified so they now
assume any URL beginning with a / is contextpath encoded and hence any that do
not can't be an external URL. Primary change from this: anything starting
with a / must be CP encoded or else will fail (before we would add the current
CP).

EncodeResource url improperly recognizes non context path encoded urls
beginning with / as being an internal url
-

Key: PORTLETBRIDGE-215
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-215
Project: MyFaces Portlet Bridge
Issue Type: Bug
Reporter: Michael Freedman
Assignee: Michael Freedman
Fix For: 1.0.1, 2.0.1, 3.0.0

If you have an url that is passed to encodeResourceUrl which begins
/foo/bar.jpg where /foo isn't this applications context-path, the bridge
recognizes this url as a internal app url and prefixs it with the
context-path. However, because JSF doesn't do auto-context path appending
the above url is invalid in regular (serlvet) JSF as its neither relative to
the current page nor the current server. Hence all resource urls that begin
with / should be seen as external urls -- i.e. assumed to be urls that are
full path (including the context-path) to another application in this server.
As ADF's GoLink uses encodeActionUrl for its targets -- we should also review
and consider correct behavior there as well.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (PORTLETBRIDGE-211) Trinidad doesn't work with the 3.0.0 Portlet Bridge

2011-06-23 Thread Michael Freedman (JIRA)

[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Freedman resolved PORTLETBRIDGE-211.

Resolution: Fixed
Fix Version/s: 3.0.0

With the release Trinidad 2.0.0 these problems have gone away -- so marking bug
as resolved.

Trinidad doesn't work with the 3.0.0 Portlet Bridge
---

Key: PORTLETBRIDGE-211
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-211
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: TCK
Affects Versions: 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Scott O'Bryan
Fix For: 3.0.0

I got 2.0.0-alpha2 working with a patch but once I upgraded to 2.0.0-beta-2
(which fixed the problem I needed to patch) the bridge completely breaks as
long as the app includes the trinidad libs. There seems to be some
incompatibilities between the Trinidad extensions and the bridge's. Did get
a chance to track down the specific details but wanted to get the issue
logged as its likely to be identified much faster by someone in the Trinidad
team.
To reproduce -- get the bridge-3.0.0-alpha and set up a project pointing to
the 3.0.0 TCK. Follow the instructions in the TCK User Manual for building
it, configuring it on Apache, and then running it. With the Trinidad jars in
the deployment you will find that almost all the test fail (170) -- the few
that pass don't actually execute Faces. If you remove the jars (and I think
drop the other Trinidad refs in the web.xml) things run fine except for those
few tests that depend on Trindiad (failed tests shoudl be something like 37).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (PORTLETBRIDGE-214) BridgeImpl incorrectly cleans up after exceptions; retains contexts

2011-06-16 Thread Michael Freedman (JIRA)


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-214.


   Resolution: Fixed
Fix Version/s: 2.0.1

The NPE is likley caused because of failure during the acquisition of the 
FacesContext -- hence its not established/remains null.   Changed code to use 
PortletConfig to log which is always around.  In addition I noticed this and 
some other conditional logging checks were logging only if logging was 
disabled.  Switched this to ensure they get logged only if logging is enabled. 

 BridgeImpl incorrectly cleans up after exceptions; retains contexts
 ---

 Key: PORTLETBRIDGE-214
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-214
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0
Reporter: Scott Oaks
Assignee: Michael Freedman
 Fix For: 2.0.1

 Attachments: stack.txt


 The exception handling of BridgeImpl.doFacesRequest() is incorrect, which 
 leads to contexts not being released after an exception.
 When an exception is thrown to the doFacesRequest() method, it ends up in 
 this code:
 try {
 ...
 } catch (Exception e) {
...
context.getExternalContext().log(Exception thrown in 
 doFacesRequest:resource, e);   // line 1168
   ...
 } finally {
   ...
   context.release();
   ...
 }
 The first problem is that whatever error is getting thrown to us is lost 
 because line 1168 is generated a NullPointerException from 
 context.getExternalContext().log(). So that NPE gets thrown from the 
 exception block and the original, actual root-cause, exception is lost.
 The reason that this code fails is that context.getExternalContext() returns 
 null -- the processing has been redirected, and this context has already been 
 released in redirectRender(). Which leads to the much more serious issue -- 
 the new context established by redirectRender() is never released in the 
 exception handling: the context.release() call in the finally block of 
 doFacesRequest() is the original, already released context. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (PORTLETBRIDGE-215) EncodeResource url improperly recognizes non context path encoded urls beginning with / as being an internal url

2011-06-14 Thread Michael Freedman (JIRA)

EncodeResource url improperly recognizes non context path encoded  urls 
beginning with / as being an internal url
-

 Key: PORTLETBRIDGE-215
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-215
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
Reporter: Michael Freedman
Assignee: Michael Freedman


If you have an url that is passed to encodeResourceUrl which begins 
/foo/bar.jpg  where /foo isn't this applications context-path, the bridge 
recognizes this url as a internal app url and prefixs it with the context-path. 
 However, because JSF doesn't do auto-context path appending the above url is 
invalid in regular (serlvet) JSF as its neither relative to the current page 
nor the current server.  Hence all resource urls that begin with / should be 
seen as external urls -- i.e. assumed to be urls that are full path (including 
the context-path) to another application in this server.

As ADF's GoLink uses encodeActionUrl for its targets -- we should also review 
and consider correct behavior there as well.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (PORTLETBRIDGE-215) EncodeResource url improperly recognizes non context path encoded urls beginning with / as being an internal url

2011-06-14 Thread Michael Freedman (JIRA)

[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13049414#comment-13049414
]

Michael Freedman commented on PORTLETBRIDGE-215:

Looks like ADF does the right thing and ensures anything starting with a / is
transformed to a context path relative url via Viewhandler.getResourceURL().
I.e. GoLink impls that by the time encodeActionURL is called anything starting
with a / is context path encoded -- whether this context path or another on the
server. So logically the bridge's encodeActionURL should check any url that
begins with / and make sure its in this apps context path, if it is not then it
should turn the url into an absolute url and return it. Fix this as well.

EncodeResource url improperly recognizes non context path encoded urls
beginning with / as being an internal url
-

Key: PORTLETBRIDGE-215
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-215
Project: MyFaces Portlet Bridge
Issue Type: Bug
Reporter: Michael Freedman
Assignee: Michael Freedman

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (PORTLETBRIDGE-214) BridgeImpl incorrectly cleans up after exceptions; retains contexts

2011-06-10 Thread Michael Freedman (JIRA)


[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13047344#comment-13047344
 ] 

Michael Freedman commented on PORTLETBRIDGE-214:


Okay -- looked at the code.  I understand what you have said but don't 
understand how we got in this situation as a redirect during a resource request 
is a noop (in a portlet/bridge environment).  Is there any chance you can set a 
breakpoint in the bridge's FacesContext.release() and send me the stack so I 
can understand/work backwards in terms of why the context has been prematurely 
released ... Note:  if you look at the corresponding doFacesRequest code for 
render requests -- you will see it does reacquire the FacesContext in the 
exception clause as it does expect a render redirect to occur.

I.e. the issue here seems to be an unexpected premature release of the 
facesContext in a resource request.  Can you help me dig/determine why this is 
happening?

 BridgeImpl incorrectly cleans up after exceptions; retains contexts
 ---

 Key: PORTLETBRIDGE-214
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-214
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0
Reporter: Scott Oaks
Assignee: Michael Freedman
 Attachments: stack.txt


 The exception handling of BridgeImpl.doFacesRequest() is incorrect, which 
 leads to contexts not being released after an exception.
 When an exception is thrown to the doFacesRequest() method, it ends up in 
 this code:
 try {
 ...
 } catch (Exception e) {
...
context.getExternalContext().log(Exception thrown in 
 doFacesRequest:resource, e);   // line 1168
   ...
 } finally {
   ...
   context.release();
   ...
 }
 The first problem is that whatever error is getting thrown to us is lost 
 because line 1168 is generated a NullPointerException from 
 context.getExternalContext().log(). So that NPE gets thrown from the 
 exception block and the original, actual root-cause, exception is lost.
 The reason that this code fails is that context.getExternalContext() returns 
 null -- the processing has been redirected, and this context has already been 
 released in redirectRender(). Which leads to the much more serious issue -- 
 the new context established by redirectRender() is never released in the 
 exception handling: the context.release() call in the finally block of 
 doFacesRequest() is the original, already released context. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] [Commented] (PORTLETBRIDGE-214) BridgeImpl incorrectly cleans up after exceptions; retains contexts

2011-06-10 Thread Michael Freedman

 You are the Scott Oaks at Oracle, right?  If so, let's continue the 
conversation/debugging directly for the moment until we get more 
detail.  I can create a patched jar for you that will log the exception 
instead of throwing the fault -- but unfortunately I am not back in the 
office until Tuesday.  If you want to get to this sooner, build off the 
2.0.0 trunk (its on a branch now) -- merely change the offending line to 
use the local data member referencing the portletContext.  There should 
either be a data member mPortletContext or mPortletConfig (I don't have 
access to the code at the moment).  If mPortletContext use 
mPortletContext.log if mPortletConfig use 
mPortletConfig.getPortletContext().log.  This is all I will do you 
anyway ...

-Mike-

On 6/10/2011 12:46 PM, Scott Oaks (JIRA) wrote:

 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13047398#comment-13047398
 ]

Scott Oaks commented on PORTLETBRIDGE-214:
--

Unfortunately, the testbed in question is production-mode; it is a little hard 
to get access. I will see what we can do -- if there is something we can catch 
after the fact it works better (e.g. I expect that lots of things call 
FacesContext.release() so we can't just generally try and trace that; the bug 
may happen once a day on a moderately-used server). If we knew the underlying 
exception that triggered the bug, it would likely help, so maybe as a first 
step we can just fix the NPE issue in the exception handler and see what 
information that gets us as to what triggers the release.

I do see that the doFacesRequest(RenderRequest request, RenderResponse 
response) reacquires the context in the exception clause (where 
doFacesRequest(ResourceRequest... doesn't). So I guess you are saying that the 
premature release in this case didn't come from the renderRedirect() method as 
I thought it must have, because that would have been a different entry point? 
That is certainly possible; I should have made clear that I was just looking 
for possible explanations at that point, and that seemed a likely one to me, 
though I don't have an understanding of what is actually going on.


BridgeImpl incorrectly cleans up after exceptions; retains contexts
---

 Key: PORTLETBRIDGE-214
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-214
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0
Reporter: Scott Oaks
Assignee: Michael Freedman
 Attachments: stack.txt


The exception handling of BridgeImpl.doFacesRequest() is incorrect, which leads 
to contexts not being released after an exception.
When an exception is thrown to the doFacesRequest() method, it ends up in this 
code:
try {
 ...
} catch (Exception e) {
...
context.getExternalContext().log(Exception thrown in 
doFacesRequest:resource, e);   // line 1168
   ...
} finally {
   ...
   context.release();
   ...
}
The first problem is that whatever error is getting thrown to us is lost 
because line 1168 is generated a NullPointerException from 
context.getExternalContext().log(). So that NPE gets thrown from the exception 
block and the original, actual root-cause, exception is lost.
The reason that this code fails is that context.getExternalContext() returns 
null -- the processing has been redirected, and this context has already been 
released in redirectRender(). Which leads to the much more serious issue -- the 
new context established by redirectRender() is never released in the exception 
handling: the context.release() call in the finally block of doFacesRequest() 
is the original, already released context.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (PORTLETBRIDGE-99) RequestScopeListener not Serializable


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-99.
---

Resolution: Fixed

Fix was to make the RequestScopeListener a non inner class -- thus when its 
serialized itsw outer class isn't.

 RequestScopeListener not Serializable
 -

 Key: PORTLETBRIDGE-99
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-99
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0-beta
 Environment: eXo PC 2.0.5 under JBoss AS 4.2.3, using both MyFaces 
 1.2.7 and JBoss embebed Mojarra
Reporter: Fernando Silva Lozano
Assignee: Michael Freedman
 Fix For: 1.0.1, 2.0.1, 3.0.0-alpha


 I get lots of erros on JBoss AS log such as:
 13:51:03,110 ERROR [STDERR] java.lang.IllegalArgumentException: 
 java.io.NotSerializableException: 
 org.apache.myfaces.portlet.faces.bridge.BridgeImpl$RequestScopeListener
 13:51:03,110 ERROR [STDERR]   at 
 org.jgroups.Message.setObject(Message.java:281)
 13:51:03,110 ERROR [STDERR]   at org.jgroups.Message.init(Message.java:141)
 13:51:03,110 ERROR [STDERR]   at 
 org.exoplatform.frameworks.portletcontainer.portalframework.replication.SessionReplicator.send(SessionReplicator.java:103)
 13:51:03,110 ERROR [STDERR]   at 
 org.exoplatform.frameworks.portletcontainer.portalframework.filters.PortalFrameworkFilter.doFilter(PortalFrameworkFilter.java:114)
 13:51:03,110 ERROR [STDERR]   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 13:51:03,111 ERROR [STDERR]   at 
 org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
 13:51:03,111 ERROR [STDERR]   at 
 org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
 13:51:03,111 ERROR [STDERR]   at 
 org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 13:51:03,111 ERROR [STDERR]   at 
 org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
 13:51:03,112 ERROR [STDERR]   at java.lang.Thread.run(Thread.java:595)
 I think it is self-explanatory: every object stored on the user HTTP session 
 should be serializable, and one of the objects put there by the bridge (an 
 inner class of BridgeImpl) isn't.
 I rated as Major because I suppose this will prevent my JSF portlet to work 
 correctly in a clustered container.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (PORTLETBRIDGE-213) Portlet 2.0 Bridge: FacesMessages not updated in bridge scope if empty


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-213.


   Resolution: Fixed
Fix Version/s: 3.0.0-alpha
   2.0.1

cached messages no longer saved if current request didn't generate any.

 Portlet 2.0 Bridge:  FacesMessages not updated in bridge scope if empty
 ---

 Key: PORTLETBRIDGE-213
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-213
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0, 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 2.0.1, 3.0.0-alpha


 The Bridge manages FacesMessages in its scope (so Messages generated during 
 an action are carried forward to the render).  Unfortunately its impl of 
 saveFacesMessageState only writes the FacesMessages data structure into the 
 scope if there are messages in the current FacesContext.  Because the 
 resource code copies forward (merges) all scope attributes that aren't there 
 at the end of the resource request, we are inadvertently copying forward the 
 old set of FacesMessages (rather then the new empty set).  Fix is to always 
 put the FacesMessages data structure into the scope even if its empty. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (PORTLETBRIDGE-204) Bridge doesn't work with Mojarra 2.0.4b09


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-204.


   Resolution: Fixed
Fix Version/s: 3.0.0-alpha

Bridge no longer caches the UIViewRoot between and action and render.  Rather 
it saves and restores across the requests.

 Bridge doesn't work with Mojarra 2.0.4b09
 -

 Key: PORTLETBRIDGE-204
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-204
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 3.0.0-alpha


 Bridge doesn't work with the latest released Mojarra. Problem again is 
 related to us slamming the UIViewRoot across the action/render without a full 
 save/restore -- this time the UIViewRoot has old listeners hanging off its 
 atts.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (PORTLETBRIDGE-190) New Bridge 3.0 files missing Apache License headers


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-190.


   Resolution: Fixed
Fix Version/s: 3.0.0-alpha

Added headers

 New Bridge 3.0 files missing Apache License headers
 ---

 Key: PORTLETBRIDGE-190
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-190
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: General
Affects Versions: 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 3.0.0-alpha


 Most of the new files added to the Bridge as part of upgrading for JSF 2.0 
 support are missing their requires Apache license/copyright statements.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (PORTLETBRIDGE-213) Portlet 2.0 Bridge: FacesMessages not updated in bridge scope if empty

2011-06-03 Thread Michael Freedman (JIRA)

Portlet 2.0 Bridge:  FacesMessages not updated in bridge scope if empty
---

 Key: PORTLETBRIDGE-213
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-213
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0, 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman


The Bridge manages FacesMessages in its scope (so Messages generated during an 
action are carried forward to the render).  Unfortunately its impl of 
saveFacesMessageState only writes the FacesMessages data structure into the 
scope if there are messages in the current FacesContext.  Because the resource 
code copies forward (merges) all scope attributes that aren't there at the end 
of the resource request, we are inadvertently copying forward the old set of 
FacesMessages (rather then the new empty set).  Fix is to always put the 
FacesMessages data structure into the scope even if its empty. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TRINIDAD-2105) DocumentRenderer.encodeAll must not assume root StateManager is Trinidad's

2011-05-26 Thread Michael Freedman (JIRA)

DocumentRenderer.encodeAll must not assume root StateManager is Trinidad's
--

 Key: TRINIDAD-2105
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2105
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Portlet
Affects Versions: 2.0.0
Reporter: Michael Freedman


DocumentRenderer.encodeAll has the following code:

StateManager sm = context.getApplication().getStateManager();

if (sm instanceof StateManagerImpl)
{
  // do real work
}
else
{
// log error and return
}

This means Trinidad fails in an environment in which its wrapped -- such as the 
Portlet Bridge -- even though its StateManager is in use.  Instead the code 
should test for whether its StateManagerImpl and if not recursively test to see 
if its a StateManagerWrapper.  For each wrapper it finds it calls .getWrapped 
and runs the test again.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (PORTLETBRIDGE-192) Proposal for 3.0 API: javax.portlet.faces.context.BridgeContext and associated BridgeContextFactory

2011-05-09 Thread Michael Freedman (JIRA)


[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030805#comment-13030805
 ] 

Michael Freedman commented on PORTLETBRIDGE-192:


Alexandr -- it looks like you are commenting on Neil's APIs as the above 
doesn't fully describe the set of APIs I have proposed/started to put into use. 
 Could you repost comments pertaining to the APIs that are in the refactored 
code?

As to your points:
1) PortletContext, Request/Response are included in the API because there is a 
short period of time between when the controller is invoked (with a 
BridgeContext) and when it acquires a FacesContext (and if a nonFaces resource 
it never acquires one).  These APIs allow the controller access to these 
portlet objects before they are exposed in Faces.

2) Do we really need another threadlocal (and what do we gain by having one)?  
95%+ of the time we will need to acquire the BridgeContext we will either have 
or also need to acquire the FacesContext.  I had been planning on adding the 
BridgeContext to the FacesContext scope and let extensions/etc. access it there 
as needed.  The only real thing running outside the FacesContext is the 
controller which is passed the BridgeContext explicitly.

3) default viewId's and PortletConfig are in the BridgeConfig

4) Whether or not we have setter methods to allow for object initialization 
(somewhat) depends on the APIs you come up with for the factories.  If the 
factories cleanly allow for this type of object initialization and allows us to 
easily extend add new initialization 'attributes in the future then you are 
right there is no need to have the set methods.  I included them so as we have 
to support new features in Faces that require additional config/context -- it 
is easy to add a get/set method and have the code using the factory updated to 
do the additional initialization call.

 Proposal for 3.0 API: javax.portlet.faces.context.BridgeContext and 
 associated BridgeContextFactory
 ---

 Key: PORTLETBRIDGE-192
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-192
 Project: MyFaces Portlet Bridge
  Issue Type: New Feature
  Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman

 This class contains contextual information related to the bridge. It is 
 inherently request scoped, and is useful for sharing data between 
 implementations of Bridge.java and ExternalContext.java
 Please refer to the following classes for this proposal: 
 http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/context/BridgeContext.java
 http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/context/BridgeContextFactory.java

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Reopened] (PORTLETBRIDGE-99) RequestScopeListener not Serializable

2011-05-05 Thread Michael Freedman (JIRA)


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman reopened PORTLETBRIDGE-99:
---


Turns out my fix doesn't work because the RequestScopeListener isn't  a static 
inner class and hence auto-causes the containing class to be serialized along 
with it and the BridgeImpl (which is the containing class contains objects that 
can't be serialized.

Easiest/best short term solution is to make the RequestScopeListener a static 
inner class and to pass the BridgeImpl object to it.

 RequestScopeListener not Serializable
 -

 Key: PORTLETBRIDGE-99
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-99
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0-beta
 Environment: eXo PC 2.0.5 under JBoss AS 4.2.3, using both MyFaces 
 1.2.7 and JBoss embebed Mojarra
Reporter: Fernando Silva Lozano
Assignee: Michael Freedman
 Fix For: 1.0.1, 2.0.1, 3.0.0-alpha


 I get lots of erros on JBoss AS log such as:
 13:51:03,110 ERROR [STDERR] java.lang.IllegalArgumentException: 
 java.io.NotSerializableException: 
 org.apache.myfaces.portlet.faces.bridge.BridgeImpl$RequestScopeListener
 13:51:03,110 ERROR [STDERR]   at 
 org.jgroups.Message.setObject(Message.java:281)
 13:51:03,110 ERROR [STDERR]   at org.jgroups.Message.init(Message.java:141)
 13:51:03,110 ERROR [STDERR]   at 
 org.exoplatform.frameworks.portletcontainer.portalframework.replication.SessionReplicator.send(SessionReplicator.java:103)
 13:51:03,110 ERROR [STDERR]   at 
 org.exoplatform.frameworks.portletcontainer.portalframework.filters.PortalFrameworkFilter.doFilter(PortalFrameworkFilter.java:114)
 13:51:03,110 ERROR [STDERR]   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 13:51:03,111 ERROR [STDERR]   at 
 org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
 13:51:03,111 ERROR [STDERR]   at 
 org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
 13:51:03,111 ERROR [STDERR]   at 
 org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 13:51:03,111 ERROR [STDERR]   at 
 org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
 13:51:03,112 ERROR [STDERR]   at java.lang.Thread.run(Thread.java:595)
 I think it is self-explanatory: every object stored on the user HTTP session 
 should be serializable, and one of the objects put there by the bridge (an 
 inner class of BridgeImpl) isn't.
 I rated as Major because I suppose this will prevent my JSF portlet to work 
 correctly in a clustered container.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ANNOUNCE] Release of Apache MyFaces Portlet Bridge 3.0.0-alpha (Portlet Bridge for JSF 2.0)

2011-04-07 Thread Michael Freedman

The Apache MyFaces Portlet Bridge team is pleased to announce the 
release of Apache MyFaces Portlet Bridge 3.0.0-alpha.  This is the first 
release of the MyFaces Portlet Bridge supporting JSF 2.0 (and 2.1).  
Besides doing the obvious upgrades to run within the updated JSF 2.0 
APIs, the bridge provides enhanced function from the the JSR 329 bridge 
(bridge-2.0.0).  It supports JSF 2.0 features such as ajax and composite 
components.


At the moment this implementation is being provided outside the JSR 
process.  Because of the delay caused by the work to complete JSR 301 
and 329 it was felt that it was better to deliver a functional JSF 2.0 
portlet bridge as quickly as possible to the community before looking at 
starting a new standards effort.


Use of this version of the bridge is the same as the JSR 329 bridge 
(portlet-bridge-2.0.0).  In fact, it uses the JSR 329 APIs unchanged.


Apache MyFaces Portlet Bridge 3.0.0-alpha is available in both binary 
and source distributions:


* http://myfaces.apache.org/portlet-bridge/3.0/downloads.html

Apache MyFaces Portlet Bridge is available in the central Maven 
repository under Group ID org.apache.myfaces.portlet-bridge.


Release Notes: 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310733version=12316085 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310733version=12316085



Enjoy!

Michael Freedman

Re: [VOTE] release for myfaces core 2.0.5

2011-04-06 Thread Michael Freedman

FYI ... I will verify that there there are no bridge issues with  this 
version today and cast my vote.

   -Mike-

On 4/6/2011 1:02 AM, Werner Punz wrote:

+1

Am 05.04.11 08:02, schrieb Leonardo Uribe:

Hi,

I was running the needed tasks to get the 2.0.5 release of Apache
MyFaces core out.

The artifacts passed all TCK tests.

Please note that this vote concerns all of the following parts:
  1. Maven artifact group org.apache.myfaces.shared v4.0.6  [1]
  2. Maven artifact group org.apache.myfaces.core v2.0.5  [1]

The artifacts were deployed on nexus repo [1] and to my private
Apache account [3] for binary and source packages.

The release notes could be found at [4].

Also the clirr test does not show binary incompatibilities with 
myfaces-api.


Please take a look at the 2.0.5 artifacts and vote!

Please note: This vote is majority approval with a minimum of three
+1 votes (see [3]).


[ ] +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,
Leonardo Uribe

[1]
https://repository.apache.org/content/repositories/orgapachemyfaces-044/org/apache/myfaces/ 


[2] http://www.apache.org/foundation/voting.html#ReleaseVotes
[3] http://people.apache.org/~lu4242/myfaces205binsrc
[4]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316346 

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316346

[jira] [Commented] (PORTLETBRIDGE-206) Proposal for 3.0 API: New constant Bridge.BRIDGE_CONTEXT_ATTRIBUTE

2011-04-06 Thread Michael Freedman (JIRA)


[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13016452#comment-13016452
 ] 

Michael Freedman commented on PORTLETBRIDGE-206:


For the time being this can't/won't go in Bridge.java.  Rather it will be part 
of the org.apache.myfaces.portlet.faces.bridge package.  Probably in 
Constants.java.

 Proposal for 3.0 API: New constant Bridge.BRIDGE_CONTEXT_ATTRIBUTE
 --

 Key: PORTLETBRIDGE-206
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-206
 Project: MyFaces Portlet Bridge
  Issue Type: New Feature
  Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman

 Proposal is to add the following constant to Bridge.java:
   public static final String BRIDGE_CONTEXT_ATTRIBUTE = 
 javax.portlet.faces.bridgeContext;
 And to require implementations of the Bridge interface to set this attribute 
 in each of the doFacesRequest(...) methods.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (PORTLETBRIDGE-203) Proposal for 3.0 IMPL: Preserve and restore JSF2 FacesContext attributes in BridgeRequestScope

2011-04-06 Thread Michael Freedman (JIRA)


[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13016463#comment-13016463
 ] 

Michael Freedman commented on PORTLETBRIDGE-203:


I have found that the 329/301 bridge methodology of caching the UIViewRoot and 
releasing the FacesContext at the end of the action and then getting the render 
to use the cached UIViewRoot in a new FacesContext will not work consistently  
in JSF 3.0.  Each release of Mojarra or Myfaces I get changes the issue I ran 
into -- yes first it was just the need to carry some of the FacesContext 
attributes forward -- but now there are issues with attributes stored on the 
UiViewRoot itself that have been released underneath these references in the 
prior facesContext.release.  

So I think the bridge is going to have to change to explicitly save and restore 
the view across the action/render -- at which point we won't need to 
preserve/restore the JSF2 FacesContext attrs anymore.

 Proposal for 3.0 IMPL: Preserve and restore JSF2 FacesContext attributes in 
 BridgeRequestScope
 --

 Key: PORTLETBRIDGE-203
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-203
 Project: MyFaces Portlet Bridge
  Issue Type: New Feature
  Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman

 The JSF 2.0 API introduced a getAttributes() method on FacesContext:
 http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/FacesContext.html#getAttributes()
 These values need to be preserved in the BridgeRequestScope. For more 
 information on implementation details, search for 
 BRIDGE_REQ_SCOPE_ATTR_FACES_CONTEXT_ATTRIBUTES in the following Java class:
 http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-impl/trunk/src/main/java/org/portletfaces/bridge/scope/BridgeRequestScopeImpl.java

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] release for myfaces core 2.0.5

2011-04-06 Thread Michael Freedman


+1
The bridge is running with this version.
-Mike-

On 4/6/2011 9:59 AM, Michael Freedman wrote:
FYI ... I will verify that there there are no bridge issues with  this 
version today and cast my vote.

   -Mike-

On 4/6/2011 1:02 AM, Werner Punz wrote:

+1

Am 05.04.11 08:02, schrieb Leonardo Uribe:

Hi,

I was running the needed tasks to get the 2.0.5 release of Apache
MyFaces core out.

The artifacts passed all TCK tests.

Please note that this vote concerns all of the following parts:
  1. Maven artifact group org.apache.myfaces.shared v4.0.6  [1]
  2. Maven artifact group org.apache.myfaces.core v2.0.5  [1]

The artifacts were deployed on nexus repo [1] and to my private
Apache account [3] for binary and source packages.

The release notes could be found at [4].

Also the clirr test does not show binary incompatibilities with 
myfaces-api.


Please take a look at the 2.0.5 artifacts and vote!

Please note: This vote is majority approval with a minimum of three
+1 votes (see [3]).


[ ] +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,
Leonardo Uribe

[1]
https://repository.apache.org/content/repositories/orgapachemyfaces-044/org/apache/myfaces/ 


[2] http://www.apache.org/foundation/voting.html#ReleaseVotes
[3] http://people.apache.org/~lu4242/myfaces205binsrc
[4]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316346 

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316346

[RESULTS] Apache MyFaces Portlet Bridge 3.0.0-alpha

2011-04-06 Thread Michael Freedman


The vote for the release of Portlet Bridge 3.0.0-alpha was approved

+1:  Mike Freedman, Scott O'Bryan, Leonardo Uribe, Bernd Bohmann, Mark 
Struberg

+0: none
-1: none

Thanks to everyone who voted.
Michael Freedman

[1] http://www.mail-archive.com/dev@myfaces.apache.org/msg52226.html

[jira] [Created] (TRINIDAD-2083) Trinidad doesn't work with the 3.0.0 Portlet Bridge

2011-04-06 Thread Michael Freedman (JIRA)

Trinidad doesn't work with the 3.0.0 Portlet Bridge
---

 Key: TRINIDAD-2083
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2083
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Portlet
Affects Versions: 2.0.0-beta-2
Reporter: Michael Freedman


I got 2.0.0-alpha2 working with a patch but once I upgraded to 2.0.0-beta-2 
(which fixed the problem I needed to patch) the bridge completely breaks as 
long as the app includes the trinidad libs.  There seems to be some 
incompatibilities between the Trinidad extensions and the bridge's.  Did get a 
chance to track down the specific details but wanted to get the issue logged as 
its likely to be identified much faster by someone in the Trinidad team.

To reproduce -- get the bridge-3.0.0-alpha and set up a project pointing to the 
3.0.0 TCK.  Follow the instructions in the TCK User Manual for building it, 
configuring it on Apache, and then running it.  With the Trinidad jars in the 
deployment you will find that almost all the test fail (170) -- the few that 
pass don't actually execute Faces.  If you remove the jars (and I think drop 
the other Trinidad refs in the web.xml) things run fine except for those few 
tests that depend on Trindiad (failed tests shoudl be something like 37).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] [Updated] (PORTLETBRIDGE-205) Proposal for 3.0 API: Deprecate constant Bridge.PORTLET_LIFECYCLE_PHASE and refactor BridgeUtil methods accordingly

2011-04-05 Thread Michael Freedman


Neil,
   Is it possible to clearly separate in the jira system proposals that 
change the Bridge spec (api) from one's that don't?  I.e. -- first step 
of this bridge work is to reimplement the internals to make it more 
open/extensible without impacting the JSR 329 APIs.  I.e. I neither want 
to run a foul of the JCP nor want to start a JSR yet.  Once this is done 
and you guys are either consuming it or otherwise show that you pass the 
expected portions of the JSR 329 TCK we can move forward with a new JSR 
where we can address updating the API and deprecating parts that are no 
longer needed.  Sound reasonable?

-Mike-

On 3/31/2011 3:23 PM, Neil Griffin (JIRA) wrote:

  [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Neil Griffin updated PORTLETBRIDGE-205:
---

 Description:
Proposal is to do this in Bridge.java:

/** @deprecated replaced by {@link Bridge#BRIDGE_CONTEXT_ATTRIBUTE} and 
{@link BridgeContext#getPortletLifecyclePhase()} */
@Deprecated public static final String PORTLET_LIFECYCLE_PHASE = 
javax.portlet.faces.phase;

And to refactor BridgeUtil.getPortletRequestPhase() to something like this:

public static Bridge.PortletPhase getPortletRequestPhase() {

Bridge.PortletPhase portletRequestPhase = null;
FacesContext facesContext = FacesContext.getCurrentInstance();
BridgeContext bridgeContext = (BridgeContext) 
facesContext.getAttributes().get(Bridge.BRIDGE_CONTEXT_ATTRIBUTE);

if (bridgeContext != null) {
portletRequestPhase = 
bridgeContext.getPortletRequestPhase();
}

return portletRequestPhase;
}

And refactor BridgeUtil.isPortletRequest() to something like this:

public static boolean isPortletRequest() {
FacesContext facesContext = FacesContext.getCurrentInstance();
BridgeContext bridgeContext = (BridgeContext) 
facesContext.getAttributes().get(Bridge.BRIDGE_CONTEXT_ATTRIBUTE);

return (bridgeContext != null);
}


   was:
Proposal is to do this in Bridge.java:

/** @deprecated replaced by {@link Bridge#BRIDGE_CONTEXT_ATTRIBUTE} and 
{@link BridgeContext#getPortletLifecyclePhase()} */
@Deprecated public static final String PORTLET_LIFECYCLE_PHASE = 
javax.portlet.faces.phase;

And to refactor BridgeUtil.getPortletRequestPhase() to something like this:

public static Bridge.PortletPhase getPortletRequestPhase() {

Bridge.PortletPhase portletRequestPhase = null;
FacesContext facesContext = FacesContext.getCurrentInstance();
ExternalContext externalContext = 
facesContext.getExternalContext();
MapString, Object  requestMap = 
externalContext.getRequestMap();

BridgeContext bridgeContext = (BridgeContext) 
requestMap.get(Bridge.BRIDGE_CONTEXT_ATTRIBUTE);

if (bridgeContext != null) {
portletRequestPhase = 
bridgeContext.getPortletRequestPhase();
}

return portletRequestPhase;
}

And refactor BridgeUtil.isPortletRequest() to something like this:

public static boolean isPortletRequest() {
FacesContext facesContext = FacesContext.getCurrentInstance();
ExternalContext externalContext = 
facesContext.getExternalContext();
MapString, Object  requestMap = 
externalContext.getRequestMap();
BridgeContext bridgeContext = (BridgeContext) 
requestMap.get(Bridge.BRIDGE_CONTEXT_ATTRIBUTE);

return (bridgeContext != null);
}




Proposal for 3.0 API: Deprecate constant Bridge.PORTLET_LIFECYCLE_PHASE and 
refactor BridgeUtil methods accordingly
---

 Key: PORTLETBRIDGE-205
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-205
 Project: MyFaces Portlet Bridge
  Issue Type: New Feature
  Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman

Proposal is to do this in Bridge.java:
/** @deprecated replaced by {@link Bridge#BRIDGE_CONTEXT_ATTRIBUTE} and 
{@link BridgeContext#getPortletLifecyclePhase()} */
@Deprecated public static final String PORTLET_LIFECYCLE_PHASE = 
javax.portlet.faces.phase;
And to refactor BridgeUtil.getPortletRequestPhase() to something like this:
public static Bridge.PortletPhase getPortletRequestPhase() {
Bridge.PortletPhase portletRequestPhase = null;
FacesContext facesContext = FacesContext.getCurrentInstance();
BridgeContext bridgeContext

Re: [Trinidad] Release schedule

2011-04-05 Thread Michael Freedman

I would like to see it working with the 3.0.0 bridge before you do the 
next release.  It seems to have taken a step backwards (with respect to 
the bridge) since its previous release(s).

-Mike-

On 4/5/2011 5:12 AM, Scott O'Bryan wrote:

That was kind of my thinking as well.

Sent from my iPhone

On Apr 4, 2011, at 8:08 PM, Andrew Robinson 
andrew.rw.robin...@gmail.com mailto:andrew.rw.robin...@gmail.com 
wrote:


I don't see that 2.0 is any less stable 1.2 at this point. I think we 
can probably remove the beta soon IMO.


On Fri, Apr 1, 2011 at 11:02 AM, Scott O'Bryan darkar...@gmail.com 
mailto:darkar...@gmail.com wrote:


Hey all,

I think  we're getting close to another release for Trinidad and
I wanted to open up a discussion on how you think we're looking
for a non-beta release.

I know there is currently a lot of work on the trinidad code line
right now so I was going to hold off on a release for another
couple of weeks and I was hoping that, at that time, the Trinidad
2.0 code would be ready to move out of beta.

If people still don't think it's ready, I can do another beta
release after I check in some of the submitted patches but I
think we're getting pretty close.

Any opinions?

Thanks,
 Scott O'Bryan

Re: [RE-RE-VOTE] Release MyFaces Portlet Bridge 3.0.0

2011-04-01 Thread Michael Freedman

 Sorry to push on this but I would like to release this before I leave 
on vacation next week.So please review and vote asap as I plan to 
close the vote Monday.

-Mike-

On 3/30/2011 11:23 AM, Michael Freedman wrote:

Please vote:

Bridge has been rebuilt/posted and now runs with either the latest 
Mojarra release (2.0.4.b09) or MyFaces Snapshot (2.0.5).  Rebuilt 
artifacts have been verified and tested and pass to the same degree as 
prior post in this sequence.  Refer to information in message below 
regarding this release and location of distributable 
components/artifacts (changes have been made to reflect current build).


As this is a re-vote -- please do so asap as I will be (hopefully) 
closing the vote by the end of this week so we can (finally) get this 
release out.


Please vote on the proposed release of MyFaces Portlet Bridge
3.0.0-alpha.  This is the alpha version of the Portlet Bridge for JSF
2.0.  It includes all the base function of JSR329 updated to run in a
JSF 2.0 environment.  Some, though not all JSF 2.0 features are
expressed/utilized.  Most significant is Ajax support and Composite
Component support.  Note:  this version of the bridge will not work
with any currently released versions of MyFaces (try Trunk).

Distributable components can be inspected in
http://people.apache.org/~mfreedman/portlet-bridge/3.0.0-alpha

Repository artifacts are at:
https://repository.apache.org/content/repositories/orgapachemyfaces-054


I have verified that the distributable jars run and pass the updated
version of the JSR 329 TCK.  In addition I have verified that the
distributable examples run (on apache tomcat/pluto).


[ ] +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,
   -Mike-


On 3/22/2011 1:17 PM, Michael Freedman wrote:
Files without necessary license statements have been updated.  Rat 
now reports no problems.  Refer to information in message below 
regarding this release and location of distributable 
components/artifacts (changes have been made to reflect current build).


As this is a re-vote -- please do so asap as I will be (hopefully) 
closing the vote by the end of this week so we can get this release out.

 -Mike-

 Original Message 
Subject:[VOTE] Release MyFaces Portlet Bridge 3.0.0
Date:   Wed, 09 Mar 2011 15:52:54 -0800
From:   Michael Freedman michael.freed...@oracle.com
Reply-To:   MyFaces Development dev@myfaces.apache.org
Organization:   Oracle Corporation
To: myfaces Development dev@myfaces.apache.org



Please vote on the proposed release of MyFaces Portlet Bridge
3.0.0-alpha.  This is the alpha version of the Portlet Bridge for JSF
2.0.  It includes all the base function of JSR329 updated to run in a
JSF 2.0 environment.  Some, though not all JSF 2.0 features are
expressed/utilized.  Most significant is Ajax support and Composite
Component suppport.  Note:  this version of the bridge will not work
with any currently released versions of MyFaces (try Trunk) and only
mostly runs on released version of Mojarra (patches available).
Likewise a patched version of Trinidad is needed to run the TCK (for
those tests that depend on Trinidad).

Distributable components can be inspected in
http://people.apache.org/~mfreedman/portlet-bridge/3.0.0-alpha

Repository artifacts are at:
https://repository.apache.org/content/repositories/orgapachemyfaces-022/


I have verified that the distributable jars run and pass the updated
version of the JSR 329 TCK.  In addition I have verified that the
distributable examples run (on apache tomcat/pluto).


[ ] +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,
   -Mike-

[jira] [Commented] (PORTLETBRIDGE-206) Proposal for 3.0 API: New constant Bridge.BRIDGE_CONTEXT_ATTRIBUTE


[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13013012#comment-13013012
 ] 

Michael Freedman commented on PORTLETBRIDGE-206:


Yes, we will need to add such a new constant -- and I was thinking we will have 
the Bridge set this on the FacesContext prior to executing the lifecycle.

 Proposal for 3.0 API: New constant Bridge.BRIDGE_CONTEXT_ATTRIBUTE
 --

 Key: PORTLETBRIDGE-206
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-206
 Project: MyFaces Portlet Bridge
  Issue Type: New Feature
  Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman

 Proposal is to add the following constant to Bridge.java:
   public static final String BRIDGE_CONTEXT_ATTRIBUTE = 
 javax.portlet.faces.bridgeContext;
 And to require implementations of the Bridge interface to set this attribute 
 in each of the doFacesRequest(...) methods.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (PORTLETBRIDGE-206) Proposal for 3.0 API: New constant Bridge.BRIDGE_CONTEXT_ATTRIBUTE


[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13013529#comment-13013529
 ] 

Michael Freedman commented on PORTLETBRIDGE-206:


Yep.

 Proposal for 3.0 API: New constant Bridge.BRIDGE_CONTEXT_ATTRIBUTE
 --

 Key: PORTLETBRIDGE-206
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-206
 Project: MyFaces Portlet Bridge
  Issue Type: New Feature
  Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman

 Proposal is to add the following constant to Bridge.java:
   public static final String BRIDGE_CONTEXT_ATTRIBUTE = 
 javax.portlet.faces.bridgeContext;
 And to require implementations of the Bridge interface to set this attribute 
 in each of the doFacesRequest(...) methods.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[RE-RE-VOTE] Release MyFaces Portlet Bridge 3.0.0

2011-03-30 Thread Michael Freedman


Please vote:

Bridge has been rebuilt/posted and now runs with either the latest 
Mojarra release (2.0.4.b09) or MyFaces Snapshot (2.0.5).  Rebuilt 
artifacts have been verified and tested and pass to the same degree as 
prior post in this sequence.  Refer to information in message below 
regarding this release and location of distributable 
components/artifacts (changes have been made to reflect current build).


As this is a re-vote -- please do so asap as I will be (hopefully) 
closing the vote by the end of this week so we can (finally) get this 
release out.


Please vote on the proposed release of MyFaces Portlet Bridge
3.0.0-alpha.  This is the alpha version of the Portlet Bridge for JSF
2.0.  It includes all the base function of JSR329 updated to run in a
JSF 2.0 environment.  Some, though not all JSF 2.0 features are
expressed/utilized.  Most significant is Ajax support and Composite
Component support.  Note:  this version of the bridge will not work
with any currently released versions of MyFaces (try Trunk).

Distributable components can be inspected in
http://people.apache.org/~mfreedman/portlet-bridge/3.0.0-alpha

Repository artifacts are at:
https://repository.apache.org/content/repositories/orgapachemyfaces-054


I have verified that the distributable jars run and pass the updated
version of the JSR 329 TCK.  In addition I have verified that the
distributable examples run (on apache tomcat/pluto).


[ ] +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,
  -Mike-



On 3/22/2011 1:17 PM, Michael Freedman wrote:
Files without necessary license statements have been updated.  Rat now 
reports no problems.  Refer to information in message below regarding 
this release and location of distributable components/artifacts 
(changes have been made to reflect current build).


As this is a re-vote -- please do so asap as I will be (hopefully) 
closing the vote by the end of this week so we can get this release out.

 -Mike-

 Original Message 
Subject:[VOTE] Release MyFaces Portlet Bridge 3.0.0
Date:   Wed, 09 Mar 2011 15:52:54 -0800
From:   Michael Freedman michael.freed...@oracle.com
Reply-To:   MyFaces Development dev@myfaces.apache.org
Organization:   Oracle Corporation
To: myfaces Development dev@myfaces.apache.org



Please vote on the proposed release of MyFaces Portlet Bridge
3.0.0-alpha.  This is the alpha version of the Portlet Bridge for JSF
2.0.  It includes all the base function of JSR329 updated to run in a
JSF 2.0 environment.  Some, though not all JSF 2.0 features are
expressed/utilized.  Most significant is Ajax support and Composite
Component suppport.  Note:  this version of the bridge will not work
with any currently released versions of MyFaces (try Trunk) and only
mostly runs on released version of Mojarra (patches available).
Likewise a patched version of Trinidad is needed to run the TCK (for
those tests that depend on Trinidad).

Distributable components can be inspected in
http://people.apache.org/~mfreedman/portlet-bridge/3.0.0-alpha

Repository artifacts are at:
https://repository.apache.org/content/repositories/orgapachemyfaces-022/


I have verified that the distributable jars run and pass the updated
version of the JSR 329 TCK.  In addition I have verified that the
distributable examples run (on apache tomcat/pluto).


[ ] +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,
   -Mike-

Re: [RE-RE-VOTE] Release MyFaces Portlet Bridge 3.0.0

2011-03-30 Thread Michael Freedman


+1

On 3/30/2011 11:23 AM, Michael Freedman wrote:

Please vote:

Bridge has been rebuilt/posted and now runs with either the latest 
Mojarra release (2.0.4.b09) or MyFaces Snapshot (2.0.5).  Rebuilt 
artifacts have been verified and tested and pass to the same degree as 
prior post in this sequence.  Refer to information in message below 
regarding this release and location of distributable 
components/artifacts (changes have been made to reflect current build).


As this is a re-vote -- please do so asap as I will be (hopefully) 
closing the vote by the end of this week so we can (finally) get this 
release out.


Please vote on the proposed release of MyFaces Portlet Bridge
3.0.0-alpha.  This is the alpha version of the Portlet Bridge for JSF
2.0.  It includes all the base function of JSR329 updated to run in a
JSF 2.0 environment.  Some, though not all JSF 2.0 features are
expressed/utilized.  Most significant is Ajax support and Composite
Component support.  Note:  this version of the bridge will not work
with any currently released versions of MyFaces (try Trunk).

Distributable components can be inspected in
http://people.apache.org/~mfreedman/portlet-bridge/3.0.0-alpha

Repository artifacts are at:
https://repository.apache.org/content/repositories/orgapachemyfaces-054


I have verified that the distributable jars run and pass the updated
version of the JSR 329 TCK.  In addition I have verified that the
distributable examples run (on apache tomcat/pluto).


[ ] +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,
   -Mike-


On 3/22/2011 1:17 PM, Michael Freedman wrote:
Files without necessary license statements have been updated.  Rat 
now reports no problems.  Refer to information in message below 
regarding this release and location of distributable 
components/artifacts (changes have been made to reflect current build).


As this is a re-vote -- please do so asap as I will be (hopefully) 
closing the vote by the end of this week so we can get this release out.

 -Mike-

 Original Message 
Subject:[VOTE] Release MyFaces Portlet Bridge 3.0.0
Date:   Wed, 09 Mar 2011 15:52:54 -0800
From:   Michael Freedman michael.freed...@oracle.com
Reply-To:   MyFaces Development dev@myfaces.apache.org
Organization:   Oracle Corporation
To: myfaces Development dev@myfaces.apache.org



Please vote on the proposed release of MyFaces Portlet Bridge
3.0.0-alpha.  This is the alpha version of the Portlet Bridge for JSF
2.0.  It includes all the base function of JSR329 updated to run in a
JSF 2.0 environment.  Some, though not all JSF 2.0 features are
expressed/utilized.  Most significant is Ajax support and Composite
Component suppport.  Note:  this version of the bridge will not work
with any currently released versions of MyFaces (try Trunk) and only
mostly runs on released version of Mojarra (patches available).
Likewise a patched version of Trinidad is needed to run the TCK (for
those tests that depend on Trinidad).

Distributable components can be inspected in
http://people.apache.org/~mfreedman/portlet-bridge/3.0.0-alpha

Repository artifacts are at:
https://repository.apache.org/content/repositories/orgapachemyfaces-022/


I have verified that the distributable jars run and pass the updated
version of the JSR 329 TCK.  In addition I have verified that the
distributable examples run (on apache tomcat/pluto).


[ ] +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,
   -Mike-

[jira] [Commented] (PORTLETBRIDGE-202) Proposal for 3.0 IMPL: Support mode changes via StateAwareResponse#setPortletMode(PortletMode)

[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13013627#comment-13013627
]

Michael Freedman commented on PORTLETBRIDGE-202:

1) On your spec comment -- I don't see why the spec would need to say anything
about this specific use case. I think (hope) the spec is clear as to the
bridge behavior when it encounters a mode change in any request -- i.e. don't
restore the scope.

2) On managing this info in the requestScope itself. Maybe -- right now the RI
handles this by encoding the info in the target viewId itself. This ensures
that whenever we are processing an incoming request that the target can check
what mode it was saved in and the bridge controller only restores if that
mode is the same as the current request. Seems to me this is a logical place
to handle things (i.e. in the controller itself) as why should the bridge
restore the scope so it can read the mode and then decide to undo the restore
beacuse the mode has changed?

Proposal for 3.0 IMPL: Support mode changes via
StateAwareResponse#setPortletMode(PortletMode)
--

Key: PORTLETBRIDGE-202
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-202
Project: MyFaces Portlet Bridge
Issue Type: New Feature
Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman

To the best of my knowledge, the Bridge 2.0 spec does not address usage of
StateAwareResponse#setPortletMode(PortletMode) within a JSF backing bean
action.
This proposal would require the BridgeRequestScope to remember the
PortletMode so that mode changes can be detected:
public interface BridgeRequestScope {
...
PortletMode getPortletMode();
void setPortletMode(PortletMode portletMode);
...
}
Note that the Bridge implementation would be required to call
bridgeRequestScope.setPortletMode() during an ActionRequest and EventRequest.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (PORTLETBRIDGE-202) Proposal for 3.0 IMPL: Support mode changes via StateAwareResponse#setPortletMode(PortletMode)


[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13013640#comment-13013640
 ] 

Michael Freedman commented on PORTLETBRIDGE-202:


PortletExternalContextImpl.encodeFacesActionTarget does the encoding of the 
target (admittedly now that you have pointed it out it would be better if it 
also checked response.getPortletMode()).  This is called when encodeActionURL 
is called with an URL that resolves to a Faces view.

doFacesRequest (renderRequest/whatever) in BridgeImpl calls hasModeChanged() to 
detect whether the mode of the request is different than the one of the target 
viewId.



 Proposal for 3.0 IMPL: Support mode changes via 
 StateAwareResponse#setPortletMode(PortletMode)
 --

 Key: PORTLETBRIDGE-202
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-202
 Project: MyFaces Portlet Bridge
  Issue Type: New Feature
  Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman

 To the best of my knowledge, the Bridge 2.0 spec does not address usage of 
 StateAwareResponse#setPortletMode(PortletMode) within a JSF backing bean 
 action.
 This proposal would require the BridgeRequestScope to remember the 
 PortletMode so that mode changes can be detected:
 public interface BridgeRequestScope {
   ...
   PortletMode getPortletMode();
   void setPortletMode(PortletMode portletMode);
   ...
 }
 Note that the Bridge implementation would be required to call 
 bridgeRequestScope.setPortletMode() during an ActionRequest and EventRequest.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (PORTLETBRIDGE-203) Proposal for 3.0 IMPL: Preserve and restore JSF2 FacesContext attributes in BridgeRequestScope

2011-03-29 Thread Michael Freedman (JIRA)


[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13012588#comment-13012588
 ] 

Michael Freedman commented on PORTLETBRIDGE-203:


We will have to discuss/debate this one.  Turns out there are some Faces 
internal FacesContext attributes that can't be preserved across FacesContext 
releases and there are others that must.  In addition we need to 
discuss/understand to what degree application developers are using this scope 
and expect/require that it last until the entire action/render occurs.  
Basically -- this scope is a mess for the bridge as its normal behavior is to 
release the FacesContext at the end of the action and start a new one in 
render.  I really want to avoid having to support a similar include/exclude 
mechanism as the request scope for any new scope.

 Proposal for 3.0 IMPL: Preserve and restore JSF2 FacesContext attributes in 
 BridgeRequestScope
 --

 Key: PORTLETBRIDGE-203
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-203
 Project: MyFaces Portlet Bridge
  Issue Type: New Feature
  Components: General
Affects Versions: 3.0.0
Reporter: Neil Griffin
Assignee: Michael Freedman

 The JSF 2.0 API introduced a getAttributes() method on FacesContext:
 http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/FacesContext.html#getAttributes()
 These values need to be preserved in the BridgeRequestScope. For more 
 information on implementation details, search for 
 BRIDGE_REQ_SCOPE_ATTR_FACES_CONTEXT_ATTRIBUTES in the following Java class:
 http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-impl/trunk/src/main/java/org/portletfaces/bridge/scope/BridgeRequestScopeImpl.java

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (PORTLETBRIDGE-204) Bridge doesn't work with Mojarra 2.0.4b09

2011-03-29 Thread Michael Freedman (JIRA)

Bridge doesn't work with Mojarra 2.0.4b09
-

 Key: PORTLETBRIDGE-204
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-204
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman


Bridge doesn't work with the latest released Mojarra. Problem again is related 
to us slamming the UIViewRoot across the action/render without a full 
save/restore -- this time the UIViewRoot has old listeners hanging off its atts.




--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [RE-VOTE] Release MyFaces Portlet Bridge 3.0.0

2011-03-29 Thread Michael Freedman

FYI ...  I held/pulled this release to make a critical fix/change to 
support Mojarra 2.0.4.b09 (I had been testing with 2.0.3).  (See 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-204 for more info).  
Expect a new version and a request for re-vote in the next day or so.  
Sorry about the delay/any confusion/hassles this creates.

   -Mike-

On 3/22/2011 1:17 PM, Michael Freedman wrote:
Files without necessary license statements have been updated.  Rat now 
reports no problems.  Refer to information in message below regarding 
this release and location of distributable components/artifacts 
(changes have been made to reflect current build).


As this is a re-vote -- please do so asap as I will be (hopefully) 
closing the vote by the end of this week so we can get this release out.

 -Mike-

 Original Message 
Subject:[VOTE] Release MyFaces Portlet Bridge 3.0.0
Date:   Wed, 09 Mar 2011 15:52:54 -0800
From:   Michael Freedman michael.freed...@oracle.com
Reply-To:   MyFaces Development dev@myfaces.apache.org
Organization:   Oracle Corporation
To: myfaces Development dev@myfaces.apache.org



Please vote on the proposed release of MyFaces Portlet Bridge
3.0.0-alpha.  This is the alpha version of the Portlet Bridge for JSF
2.0.  It includes all the base function of JSR329 updated to run in a
JSF 2.0 environment.  Some, though not all JSF 2.0 features are
expressed/utilized.  Most significant is Ajax support and Composite
Component suppport.  Note:  this version of the bridge will not work
with any currently released versions of MyFaces (try Trunk) and only
mostly runs on released version of Mojarra (patches available).
Likewise a patched version of Trinidad is needed to run the TCK (for
those tests that depend on Trinidad).

Distributable components can be inspected in
http://people.apache.org/~mfreedman/portlet-bridge/3.0.0-alpha

Repository artifacts are at:
https://repository.apache.org/content/repositories/orgapachemyfaces-022/


I have verified that the distributable jars run and pass the updated
version of the JSR 329 TCK.  In addition I have verified that the
distributable examples run (on apache tomcat/pluto).


[ ] +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,
   -Mike-

Re: [RE-VOTE] Release MyFaces Portlet Bridge 3.0.0

2011-03-23 Thread Michael Freedman


+1

On 3/22/2011 1:17 PM, Michael Freedman wrote:
Files without necessary license statements have been updated.  Rat now 
reports no problems.  Refer to information in message below regarding 
this release and location of distributable components/artifacts 
(changes have been made to reflect current build).


As this is a re-vote -- please do so asap as I will be (hopefully) 
closing the vote by the end of this week so we can get this release out.

 -Mike-

 Original Message 
Subject:[VOTE] Release MyFaces Portlet Bridge 3.0.0
Date:   Wed, 09 Mar 2011 15:52:54 -0800
From:   Michael Freedman michael.freed...@oracle.com
Reply-To:   MyFaces Development dev@myfaces.apache.org
Organization:   Oracle Corporation
To: myfaces Development dev@myfaces.apache.org



Please vote on the proposed release of MyFaces Portlet Bridge
3.0.0-alpha.  This is the alpha version of the Portlet Bridge for JSF
2.0.  It includes all the base function of JSR329 updated to run in a
JSF 2.0 environment.  Some, though not all JSF 2.0 features are
expressed/utilized.  Most significant is Ajax support and Composite
Component suppport.  Note:  this version of the bridge will not work
with any currently released versions of MyFaces (try Trunk) and only
mostly runs on released version of Mojarra (patches available).
Likewise a patched version of Trinidad is needed to run the TCK (for
those tests that depend on Trinidad).

Distributable components can be inspected in
http://people.apache.org/~mfreedman/portlet-bridge/3.0.0-alpha

Repository artifacts are at:
https://repository.apache.org/content/repositories/orgapachemyfaces-022/


I have verified that the distributable jars run and pass the updated
version of the JSR 329 TCK.  In addition I have verified that the
distributable examples run (on apache tomcat/pluto).


[ ] +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,
   -Mike-

[jira] [Created] (MYFACES-3081) javax.faces.Application addBehaviors() throws UnsupportedOperationException when it shouldn't

2011-03-23 Thread Michael Freedman (JIRA)

javax.faces.Application addBehaviors() throws UnsupportedOperationException 
when it shouldn't
-

 Key: MYFACES-3081
 URL: https://issues.apache.org/jira/browse/MYFACES-3081
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.0.5-SNAPSHOT
Reporter: Michael Freedman


Line 140 of javax.faces.Application is currently:

application.addBehavior(behaviorId, behaviorClass);

when it should be:

return application.addBehavior(behaviorId, behaviorClass);

without the return we fall through and throw the UnsupportedOperationException 
when we shouldn't.



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3081) javax.faces.Application addBehaviors() throws UnsupportedOperationException when it shouldn't

2011-03-23 Thread Michael Freedman (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13010509#comment-13010509
 ] 

Michael Freedman commented on MYFACES-3081:
---

Oops -- meant the fix is:
   application.addBehavior(behaviorId, behaviorClass); 
   return;

See patch file.

 javax.faces.Application addBehaviors() throws UnsupportedOperationException 
 when it shouldn't
 -

 Key: MYFACES-3081
 URL: https://issues.apache.org/jira/browse/MYFACES-3081
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.0.5-SNAPSHOT
Reporter: Michael Freedman
Assignee: Leonardo Uribe
 Fix For: 2.0.5-SNAPSHOT


 Line 140 of javax.faces.Application is currently:
 application.addBehavior(behaviorId, behaviorClass);
 when it should be:
 return application.addBehavior(behaviorId, behaviorClass);
 without the return we fall through and throw the 
 UnsupportedOperationException when we shouldn't.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[RE-VOTE] Release MyFaces Portlet Bridge 3.0.0

2011-03-22 Thread Michael Freedman

Files without necessary license statements have been updated.  Rat now 
reports no problems.  Refer to information in message below regarding 
this release and location of distributable components/artifacts (changes 
have been made to reflect current build).


As this is a re-vote -- please do so asap as I will be (hopefully) 
closing the vote by the end of this week so we can get this release out.

 -Mike-

 Original Message 
Subject:[VOTE] Release MyFaces Portlet Bridge 3.0.0
Date:   Wed, 09 Mar 2011 15:52:54 -0800
From:   Michael Freedman michael.freed...@oracle.com
Reply-To:   MyFaces Development dev@myfaces.apache.org
Organization:   Oracle Corporation
To: myfaces Development dev@myfaces.apache.org



Please vote on the proposed release of MyFaces Portlet Bridge
3.0.0-alpha.  This is the alpha version of the Portlet Bridge for JSF
2.0.  It includes all the base function of JSR329 updated to run in a
JSF 2.0 environment.  Some, though not all JSF 2.0 features are
expressed/utilized.  Most significant is Ajax support and Composite
Component suppport.  Note:  this version of the bridge will not work
with any currently released versions of MyFaces (try Trunk) and only
mostly runs on released version of Mojarra (patches available).
Likewise a patched version of Trinidad is needed to run the TCK (for
those tests that depend on Trinidad).

Distributable components can be inspected in
http://people.apache.org/~mfreedman/portlet-bridge/3.0.0-alpha

Repository artifacts are at:
https://repository.apache.org/content/repositories/orgapachemyfaces-022/


I have verified that the distributable jars run and pass the updated
version of the JSR 329 TCK.  In addition I have verified that the
distributable examples run (on apache tomcat/pluto).


[ ] +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,
  -Mike-

[jira] Created: (PORTLETBRIDGE-190) New Bridge 3.0 files missing Apache License headers

2011-03-18 Thread Michael Freedman (JIRA)

New Bridge 3.0 files missing Apache License headers
---

 Key: PORTLETBRIDGE-190
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-190
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: General
Reporter: Michael Freedman
Assignee: Michael Freedman


Most of the new files added to the Bridge as part of upgrading for JSF 2.0 
support are missing their requires Apache license/copyright statements.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Release MyFaces Portlet Bridge 3.0.0

2011-03-18 Thread Michael Freedman

Bummer ... we stepped on each other toes as I was just committing most 
of the same.  Thanks though for this.  Let me know if there are 
additional issues you want fixed.



On 3/18/2011 2:51 PM, Bernd Bohmann wrote:

Hello Michael,

with my last commit I get:

INFO] 
[INFO] MyFaces Portlet Bridge  SUCCESS [1.969s]
[INFO] MyFaces Portlet Bridge API  SUCCESS [0.086s]
[INFO] MyFaces Portlet Bridge Implementation . SUCCESS [0.205s]
[INFO] MyFaces Portlet Bridge Examples ... SUCCESS [0.277s]
[INFO] MyFaces Portlet Bridge Blank Project .. SUCCESS [0.085s]
[INFO] MyFaces Portlet Bridge CarStore Demo .. SUCCESS [0.179s]
[INFO] MyFaces Portlet Bridge Facelets Guess Demo  SUCCESS [0.045s]
[INFO] MyFaces Portlet Bridge GuessNumber JSP Demo ... SUCCESS [0.060s]
[INFO] MyFaces Portlet Bridge GuessNumber JSP with Mojarra WriteBehind
Filter Demo  SUCCESS [0.058s]
[INFO] MyFaces Portlet Bridge GuessNumber JSP with MyFaces WriteBehind
Filter Demo  SUCCESS [0.049s]
[INFO] MyFaces Portlet Bridge HelloDuke Demo . SUCCESS [0.098s]
[INFO] MyFaces Portlet Bridge HelloDuke Coordination Demo  SUCCESS [0.088s]
[INFO] 
[INFO] 
[INFO] BUILD SUCCESSFUL
[INFO] 

for

mvn org.apache.rat:apache-rat-plugin:check

I also added the missing svn properties to trunk.

For me the trunk is now fine.

Regards


Bernd

On Fri, Mar 18, 2011 at 3:29 PM, Bernd Bohmann
bernd.bohm...@atanion.com  wrote:

Hello Michael,

i have added an example rat configuration to the 3.0.x branch.

You can invoke the plugin with

mvn org.apache.rat:apache-rat-plugin:check

mvn rat:check

does not work because it calls the codehaus rat plugin. I asume the
codehaus plugin is defined somewhere in the master poms.

If you like I would also fix some missing svn properties

see:

http://www.apache.org/dev/version-control.html#https-svn-config

Regards

Bernd


On Fri, Mar 18, 2011 at 12:21 PM, Mark Strubergstrub...@yahoo.de  wrote:

yup, sorry for taking so long, but Bernd is right, which means a -1

e.g. 
api/src/main/java/javax/portlet/faces/annotation/BridgeRequestScopeAttributeAdded.java

This needs to get fixed before we can ship it.

you can check this yourself by simply invoking


$  mvn rat:check

There might be single files which could be excluded from the scan, but overally 
it works very well.

LieGrue,
strub


--- On Fri, 3/18/11, Bernd Bohmannbernd.bohm...@atanion.com  wrote:


From: Bernd Bohmannbernd.bohm...@atanion.com
Subject: Re: [VOTE] Release MyFaces Portlet Bridge 3.0.0
To: MyFaces Developmentdev@myfaces.apache.org
Date: Friday, March 18, 2011, 9:33 AM
Hello Michael,

i performed a checkout of
http://svn.apache.org/repos/asf/myfaces/portlet-bridge/core/tags/3.0.0-alpha/
and I found many files without a license header.

Regards

Bernd

On Thu, Mar 17, 2011 at 5:58 PM, Michael Freedman
michael.freed...@oracle.com
wrote:

Reminder -- if you are intending to vote please do so

by mid-day Friday

(PST) as I want to close the vote before the weekend.
 -Mike-

On 3/16/2011 1:12 PM, Michael Freedman wrote:

+1

FYI ... I plan to close the vote on Friday.

Hopefully I will have some more

votes to record by then.
-Mike-

On 3/15/2011 9:30 AM, Michael Freedman wrote:

Here is the information you want -- however I don't

really want to hold this

release until MyFaces/Trinidad are released -- rather

can't we use this

release as pressure to wrap up releases in these other

projects so they

follow shortly?

Have folks been waiting to vote because of Scott's

e-mail -- if so I would

appreciate your vote so I can close/release this.

Trinidad JIRA:
  TRINIDAD-1996 (Status Fixed 1/26/11)  I believe

this fix is in Beta-2 but I

haven't tried it yet and another member of the team

reports other problems

with using beta-2.  I need to investigate more

MyFaces JIRA:

MYFACES-3064: Fixed 3/1/11  Fix Version:

2.0.5-SNAPSHOT

MYFACES-3045: Fixed 3/1/11  Fix Version:

2.0.5-SNAPSHOT

MYFACES-3042: Fixed 2/15/11  Fix Version: Unresolved

-- patch available

MYFACES-3039: Fixed 2/18/11  Fix Version:

2.0.5-SNAPSHOT

MYFACES-3038: Fixed 2/18/11  Fix Version: 2.0.4
MYFACES-3017: Fixed 2/9/11  Fix Version: 2.0.4






MyFacesJIRA:

On 3/10/2011 5:50 AM, Scott O'Bryan wrote:

Hey Mike, do we have JIRA tickets for the Trinidad

patches needed?

Also, what are the challenges with the MyFaces

core?  I, for one,

would like to see this fixed ASAP..

On Mar 9, 2011, at 4:53 PM, Michael Freedman
michael.freed...@oracle.com

wrote:

Please vote on the proposed release of MyFaces Portlet

Bridge 3.0.0-alpha

Re: [VOTE] Release MyFaces Portlet Bridge 3.0.0

2011-03-17 Thread Michael Freedman

Reminder -- if you are intending to vote please do so by mid-day Friday 
(PST) as I want to close the vote before the weekend.

-Mike-

On 3/16/2011 1:12 PM, Michael Freedman wrote:

+1

FYI ... I plan to close the vote on Friday.  Hopefully I will have 
some more votes to record by then.

   -Mike-

On 3/15/2011 9:30 AM, Michael Freedman wrote:
Here is the information you want -- however I don't really want to 
hold this release until MyFaces/Trinidad are released -- rather can't 
we use this release as pressure to wrap up releases in these other 
projects so they follow shortly?


Have folks been waiting to vote because of Scott's e-mail -- if so I 
would appreciate your vote so I can close/release this.


Trinidad JIRA:
TRINIDAD-1996 https://issues.apache.org/jira/browse/TRINIDAD-1996 
(Status Fixed 1/26/11)  I believe this fix is in Beta-2 but I haven't 
tried it yet and another member of the team reports other problems 
with using beta-2.  I need to investigate more


MyFaces JIRA:

MYFACES-3064 https://issues.apache.org/jira/browse/MYFACES-3064: 
Fixed 3/1/11  Fix Version: 2.0.5-SNAPSHOT
MYFACES-3045 https://issues.apache.org/jira/browse/MYFACES-3045: 
Fixed 3/1/11  Fix Version: 2.0.5-SNAPSHOT
MYFACES-3042 https://issues.apache.org/jira/browse/MYFACES-3042: 
Fixed 2/15/11  Fix Version: Unresolved -- patch available
MYFACES-3039 https://issues.apache.org/jira/browse/MYFACES-3039: 
Fixed 2/18/11  Fix Version: 2.0.5-SNAPSHOT
MYFACES-3038 https://issues.apache.org/jira/browse/MYFACES-3038: 
Fixed 2/18/11  Fix Version: 2.0.4
MYFACES-3017 https://issues.apache.org/jira/browse/MYFACES-3017: 
Fixed 2/9/11  Fix Version: 2.0.4







MyFacesJIRA:

On 3/10/2011 5:50 AM, Scott O'Bryan wrote:

Hey Mike, do we have JIRA tickets for the Trinidad patches needed?

Also, what are the challenges with the MyFaces core?  I, for one,
would like to see this fixed ASAP..

On Mar 9, 2011, at 4:53 PM, Michael Freedman
michael.freed...@oracle.com  wrote:


Please vote on the proposed release of MyFaces Portlet Bridge 3.0.0-alpha.  
This is the alpha version of the Portlet Bridge for JSF 2.0.  It includes all 
the base function of JSR329 updated to run in a JSF 2.0 environment.  Some, 
though not all JSF 2.0 features are expressed/utilized.  Most significant is 
Ajax support and Composite Component suppport.  Note:  this version of the 
bridge will not work with any currently released versions of MyFaces (try 
Trunk) and only mostly runs on released version of Mojarra (patches available). 
 Likewise a patched version of Trinidad is needed to run the TCK (for those 
tests that depend on Trinidad).

Distributable components can be inspected in
http://people.apache.org/~mfreedman/portlet-bridge/3.0.0-alpha

Repository artifacts are at:
https://repository.apache.org/content/repositories/orgapachemyfaces-006/


I have verified that the distributable jars run and pass the updated version of 
the JSR 329 TCK.  In addition I have verified that the distributable examples 
run (on apache tomcat/pluto).


[ ] +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,
  -Mike-

Re: [VOTE] Release MyFaces Portlet Bridge 3.0.0

2011-03-16 Thread Michael Freedman


+1

FYI ... I plan to close the vote on Friday.  Hopefully I will have some 
more votes to record by then.

   -Mike-

On 3/15/2011 9:30 AM, Michael Freedman wrote:
Here is the information you want -- however I don't really want to 
hold this release until MyFaces/Trinidad are released -- rather can't 
we use this release as pressure to wrap up releases in these other 
projects so they follow shortly?


Have folks been waiting to vote because of Scott's e-mail -- if so I 
would appreciate your vote so I can close/release this.


Trinidad JIRA:
TRINIDAD-1996 https://issues.apache.org/jira/browse/TRINIDAD-1996 
(Status Fixed 1/26/11)  I believe this fix is in Beta-2 but I haven't 
tried it yet and another member of the team reports other problems 
with using beta-2.  I need to investigate more


MyFaces JIRA:

MYFACES-3064 https://issues.apache.org/jira/browse/MYFACES-3064: 
Fixed 3/1/11  Fix Version: 2.0.5-SNAPSHOT
MYFACES-3045 https://issues.apache.org/jira/browse/MYFACES-3045: 
Fixed 3/1/11  Fix Version: 2.0.5-SNAPSHOT
MYFACES-3042 https://issues.apache.org/jira/browse/MYFACES-3042: 
Fixed 2/15/11  Fix Version: Unresolved -- patch available
MYFACES-3039 https://issues.apache.org/jira/browse/MYFACES-3039: 
Fixed 2/18/11  Fix Version: 2.0.5-SNAPSHOT
MYFACES-3038 https://issues.apache.org/jira/browse/MYFACES-3038: 
Fixed 2/18/11  Fix Version: 2.0.4
MYFACES-3017 https://issues.apache.org/jira/browse/MYFACES-3017: 
Fixed 2/9/11  Fix Version: 2.0.4







MyFacesJIRA:

On 3/10/2011 5:50 AM, Scott O'Bryan wrote:

Hey Mike, do we have JIRA tickets for the Trinidad patches needed?

Also, what are the challenges with the MyFaces core?  I, for one,
would like to see this fixed ASAP..

On Mar 9, 2011, at 4:53 PM, Michael Freedman
michael.freed...@oracle.com  wrote:


Please vote on the proposed release of MyFaces Portlet Bridge 3.0.0-alpha.  
This is the alpha version of the Portlet Bridge for JSF 2.0.  It includes all 
the base function of JSR329 updated to run in a JSF 2.0 environment.  Some, 
though not all JSF 2.0 features are expressed/utilized.  Most significant is 
Ajax support and Composite Component suppport.  Note:  this version of the 
bridge will not work with any currently released versions of MyFaces (try 
Trunk) and only mostly runs on released version of Mojarra (patches available). 
 Likewise a patched version of Trinidad is needed to run the TCK (for those 
tests that depend on Trinidad).

Distributable components can be inspected in
http://people.apache.org/~mfreedman/portlet-bridge/3.0.0-alpha

Repository artifacts are at:
https://repository.apache.org/content/repositories/orgapachemyfaces-006/


I have verified that the distributable jars run and pass the updated version of 
the JSR 329 TCK.  In addition I have verified that the distributable examples 
run (on apache tomcat/pluto).


[ ] +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,
  -Mike-

Re: [VOTE] Release MyFaces Portlet Bridge 3.0.0

2011-03-15 Thread Michael Freedman

Here is the information you want -- however I don't really want to hold 
this release until MyFaces/Trinidad are released -- rather can't we use 
this release as pressure to wrap up releases in these other projects so 
they follow shortly?


Have folks been waiting to vote because of Scott's e-mail -- if so I 
would appreciate your vote so I can close/release this.


Trinidad JIRA:
TRINIDAD-1996 https://issues.apache.org/jira/browse/TRINIDAD-1996 
(Status Fixed 1/26/11)  I believe this fix is in Beta-2 but I haven't 
tried it yet and another member of the team reports other problems with 
using beta-2.  I need to investigate more


MyFaces JIRA:

MYFACES-3064 https://issues.apache.org/jira/browse/MYFACES-3064: Fixed 
3/1/11  Fix Version: 2.0.5-SNAPSHOT
MYFACES-3045 https://issues.apache.org/jira/browse/MYFACES-3045: Fixed 
3/1/11  Fix Version: 2.0.5-SNAPSHOT
MYFACES-3042 https://issues.apache.org/jira/browse/MYFACES-3042: Fixed 
2/15/11  Fix Version: Unresolved -- patch available
MYFACES-3039 https://issues.apache.org/jira/browse/MYFACES-3039: Fixed 
2/18/11  Fix Version: 2.0.5-SNAPSHOT
MYFACES-3038 https://issues.apache.org/jira/browse/MYFACES-3038: Fixed 
2/18/11  Fix Version: 2.0.4
MYFACES-3017 https://issues.apache.org/jira/browse/MYFACES-3017: Fixed 
2/9/11  Fix Version: 2.0.4


https://issues.apache.org/jira/browse/MYFACES-3017




MyFacesJIRA:

On 3/10/2011 5:50 AM, Scott O'Bryan wrote:

Hey Mike, do we have JIRA tickets for the Trinidad patches needed?

Also, what are the challenges with the MyFaces core?  I, for one,
would like to see this fixed ASAP..

On Mar 9, 2011, at 4:53 PM, Michael Freedman
michael.freed...@oracle.com  wrote:


Please vote on the proposed release of MyFaces Portlet Bridge 3.0.0-alpha.  
This is the alpha version of the Portlet Bridge for JSF 2.0.  It includes all 
the base function of JSR329 updated to run in a JSF 2.0 environment.  Some, 
though not all JSF 2.0 features are expressed/utilized.  Most significant is 
Ajax support and Composite Component suppport.  Note:  this version of the 
bridge will not work with any currently released versions of MyFaces (try 
Trunk) and only mostly runs on released version of Mojarra (patches available). 
 Likewise a patched version of Trinidad is needed to run the TCK (for those 
tests that depend on Trinidad).

Distributable components can be inspected in
http://people.apache.org/~mfreedman/portlet-bridge/3.0.0-alpha

Repository artifacts are at:
https://repository.apache.org/content/repositories/orgapachemyfaces-006/


I have verified that the distributable jars run and pass the updated version of 
the JSR 329 TCK.  In addition I have verified that the distributable examples 
run (on apache tomcat/pluto).


[ ] +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,
  -Mike-

Re: [VOTE] Release MyFaces Portlet Bridge 3.0.0

2011-03-15 Thread Michael Freedman

Sorry, I was out pretty much from the moment I sent the vote e-mail to 
now and had neglected to send this figuring it had already been done by 
someone else on the team (when they did the build).  It is now closed.

-Mike-

On 3/15/2011 10:07 AM, Mark Struberg wrote:

Hi Michael!

It seems that
https://repository.apache.org/content/repositories/orgapachemyfaces-006/
didnt get closed.

If it contains all the artifacts you need, then please log in to 
repository.apache.org and click on 'close'. This will close the upload window 
and finishes packaging the staging repo.
Once we finally voted upon the release, you'll have to 'Promote' the staging 
repo. This will push all the artifacts to the maven.central repo.

LieGrue,
strub


--- On Tue, 3/15/11, Michael Freedmanmichael.freed...@oracle.com  wrote:

From: Michael Freedmanmichael.freed...@oracle.com
Subject: Re: [VOTE] Release MyFaces Portlet Bridge 3.0.0
To: MyFaces Developmentdev@myfaces.apache.org
Date: Tuesday, March 15, 2011, 4:30 PM







   Here is the information you want -- however I don't really want to
 hold this release until MyFaces/Trinidad are released -- rather
 can't we use this release as pressure to wrap up releases in these
 other projects so they follow shortly?



 Have folks been waiting to vote because of Scott's e-mail -- if so I
 would appreciate your vote so I can close/release this.



 Trinidad JIRA:

  TRINIDAD-1996
 (Status Fixed 1/26/11)  I believe this fix is in Beta-2 but I
 haven't tried it yet and another member of the team reports other
 problems with using beta-2.  I need to investigate more



 MyFaces JIRA:



 MYFACES-3064:
 Fixed 3/1/11  Fix Version: 2.0.5-SNAPSHOT

 MYFACES-3045:
 Fixed 3/1/11  Fix Version: 2.0.5-SNAPSHOT

 MYFACES-3042:
 Fixed 2/15/11  Fix Version: Unresolved -- patch available

 MYFACES-3039:
 Fixed 2/18/11  Fix Version: 2.0.5-SNAPSHOT

 MYFACES-3038:
 Fixed 2/18/11  Fix Version: 2.0.4

 MYFACES-3017:
 Fixed 2/9/11  Fix Version: 2.0.4













 MyFacesJIRA:



 On 3/10/2011 5:50 AM, Scott O'Bryan wrote:

   Hey Mike, do we have JIRA tickets for the Trinidad patches needed?

Also, what are the challenges with the MyFaces core?  I, for one,
would like to see this fixed ASAP..

On Mar 9, 2011, at 4:53 PM, Michael Freedman
michael.freed...@oracle.com  wrote:



 Please vote on the proposed release of MyFaces Portlet Bridge 
3.0.0-alpha.  This is the alpha version of the Portlet Bridge for JSF 2.0.  It 
includes all the base function of JSR329 updated to run in a JSF 2.0 
environment.  Some, though not all JSF 2.0 features are expressed/utilized.  
Most significant is Ajax support and Composite Component suppport.  Note:  this 
version of the bridge will not work with any currently released versions of 
MyFaces (try Trunk) and only mostly runs on released version of Mojarra 
(patches available).  Likewise a patched version of Trinidad is needed to run 
the TCK (for those tests that depend on Trinidad).

Distributable components can be inspected in
http://people.apache.org/~mfreedman/portlet-bridge/3.0.0-alpha

Repository artifacts are at:
https://repository.apache.org/content/repositories/orgapachemyfaces-006/


I have verified that the distributable jars run and pass the updated version of 
the JSR 329 TCK.  In addition I have verified that the distributable examples 
run (on apache tomcat/pluto).


[ ] +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,
  -Mike-

[jira] Commented: (PORTLETBRIDGE-187) Why does the 3.0.0 implementation of PortletFacesContextFactoryImpl differ from the one in 2.0?

2011-03-15 Thread Michael Freedman (JIRA)


[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007302#comment-13007302
 ] 

Michael Freedman commented on PORTLETBRIDGE-187:


Yep, in JSF 2.0 the ExternalContext creation has been separated from the 
FacesContext creation.  Turns out that the generic FacesContext impl is 95%+ (I 
think its actually 100%) platform independent -- so the bridge now can grab and 
wrap the base one and only override those methods where it extends the 
behavior.  Pretty much all the platform dependent code is safely inside the 
ExternalContext which now has its own factory and hence isn't something tied 
explicitly to a given FacesContext.

 Why does the 3.0.0 implementation of PortletFacesContextFactoryImpl differ 
 from the one in 2.0?
 ---

 Key: PORTLETBRIDGE-187
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-187
 Project: MyFaces Portlet Bridge
  Issue Type: Question
  Components: Impl
Affects Versions: 3.0.0-alpha
Reporter: Hampus Wingren
Assignee: Michael Freedman

 This seems like an impossible thing to do if there is no other 
 PortletFacesContext implementations available. Is it really correct to try 
 and lookup another FacesContext if we are in a portlet environment? 
 // if in portlet environment -- do a portlet container neutral test
 // first in case we are packaged in a web app that isn't deployed 
 // on a portlet container/as a portlet. Note:  can't use the BridgeUtil
 // method as that call requires the facesContext to exist.
 FacesContext fc = getWrapped().getFacesContext(context, request, 
 response, lifecycle);
   
 if(ExternalContextUtils.isPortlet(fc.getExternalContext()))
 {
   fc = new FacesContextImpl(fc);
 }
   
 return fc;
 regards,
 Hampus

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (PORTLETBRIDGE-188) HEAD resources added to the viewroot by portlets

2011-03-15 Thread Michael Freedman (JIRA)


[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13007303#comment-13007303
 ] 

Michael Freedman commented on PORTLETBRIDGE-188:


Yes,  this code/support is coming.  I didn't place it in the first batch of 
function to support as I upgrades the JSF 1.2 bridge as I thought it was more 
important to focus on the facelets support, Ajax/Partial rendering support and 
ensuring composite components ran properly (as well as ensuring the bridge 
continued to provide all the JSR 329 behaviors one would expect for those 
bringing forward 1.2 apps into this env.)



 HEAD resources added to the viewroot by portlets
 

 Key: PORTLETBRIDGE-188
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-188
 Project: MyFaces Portlet Bridge
  Issue Type: Question
  Components: Impl
Affects Versions: 3.0.0
Reporter: Hampus Wingren
Assignee: Michael Freedman

 Hi,
 Are there any plans on supporting some way of extracting the HEAD resources 
 that a portlet may add through JSF so that the portal can handle them in some 
 manner?
 Regards,
 Hampus

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[VOTE] Release MyFaces Portlet Bridge 3.0.0

2011-03-09 Thread Michael Freedman

Please vote on the proposed release of MyFaces Portlet Bridge 
3.0.0-alpha.  This is the alpha version of the Portlet Bridge for JSF 
2.0.  It includes all the base function of JSR329 updated to run in a 
JSF 2.0 environment.  Some, though not all JSF 2.0 features are 
expressed/utilized.  Most significant is Ajax support and Composite 
Component suppport.  Note:  this version of the bridge will not work 
with any currently released versions of MyFaces (try Trunk) and only 
mostly runs on released version of Mojarra (patches available).  
Likewise a patched version of Trinidad is needed to run the TCK (for 
those tests that depend on Trinidad).


Distributable components can be inspected in
http://people.apache.org/~mfreedman/portlet-bridge/3.0.0-alpha

Repository artifacts are at:
https://repository.apache.org/content/repositories/orgapachemyfaces-006/


I have verified that the distributable jars run and pass the updated 
version of the JSR 329 TCK.  In addition I have verified that the 
distributable examples run (on apache tomcat/pluto).



[ ] +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,
  -Mike-

[jira] Created: (MYFACES-3064) UIView.createUniqueId shouldn't call encodeNameSpace to build the id.

2011-03-09 Thread Michael Freedman (JIRA)

UIView.createUniqueId shouldn't call encodeNameSpace to build the id.
-

 Key: MYFACES-3064
 URL: https://issues.apache.org/jira/browse/MYFACES-3064
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.0.4, 1.2.10
Reporter: Michael Freedman


Submitting a new bug based on one I recently reopened as it pertains to 1.2 and 
2.0 impls as well:
Referer bug: https://issues.apache.org/jira/browse/MYFACES-702

Problem reported in the above bug is related to the component's id being 
prefixed with the portletNamespace which is caused by calling encodeNamespace.  
Why is this api called in generating the component id.  encodeNamespace was 
added to external context by and large for the portlet environment  to allow it 
to prefix client ids to be unique on the page they are being incorporated into. 
 Is there a reason for needing this when generating the component id?  FYI ... 
Mojarra doesn't make this call from createUniqureId.

Hopefully, this is something that can be fixed by just removing the call 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Reopened: (MYFACES-702) outputText generates wrapped span element in a portal

[
https://issues.apache.org/jira/browse/MYFACES-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Freedman reopened MYFACES-702:
--

Reopening because PORTLETBRIDGE-186 was filed.
(https://issues.apache.org/jira/browse/PORTLETBRIDGE-186)

I.e. The problem reported in MYFaces-702 was reopened against the bridge
indicating that the 1.1 Bridge change/patch to work around this should be
applied to the 1.2 bridge.

I am not so sure. It appears that the real bug is that
UIViewRoot.createUniqueId calls ExternalContext.encodeNamespace on the id
before returning. It shouldn't make this call. Rather it should just return
the uniqueId it generates. My guess is this was very old code that was added
to deal with portlet/portal namespacing issues. However, the bridge now
handles this more correctly by not impacting the component id -- rather it
introduces its own UIViewRoot that provides a NamingContainer which ensures all
clientIds are namespaced via this externalcontext call.

Is this correct, or is there some valid reason that createUniqueId calls
encodeNamesapce?

outputText generates wrapped span element in a portal
-

Key: MYFACES-702
URL: https://issues.apache.org/jira/browse/MYFACES-702
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.1.0
Reporter: Gavin Cornwell
Assignee: Martin Marinschek
Fix For: 1.1.2

Attachments: myfaces702.patch

We have a JSF app that runs as a portlet and normal webapp.
In the webapp the h:outputText value=some text/ appears as I would expect
(i.e. just the text) however the same thing in the portlet gets rendered as:
span id=form-id:handleMetaDataEvent_id36some text/span
This becomes a problem when you are trying to use outputText to render part
of a URL or to become a JavaScript string as the output includes the span
element!
Looking at the renderer code for outputText it appears the span gets
generated when the id does not start with _id, so the question is where has
the handleMetaDataEvent prefix for the id come from?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (PORTLETBRIDGE-186) Unnecesarry Id and span's generated in a portal


[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13003472#comment-13003472
 ] 

Michael Freedman commented on PORTLETBRIDGE-186:


I have reopened https://issues.apache.org/jira/browse/MYFACES-702 as it looks 
to me that the real bug here is that UIViewRoot.createUniqueId calls 
encodeNamespace().  I don't see a valid reason for it doing so and would prefer 
comment/fix by the MyFaces core folks before introducing any hacks to 
workaround the issue.In the meantime if you need to workaround the issue 
you can always introduce your own ExternalContext and subclass encodeNameSpace 
to add the additional prefix.

 Unnecesarry Id and span's generated in a portal
 ---

 Key: PORTLETBRIDGE-186
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-186
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
Reporter: Krashan Brahmanjara
Assignee: Michael Freedman

 Html generated via bridge has dot a'lot of unnecesary code :id's, span's and 
 span's unwanted by programmers (like h:outputText without styleClass)
 Full description of this problem and easy patch is here 
 https://issues.apache.org/jira/browse/MYFACES-702.
 BTW.
 It looks like very old bug. Old patch pplied to file:
 myfaces_1_1_8\impl\src\main\java\org\apache\myfaces\context\portlet\PortletExternalContextImpl.java
 still exist but was not moved and applied to file:
 myfaces-portlet-bridge-2.0.0\src\impl\src\main\java\org\apache\myfaces\portlet\faces\context\PortletFacesContextImpl.java

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: staging repositories

2011-03-07 Thread Michael Freedman

Yep -- 
https://repository.apache.org/content/repositories/orgapachemyfaces-047/ 
--  this is/was a version of the bridge for JSF 2.0 that I was about to 
send for a vote to release as alpha -- prior to starting such a vote I 
needed a JCP legal question answered -- that has taken a while.  Based 
on the answer, we will be removing this repos and creating/submitting a 
new one soon for vote/release.

 -Mike-

On 3/3/2011 11:58 AM, Gerhard wrote:

hi mike and werner,

i saw [1] and [2] - they are closed but not released since a quite 
long time.


regards,
gerhard

[1] 
https://repository.apache.org/content/repositories/orgapachemyfaces-017/
[2] 
https://repository.apache.org/content/repositories/orgapachemyfaces-047/


http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

[jira] Resolved: (PORTLETBRIDGE-183) Potential NPE in FacesContext.release


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-183.


   Resolution: Fixed
Fix Version/s: 3.0.0-alpha
   2.0.1
   1.0.1

Updated all versions with the simple fix in release() that first makes sure the 
attr Map returned from looking up on the request attrs is non-null.

 Potential NPE in FacesContext.release
 -

 Key: PORTLETBRIDGE-183
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-183
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
Affects Versions: 1.0.0, 2.0.0, 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 1.0.1, 2.0.1, 3.0.0-alpha


 The Bridge's FacesContext.release dereferences the return from 
 request.getAttribute(BridgeImpl.PREEXISTING_ATTRIBUTE_NAMES) without checking 
 to see if its null.  Now it would only be null if the bridge didn't 
 create/release FC but there seems to be at least one situation in which this 
 has occurred and in any case the code should be written correctly to avoid 
 the potential problem/NPE.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (PORTLETBRIDGE-99) RequestScopeListener not Serializable


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-99.
---

   Resolution: Fixed
Fix Version/s: 3.0.0-alpha
   2.0.1
   1.0.1

Finally got around to making this object serializable to avoid the exception.

 RequestScopeListener not Serializable
 -

 Key: PORTLETBRIDGE-99
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-99
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0-beta
 Environment: eXo PC 2.0.5 under JBoss AS 4.2.3, using both MyFaces 
 1.2.7 and JBoss embebed Mojarra
Reporter: Fernando Silva Lozano
 Fix For: 1.0.1, 2.0.1, 3.0.0-alpha


 I get lots of erros on JBoss AS log such as:
 13:51:03,110 ERROR [STDERR] java.lang.IllegalArgumentException: 
 java.io.NotSerializableException: 
 org.apache.myfaces.portlet.faces.bridge.BridgeImpl$RequestScopeListener
 13:51:03,110 ERROR [STDERR]   at 
 org.jgroups.Message.setObject(Message.java:281)
 13:51:03,110 ERROR [STDERR]   at org.jgroups.Message.init(Message.java:141)
 13:51:03,110 ERROR [STDERR]   at 
 org.exoplatform.frameworks.portletcontainer.portalframework.replication.SessionReplicator.send(SessionReplicator.java:103)
 13:51:03,110 ERROR [STDERR]   at 
 org.exoplatform.frameworks.portletcontainer.portalframework.filters.PortalFrameworkFilter.doFilter(PortalFrameworkFilter.java:114)
 13:51:03,110 ERROR [STDERR]   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 13:51:03,111 ERROR [STDERR]   at 
 org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
 13:51:03,111 ERROR [STDERR]   at 
 org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
 13:51:03,111 ERROR [STDERR]   at 
 org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 13:51:03,111 ERROR [STDERR]   at 
 org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
 13:51:03,112 ERROR [STDERR]   at java.lang.Thread.run(Thread.java:595)
 I think it is self-explanatory: every object stored on the user HTTP session 
 should be serializable, and one of the objects put there by the bridge (an 
 inner class of BridgeImpl) isn't.
 I rated as Major because I suppose this will prevent my JSF portlet to work 
 correctly in a clustered container.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (PORTLETBRIDGE-185) Portlet 2.0 Bridge NPE in restore resource request if scope isn't in Map

2011-03-03 Thread Michael Freedman (JIRA)

Portlet 2.0 Bridge NPE in restore resource request if scope isn't in Map


 Key: PORTLETBRIDGE-185
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-185
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0
Reporter: Michael Freedman
Assignee: Michael Freedman


In handling a resource request we reacquire the bridge request scope.  If we 
find the scopeId to use but the scope has since been removed from the ScopeMap 
(or never put there in the first place) you get an NPE.  This happen because 
the code (getResourceRequestScopeId() in BridgeImpl) dereferences the (Map) 
object pulled from the scopeMap using the scopeId key without checking first if 
this object is null (wasn't found).

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (PORTLETBRIDGE-185) Portlet 2.0 Bridge NPE in restore resource request if scope isn't in Map

2011-03-03 Thread Michael Freedman (JIRA)

[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Freedman resolved PORTLETBRIDGE-185.

Resolution: Fixed
Fix Version/s: 2.0.1

Turns out the actual use case that caused this occurred because of a
concurrency interaction inside a series of requests that occur after a
renderredirect and include an concurrent render and resource request. The use
case problem is the bridge was creating the scopeId early in the render but not
actually giving it a representation in the ScopeMap until later. When a
concurrent resource request is run -- it can hit this case where it picks up
this new scopeId but doesn't find the entry.

Fix was actually quite involved -- in that it also showed that in this use case
the bridge was overally aggressively creating new scopes. So now the scope
activation/resolution has been reworked to make this work/simpler.

Portlet 2.0 Bridge NPE in restore resource request if scope isn't in Map

Key: PORTLETBRIDGE-185
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-185
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 2.0.0
Reporter: Michael Freedman
Assignee: Michael Freedman
Fix For: 2.0.1

In handling a resource request we reacquire the bridge request scope. If we
find the scopeId to use but the scope has since been removed from the
ScopeMap (or never put there in the first place) you get an NPE. This happen
because the code (getResourceRequestScopeId() in BridgeImpl) dereferences the
(Map) object pulled from the scopeMap using the scopeId key without checking
first if this object is null (wasn't found).

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (PORTLETBRIDGE-184) Bridge NPE in resolving scope during resource request if scope has been removed from cache

2011-03-03 Thread Michael Freedman (JIRA)


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-184.


Resolution: Duplicate

Inadvertently opened duplicate second bug: PORTLETBRIDGE-185 and updated/marked 
that one fixed.

 Bridge NPE in resolving scope during resource request if scope has been 
 removed from cache
 --

 Key: PORTLETBRIDGE-184
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-184
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0
Reporter: Michael Freedman
Assignee: Michael Freedman

 If the Bridge receives a scopeid in the incoming request during a resource 
 request and that scope isn't in the cache (it has been removed) then the 
 bridge throws a NPE as it doesn't include a check to ensure that the map 
 returned from looking up the scopeId isn't null.  
 Code currently reads like this:
   private String getResourceRequestScopeId(ExternalContext extCtx, 
 PortletRequest request)
   {
 // get the render scope this resource request is contained in
 String scopeId = getRequestScopeId(request);

 if (scopeId == null)
 {
   // first request is a resource request
   // create a scope and store in the session until an action occurs
   // pass null as we aren't a StateAwareResponse
   return initBridgeRequestScope(request, null);
 }
 
 // Check to see if this resource request is targeting the same view or a 
 different one
 MapString, Object m = getScopeMap(scopeId);
 MapString, String childResourceScopeMap = (MapString, String) 
 m.get(CHILD_RESOURCE_REQUEST_SCOPE_MAP);
 String scopeIdKey = (String) m.get(SCOPE_VIEW_KEY);
 String childIdKey = getScopeViewKey(extCtx);
 Instead code should check for null return from geetScopeMap and if null init 
 a new bridge RequestScope.  

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (PORTLETBRIDGE-184) Bridge NPE in resolving scope during resource request if scope has been removed from cache

2011-03-01 Thread Michael Freedman (JIRA)

Bridge NPE in resolving scope during resource request if scope has been removed 
from cache
--

 Key: PORTLETBRIDGE-184
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-184
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 2.0.0
Reporter: Michael Freedman
Assignee: Michael Freedman


If the Bridge receives a scopeid in the incoming request during a resource 
request and that scope isn't in the cache (it has been removed) then the bridge 
throws a NPE as it doesn't include a check to ensure that the map returned from 
looking up the scopeId isn't null.  

Code currently reads like this:
  private String getResourceRequestScopeId(ExternalContext extCtx, 
PortletRequest request)
  {

// get the render scope this resource request is contained in
String scopeId = getRequestScopeId(request);
   
if (scopeId == null)
{
  // first request is a resource request
  // create a scope and store in the session until an action occurs
  // pass null as we aren't a StateAwareResponse
  return initBridgeRequestScope(request, null);
}

// Check to see if this resource request is targeting the same view or a 
different one
MapString, Object m = getScopeMap(scopeId);
MapString, String childResourceScopeMap = (MapString, String) 
m.get(CHILD_RESOURCE_REQUEST_SCOPE_MAP);
String scopeIdKey = (String) m.get(SCOPE_VIEW_KEY);
String childIdKey = getScopeViewKey(extCtx);

Instead code should check for null return from geetScopeMap and if null init a 
new bridge RequestScope.  

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MYFACES-3045) jsf.js jsf.ajax.request doesn't resolve calling URL correctly -- ajax use in portlets broken

2011-02-24 Thread Michael Freedman (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12999028#comment-12999028
 ] 

Michael Freedman commented on MYFACES-3045:
---

A potential patch (this works for me): replace the line in 
_AjaxRequest._startXHR:
this._xhr.open(this._ajaxType, this._sourceForm.action+
((this._ajaxType == GET)? 
?+this._requestParameters.makeFinal():)
, true);

with the following lines:


var targetURL;
if (typeof this._sourceForm.elements[javax.faces.encodedURL] == 
'undefined') {
  targetURL = this._sourceForm.action;
} else {
  targetURL = 
this._sourceForm.elements[javax.faces.encodedURL].value;
  }

this._xhr.open(this._ajaxType, targetURL +
((this._ajaxType == GET)? 
?+this._requestParameters.makeFinal():)
, true);

Sorry no patch file as the one that the Diff program used to generate the patch 
seems to want to replace everything...And anyway I am not authorized to provide 
includable patches.


 jsf.js jsf.ajax.request doesn't resolve calling URL correctly -- ajax use in 
 portlets broken
 

 Key: MYFACES-3045
 URL: https://issues.apache.org/jira/browse/MYFACES-3045
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.5-SNAPSHOT
Reporter: Michael Freedman

 Javadoc for jsf.ajax.request says you determine the calling URL by:
 Determine the posting URL as follows: If the hidden field 
 javax.faces.encodedURL is present in the submitting form, use its value as 
 the posting URL. Otherwise, use the action property of the form element as 
 the URL.
 Looks like the MyFaces impl skips loking for/using the javax.faces.encodedURL 
 and only uses the form action.  This means ajax is broken in portlets (when 
 using MyFaces).  I.e. the  javax.faces.encodedURL in the portlet case is 
 different than the action URL and the one that needs to be used.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (PORTLETBRIDGE-99) RequestScopeListener not Serializable

2011-02-17 Thread Michael Freedman (JIRA)


[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996122#comment-12996122
 ] 

Michael Freedman commented on PORTLETBRIDGE-99:
---

Two attributes need to support Serializable:  RequestScopeListener and 
QueryString

 RequestScopeListener not Serializable
 -

 Key: PORTLETBRIDGE-99
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-99
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0-beta
 Environment: eXo PC 2.0.5 under JBoss AS 4.2.3, using both MyFaces 
 1.2.7 and JBoss embebed Mojarra
Reporter: Fernando Silva Lozano

 I get lots of erros on JBoss AS log such as:
 13:51:03,110 ERROR [STDERR] java.lang.IllegalArgumentException: 
 java.io.NotSerializableException: 
 org.apache.myfaces.portlet.faces.bridge.BridgeImpl$RequestScopeListener
 13:51:03,110 ERROR [STDERR]   at 
 org.jgroups.Message.setObject(Message.java:281)
 13:51:03,110 ERROR [STDERR]   at org.jgroups.Message.init(Message.java:141)
 13:51:03,110 ERROR [STDERR]   at 
 org.exoplatform.frameworks.portletcontainer.portalframework.replication.SessionReplicator.send(SessionReplicator.java:103)
 13:51:03,110 ERROR [STDERR]   at 
 org.exoplatform.frameworks.portletcontainer.portalframework.filters.PortalFrameworkFilter.doFilter(PortalFrameworkFilter.java:114)
 13:51:03,110 ERROR [STDERR]   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 13:51:03,111 ERROR [STDERR]   at 
 org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
 13:51:03,111 ERROR [STDERR]   at 
 org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
 13:51:03,111 ERROR [STDERR]   at 
 org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
 13:51:03,111 ERROR [STDERR]   at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 13:51:03,111 ERROR [STDERR]   at 
 org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
 13:51:03,112 ERROR [STDERR]   at 
 org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
 13:51:03,112 ERROR [STDERR]   at java.lang.Thread.run(Thread.java:595)
 I think it is self-explanatory: every object stored on the user HTTP session 
 should be serializable, and one of the objects put there by the bridge (an 
 inner class of BridgeImpl) isn't.
 I rated as Major because I suppose this will prevent my JSF portlet to work 
 correctly in a clustered container.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (MYFACES-3042) CCE: when running in portlet: Remove Servlet dependencies in FaceletViewDeclarationLanguage.java

2011-02-15 Thread Michael Freedman (JIRA)


 [ 
https://issues.apache.org/jira/browse/MYFACES-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman updated MYFACES-3042:
--

Status: Patch Available  (was: Open)

 CCE: when running in portlet: Remove Servlet dependencies in 
 FaceletViewDeclarationLanguage.java
 

 Key: MYFACES-3042
 URL: https://issues.apache.org/jira/browse/MYFACES-3042
 Project: MyFaces Core
  Issue Type: Bug
  Components: Portlet_Support
Affects Versions: 2.0.5-SNAPSHOT
Reporter: Michael Freedman
 Attachments: jira-myfaces-3042.patch


 In FaceletViewDeclarationLanguage.java: createResponseWriter(), 
 getResponseEncoding(), handleFaceletNotFound(), and sendSourceNotFound() each 
 cast to Servlet object.  This causes ClassCastExceptions when run in a 
 portlet environment.  Each of these calls/casts can be removed and 
 ExternalContext APIs can be used instead to get/set the needed information 
 from the request or response object.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MYFACES-3042) CCE: when running in portlet: Remove Servlet dependencies in FaceletViewDeclarationLanguage.java

2011-02-15 Thread Michael Freedman (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12994882#comment-12994882
 ] 

Michael Freedman commented on MYFACES-3042:
---

I have attached a potential patch -- Apologies for not just making the changes 
but (1) this change breaks an automated test that is part of the build as it 
seems the test environment doesn't provide its own stub impl of the new JSF 2.0 
ExternalContext methods that these changes rely on -- and I have no clue how to 
address those and (2) the various paperwork Oracle made me sign to allow me to 
participate in Apache only allows me to submit work related to the Portlet 
Bridge project -- MyFaces work has to be submitted by those from Oracle signed 
up to do that.

 CCE: when running in portlet: Remove Servlet dependencies in 
 FaceletViewDeclarationLanguage.java
 

 Key: MYFACES-3042
 URL: https://issues.apache.org/jira/browse/MYFACES-3042
 Project: MyFaces Core
  Issue Type: Bug
  Components: Portlet_Support
Affects Versions: 2.0.5-SNAPSHOT
Reporter: Michael Freedman
 Attachments: jira-myfaces-3042.patch


 In FaceletViewDeclarationLanguage.java: createResponseWriter(), 
 getResponseEncoding(), handleFaceletNotFound(), and sendSourceNotFound() each 
 cast to Servlet object.  This causes ClassCastExceptions when run in a 
 portlet environment.  Each of these calls/casts can be removed and 
 ExternalContext APIs can be used instead to get/set the needed information 
 from the request or response object.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MYFACES-3045) jsf.js jsf.ajax.request doesn't resolve calling URL correctly -- ajax use in portlets broken

2011-02-15 Thread Michael Freedman (JIRA)

jsf.js jsf.ajax.request doesn't resolve calling URL correctly -- ajax use in 
portlets broken


 Key: MYFACES-3045
 URL: https://issues.apache.org/jira/browse/MYFACES-3045
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.5-SNAPSHOT
Reporter: Michael Freedman


Javadoc for jsf.ajax.request says you determine the calling URL by:
Determine the posting URL as follows: If the hidden field 
javax.faces.encodedURL is present in the submitting form, use its value as the 
posting URL. Otherwise, use the action property of the form element as the URL.

Looks like the MyFaces impl skips loking for/using the javax.faces.encodedURL 
and only uses the form action.  This means ajax is broken in portlets (when 
using MyFaces).  I.e. the  javax.faces.encodedURL in the portlet case is 
different than the action URL and the one that needs to be used.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (PORTLETBRIDGE-183) Potential NPE in FacesContext.release

Potential NPE in FacesContext.release
-

 Key: PORTLETBRIDGE-183
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-183
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
Affects Versions: 2.0.0, 1.0.0, 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman


The Bridge's FacesContext.release dereferences the return from 
request.getAttribute(BridgeImpl.PREEXISTING_ATTRIBUTE_NAMES) without checking 
to see if its null.  Now it would only be null if the bridge didn't 
create/release FC but there seems to be at least one situation in which this 
has occurred and in any case the code should be written correctly to avoid the 
potential problem/NPE.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MYFACES-3042) CCE: when running in portlet: Remove Servlet dependencies in FaceletViewDeclarationLanguage.java

CCE: when running in portlet: Remove Servlet dependencies in 
FaceletViewDeclarationLanguage.java


 Key: MYFACES-3042
 URL: https://issues.apache.org/jira/browse/MYFACES-3042
 Project: MyFaces Core
  Issue Type: Bug
  Components: Portlet_Support
Affects Versions: 2.0.5-SNAPSHOT
Reporter: Michael Freedman


In FaceletViewDeclarationLanguage.java: createResponseWriter(), 
getResponseEncoding(), handleFaceletNotFound(), and sendSourceNotFound() each 
cast to Servlet object.  This causes ClassCastExceptions when run in a portlet 
environment.  Each of these calls/casts can be removed and ExternalContext APIs 
can be used instead to get/set the needed information from the request or 
response object.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Reopened: (MYFACES-3039) MyFaces broken in Portlet environment: Fails to support extendable FacesContextFactory/FacesContext/ExternalContext

[
https://issues.apache.org/jira/browse/MYFACES-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Freedman reopened MYFACES-3039:
---

Can you clarify what the defaultExternalContext is being used for? On portlet
requests this seemingly won't be set/used as its the Bridge's ExternalContext
that is in use not the core MyFaces one (which does the attribute put that
causes this default stuff to be enabled). Basically, I am trying to ensure
there isn't a problem in the portlet env in not participating in this mechanism.

MyFaces broken in Portlet environment: Fails to support extendable
FacesContextFactory/FacesContext/ExternalContext

Key: MYFACES-3039
URL: https://issues.apache.org/jira/browse/MYFACES-3039
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Reporter: Michael Freedman
Assignee: Leonardo Uribe
Fix For: 2.0.5-SNAPSHOT

JSF 2.0 improved the definition/handling of the instantiation of the
FacesContext allowing non-servlet environments to wrap the base/core impl.
This was done because most of the FacesContext apis are inherently runtime
environment neutral -- allowing the portlet bridge to not have to
duplicate/reimplement and maybe get wrong base core function. Unfortunately
MyFaces doesn't conform to this change and hence the Portlet Bridge can't run
in the MyFaces environment.
Basically the bridge expects to be able to delegate from its
FacesContextFactoryImpl.getFacesContext and then wrap the returned
FacesContext with its own. This requires the underlying core impl to be
runtime (servlet/portlet) neutral during the creation process. The bridge
will wrap the FacesContext and supply its own ExternalContext such that any
servlet dependent impl in the core FacesContext/ExternalContext will be
hidden by overrides.
FYI ... until this is addressed I can't begin any testing of the bridge on
MyFaces.

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MYFACES-3042) CCE: when running in portlet: Remove Servlet dependencies in FaceletViewDeclarationLanguage.java


[ 
https://issues.apache.org/jira/browse/MYFACES-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12994511#comment-12994511
 ] 

Michael Freedman commented on MYFACES-3042:
---

FYI ... when you make these changes it looks like you will also have to 
implement an ExternalContext (stub) to use in the test harness as one doesn't 
seem to exist at the moment -- and these new 2.0 methods through an exception 
(from the javax.faces.context impl) if not implemented.

 CCE: when running in portlet: Remove Servlet dependencies in 
 FaceletViewDeclarationLanguage.java
 

 Key: MYFACES-3042
 URL: https://issues.apache.org/jira/browse/MYFACES-3042
 Project: MyFaces Core
  Issue Type: Bug
  Components: Portlet_Support
Affects Versions: 2.0.5-SNAPSHOT
Reporter: Michael Freedman

 In FaceletViewDeclarationLanguage.java: createResponseWriter(), 
 getResponseEncoding(), handleFaceletNotFound(), and sendSourceNotFound() each 
 cast to Servlet object.  This causes ClassCastExceptions when run in a 
 portlet environment.  Each of these calls/casts can be removed and 
 ExternalContext APIs can be used instead to get/set the needed information 
 from the request or response object.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (MYFACES-3039) MyFaces broken in Portlet environment: Fails to support extendable FacesContextFactory/FacesContext/ExternalContext

2011-02-09 Thread Michael Freedman (JIRA)

[
https://issues.apache.org/jira/browse/MYFACES-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12992575#comment-12992575
]

Michael Freedman commented on MYFACES-3039:
---

I have to respectively disagree. The only servlet dependency I see in the
MyFaces FacesContextImpl I see is in the special constructor code used to
self create an external context. Isn't this a holdover from the JSF 1.2
pattern? In JSF 2.0 things were reorganized so the ExternalContext is
constructed from a factory and passed to the FacesContext constructor -- ala:
FacesContext ctx =
new FacesContextImpl(
externalContextFactory.getExternalContext(sc, request,
response),
lifecycle);

This allows the FacesContext to be environment neutral (all environmental stuff
is within the ExternalContext) -- and with the new FacesContext wrapper its now
easy for the bridge to wrap the core context and only override the few method
it changes.

What is the rationale for the MyFaces model and runtime dependency? If some of
that rationale needs to be maintained, can't it be isolated to the circumstance
it pertains to and the more general pattern (runtime neutral) be utilized in
other cases (like the bridge)?

Basically, what I am arguing is that the model supported by the spec and
implemented by Mojarra seems to be a general/broad model and should be
supported by MyFaces -- and if improvements can be made for specific
situations, so be it, but handle as such without penalizing the general.

MyFaces broken in Portlet environment: Fails to support extendable
FacesContextFactory/FacesContext/ExternalContext

Key: MYFACES-3039
URL: https://issues.apache.org/jira/browse/MYFACES-3039
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Reporter: Michael Freedman

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (PORTLETBRIDGE-174) Portlet Bridge 3.0.0 -- PortletViewHandler.render needs to reference MimeResponse after the check for portlet request


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-174.


Resolution: Fixed

See comment above ...

 Portlet Bridge 3.0.0 -- PortletViewHandler.render needs to reference 
 MimeResponse after the check for portlet request
 -

 Key: PORTLETBRIDGE-174
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-174
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 3.0.0-alpha


 or else you get a ClassCastException when run as a servlet.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (PORTLETBRIDGE-175) Bridge phase listeners have portlet dependecy but can be executed in a servlet request yielding ClassCastException

[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Freedman resolved PORTLETBRIDGE-175.

Resolution: Fixed
Fix Version/s: 3.0.0-alpha

As suggested, modified code to ensure we are in a Portlet request before
executing phase listener.

Bridge phase listeners have portlet dependecy but can be executed in a
servlet request yielding ClassCastException
--

Key: PORTLETBRIDGE-175
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-175
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 1.0.0, 2.0.0, 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
Fix For: 3.0.0-alpha

The Bridge temporarily installs its own phase listeners to provide a variety
of behaviors . As phase listeners are controlled by the lifecycle and there
(can be) is only 1 lifecycle instance per application all listeners are
called whenever the lifecycle is run. Because you can have distinct portlets
in a application and the application can also run as a servlet care must be
taken to only execute the phase listener if its truly the target of the
execution. The bridge properly handles this for the multiple portlet case by
checking that the event's FacesContext is the same as the thread's (current
instances). Unfortunately this doesn't prevent the code from executing in
the servlet case. I.e. if a portlet request comes in an is being processed
by the bridge it will install the phase listener. If a second request
happens concurrently but accesses this app as a servlet, we will execute the
bridge's phase listener in this servlet request. This results in a
ClassCastException as the code accesses the request object as a
PortletRequest (but its not).
Simple fix is to expand the test to only execute the phase listener is the
FacesContext instance match and its a Portlet request.

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (PORTLETBRIDGE-176) encodeActionURL must properly encode urls containing fragment references (#)


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-176.


   Resolution: Fixed
Fix Version/s: 3.0.0-alpha

partially fixed:  code now at least can deal with incoming URLs containing # 
fragments.  I.e. the utility code that parses this now recognizes the fragment 
portion separately from the parameter portion.  The thing is that that 
fragments in URLs are essentially thrown away/ignored as the portlet spec 
provides no way to encode them into the generated URL.

 encodeActionURL must properly encode urls containing fragment references (#)
 

 Key: PORTLETBRIDGE-176
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-176
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0, 2.0.0, 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 3.0.0-alpha


 Currently encodeActionURL (and encodeResourceURL?)  don't handle (deal with 
 properly) urls that contain fragment references (#).  What we should do is 
 parse the # and for now just throw it away.  The portlet spec doesn't 
 deal with fragments -- though something might work with local portlets -- 
 wsrp/remote portlets using consumer rewriting will not work.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (PORTLETBRIDGE-177) Portlet Bridge 3.0.0 -- Support Bookmarkable URLs


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-177.


   Resolution: Fixed
Fix Version/s: 3.0.0-alpha

Code modified so encodeBookmarkableURL adds a special QS marker indicating its 
a bookmark url.  This param is generally set with a value of true.  When set 
with a value of false, it still signals a renderURL but one which should 
include the request scope (i.e. a redisplay vs a bookmark url).

 Portlet Bridge 3.0.0 -- Support Bookmarkable URLs
 -

 Key: PORTLETBRIDGE-177
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-177
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 3.0.0-alpha


 Faces 2.0 has support for bookmarkableURLs, and is implemented by first 
 calling ExternalContext.encodeBookMarkableUrl followed by encodeActionURL.  
 Birdge needs to 
   a) provide an implementation for encodeBookmarkableUrl -- this impl needs 
 to add a parameter to the query string that signals the Bridge's 
 encodeActionUrl to use a renderURL
   b) modify encodeActionUrl to recognize/use the special parameter and create 
 a renderUrl
 Note:  to make this generic -- we should define a constant for this special 
 parameter in javax.portlet.faces.Bridge

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (PORTLETBRIDGE-178) Portlet Bridge 3.0.0 -- Support Views using Ajax that reference component ids (in the execute or render id list)

[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Freedman resolved PORTLETBRIDGE-178.

Resolution: Fixed
Fix Version/s: 3.0.0-alpha

As suggested in original comment -- added the PartialViewContext Impl and do
the extra resolution when needed.

Portlet Bridge 3.0.0 -- Support Views using Ajax that reference component ids
(in the execute or render id list)

Key: PORTLETBRIDGE-178
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-178
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
Fix For: 3.0.0-alpha

The Faces 2.0 ajax javascript signature takes two parameters that allow you
to identify the targets of the action and the render. Many samples, (and
hence commonly) set these ids statically. This breaks when run in a
portlet/bridge environment because the bridge wraps the entire tree with its
own UIViewRoot which adds a NamingContainer to ensure are ids are unique in
an overall portal page. I.e. its NC prefix is prepended to the component id.

So the problem is the request sends ids x, y, z while the tree contains nc.x,
nc,y, nc.z. hence the ids aren't found and nothing is executed/rendered.
Fix is to write our own PartialViewContext which overrides getRenderIds() and
getExecuteIds() and take all the ids that don't resolve and retry them with
the nc id prepended.

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (PORTLETBRIDGE-179) Portlet Bridge 3.0.0 -- Mojarra 2.0 contains some FacesContext attributed that expect to be held for a full lifecycle

[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Freedman resolved PORTLETBRIDGE-179.

Resolution: Fixed
Fix Version/s: 3.0.0-alpha

Modfied code so you can configure the portlet via an init parameter with a
specific set of FacesContext attributes that should be carried from the action
to the render. For these samples I configure with the two attributes needed to
get the Facelets (render) restore to work properly.

Portlet Bridge 3.0.0 -- Mojarra 2.0 contains some FacesContext attributed
that expect to be held for a full lifecycle
-

Key: PORTLETBRIDGE-179
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-179
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
Fix For: 3.0.0-alpha

In the situation that a ViewRoot isn't being restored by Faces (i.e. the
client/bridge pushes an existing ViewRoot into the FacesContext prior to
calling restore), and the application has composite components (and hence
using Facelets), the restore/subsequent save gets all screwed up because to
work properly Faces expects a couple of FacesContext attributes to also be
set at this time.
I.e. in the bridge at the end of the action phase we release the FacesContext
-- this causes attrs to be lost. However we hold onto the ViewRoot (because
we can't Faces save it) in a in-memory cache. In the subsequent render we
push this viewRoot back into the facesContext before we call restoreView.
When the Faces view contains composite components things go off the rails
(because it expects the FacesContext to contain two attributes (one keyed
with the viewRoot object of the current view (value -- boolean = true) and
another keyed with com.sun.faces.FACELET_FACTORY).
FYI ... I have contacted the Mojarra team to determine whether they will
consider this a bug on their side or not. However to workaround in existing
versions I should add a new portlet initParam (maybe something that can be
added to the faces-config as well -- but we will wait on the Mojarra guys
first) that allows you to name a list of attributes that should be preserved.
Then change the code to preserve and restore only those attributes that are
requested in this config.

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (PORTLETBRIDGE-180) Portlet Bridge 3.0.0 -- Update extension to view mapping to account for JSF 2.0 support of a list of mappable extensions


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-180.


   Resolution: Fixed
Fix Version/s: 3.0.0-alpha

Code now parses the list (vs assuming only one) and tries each to see if the 
resource exists when converting from .jsf (etc) to the actual valid suffix.

 Portlet Bridge 3.0.0 -- Update extension to view mapping to account for JSF 
 2.0 support of a list of mappable extensions
 

 Key: PORTLETBRIDGE-180
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-180
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
 Fix For: 3.0.0-alpha


 In JSF 2.0 an application can define multiple suffixes that are recognized as 
 being processed by Faces (whereas in 1.2 you only had one).  This means 
 translating a viewId to an url requires walking this list and seeing if the 
 underlying resource exists -- Also need vice-versa support.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (PORTLETBRIDGE-181) Portlet Bridge 3.0.0 -- Need to add impls for ExternalContext methods not currently implemented


 [ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Freedman resolved PORTLETBRIDGE-181.


Resolution: Fixed

Added each of these methods.

 Portlet Bridge 3.0.0 -- Need to add impls for ExternalContext methods not 
 currently implemented
 ---

 Key: PORTLETBRIDGE-181
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-181
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman

 These include:
setResponseBufferSize
setResponseContentLength
getResponseBufferSize
responseFlushBuffer
responseSendError

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (PORTLETBRIDGE-182) Portlet Bridge 3.0.0 -- renderURLs shouldn't carry forward scope by default

Portlet Bridge 3.0.0 -- renderURLs shouldn't carry forward scope by default
---

 Key: PORTLETBRIDGE-182
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-182
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman


Late in the game the bridge impl changed (2.0) whereby a bridge scope is always 
created on any request that there isn't one (in the case you are in a render or 
resource request we cache this in a session attr).  Because of this renderURLs 
created via encodeActionURL might retain their scopes across submissions.  This 
doesn't seem like the reasonable default.  With Portlet 3.0.0 they added a 
concept of a bookmarkable url -- which makes it more common for a faces app to 
create a render url (prior versions could only do it using the special 
portlet:render? syntax).  So we need to fix the encodeActionURL to mark 
renderURLs as not preserving the scope.  

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (PORTLETBRIDGE-182) Portlet Bridge 3.0.0 -- renderURLs shouldn't carry forward scope by default

[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael Freedman resolved PORTLETBRIDGE-182.

Resolution: Fixed
Fix Version/s: 3.0.0-alpha

I leveraged the special QS param that signals to encodeActionURL that its
encoding a bookmarkable url. If the value of this QS param is true then the
scope isn't preserved (we add a new different param to the url being generated
that is recognized in the bridge's render) If the value is false we still
create the render url but without this extra param -- hence the bridge will
preserve the scope. This later is done/supported as TCK tests rely on this to
do render redisplays (within the scope).

Portlet Bridge 3.0.0 -- renderURLs shouldn't carry forward scope by default
---

Key: PORTLETBRIDGE-182
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-182
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 3.0.0-alpha
Reporter: Michael Freedman
Assignee: Michael Freedman
Fix For: 3.0.0-alpha

Late in the game the bridge impl changed (2.0) whereby a bridge scope is
always created on any request that there isn't one (in the case you are in a
render or resource request we cache this in a session attr). Because of this
renderURLs created via encodeActionURL might retain their scopes across
submissions. This doesn't seem like the reasonable default. With Portlet
3.0.0 they added a concept of a bookmarkable url -- which makes it more
common for a faces app to create a render url (prior versions could only do
it using the special portlet:render? syntax). So we need to fix the
encodeActionURL to mark renderURLs as not preserving the scope.

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MYFACES-3038) MyFaces fails to recognize ViewDeclarationLanguageFactory when defined in META-INF/services -- throws IllegalStateException instead

MyFaces fails to recognize ViewDeclarationLanguageFactory when defined in 
META-INF/services -- throws IllegalStateException instead
---

 Key: MYFACES-3038
 URL: https://issues.apache.org/jira/browse/MYFACES-3038
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-314
Affects Versions: 2.0.3
Reporter: Michael Freedman


Spec says a factory can be declared by including a META-INF/services file with 
the name of the javax.faces factory class (in this case 
java.faces.view.ViewDeclarationLanguageFactory ) with its contents containing a 
single line containing the name of the class that implements this factory.  The 
MyFaces startup/read config code throws an IllegalStateException however in 
this case.  Looks like the code wasn't updated to reflect the new 2.0 Factory.

Use case -- Portlet Bridge currently uses this methodology and hence doesn't 
run on MyFaces.  

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MYFACES-3039) MyFaces broken in Portlet environment: Fails to support extendable FacesContextFactory/FacesContext/ExternalContext