Re: [VOTE] release for myfaces core 2.0.5
+1 Am 05.04.11 08:02, schrieb Leonardo Uribe: Hi, I was running the needed tasks to get the 2.0.5 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.6 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.5 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.5 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-044/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces205binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316346 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316346
Re: [VOTE] release for myfaces core 2.0.5
+1 regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/4/6 Werner Punz werner.p...@gmail.com +1 Am 05.04.11 08:02, schrieb Leonardo Uribe: Hi, I was running the needed tasks to get the 2.0.5 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.6 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.5 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.5 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-044/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces205binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316346 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316346
NullPointerException when calling returnFromDialog
Hi, I have a window that opens another window which then opens another window (Window 3). When I'm trying to call returnFromDialog from Window 3, it sometimes throws a NullPointerException on this line: java.lang.NullPointerException at org.apache.myfaces.trinidadinternal.context.PageFlowScopeMap.discard(PageFlowScopeMap.java:341) at org.apache.myfaces.trinidadinternal.context.PageFlowScopeProviderImpl.popPageFlowScope(PageFlowScopeProviderImpl.java:106) at org.apache.myfaces.trinidadinternal.context.RequestContextImpl.returnFromDialog(RequestContextImpl.java:125) The NullPointerException is being thrown on this line: _sharedData._parent._sharedData._children.removeOldEntry(childToken, storeMap); because the children attribute is null. I tried to debug the code and whenever I have my breakpoint on this line, I am able to replicate this exception. What I have found so far is that the returnFromDialog creates a new request to close the window. This new request is setting the children attribute to null in the getToken() method. Whenever the children attribute is nulled before the removeOldEntry is called from the discard() method, I get the NullPointerException. Is this a JSF bug or is there something I'm doing wrong with the dialogs? I am currently using Trinidad 1.2.7. Regards, Jhoanna The information in this e-mail is intended for the named recipient only. It may contain privileged and/or confidential information. If you are not the intended recipient, you must not disclose, copy, distribute, take any action or reliance on it. If you have received this e-mail in error, please notify the sender immediately and delete this e-mail. Warning: E-mail transmission cannot be guaranteed to be secure or error-free. The recipient should check this email and any attachments for the presence of viruses. The sender does not accept liability for any errors or omissions in the contents of this message.
Re: [VOTE] release for myfaces core 2.0.5
hi mark, yes - you are right! (since i had to release codi, i directly opened the link from nexus - so i didn't see the wrong link.) thx regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/4/6 Mark Struberg strub...@yahoo.de hmm, guess there was a copy error from the old 2.0.4 vote. The correct staging repo URL looks like the following: https://repository.apache.org/content/repositories/orgapachemyfaces-066 For testing it please add the following into your ~/.m2/settings.xml: profiles profile idstaging/id repositories repository idnexus staging/id url http://repository.apache.org/content/repositories/orgapachemyfaces-066/ /url releases enabledtrue/enabled /releases snapshots enabledfalse/enabled /snapshots /repository /repositories /profile /profiles then upgrade your pom to use myfaces-2.0.5 and run with $ mvn clean install -Pstaging Will report feedback in ~1h after running the full test suite in my fat real world app. LieGrue, strub --- On Tue, 4/5/11, Leonardo Uribe lu4...@gmail.com wrote: From: Leonardo Uribe lu4...@gmail.com Subject: [VOTE] release for myfaces core 2.0.5 To: MyFaces Development dev@myfaces.apache.org Date: Tuesday, April 5, 2011, 6:02 AM Hi, I was running the needed tasks to get the 2.0.5 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.6 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.5 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.5 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-044/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces205binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316346
Re: [VOTE] release for myfaces core 2.0.5
important update, the repo url should always be https:// and not http ! otherwise you'll get a redirect from the server (which wagon-lightweight-httpd cannot handle correctly ...) LieGrue, strub --- On Wed, 4/6/11, Mark Struberg strub...@yahoo.de wrote: From: Mark Struberg strub...@yahoo.de Subject: Re: [VOTE] release for myfaces core 2.0.5 To: MyFaces Development dev@myfaces.apache.org Date: Wednesday, April 6, 2011, 9:30 AM hmm, guess there was a copy error from the old 2.0.4 vote. The correct staging repo URL looks like the following: https://repository.apache.org/content/repositories/orgapachemyfaces-066 For testing it please add the following into your ~/.m2/settings.xml: profiles profile idstaging/id repositories repository idnexus staging/id urlhttp://repository.apache.org/content/repositories/orgapachemyfaces-066//url releases enabledtrue/enabled /releases snapshots enabledfalse/enabled /snapshots /repository /repositories /profile /profiles then upgrade your pom to use myfaces-2.0.5 and run with $ mvn clean install -Pstaging Will report feedback in ~1h after running the full test suite in my fat real world app. LieGrue, strub --- On Tue, 4/5/11, Leonardo Uribe lu4...@gmail.com wrote: From: Leonardo Uribe lu4...@gmail.com Subject: [VOTE] release for myfaces core 2.0.5 To: MyFaces Development dev@myfaces.apache.org Date: Tuesday, April 5, 2011, 6:02 AM Hi, I was running the needed tasks to get the 2.0.5 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.6 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.5 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.5 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-044/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces205binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316346
[jira] [Updated] (MYFACES-3080) 'begin' event does not have 'status' property set
[ https://issues.apache.org/jira/browse/MYFACES-3080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rene O updated MYFACES-3080: Status: Patch Available (was: Open) 'begin' event does not have 'status' property set - Key: MYFACES-3080 URL: https://issues.apache.org/jira/browse/MYFACES-3080 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.5-SNAPSHOT Reporter: Nick Belaevski With the current 2.0.5-SNAPSHOT 'begin' event does not have 'status' property set. This is due to missing argument in _Impl.sendEvent() call: _Impl.sendEvent(this._xhr, _Impl.BEGIN); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3080) 'begin' event does not have 'status' property set
[ https://issues.apache.org/jira/browse/MYFACES-3080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13016362#comment-13016362 ] Rene O commented on MYFACES-3080: - To solve this problem change in file META-INF\resources\javax.faces\jsf.js B.sendEvent(this._xhr, B.BEGIN); to: B.sendEvent(this._xhr, this._context, B.BEGIN); 'begin' event does not have 'status' property set - Key: MYFACES-3080 URL: https://issues.apache.org/jira/browse/MYFACES-3080 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.5-SNAPSHOT Reporter: Nick Belaevski With the current 2.0.5-SNAPSHOT 'begin' event does not have 'status' property set. This is due to missing argument in _Impl.sendEvent() call: _Impl.sendEvent(this._xhr, _Impl.BEGIN); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (EXTCDI-162) re-visit implementation of custom project stages.
[
https://issues.apache.org/jira/browse/EXTCDI-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13012158#comment-13012158
]
Gerhard Petracek edited comment on EXTCDI-162 at 4/6/11 1:04 PM:
-
imo users don't directly think - i create a custom project-stage - ah right
everything is a bean and codi has a producer for the project stage - i've to
use @Typed - ask 100 users - and maybe 1 will think that way. the problem is
- as soon as you create a custom implementation and you forget it - you get the
exception (just because we have an internal producer which already uses the
default qualifier).
@a: it is - because it's easier for users and you need @Typed() in all cases -
you never have the choice to do something different
@b: we already have an observer in an extension - the overhead would be only
one method call (and not a whole extension)
@c: no - because they can use @Typed() if they are aware of it (without
breaking something)
@Veto or @NoBean or maybe even better @Ignored would be find for me as well -
esp. @Ignored would be more expressive than @Typed()
imo @Ignored would be a nice feature anyway. we already had this topic in an
irc discussion
was (Author: gpetracek):
imo users don't directly think - i create a custom project-stage - ah right
everything is a bean and codi has a producer for the project stage - i've to
use @Typed - ask 100 users - and maybe 1 will think that way. the problem is
- as soon as you create a custom implementation and you forget it - you get the
exception (just because we have an internal producer which already uses the
default qualifier).
@a: it is - because it's easier for users and you need @Typed() in all cases -
you never have the choice to do something different
@b: we already have an observer in an extension - the overhead would be only
one method call (and not a whole extension)
@c: no - because they can use @Typed() if they are aware of it (without
breaking something)
@Veto or @NoBean would be find for me as well - esp. @NoBean would be more
expressive than @Typed()
imo @NoBean would be a nice feature anyway. we already had this topic in an irc
discussion
re-visit implementation of custom project stages.
-
Key: EXTCDI-162
URL: https://issues.apache.org/jira/browse/EXTCDI-162
Project: MyFaces CODI
Issue Type: Task
Components: Core
Affects Versions: 0.9.4
Reporter: Gerhard Petracek
if users forget @Typed(), they would see an AmbiguousResolutionException.
cdi-qualifiers aren't supported (in case of project-stages). so @Typed() is
required all the time.
currently valid example:
public class CustomProjectStage implements ProjectStageHolder
{
@Typed()
public static final class Debugging extends ProjectStage
{
private static final long serialVersionUID = -8626602281649294170L;
}
public static final Debugging Debugging = new Debugging();
}
since there is no support for cdi-qualifiers, we could veto those classes.
that would allow to skip the @Typed() but the rest would be the same (because
codi will still find them).
pro: users don't have to use @Typed() explicitly (and they won't see the
AmbiguousResolutionException, if they forget using @Typed())
con: it isn't std. cdi - but adding @Typed() even though it isn't needed
wouldn't harm.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACESTEST-47) Improve module for automated webapp tests for MyFaces core + extensions (aka webapptest)
[ https://issues.apache.org/jira/browse/MYFACESTEST-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] abhishek srivastava updated MYFACESTEST-47: --- Status: Patch Available (was: Open) Improve module for automated webapp tests for MyFaces core + extensions (aka webapptest) Key: MYFACESTEST-47 URL: https://issues.apache.org/jira/browse/MYFACESTEST-47 Project: MyFaces Test Issue Type: Improvement Components: webapptest Reporter: Jakob Korherr Assignee: Jakob Korherr Labels: gsoc2011 Last year we had a student working during GSoC on an module for automated webapp tests for MyFaces core + extensions. The outcome of this project was webapptest. webapptest uses Arquillian and HtmlUnit to run JSF (integration-)tests against a real servlet container with a real browser, allowing to do assertions on client and on server-side. The current version of webapptest is pretty much the outcome of last year's GSoC, however, with some bugfixes and some improved features (see MYFACESTEST component webapptest). Some features could not be implemented last year, because they were technically impossible. Although it already works pretty well, there is still a lot of work to do: - The initial goal of webapptest was also to be able to run one test against multiple containers with different configurations (e.g. tomat 6.0.31 + MyFaces 2.0.3, tomcat 6.0.31 + MyFaces 2.0.4, tomcat 7.0.1 + MyFaces 2.0.4, tomcat x.x.x + Mojarra 2.0.x, Glassfish 3.1 + Mojarra 2.0.x, etc ...), allowing MyFaces extensions to automatically test and prove their interoperability! This task is not a very easy one, because it requires a lot of ClassLoader related work. - The API + assertion possibilities need to be improved - Better error messages + tracing - the implementation must be more stable (along different containers) - type-safe dependency configuration (including automatically resolving transitive dependencies) ... Thus, I think it would be very great to have a student working on this stuff again in this year's GSoC. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] release for myfaces core 2.0.5
FYI ... I will verify that there there are no bridge issues with this version today and cast my vote. -Mike- On 4/6/2011 1:02 AM, Werner Punz wrote: +1 Am 05.04.11 08:02, schrieb Leonardo Uribe: Hi, I was running the needed tasks to get the 2.0.5 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.6 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.5 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.5 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-044/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces205binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316346 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316346
[jira] [Updated] (MYFACESTEST-47) Improve module for automated webapp tests for MyFaces core + extensions (aka webapptest)
[ https://issues.apache.org/jira/browse/MYFACESTEST-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACESTEST-47: - Status: Open (was: Patch Available) Improve module for automated webapp tests for MyFaces core + extensions (aka webapptest) Key: MYFACESTEST-47 URL: https://issues.apache.org/jira/browse/MYFACESTEST-47 Project: MyFaces Test Issue Type: Improvement Components: webapptest Reporter: Jakob Korherr Assignee: Jakob Korherr Labels: gsoc2011 Last year we had a student working during GSoC on an module for automated webapp tests for MyFaces core + extensions. The outcome of this project was webapptest. webapptest uses Arquillian and HtmlUnit to run JSF (integration-)tests against a real servlet container with a real browser, allowing to do assertions on client and on server-side. The current version of webapptest is pretty much the outcome of last year's GSoC, however, with some bugfixes and some improved features (see MYFACESTEST component webapptest). Some features could not be implemented last year, because they were technically impossible. Although it already works pretty well, there is still a lot of work to do: - The initial goal of webapptest was also to be able to run one test against multiple containers with different configurations (e.g. tomat 6.0.31 + MyFaces 2.0.3, tomcat 6.0.31 + MyFaces 2.0.4, tomcat 7.0.1 + MyFaces 2.0.4, tomcat x.x.x + Mojarra 2.0.x, Glassfish 3.1 + Mojarra 2.0.x, etc ...), allowing MyFaces extensions to automatically test and prove their interoperability! This task is not a very easy one, because it requires a lot of ClassLoader related work. - The API + assertion possibilities need to be improved - Better error messages + tracing - the implementation must be more stable (along different containers) - type-safe dependency configuration (including automatically resolving transitive dependencies) ... Thus, I think it would be very great to have a student working on this stuff again in this year's GSoC. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-206) Proposal for 3.0 API: New constant Bridge.BRIDGE_CONTEXT_ATTRIBUTE
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13016452#comment-13016452 ] Michael Freedman commented on PORTLETBRIDGE-206: For the time being this can't/won't go in Bridge.java. Rather it will be part of the org.apache.myfaces.portlet.faces.bridge package. Probably in Constants.java. Proposal for 3.0 API: New constant Bridge.BRIDGE_CONTEXT_ATTRIBUTE -- Key: PORTLETBRIDGE-206 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-206 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman Proposal is to add the following constant to Bridge.java: public static final String BRIDGE_CONTEXT_ATTRIBUTE = javax.portlet.faces.bridgeContext; And to require implementations of the Bridge interface to set this attribute in each of the doFacesRequest(...) methods. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-203) Proposal for 3.0 IMPL: Preserve and restore JSF2 FacesContext attributes in BridgeRequestScope
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13016463#comment-13016463 ] Michael Freedman commented on PORTLETBRIDGE-203: I have found that the 329/301 bridge methodology of caching the UIViewRoot and releasing the FacesContext at the end of the action and then getting the render to use the cached UIViewRoot in a new FacesContext will not work consistently in JSF 3.0. Each release of Mojarra or Myfaces I get changes the issue I ran into -- yes first it was just the need to carry some of the FacesContext attributes forward -- but now there are issues with attributes stored on the UiViewRoot itself that have been released underneath these references in the prior facesContext.release. So I think the bridge is going to have to change to explicitly save and restore the view across the action/render -- at which point we won't need to preserve/restore the JSF2 FacesContext attrs anymore. Proposal for 3.0 IMPL: Preserve and restore JSF2 FacesContext attributes in BridgeRequestScope -- Key: PORTLETBRIDGE-203 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-203 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman The JSF 2.0 API introduced a getAttributes() method on FacesContext: http://javaserverfaces.java.net/nonav/docs/2.0/javadocs/javax/faces/context/FacesContext.html#getAttributes() These values need to be preserved in the BridgeRequestScope. For more information on implementation details, search for BRIDGE_REQ_SCOPE_ATTR_FACES_CONTEXT_ATTRIBUTES in the following Java class: http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-impl/trunk/src/main/java/org/portletfaces/bridge/scope/BridgeRequestScopeImpl.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] release for myfaces core 2.0.5
+1 On Wed, Apr 6, 2011 at 6:28 AM, Mark Struberg strub...@yahoo.de wrote: +1 myfaces-2.0.5 works well so far, source release tar.gz also looks fine. LieGrue, strub --- On Wed, 4/6/11, Mark Struberg strub...@yahoo.de wrote: From: Mark Struberg strub...@yahoo.de Subject: Re: [VOTE] release for myfaces core 2.0.5 To: MyFaces Development dev@myfaces.apache.org Date: Wednesday, April 6, 2011, 10:57 AM important update, the repo url should always be https:// and not http ! otherwise you'll get a redirect from the server (which wagon-lightweight-httpd cannot handle correctly ...) LieGrue, strub --- On Wed, 4/6/11, Mark Struberg strub...@yahoo.de wrote: From: Mark Struberg strub...@yahoo.de Subject: Re: [VOTE] release for myfaces core 2.0.5 To: MyFaces Development dev@myfaces.apache.org Date: Wednesday, April 6, 2011, 9:30 AM hmm, guess there was a copy error from the old 2.0.4 vote. The correct staging repo URL looks like the following: https://repository.apache.org/content/repositories/orgapachemyfaces-066 For testing it please add the following into your ~/.m2/settings.xml: profiles profile idstaging/id repositories repository idnexus staging/id urlhttp://repository.apache.org/content/repositories/orgapachemyfaces-066//url releases enabledtrue/enabled /releases snapshots enabledfalse/enabled /snapshots /repository /repositories /profile /profiles then upgrade your pom to use myfaces-2.0.5 and run with $ mvn clean install -Pstaging Will report feedback in ~1h after running the full test suite in my fat real world app. LieGrue, strub --- On Tue, 4/5/11, Leonardo Uribe lu4...@gmail.com wrote: From: Leonardo Uribe lu4...@gmail.com Subject: [VOTE] release for myfaces core 2.0.5 To: MyFaces Development dev@myfaces.apache.org Date: Tuesday, April 5, 2011, 6:02 AM Hi, I was running the needed tasks to get the 2.0.5 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.6 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.5 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.5 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-044/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces205binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316346 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] [Commented] (TRINIDAD-2071) Connection Failed
[
https://issues.apache.org/jira/browse/TRINIDAD-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13016476#comment-13016476
]
Jonathan Gentry commented on TRINIDAD-2071:
---
The real question is why line 592 is not coming back as
TrXMLRequest.COMPLETED.
Connection Failed
-
Key: TRINIDAD-2071
URL: https://issues.apache.org/jira/browse/TRINIDAD-2071
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.0.5-core
Environment: We are running on a Unix server using Oracle 10g as an
application server in a clustered environment
Reporter: ACTUR
We are experiencing a connection failure issue the message appears to be
coming from trinidad-impl-1.0.5.jar -
\META-INF\adf\jsLibs\xhr\RequestQueue.js stating a connection failure. This
usually happens when a user selects a component that is doing a partial page
refresh. The application hangs for about 20 seconds and then returns the
connection fail message. We only found one similar issue out there and with a
work around to comment out the message in the RequestQueue.js however this
does not completely fix the problem we still experience the delay without the
message. Is there a fix for this. Below is the solution we have found on a
blog:
TrRequestQueue._alertError = function()
{
var failedConnectionText = TrRequestQueue._getFailedConnectionText();
if (failedConnectionText != null)
alert(Trapped Connection Failed !!! );
}
TrRequestQueue._getFailedConnectionText() : This method returns 'Connection
Failed' This message is given whenever any issue occures with IFrames that
are used internally in trinidad. But it has no major impact on app, so can
be taken as warning. SO the solution is to just override this method
comment out the code as below.
TrRequestQueue._alertError = function()
{
// Do nothing. Supressing alert code.
// var failedConnectionText = TrRequestQueue._getFailedConnectionText();
//if (failedConnectionText != null)
// alert(Trapped Connection Failed !!! );
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3101) NavigationHandlerImpl throws NullpointerException if view is expired
[ https://issues.apache.org/jira/browse/MYFACES-3101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Kočí updated MYFACES-3101: - Status: Patch Available (was: Open) NavigationHandlerImpl throws NullpointerException if view is expired Key: MYFACES-3101 URL: https://issues.apache.org/jira/browse/MYFACES-3101 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.0.4 Reporter: Martin Stockhammer I tried to use the NavigationHandler inside a Faces exception handler to deal with ViewExpiredException as mentioned here: http://www.nfjsone.com/blog/ed_burns/2009/09/dealing_gracefully_with_viewexpiredexception_in_jsf2. The example does not work with myfaces, because org.apache.myfaces.application.NavigationHandlerImpl throws a NullpointerException while handleNavigation() is called. The exception occurs in line 160: String viewId = facesContext.getViewRoot().getViewId(); I think the cause is that the viewroot is not set anymore when the ViewExpiredException is thrown. The official API for NavigationHandler.handleNavigation tells, that the NullpointerException is thrown only if the given facescontext is null. NullPointerException - if context is null -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-166) Handle situation for viewRoot = null
Handle situation for viewRoot = null Key: EXTCDI-166 URL: https://issues.apache.org/jira/browse/EXTCDI-166 Project: MyFaces CODI Issue Type: Bug Components: JEE-JSF20-Module Affects Versions: 0.9.5 Environment: myfaces trunk, codi trunk Reporter: Martin Kočí With example from http://www.nfjsone.com/blog/ed_burns/2009/09/dealing_gracefully_with_viewexpiredexception_in_jsf2 and a coding typo like: nav.handleNavigation(fc, null, /nonExistentView.xhtml); you get facesContext.viewRoot = null even in render_response phase codi throw NPEs in such case, see attached patch for details. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2082) hidden labels don't always render in screen reader mode
hidden labels don't always render in screen reader mode --- Key: TRINIDAD-2082 URL: https://issues.apache.org/jira/browse/TRINIDAD-2082 Project: MyFaces Trinidad Issue Type: Bug Components: Components Reporter: Dave Robinson When in screen reader mode, we always expect hidden labels to be rendered, as these hidden labels often contain information (like labels for input fields) necessary for 508 and WCAG 2.0 compliance. The HiddenLabelUtils has a method supportsHiddenLabels() that returns false if the current agent does not support hidden (off page) labels on the page. When in screen reader mode, this method should always return true, as we always want labels to be present in screen reader mode - regardless if they correctly appear hidden or not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2082) hidden labels don't always render in screen reader mode
[ https://issues.apache.org/jira/browse/TRINIDAD-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Robinson updated TRINIDAD-2082: Status: Patch Available (was: Open) hidden labels don't always render in screen reader mode --- Key: TRINIDAD-2082 URL: https://issues.apache.org/jira/browse/TRINIDAD-2082 Project: MyFaces Trinidad Issue Type: Bug Components: Components Reporter: Dave Robinson When in screen reader mode, we always expect hidden labels to be rendered, as these hidden labels often contain information (like labels for input fields) necessary for 508 and WCAG 2.0 compliance. The HiddenLabelUtils has a method supportsHiddenLabels() that returns false if the current agent does not support hidden (off page) labels on the page. When in screen reader mode, this method should always return true, as we always want labels to be present in screen reader mode - regardless if they correctly appear hidden or not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Undocumented (inadvertent?) change in API with 1.2.9 - 1.2.10
According to the documentation[1], ApplicationImpl should have a method called addConverterConfiguration(), however this was removed in 1.2.10. This can be verified by looking at the source in 1.2.9[2] as compared to 1.2.10[3]. Was this done intentionally? If so, why? Is there a drop in replacement for this method? Can someone update the documentation to reflect that this function no longer exists? If it was unintentional, what is the ETA for the official release of a corrected version? [1] http://myfaces.apache.org/core12/myfaces-impl/apidocs/org/apache/myfaces/application/ApplicationImpl.html [2] http://archive.apache.org/dist/myfaces/source/myfaces-core-1.2.9-src.zip [3] http://www.apache.org/dyn/closer.cgi/myfaces/source/myfaces-core-assembly-1.2.10-src.zip Thanks, Adam - FHA 203b; 203k; HECM; VA; USDA; Conventional - Warehouse Lines; FHA-Authorized Originators - Lending and Servicing in over 45 States www.swmc.com - www.simplehecmcalculator.com Visit www.swmc.com/resources for helpful links on Training, Webinars, Lender Alerts and Submitting Conditions This email and any content within or attached hereto from Sun West Mortgage Company, Inc. is confidential and/or legally privileged. The information is intended only for the use of the individual or entity named on this email. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this email information is strictly prohibited, and that the documents should be returned to this office immediately by email. Receipt by anyone other than the intended recipient is not a waiver of any privilege. Please do not include your social security number, account number, or any other personal or financial information in the content of the email. Should you have any questions, please call (800) 453 7884.
Re: [site] Branding requirements
hi @ all, please answer to this mail, if you have some news about this topic. (we have to include it in the board report.) regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/10/29 Matthias Wessendorf mat...@apache.org E.g. -CWiki link missing -check trademark -Foundation: License and Security are missing -Trademark Attributions = to be done... -Logos And Graphics = To be changed... -Powered By... Logos = Do we have those ? -Matthias On Fri, Oct 29, 2010 at 1:24 PM, Matthias Wessendorf mat...@apache.org wrote: All Apache projects have been asked to abide by these foundation-wide guidelines [1]. Having a quick look down the list of things that are expected, it seems we have a few site patches to make. [1] http://www.apache.org/foundation/marks/pmcs -- 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] [Issue Comment Edited] (TRINIDAD-2082) hidden labels don't always render in screen reader mode
[ https://issues.apache.org/jira/browse/TRINIDAD-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13016567#comment-13016567 ] Dave Robinson edited comment on TRINIDAD-2082 at 4/6/11 9:56 PM: - Use the JIRA-TRINIDAD-2082v2.patch instead of the first one submitted. With further testing I saw that the webkit xml agent file did not list webkit as having the capability of supporting HTML fieldsets, so fixed that too. You can see that the Safari agent goldens are now getting the fieldsets when before they were not. was (Author: daverobinson): Use this one. With further testing I saw that the webkit xml agent file did not list webkit as having the capability of supporting HTML fieldsets, so fixed that too. You can see that the Safari agent goldens are now getting the fieldsets when before they were not. hidden labels don't always render in screen reader mode --- Key: TRINIDAD-2082 URL: https://issues.apache.org/jira/browse/TRINIDAD-2082 Project: MyFaces Trinidad Issue Type: Bug Components: Components Reporter: Dave Robinson Attachments: JIRA-TRINIDAD-2082.patch, JIRA-TRINIDAD-2082v2.patch When in screen reader mode, we always expect hidden labels to be rendered, as these hidden labels often contain information (like labels for input fields) necessary for 508 and WCAG 2.0 compliance. The HiddenLabelUtils has a method supportsHiddenLabels() that returns false if the current agent does not support hidden (off page) labels on the page. When in screen reader mode, this method should always return true, as we always want labels to be present in screen reader mode - regardless if they correctly appear hidden or not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] release for myfaces core 2.0.5
+1 The bridge is running with this version. -Mike- On 4/6/2011 9:59 AM, Michael Freedman wrote: FYI ... I will verify that there there are no bridge issues with this version today and cast my vote. -Mike- On 4/6/2011 1:02 AM, Werner Punz wrote: +1 Am 05.04.11 08:02, schrieb Leonardo Uribe: Hi, I was running the needed tasks to get the 2.0.5 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.6 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.5 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.5 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-044/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces205binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316346 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316346
[jira] [Updated] (TRINIDAD-2082) hidden labels don't always render in screen reader mode
[ https://issues.apache.org/jira/browse/TRINIDAD-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Cooper updated TRINIDAD-2082: -- Resolution: Fixed Fix Version/s: 2.0.0-beta-3 Status: Resolved (was: Patch Available) hidden labels don't always render in screen reader mode --- Key: TRINIDAD-2082 URL: https://issues.apache.org/jira/browse/TRINIDAD-2082 Project: MyFaces Trinidad Issue Type: Bug Components: Components Reporter: Dave Robinson Assignee: Matt Cooper Fix For: 2.0.0-beta-3 Attachments: JIRA-TRINIDAD-2082.patch, JIRA-TRINIDAD-2082v2.patch When in screen reader mode, we always expect hidden labels to be rendered, as these hidden labels often contain information (like labels for input fields) necessary for 508 and WCAG 2.0 compliance. The HiddenLabelUtils has a method supportsHiddenLabels() that returns false if the current agent does not support hidden (off page) labels on the page. When in screen reader mode, this method should always return true, as we always want labels to be present in screen reader mode - regardless if they correctly appear hidden or not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[RESULTS] Apache MyFaces Portlet Bridge 3.0.0-alpha
The vote for the release of Portlet Bridge 3.0.0-alpha was approved +1: Mike Freedman, Scott O'Bryan, Leonardo Uribe, Bernd Bohmann, Mark Struberg +0: none -1: none Thanks to everyone who voted. Michael Freedman [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg52226.html
[jira] [Created] (TRINIDAD-2083) Trinidad doesn't work with the 3.0.0 Portlet Bridge
Trinidad doesn't work with the 3.0.0 Portlet Bridge --- Key: TRINIDAD-2083 URL: https://issues.apache.org/jira/browse/TRINIDAD-2083 Project: MyFaces Trinidad Issue Type: Bug Components: Portlet Affects Versions: 2.0.0-beta-2 Reporter: Michael Freedman I got 2.0.0-alpha2 working with a patch but once I upgraded to 2.0.0-beta-2 (which fixed the problem I needed to patch) the bridge completely breaks as long as the app includes the trinidad libs. There seems to be some incompatibilities between the Trinidad extensions and the bridge's. Did get a chance to track down the specific details but wanted to get the issue logged as its likely to be identified much faster by someone in the Trinidad team. To reproduce -- get the bridge-3.0.0-alpha and set up a project pointing to the 3.0.0 TCK. Follow the instructions in the TCK User Manual for building it, configuring it on Apache, and then running it. With the Trinidad jars in the deployment you will find that almost all the test fail (170) -- the few that pass don't actually execute Faces. If you remove the jars (and I think drop the other Trinidad refs in the web.xml) things run fine except for those few tests that depend on Trindiad (failed tests shoudl be something like 37). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-2080) NullPointerException from skinning framework code (SkinUtils)
[
https://issues.apache.org/jira/browse/TRINIDAD-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeanne Waldman updated TRINIDAD-2080:
-
Resolution: Fixed
Fix Version/s: 2.0.0-beta-3
Status: Resolved (was: Patch Available)
NullPointerException from skinning framework code (SkinUtils)
-
Key: TRINIDAD-2080
URL: https://issues.apache.org/jira/browse/TRINIDAD-2080
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Affects Versions: 2.0.0-beta-2
Environment: n/a
Reporter: Prakash Udupa
Assignee: Jeanne Waldman
Fix For: 2.0.0-beta-3
Attachments: npe_JIRA-2080.patch
Original Estimate: 1h
Remaining Estimate: 1h
In our application, where we use Trinidad, we hit on the following
exception...
Mar 10, 2011 1:25:33 PM org.apache.myfaces.trinidad.webapp.TrinidadFilter
SEVERE:
java.lang.NullPointerException
at org.apache.myfaces.trinidadinternal.skin.SkinUtils._registerSkinExtensionsA
ndAdditions(SkinUtils.java:379)
at org.apache.myfaces.trinidadinternal.skin.SkinUtils.registerSkinExtensions(S
kinUtils.java:129)
at org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.init(Glob
alConfiguratorImpl.java:406)
at oracle.adfinternal.view.faces.webapp.rich.RegistrationFilter.init(Registrat
ionFilter.java:53)
at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.init(Trinidad
FilterImpl.java:110)
at org.apache.myfaces.trinidad.webapp.TrinidadFilter.init(TrinidadFilter.java:
54)
The culprit code is here...
private static void _registerSkinExtensionsAndAdditions(
ExternalContext context,
SkinFactory skinFactory)
{
if (context == null)
return;
// Add META-INF/trinidad-skins.xml skins to skin factory. (sorted first
to make sure
// we register the most 'base' skins first)
if (_LOG.isFine()) _LOG.fine(Parse META-INF/trinidad-skins.xml files);
ListSkinsNode metaInfSkinsNodeList = _getMetaInfSkinsNodeList();
// Go through each SkinsNode object
// (contains List of SkinNodes and List of SkinAdditionNodes)
// and return a List of the SkinNodes.
ListSkinNode metaInfSkinNodes = new ArrayListSkinNode();
for (SkinsNode skinsNode : metaInfSkinsNodeList)
{
metaInfSkinNodes.addAll(skinsNode.getSkinNodes());
}
addAll (from its doc) assumes that supplied collection is non-null. The
supplier does not guarantee this, so we will need some defensive code here to
avoid the NPE.
Will provide a patch.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TRINIDAD-1496) Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value instead of just getImageURI
[ https://issues.apache.org/jira/browse/TRINIDAD-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeanne Waldman updated TRINIDAD-1496: - Status: Patch Available (was: Open) Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value instead of just getImageURI -- Key: TRINIDAD-1496 URL: https://issues.apache.org/jira/browse/TRINIDAD-1496 Project: MyFaces Trinidad Issue Type: New Feature Components: Components Affects Versions: 1.2.11-core Reporter: Matt Cooper Priority: Minor In skinning, you can define image icons in 4 different ways: 1.) Absolute URLs specify the complete URL to the resource, including the protocol (e.g. http://). Example: content: url(http://incubator.apache.org/images/asf_logo_wide.gif); 2.) Relative URLs are used if the specified URL does not start with a slash (/) and if there's no protocol present. A relative URL is based on the skin's CSS file location. For instance, if the CSS is located in MyWebApp/skins/mySkin/ and the specified url is skinImages/myImage.gif, then the final URL will be /MyWebApp/skins/mySkin/skinImages/myImage.gif. Example: content: url(skin_images/ObjectIconError.gif); 3.) Context relative URLs are resolved relatively to the context root of the web application. To use them, you simply have to make it start with a single slash (/). For instance, if the context root is /MyWebApp and the specified URL is /images/myImage.jpeg, the resulting URL will be /MyWebApp/images/myImage.jpeg. Example: content: url(/skins/mySkin/skin_images/ObjectIconError.gif); 4.) Server relative URLs are resolved relatively to the web server as opposed to the context root. This allow to easily refer to resources located on another application on the same server. To use this type of URL, the specified URL must starts with two slashes (//). Example: content: url(//MyOtherWebApp/images/myCalendar.gif); The org.apache.myfaces.trinidad.skin.Icon class currently provides a getImageURI() method. This method returns a value that has the context path built-in. If a component exposes an icon attribute (there are a handful in Apache MyFaces Trinidad and also in another framework that has components built upon Trinidad), that icon String supports these same alternative mechanisms for referring to the icon image. Let's say you have a component that you want to keep abstract but might want it to reuse existing components (e.g. a rich text editor with a toolbar containing buttons that you want to reuse an existing toolbar button component so you can have consistency in button styling). For that publicly-exposed component, you will want to allow people to customize in skinning what the icons are for its toolbar. These icons must be defined in that publicly-exposed component but then converted into a String that can be passed into the toolbar button component. With the current Icon.getImageURI(), if a user skinned the icon image using some of the 4 above paths, either the icon would have 2 context paths added to it (one from the skin framework and one from the toolbar button resource encoding) or it would have a context path when it should not be including the local context path (image definition option #4). For the public component's renderer to support all 4 of these image definition options, the org.apache.myfaces.trinidad.skin.Icon needs to expose some mechanism to either let it have access to the raw content value so that raw value can be passed along to the button or at least some kind of mechanism to let the public component's renderer know that it is not safe to let the button add its own copy of the context path (e.g. add another leading / to the result). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TRINIDAD-1496) Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value instead of just getImageURI
[ https://issues.apache.org/jira/browse/TRINIDAD-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13016643#comment-13016643 ] Jeanne Waldman commented on TRINIDAD-1496: -- This is not as simple as I first thought because the Icon object is built with pre-processed URIs ready to be output to the css or html. They do not have the raw uris, and the raw uris cannot be determined from the regular uris, since for css relative urls, we would need to know where the css file was. We parse each css files in SkinStyleSheetParserUtils. here we configure the url. Then in StyleSheetDocument, when we do all the property merging, we create the Icon objects. At this point the css file information is long gone. We do not even know all the skins that were merged together to form this one StyleSheetDocument. I've attached a patch for an idea for a fix. That is to pass in a dummy property into the IconNodes (raw-url), then in StyleSheetDocument we can read this, and use it to create the Icon. The Icon constructors will have to change. Also note, that we will have to check the code carefully for right-to-left icons. I did not in this patch. It's simply an idea. Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value instead of just getImageURI -- Key: TRINIDAD-1496 URL: https://issues.apache.org/jira/browse/TRINIDAD-1496 Project: MyFaces Trinidad Issue Type: New Feature Components: Components Affects Versions: 1.2.11-core Reporter: Matt Cooper Priority: Minor In skinning, you can define image icons in 4 different ways: 1.) Absolute URLs specify the complete URL to the resource, including the protocol (e.g. http://). Example: content: url(http://incubator.apache.org/images/asf_logo_wide.gif); 2.) Relative URLs are used if the specified URL does not start with a slash (/) and if there's no protocol present. A relative URL is based on the skin's CSS file location. For instance, if the CSS is located in MyWebApp/skins/mySkin/ and the specified url is skinImages/myImage.gif, then the final URL will be /MyWebApp/skins/mySkin/skinImages/myImage.gif. Example: content: url(skin_images/ObjectIconError.gif); 3.) Context relative URLs are resolved relatively to the context root of the web application. To use them, you simply have to make it start with a single slash (/). For instance, if the context root is /MyWebApp and the specified URL is /images/myImage.jpeg, the resulting URL will be /MyWebApp/images/myImage.jpeg. Example: content: url(/skins/mySkin/skin_images/ObjectIconError.gif); 4.) Server relative URLs are resolved relatively to the web server as opposed to the context root. This allow to easily refer to resources located on another application on the same server. To use this type of URL, the specified URL must starts with two slashes (//). Example: content: url(//MyOtherWebApp/images/myCalendar.gif); The org.apache.myfaces.trinidad.skin.Icon class currently provides a getImageURI() method. This method returns a value that has the context path built-in. If a component exposes an icon attribute (there are a handful in Apache MyFaces Trinidad and also in another framework that has components built upon Trinidad), that icon String supports these same alternative mechanisms for referring to the icon image. Let's say you have a component that you want to keep abstract but might want it to reuse existing components (e.g. a rich text editor with a toolbar containing buttons that you want to reuse an existing toolbar button component so you can have consistency in button styling). For that publicly-exposed component, you will want to allow people to customize in skinning what the icons are for its toolbar. These icons must be defined in that publicly-exposed component but then converted into a String that can be passed into the toolbar button component. With the current Icon.getImageURI(), if a user skinned the icon image using some of the 4 above paths, either the icon would have 2 context paths added to it (one from the skin framework and one from the toolbar button resource encoding) or it would have a context path when it should not be including the local context path (image definition option #4). For the public component's renderer to support all 4 of these image definition options, the org.apache.myfaces.trinidad.skin.Icon needs to expose some mechanism to either let it have access to the raw content value so that raw value can be passed along to the button or at least some kind of mechanism to let the public component's renderer know that it is not safe to let the button add its own copy of the context path (e.g. add another
Re: Undocumented (inadvertent?) change in API with 1.2.9 - 1.2.10
Hi Adam, This was changed to use RuntimeConfig instead, see https://issues.apache.org/jira/browse/MYFACES-2928 Please note that since ApplicationImpl is an internal MyFaces class, changes like this one may occur anytime. Regards, Jakob 2011/4/6 a...@swmc.com According to the documentation[1], ApplicationImpl should have a method called addConverterConfiguration(), however this was removed in 1.2.10. This can be verified by looking at the source in 1.2.9[2] as compared to 1.2.10[3]. Was this done intentionally? If so, why? Is there a drop in replacement for this method? Can someone update the documentation to reflect that this function no longer exists? If it was unintentional, what is the ETA for the official release of a corrected version? [1] http://myfaces.apache.org/core12/myfaces-impl/apidocs/org/apache/myfaces/application/ApplicationImpl.html [2] http://archive.apache.org/dist/myfaces/source/myfaces-core-1.2.9-src.zip [3] http://www.apache.org/dyn/closer.cgi/myfaces/source/myfaces-core-assembly-1.2.10-src.zip Thanks, Adam -- - FHA 203b; 203k; HECM; VA; USDA; Conventional - Warehouse Lines; FHA-Authorized Originators - Lending and Servicing in over 45 States www.swmc.com - www.simplehecmcalculator.comVisit www.swmc.com/resources http://www.swmc.com/resources.htm for helpful links on Training, Webinars, Lender Alerts and Submitting Conditions This email and any content within or attached hereto from Sun West Mortgage Company, Inc. is confidential and/or legally privileged. The information is intended only for the use of the individual or entity named on this email. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this email information is strictly prohibited, and that the documents should be returned to this office immediately by email. Receipt by anyone other than the intended recipient is not a waiver of any privilege. Please do not include your social security number, account number, or any other personal or financial information in the content of the email. Should you have any questions, please call (800) 453 7884. -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
