Re: [VOTE] Release of Apache MyFaces Trinidad 2.1.0
+1 On 11/15/2013 4:02 PM, Scott O'Bryan wrote: Hello everyone, I was running the tasks needed to release Apache MyFaces Trinidad v. 2.1.0 which is the latest in the Trinidad render kit series. This is the first release in over a year and contains over a hundred bug fixes since the last release. All Blocker bugs are currently fixed and all patches request by the community have been applied. All tests are passing as is the apache-rat:check. I have generated the tag [1] and have deployed the build artifacts to nexus [2]. I have also included the source archive [3]. Please take a look at the Apache MyFaces Trinidad v. 2.1.0 release artifacts and vote. Please note: This vote is majority approval with a minimum of three +1 votes (see [4]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott O'Bryan [1] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.1.0 [2] https://repository.apache.org/content/repositories/orgapachemyfaces-141 [3] https://repository.apache.org/content/repositories/orgapachemyfaces-141/org/apache/myfaces/trinidad/trinidad/2.1.0/trinidad-2.1.0-source-release.zip [4] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: [Trinidad] Anyone care to review fix for TRINIDAD-2410?
+1 On 8/26/2013 11:06 AM, Andy Schwartz wrote: Gang - I encountered this issue with UIXEditableValue recently: https://issues.apache.org/jira/browse/TRINIDAD-2410 UIXEditableValue includes the following two property key definitions: static public final PropertyKey LOCAL_VALUE_SET_KEY = TYPE.registerKey(localValueSet, Boolean.class); static public final PropertyKey SUBMITTED_VALUE_KEY = TYPE.registerKey(submittedValue); Note that although neither of these property keys support EL binding, the property key definitions fail to specify the PropertyKey.CAP_NOT_BOUND capability. We should specify this to avoid unnecessary lookups in the ValueExpression map. Anyone want to review the patch here: https://issues.apache.org/jira/secure/attachment/12599951/trinidad-2410.patch Before I commit? Seems like a trivial issue and fix, but wouldn't mind a second pair of eyes on it. Andy
[jira] [Created] (TRINIDAD-2368) getFacets().values().remove(component) does not fire REVOVE component system event
Max Starets created TRINIDAD-2368: - Summary: getFacets().values().remove(component) does not fire REVOVE component system event Key: TRINIDAD-2368 URL: https://issues.apache.org/jira/browse/TRINIDAD-2368 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets getFacets().values().remove(component) does not fire the REMOVE event, but getFacets().remove(key) does. This is happening because FacetHashMap in Trinidad only overrides remove() and clear(), but provides no hooks for removal via an entry set or an iterator. Note that Mojarra's UIComponentBase does the right thing -- 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] (TRINIDAD-2369) Mojarra 2.1.18 partial state saving incompatibility when moving a facet
Max Starets created TRINIDAD-2369: - Summary: Mojarra 2.1.18 partial state saving incompatibility when moving a facet Key: TRINIDAD-2369 URL: https://issues.apache.org/jira/browse/TRINIDAD-2369 Project: MyFaces Trinidad Issue Type: Bug Environment: Mojarra 2.1.18 Reporter: Max Starets To reproduce the issue, create a test application doing the following during invoke_application: 1) Move a component to be a facet of some other component: newParent.getFacets().put(center, component1); 2) Move the component to its original parent: originalParent.getChildren().add(component1); Note that the following exception will be thrown by Mojarra: javax.faces.FacesException: Cannot add the same component twice: o1 at com.sun.faces.context.StateContext$AddRemoveListener.handleAddRemoveWithAutoPrune(StateContext.java:528) at com.sun.faces.context.StateContext$AddRemoveListener.handleAdd(StateContext.java:437) at com.sun.faces.context.StateContext$AddRemoveListener.processEvent(StateContext.java:359) at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) at com.sun.faces.application.ApplicationImpl.processListenersAccountingForAdds(ApplicationImpl.java:2210) at com.sun.faces.application.ApplicationImpl.invokeViewListenersFor(ApplicationImpl.java:2031) at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:292) at org.apache.myfaces.trinidad.component.UIXComponentBase._publishPostAddToViewEvent(UIXComponentBase.java:1597) at org.apache.myfaces.trinidad.component.UIXComponentBase.setParent(UIXComponentBase.java:701) at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:66) at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:73) at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:36) -- 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] (TRINIDAD-2369) Mojarra 2.1.18 partial state saving incompatibility when moving a facet
[ https://issues.apache.org/jira/browse/TRINIDAD-2369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13589932#comment-13589932 ] Max Starets commented on TRINIDAD-2369: --- This issue is a manifestation of TRINIDAD-2368. Because teh REMOVE event is not fired when the component is moved out of the facet, Mojarra's partial code sees two consequitive ADD events for the same component. Mojarra 2.1.18 partial state saving incompatibility when moving a facet --- Key: TRINIDAD-2369 URL: https://issues.apache.org/jira/browse/TRINIDAD-2369 Project: MyFaces Trinidad Issue Type: Bug Environment: Mojarra 2.1.18 Reporter: Max Starets To reproduce the issue, create a test application doing the following during invoke_application: 1) Move a component to be a facet of some other component: newParent.getFacets().put(center, component1); 2) Move the component to its original parent: originalParent.getChildren().add(component1); Note that the following exception will be thrown by Mojarra: javax.faces.FacesException: Cannot add the same component twice: o1 at com.sun.faces.context.StateContext$AddRemoveListener.handleAddRemoveWithAutoPrune(StateContext.java:528) at com.sun.faces.context.StateContext$AddRemoveListener.handleAdd(StateContext.java:437) at com.sun.faces.context.StateContext$AddRemoveListener.processEvent(StateContext.java:359) at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) at com.sun.faces.application.ApplicationImpl.processListenersAccountingForAdds(ApplicationImpl.java:2210) at com.sun.faces.application.ApplicationImpl.invokeViewListenersFor(ApplicationImpl.java:2031) at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:292) at org.apache.myfaces.trinidad.component.UIXComponentBase._publishPostAddToViewEvent(UIXComponentBase.java:1597) at org.apache.myfaces.trinidad.component.UIXComponentBase.setParent(UIXComponentBase.java:701) at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:66) at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:73) at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:36) -- 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] [Updated] (TRINIDAD-2369) Mojarra 2.1.18 partial state saving incompatibility when moving a facet
[ https://issues.apache.org/jira/browse/TRINIDAD-2369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2369: -- Status: Patch Available (was: Open) Mojarra 2.1.18 partial state saving incompatibility when moving a facet --- Key: TRINIDAD-2369 URL: https://issues.apache.org/jira/browse/TRINIDAD-2369 Project: MyFaces Trinidad Issue Type: Bug Environment: Mojarra 2.1.18 Reporter: Max Starets Attachments: TRINIDAD-2369.patch To reproduce the issue, create a test application doing the following during invoke_application: 1) Move a component to be a facet of some other component: newParent.getFacets().put(center, component1); 2) Move the component to its original parent: originalParent.getChildren().add(component1); Note that the following exception will be thrown by Mojarra: javax.faces.FacesException: Cannot add the same component twice: o1 at com.sun.faces.context.StateContext$AddRemoveListener.handleAddRemoveWithAutoPrune(StateContext.java:528) at com.sun.faces.context.StateContext$AddRemoveListener.handleAdd(StateContext.java:437) at com.sun.faces.context.StateContext$AddRemoveListener.processEvent(StateContext.java:359) at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106) at com.sun.faces.application.ApplicationImpl.processListenersAccountingForAdds(ApplicationImpl.java:2210) at com.sun.faces.application.ApplicationImpl.invokeViewListenersFor(ApplicationImpl.java:2031) at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:292) at org.apache.myfaces.trinidad.component.UIXComponentBase._publishPostAddToViewEvent(UIXComponentBase.java:1597) at org.apache.myfaces.trinidad.component.UIXComponentBase.setParent(UIXComponentBase.java:701) at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:66) at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:73) at org.apache.myfaces.trinidad.component.ChildArrayList.add(ChildArrayList.java:36) -- 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] (TRINIDAD-2347) JSESSIONID is not send with the first response
[ https://issues.apache.org/jira/browse/TRINIDAD-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets resolved TRINIDAD-2347. --- Resolution: Fixed JSESSIONID is not send with the first response -- Key: TRINIDAD-2347 URL: https://issues.apache.org/jira/browse/TRINIDAD-2347 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.1-core Reporter: Max Starets Assignee: Max Starets To reproduce the issue, create a Facelets page with a form producing fairly large (~50K) HTML content. Notice that the response for the initial GET does not send JSESSIONID to the client. This is happening because the session is 'touched' by the state saving code after the response headers have been committed to the client. The fix would be to 'touch' the session before rendering begins -- 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] [Updated] (TRINIDAD-2216) The partialSubmit does not work with JSF 2 RI
[
https://issues.apache.org/jira/browse/TRINIDAD-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Starets updated TRINIDAD-2216:
--
Resolution: Fixed
Fix Version/s: 2.1.0-core
Status: Resolved (was: Patch Available)
The partialSubmit does not work with JSF 2 RI
-
Key: TRINIDAD-2216
URL: https://issues.apache.org/jira/browse/TRINIDAD-2216
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0-core
Environment: Mojarra 2.1.6 (SNAPSHOT 20111206)
Glassfish 3.1.1
Trinidad 2.0.0
Reporter: Tomas Havelka
Fix For: 2.1.0-core
Attachments: TRINIDAD-2216-2259-2302.patch, TRINIDAD-2216.patch
Trinidad's partialSubmit does not work because the source parameter passed in
the jsf.ajax.request call is null. See XMLRequest.js on the line 358. The
source is part of the payload but is not assigned to the source parameter
itself. It causes the RI implementation of jsf.ajax.request throws an error
because of this code in it:
if (typeof source === 'undefined' || source === null) {
throw new Error(jsf.ajax.request: source not set);
}
--
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] [Updated] (TRINIDAD-2259) Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true
[ https://issues.apache.org/jira/browse/TRINIDAD-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2259: -- Resolution: Fixed Fix Version/s: 2.1.0-core Status: Resolved (was: Patch Available) Fixed by TRINIDAD-2216 Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true -- Key: TRINIDAD-2259 URL: https://issues.apache.org/jira/browse/TRINIDAD-2259 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.1-core Environment: mojarra 2.0.9 Reporter: Daniel Charczynski Assignee: Max Starets Priority: Critical Fix For: 2.0.2-core, 2.1.0-core launchDialog.xhtml from examples doesn't work as facelet problem with ReturnEvent There is simple way to reproduce this issue 1 download trinidad 2.0.1 examples http://www.apache.org/dyn/closer.cgi/myfaces/binaries/trinidad-2.0.1-example.zip 2. download and extract tomcat 6.x 3. put mojarra 2.0.9 into tomcat libs 4. put jstl 1.2.1 api and impl libs into tomcat libs do some changes in trinidad-demo.war 5. copy launchDialog.jspx to launchDialog.xhtml 6 change jsp:root tag of launchDialog.xhtml to ui:composition xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; xmlns:trd=http://myfaces.apache.org/trinidad/demo; xmlns:trh=http://myfaces.apache.org/trinidad/html; and end jsp:root to ui:composition 7. deploy trinidad-demo.war and start server 8. go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml and clickAdd button - should not work :( IT WILL WORK WHEN - go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml - click (first ellipsis button) - close popup - Click Add button :) important thing is to go load http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml page directly from browser - every test - in order to clear all parameters simillar issue is when you change javax.faces.FACELETS_VIEW_MAPPINGS to *.jspx and go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.jspx -- 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] [Updated] (TRINIDAD-2334) Dialog popup returns with error, if called from commandButton with partial submit
[
https://issues.apache.org/jira/browse/TRINIDAD-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Starets updated TRINIDAD-2334:
--
Resolution: Fixed
Fix Version/s: (was: 2.0.2-core)
Status: Resolved (was: Patch Available)
Fixed by TRINIDAD-2216
Dialog popup returns with error, if called from commandButton with partial
submit
-
Key: TRINIDAD-2334
URL: https://issues.apache.org/jira/browse/TRINIDAD-2334
Project: MyFaces Trinidad
Issue Type: Bug
Components: Build
Affects Versions: 2.0.1-core
Environment: Tomcat 7.0.32, Mojarra 2.0.9, Trinidad 2.0.1, Internet
Explorer 8, FireFox 15
Reporter: Robert Schoch
Assignee: Max Starets
Priority: Blocker
Labels: patch
Fix For: 2.1.0-core
Attachments: patch-for-XMLRequest.diff
Dialog launch in XHTML pages works fine and the components with
partialTriggers are updated.
But after return from dialog the following error message appears:
Error calling TrPanelPopup callback function:
Error: jsf.ajax.request: source not set
Then nothing happens more, no components are updated and the page is blocked
for about 10 seconds.
This is a Sample for the dialog launch page:
tr:document xmlns=http://www.w3.org/1999/xhtml;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
id=HtmlDocument mode=strict title=Test Dialog Launcher
tr:form id=TestForm
tr:panelButtonBar id=ButtonBar
inlineStyle=margin-left:auto;margin-right:auto;
tr:commandButton id=launchButton text=Launch Dialog
action=dialog:confirm
useWindow=true windowWidth=280 windowHeight=120
partialSubmit=true
launchListener=#{dialogController.dialogLaunchListener}
returnListener=#{dialogController.dialogReturnListener} /
/tr:panelButtonBar
tr:panelBox id=infoPanel text=Last Action
partialTriggers=launchButton
inlineStyle=margin-left:auto;margin-right:auto;
tr:outputText id=lastAction value=#{dialogController.lastAction}
/
/tr:panelBox
/tr:form
/tr:document
This is the dialog page:
tr:document xmlns=http://www.w3.org/1999/xhtml;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
id=HtmlDocument mode=strict title=Test Dialog
tr:form id=DialogForm
tr:outputText id=dialogMessage value=hello from dialog /
tr:panelButtonBar id=buttonBar
inlineStyle=width:auto;margin-left:auto;margin-right:auto;
tr:commandButton id=okButton text=OK
actionListener=#{dialogController.dialogActionListener}/
tr:commandButton id=cancelButton text=Cancel
actionListener=#{dialogController.dialogActionListener}/
/tr:panelButtonBar
/tr:form
/tr:document
And this is the dialog controller:
package de.ospkdd.sample;
import java.io.Serializable;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
import javax.faces.event.ActionEvent;
import org.apache.myfaces.trinidad.context.RequestContext;
import org.apache.myfaces.trinidad.event.LaunchEvent;
import org.apache.myfaces.trinidad.event.ReturnEvent;
@ManagedBean
@SessionScoped
public class DialogController implements Serializable {
private static final long serialVersionUID = -23121260063689204L;
private String lastAction = ???;
public DialogController() {}
public void dialogLaunchListener(LaunchEvent event) {
lastAction = dialog launched...;
}
public void dialogActionListener(ActionEvent event) {
RequestContext.getCurrentInstance().returnFromDialog(
event.getComponent().getId(), null);
lastAction = button clicked...;
}
public void dialogReturnListener(ReturnEvent event) {
lastAction = dialog returned: + (String)event.getReturnValue();
}
public String getLastAction() {
return lastAction;
}
}
--
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
Re: Trinidad commit question
Werner, Thanks! I will take care of TRINIDAD-2302 soon. Thinking a bit more about it, the issue is a bit different from TRINIDAD-2216 (one case has an explicit f:ajax, and the other performs legacy Trinidad PPR over JSF Ajax). Most likely, we will need both the check for the Ajax behavior and the javascript-based solution that will take care of the legacy Trinidad PPR. Max On 1/9/2013 8:40 AM, Werner Punz wrote: Ok Max first of all thanks for letting me in. I now have applied most of the patches with the exception of TRINIDAD-2302 which as requested now is assigned to you, TRINIDAD-2252 (which already was implemented) and TRINIDAD-2307 there I am not sure if the patch is correct, it looks incorrect to me but I lack the deeper knowledge there. Can anyone have a quick look at it, if it is correct? Thanks a lot Werner Punz Am 08.01.13 15:41, schrieb Max Starets: Hey Werner, First, huge thanks for helping us out when we are swamped with working on other projects! Regarding TRINIDAD-2302: this is indeed a duplicate of TRINIDAD-2216, and the patch for TRINIDAD-2302 seems to be better than the proposed patch for TRINIDAD-2216. However, I wonder whether we could use an even more optimized approach: since the ID is known in the Javascript method that ultimately calls jsf.ajax.request(), could we just add the ID in Javascript code on the fly if one is not present? This way won't increase the content size (the ID is already rendered as part of the javascript event handler call, so with the patch for TRINIDAD-2302 we would be really rendering it twice). You can assign TRINIDAD-2302 to me, and I will take care of it within the next two weeks. However, if we need a fix urgently, I would not object to the current patch for TRINIDAD-2302 being committed. I am also +1 on the rest of the patches. Thanks, Max On 1/8/2013 3:43 AM, Werner Punz wrote: Hi following issues: TRINIDAD-2349: TreeRenderer renders double html ids https://issues.apache.org/jira/browse/TRINIDAD-2349 TRINIDAD-2348: HeadRenderer renders meta tags in wrong order for IE https://issues.apache.org/jira/browse/TRINIDAD-2348 TRINIDAD-2252: ViewDeclarationLanguageFactoryImpl$ChangeApplyingVDLWrapper does not override non-abstract retargetMethodExpressions() causing composite component actions not to fire https://issues.apache.org/jira/browse/TRINIDAD-2252 TRINIDAD-2302: source component of ajax request is rendered without id (causing javascript errors) https://issues.apache.org/jira/browse/TRINIDAD-2302 TRINIDAD-2303: State saving skips facets (component resources). https://issues.apache.org/jira/browse/TRINIDAD-2303 TRINIDAD-2307: Selectors that are classified as icons are not correctly added as style. https://issues.apache.org/jira/browse/TRINIDAD-2307 Werner Am 07.01.13 16:59, schrieb Max Starets: Hey Werner, Would you mind listing the JIRA issues? Thanks, Max On 1/7/2013 3:34 AM, Werner Punz wrote: Hello, I know I have committer rights, but since it is not a project I have not been actively involved in, I am asking first. The issue is, that there is a handful of patches in Jira which I want to merge into the main codebase of Trinidad which fix a number of annoying issues. Does anyone of the Trinidad devs have any objection that I do it? Werner
Re: Trinidad commit question
Hey Werner, First, huge thanks for helping us out when we are swamped with working on other projects! Regarding TRINIDAD-2302: this is indeed a duplicate of TRINIDAD-2216, and the patch for TRINIDAD-2302 seems to be better than the proposed patch for TRINIDAD-2216. However, I wonder whether we could use an even more optimized approach: since the ID is known in the Javascript method that ultimately calls jsf.ajax.request(), could we just add the ID in Javascript code on the fly if one is not present? This way won't increase the content size (the ID is already rendered as part of the javascript event handler call, so with the patch for TRINIDAD-2302 we would be really rendering it twice). You can assign TRINIDAD-2302 to me, and I will take care of it within the next two weeks. However, if we need a fix urgently, I would not object to the current patch for TRINIDAD-2302 being committed. I am also +1 on the rest of the patches. Thanks, Max On 1/8/2013 3:43 AM, Werner Punz wrote: Hi following issues: TRINIDAD-2349: TreeRenderer renders double html ids https://issues.apache.org/jira/browse/TRINIDAD-2349 TRINIDAD-2348: HeadRenderer renders meta tags in wrong order for IE https://issues.apache.org/jira/browse/TRINIDAD-2348 TRINIDAD-2252: ViewDeclarationLanguageFactoryImpl$ChangeApplyingVDLWrapper does not override non-abstract retargetMethodExpressions() causing composite component actions not to fire https://issues.apache.org/jira/browse/TRINIDAD-2252 TRINIDAD-2302: source component of ajax request is rendered without id (causing javascript errors) https://issues.apache.org/jira/browse/TRINIDAD-2302 TRINIDAD-2303: State saving skips facets (component resources). https://issues.apache.org/jira/browse/TRINIDAD-2303 TRINIDAD-2307: Selectors that are classified as icons are not correctly added as style. https://issues.apache.org/jira/browse/TRINIDAD-2307 Werner Am 07.01.13 16:59, schrieb Max Starets: Hey Werner, Would you mind listing the JIRA issues? Thanks, Max On 1/7/2013 3:34 AM, Werner Punz wrote: Hello, I know I have committer rights, but since it is not a project I have not been actively involved in, I am asking first. The issue is, that there is a handful of patches in Jira which I want to merge into the main codebase of Trinidad which fix a number of annoying issues. Does anyone of the Trinidad devs have any objection that I do it? Werner
Re: Trinidad commit question
Hey Werner, Would you mind listing the JIRA issues? Thanks, Max On 1/7/2013 3:34 AM, Werner Punz wrote: Hello, I know I have committer rights, but since it is not a project I have not been actively involved in, I am asking first. The issue is, that there is a handful of patches in Jira which I want to merge into the main codebase of Trinidad which fix a number of annoying issues. Does anyone of the Trinidad devs have any objection that I do it? Werner
Re: Apache Trinidad 2.0 - java.io.IOException: Not in GZIP format
Parthiv, I would try logging the state staring you are sending to the server. Perhaps something is happening during a previous request, and your test script is unable to extract javax.faces.ViewState parameter. You would get this message if the parameter value is empty. Max On 12/26/2012 6:28 AM, parthiv pradhan wrote: Hi, We have an application which is developed on Apache trinidad 2.0. we have the following setting in our web.xml - context-param param-namejavax.faces.STATE_SAVING_METHOD/param-name param-valueclient/param-value /context-param context-param param-nameorg.apache.myfaces.COMPRESS_STATE_IN_SESSION/param-name param-valuefalse/param-value /context-param context-param param-nameorg.apache.myfaces.SERIALIZE_STATE_IN_SESSION/param-name param-valuefalse/param-value /context-param context-param param-nameorg.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS/param-name param-value8/param-value /context-param context-param param-nameorg.apache.myfaces.trinidad.COMPRESS_VIEW_STATE/param-name param-valuetrue/param-value /context-param context-param param-nameorg.apache.myfaces.trinidad.CACHE_VIEW_ROOT/param-name param-valuefalse/param-value /context-param Any idea why In high load during performance test for 150 concurrent user following exceptions are thrown. 2012-12-25 21:17:45,190 SEVERE [org.apache.myfaces.trinidadinternal.renderkit.core.CoreResponseStateManager] (http-10.44.40.108-8280-3) java.io.IOException: Not in GZIP format at java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:154) at java.util.zip.GZIPInputStream.init(GZIPInputStream.java:75) at org.apache.myfaces.trinidadinternal.renderkit.core.CoreResponseStateManager._restoreSerializedView(CoreResponseStateManager.java:289) at org.apache.myfaces.trinidadinternal.renderkit.core.CoreResponseStateManager.getTreeStructureToRestore(CoreResponseStateManager.java:146) at javax.faces.render.ResponseStateManager.getState(ResponseStateManager.java:249) at org.apache.myfaces.trinidadinternal.renderkit.core.CoreResponseStateManager.getState(CoreResponseStateManager.java:69) at org.apache.myfaces.trinidadinternal.application.StateManagerImpl.restoreView(StateManagerImpl.java:764) at com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:123) at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:452) at org.apache.myfaces.trinidadinternal.application.ViewDeclarationLanguageFactoryImpl$ChangeApplyingVDLWrapper.restoreView(ViewDeclarationLanguageFactoryImpl.java:335) at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:148) at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:303) at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:303) at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:242) at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:192) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) 267801,11 99% thanks Parthiv
[jira] [Created] (TRINIDAD-2347) JSESSIONID is not send with the first RESPONSE
Max Starets created TRINIDAD-2347: - Summary: JSESSIONID is not send with the first RESPONSE Key: TRINIDAD-2347 URL: https://issues.apache.org/jira/browse/TRINIDAD-2347 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.1-core Reporter: Max Starets Assignee: Max Starets To reproduce the issue, create a Facelets page with a form producing fairly large (~50K) HTML content. Notice that the response for the initial GET does not send JSESSIONID to the client. This is happening because the session is 'touched' by the state saving code after the response headers have been committed to the client. The fix would be to 'touch' the session before rendering begins -- 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] (TRINIDAD-2259) Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true
[ https://issues.apache.org/jira/browse/TRINIDAD-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13512058#comment-13512058 ] Max Starets commented on TRINIDAD-2259: --- I will be working on TRINIDAD-2334 soon. Also filed a related issue TRINIDAD-2347 Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true -- Key: TRINIDAD-2259 URL: https://issues.apache.org/jira/browse/TRINIDAD-2259 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.1-core Environment: mojarra 2.0.9 Reporter: Daniel Charczynski Assignee: Max Starets Priority: Critical Fix For: 2.0.2-core launchDialog.xhtml from examples doesn't work as facelet problem with ReturnEvent There is simple way to reproduce this issue 1 download trinidad 2.0.1 examples http://www.apache.org/dyn/closer.cgi/myfaces/binaries/trinidad-2.0.1-example.zip 2. download and extract tomcat 6.x 3. put mojarra 2.0.9 into tomcat libs 4. put jstl 1.2.1 api and impl libs into tomcat libs do some changes in trinidad-demo.war 5. copy launchDialog.jspx to launchDialog.xhtml 6 change jsp:root tag of launchDialog.xhtml to ui:composition xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; xmlns:trd=http://myfaces.apache.org/trinidad/demo; xmlns:trh=http://myfaces.apache.org/trinidad/html; and end jsp:root to ui:composition 7. deploy trinidad-demo.war and start server 8. go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml and clickAdd button - should not work :( IT WILL WORK WHEN - go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml - click (first ellipsis button) - close popup - Click Add button :) important thing is to go load http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml page directly from browser - every test - in order to clear all parameters simillar issue is when you change javax.faces.FACELETS_VIEW_MAPPINGS to *.jspx and go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.jspx -- 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] [Reopened] (TRINIDAD-2259) Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true
[ https://issues.apache.org/jira/browse/TRINIDAD-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets reopened TRINIDAD-2259: --- Assignee: Max Starets Reopening this issue, since there are other problems with the dialog beyond the null source error in JSF Ajax implementation Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true -- Key: TRINIDAD-2259 URL: https://issues.apache.org/jira/browse/TRINIDAD-2259 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.1-core Environment: mojarra 2.0.9 Reporter: Daniel Charczynski Assignee: Max Starets Priority: Critical Fix For: 2.0.2-core launchDialog.xhtml from examples doesn't work as facelet problem with ReturnEvent There is simple way to reproduce this issue 1 download trinidad 2.0.1 examples http://www.apache.org/dyn/closer.cgi/myfaces/binaries/trinidad-2.0.1-example.zip 2. download and extract tomcat 6.x 3. put mojarra 2.0.9 into tomcat libs 4. put jstl 1.2.1 api and impl libs into tomcat libs do some changes in trinidad-demo.war 5. copy launchDialog.jspx to launchDialog.xhtml 6 change jsp:root tag of launchDialog.xhtml to ui:composition xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; xmlns:trd=http://myfaces.apache.org/trinidad/demo; xmlns:trh=http://myfaces.apache.org/trinidad/html; and end jsp:root to ui:composition 7. deploy trinidad-demo.war and start server 8. go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml and clickAdd button - should not work :( IT WILL WORK WHEN - go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml - click (first ellipsis button) - close popup - Click Add button :) important thing is to go load http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml page directly from browser - every test - in order to clear all parameters simillar issue is when you change javax.faces.FACELETS_VIEW_MAPPINGS to *.jspx and go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.jspx -- 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] (TRINIDAD-2259) Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true
[ https://issues.apache.org/jira/browse/TRINIDAD-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505969#comment-13505969 ] Max Starets commented on TRINIDAD-2259: --- The org.apache.myfaces.trinidadinternal.PPR_OVER_JSF_AJAX workaround would still apply though Serious problem with Facelets - launchDialog.xhtml from examples doesn't work as facelet - problem with partialSubmit=true -- Key: TRINIDAD-2259 URL: https://issues.apache.org/jira/browse/TRINIDAD-2259 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.1-core Environment: mojarra 2.0.9 Reporter: Daniel Charczynski Assignee: Max Starets Priority: Critical Fix For: 2.0.2-core launchDialog.xhtml from examples doesn't work as facelet problem with ReturnEvent There is simple way to reproduce this issue 1 download trinidad 2.0.1 examples http://www.apache.org/dyn/closer.cgi/myfaces/binaries/trinidad-2.0.1-example.zip 2. download and extract tomcat 6.x 3. put mojarra 2.0.9 into tomcat libs 4. put jstl 1.2.1 api and impl libs into tomcat libs do some changes in trinidad-demo.war 5. copy launchDialog.jspx to launchDialog.xhtml 6 change jsp:root tag of launchDialog.xhtml to ui:composition xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; xmlns:trd=http://myfaces.apache.org/trinidad/demo; xmlns:trh=http://myfaces.apache.org/trinidad/html; and end jsp:root to ui:composition 7. deploy trinidad-demo.war and start server 8. go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml and clickAdd button - should not work :( IT WILL WORK WHEN - go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml - click (first ellipsis button) - close popup - Click Add button :) important thing is to go load http://localhost:8080/trinidad-demo/faces/demos/launchDialog.xhtml page directly from browser - every test - in order to clear all parameters simillar issue is when you change javax.faces.FACELETS_VIEW_MAPPINGS to *.jspx and go to http://localhost:8080/trinidad-demo/faces/demos/launchDialog.jspx -- 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] (TRINIDAD-2256) Need to update WebKit capabilities for Android: History Management APIs are no longer suppprted
Need to update WebKit capabilities for Android: History Management APIs are no longer suppprted --- Key: TRINIDAD-2256 URL: https://issues.apache.org/jira/browse/TRINIDAD-2256 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.1-core Reporter: Max Starets Assignee: Max Starets See: http://caniuse.com/#search=history http://code.google.com/p/android/issues/detail?id=23979 Until the issues is fixed, we should update capability definitions to reflect that history management is no longer supported on Android -- 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] (TRINIDAD-2256) Need to update WebKit capabilities for Android: History Management APIs are no longer supported
[ https://issues.apache.org/jira/browse/TRINIDAD-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets resolved TRINIDAD-2256. --- Resolution: Fixed Fix Version/s: 2.1.0-core Need to update WebKit capabilities for Android: History Management APIs are no longer supported --- Key: TRINIDAD-2256 URL: https://issues.apache.org/jira/browse/TRINIDAD-2256 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.1-core Reporter: Max Starets Assignee: Max Starets Fix For: 2.1.0-core See: http://caniuse.com/#search=history http://code.google.com/p/android/issues/detail?id=23979 Until the issues is fixed, we should update capability definitions to reflect that history management is no longer supported on Android -- 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] (TRINIDAD-2255) Need to Expose ViewDeclarationLanguageWrapper
Need to Expose ViewDeclarationLanguageWrapper - Key: TRINIDAD-2255 URL: https://issues.apache.org/jira/browse/TRINIDAD-2255 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Max Starets Assignee: Max Starets Until we upgrade to JSF 2.2, we need to expose ViewDeclarationLanguageWrapper. As TRINIDAD-2252 showed, it is very dangerous to implement local wrappers, since it makes it harder to ensure that the new methods are properly added. -- 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] [Updated] (TRINIDAD-2255) Need to Expose ViewDeclarationLanguageWrapper
[ https://issues.apache.org/jira/browse/TRINIDAD-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2255: -- Status: Patch Available (was: Open) Need to Expose ViewDeclarationLanguageWrapper - Key: TRINIDAD-2255 URL: https://issues.apache.org/jira/browse/TRINIDAD-2255 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Max Starets Assignee: Max Starets Fix For: 2.1.0-core Attachments: trinidad-2255.patch Until we upgrade to JSF 2.2, we need to expose ViewDeclarationLanguageWrapper. As TRINIDAD-2252 showed, it is very dangerous to implement local wrappers, since it makes it harder to ensure that the new methods are properly added. -- 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] (TRINIDAD-2254) Trinidad's h:commandButton and h:commandLink renderer overrides do not specify dependency on submitForm()
Trinidad's h:commandButton and h:commandLink renderer overrides do not specify dependency on submitForm() - Key: TRINIDAD-2254 URL: https://issues.apache.org/jira/browse/TRINIDAD-2254 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Reporter: Max Starets Assignee: Max Starets -- 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] (TRINIDAD-2254) Trinidad's h:commandButton and h:commandLink renderer overrides do not specify dependency on submitForm()
[ https://issues.apache.org/jira/browse/TRINIDAD-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250060#comment-13250060 ] Max Starets commented on TRINIDAD-2254: --- h:commandButton and h:commandLink renderers should be calling XhtmlUtils.addLib with submitForm() to ensure that the right js library is included Trinidad's h:commandButton and h:commandLink renderer overrides do not specify dependency on submitForm() - Key: TRINIDAD-2254 URL: https://issues.apache.org/jira/browse/TRINIDAD-2254 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Reporter: Max Starets Assignee: Max Starets -- 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] [Updated] (TRINIDAD-2254) Trinidad's h:commandButton and h:commandLink renderer overrides do not specify dependency on submitForm()
[ https://issues.apache.org/jira/browse/TRINIDAD-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2254: -- Status: Patch Available (was: Open) Trinidad's h:commandButton and h:commandLink renderer overrides do not specify dependency on submitForm() - Key: TRINIDAD-2254 URL: https://issues.apache.org/jira/browse/TRINIDAD-2254 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.1-core Reporter: Max Starets Assignee: Max Starets Attachments: trinidad-2254.patch -- 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
Re: Move Trinidad Trunk to JSF 2.1
+1 On 3/25/2012 12:17 PM, Scott O'Bryan wrote: Hey all, Currently the Trinidad Trunk is set to JSF 2.0. There have been a number of blocker bugs recently (namely some issues with the ViewDeclarationLanguages and composite components) which have generated some blocking bugs. These problems were cause by additional methods in the ViewDeclarationLanguage syntax which we have to wrap for some of the functionality in Trinidad to be complete. At this time I propose the following: 1. Copy the current Trinidad Trunk to be branches/trinidad-2.0.x 2. Change the version of Trinidad Trunk to be 2.1.0-SNAPSHOT 3. Change the JSF dependency for trunk to be MyFaces 2.1 4. Change the trinidad plugins trunk to be 2.1.0 for consistency. 5. Change both branches/trinidad-2.0.x and trunk to use the new trinidad plugins snapshot. I'm hoping everyone will agree to this so that we can fix some of the blocker issues we've had show up after the the last Trinidad release. Many of which seem to be JSF 2.1 related. Please respond to this email with a +1 or a -1 and don't forget to include any any reasons why you do not wish to support the move. Thanks, Scott
[jira] [Created] (TRINIDAD-2249) Enable PageFlowScopePriver to apply specific encoding to the dialog URLs
Enable PageFlowScopePriver to apply specific encoding to the dialog URLs
Key: TRINIDAD-2249
URL: https://issues.apache.org/jira/browse/TRINIDAD-2249
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Archetype
Affects Versions: 2.0.2-core
Reporter: Max Starets
Assignee: Max Starets
PageFlowScopeProvider currently only exposes encodeCurrentPageFlowScopeURL(),
which gets called from ViewHandlerImpl.getActionURL(). It would be highly
desirable to provide a way for the PageFlowScopeProvider implementors to
perform encoding specific to the dialog URLs:
/**
* Encode the page flow scope into the dialog URL
*
* Note that the Dialog Framework may first call ViewHandler.getActionURL(),
which in turn will
* call encodeCurrentPageFlowScopeURL(). Then this method will be given a
chance to encode any dialog-specific
* information. The dafault implementation does not modify the URL.
*
* @param context the current FacesContext
* @param url an URL (which may already contain query parameters)
* @return encoded URL
*/
public String encodeDialogPageFlowScopeURL(
FacesContext context,
String url)
{
return url;
}
--
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] [Updated] (TRINIDAD-2249) Enable PageFlowScopePriver to apply specific encoding to the dialog URLs
[
https://issues.apache.org/jira/browse/TRINIDAD-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Max Starets updated TRINIDAD-2249:
--
Status: Patch Available (was: Open)
Enable PageFlowScopePriver to apply specific encoding to the dialog URLs
Key: TRINIDAD-2249
URL: https://issues.apache.org/jira/browse/TRINIDAD-2249
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Archetype
Affects Versions: 2.0.2-core
Reporter: Max Starets
Assignee: Max Starets
Attachments: trinidad-2249.patch
PageFlowScopeProvider currently only exposes encodeCurrentPageFlowScopeURL(),
which gets called from ViewHandlerImpl.getActionURL(). It would be highly
desirable to provide a way for the PageFlowScopeProvider implementors to
perform encoding specific to the dialog URLs:
/**
* Encode the page flow scope into the dialog URL
*
* Note that the Dialog Framework may first call
ViewHandler.getActionURL(), which in turn will
* call encodeCurrentPageFlowScopeURL(). Then this method will be given a
chance to encode any dialog-specific
* information. The dafault implementation does not modify the URL.
*
* @param context the current FacesContext
* @param url an URL (which may already contain query parameters)
* @return encoded URL
*/
public String encodeDialogPageFlowScopeURL(
FacesContext context,
String url)
{
return url;
}
--
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] (TRINIDAD-2252) ViewDeclarationLanguageFactoryImpl$ChangeApplyingVDLWrapper does not override non-abstract retargetMethodExpressions() causing composite component actions not to fire
ViewDeclarationLanguageFactoryImpl$ChangeApplyingVDLWrapper does not override non-abstract retargetMethodExpressions() causing composite component actions not to fire -- Key: TRINIDAD-2252 URL: https://issues.apache.org/jira/browse/TRINIDAD-2252 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.0-core Reporter: Max Starets Assignee: Max Starets ViewDeclarationLanguageFactoryImpl$ChangeApplyingVDLWrapper shoudl be overriding (and delegating to the wrapped object) retargetMethodExpressions() and retargetMethodExpressions(). Note that viewExists() and getId() shoudl be added too, but that is not feasible until we start building with JSF 2.1. Once we move to JSF 2.2, we should start using ViewDeclarationLanguageWrapper from JSF API -- 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
Re: Trinidad 2.0.1 PPR hour Glass Issue with facelet
Parthiv,
Could you file a JIRA issue for this? I do not see anything obviously
wrong in your test case.
Does it happen for all browsers?
Max
On 3/14/2012 6:40 AM, parthiv.prad...@gmail.com wrote:
- Forwarded message -
From: Parthiv Pradhan parthiv_prad...@infosys.com
Date: Wed, Mar 14, 2012 4:00 pm
Subject: Trinidad 2.0.1 PPR hour Glass Issue with facelet
To: parthiv.prad...@gmail.com parthiv.prad...@gmail.com
Hi,
Following is the content of my xhtml file. On clicking the button
though the output text gets updated an hour glass appears. It seems to
be an issue just with facelets. It only happens in case the partial
trigger is placed on the parent container. I am also attaching the
xhtml file and Java bean. I think this is a basic
functionality/feature on Trinidad JSF 2.0.1 and it should work. Where
am I going wrong?
ui:composition xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:jsp=http://java.sun.com/JSP/Page;
version=2.0
xmlns:f=http://java.sun.com/jsf/core;
xmlns:tr=http://myfaces.apache.org/trinidad;
f:view
tr:document title=Apache Trinidad Demo Index stateSaving=client
tr:form
tr:panelGroupLayout partialTriggers=demobtn
tr:commandButton text=howdyyy!! partialSubmit=true id=demobtn
actionListener=#{DemoBean.demoActionListener} /tr:commandButton
tr:outputText value=#{DemoBean.demoString} id=demoout
/tr:outputText
/tr:panelGroupLayout
/tr:form
/tr:document
/f:view
/ui:composition
Following needs be put in to the faces-config.xml file
managed-bean
managed-bean-nameDemoBean/managed-bean-name
managed-bean-class
com.parthiv.example.DemoBean
/managed-bean-class
managed-bean-scope
request
/managed-bean-scope
/managed-bean
Thanks
Parthiv
CAUTION - Disclaimer *
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
solely
for the use of the addressee(s). If you are not the intended
recipient, please
notify the sender by e-mail and delete the original message. Further,
you are not
to copy, disclose, or distribute this e-mail or its contents to any
other person and
any such actions are unlawful. This e-mail may contain viruses.
Infosys has taken
every reasonable precaution to minimize this risk, but is not liable
for any damage
you may sustain as a result of any virus in this e-mail. You should
carry out your
own virus checks before opening the e-mail or attachment. Infosys
reserves the
right to monitor and review the content of all messages sent to or
from this e-mail
address. Messages sent to or from this e-mail address may be stored on
the
Infosys e-mail system.
***INFOSYS End of Disclaimer INFOSYS***
[jira] [Updated] (TRINIDAD-2218) Need an ability for the WindowManager implementation to be executed before all Configurators and filters and to complete teh response
[ https://issues.apache.org/jira/browse/TRINIDAD-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2218: -- Resolution: Fixed Fix Version/s: 2.0.2-core Status: Resolved (was: Patch Available) Need an ability for the WindowManager implementation to be executed before all Configurators and filters and to complete teh response - Key: TRINIDAD-2218 URL: https://issues.apache.org/jira/browse/TRINIDAD-2218 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.2-core Reporter: Max Starets Assignee: Max Starets Fix For: 2.0.2-core Attachments: trinidad-2218.patch Since WindowManager is expected to make the Window Map available to all Configurators, we need a way to ensure that it is executed before all Configurators and filters. Also, WindowManager needs to be able to complete a response, so that it can send a script response to the client. -- 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] (TRINIDAD-2218) Need an ability for the WindowManager implementation to be executed before all Configurators and filters and to complete teh response
[ https://issues.apache.org/jira/browse/TRINIDAD-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13220959#comment-13220959 ] Max Starets commented on TRINIDAD-2218: --- Hey Scott, thanks for reviewing the patch. Configurator.disableConfiguratorServices() did not work because we weren't releasing the RequestContext at the end. When you say 'Trinidad filter', do you mean TrinidadFilterImpl? The issue is that RequestContext is not available there. If you mean filters invoked after Configurators, then it won't work either because we need to provide a window Id to configurators. Lets discuss this offline Need an ability for the WindowManager implementation to be executed before all Configurators and filters and to complete teh response - Key: TRINIDAD-2218 URL: https://issues.apache.org/jira/browse/TRINIDAD-2218 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.2-core Reporter: Max Starets Assignee: Scott O'Bryan Attachments: trinidad-2218.patch Since WindowManager is expected to make the Window Map available to all Configurators, we need a way to ensure that it is executed before all Configurators and filters. Also, WindowManager needs to be able to complete a response, so that it can send a script response to the client. -- 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] (TRINIDAD-2218) Need an ability for the WindowManager implementation to be executed before all Configurators and filters and to complete teh response
Need an ability for the WindowManager implementation to be executed before all Configurators and filters and to complete teh response - Key: TRINIDAD-2218 URL: https://issues.apache.org/jira/browse/TRINIDAD-2218 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.2-core Reporter: Max Starets Assignee: Max Starets Since WindowManager is expected to make the Window Map available to all Configurators, we need a way to ensure that it is executed before all Configurators and filters. Also, WindowManager needs to be able to complete a response, so that it can send a script response to the client. -- 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] [Updated] (TRINIDAD-2218) Need an ability for the WindowManager implementation to be executed before all Configurators and filters and to complete teh response
[ https://issues.apache.org/jira/browse/TRINIDAD-2218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2218: -- Status: Patch Available (was: Open) Need an ability for the WindowManager implementation to be executed before all Configurators and filters and to complete teh response - Key: TRINIDAD-2218 URL: https://issues.apache.org/jira/browse/TRINIDAD-2218 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.2-core Reporter: Max Starets Assignee: Max Starets Attachments: trinidad-2218.patch Since WindowManager is expected to make the Window Map available to all Configurators, we need a way to ensure that it is executed before all Configurators and filters. Also, WindowManager needs to be able to complete a response, so that it can send a script response to the client. -- 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
Re: [trinidad] cleanup
I think we that for 2.0.x versions of Trinidad, should definitely remove stuff that cannot be possibly used/invoked with JSF 2.0. I would not remove all deprecated APIs at once though. Perhaps we could could do it 'in waves ' - start with APIs that were decprected for the longest time, announce that they are going to be removed in the next release and give our users considerable time to check their code. Max On 10/5/2011 9:22 AM, Scott O'Bryan wrote: The backward compatibility library might be an interesting idea. It just won't always be possible if an existing class has deprecated methods on it. I don't know how many Deprecated classes we have. Scott On 10/05/2011 07:07 AM, Gerhard Petracek wrote: basically i agree with mark. at some point we have to get rid of the old stuff (esp. pre jsf stuff). at least we can move the deprecated parts to the mentioned backward compatibility module (if needed). in combination with shade there shouldn't be a problem at all and it forces us to cleanup and re-visit those old parts. @scott: for sure it has to be a community decision. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/10/5 Mark Struberg strub...@yahoo.de mailto:strub...@yahoo.de My intention is not to break something, and I was ONLY talking about the JSF-2 version of Trinidad. If there is code which just makes no sense at all in JSF-2, then we should in MY opinion kill this code. If it doesn't make sense for Trinidad, then it is highly likely that it also don't make sense for ADF anymore, right? IF some parts are still needed by some known 3rd party libs, then those parts can of course remain. But at the end of the day maintaining Trinidad will become more and more problematic if we don't get rid of long time obsolete stuff. Again: only my personal opinion and experience. I assume that ADF also has a JSF-1 and a separate JSF-2 branch. All the JSF-1 stuff would of course remain the way it is currently! LieGrue, strub - Original Message - From: Scott O'Bryan darkar...@gmail.com mailto:darkar...@gmail.com To: dev@myfaces.apache.org mailto:dev@myfaces.apache.org Cc: Sent: Wednesday, October 5, 2011 2:20 PM Subject: Re: [trinidad] cleanup We could, yes. But we would force people to migrate apps which, perhaps is not a bad thing but traditionally we've taken a full vote before changing/removing API's in Trinidad because, doing so, incurs additional cost on the other frameworks which are using Trinidad as a foundation. Any company which provides Trinidad as a foundation for other framework code (like Oracle's ADFFaces) benefits from NOT breaking users of the framework every release and, frankly, I see a lot of value in keeping them around 'if possible'. Like I say, I'm not opposed to it, but I suppose I take more of a Java ZEN approach to deprecation of API's. Scott On 10/05/2011 05:41 AM, Mark Struberg wrote: I'm not sure if I understand this correctly. Trinidad-2 is for JSF-2 upwards exclusively, isn't? If so, then we can easily get rid of all the old dust which just confuses people. Furthermore there seems to be a few compat problems with JSF-2 f:ajax which can only be resolved by carefully cleaning those areas up. Just leave behind the old stuff. LieGrue, strub From: Scott O'Bryandarkar...@gmail.com mailto:darkar...@gmail.com To: MyFaces Developmentdev@myfaces.apache.org mailto:dev@myfaces.apache.org Sent: Wednesday, October 5, 2011 1:06 PM Subject: Re: [trinidad] cleanup Well just because something is depth aged doesn't mean we can remove it. It just means that an alternate means is suggested or something may not work exactly as expected if used. A Prime example is ExternalContextUtils. That guy has been around since JSF 1.1. It contains lots of functionality that wasn't present in later versions of JSF, but now is. Use of the native objects should be encouraged, but there is also something to be said about older code being able to migrate easier to a later release. Now I DO agree with removing the JSDoc and possibly the deprecations in the impl, but I think it's important to keep any deprecations in the API for backward compatibility. Sent from my iPhone On Oct 5, 2011, at 4:32 AM, Gerhard Petracekgerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com wrote: both - there are just two possibilities: those parts are
[jira] [Reopened] (TRINIDAD-2100) Trinidad's Library Scriptlet Mechansim Should Support More Selective JS Inclusion
[ https://issues.apache.org/jira/browse/TRINIDAD-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets reopened TRINIDAD-2100: --- Reopening this issue since the CharSets got put into CoreFmt in CoreCommonScriptsResourceLoader, while javascriptmap.properties is still listing it in Common Trinidad's Library Scriptlet Mechansim Should Support More Selective JS Inclusion - Key: TRINIDAD-2100 URL: https://issues.apache.org/jira/browse/TRINIDAD-2100 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-core Reporter: Max Starets Assignee: Max Starets Fix For: 2.0.1-core Attachments: trinidad-2100.patch Currently, most of Trinidad's JS libs go into the common js library. It makes sense to break out libraries dealing with client-side formatting since they are fairly large, and pulling them on demand is possible. It also makes sense to separate locale support from the rest of the common, so that other framework using Trinidad (namely ADF Faces) could avoid pulling in unnecessary functionality (PPR support, etc.) -- 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] [Updated] (TRINIDAD-2100) Trinidad's Library Scriptlet Mechansim Should Support More Selective JS Inclusion
[ https://issues.apache.org/jira/browse/TRINIDAD-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2100: -- Status: Patch Available (was: Reopened) Trinidad's Library Scriptlet Mechansim Should Support More Selective JS Inclusion - Key: TRINIDAD-2100 URL: https://issues.apache.org/jira/browse/TRINIDAD-2100 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-core Reporter: Max Starets Assignee: Max Starets Fix For: 2.0.1-core Attachments: trinidad-2100-2.patch, trinidad-2100.patch Currently, most of Trinidad's JS libs go into the common js library. It makes sense to break out libraries dealing with client-side formatting since they are fairly large, and pulling them on demand is possible. It also makes sense to separate locale support from the rest of the common, so that other framework using Trinidad (namely ADF Faces) could avoid pulling in unnecessary functionality (PPR support, etc.) -- 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] [Updated] (TRINIDAD-2100) Trinidad's Library Scriptlet Mechansim Should Support More Selective JS Inclusion
[ https://issues.apache.org/jira/browse/TRINIDAD-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2100: -- Resolution: Fixed Status: Resolved (was: Patch Available) Trinidad's Library Scriptlet Mechansim Should Support More Selective JS Inclusion - Key: TRINIDAD-2100 URL: https://issues.apache.org/jira/browse/TRINIDAD-2100 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-core Reporter: Max Starets Assignee: Max Starets Fix For: 2.0.1-core Attachments: trinidad-2100-2.patch, trinidad-2100.patch Currently, most of Trinidad's JS libs go into the common js library. It makes sense to break out libraries dealing with client-side formatting since they are fairly large, and pulling them on demand is possible. It also makes sense to separate locale support from the rest of the common, so that other framework using Trinidad (namely ADF Faces) could avoid pulling in unnecessary functionality (PPR support, etc.) -- 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] (TRINIDAD-2129) Component showcase demo broken
[ https://issues.apache.org/jira/browse/TRINIDAD-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13085964#comment-13085964 ] Max Starets commented on TRINIDAD-2129: --- The issue is that RI's BaseTableRenderer is using writeText(Object text, UIComponent component, String propertyName), which is not overridden in PPRResponseWriter (the method was added in JSF 1.2). This produces white space in PPR response, which is not tolerated by JSF Ajax response processing. The old legacy Trinidad PPR response processor was just skipping the white space, so we never ran into this problem. Introducing writeText override in PPRResponseWriter fixes the issue. Component showcase demo broken -- Key: TRINIDAD-2129 URL: https://issues.apache.org/jira/browse/TRINIDAD-2129 Project: MyFaces Trinidad Issue Type: Bug Environment: Tested on GlassFish v3.1, though not sure that is significant. Repros in various browsers (FF, Safari, Chrome). Reporter: Andy Schwartz The Browse Components accordion in the component showcase demo is not working. It is not possible to disclose any accordion pane. Interestingly, the standalone panelAccordion demo under the trinidad-demo example does work without problem. Specifying priority as major (and possibly should be higher) as it is possible that this is a symptom of a more fundamental problem. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TRINIDAD-2129) Component showcase demo broken
[ https://issues.apache.org/jira/browse/TRINIDAD-2129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets resolved TRINIDAD-2129. --- Resolution: Fixed Fix Version/s: 2.0.1 Component showcase demo broken -- Key: TRINIDAD-2129 URL: https://issues.apache.org/jira/browse/TRINIDAD-2129 Project: MyFaces Trinidad Issue Type: Bug Environment: Tested on GlassFish v3.1, though not sure that is significant. Repros in various browsers (FF, Safari, Chrome). Reporter: Andy Schwartz Assignee: Max Starets Fix For: 2.0.1 Attachments: TRINIDAD-2129.patch The Browse Components accordion in the component showcase demo is not working. It is not possible to disclose any accordion pane. Interestingly, the standalone panelAccordion demo under the trinidad-demo example does work without problem. Specifying priority as major (and possibly should be higher) as it is possible that this is a symptom of a more fundamental problem. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Trinidad] Will be releasing next Trinidad 2.0 next week
Scott, I have submitted the fix for this - the problem was that we were getting white space in Ajax response, which was not tolerated by Mojarra's Ajax response processing. I have added a missing PPRResponseWriter writeText() override, which fixes the issue. Max On 8/16/2011 1:21 PM, Andy Schwartz wrote: Hey Scott - It is not marked as a blocker, though think it would be good to take a look at this one before we release: https://issues.apache.org/jira/browse/TRINIDAD-2129 Andy
[jira] [Created] (TRINIDAD-2124) TrinidadAgent Needs to Expose Browser Management History Capability
TrinidadAgent Needs to Expose Browser Management History Capability --- Key: TRINIDAD-2124 URL: https://issues.apache.org/jira/browse/TRINIDAD-2124 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.1 Reporter: Max Starets -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2124) TrinidadAgent Needs to Expose Browser Management History Capability
[ https://issues.apache.org/jira/browse/TRINIDAD-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2124: -- Status: Patch Available (was: Open) TrinidadAgent Needs to Expose Browser Management History Capability --- Key: TRINIDAD-2124 URL: https://issues.apache.org/jira/browse/TRINIDAD-2124 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.1 Reporter: Max Starets Assignee: Max Starets Attachments: trinidad-2124.patch -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE[ Release of Trinidad Maven Plugins v. 2.0.6
+1 On 8/3/2011 3:54 PM, Scott O'Bryan wrote: Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.6released and now I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins including adding support for more JSF 2.0 stuff as well as support for later versions of JDeveloper and Maven 3. This tag has been in use on Trinidad Trunk for some time and should now be ready for a real release. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-004 [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.6
[jira] [Commented] (TRINIDAD-2123) tr:chart chartDrillDownListener method not called with facelets
[
https://issues.apache.org/jira/browse/TRINIDAD-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071240#comment-13071240
]
Max Starets commented on TRINIDAD-2123:
---
As a temporary workaround, you can use a component binding for your chart with
a request-scoped bean. In your bean's setter method (lets say it is called
setChart()) you can call addChartDrillDownListener programmatically to register
your listener.
tr:chart chartDrillDownListener method not called with facelets
---
Key: TRINIDAD-2123
URL: https://issues.apache.org/jira/browse/TRINIDAD-2123
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components, Facelets
Affects Versions: 2.0.0
Environment: Intel x64 platform, Windows 7, FireFox 5.0
Reporter: Kokavecz András
Original Estimate: 1h
Remaining Estimate: 1h
I'm trying to use Trinidad charts and I have problems with the chartDrillDown
listener and also with the binding of the chart component to an UIComponent.
1.)
If I use a JSPX page with jsp:root and f:view tags, so withOUT Facelets it
all works fine...the chartDrillDown fires up.
2.)
If inside ui:composition tags, so WITH facelets the problem is, that the API
tries to look up the chartDrillDownListener as a property not as a
MethodExpression.
This is also the case with bindig the tr:chart element to an UIComponent.
I debugged the class UIXChart, as the event travels throught its
broadcast(FacesEvent event) method.
// Deliver to the default ChartDrillDownEvent
if (event instanceof ChartDrillDownEvent) {
broadcastToMethodExpression(event,
getChartDrillDownListener());
}
super.broadcast(event);
In case of FACELETS the getChartDrillDownListener() method tries to call
getProperty() for UIXComponentBase and exits with a PropertyNotFoundException.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Issues Upgrading JSF and Richfaces
David, The exception is for a class from Facelets 1.1.x. I would make sure that you do not have old Facelets libraries around (Facelets is now part of JSF 2.0) and that you do not have any custom Facelets tag definitions (taglib.xml) referencing the old classes. Max On 7/5/2011 10:16 AM, David Wu wrote: Hi Scott, Thanks for the quick reply. Let check what other Mojarra libraries and classes files are left around. I will keep you updated.
Re: jaxconf
Bernd, Andy Schwartz, Blake Sullivan and I (all Trinidad commiters) will be there. Max On 6/17/2011 2:14 AM, Bernd Bohmann wrote: Hello, I would like to meet other myfaces or jsf people at the jaxconf. Please send a short note who is attending. Regards Bernd
Re: Not able to use tr validators/convertors with facelets
Parthiv, TrinidadConverterHandler has a constructor that takes ValidatorConfig, but no constructor that takes TagConfig. What version of Trinidad are you using? And what is the version of Facelets? It would also help if you included a code fragment that is producing this exception for you. Max On 6/3/2011 11:52 PM, parthiv pradhan wrote: Hi All, I am having this strange problem. I am able to use all trinidad components in my project where I am using facelets. But when I use any of the trinidad validator/convertor tag I get the below error while running the xhtml file. any help on this would be very useful!! thanks Parthiv --- (2011-06-04 08:52:10,705) ERROR org.ajax4jsf.webapp.BaseXMLFilter - Exception in the filter chain javax.servlet.ServletException: org.apache.myfaces.trinidadinternal.facelets.TrinidadConverterHandler.init(com.sun.facelets.tag.TagConfig) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:277) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:341) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:83) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:178) at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290) at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.NoSuchMethodException: org.apache.myfaces.trinidadinternal.facelets.TrinidadConverterHandler.init(com.sun.facelets.tag.TagConfig) at java.lang.Class.getConstructor0(Unknown Source) at java.lang.Class.getConstructor(Unknown Source) at com.sun.facelets.tag.AbstractTagLibrary$HandlerFactory.createHandler(AbstractTagLibrary.java:109) at com.sun.facelets.tag.AbstractTagLibrary.createTagHandler(AbstractTagLibrary.java:533) at com.sun.facelets.tag.CompositeTagLibrary.createTagHandler(CompositeTagLibrary.java:79) at com.sun.facelets.compiler.TagUnit.createFaceletHandler(TagUnit.java:48) at com.sun.facelets.compiler.TextUnit.createFaceletHandler(TextUnit.java:76) at com.sun.facelets.compiler.CompilationUnit.getNextFaceletHandler(CompilationUnit.java:69) at com.sun.facelets.compiler.TagUnit.getNextHandler(TagUnit.java:52) at com.sun.facelets.tag.AbstractTagLibrary$ComponentConfigWrapper.getNextHandler(AbstractTagLibrary.java:152) at com.sun.facelets.tag.TagHandler.init(TagHandler.java:41) at com.sun.facelets.tag.MetaTagHandler.init(MetaTagHandler.java:34) at
Re: [Trinidad] Unable to populate the header column text and shortDesc dynamically
Claus,
Components in the column's header facet are not stamped (they are not
specific to any given row),
and you cannot access the var expression ('arg') there.
The header facet applies to the entire column, and not any given row.
Hope this helps,
Max Starets
On 5/18/2011 5:16 AM, Nielsen, Claus Djernaes wrote:
Hi
I would like to populate the header text and the tooltip based on what
we get in the table. Is this possible?
I have tried the example as below. And putting the header text and
shortDesc on the tr:column as well. None of it has worked.
tr:table value=#{generateSendCapacitySummaryBean.vesselDetails}
bandingInterval=2 banding=row var=arg
emptyText=No vessel call details
tr:column
f:facet name=header
tr:outputText value=Service shortDesc=#{arg.serviceTooltip}/
/f:facet
tr:outputText value=#{arg.service} /
/tr:column
/tr:table
Is there a way to solve this?
Best regards
Claus D. Nielsen
P.S
I have created a Jira as well. It's ID is
·MyFaces Trinidad https://issues.apache.org/jira/browse/TRINIDAD
·TRINIDAD-2103 https://issues.apache.org/jira/browse/TRINIDAD-2103
This e-mail is intended exclusively for the addressee. If you are not
the addressee you must not read, copy, use or disclose the e-mail nor
the content; please notify us immediately [by clicking 'Reply'] and
delete this e-mail.
[jira] [Commented] (TRINIDAD-2100) Trinidad's Library Scriptlet Mechansim Should Support More Selective JS Inclusion
[ https://issues.apache.org/jira/browse/TRINIDAD-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13031902#comment-13031902 ] Max Starets commented on TRINIDAD-2100: --- The basic idea of the patch is to separate Locale, CoreFormat, DateFormat and ColorFormat libraries from the common library. This will allow frameworks using Trinidad as a base to include libraries selectively. Trinidad's Library Scriptlet Mechansim Should Support More Selective JS Inclusion - Key: TRINIDAD-2100 URL: https://issues.apache.org/jira/browse/TRINIDAD-2100 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0 Reporter: Max Starets Assignee: Max Starets Attachments: trinidad-2100.patch Currently, most of Trinidad's JS libs go into the common js library. It makes sense to break out libraries dealing with client-side formatting since they are fairly large, and pulling them on demand is possible. It also makes sense to separate locale support from the rest of the common, so that other framework using Trinidad (namely ADF Faces) could avoid pulling in unnecessary functionality (PPR support, etc.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2100) Trinidad's Library Scriptlet Mechansim Should Support More Selective JS Inclusion
Trinidad's Library Scriptlet Mechansim Should Support More Selective JS Inclusion - Key: TRINIDAD-2100 URL: https://issues.apache.org/jira/browse/TRINIDAD-2100 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets Currently, most of Trinidad's JS libs go into the common js library. It makes sense to break out libraries dealing with client-side formatting since they are fairly large, and pulling them on demand is possible. It also makes sense to separate locale support from the rest of the common, so that other framework using Trinidad (namely ADF Faces) could avoid pulling in unnecessary functionality (PPR support, etc.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2100) Trinidad's Library Scriptlet Mechansim Should Support More Selective JS Inclusion
[ https://issues.apache.org/jira/browse/TRINIDAD-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2100: -- Status: Patch Available (was: Open) Trinidad's Library Scriptlet Mechansim Should Support More Selective JS Inclusion - Key: TRINIDAD-2100 URL: https://issues.apache.org/jira/browse/TRINIDAD-2100 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets Attachments: TRINIDAD-2002.patch Currently, most of Trinidad's JS libs go into the common js library. It makes sense to break out libraries dealing with client-side formatting since they are fairly large, and pulling them on demand is possible. It also makes sense to separate locale support from the rest of the common, so that other framework using Trinidad (namely ADF Faces) could avoid pulling in unnecessary functionality (PPR support, etc.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2073) Session based changes fail to apply for facelets VDL
[ https://issues.apache.org/jira/browse/TRINIDAD-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2073: -- Status: Open (was: Patch Available) Session based changes fail to apply for facelets VDL Key: TRINIDAD-2073 URL: https://issues.apache.org/jira/browse/TRINIDAD-2073 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.0-beta-2 Reporter: Prakash Udupa Attachments: TRINIDAD-2073.patch Original Estimate: 24h Remaining Estimate: 24h SessionChangeManager stored changes are not applied for Facelets pages. These work well for JSPs, where we invoke the change application methods in SessionChangeManager from the document tag handler. For facelets we need to call these methods similarly in a suitable point in the lifecycle, either in the document handler or soon after the view is built. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-2073) Session based changes fail to apply for facelets VDL
[ https://issues.apache.org/jira/browse/TRINIDAD-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13017570#comment-13017570 ] Max Starets commented on TRINIDAD-2073: --- Reverted changes per Prakash's request Session based changes fail to apply for facelets VDL Key: TRINIDAD-2073 URL: https://issues.apache.org/jira/browse/TRINIDAD-2073 Project: MyFaces Trinidad Issue Type: Bug Components: Facelets Affects Versions: 2.0.0-beta-2 Reporter: Prakash Udupa Attachments: TRINIDAD-2073.patch Original Estimate: 24h Remaining Estimate: 24h SessionChangeManager stored changes are not applied for Facelets pages. These work well for JSPs, where we invoke the change application methods in SessionChangeManager from the document tag handler. For facelets we need to call these methods similarly in a suitable point in the lifecycle, either in the document handler or soon after the view is built. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] release for myfaces test 1.0.2
+1 On 3/25/2011 8:44 AM, Scott O'Bryan wrote: +1 On Mar 25, 2011, at 5:06 AM, Jakob Korherr jakob.korh...@gmail.com wrote: +1 Regards, Jakob 2011/3/24 Leonardo Uribe lu4...@gmail.com: +1 2011/3/24 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 1.0.2 release of Apache MyFaces Test out. Note these artifacts are necessary to start the release of myfaces core 2.0.5. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.test v1.0.2 [1] The artifacts are deployed to nexus repository [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Please take a look at the 1.0.2 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-037/org/apache/myfaces/test/ https://repository.apache.org/content/groups/staging/org/apache/myfaces/test/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfacestest102binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310951version=12316321 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
Thanks, Leonardo! You rock! Max On 3/24/2011 6:06 PM, Leonardo Uribe wrote: Hi I have created these issues: http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-952 https://issues.apache.org/jira/browse/MYFACES-3082 I agree with the proposed behavior, and I don't think do it could cause any problems. So from my side there is no objections about the artifacts proposed. Thanks for the clarification. Leonardo 2011/3/24 Andy Schwartz andy.g.schwa...@gmail.com: Gang - Looking back at the EG emails, I realize now that I dropped the ball on making sure that my proposed changes actually made it into the spec. Here was my original email (Metadata complete jar files) from Septeber 3, 2009: Gang - Section 11.5.1 of the spec defines the following annotation scanning behavior: Requirements for scanning of classes for annotations * If the faces-config element in the WEB-INF/faces-config.xml file contains metadata-complete attribute whose value is “true”, the implementation must not perform annotation scanning on any classes except for those classes provided by the implementation itself. Otherwise, continue as follows. * If the runtime discovers a conflict between an entry in the Application Configuration Resources and an annotation, the entry in the Application Configuration Resources takes precedence. * All classes in WEB-INF/classes must be scanned. * For every jar in the application's WEB-INF/lib directory, if the jar contains a “META-INF/faces-config.xml” file or a file that matches the regular expression “.*\.faces-config.xml” (even an empty one), all classes in that jar must be scanned. Since application developers have the ability to disable annotation scanning at a global level, this means that any component set that wants to support this mode would need to provide a metadata complete faces-config.xml file. I don't think this is a hardship for most component vendors, since presumably component vendors are going to want to provide design-time metadata (eg. JSR-276 metadata), which, for the moment, requires a faces-config.xml file anyway. A question that came up here is whether we can tweak section 11.5.1 to accommodate metadata complete jar files. That is, can we specify that any jar that contains a faces-config.xml with a metadata-complete=true attribute would not be scanned? This would allow component vendors to indicate that their jar files are metadata complete, and thus avoid the cost of annotation scanning for the contents of the jar. Note that while the annotation scan is typically a one time hit (during application startup), design-time tools may end up starting/stopping JSF repeatedly during the development process. Thus, avoiding unnecessary scanning should provide for a more efficient development experience. Any thoughts on whether we could/should make this change? Does anyone know of reasons why we avoided specifying this originally? Also - if we agree to make this change, is this small enough that we could get this into the the next MR? Andy Both Dan and Pete responded in support. There were no other responses on the EG list. I should have followed up to make sure that the spec update happened, but apparently never did. I will do that now. :-) Sorry about the confusion. :-( Andy
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
+1 On 3/24/2011 12:32 PM, Scott O'Bryan wrote: Hello Everyone, I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.5 released and not I need a vote as to whether everything looks good or not. There were some minor fixes and the plugins now mark the trinidad package as being metadata complete in order to help avoid having to scan the jar for class annotations at runtime. I have generated the tag and deployed all the artifacts to the Nexus Repository for review. The artifacts are as follows: * The generated repository artifacts [1] * The updated svn repository [2] Please take a look at the artifacts and don't forget to vote early and often. :D The vote will stay open for at least 72 hours to give people a chance to respond. Thanks, Scott O'Bryan [1] https://repository.apache.org/content/repositories/orgapachemyfaces-035 [2] https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.5
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
Hey Leonrado, The change is to allow the plugin to generate metadata-complete=true for trinidad-impl's faces-config.xml. See https://issues.apache.org/jira/browse/TRINIDAD-2068 Max On 3/24/2011 3:50 PM, Leonardo Uribe wrote: Hi As a side note: SO There were some minor fixes and the plugins now mark the trinidad package SO as being metadata complete in order to help avoid having to scan the jar for SO class annotations at runtime. Reading JSF 2.0 spec, metadata-complete is only used on WEB-INF/faces-config.xml. Is it a change for 2.1? or maybe there is something missing on the spec? regards, Leonardo Uribe 2011/3/24 Andy Schwartz andy.g.schwa...@gmail.com: +1. Thanks for putting this together Scott! Andy
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
Leonardo, I have tested metadata-complete with Mojarra, and it is not ignored. I can point you to the Mojarra code that does the check. From what I understand, this feature was included a while ago (during the initial 2.0 release) after Andy Schwartz lobbied for it. It looks like the spec was not properly updated, I still would like to proceed with the plugin change since we can take advantage of skipping annotation scanning at least with Mojarra. Max On 3/24/2011 5:13 PM, Leonardo Uribe wrote: Hi 2011/3/24 Max Starets max.star...@oracle.com: Hey Leonrado, The change is to allow the plugin to generate metadata-complete=true for trinidad-impl's faces-config.xml. See https://issues.apache.org/jira/browse/TRINIDAD-2068 The problem here is this config will be ignored by myfaces core, because we don't have any code that check for it before scan for annotations. In practice, trinidad jars are scanned for JSF 2.0 annotations, no matter if myfaces or mojarra are used. I understand the intention, but to complete it, it is necessary to commit some changes on myfaces core 2.0.x (and mojarra). I checked it some days ago and the documentation is not clear: ...The metadata-complete attribute defines whether this JavaServer Faces application is complete, or whether the class files available to this module and packaged with this application should be examined for annotations that specify configuration information ... This attribute is only inspected on the application configuration resource file located at WEB-INF/faces-config.xml. The presence of this attribute on any application configuration resource other than the one located at WEB-INF/faces-config.xml, including any files named using the javax.faces.CONFIG_FILES attribute, must be ignored. ... regards, Leonardo Max On 3/24/2011 3:50 PM, Leonardo Uribe wrote: Hi As a side note: SO There were some minor fixes and the plugins now mark the trinidad package SO as being metadata complete in order to help avoid having to scan the jar for SO class annotations at runtime. Reading JSF 2.0 spec, metadata-complete is only used on WEB-INF/faces-config.xml. Is it a change for 2.1? or maybe there is something missing on the spec? regards, Leonardo Uribe 2011/3/24 Andy Schwartz andy.g.schwa...@gmail.com: +1. Thanks for putting this together Scott! Andy
Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.5
Leonardo, The check in Mojarra is done in com.sun.faces.config.ConfigManager.getAnnotationScanURLs(). Andy can probably dig out EG e-mails where this was agreed. Thanks, Max On 3/24/2011 5:35 PM, Max Starets wrote: Leonardo, I have tested metadata-complete with Mojarra, and it is not ignored. I can point you to the Mojarra code that does the check. From what I understand, this feature was included a while ago (during the initial 2.0 release) after Andy Schwartz lobbied for it. It looks like the spec was not properly updated, I still would like to proceed with the plugin change since we can take advantage of skipping annotation scanning at least with Mojarra. Max On 3/24/2011 5:13 PM, Leonardo Uribe wrote: Hi 2011/3/24 Max Starets max.star...@oracle.com: Hey Leonrado, The change is to allow the plugin to generate metadata-complete=true for trinidad-impl's faces-config.xml. See https://issues.apache.org/jira/browse/TRINIDAD-2068 The problem here is this config will be ignored by myfaces core, because we don't have any code that check for it before scan for annotations. In practice, trinidad jars are scanned for JSF 2.0 annotations, no matter if myfaces or mojarra are used. I understand the intention, but to complete it, it is necessary to commit some changes on myfaces core 2.0.x (and mojarra). I checked it some days ago and the documentation is not clear: ...The metadata-complete attribute defines whether this JavaServer Faces application is complete, or whether the class files available to this module and packaged with this application should be examined for annotations that specify configuration information ... This attribute is only inspected on the application configuration resource file located at WEB-INF/faces-config.xml. The presence of this attribute on any application configuration resource other than the one located at WEB-INF/faces-config.xml, including any files named using the javax.faces.CONFIG_FILES attribute, must be ignored. ... regards, Leonardo Max On 3/24/2011 3:50 PM, Leonardo Uribe wrote: Hi As a side note: SO There were some minor fixes and the plugins now mark the trinidad package SO as being metadata complete in order to help avoid having to scan the jar for SO class annotations at runtime. Reading JSF 2.0 spec, metadata-complete is only used on WEB-INF/faces-config.xml. Is it a change for 2.1? or maybe there is something missing on the spec? regards, Leonardo Uribe 2011/3/24 Andy Schwartz andy.g.schwa...@gmail.com: +1. Thanks for putting this together Scott! Andy
[jira] [Created] (TRINIDAD-2068) Trinidad's faces-config.xml should have metadata-complete=true
Trinidad's faces-config.xml should have metadata-complete=true -- Key: TRINIDAD-2068 URL: https://issues.apache.org/jira/browse/TRINIDAD-2068 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Reporter: Max Starets Assignee: Max Starets Since trinidad-impl.jar does not use configuration annotations, we should disable annotation scanning by setting metadata-complete to false in faces-config. This will improve deployment performance for applications using Trinidad. Note that the change will disable annotation scanning only for trinidad-impl.jar. Users will still be able to use annotations in their code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2068) Trinidad's faces-config.xml should have metadata-complete=true
[ https://issues.apache.org/jira/browse/TRINIDAD-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2068: -- Status: Patch Available (was: Open) Trinidad's faces-config.xml should have metadata-complete=true -- Key: TRINIDAD-2068 URL: https://issues.apache.org/jira/browse/TRINIDAD-2068 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Reporter: Max Starets Assignee: Max Starets Attachments: trinidad2068-pom.patch, trinidad2068.patch Since trinidad-impl.jar does not use configuration annotations, we should disable annotation scanning by setting metadata-complete to false in faces-config. This will improve deployment performance for applications using Trinidad. Note that the change will disable annotation scanning only for trinidad-impl.jar. Users will still be able to use annotations in their code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2068) Trinidad's faces-config.xml should have metadata-complete=true
[ https://issues.apache.org/jira/browse/TRINIDAD-2068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2068: -- Resolution: Fixed Fix Version/s: 2.0.5-plugins Status: Resolved (was: Patch Available) Trinidad's faces-config.xml should have metadata-complete=true -- Key: TRINIDAD-2068 URL: https://issues.apache.org/jira/browse/TRINIDAD-2068 Project: MyFaces Trinidad Issue Type: Bug Components: Plugins Reporter: Max Starets Assignee: Max Starets Fix For: 2.0.5-plugins Attachments: trinidad2068-pom.patch, trinidad2068.patch Since trinidad-impl.jar does not use configuration annotations, we should disable annotation scanning by setting metadata-complete to false in faces-config. This will improve deployment performance for applications using Trinidad. Note that the change will disable annotation scanning only for trinidad-impl.jar. Users will still be able to use annotations in their code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TRINIDAD-2048) ComponentUtils.getScopedIdForComponent() is not producing consistent scoped IDs for components relocated during tag execution
[ https://issues.apache.org/jira/browse/TRINIDAD-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets resolved TRINIDAD-2048. --- Resolution: Fixed ComponentUtils.getScopedIdForComponent() is not producing consistent scoped IDs for components relocated during tag execution - Key: TRINIDAD-2048 URL: https://issues.apache.org/jira/browse/TRINIDAD-2048 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets Attachments: trinidad2048-1.2.x.patch, trinidad2048.patch getScopedIdForComponent() simply walks the parent hierarchy to append naming container IDs. However, we have components that get relocated during tag execution, so their naming container hierarchy is different at tag execution time vs. the rest of the lifecycle. To solve this problem, we need to have getScopedIdForComponent return a scoped Id reflecting the original naming container hierarchy for the component, i.e. return its pre-relocation scoped ID. This will require API additions on UIXComponent to allow relocated components to provide their logical (original parent). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2048) ComponentUtils.getScopedIdForComponent() is not producing consistent scoped IDs for components relocated during tag execution
[
https://issues.apache.org/jira/browse/TRINIDAD-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13006083#comment-13006083
]
Max Starets commented on TRINIDAD-2048:
---
Minor modification on top of the deltas to handle null _insertBeforeId:
@Override
public boolean equals(Object o)
{
if (o == this)
return true;
if (!(o instanceof MoveChildComponentChange))
return false;
MoveChildComponentChange other = (MoveChildComponentChange)o;
return getSourceLogicalScopedId().equals(other.getSourceLogicalScopedId())
getDestinationLogicalScopedId().equals(other.getDestinationLogicalScopedId())
_equalsOrNull(_insertBeforeId, other._insertBeforeId);
}
@Override
public int hashCode()
{
int hashCode = getSourceLogicalScopedId().hashCode() + 37 *
getDestinationLogicalScopedId().hashCode();
if (_insertBeforeId != null)
{
hashCode = hashCode + 1369 * _insertBeforeId.hashCode();
}
return hashCode;
}
private boolean _equalsOrNull(Object obj1, Object obj2)
{
return (obj1 == null) ? (obj2 == null) : obj1.equals(obj2);
}
ComponentUtils.getScopedIdForComponent() is not producing consistent scoped
IDs for components relocated during tag execution
-
Key: TRINIDAD-2048
URL: https://issues.apache.org/jira/browse/TRINIDAD-2048
Project: MyFaces Trinidad
Issue Type: Bug
Reporter: Max Starets
Assignee: Max Starets
Attachments: trinidad2048-1.2.x.patch, trinidad2048.patch
getScopedIdForComponent() simply walks the parent hierarchy to append naming
container IDs. However, we have components that get relocated during tag
execution, so their naming container hierarchy is different at tag execution
time vs. the rest of the lifecycle. To solve this problem, we need to have
getScopedIdForComponent return a scoped Id reflecting the original naming
container hierarchy for the component, i.e. return its pre-relocation scoped
ID.
This will require API additions on UIXComponent to allow relocated components
to provide their logical (original parent).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2048) ComponentUtils.getScopedIdForComponent() is not producing consistent scoped IDs for components relocated during tag execution
ComponentUtils.getScopedIdForComponent() is not producing consistent scoped IDs for components relocated during tag execution - Key: TRINIDAD-2048 URL: https://issues.apache.org/jira/browse/TRINIDAD-2048 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets getScopedIdForComponent() simply walks the parent hierarchy to append naming container IDs. However, we have components that get relocated during tag execution, so their naming container hierarchy is different at tag execution time vs. the rest of the lifecycle. To solve this problem, we need to have getScopedIdForComponent return a scoped Id reflecting the original naming container hierarchy for the component, i.e. return its pre-relocation scoped ID. This will require API additions on UIXComponent to allow relocated components to provide their logical (original parent). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2040) Issue 2034 introduced regression in StringArrayPropertyTagRule
Issue 2034 introduced regression in StringArrayPropertyTagRule -- Key: TRINIDAD-2040 URL: https://issues.apache.org/jira/browse/TRINIDAD-2040 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets To reproduce, run any Facelets page that uses partialTrigger attribute. You will see the following exception: java.lang.IllegalArgumentException: argument type mismatch [echo] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [echo] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [echo] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [echo] at java.lang.reflect.Method.invoke(Method.java:597) [echo] at org.apache.myfaces.trinidadinternal.facelets.StringArrayPropertyTagRule$LiteralPropertyMetadata.applyMetadata(StringArrayPropertyTagRule.java:66) [echo] at -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TRINIDAD-2040) Issue 2034 introduced regression in StringArrayPropertyTagRule
[ https://issues.apache.org/jira/browse/TRINIDAD-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12996575#comment-12996575 ] Max Starets commented on TRINIDAD-2040: --- The problem was that 'params; was declared as an Object, and not as an Onject[]. Issue 2034 introduced regression in StringArrayPropertyTagRule -- Key: TRINIDAD-2040 URL: https://issues.apache.org/jira/browse/TRINIDAD-2040 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets To reproduce, run any Facelets page that uses partialTrigger attribute. You will see the following exception: java.lang.IllegalArgumentException: argument type mismatch [echo] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [echo] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [echo] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [echo] at java.lang.reflect.Method.invoke(Method.java:597) [echo] at org.apache.myfaces.trinidadinternal.facelets.StringArrayPropertyTagRule$LiteralPropertyMetadata.applyMetadata(StringArrayPropertyTagRule.java:66) [echo] at -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (TRINIDAD-2040) Issue 2034 introduced regression in StringArrayPropertyTagRule
[ https://issues.apache.org/jira/browse/TRINIDAD-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets resolved TRINIDAD-2040. --- Resolution: Fixed Issue 2034 introduced regression in StringArrayPropertyTagRule -- Key: TRINIDAD-2040 URL: https://issues.apache.org/jira/browse/TRINIDAD-2040 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets To reproduce, run any Facelets page that uses partialTrigger attribute. You will see the following exception: java.lang.IllegalArgumentException: argument type mismatch [echo] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [echo] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [echo] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [echo] at java.lang.reflect.Method.invoke(Method.java:597) [echo] at org.apache.myfaces.trinidadinternal.facelets.StringArrayPropertyTagRule$LiteralPropertyMetadata.applyMetadata(StringArrayPropertyTagRule.java:66) [echo] at -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release of Trinidad 2.0.0 Beta 2 (Try 2)
+1 On 2/16/2011 9:48 AM, Scott O'Bryan wrote: Hey Everyone, Okay, I have checked in code to address TRINIDAD-2037 which was the issue raised by Matthias in the previous vote[1]. The artifacts have been regenerated and Matthias has tested the fix and it works. This is still a beta release so there are still a few open bugs, but all of the unit tests pass and this beta has undergone some considerable testing since the last release. Therefore I would like to ask for a re-vote on this release. All of the following should be ready for review: * The generated repository and assembly artifacts[2] * The generated source archive[3] * The updated svn repository[4] Please review the artifacts and vote according to the following: [ ] +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.. This vote will remain open for at least 72 hours. Thanks, Scott O'Bryan [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg51466.html [2] https://repository.apache.org/content/repositories/orgapachemyfaces-015/ [3] https://repository.apache.org/content/repositories/orgapachemyfaces-015/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-2/trinidad-2.0.0-beta-2-source-release.zip [4] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.0-beta-2
Re: [VOTE] Release for Trinidad 2.0.0-beta-2
+1 On 2/15/2011 4:09 AM, Scott O'Bryan wrote: +1 On 02/15/2011 02:09 AM, Scott O'Bryan wrote: Okay, so my first hickup. I forgot to include the voting part. :D [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Scott On 02/15/2011 01:59 AM, Scott O'Bryan wrote: Hey all, I was running the tasks needed to get the Trinidad 2.0.0-beta-2 release out and now I need a vote as to whether everything looks good or not. This is still a beta release so there are still a few open bugs, but all of the unit tests pass and this beta has undergone some considerable testing. I have deployed the artifacts to the Nexus Repository [1] for review. The release notes for the Trinidad 2.0.0-beta-2 release are on the JIRA site [2] for review as well. This vote will remain open for at least 72 hours. Thanks, Scott O'Bryan PS- This is my first release of Trinidad since moving over to NEXUS, so a lot of scrutiny and your suggestions would be much appreciated. [1] https://repository.apache.org/content/repositories/orgapachemyfaces-005/ [2] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661version=12316092 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310661version=12316092
[jira] Updated: (TRINIDAD-2034) DatePropertyTagRule and StringArrayPropertyTagRule cache mutable objects
[ https://issues.apache.org/jira/browse/TRINIDAD-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2034: -- Status: Patch Available (was: Open) DatePropertyTagRule and StringArrayPropertyTagRule cache mutable objects Key: TRINIDAD-2034 URL: https://issues.apache.org/jira/browse/TRINIDAD-2034 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets When DatePropertyTagRule and StringArrayPropertyTagRule are applied to attributes specified as string literals, the parsing results are cached on the tag. The issue is that the parsing results are mutable (java.util.Date and String[]), so they a) cannot be shared; b) cannot be cached. The fix will be to clone a new object every time LiteralPropertyMetadata.applyMetadata() is called. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (TRINIDAD-2034) DatePropertyTagRule and StringArrayPropertyTagRule cache mutable objects
[ https://issues.apache.org/jira/browse/TRINIDAD-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2034: -- Resolution: Fixed Status: Resolved (was: Patch Available) DatePropertyTagRule and StringArrayPropertyTagRule cache mutable objects Key: TRINIDAD-2034 URL: https://issues.apache.org/jira/browse/TRINIDAD-2034 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets Attachments: trinidad-2034.diff When DatePropertyTagRule and StringArrayPropertyTagRule are applied to attributes specified as string literals, the parsing results are cached on the tag. The issue is that the parsing results are mutable (java.util.Date and String[]), so they a) cannot be shared; b) cannot be cached. The fix will be to clone a new object every time LiteralPropertyMetadata.applyMetadata() is called. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TRINIDAD-2034) DatePropertyTagRule and StringArrayPropertyTagRule cache mutable objects
DatePropertyTagRule and StringArrayPropertyTagRule cache mutable objects Key: TRINIDAD-2034 URL: https://issues.apache.org/jira/browse/TRINIDAD-2034 Project: MyFaces Trinidad Issue Type: Bug Reporter: Max Starets Assignee: Max Starets When DatePropertyTagRule and StringArrayPropertyTagRule are applied to attributes specified as string literals, the parsing results are cached on the tag. The issue is that the parsing results are mutable (java.util.Date and String[]), so they a) cannot be shared; b) cannot be cached. The fix will be to clone a new object every time LiteralPropertyMetadata.applyMetadata() is called. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Myfaces js translation help
Werner,
Here are the Russian translations,
It;s been a while since I used Russian for anything related to
computing, so hopefully I have not messed up the terminology too much.
Max
MSG_TEST: ТестовоеСообщение,
/*Messages*/
MSG_DEV_MODE: Это сообщение выдано, потому что 'project stage' было
присоено значение 'development', и никаких +
других error listeners зарегистрировано не было.,
MSG_AFFECTED_CLASS: Задействованный класс:,
MSG_AFFECTED_METHOD: Задействованный метод:,
MSG_ERROR_NAME: Имя ошибки:,
MSG_ERROR_MESSAGE: Имя ошибки:,
MSG_ERROR_DESC: Описание ошибки:,
MSG_ERROR_NO: Номер ошибки:,
MSG_ERROR_LINENO: Номер строки ошибки:,
/*Errors and messages*/
ERR_FORM: Sourceform не найдена, потому что элемент не находится внутри
form, либо были найдены элементы form с рдинаковым именем или
идентификатором. Обработка ajax остановлена,
ERR_VIEWSTATE: jsf.viewState: Параметру присвоено значение, не
являющееся элементом form!,
ERR_TRANSPORT: Несуществующий тип транспорта {0},
ERR_EVT_PASS: Параметр event необходим, и не может быть null или
undefined,
ERR_CONSTRUCT: Часть ответа не удалось прочитать при создании данных
события: {0} ,
ERR_MALFORMEDXML: Ответ сервера не может быть обработан, он не в
формате xml !,
ERR_SOURCE_FUNC: source не может быть функцией (возможно, для source и
event не были даны значения,
ERR_EV_OR_UNKNOWN: Объект event или unknown должен быть всторым
параметром,
ERR_SOURCE_NOSTR: source не может быть типа string,
ERR_SOURCE_DEF_NULL: source должно быть присвоено значение или null,
//_Lang.js
ERR_MUST_STRING: {0}: {1} namespace должно быть типа String,
ERR_REF_OR_ID: {0}: {1} a Ссылочный узел (reference node) или
идентификатор необходимы,
ERR_PARAM_GENERIC: {0}: параметр {1} должен быть типа {2},
ERR_PARAM_STR: {0}: {1} параметр должен быть типа string,
ERR_PARAM_STR_RE: {0}: {1} параметр должен быть типа string string или
regular expression,
ERR_PARAM_MIXMAPS: {0}: source b destination map необходимы,
ERR_MUST_BE_PROVIDED: {0}: {1} и {2} необходимы,
ERR_MUST_BE_PROVIDED1: {0}: {1} должно быть присвоено значение,
ERR_REPLACE_EL: replaceElements вызвана, с evalNodes, не являющимся
массивом,
ERR_EMPTY_RESPONSE: {0}: Ответ не может бвть null или пустым!,
ERR_ITEM_ID_NOTFOUND: {0}: Элемент с идентификатором {1} не найден,
ERR_PPR_IDREQ: {0}: Ошибка в PPR Insert, id необходим,
ERR_PPR_INSERTBEFID: {0}: Ошибка в PPR Insert, before id или after id
необходимы,
ERR_PPR_INSERTBEFID_1: {0}: Ошибка в PPR Insert, before node c id {1}
не найден в документе,
ERR_PPR_INSERTBEFID_2: {0}: Ошибка в PPR Insert, after node с id {1} не
найден в документе,
ERR_PPR_DELID: {0}: Ошибка в удалении, id не найден в xml документе,
ERR_PPR_UNKNOWNCID: {0}: Неопознанный Html-Component-ID: {1},
ERR_NO_VIEWROOTATTR: {0}: Изменение атрибутов ViewRoot не предусмотрено,
ERR_NO_HEADATTR: {0}: Изменение атрибутов Head не предусмотрено,
ERR_RED_URL: {0}: Перенаправление (Redirect) без url
On 2/3/2011 1:20 PM, Werner Punz wrote:
Hello everyone I also could need some translation help for as many
languages as possible, so here is the deal, translate me please
following key value pairs so that I can add them to the myfaces
javascripts for the next release:
Currently we have english, german and dutch:
I could at least need spanish french italian, russian and chinese also
would be nice
MSG_TEST: Testmessage,
/*Messages*/
MSG_DEV_MODE: Note, this message is only sent, because project stage
is development and no +
other error listeners are registered.,
MSG_AFFECTED_CLASS: Affected Class:,
MSG_AFFECTED_METHOD: Affected Method:,
MSG_ERROR_NAME: Error Name:,
MSG_ERROR_MESSAGE: Error Name:,
MSG_ERROR_DESC: Error Description:,
MSG_ERROR_NO: Error Number:,
MSG_ERROR_LINENO: Error Line Number:,
/*Errors and messages*/
ERR_FORM: Sourceform could not be determined, either because element
is not attached to a form or we have multiple forms with named
elements of the same identifier or name, stopping the ajax processing,
ERR_VIEWSTATE: jsf.viewState: param value not of type form!,
ERR_TRANSPORT: Transport type {0} does not exist,
ERR_EVT_PASS: an event must be passed down (either a an event object
null or undefined) ,
ERR_CONSTRUCT: Parts of the response couldn't be retrieved when
constructing the event data: {0} ,
ERR_MALFORMEDXML: The server response could not be parsed, the server
has returned with a response which is not xml !,
ERR_SOURCE_FUNC: source cannot be a function (probably source and
event were not defined or set to null,
ERR_EV_OR_UNKNOWN: An event object or unknown must be passed as
second parameter,
ERR_SOURCE_NOSTR: source cannot be a string,
ERR_SOURCE_DEF_NULL: source must be defined or null,
//_Lang.js
ERR_MUST_STRING: {0}: {1} namespace must be of type String,
ERR_REF_OR_ID: {0}: {1} a reference node or identifier must be
provided,
ERR_PARAM_GENERIC: {0}: parameter {1} must be of type {2},
ERR_PARAM_STR: {0}: {1} param must be of type string,
ERR_PARAM_STR_RE: {0}:
[jira] Reopened: (TRINIDAD-1632) Trinidad 2 - exception thrown when partial state saving turned on
[ https://issues.apache.org/jira/browse/TRINIDAD-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets reopened TRINIDAD-1632: --- Assignee: Max Starets (was: Gabrielle Crawford) We are still seeing this issue when view root caching is enabled. Trinidad 2 - exception thrown when partial state saving turned on - Key: TRINIDAD-1632 URL: https://issues.apache.org/jira/browse/TRINIDAD-1632 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-alpha Reporter: Gabrielle Crawford Assignee: Max Starets Fix For: 2.0.0-alpha Set the following values in web.xml context-param param-namejavax.faces.PARTIAL_STATE_SAVING/param-name param-valuetrue/param-value /context-param context-param param-nameorg.apache.myfaces.trinidad.CHANGE_PERSISTENCE/param-name param-valueorg.apache.myfaces.trinidad.change.NullChangeManager/param-value /context-param context-param param-nameorg.apache.myfaces.trinidad.CACHE_VIEW_ROOT/param-name param-valuefalse/param-value /context-param context-param param-namejavax.faces.FACELETS_VIEW_MAPPINGS/param-name param-value*.xhtml;*.jspx/param-value /context-param Now render a page, initially it renders fine, but when you try to interact with the page, like click a command component, you get an exception java.lang.NullPointerException at org.apache.myfaces.trinidad.component.UIXComponentBase._getRendererImpl(UIXComponentBase.java:1145) at org.apache.myfaces.trinidad.component.UIXComponentBase._getLifecycleRendererImpl(UIXComponentBase.java:1159) at org.apache.myfaces.trinidad.component.UIXComponentBase.getLifecycleRenderer(UIXComponentBase.java:1184) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:978) at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:799) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1042) at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:940) at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:310) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292) at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at org.apache.myfaces.trinidaddemo.webapp.RedirectFilter.doFilter(RedirectFilter.java:97) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at oracle.dms.wls.DMSServletFilter.doFilter(DMSServletFilter.java:325) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3592) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2202) at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2108) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1432) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1632) Trinidad 2 - exception thrown when partial state saving turned on
[ https://issues.apache.org/jira/browse/TRINIDAD-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1632: -- Status: Patch Available (was: Reopened) Trinidad 2 - exception thrown when partial state saving turned on - Key: TRINIDAD-1632 URL: https://issues.apache.org/jira/browse/TRINIDAD-1632 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-alpha Reporter: Gabrielle Crawford Assignee: Max Starets Fix For: 2.0.0-alpha Attachments: trinidad-1632.patch Set the following values in web.xml context-param param-namejavax.faces.PARTIAL_STATE_SAVING/param-name param-valuetrue/param-value /context-param context-param param-nameorg.apache.myfaces.trinidad.CHANGE_PERSISTENCE/param-name param-valueorg.apache.myfaces.trinidad.change.NullChangeManager/param-value /context-param context-param param-nameorg.apache.myfaces.trinidad.CACHE_VIEW_ROOT/param-name param-valuefalse/param-value /context-param context-param param-namejavax.faces.FACELETS_VIEW_MAPPINGS/param-name param-value*.xhtml;*.jspx/param-value /context-param Now render a page, initially it renders fine, but when you try to interact with the page, like click a command component, you get an exception java.lang.NullPointerException at org.apache.myfaces.trinidad.component.UIXComponentBase._getRendererImpl(UIXComponentBase.java:1145) at org.apache.myfaces.trinidad.component.UIXComponentBase._getLifecycleRendererImpl(UIXComponentBase.java:1159) at org.apache.myfaces.trinidad.component.UIXComponentBase.getLifecycleRenderer(UIXComponentBase.java:1184) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:978) at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:799) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1042) at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:940) at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:310) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292) at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at org.apache.myfaces.trinidaddemo.webapp.RedirectFilter.doFilter(RedirectFilter.java:97) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at oracle.dms.wls.DMSServletFilter.doFilter(DMSServletFilter.java:325) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3592) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2202) at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2108) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1432) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at weblogic.work.ExecuteThread.run(ExecuteThread.java:173) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1632) Trinidad 2 - exception thrown when partial state saving turned on
[ https://issues.apache.org/jira/browse/TRINIDAD-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1632: -- Resolution: Fixed Fix Version/s: (was: 2.0.0-alpha) 2.0.0-alpha-2 Status: Resolved (was: Patch Available) Force full state saving for the view root if view root caching is enabled. Trinidad 2 - exception thrown when partial state saving turned on - Key: TRINIDAD-1632 URL: https://issues.apache.org/jira/browse/TRINIDAD-1632 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-alpha Reporter: Gabrielle Crawford Assignee: Max Starets Fix For: 2.0.0-alpha-2 Attachments: trinidad-1632.patch Set the following values in web.xml context-param param-namejavax.faces.PARTIAL_STATE_SAVING/param-name param-valuetrue/param-value /context-param context-param param-nameorg.apache.myfaces.trinidad.CHANGE_PERSISTENCE/param-name param-valueorg.apache.myfaces.trinidad.change.NullChangeManager/param-value /context-param context-param param-nameorg.apache.myfaces.trinidad.CACHE_VIEW_ROOT/param-name param-valuefalse/param-value /context-param context-param param-namejavax.faces.FACELETS_VIEW_MAPPINGS/param-name param-value*.xhtml;*.jspx/param-value /context-param Now render a page, initially it renders fine, but when you try to interact with the page, like click a command component, you get an exception java.lang.NullPointerException at org.apache.myfaces.trinidad.component.UIXComponentBase._getRendererImpl(UIXComponentBase.java:1145) at org.apache.myfaces.trinidad.component.UIXComponentBase._getLifecycleRendererImpl(UIXComponentBase.java:1159) at org.apache.myfaces.trinidad.component.UIXComponentBase.getLifecycleRenderer(UIXComponentBase.java:1184) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:978) at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:799) at javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1042) at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:940) at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:310) at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227) at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125) at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292) at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at org.apache.myfaces.trinidaddemo.webapp.RedirectFilter.doFilter(RedirectFilter.java:97) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at oracle.dms.wls.DMSServletFilter.doFilter(DMSServletFilter.java:325) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3592) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121) at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2202) at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2108) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1432) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201) at weblogic.work.ExecuteThread.run(ExecuteThread.java:173
Re: Trinidad 2.0: Should we provide release notes about having to disable partial state saving with Facelets
Hello Everyone, It appears that both 1632 and 1635 were fixed for the case when view root caching was disabled. The exception from 1632 was still there when we were caching the view root. I just submitted a fix, so barring any new issues we do not have to require that partial state saving be disabled. Thanks, Max On 1/27/2011 5:23 PM, Blake Sullivan wrote: It looks like that was fixed, so is the problem now TRINIDAD-1635 https://issues.apache.org/jira/browse/TRINIDAD-1635. -- Blake On 1/27/11 2:18 PM, Gabrielle Crawford wrote: There was this https://issues.apache.org/jira/browse/TRINIDAD-1632 On 1/26/2011 10:15 AM, MAX STARETS wrote: Blake, Andy and I have discussed this offline a bit, and his preference was we do not hack the flag to be off explicitly (he thought it would create even more confusion). He also suggested that we look at fixing the issues in Trinidad sooner rather than later. The users are getting the following exception: java.lang.NullPointerException at org.apache.myfaces.trinidad.component.UIXComponentBase._getRendererImpl(UIXComponentBase.java:1299) at org.apache.myfaces.trinidad.component.UIXComponentBase._cacheRenderer(UIXComponentBase.java:1279) at org.apache.myfaces.trinidad.component.UIXComponentBase.__rendererDecode(UIXComponentBase.java:1193) at org.apache.myfaces.trinidad.component.UIXComponentBase.decode(UIXComponentBase.java:724) at org.apache.myfaces.trinidad.component.UIXForm.processDecodes(UIXForm.java:71) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImpl(UIXComponentBase.java:1081) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:1067) at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:839) It is caused by the absence of the render kit Id on the view root after state restoration. *Gabrielle*, I thought you have prototyped a fix for this issue a while back. Do you have the the code somewhere? Thanks, Max On 1/26/2011 12:23 PM, Blake Sullivan wrote: I think we need to do both--essentially force partial state saving off and document that we are going to force it off. -- Blake Sullivan On 1/26/11 6:57 AM, Matthias Wessendorf wrote: On Wed, Jan 26, 2011 at 3:33 PM, MAX STARETSmax.star...@oracle.com wrote: Hello Everyone, I think we need to do something about the fact that any Facelets application with Trinidad 2.0 will fail in a very non-obvious way unless partial state saving is disabled with the following context parameter: context-param param-namejavax.faces.PARTIAL_STATE_SAVING/param-name param-valuefalse/param-value /context-param I see two options: Document it prominently in the release notes Try to fake the parameter in Trinidad code as always being set. I am not sure if (2) is feasible, but the advantage would be that the users will not have to manually re-enable partial state saving when we resolve the compatibility issues. I am fine with (2), even if it's a bit hacky :-) Opinions? Max
Trinidad 2.0: Should we provide release notes about having to disable partial state saving with Facelets
Hello Everyone, I think we need to do something about the fact that any Facelets application with Trinidad 2.0 will fail in a very non-obvious way unless partial state saving is disabled with the following context parameter: context-param param-namejavax.faces.PARTIAL_STATE_SAVING/param-name param-valuefalse/param-value /context-param I see two options: 1. Document it prominently in the release notes 2. Try to fake the parameter in Trinidad code as always being set. I am not sure if (2) is feasible, but the advantage would be that the users will not have to manually re-enable partial state saving when we resolve the compatibility issues. Opinions? Max
Re: [Trinidad] jsf2_ajax N branches
I don't think so. Max On 1/26/2011 8:51 AM, Matthias Wessendorf wrote: Hi, do we still need the various jsf2_ajax branches? Thx, Matthias
Re: Trinidad 2.0: Should we provide release notes about having to disable partial state saving with Facelets
Blake, Andy and I have discussed this offline a bit, and his preference was we do not hack the flag to be off explicitly (he thought it would create even more confusion). He also suggested that we look at fixing the issues in Trinidad sooner rather than later. The users are getting the following exception: java.lang.NullPointerException at org.apache.myfaces.trinidad.component.UIXComponentBase._getRendererImpl(UIXComponentBase.java:1299) at org.apache.myfaces.trinidad.component.UIXComponentBase._cacheRenderer(UIXComponentBase.java:1279) at org.apache.myfaces.trinidad.component.UIXComponentBase.__rendererDecode(UIXComponentBase.java:1193) at org.apache.myfaces.trinidad.component.UIXComponentBase.decode(UIXComponentBase.java:724) at org.apache.myfaces.trinidad.component.UIXForm.processDecodes(UIXForm.java:71) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildrenImpl(UIXComponentBase.java:1081) at org.apache.myfaces.trinidad.component.UIXComponentBase.decodeChildren(UIXComponentBase.java:1067) at org.apache.myfaces.trinidad.component.UIXComponentBase.processDecodes(UIXComponentBase.java:839) It is caused by the absence of the render kit Id on the view root after state restoration. *Gabrielle*, I thought you have prototyped a fix for this issue a while back. Do you have the the code somewhere? Thanks, Max On 1/26/2011 12:23 PM, Blake Sullivan wrote: I think we need to do both--essentially force partial state saving off and document that we are going to force it off. -- Blake Sullivan On 1/26/11 6:57 AM, Matthias Wessendorf wrote: On Wed, Jan 26, 2011 at 3:33 PM, MAX STARETSmax.star...@oracle.com wrote: Hello Everyone, I think we need to do something about the fact that any Facelets application with Trinidad 2.0 will fail in a very non-obvious way unless partial state saving is disabled with the following context parameter: context-param param-namejavax.faces.PARTIAL_STATE_SAVING/param-name param-valuefalse/param-value /context-param I see two options: Document it prominently in the release notes Try to fake the parameter in Trinidad code as always being set. I am not sure if (2) is feasible, but the advantage would be that the users will not have to manually re-enable partial state saving when we resolve the compatibility issues. I am fine with (2), even if it's a bit hacky :-) Opinions? Max
Re: [VOTE] Apache MyFaces Trinidad 2.0.0-beta-1
+1 On 1/21/2011 6:44 AM, Matthias Wessendorf wrote: Hi, I've created a Trinidad 2.0.0-beta-1 release candidate, with the following artifacts up for a vote: SVN source tag (r1061736): http://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.0-beta-1/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachemyfaces-062/ Source release: https://repository.apache.org/content/repositories/orgapachemyfaces-062/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-1/trinidad-2.0.0-beta-1-source-release.zip Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Matthias
Re: [VOTE] Trinidad plugins: 2.0.4
+1 On 1/17/2011 4:28 AM, Scott O'Bryan wrote: +1 On Jan 17, 2011, at 2:01 AM, Mark Strubergstrub...@yahoo.de wrote: +1 (since I've seen NOTICE.txt got already fixed in SVN and will be here in the next release) LieGrue, strub --- On Mon, 1/17/11, Matthias Wessendorfmat...@apache.org wrote: From: Matthias Wessendorfmat...@apache.org Subject: [VOTE] Trinidad plugins: 2.0.4 To: MyFaces Developmentdev@myfaces.apache.org Date: Monday, January 17, 2011, 8:12 AM Hi, I've created a 2.0.4 release candidate, with the following artifacts up for a vote: SVN source tag (r1059776): http://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.4/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachemyfaces-034/ Source release: https://repository.apache.org/content/repositories/orgapachemyfaces-034/org/apache/myfaces/trinidadbuild/maven-plugin-parent/2.0.4/maven-plugin-parent-2.0.4-source-release.zip [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (TRINIDAD-2010) Agent's support for web crawlers should include Oracle SES
Agent's support for web crawlers should include Oracle SES -- Key: TRINIDAD-2010 URL: https://issues.apache.org/jira/browse/TRINIDAD-2010 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha-2 Reporter: Max Starets Assignee: Max Starets -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-2010) Agent's support for web crawlers should include Oracle SES
[ https://issues.apache.org/jira/browse/TRINIDAD-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2010: -- Status: Patch Available (was: Open) Agent's support for web crawlers should include Oracle SES -- Key: TRINIDAD-2010 URL: https://issues.apache.org/jira/browse/TRINIDAD-2010 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha-2 Reporter: Max Starets Assignee: Max Starets Attachments: trinidad2010.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-2010) Agent's support for web crawlers should include Oracle SES
[ https://issues.apache.org/jira/browse/TRINIDAD-2010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2010: -- Resolution: Fixed Fix Version/s: 2.0.0-beta-1 Status: Resolved (was: Patch Available) Agent's support for web crawlers should include Oracle SES -- Key: TRINIDAD-2010 URL: https://issues.apache.org/jira/browse/TRINIDAD-2010 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha-2 Reporter: Max Starets Assignee: Max Starets Fix For: 2.0.0-beta-1 Attachments: trinidad2010.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-2008) tr:panelBorderLayout is throwing exception with Mojarra during tag execution
tr:panelBorderLayout is throwing exception with Mojarra during tag execution Key: TRINIDAD-2008 URL: https://issues.apache.org/jira/browse/TRINIDAD-2008 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha-2 Environment: Mojarra 2.0.4, WLS Reporter: Max Starets To reproduce the issue, try running the following test.xhtml page: f:view xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; tr:document tr:form tr:panelBorderLayout/ /tr:form /tr:document /f:view You will notice java.lang.ExceptionInInitializerError at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.clinit(PanelBorderLayoutRenderer.java:1102) The root cause is the following exception: java.lang.NullPointerException at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:171) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.init(NamedLocaleInfoScriptlet.java:62) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.registerNamedLocales(NamedLocaleInfoScriptlet.java:47) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.XhtmlScriptletFactory.registerAllScriptlets(XhtmlScriptletFactory.java:73) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlUtils.clinit(XhtmlUtils.java:825) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.clinit(PanelBorderLayoutRenderer.java:1102) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.apache.myfaces.trinidadinternal.renderkit.ClassRendererInstantiator.instantiate(ClassRendererInstantiator.java:49) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.findRenderer(RenderKitBase.java:167) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:104) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:114) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.getRenderer(RenderKitBase.java:129) at com.sun.faces.application.ApplicationImpl.applyAnnotations(ApplicationImpl.java:1915) at com.sun.faces.application.ApplicationImpl.createComponentApplyAnnotations(ApplicationImpl.java:1864) at com.sun.faces.application.ApplicationImpl.createComponent(ApplicationImpl.java:1125) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.createComponent(ComponentTagHandlerDelegateImpl.java:513) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:153) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:94) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:163) at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:89) at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:79) at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:148) at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:740
Re: [VOTE] Apache MyFaces Trinidad 2.0.0-beta-1
+1 On 1/14/2011 7:10 AM, Matthias Wessendorf wrote: Hi, I've created a Trinidad 2.0.0-beta-1 release candidate, with the following artifacts up for a vote: SVN source tag (r1058869): http://svn.apache.org/repos/asf/myfaces/trinidad/tags/2.0.0-beta-1/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachemyfaces-025/ Source release: https://repository.apache.org/content/repositories/orgapachemyfaces-025/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-1/trinidad-2.0.0-beta-1-source-release.zip Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Matthias
[jira] Reopened: (TRINIDAD-2008) tr:panelBorderLayout is throwing exception with Mojarra during tag execution
[ https://issues.apache.org/jira/browse/TRINIDAD-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets reopened TRINIDAD-2008: --- I am seeing it with the latest build tr:panelBorderLayout is throwing exception with Mojarra during tag execution Key: TRINIDAD-2008 URL: https://issues.apache.org/jira/browse/TRINIDAD-2008 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha-2 Environment: Mojarra 2.0.4, WLS Reporter: Max Starets To reproduce the issue, try running the following test.xhtml page: f:view xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; tr:document tr:form tr:panelBorderLayout/ /tr:form /tr:document /f:view You will notice java.lang.ExceptionInInitializerError at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.clinit(PanelBorderLayoutRenderer.java:1102) The root cause is the following exception: java.lang.NullPointerException at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:171) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.init(NamedLocaleInfoScriptlet.java:62) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.registerNamedLocales(NamedLocaleInfoScriptlet.java:47) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.XhtmlScriptletFactory.registerAllScriptlets(XhtmlScriptletFactory.java:73) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlUtils.clinit(XhtmlUtils.java:825) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.clinit(PanelBorderLayoutRenderer.java:1102) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.apache.myfaces.trinidadinternal.renderkit.ClassRendererInstantiator.instantiate(ClassRendererInstantiator.java:49) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.findRenderer(RenderKitBase.java:167) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:104) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:114) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.getRenderer(RenderKitBase.java:129) at com.sun.faces.application.ApplicationImpl.applyAnnotations(ApplicationImpl.java:1915) at com.sun.faces.application.ApplicationImpl.createComponentApplyAnnotations(ApplicationImpl.java:1864) at com.sun.faces.application.ApplicationImpl.createComponent(ApplicationImpl.java:1125) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.createComponent(ComponentTagHandlerDelegateImpl.java:513) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:153) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:94) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:163) at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:89) at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:79
Re: [VOTE] Apache MyFaces Trinidad 2.0.0-beta-1
Actually I think we should take a quick look at https://issues.apache.org/jira/browse/TRINIDAD-2008 first to decide how important it is. Max On 1/14/2011 11:25 AM, MAX STARETS wrote: +1 On 1/14/2011 7:10 AM, Matthias Wessendorf wrote: Hi, I've created a Trinidad 2.0.0-beta-1 release candidate, with the following artifacts up for a vote: SVN source tag (r1058869): http://svn.apache.org/repos/asf/myfaces/trinidad/tags/2.0.0-beta-1/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachemyfaces-025/ Source release: https://repository.apache.org/content/repositories/orgapachemyfaces-025/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-1/trinidad-2.0.0-beta-1-source-release.zip Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Matthias
[jira] Updated: (TRINIDAD-2008) tr:panelBorderLayout is throwing exception with Mojarra during tag execution
[ https://issues.apache.org/jira/browse/TRINIDAD-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2008: -- Status: Patch Available (was: Reopened) tr:panelBorderLayout is throwing exception with Mojarra during tag execution Key: TRINIDAD-2008 URL: https://issues.apache.org/jira/browse/TRINIDAD-2008 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha-2 Environment: Mojarra 2.0.4, WLS Reporter: Max Starets Assignee: Max Starets Attachments: TRINIDAD-2002.patch To reproduce the issue, try running the following test.xhtml page: f:view xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; tr:document tr:form tr:panelBorderLayout/ /tr:form /tr:document /f:view You will notice java.lang.ExceptionInInitializerError at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.clinit(PanelBorderLayoutRenderer.java:1102) The root cause is the following exception: java.lang.NullPointerException at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:171) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.init(NamedLocaleInfoScriptlet.java:62) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.registerNamedLocales(NamedLocaleInfoScriptlet.java:47) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.XhtmlScriptletFactory.registerAllScriptlets(XhtmlScriptletFactory.java:73) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlUtils.clinit(XhtmlUtils.java:825) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.clinit(PanelBorderLayoutRenderer.java:1102) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.apache.myfaces.trinidadinternal.renderkit.ClassRendererInstantiator.instantiate(ClassRendererInstantiator.java:49) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.findRenderer(RenderKitBase.java:167) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:104) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:114) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.getRenderer(RenderKitBase.java:129) at com.sun.faces.application.ApplicationImpl.applyAnnotations(ApplicationImpl.java:1915) at com.sun.faces.application.ApplicationImpl.createComponentApplyAnnotations(ApplicationImpl.java:1864) at com.sun.faces.application.ApplicationImpl.createComponent(ApplicationImpl.java:1125) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.createComponent(ComponentTagHandlerDelegateImpl.java:513) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:153) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:94) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:163) at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:89
[jira] Updated: (TRINIDAD-2008) tr:panelBorderLayout is throwing exception with Mojarra during tag execution
[ https://issues.apache.org/jira/browse/TRINIDAD-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2008: -- Resolution: Fixed Fix Version/s: 2.0.0-beta-1 Status: Resolved (was: Patch Available) tr:panelBorderLayout is throwing exception with Mojarra during tag execution Key: TRINIDAD-2008 URL: https://issues.apache.org/jira/browse/TRINIDAD-2008 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha-2 Environment: Mojarra 2.0.4, WLS Reporter: Max Starets Assignee: Max Starets Fix For: 2.0.0-beta-1 Attachments: TRINIDAD-2002.patch To reproduce the issue, try running the following test.xhtml page: f:view xmlns=http://www.w3.org/1999/xhtml; xmlns:h=http://java.sun.com/jsf/html; xmlns:f=http://java.sun.com/jsf/core; xmlns:tr=http://myfaces.apache.org/trinidad; tr:document tr:form tr:panelBorderLayout/ /tr:form /tr:document /f:view You will notice java.lang.ExceptionInInitializerError at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.clinit(PanelBorderLayoutRenderer.java:1102) The root cause is the following exception: java.lang.NullPointerException at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:171) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.init(NamedLocaleInfoScriptlet.java:62) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.registerNamedLocales(NamedLocaleInfoScriptlet.java:47) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.XhtmlScriptletFactory.registerAllScriptlets(XhtmlScriptletFactory.java:73) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlUtils.clinit(XhtmlUtils.java:825) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.clinit(PanelBorderLayoutRenderer.java:1102) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at java.lang.Class.newInstance0(Class.java:355) at java.lang.Class.newInstance(Class.java:308) at org.apache.myfaces.trinidadinternal.renderkit.ClassRendererInstantiator.instantiate(ClassRendererInstantiator.java:49) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.findRenderer(RenderKitBase.java:167) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:104) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.findRenderer(RenderKitDecorator.java:114) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.getRenderer(RenderKitBase.java:129) at com.sun.faces.application.ApplicationImpl.applyAnnotations(ApplicationImpl.java:1915) at com.sun.faces.application.ApplicationImpl.createComponentApplyAnnotations(ApplicationImpl.java:1864) at com.sun.faces.application.ApplicationImpl.createComponent(ApplicationImpl.java:1125) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.createComponent(ComponentTagHandlerDelegateImpl.java:513) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:153) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:94) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:133) at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:180) at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:116) at com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:163
[jira] Commented: (TRINIDAD-1960) NullPointerException in LocaleInfoScriptlet.getSupportedLocaleVariant
[ https://issues.apache.org/jira/browse/TRINIDAD-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12981931#action_12981931 ] Max Starets commented on TRINIDAD-1960: --- The fix for TRINIDAD-2008 on the trunk would probably work here as well NullPointerException in LocaleInfoScriptlet.getSupportedLocaleVariant - Key: TRINIDAD-1960 URL: https://issues.apache.org/jira/browse/TRINIDAD-1960 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.14-core Environment: Mac OS X 10.6, Java 6, Glassfish 3.0.2 Reporter: Manuel Blechschmidt Attachments: PreventNullPointerInLocaleInfoScroptlet.patch Hi, I tried to deploy trinidad in a web app to my Glassfish Server. After reporting and fixing TRINIDAD-1959 I get the following problem: Caused by: java.lang.NullPointerException at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:171) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.init(NamedLocaleInfoScriptlet.java:62) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.registerNamedLocales(NamedLocaleInfoScriptlet.java:47) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.XhtmlScriptletFactory.registerAllScriptlets(XhtmlScriptletFactory.java:73) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.XhtmlUtils.clinit(XhtmlUtils.java:598) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBorderLayoutRenderer.clinit(PanelBorderLayoutRenderer.java:1050) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at org.apache.myfaces.extensions.validator.generic.renderkit.ExtValGenericRenderKit.intercept(ExtValGenericRenderKit.java:84) at org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit$$EnhancerByCGLIB$$30834978.addRenderer(generated) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase._loadRenderKitMap(RenderKitBase.java:258) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBase.init(RenderKitBase.java:56) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitDecorator.init(RenderKitDecorator.java:39) at org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit.init(CoreRenderKit.java:168) at org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderKit$$EnhancerByCGLIB$$30834978.init(generated) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:228) at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:220) at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:216) at net.sf.cglib.proxy.Enhancer.createUsingReflection(Enhancer.java:640) at net.sf.cglib.proxy.Enhancer.firstInstance(Enhancer.java:538) at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:225) at net.sf.cglib.proxy.Enhancer.createHelper(Enhancer.java:377) at net.sf.cglib.proxy.Enhancer.create(Enhancer.java:285) at org.apache.myfaces.extensions.validator.generic.renderkit.ExtValGenericRenderKit.newInstance(ExtValGenericRenderKit.java:62) at org.apache.myfaces.extensions.validator.generic.renderkit.GenericRenderKitWrapperFactory.createWrapper(GenericRenderKitWrapperFactory.java:45) at org.apache.myfaces.extensions.validator.core.renderkit.DefaultRenderKitWrapperFactory.createWrapper(DefaultRenderKitWrapperFactory.java:54) at org.apache.myfaces.extensions.validator.core.renderkit.ExtValRenderKitFactory.getRenderKit(ExtValRenderKitFactory.java:84) at org.apache.myfaces.trinidadinternal.renderkit.CoreRenderKitFactory.getRenderKit(CoreRenderKitFactory.java:55) at com.sun.faces.config.processor.RenderKitConfigProcessor.process(RenderKitConfigProcessor.java:170) at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:114) at com.sun.faces.config.processor.ManagedBeanConfigProcessor.process(ManagedBeanConfigProcessor.java:270) at com.sun.faces.config.processor.AbstractConfigProcessor.invokeNext(AbstractConfigProcessor.java:114
Re: [VOTE] Trinidad core: 1.2.14
+1 On 9/7/2010 2:47 PM, Blake Sullivan wrote: +1 On 9/7/10 11:30 AM, Matthias Wessendorf wrote: +1 sent from my Android phone On Sep 7, 2010 8:27 PM, Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org wrote: Hi, I was running the needed tasks to get the next release of the Apache MyFaces Trinidad 1.2.x CORE out. The artifacts are deployed to my private Apache account ([1]). Please take a look at the 1.2.14 artifacts and vote. The release includes fixes and the new casablanca skin. [ ] +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, Matthias [1] http://people.apache.org/~matzew/staging_repo/ http://people.apache.org/%7Ematzew/staging_repo/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] Apache MyFaces Trinidad 1.2.14
+1 On 1/10/2011 11:28 AM, Matthias Wessendorf wrote: Hi, I've created a Trinidad 1.2.14 release candidate, with the following artifacts up for a vote: SVN source tag (r1057250): http://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-1.2.14/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachemyfaces-013/ Source release: https://repository.apache.org/content/repositories/orgapachemyfaces-013/org/apache/myfaces/trinidad/trinidad/1.2.14/trinidad-1.2.14-source-release.zip Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Matthias
[jira] Updated: (TRINIDAD-2002) TrinidadFilterImpl FacesContext initialization
[ https://issues.apache.org/jira/browse/TRINIDAD-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-2002: -- Resolution: Fixed Fix Version/s: 2.0.0.3-core Status: Resolved (was: Patch Available) patch committed. TrinidadFilterImpl FacesContext initialization -- Key: TRINIDAD-2002 URL: https://issues.apache.org/jira/browse/TRINIDAD-2002 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0-alpha Reporter: Andy Schwartz Priority: Minor Fix For: 2.0.0.3-core Attachments: TRINIDAD-2002.patch ADF Faces hooks into Trinidad's TrinidadFilterImpl sub-filter service and uses this to perform early configuration/initialization work. In particular, we use the ApplicationFactory to get at the Application instance and then create/add converters to the Application. This works fine on Mojarra 2.0.x releases. However, this fails in both: - MyFaces 2.0.x - Mojarra 2.1.x In both cases, the reason for the failure is that access to the FacesContext is required but is not yet available. In MyFaces 2.0.x, the FacesContext/ExternalContext is required by Application.createConverter()/setConverterProperties() in order to determine the value of the javax.faces.DATETIMECONVERTER_DEFAULT_TIMEZONE_IS_SYSTEM_TIMEZONE context parameter. In Mojarra 2.1.x, the ApplicationFactory requires access to the FacesContext in order to create the Application instance. While we can work around this issue at the ADF Faces level, TrinidadFilterImpl is already well positioned to address this - ie. TrinidadFilterImpl has access to the PseudoFacesContext and already sets this up for other cases (eg. for Configurator.beginRequest()). I am logging this issue to request that we take advantage of the existing support that TrinidadFilterImpl/PseudoFacesContext provides for early FacesContext access and extend this to TrinidadFilterImpl.init(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Trinidad plugins: 2.0.3 release
+1 On 1/10/2011 8:46 AM, Matthias Wessendorf wrote: Hi, I've created a 2.0.3 release candidate, with the following artifacts up for a vote: SVN source tag (r1057187): http://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.3/ Maven staging repo: https://repository.apache.org/content/repositories/orgapachemyfaces-012/ Source release: https://repository.apache.org/content/repositories/orgapachemyfaces-012/org/apache/myfaces/trinidadbuild/maven-plugin-parent/2.0.3/maven-plugin-parent-2.0.3-source-release.zip Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, Matthias
[jira] Updated: (TRINIDAD-1764) System event listener state saving
[ https://issues.apache.org/jira/browse/TRINIDAD-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Starets updated TRINIDAD-1764: -- Resolution: Fixed Fix Version/s: 2.0.0.3-core Status: Resolved (was: Patch Available) System event listener state saving -- Key: TRINIDAD-1764 URL: https://issues.apache.org/jira/browse/TRINIDAD-1764 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 2.0.0-alpha Reporter: Andy Schwartz Assignee: Max Starets Fix For: 2.0.0.3-core Attachments: trinidad-1764.patch The JSF specification requires that UIComponent provide implementations for the following new system event-related methods: - subscribeToEvent() - unsubscribeFromEvent() - getListenersForEventClass() Both Mojarra and MyFaces provide implementations of these methods in UIComponent. However, UIComponent itself does not provide any state saving implementation. This is provided by UIComponentBase - ie. UIComponentBase handles state saving for system event listeners stored on the UIComponent instance. This approach is flawed in that it only provides correct behavior for component implementations that extend UIComponentBase. Components that extend UIComponent directly will be subtly broken in that system event listeners can be registered, but will not be state saved. Furthermore, since the system event listener storage in UIComponent is package-private, there is no way for components that extend UIComponent directly to handle state saving for registered listeners. The only option is for components that extend UIComponent directly to implement their own (redundant) storage for system event listeners so that the component implementation can provide its own state saving implementation. Since all of the Trinidad components extend UIComponent (not UIComponentBase), we'll need to implement such a solution in UIXComponentBase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
TRINIDAD-1764
Hello Everyone, I am planning to commit a patch for TRINIDAD-1764 within the next two days. I wanted to alert the dev list about the pending check-in since we will be changing FacesBean API (the methods related to ClientBehaviors will be removed). Please let me know if you have concerns or objects about this change. The change has been reviewed by Andrew Robinson and Blake Sullivan. Thank you and Happy New Year, Max
