[jira] Commented: (ORCHESTRA-40) A transaction token component inspired by the struts transaction processor
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763854#action_12763854 ] Mario Ivankovits commented on ORCHESTRA-40: --- I think we all agree, having a decent handling for this thing is a long missing feature here in JSF land. I also agree that it is much more a virulent problem when you use a conversation framework as it is much likely that you run into problems with the database else. The question is if we need it strongly integrated into Orchestra. I've looked at the patch, and beside that something gets stored into the conversationContext I can not see anything which can not be solved using normal JSF phase listeners. And for storing into the conversationContext we can create a scope which does this (instead of accessing it directly). You also gain the ability to decide on which level the tokens are kept. If you do not use Orchestra you simply can the manager bean into the session then. I'd say this component qualifies for its own project, e.g. within our ext (sorry, lost the name) project. On the other hand, I understand that - compared to seam and webflow - people await such functionality from Orchestra too. If we add this to Orchestra, I'd like to see it in a separated module, e.g. orchestra-jsfext. Would this be feasible? As for the technical aspect of this patch, I have some notes: 1) Does this solution work with ajax, or will an ajax request trigger a DOUBLE_SUBMIT_OR_RELOAD_TYPE notification? I think ajax detection needs to be added, at least to detect JSF 2.0 alike ajax requests. 2) I see you store the token in the request parameter. Probably - in the context of ajax - storing it as attribute on the UIViewRoot might be better. If you have to deal with ajax requests you are able to update this value then with the new token. I am also constantly thinking about moving the conversationContext paramter into the UIViewRoot - but this is another story. 3) We should also add a default TransactionTokenListener which behaves in a way we think an application should react on these events.People than can use it to jump start the system. Probably something like MyTransactionTokenListener with a faces message added so the user will get some feedback. 4) I'd like to have a way to "ignore" some requests. E.g. if you issue an jsf action which will just stream a PDF to the user (without page change), the browser stay on the page, but the token has been "used" then. The current token needs to be added to the list of used tokens at the end of the request then. Probably an API like TransactionTokenManager.getInstance().ignoreRequest() suppress this addittion then for the current request. The token can then be used again. Also trinidad has at least two components which open a window and just report the value back to the main window. Probably we also need a way to ignore requests based on an URL pattern to deal with that? Ciao, Mario > A transaction token component inspired by the struts transaction processor > -- > > Key: ORCHESTRA-40 > URL: https://issues.apache.org/jira/browse/ORCHESTRA-40 > Project: MyFaces Orchestra > Issue Type: New Feature > Components: Conversation >Affects Versions: 1.3.1 >Reporter: Bernd Bohmann >Assignee: Simon Kitching > Attachments: > ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, > ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, > ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch > > > A transactionToken Component for orchestra inspired by the struts transaction > processor. > The transaction token is to be used for enforcing a single request for a > particular transaction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jsf 2.0] UISelectItems does not implement getter and setter for attributes added on f:selectItems
Hi Checking some stuff about jsf 2.0, I have seen that f:selectItems added some new attributes, but UISelectItems javadoc does not have getter and setters for them. In theory, every attribute defined for a component should have getter and setter (with some exceptions like "binding"). On myfaces, we add getter and setter without notice it. Is this a typo error, or this is intentional? regards Leonardo Uribe
[jira] Reopened: (MYFACES-2309) Add new attributes to f:selectItems
[ https://issues.apache.org/jira/browse/MYFACES-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe reopened MYFACES-2309: - UISelectItems javadoc does not have getter and setters for them, so we have to ask EG for this and if is true, update our code. > Add new attributes to f:selectItems > --- > > Key: MYFACES-2309 > URL: https://issues.apache.org/jira/browse/MYFACES-2309 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Fix For: 2.0.0-alpha > > Attachments: selectitems_new_attributes.patch > > > New attributes where added to f:selectItems tag. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-40) A transaction token component inspired by the struts transaction processor
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763785#action_12763785 ] Martin Marinschek commented on ORCHESTRA-40: Ok, so there was a lot of action here, but not really a lot of discussion. Let's discuss about the base first: Bernd's (and by the way also Manfred's and mine) point of view is that a JSF application should have a way to be informed of back-button clicks, forward-button clicks, refreshes, double-submits, etc. As I see it, an interface implemented by the application should provide a hook which needs to be called in such cases. Now for me this is highly conversation-context (=tab or window) related: a back-button is always clicked within a tab or window. If you want to indicate to the user that the back-button has been pressed you will need to store a list of tokens (one per request) and again, I think that should be stored per conversation-context (not in the session). If it is not for this, Orchestra should provide ways to handle these problems cause a solution is desperately needed in the JSF space. AFAIK, only Spring Webflow provides something out of the box, and with Spring Webflow you are moving pretty far off the JSF standard, both from a configuration perspective and a usage perspective (however, I am not saying that Spring Webflow is bad - it is indeed a very good framework - just not very close to JSF if you take a deeper look at it). regards, Martin > A transaction token component inspired by the struts transaction processor > -- > > Key: ORCHESTRA-40 > URL: https://issues.apache.org/jira/browse/ORCHESTRA-40 > Project: MyFaces Orchestra > Issue Type: New Feature > Components: Conversation >Affects Versions: 1.3.1 >Reporter: Bernd Bohmann >Assignee: Simon Kitching > Attachments: > ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, > ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, > ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch > > > A transactionToken Component for orchestra inspired by the struts transaction > processor. > The transaction token is to be used for enforcing a single request for a > particular transaction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ORCHESTRA-41) NullPointerException in method findConversationContextId
[ https://issues.apache.org/jira/browse/ORCHESTRA-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Marinschek resolved ORCHESTRA-41. Resolution: Cannot Reproduce Assignee: Martin Marinschek > NullPointerException in method findConversationContextId > > > Key: ORCHESTRA-41 > URL: https://issues.apache.org/jira/browse/ORCHESTRA-41 > Project: MyFaces Orchestra > Issue Type: Bug > Components: Conversation, FrameworkAdapter >Affects Versions: 1.3.1 > Environment: Windows XP SP2, Tomcat 6.0.20 >Reporter: Bozhidar Bozhanov >Assignee: Martin Marinschek > Original Estimate: 0.08h > Remaining Estimate: 0.08h > > After some time, (probably when a thread times-out) the following appears: > Exception in thread > "org.apache.myfaces.orchestra.conversation.ConversationWiperThread" > java.lang.NullPointerException > at > org.apache.myfaces.orchestra.conversation.ConversationManager.findConversationContextId(ConversationManager.java:140) > at > org.apache.myfaces.orchestra.conversation.ConversationManager.removeAndInvalidateConversationContext(ConversationManager.java:343) > at > org.apache.myfaces.orchestra.conversation.ConversationManager.checkTimeouts(ConversationManager.java:626) > at > org.apache.myfaces.orchestra.conversation.ConversationWiperThread._run(ConversationWiperThread.java:113) > at > org.apache.myfaces.orchestra.conversation.ConversationWiperThread.run(ConversationWiperThread.java:90) > It doesn't bring any trouble to the front-end, but still, it is an exception > :) > The problem, I think is that the ThreadLocal variable (after the thread has > timed-out) return null, so no conversationContext anymore. A little anti-NPE > check in the findConversaionContextId would get rid of the exception. > I'm not sure whether this happens in 1.3.1, I checked the source code in the > repository and there was no NPE check, so I presume the issue is still there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
JSF 2.0 upgrade of our component libraries / extensions
Hi all, I just posted the following Orchestra issue: Orchestra should support JSF 2.0. The supplied patch changes the decorators in Orchestra to allow this, however, the patch is not backwards compatible with the 1.2/1.1 version (and contrary to supporting both 1.1 and 1.2 in one version, this is not possible with 2.0 anymore, as the interfaces have new methods which in turn have parameters/return types which are only available in JSF 2.0). The question will be how we will be able to continue. I see two options: a) a branch, and two independent releases b) adding a common JSF 1.2 compatibility library, which would allow to a certain extent to mimick basic JSF 2.0 infrastructure (it would not try to reimplement features from 2.0, however) For option b), I would like to get your input. Does that sound reasonable/useful for you? In cs-JSF in Credit-Suisse, we do follow this approach. regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Created: (ORCHESTRA-45) Support for JSF 2.0
Support for JSF 2.0 --- Key: ORCHESTRA-45 URL: https://issues.apache.org/jira/browse/ORCHESTRA-45 Project: MyFaces Orchestra Issue Type: Improvement Components: FrameworkAdapter Affects Versions: 1.3.1 Reporter: Martin Marinschek Orchestra should support JSF 2.0. The supplied patch changes the decorators in Orchestra to allow this, however, the patch is not backwards compatible with the 1.2/1.1 version (and contrary to supporting both 1.1 and 1.2 in one version, this is not possible with 2.0 anymore, as the interfaces have new methods which in turn have parameters/return types which are only available in JSF 2.0). The question will be how we will be able to continue. I see two options: a) a branch, and two independent releases b) adding a common JSF 1.2 compatibility library, which would allow to a certain extent to mimick basic JSF 2.0 infrastructure (it would not try to reimplement features from 2.0, however) I will also post this question to the MyFaces mailing-list, and we will see how to proceed from here. regards, Martin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2370) 'invokeOnComponent' method in UIData does not properly process header/footer facets
[ https://issues.apache.org/jira/browse/MYFACES-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763736#action_12763736 ] Kennard Consulting commented on MYFACES-2370: - Terrific. Thanks for the quick turnaround guys. Look forward to trying it. > 'invokeOnComponent' method in UIData does not properly process > header/footer facets > -- > > Key: MYFACES-2370 > URL: https://issues.apache.org/jira/browse/MYFACES-2370 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 1.2.7 >Reporter: Kennard Consulting >Assignee: Leonardo Uribe > Fix For: 1.2.8-SNAPSHOT > > Attachments: uidata.patch > > > A bug that was originally reported to the RichFaces project here (includes > simple test case)... > https://jira.jboss.org/jira/browse/RF-7700 > ...was identifed by the RichFaces team as being caused by failure to process > header/footer facets in 'invokeOnComponent'. The RichFaces team > reported this to the Mojarra guys... > https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1308 > ...who fixed it in their implementation (as of 1.2_14) > I then put together a MyFaces version of the same test case (attached as > suggestionMyFaces.zip)... > https://jira.jboss.org/jira/browse/RF-7700 > ...and it appears MyFaces (as of 1.2.7) has the same bug? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2370) 'invokeOnComponent' method in UIData does not properly process header/footer facets
[ https://issues.apache.org/jira/browse/MYFACES-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-2370: Resolution: Fixed Fix Version/s: 1.2.8-SNAPSHOT Assignee: Leonardo Uribe Status: Resolved (was: Patch Available) Thanks to Jakob Korherr for provide this patch > 'invokeOnComponent' method in UIData does not properly process > header/footer facets > -- > > Key: MYFACES-2370 > URL: https://issues.apache.org/jira/browse/MYFACES-2370 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 1.2.7 >Reporter: Kennard Consulting >Assignee: Leonardo Uribe > Fix For: 1.2.8-SNAPSHOT > > Attachments: uidata.patch > > > A bug that was originally reported to the RichFaces project here (includes > simple test case)... > https://jira.jboss.org/jira/browse/RF-7700 > ...was identifed by the RichFaces team as being caused by failure to process > header/footer facets in 'invokeOnComponent'. The RichFaces team > reported this to the Mojarra guys... > https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1308 > ...who fixed it in their implementation (as of 1.2_14) > I then put together a MyFaces version of the same test case (attached as > suggestionMyFaces.zip)... > https://jira.jboss.org/jira/browse/RF-7700 > ...and it appears MyFaces (as of 1.2.7) has the same bug? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2136) UISelectMany
[ https://issues.apache.org/jira/browse/MYFACES-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-2136: Resolution: Fixed Fix Version/s: 2.0.0-alpha Assignee: Leonardo Uribe Status: Resolved (was: Patch Available) Thanks to Jakob Korherr for provide this patch > UISelectMany > > > Key: MYFACES-2136 > URL: https://issues.apache.org/jira/browse/MYFACES-2136 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Simon-Pierre Béliveau >Assignee: Leonardo Uribe > Fix For: 2.0.0-alpha > > Attachments: uiselectmany_conversion.patch > > > The currently selected items can be stored in a Collection. > Store the result of each conversion in a data structure, called > targetForConvertedValues for discussion. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2330) Get "basic-ajax" 2.0 sample app working
[ https://issues.apache.org/jira/browse/MYFACES-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2330. - Resolution: Fixed Fix Version/s: 2.0.0-alpha Assignee: Leonardo Uribe At this time everything is working well, so I'll close this issue. We can reopen it later if necessary (more examples here...) > Get "basic-ajax" 2.0 sample app working > --- > > Key: MYFACES-2330 > URL: https://issues.apache.org/jira/browse/MYFACES-2330 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Curtiss Howard >Assignee: Leonardo Uribe > Fix For: 2.0.0-alpha > > > Get the Mojarra "basic-ajax" sample app working. This app tests UI > templating and AJAX. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2340) Get "basic-ezcomp" 2.0 sample working
[ https://issues.apache.org/jira/browse/MYFACES-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2340. - Resolution: Fixed Assignee: Leonardo Uribe At this time everything is working well, so I'll close this issue. We can reopen it later if necessary (more examples here...) > Get "basic-ezcomp" 2.0 sample working > - > > Key: MYFACES-2340 > URL: https://issues.apache.org/jira/browse/MYFACES-2340 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Curtiss Howard >Assignee: Leonardo Uribe > Fix For: 2.0.0-alpha > > > Get the "basic-ezcomp" Mojarra 2.0 sample working. This sample makes > extensive use of composite components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] JSF 2.0
I don't believe that SessionSerializationChecker should have a getWrapped method yet. This class follows the pattern of the Collections decorators which don't have getWrapped(). -- Blake Sullivan Martin Kočí said the following On 10/8/2009 3:55 AM PT: Hi, I'm using trinidad with mojarra 2.0. These are steps to get trinidad compiled and running on JSF 2.0: 1) Since 2.0 all method on wrappers are public. In this case it is: - org.apache.myfaces.trinidadinternal.application.StateManagerImpl - make getWrapped public - org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl - make getWrapped -> public Those changes are backward compatible with 1.2. 2) Make NavigationHandlerImpl child of javax.faces.application.ConfigurableNavigationHandler 3) Use javax.faces.context.ExternalContextWrapper instead of ExternalContextDecorator and make changes: - SessionSerializationChecker - add method getWrapped - XmlHttpPortletExternalContext -add method getWrapped - OverrideDispatch - add method getWrapped - ClearRequestExternalContext - add method getWrapped 4) Use Facelets API from javax.faces instead of com.sun I'll create patches - can you add version 2.0 to JIRA please? Matthias Wessendorf píše v Čt 08. 10. 2009 v 10:24 +0200: Hello Andy, I created the "experimental" branch on this location: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x Greetings, Matthias On Thu, Oct 8, 2009 at 2:37 AM, Andy Schwartz wrote: Gang - I am interested in taking a closer look at Trinidad/JSF 2.0 integration. I suspect that there are other folks who are interested in this as well. Would it be possible to create a Trinidad branch for JSF 2.0-related work? For the moment, I think that an experimental/sandbox-type branch that we could use for prototyping purposes would be helpful/would facilitate collaboration on this effort. Thoughts? Andy
[jira] Commented: (MYFACES-2340) Get "basic-ezcomp" 2.0 sample working
[ https://issues.apache.org/jira/browse/MYFACES-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763669#action_12763669 ] Leonardo Uribe commented on MYFACES-2340: - Committed fix partial state saving suscribe add/remove components view listener after relocate components. > Get "basic-ezcomp" 2.0 sample working > - > > Key: MYFACES-2340 > URL: https://issues.apache.org/jira/browse/MYFACES-2340 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Affects Versions: 2.0.0-alpha >Reporter: Curtiss Howard > Fix For: 2.0.0-alpha > > > Get the "basic-ezcomp" Mojarra 2.0 sample working. This sample makes > extensive use of composite components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1591) [Trinidad2] Make trinidad runnable on JSF 2.0
[Trinidad2] Make trinidad runnable on JSF 2.0 - Key: TRINIDAD-1591 URL: https://issues.apache.org/jira/browse/TRINIDAD-1591 Project: MyFaces Trinidad Issue Type: Task Components: Build Affects Versions: 2.0.0-core Environment: trinidad 2.0 branch, JSF 2.0 Mojarra Reporter: Martin Koci - org.apache.myfaces.trinidadinternal.application.StateManagerImpl - make getWrapped public - org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl - make getWrapped public - make NavigationHandlerImpl child of javax.faces.application.ConfigurableNavigationHandler - use javax.faces.context.ExternalContextWrapper instead of ExternalContextDecorator and make changes: - SessionSerializationChecker - add method getWrapped - XmlHttpPortletExternalContext -add method getWrapped - OverrideDispatch - add method getWrapped - ClearRequestExternalContext - add method getWrapped - Use Facelets API from javax.faces instead of com.sun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1591) [Trinidad2] Make trinidad runnable on JSF 2.0
[ https://issues.apache.org/jira/browse/TRINIDAD-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Koci updated TRINIDAD-1591: -- Status: Patch Available (was: Open) > [Trinidad2] Make trinidad runnable on JSF 2.0 > - > > Key: TRINIDAD-1591 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1591 > Project: MyFaces Trinidad > Issue Type: Task > Components: Build >Affects Versions: 2.0.0-core > Environment: trinidad 2.0 branch, JSF 2.0 Mojarra >Reporter: Martin Koci > > - org.apache.myfaces.trinidadinternal.application.StateManagerImpl - > make getWrapped public > - org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl - make > getWrapped public > - make NavigationHandlerImpl child of > javax.faces.application.ConfigurableNavigationHandler > - use javax.faces.context.ExternalContextWrapper instead of > ExternalContextDecorator > and make changes: > - SessionSerializationChecker - add method getWrapped > - XmlHttpPortletExternalContext -add method getWrapped > - OverrideDispatch - add method getWrapped > - ClearRequestExternalContext - add method getWrapped > - Use Facelets API from javax.faces instead of com.sun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1590) maven-jdev-plugin: added ability to set JVM Java Options. Default is "-ea" to enable assertions
[
https://issues.apache.org/jira/browse/TRINIDAD-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Kind updated TRINIDAD-1590:
Status: Patch Available (was: Open)
> maven-jdev-plugin: added ability to set JVM Java Options. Default is "-ea" to
> enable assertions
> ---
>
> Key: TRINIDAD-1590
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1590
> Project: MyFaces Trinidad
> Issue Type: New Feature
>Affects Versions: 1.2.10-plugins
>Reporter: Gary Kind
>
> In Jdeveloper under Project Properties -> Run/Debug/Profile, edit a selected
> profile and you will see a Java Options input text field to the right of the
> selected JVM. An attribute has been added to the maven-jdev-plugin to set
> these Java Options. Here is a sample of how it would be set in a maven
> pom.xml file:
>
> org.apache.myfaces.trinidadbuild
> maven-jdev-plugin
>
> -ea
> ${jdev.project.has.tests}
>
> ${project.basedir}/src/test
>
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1590) maven-jdev-plugin: added ability to set JVM Java Options. Default is "-ea" to enable assertions
maven-jdev-plugin: added ability to set JVM Java Options. Default is "-ea" to
enable assertions
---
Key: TRINIDAD-1590
URL: https://issues.apache.org/jira/browse/TRINIDAD-1590
Project: MyFaces Trinidad
Issue Type: New Feature
Affects Versions: 1.2.10-plugins
Reporter: Gary Kind
In Jdeveloper under Project Properties -> Run/Debug/Profile, edit a selected
profile and you will see a Java Options input text field to the right of the
selected JVM. An attribute has been added to the maven-jdev-plugin to set
these Java Options. Here is a sample of how it would be set in a maven pom.xml
file:
org.apache.myfaces.trinidadbuild
maven-jdev-plugin
-ea
${jdev.project.has.tests}
${project.basedir}/src/test
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2378) Use java util logging on 2.0.x branch
[ https://issues.apache.org/jira/browse/MYFACES-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763536#action_12763536 ] Leonardo Uribe commented on MYFACES-2378: - Ok. After take a look at these arguments, I think it is better to keep the full class name as the key for now, because it is more simple. > Use java util logging on 2.0.x branch > - > > Key: MYFACES-2378 > URL: https://issues.apache.org/jira/browse/MYFACES-2378 > Project: MyFaces Core > Issue Type: Task > Components: JSR-314 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > Attachments: MYFACES-2378-core.patch, MYFACES-2378-shared-core.patch > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2370) 'invokeOnComponent' method in UIData does not properly process header/footer facets
[ https://issues.apache.org/jira/browse/MYFACES-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2370: --- Status: Patch Available (was: Open) > 'invokeOnComponent' method in UIData does not properly process > header/footer facets > -- > > Key: MYFACES-2370 > URL: https://issues.apache.org/jira/browse/MYFACES-2370 > Project: MyFaces Core > Issue Type: Bug > Components: General >Affects Versions: 1.2.7 >Reporter: Kennard Consulting > Attachments: uidata.patch > > > A bug that was originally reported to the RichFaces project here (includes > simple test case)... > https://jira.jboss.org/jira/browse/RF-7700 > ...was identifed by the RichFaces team as being caused by failure to process > header/footer facets in 'invokeOnComponent'. The RichFaces team > reported this to the Mojarra guys... > https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1308 > ...who fixed it in their implementation (as of 1.2_14) > I then put together a MyFaces version of the same test case (attached as > suggestionMyFaces.zip)... > https://jira.jboss.org/jira/browse/RF-7700 > ...and it appears MyFaces (as of 1.2.7) has the same bug? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: TRINIDAD-1558 - NPE w/ Googlebot
ok... the fix for "TRINIDAD-1520" does fix this as well. Thx, Matthias On Thu, Oct 8, 2009 at 1:52 PM, Matthias Wessendorf wrote: > Hi, > > there were several issues in the past regarding exceptions w/ the > Googlebot engine. > > Does one know if this: > https://issues.apache.org/jira/browse/TRINIDAD-1558 > > has been fixed with the recent checkins ? > > Thanks! > Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Updated: (TRINIDAD-1558) java.lang.NullPointerException: version must be non-null with Googlebot agent (trindad trunk)
[ https://issues.apache.org/jira/browse/TRINIDAD-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf updated TRINIDAD-1558: - Resolution: Duplicate Fix Version/s: 1.2.13-core Status: Resolved (was: Patch Available) this is a duplicate of TRINIDAD-1520. The bug has been fixed with the fix for TRINIDAD-1520 > java.lang.NullPointerException: version must be non-null with Googlebot agent > (trindad trunk) > -- > > Key: TRINIDAD-1558 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1558 > Project: MyFaces Trinidad > Issue Type: Bug >Affects Versions: 1.2.13-core > Environment: Linux 2.6 Java(TM) SE Runtime Environment (build > 1.6.0_16-b01) tomcat 6.0.18 myfaces-api/impl-1.2.7 trinidad-api/impl > 1.2.13-SNAPSHOT (trunk) >Reporter: Angel >Priority: Critical > Fix For: 1.2.13-core > > > when request with the header of Googlebots comes > org/apache/myfaces/trinidadinternal/agent/AgentImpl.java gets initialized > with String _agent = NULL; and String _agentVersion = NULL; and a NPE is > thrown: > java.lang.NullPointerException: version must be non-null > at > org.apache.myfaces.trinidad.context.Version._checkNonEmptyString(Version.java:197) > at org.apache.myfaces.trinidad.context.Version.(Version.java:69) > at org.apache.myfaces.trinidad.context.Version.(Version.java:54) > at > org.apache.myfaces.trinidadinternal.style.util.NameUtils._isBrowserAndVersionMatch(NameUtils.java:640) > at > org.apache.myfaces.trinidadinternal.style.util.NameUtils.getContextName(NameUtils.java:344) > at > org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache.getTargetStyleSheetName(FileSystemStyleCache.java:325) > at > org.apache.myfaces.trinidadinternal.skin.SkinStyleProvider.getTargetStyleSheetName(SkinStyleProvider.java:199) > at > org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache._getOutputFiles(FileSystemStyleCache.java:879) > at > org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache._createStyleSheetFiles(FileSystemStyleCache.java:757) > at > org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache._createEntry(FileSystemStyleCache.java:542) > at > org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache._getEntry(FileSystemStyleCache.java:445) > at > org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache.getStyleSheetURIs(FileSystemStyleCache.java:165) > at > org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.StyleSheetRenderer.encodeAll(StyleSheetRenderer.java:97) > at > org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:446) > at > org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.HeadRenderer.encodeBegin(HeadRenderer.java:80) > at > org.apache.myfaces.trinidad.render.CoreRenderer.encodeBegin(CoreRenderer.java:311) > at > org.apache.myfaces.trinidad.component.UIXComponentBase.encodeBegin(UIXComponentBase.java:718) > at > org.apache.myfaces.trinidad.component.UIXComponentBase.__encodeRecursive(UIXComponentBase.java:1478) > at > org.apache.myfaces.trinidad.component.UIXComponentBase.__encodeRecursive(UIXComponentBase.java:1489) > at > org.apache.myfaces.trinidad.component.UIXComponentBase.encodeAll(UIXComponentBase.java:771) > at javax.faces.component.UIComponent.encodeAll(UIComponent.java:257) > at > org.apache.myfaces.application.jsp.JspViewHandlerImpl.actuallyRenderView(JspViewHandlerImpl.java:427) > at > org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:383) > at > javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:48) > at > org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:193) > at > org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41) > at > org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140) > at javax.faces.webapp.FacesServlet.service(FacesServlet.java:155) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown > Source) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown > Source) > 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.Applicati
TRINIDAD-1558 - NPE w/ Googlebot
Hi, there were several issues in the past regarding exceptions w/ the Googlebot engine. Does one know if this: https://issues.apache.org/jira/browse/TRINIDAD-1558 has been fixed with the recent checkins ? Thanks! Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad] JSF 2.0
On Thu, Oct 8, 2009 at 1:33 PM, Martin Kočí wrote:
>
> Matthias Wessendorf píše v Čt 08. 10. 2009 v 12:50 +0200:
>> the goal is not only to make it running with JSF 2.0;
>> the goal is to support JSF 2.0 features w/in Trinidad.
>
> Yes, I understand that. Right now I'm working on Resource API support -
> I'll provide some patches for #{resource['image.jpg']} etc.
cool :)
>
>
> Martin
>
>>
>> -Matthias
>>
>> On Thu, Oct 8, 2009 at 12:55 PM, Martin Kočí wrote:
>> > Hi,
>> >
>> > I'm using trinidad with mojarra 2.0. These are steps to get trinidad
>> > compiled and running on JSF 2.0:
>> >
>> > 1) Since 2.0 all method on wrappers are public. In this case it is:
>> > - org.apache.myfaces.trinidadinternal.application.StateManagerImpl -
>> > make getWrapped public
>> > - org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl - make
>> > getWrapped -> public
>> >
>> > Those changes are backward compatible with 1.2.
>> >
>> >
>> > 2) Make NavigationHandlerImpl child of
>> > javax.faces.application.ConfigurableNavigationHandler
>> >
>> >
>> > 3) Use javax.faces.context.ExternalContextWrapper instead of
>> > ExternalContextDecorator
>> >
>> > and make changes:
>> > - SessionSerializationChecker - add method getWrapped
>> > - XmlHttpPortletExternalContext -add method getWrapped
>> > - OverrideDispatch - add method getWrapped
>> > - ClearRequestExternalContext - add method getWrapped
>> >
>> >
>> > 4) Use Facelets API from javax.faces instead of com.sun
>> >
>> >
>> >
>> > I'll create patches - can you add version 2.0 to JIRA please?
>> >
>> >
>> > Matthias Wessendorf píše v Čt 08. 10. 2009 v 10:24 +0200:
>> >> Hello Andy,
>> >>
>> >> I created the "experimental" branch on this location:
>> >>
>> >> https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x
>> >>
>> >>
>> >> Greetings,
>> >> Matthias
>> >>
>> >>
>> >> On Thu, Oct 8, 2009 at 2:37 AM, Andy Schwartz
>> >> wrote:
>> >> > Gang -
>> >> >
>> >> > I am interested in taking a closer look at Trinidad/JSF 2.0
>> >> > integration. I suspect that there are other folks who are interested
>> >> > in this as well. Would it be possible to create a Trinidad branch for
>> >> > JSF 2.0-related work? For the moment, I think that an
>> >> > experimental/sandbox-type branch that we could use for prototyping
>> >> > purposes would be helpful/would facilitate collaboration on this
>> >> > effort.
>> >> >
>> >> > Thoughts?
>> >> >
>> >> > Andy
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: [Trinidad] JSF 2.0
Matthias Wessendorf píše v Čt 08. 10. 2009 v 12:50 +0200:
> the goal is not only to make it running with JSF 2.0;
> the goal is to support JSF 2.0 features w/in Trinidad.
Yes, I understand that. Right now I'm working on Resource API support -
I'll provide some patches for #{resource['image.jpg']} etc.
Martin
>
> -Matthias
>
> On Thu, Oct 8, 2009 at 12:55 PM, Martin Kočí wrote:
> > Hi,
> >
> > I'm using trinidad with mojarra 2.0. These are steps to get trinidad
> > compiled and running on JSF 2.0:
> >
> > 1) Since 2.0 all method on wrappers are public. In this case it is:
> > - org.apache.myfaces.trinidadinternal.application.StateManagerImpl -
> > make getWrapped public
> > - org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl - make
> > getWrapped -> public
> >
> > Those changes are backward compatible with 1.2.
> >
> >
> > 2) Make NavigationHandlerImpl child of
> > javax.faces.application.ConfigurableNavigationHandler
> >
> >
> > 3) Use javax.faces.context.ExternalContextWrapper instead of
> > ExternalContextDecorator
> >
> > and make changes:
> > - SessionSerializationChecker - add method getWrapped
> > - XmlHttpPortletExternalContext -add method getWrapped
> > - OverrideDispatch - add method getWrapped
> > - ClearRequestExternalContext - add method getWrapped
> >
> >
> > 4) Use Facelets API from javax.faces instead of com.sun
> >
> >
> >
> > I'll create patches - can you add version 2.0 to JIRA please?
> >
> >
> > Matthias Wessendorf píše v Čt 08. 10. 2009 v 10:24 +0200:
> >> Hello Andy,
> >>
> >> I created the "experimental" branch on this location:
> >>
> >> https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x
> >>
> >>
> >> Greetings,
> >> Matthias
> >>
> >>
> >> On Thu, Oct 8, 2009 at 2:37 AM, Andy Schwartz
> >> wrote:
> >> > Gang -
> >> >
> >> > I am interested in taking a closer look at Trinidad/JSF 2.0
> >> > integration. I suspect that there are other folks who are interested
> >> > in this as well. Would it be possible to create a Trinidad branch for
> >> > JSF 2.0-related work? For the moment, I think that an
> >> > experimental/sandbox-type branch that we could use for prototyping
> >> > purposes would be helpful/would facilitate collaboration on this
> >> > effort.
> >> >
> >> > Thoughts?
> >> >
> >> > Andy
> >> >
> >>
> >>
> >>
> >
> >
>
>
>
[jira] Created: (TOMAHAWK-1461) WARNING: Invalid tag found: unexpected input while looking for attr name or '/>' at line 10. Surroundings: '" name="form_SUBMIT" value="1"'.
WARNING: Invalid tag found: unexpected input while looking for attr name or '/>' at line 10. Surroundings: '" name="form_SUBMIT" value="1"'. Key: TOMAHAWK-1461 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1461 Project: MyFaces Tomahawk Issue Type: Bug Components: Examples Affects Versions: 1.1.9, 1.1.7 Environment: Tomcat 6, myfaces-impl-1.1.7, myfaces-api-1.1.7 and tomahawk-1.1.9. Working on myfaces-example-blank-1.1.9 war file in eclipse. Reporter: khushwinder Priority: Critical I am trying to run following jsp page : <%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %> <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f"%> Hello World Because thaevalue of inputText value box is ending with \\ slashes i am getting the following warning: WARNING: Invalid tag found: unexpected input while looking for attr name or '/>' at line 10. Surroundings: '" name="form_SUBMIT" value="1"'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1589) Light Weight Dialog adjustment to standard window behaviour
[ https://issues.apache.org/jira/browse/TRINIDAD-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radek Hodain updated TRINIDAD-1589: --- Status: Patch Available (was: Open) > Light Weight Dialog adjustment to standard window behaviour > --- > > Key: TRINIDAD-1589 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1589 > Project: MyFaces Trinidad > Issue Type: New Feature > Components: Skinning >Reporter: Radek Hodain >Priority: Trivial > Attachments: icons.zip, maxSize.png, patch.txt, userSize.png > > Original Estimate: 1h > Remaining Estimate: 1h > > Add Minimize and the Restore-down buttons into light weight dialog to better > adjustment to standard window behavior. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] JSF 2.0
done; added "2.0.0-core" -Matthias On Thu, Oct 8, 2009 at 12:50 PM, Matthias Wessendorf wrote: > oh, yes. I will add a new version :-) > > Thanks for the feedback! > > On Thu, Oct 8, 2009 at 12:50 PM, Matthias Wessendorf > wrote: >> the goal is not only to make it running with JSF 2.0; >> the goal is to support JSF 2.0 features w/in Trinidad. >> >> -Matthias >> >> On Thu, Oct 8, 2009 at 12:55 PM, Martin Kočí wrote: >>> Hi, >>> >>> I'm using trinidad with mojarra 2.0. These are steps to get trinidad >>> compiled and running on JSF 2.0: >>> >>> 1) Since 2.0 all method on wrappers are public. In this case it is: >>> - org.apache.myfaces.trinidadinternal.application.StateManagerImpl - >>> make getWrapped public >>> - org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl - make >>> getWrapped -> public >>> >>> Those changes are backward compatible with 1.2. >>> >>> >>> 2) Make NavigationHandlerImpl child of >>> javax.faces.application.ConfigurableNavigationHandler >>> >>> >>> 3) Use javax.faces.context.ExternalContextWrapper instead of >>> ExternalContextDecorator >>> >>> and make changes: >>> - SessionSerializationChecker - add method getWrapped >>> - XmlHttpPortletExternalContext -add method getWrapped >>> - OverrideDispatch - add method getWrapped >>> - ClearRequestExternalContext - add method getWrapped >>> >>> >>> 4) Use Facelets API from javax.faces instead of com.sun >>> >>> >>> >>> I'll create patches - can you add version 2.0 to JIRA please? >>> >>> >>> Matthias Wessendorf píše v Čt 08. 10. 2009 v 10:24 +0200: Hello Andy, I created the "experimental" branch on this location: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x Greetings, Matthias On Thu, Oct 8, 2009 at 2:37 AM, Andy Schwartz wrote: > Gang - > > I am interested in taking a closer look at Trinidad/JSF 2.0 > integration. I suspect that there are other folks who are interested > in this as well. Would it be possible to create a Trinidad branch for > JSF 2.0-related work? For the moment, I think that an > experimental/sandbox-type branch that we could use for prototyping > purposes would be helpful/would facilitate collaboration on this > effort. > > Thoughts? > > Andy > >>> >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad] JSF 2.0
oh, yes. I will add a new version :-) Thanks for the feedback! On Thu, Oct 8, 2009 at 12:50 PM, Matthias Wessendorf wrote: > the goal is not only to make it running with JSF 2.0; > the goal is to support JSF 2.0 features w/in Trinidad. > > -Matthias > > On Thu, Oct 8, 2009 at 12:55 PM, Martin Kočí wrote: >> Hi, >> >> I'm using trinidad with mojarra 2.0. These are steps to get trinidad >> compiled and running on JSF 2.0: >> >> 1) Since 2.0 all method on wrappers are public. In this case it is: >> - org.apache.myfaces.trinidadinternal.application.StateManagerImpl - >> make getWrapped public >> - org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl - make >> getWrapped -> public >> >> Those changes are backward compatible with 1.2. >> >> >> 2) Make NavigationHandlerImpl child of >> javax.faces.application.ConfigurableNavigationHandler >> >> >> 3) Use javax.faces.context.ExternalContextWrapper instead of >> ExternalContextDecorator >> >> and make changes: >> - SessionSerializationChecker - add method getWrapped >> - XmlHttpPortletExternalContext -add method getWrapped >> - OverrideDispatch - add method getWrapped >> - ClearRequestExternalContext - add method getWrapped >> >> >> 4) Use Facelets API from javax.faces instead of com.sun >> >> >> >> I'll create patches - can you add version 2.0 to JIRA please? >> >> >> Matthias Wessendorf píše v Čt 08. 10. 2009 v 10:24 +0200: >>> Hello Andy, >>> >>> I created the "experimental" branch on this location: >>> >>> https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x >>> >>> >>> Greetings, >>> Matthias >>> >>> >>> On Thu, Oct 8, 2009 at 2:37 AM, Andy Schwartz >>> wrote: >>> > Gang - >>> > >>> > I am interested in taking a closer look at Trinidad/JSF 2.0 >>> > integration. I suspect that there are other folks who are interested >>> > in this as well. Would it be possible to create a Trinidad branch for >>> > JSF 2.0-related work? For the moment, I think that an >>> > experimental/sandbox-type branch that we could use for prototyping >>> > purposes would be helpful/would facilitate collaboration on this >>> > effort. >>> > >>> > Thoughts? >>> > >>> > Andy >>> > >>> >>> >>> >> >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad] JSF 2.0
the goal is not only to make it running with JSF 2.0; the goal is to support JSF 2.0 features w/in Trinidad. -Matthias On Thu, Oct 8, 2009 at 12:55 PM, Martin Kočí wrote: > Hi, > > I'm using trinidad with mojarra 2.0. These are steps to get trinidad > compiled and running on JSF 2.0: > > 1) Since 2.0 all method on wrappers are public. In this case it is: > - org.apache.myfaces.trinidadinternal.application.StateManagerImpl - > make getWrapped public > - org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl - make > getWrapped -> public > > Those changes are backward compatible with 1.2. > > > 2) Make NavigationHandlerImpl child of > javax.faces.application.ConfigurableNavigationHandler > > > 3) Use javax.faces.context.ExternalContextWrapper instead of > ExternalContextDecorator > > and make changes: > - SessionSerializationChecker - add method getWrapped > - XmlHttpPortletExternalContext -add method getWrapped > - OverrideDispatch - add method getWrapped > - ClearRequestExternalContext - add method getWrapped > > > 4) Use Facelets API from javax.faces instead of com.sun > > > > I'll create patches - can you add version 2.0 to JIRA please? > > > Matthias Wessendorf píše v Čt 08. 10. 2009 v 10:24 +0200: >> Hello Andy, >> >> I created the "experimental" branch on this location: >> >> https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x >> >> >> Greetings, >> Matthias >> >> >> On Thu, Oct 8, 2009 at 2:37 AM, Andy Schwartz >> wrote: >> > Gang - >> > >> > I am interested in taking a closer look at Trinidad/JSF 2.0 >> > integration. I suspect that there are other folks who are interested >> > in this as well. Would it be possible to create a Trinidad branch for >> > JSF 2.0-related work? For the moment, I think that an >> > experimental/sandbox-type branch that we could use for prototyping >> > purposes would be helpful/would facilitate collaboration on this >> > effort. >> > >> > Thoughts? >> > >> > Andy >> > >> >> >> > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad] JSF 2.0
Hi, I'm using trinidad with mojarra 2.0. These are steps to get trinidad compiled and running on JSF 2.0: 1) Since 2.0 all method on wrappers are public. In this case it is: - org.apache.myfaces.trinidadinternal.application.StateManagerImpl - make getWrapped public - org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl - make getWrapped -> public Those changes are backward compatible with 1.2. 2) Make NavigationHandlerImpl child of javax.faces.application.ConfigurableNavigationHandler 3) Use javax.faces.context.ExternalContextWrapper instead of ExternalContextDecorator and make changes: - SessionSerializationChecker - add method getWrapped - XmlHttpPortletExternalContext -add method getWrapped - OverrideDispatch - add method getWrapped - ClearRequestExternalContext - add method getWrapped 4) Use Facelets API from javax.faces instead of com.sun I'll create patches - can you add version 2.0 to JIRA please? Matthias Wessendorf píše v Čt 08. 10. 2009 v 10:24 +0200: > Hello Andy, > > I created the "experimental" branch on this location: > > https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x > > > Greetings, > Matthias > > > On Thu, Oct 8, 2009 at 2:37 AM, Andy Schwartz > wrote: > > Gang - > > > > I am interested in taking a closer look at Trinidad/JSF 2.0 > > integration. I suspect that there are other folks who are interested > > in this as well. Would it be possible to create a Trinidad branch for > > JSF 2.0-related work? For the moment, I think that an > > experimental/sandbox-type branch that we could use for prototyping > > purposes would be helpful/would facilitate collaboration on this > > effort. > > > > Thoughts? > > > > Andy > > > > >
Re: xmlmenumodel not displaying sub menus with trinidad/jsf
Your focusViewId should be something like '/dept.jspx' and '/emp.jspx'
and not '/dept' and '/emp'.
Try putting an outputText on your page to see what the focusViewId is
for that page:
Thanks,
Abhi
On Thu, Oct 8, 2009 at 12:00 PM, ADFUR wrote:
>
> Hi Abhi,
>
> I am using trinidad 1.2.12. I made changes that you suggested, am still
> getting the same output.
>
> modified metadata file is as below.
>
> http://myfaces.apache.org/trinidad/menu";>
>
> action="__dept_adfMenu_action__" focusViewId="/dept"/>
>
> action="__emp_adfMenu_action__" focusViewId="/emp">
> focusViewId="/emp1"/>
> focusViewId="/emp2"/>
>
> action="__emp_dnd_adfMenu_action__" focusViewId="/emp_dnd"/>
>
>
> modified jspx code is as below.
>
>
> level="0"
> hint="tabs" id="navigationPane1">
>
> action="#{menuInfo.doAction}"
> id="pt_cni2"/>
>
>
>
> level="1"
> hint="bar" id="pt_np3">
>
> action="#{menuInfo.doAction}"
> id="pt_cni3"/>
>
>
>
> Do I need to code anything at the server side?
>
> Thanks,
> UR
>
>
>
> Abhijit Ghosh wrote:
>>
>> Please let us know what version of trinidad you are using.Your tag
>> code seems fine.The menu metadata xml has the same focusViewId for the
>> parent and two of it's children,I don't think that is correct.Also
>> selected=true is not needed on the commandNavigationItems,though I
>> doubt it would cause the problem you are describing.Can you make the
>> above changes and try it out.
>>
>>
>> Thanks,
>> Abhi
>>
>>
>>
>>
>> On Tue, Oct 6, 2009 at 3:00 AM, ADFUR wrote:
>>>
>>> I am trying to display two level menus in my application. I am getting
>>> top
>>> level menu at the sub level.
>>> Am I missing anything?
>>>
>>> Here is my (meta data) root_menu.xml file.
>>>
>>>
>>> http://myfaces.apache.org/trinidad/menu";>
>>>
>>> >> action="__dept_adfMenu_action__" focusViewId="/dept"/>
>>> >> action="__emp_adfMenu_action__" focusViewId="/emp">
>>> >> focusViewId="/emp"/>
>>> >> focusViewId="/emp"/>
>>>
>>>
>>>
>>> >> action="__emp_dnd_adfMenu_action__" focusViewId="/emp_dnd"/>
>>>
>>>
>>>
>>>
>>>
>>> My faces-config.xml has following bean defined.
>>>
>>>
>>> Menu Model Managed Bean
>>>
>>> root_menu
>>>
>>> org.apache.myfaces.trinidad.model.XMLMenuModel
>>> request
>>>
>>> createHiddenNodes
>>> true
>>>
>>>
>>> source
>>> /WEB-INF/root_menu.xml
>>>
>>>
>>>
>>>
>>> My jsf code is as below.
>>>
>>> >> hint="tabs" id="navigationPane1">
>>>
>>> >>
>>> action="#{menuInfo.doAction}"
>>> icon="#{menuInfo.icon}"
>>>
>>> destination="#{menuInfo.destination}"
>>>
>>> rendered="#{menuInfo.rendered}"
>>> selected="true"
>>> id="pt_cni2"/>
>>>
>>>
>>>
>>> >> level="1"
>>> hint="bar" id="pt_np3">
>>>
>>> >>
>>> action="#{menuInfo.doAction}"
>>> icon="#{menuInfo.icon}"
>>>
>>> destination="#{menuInfo.destination}"
>>>
>>> rendered="#{menuInfo.rendered}"
>>> selected="true"
>>> id="pt_cni3"/>
>>>
>>>
>>>
>>>
>>> I am getting tabs as below
>>>
>>> department employees employess_dnd
>>> department | employees | employees_dnd
>>>
>>>
>>> I wanted it in this way
>>> department employees employess_dnd
>>> innerTb1 | innerTb2.
>>>
>>> Thanks for your help.
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/xmlmenumodel-not-displaying-sub-menus-with-trinidad-jsf-tp25757024p25757024.html
>>> Sent from the My Faces - Dev mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/xmlmenumodel-not-displaying-sub-menus-with-trinidad-jsf-tp25757024p25799077.html
> Sent from the My Faces - Dev mailing list archive at Nabble.com.
>
>
unsubscribe
From: Radek Hodain (JIRA) [mailto:d...@myfaces.apache.org] Sent: Thu 08/10/2009 10:39 To: dev@myfaces.apache.org Subject: [jira] Created: (TRINIDAD-1589) Light Weight Dialog adjustment to standard window behaviour Light Weight Dialog adjustment to standard window behaviour --- Key: TRINIDAD-1589 URL: https://issues.apache.org/jira/browse/TRINIDAD-1589 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Radek Hodain Priority: Trivial Attachments: patch.txt Add Minimize and the Restore-down buttons into light weight dialog to better adjustment to standard window behavior. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1589) Light Weight Dialog adjustment to standard window behaviour
Light Weight Dialog adjustment to standard window behaviour --- Key: TRINIDAD-1589 URL: https://issues.apache.org/jira/browse/TRINIDAD-1589 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Radek Hodain Priority: Trivial Attachments: patch.txt Add Minimize and the Restore-down buttons into light weight dialog to better adjustment to standard window behavior. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] JSF 2.0
Hello Andy, I created the "experimental" branch on this location: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x Greetings, Matthias On Thu, Oct 8, 2009 at 2:37 AM, Andy Schwartz wrote: > Gang - > > I am interested in taking a closer look at Trinidad/JSF 2.0 > integration. I suspect that there are other folks who are interested > in this as well. Would it be possible to create a Trinidad branch for > JSF 2.0-related work? For the moment, I think that an > experimental/sandbox-type branch that we could use for prototyping > purposes would be helpful/would facilitate collaboration on this > effort. > > Thoughts? > > Andy > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad] JSF 2.0
Good! Looking forward that :) Cheers, Bruno 2009/10/8 Matthias Wessendorf > Sure! Let me create such à branch. you create jira tickets for all the > issues. > > -Matthias > > Sent from my iPod. > > > On 08.10.2009, at 02:37, Andy Schwartz wrote: > > Gang - >> >> I am interested in taking a closer look at Trinidad/JSF 2.0 >> integration. I suspect that there are other folks who are interested >> in this as well. Would it be possible to create a Trinidad branch for >> JSF 2.0-related work? For the moment, I think that an >> experimental/sandbox-type branch that we could use for prototyping >> purposes would be helpful/would facilitate collaboration on this >> effort. >> >> Thoughts? >> >> Andy >> >
[jira] Created: (TRINIDAD-1588) NullPointerException using labelAndAccessKey Attribute in XMLMenuModel itemNode Definition
NullPointerException using labelAndAccessKey Attribute in XMLMenuModel itemNode
Definition
--
Key: TRINIDAD-1588
URL: https://issues.apache.org/jira/browse/TRINIDAD-1588
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.12-core
Reporter: Markus Dreher
With Trinidad 1.2.12 i've got the an Exception using the following definition,
which worked very well in Version before 1.2.12:
The labelAndAccessKey Value uses no AccessKey Notation (&), which results in
the following NullpointerException:
java.lang.NullPointerException
at
org.apache.myfaces.trinidadinternal.menu.ImmutableItemNode._joinLabelAndAccessKey(ImmutableItemNode.java:569)
at
org.apache.myfaces.trinidadinternal.menu.ImmutableItemNode.getLabelAndAccessKey(ImmutableItemNode.java:522)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:62)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
at
com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:72)
at org.apache.el.parser.AstValue.getValue(AstValue.java:97)
at
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at
com.sun.facelets.el.TagValueExpression.getValue(TagValueExpression.java:71)
There should be a check for a null accessKey like in ImmutableGroupNode and
MenuNode since this is a legal condition.
add before line 522:
if(accessKey == null) {
return label;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
