Re: [core] tasks for release myfaces core 2.0.6 and 2.1.0-rc
Hi I will give you a public notice in this thread when I am done with my testing and fixing. I also want to fix MYFACES-3131 since it crawled up yesterday. Werner Am 09.05.11 00:02, schrieb Leonardo Uribe: Hi Werner Ok, good to know that. I'll be waiting until those issues are solved to start the release procedure. Leonardo 2011/5/8 Werner Punzwerner.p...@gmail.com: Hi Leo sounds good the two weeks will give me some time to test my scripts extensively next week. I slipped a nasty bug in the last release which I do not want to repeat for the upcoming releases of both 2.0.x and 2.1.x I will do the testing round probably on thursday. Werner Am 08.05.11 16:51, schrieb Mark Struberg: +1 sounds good. LieGrue, strub --- On Fri, 5/6/11, Leonardo Uribelu4...@gmail.comwrote: From: Leonardo Uribelu4...@gmail.com Subject: [core] tasks for release myfaces core 2.0.6 and 2.1.0-rc To: MyFaces Developmentdev@myfaces.apache.org Date: Friday, May 6, 2011, 4:48 PM Hi It could be good to do a release of myfaces core 2.0.5 and 2.1.0-rc in 1 or 2 weeks. The code for myfaces core 2.1.x (actually in trunk) is ready, all features specified by the spec were implemented. So to keep things moving and get some feedback, I think it could be good to do a release, so people can give a try. After that, it could be good to do a release of tomahawk too (1.1.11). Most of the issues planned for this release were already solved, and the only thing left is do a cleanup for sandbox for jsf 2.0. If you have some issues that needs to be included in these releases, it is a good time to say it. best regards, Leonardo Uribe
Tomahawk Sandbox inputSuggestAjax problem
Hi all,
I am using MyFaces 1.1.5, Tomahawk 1.1.6 Sandbox 1.1.6. The problem is
that when I use inputSuggestAjax tag from Sandbox, it makes Ajax request but
do not open suggest box (a list which starts with character entered in text
box).
Here is the code used.
JSP file code:
s:inputSuggestAjax
suggestedItemsMethod=#{jsfBean.getAjaxResponse}
value=#{jsfBean.textValue} charset=UTF-8 /
suggestedItemsMethod:
public ListString getAjaxResponse(String keyWord) {
ListString list = new ArrayListString();
list.add(keyWord + _TEST);
list.add(5 + keyWord + _TEST1);
list.add(1 - + keyWord + _TEST2);
list.add(TEST3 - + keyWord + _SAMPLE);
return list;
}
Can any one help me out?
Thanks.
--
View this message in context:
http://old.nabble.com/Tomahawk-Sandbox-inputSuggestAjax-problem-tp31574522p31574522.html
Sent from the My Faces - Dev mailing list archive at Nabble.com.
[jira] [Resolved] (MYFACES-3128) Problems with a custom Resource Resolver
[
https://issues.apache.org/jira/browse/MYFACES-3128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Fernandez Corugedo resolved MYFACES-3128.
--
Resolution: Duplicate
Fix Version/s: 2.1.0
2.1.0-SNAPSHOT
https://issues.apache.org/jira/browse/MYFACES-2628
Problems with a custom Resource Resolver
Key: MYFACES-3128
URL: https://issues.apache.org/jira/browse/MYFACES-3128
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.5
Environment: GlassFish 3.0 with Oracle JVM 1.6 and Websphere
7.0.0.13 with IBM JVM 1.6
Reporter: Juan Fernandez Corugedo
Fix For: 2.1.0-SNAPSHOT, 2.1.0
Attachments: mojarra-test.war, myfaces-test.war
Hi.
I'm working in a project with Myfaces 2.0.5 (or 2.1.0) and I have had a
problem with a custom ResourceResolver.
I have coded a ResourceResolver that dynamically builds an XHTML file when
the engine asks him to resolve a certain URL.
To achieve this, I have update the web.xml as follows:
context-param
param-namejavax.faces.FACELETS_VIEW_MAPPINGS/param-name
param-value*.test;*.xhtml/param-value
/context-param
context-param
param-namejavax.faces.FACELETS_RESOURCE_RESOLVER/param-name
param-valuecom.test.view.facelets.CustomResourceResolver/param-value
/context-param
My CustomResourceResolver is very simple:
package com.test.view.facelets;
import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLConnection;
import java.net.URLStreamHandler;
import javax.faces.view.facelets.ResourceResolver;
public class CustomResourceResolver extends ResourceResolver {
private ResourceResolver innerResourceResolver;
private String viewSource = xhtml of the test page ;
public CustomResourceResolver(ResourceResolver resourceResolver){
this.innerResourceResolver = resourceResolver;
}
@Override
public URL resolveUrl(String path) {
System.out.println(Buscando la URL del recurso: + path);
URL result = null;
if(path.endsWith(.test)){
try{
result = getUrlForResourceAsStream(path);
}catch(Exception e){
System.out.println(Unexpected error while obtaining the URL
from resource + path);
e.printStackTrace(System.out);
}
}else{
result = this.innerResourceResolver.resolveUrl(path);
}
return result;
}
private URL getUrlForResourceAsStream(String path) throws
MalformedURLException {
URLStreamHandler handler = new URLStreamHandler() {
protected URLConnection openConnection(URL u) throws IOException {
final String file = u.getFile();
return new URLConnection(u) {
public void connect() throws IOException {
}
public InputStream getInputStream() throws IOException {
System.out.println(Opening internal url to + file);
try{
System.out.println(Generando el InputStream de
la pagina:\n + viewSource);
return new
ByteArrayInputStream(viewSource.getBytes(UTF-8));
}catch (Exception e) {
e.printStackTrace();
throw new RuntimeException(Unexpected error
while obtaining the view, e);
}
}
};
}
};
return new URL(internal, null, 0, path, handler);
}
}
As you can see, the code is very simple. When the suffix matches the pattern
.test, the Resolver creates a mock URL with a backing ByteArrayInputStream.
If the suffix does not matches the pattern, the normal ResourceResolver is
invoked.
With this configuration and code, when I request the URL:
http://xx:/z/anything.test the application fails with error:
The problem is this:
java.lang.NullPointerException
at java.lang.StringBuilder.init(StringBuilder.java:92)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.getRenderedViewId(FaceletViewDeclarationLanguage.java:1630)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.buildView(FaceletViewDeclarationLanguage.java:279)
The executes the viewHandler.createView(.test) method. It internally
calls the getViewHandlerSupport().calculateViewId(context, viewId); method to
obtain the viewId, and this method calls
[jira] [Created] (TOBAGO-998) Partially update while popup close drops User input
Partially update while popup close drops User input Key: TOBAGO-998 URL: https://issues.apache.org/jira/browse/TOBAGO-998 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.35 Reporter: Volker Weber Assignee: Volker Weber Priority: Blocker When opening a Popup (via Ajax) all hidden input elements are disabled by javascript. When closing this popup the content of the hidden Inputs is not send to the server. This results in data loss when poup close request updates a panel with changed data on client side. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RESULTS] Release of Trinidad 2.0.0
The website is not yet updated -M On Mon, May 2, 2011 at 9:09 PM, Scott O'Bryan darkar...@gmail.com wrote: Argh.. :) Yes, the release is basically done but I was going to get the site updated before making the announcement and trying to fix an issue with the tag doc. :) Thanks for reminding me. :) You should be able to find the maven artifacts though and the release artifacts should be available at http://www.apache.org/dyn/closer.cgi/myfaces/binaries/trinidad-2.0.0-dist.tar.gz. I'll get the website updated tonight and get out the release email. Thanks Glauco.. On 05/02/2011 12:18 PM, Glauco P. Gomes wrote: Any news about the release? Any date? Thanks, Glauco P. Gomes Em 18-04-2011 16:38, Scott O'Bryan escreveu: Thanks to everyone who voted. The vote to release of Trinidad 2.0.0 passed [1] with the following results: +1 (5): Matt Cooper, Werner Punz, Bruno Aranda, Andrew Robinson, Scott O'Bryan And no +0 or -1 votes. Thanks, Scott O'Bryan [1] http://mail-archives.apache.org/mod_mbox/myfaces-dev/201104.mbox/%3c4da77e81.6030...@gmail.com%3E -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [core] tasks for release myfaces core 2.0.6 and 2.1.0-rc
Hi, I see one big issue: https://issues.apache.org/jira/browse/MYFACES-3117 That may require a change in server state management, so I suggest solve it before first 2.1 release Another one is a big performance improvement: https://issues.apache.org/jira/browse/MYFACES-3130 that needs discussion. Regards, Kočičák Leonardo Uribe píše v Pá 06. 05. 2011 v 11:48 -0500: Hi It could be good to do a release of myfaces core 2.0.5 and 2.1.0-rc in 1 or 2 weeks. The code for myfaces core 2.1.x (actually in trunk) is ready, all features specified by the spec were implemented. So to keep things moving and get some feedback, I think it could be good to do a release, so people can give a try. After that, it could be good to do a release of tomahawk too (1.1.11). Most of the issues planned for this release were already solved, and the only thing left is do a cleanup for sandbox for jsf 2.0. If you have some issues that needs to be included in these releases, it is a good time to say it. best regards, Leonardo Uribe
[VOTE] Release of Extensions CDI (CODI) 0.9.5
Hi, I was running the needed tasks to get the 6th release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0 and 2.1) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module - CODI Distribution Modules - CODI Base Test-Infrastructure Module - CODI JUnit-Support Module - CODI Cargo-Support Module - CODI OpenWebBeans Test-Support Module - CODI JSF Test-Support Module - CODI JSF Example Please take a look at the 0.9.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, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-032/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-032/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/0.9.5/myfaces-extcdi-parent-0.9.5-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: [VOTE] Release of Extensions CDI (CODI) 0.9.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/5/9 Gerhard Petracek gpetra...@apache.org Hi, I was running the needed tasks to get the 6th release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0 and 2.1) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module - CODI Distribution Modules - CODI Base Test-Infrastructure Module - CODI JUnit-Support Module - CODI Cargo-Support Module - CODI OpenWebBeans Test-Support Module - CODI JSF Test-Support Module - CODI JSF Example Please take a look at the 0.9.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, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-032/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-032/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/0.9.5/myfaces-extcdi-parent-0.9.5-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes
[jira] [Created] (MYFACES-3133) cc attribute cannot be resolved when composite component is used inside a datatable
cc attribute cannot be resolved when composite component is used inside a datatable - Key: MYFACES-3133 URL: https://issues.apache.org/jira/browse/MYFACES-3133 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.2 Reporter: Michael Wohlfart When a composite component is used inside a datatable, the resolving of the general cc-attribute does not work consistently. For value bindings (with e.g. inputText) everything seems to be fine, but when used inside an actionListener-attribute or an action-attribute (with e.g. commandButton) the resolvement of cc fails. I've isolated the problem to the method CompositeComponentELUtils.getCompositeComponentBasedOnLocation(..) which checks if the parent component in the component stack is a composite component. The HtmlDataTable element is not recognized as such. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3133) cc attribute cannot be resolved when composite component is used inside a datatable
[ https://issues.apache.org/jira/browse/MYFACES-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030715#comment-13030715 ] Michael Wohlfart commented on MYFACES-3133: --- I haven't checked if the problem persists in newer versions than 2.0.2 yet.. will do when there is time... cc attribute cannot be resolved when composite component is used inside a datatable - Key: MYFACES-3133 URL: https://issues.apache.org/jira/browse/MYFACES-3133 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.2 Reporter: Michael Wohlfart Attachments: testproject.zip When a composite component is used inside a datatable, the resolving of the general cc-attribute does not work consistently. For value bindings (with e.g. inputText) everything seems to be fine, but when used inside an actionListener-attribute or an action-attribute (with e.g. commandButton) the resolvement of cc fails. I've isolated the problem to the method CompositeComponentELUtils.getCompositeComponentBasedOnLocation(..) which checks if the parent component in the component stack is a composite component. The HtmlDataTable element is not recognized as such. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MYFACES-3133) cc attribute cannot be resolved when composite component is used inside a datatable
[ https://issues.apache.org/jira/browse/MYFACES-3133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030714#comment-13030714 ] Michael Wohlfart edited comment on MYFACES-3133 at 5/9/11 12:39 PM: To reproduce the bug, deploy the dynamic webproject to your favourite container, call containerlocation/testproject/test.jsf in your favourite browser and push the button... was (Author: michael.wohlfart): To reproduce the bug, deploy the dynamic webproject to your favourite container and call containerlocation/testproject/test.jsf cc attribute cannot be resolved when composite component is used inside a datatable - Key: MYFACES-3133 URL: https://issues.apache.org/jira/browse/MYFACES-3133 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.2 Reporter: Michael Wohlfart Attachments: testproject.zip When a composite component is used inside a datatable, the resolving of the general cc-attribute does not work consistently. For value bindings (with e.g. inputText) everything seems to be fine, but when used inside an actionListener-attribute or an action-attribute (with e.g. commandButton) the resolvement of cc fails. I've isolated the problem to the method CompositeComponentELUtils.getCompositeComponentBasedOnLocation(..) which checks if the parent component in the component stack is a composite component. The HtmlDataTable element is not recognized as such. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RESULTS] Release of Trinidad 2.0.0
Yes. I had some problems with the maven 3 site plugin last week and I fixed them over the weekend. The site should be available as soon as replication happens and I'll be checking in a fix soon to svn. On 05/09/2011 04:44 AM, Matthias Wessendorf wrote: The website is not yet updated -M On Mon, May 2, 2011 at 9:09 PM, Scott O'Bryandarkar...@gmail.com wrote: Argh.. :) Yes, the release is basically done but I was going to get the site updated before making the announcement and trying to fix an issue with the tag doc. :) Thanks for reminding me. :) You should be able to find the maven artifacts though and the release artifacts should be available at http://www.apache.org/dyn/closer.cgi/myfaces/binaries/trinidad-2.0.0-dist.tar.gz. I'll get the website updated tonight and get out the release email. Thanks Glauco.. On 05/02/2011 12:18 PM, Glauco P. Gomes wrote: Any news about the release? Any date? Thanks, Glauco P. Gomes Em 18-04-2011 16:38, Scott O'Bryan escreveu: Thanks to everyone who voted. The vote to release of Trinidad 2.0.0 passed [1] with the following results: +1 (5): Matt Cooper, Werner Punz, Bruno Aranda, Andrew Robinson, Scott O'Bryan And no +0 or -1 votes. Thanks, Scott O'Bryan [1] http://mail-archives.apache.org/mod_mbox/myfaces-dev/201104.mbox/%3c4da77e81.6030...@gmail.com%3E
[jira] [Created] (TOBAGO-999) Partially update while popup close drops User input
Partially update while popup close drops User input Key: TOBAGO-999 URL: https://issues.apache.org/jira/browse/TOBAGO-999 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.35 Reporter: Volker Weber Assignee: Volker Weber Priority: Blocker When opening a Popup (via Ajax) all hidden input elements are disabled by javascript. When closing this popup the content of the hidden Inputs is not send to the server. This results in data loss when poup close request updates a panel with changed data on client side. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOBAGO-998) Partially update while popup close drops User input
[ https://issues.apache.org/jira/browse/TOBAGO-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030741#comment-13030741 ] Volker Weber commented on TOBAGO-998: - This is fixed in 1.0.36 with Revision #1101027 We need to check if this is also a Problem in 1.5. Partially update while popup close drops User input Key: TOBAGO-998 URL: https://issues.apache.org/jira/browse/TOBAGO-998 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.35 Reporter: Volker Weber Assignee: Volker Weber Priority: Blocker Fix For: 1.0.36 When opening a Popup (via Ajax) all hidden input elements are disabled by javascript. When closing this popup the content of the hidden Inputs is not send to the server. This results in data loss when poup close request updates a panel with changed data on client side. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (TOBAGO-998) Partially update while popup close drops User input
[ https://issues.apache.org/jira/browse/TOBAGO-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Volker Weber resolved TOBAGO-998. - Resolution: Fixed Fix Version/s: 1.0.36 Partially update while popup close drops User input Key: TOBAGO-998 URL: https://issues.apache.org/jira/browse/TOBAGO-998 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.0.35 Reporter: Volker Weber Assignee: Volker Weber Priority: Blocker Fix For: 1.0.36 When opening a Popup (via Ajax) all hidden input elements are disabled by javascript. When closing this popup the content of the hidden Inputs is not send to the server. This results in data loss when poup close request updates a panel with changed data on client side. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (EXTCDI-174) Introduce @PropertyActivated or @ConfigActivated
[
https://issues.apache.org/jira/browse/EXTCDI-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030753#comment-13030753
]
Gerhard Petracek commented on EXTCDI-174:
-
suggestion:
@ActivatedOn(any expression)
... by default it would be interpreted by ConfiguredValueInterpreter which
delegates to the existing ConfiguredValueResolver (which also allows to add
custom resolvers to the lookup chain).
as an alternative it would be possible to overrule the default interpreter via:
@ActivatedOn(value = any expression, interpreter = CustomInterpreter.class)
- per default it's simple but still very extensible
Introduce @PropertyActivated or @ConfigActivated
Key: EXTCDI-174
URL: https://issues.apache.org/jira/browse/EXTCDI-174
Project: MyFaces CODI
Issue Type: New Feature
Components: Core
Reporter: Mark Struberg
Assignee: Mark Struberg
While at JAX, I got pretty often asked if there is a way to configure
alternatives automatically via configuration. I pointed them to
@ProjectStageActivated and this solved 60% of the problems.
But there are pretty often more complex scenarios where users like to switch
between e.g. database vendors based on an external configuration.
This could e.g. be a normal java properties file and something like
{code}
@PropertyActivated(user.databyse, mysql)
{code}
where the first parameter is the name and the 2nd is the value which must be
set.
Please add further ideas for ways to change those configurations.
The actual implementation should be trivial as we have most of the work done
already in ProjectStageActivationExtension.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PORTLETBRIDGE-192) Proposal for 3.0 API: javax.portlet.faces.context.BridgeContext and associated BridgeContextFactory
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030805#comment-13030805 ] Michael Freedman commented on PORTLETBRIDGE-192: Alexandr -- it looks like you are commenting on Neil's APIs as the above doesn't fully describe the set of APIs I have proposed/started to put into use. Could you repost comments pertaining to the APIs that are in the refactored code? As to your points: 1) PortletContext, Request/Response are included in the API because there is a short period of time between when the controller is invoked (with a BridgeContext) and when it acquires a FacesContext (and if a nonFaces resource it never acquires one). These APIs allow the controller access to these portlet objects before they are exposed in Faces. 2) Do we really need another threadlocal (and what do we gain by having one)? 95%+ of the time we will need to acquire the BridgeContext we will either have or also need to acquire the FacesContext. I had been planning on adding the BridgeContext to the FacesContext scope and let extensions/etc. access it there as needed. The only real thing running outside the FacesContext is the controller which is passed the BridgeContext explicitly. 3) default viewId's and PortletConfig are in the BridgeConfig 4) Whether or not we have setter methods to allow for object initialization (somewhat) depends on the APIs you come up with for the factories. If the factories cleanly allow for this type of object initialization and allows us to easily extend add new initialization 'attributes in the future then you are right there is no need to have the set methods. I included them so as we have to support new features in Faces that require additional config/context -- it is easy to add a get/set method and have the code using the factory updated to do the additional initialization call. Proposal for 3.0 API: javax.portlet.faces.context.BridgeContext and associated BridgeContextFactory --- Key: PORTLETBRIDGE-192 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-192 Project: MyFaces Portlet Bridge Issue Type: New Feature Components: General Affects Versions: 3.0.0 Reporter: Neil Griffin Assignee: Michael Freedman This class contains contextual information related to the bridge. It is inherently request scoped, and is useful for sharing data between implementations of Bridge.java and ExternalContext.java Please refer to the following classes for this proposal: http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/context/BridgeContext.java http://svn.portletfaces.org/svn/portletfaces/bridge/portletfaces-bridge-api/trunk/src/main/java/org/portletfaces/bridge/context/BridgeContextFactory.java -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3132) javax.faces.context.ResponseWriterWrapper implementation is overdone
[ https://issues.apache.org/jira/browse/MYFACES-3132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3132. - Resolution: Fixed Fix Version/s: 2.1.0 2.0.6 Assignee: Leonardo Uribe The base javadoc of java.io.Writer says this: ... Abstract class for writing to character streams. The only methods that a subclass must implement are write(char[], int, int), flush(), and close(). Most subclasses, however, will override some of the methods defined here in order to provide higher efficiency, additional functionality, or both... so all other methods are not necessary to implement for javax.faces.context.ResponseWriterWrapper class. javax.faces.context.ResponseWriterWrapper implementation is overdone Key: MYFACES-3132 URL: https://issues.apache.org/jira/browse/MYFACES-3132 Project: MyFaces Core Issue Type: Bug Reporter: Matt Benson Assignee: Leonardo Uribe Fix For: 2.0.6, 2.1.0 Attachments: MYFACES-3132-1.patch When using IceFaces an NPE is encountered when one of the lower-level Writer calls is made against its DomResponseWriter (specifically this was a result of HtmlRendererUtils.renderSelectOptions() calling writer.write(TABULATOR)). This is because java.io.Writer delegates all forms of #write() back to the abstract write(char[], int, int) variant. MyFaces' version of ResponseWriterWrapper implements write(int) directly, whereas the spec actually not does declare this method as being implemented here and thus allows the default implementation from Writer to delegate to the char[], int, int version. Since the MyFaces version calls getWrapped().write(int), an NPE is thrown that would be avoided if IceFaces were permitted to proceed through the call sequence as implicitly promised by the spec. True implementation of the spec requires deleting each of: * append(char) * append(CharSequence) * append(CharSequence, int, int) * write(char[]) * write(int) * write(String) * write(String, int, int) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [core] tasks for release myfaces core 2.0.6 and 2.1.0-rc
Hi 2011/5/9 Martin Koci martin.kocicak.k...@gmail.com: Hi, I see one big issue: https://issues.apache.org/jira/browse/MYFACES-3117 That may require a change in server state management, so I suggest solve it before first 2.1 release Just for information the issue title is this: MYFACES-3117 Current server state saving implementation prevents multi-window usage In my understanding, the current implementation was made taking into account the back button. So, if an user navigates from one view to another one and goes back, the state will be restored. @Martin Koci: Could you open a thread on myfaces dev list, so we can discuss this one properly? This issue is not easy to understand, but it is very important and deserves a full discussion with myfaces community. Another one is a big performance improvement: https://issues.apache.org/jira/browse/MYFACES-3130 that needs discussion. @Martin Koci: Could you open a thread on myfaces dev list, so we can discuss this one properly too? In theory, it is ok to use iteration using indices instead call for an iterator for components. In this case we are supposing an implementation detail about UIComponent, but I can imagine someone overriding this stuff and using other structure different to ArrayList. I would like to have a list about the tasks we need to do to enhance myfaces core performance, to take concrete actions and make myfaces even better. regards, Leonardo Uribe Regards, Kočičák Leonardo Uribe píše v Pá 06. 05. 2011 v 11:48 -0500: Hi It could be good to do a release of myfaces core 2.0.5 and 2.1.0-rc in 1 or 2 weeks. The code for myfaces core 2.1.x (actually in trunk) is ready, all features specified by the spec were implemented. So to keep things moving and get some feedback, I think it could be good to do a release, so people can give a try. After that, it could be good to do a release of tomahawk too (1.1.11). Most of the issues planned for this release were already solved, and the only thing left is do a cleanup for sandbox for jsf 2.0. If you have some issues that needs to be included in these releases, it is a good time to say it. best regards, Leonardo Uribe
[jira] [Resolved] (MYFACES-3131) jsf.js:tables not rendering after ajax call in internet explorer 6
[ https://issues.apache.org/jira/browse/MYFACES-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-3131. -- Resolution: Fixed Fix Version/s: 2.1.0-SNAPSHOT 2.0.6-SNAPSHOT the issue is fixed, i also ran extensive testing for subtable replacements to make sure that the subtable replacement code now is waterproof jsf.js:tables not rendering after ajax call in internet explorer 6 -- Key: MYFACES-3131 URL: https://issues.apache.org/jira/browse/MYFACES-3131 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.5 Environment: Tomcat 6 / Myfaces 2.0.5 and Richfaces 4.0.0.Final Internet Explorer 6 as client Reporter: James G Fix For: 2.0.6-SNAPSHOT, 2.1.0-SNAPSHOT objects that start with table disappear when they are selected for render during an ajax call. I debugged the problem and found it occurs in the _outerHTMLNonCompliant function. When tagName is table, _buildTableNodes is called (it really shouldn't be called in this case). In _buildTableNodes, dummyPlaceHolder.innerHTML is set to tabletableSTUFF/table/table. ie6 changes this to tabletbody/tbodytableSTUFF/table/table so evalNodes is set to the empty tbody and thus the table sent back from the server is lost. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3131) jsf.js:tables not rendering after ajax call in internet explorer 6
[ https://issues.apache.org/jira/browse/MYFACES-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030880#comment-13030880 ] James G commented on MYFACES-3131: -- Thanks for fixing this!! jsf.js:tables not rendering after ajax call in internet explorer 6 -- Key: MYFACES-3131 URL: https://issues.apache.org/jira/browse/MYFACES-3131 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.5 Environment: Tomcat 6 / Myfaces 2.0.5 and Richfaces 4.0.0.Final Internet Explorer 6 as client Reporter: James G Fix For: 2.0.6-SNAPSHOT, 2.1.0-SNAPSHOT objects that start with table disappear when they are selected for render during an ajax call. I debugged the problem and found it occurs in the _outerHTMLNonCompliant function. When tagName is table, _buildTableNodes is called (it really shouldn't be called in this case). In _buildTableNodes, dummyPlaceHolder.innerHTML is set to tabletableSTUFF/table/table. ie6 changes this to tabletbody/tbodytableSTUFF/table/table so evalNodes is set to the empty tbody and thus the table sent back from the server is lost. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Release of Extensions CDI (CODI) 0.9.5
+1 Regards, Jakob 2011/5/9 Gerhard Petracek gerhard.petra...@gmail.com: +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/5/9 Gerhard Petracek gpetra...@apache.org Hi, I was running the needed tasks to get the 6th release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0 and 2.1) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module - CODI Distribution Modules - CODI Base Test-Infrastructure Module - CODI JUnit-Support Module - CODI Cargo-Support Module - CODI OpenWebBeans Test-Support Module - CODI JSF Test-Support Module - CODI JSF Example Please take a look at the 0.9.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, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-032/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-032/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/0.9.5/myfaces-extcdi-parent-0.9.5-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] Release of Extensions CDI (CODI) 0.9.5
+1 Am 09.05.11 22:32, schrieb Jakob Korherr: +1 Regards, Jakob 2011/5/9 Gerhard Petracekgerhard.petra...@gmail.com: +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/5/9 Gerhard Petracekgpetra...@apache.org Hi, I was running the needed tasks to get the 6th release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0 and 2.1) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module - CODI Distribution Modules - CODI Base Test-Infrastructure Module - CODI JUnit-Support Module - CODI Cargo-Support Module - CODI OpenWebBeans Test-Support Module - CODI JSF Test-Support Module - CODI JSF Example Please take a look at the 0.9.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, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-032/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-032/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/0.9.5/myfaces-extcdi-parent-0.9.5-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes
[VOTE] Release Tobago 1.0.36
Hello, I would like to release Tobago 1.0.36. Changes: ** Bug * [TOBAGO-980] - tc:attribute mode=valueIfSet not working in some cases * [TOBAGO-981] - Infinite loop in tobago-menu.js * [TOBAGO-983] - ComponentUtils.findDescendant returns the wrong component * [TOBAGO-995] - TextArea applies always style class tobago-TextArea-required, if length validator is present * [TOBAGO-996] - NonFacesRequestServlet doesn't work proper with JSF 1.2 * [TOBAGO-998] - Partially update while popup close drops User input ** Improvement * [TOBAGO-986] - Sheet can only sort UIOutput - Nothing happend with UILinkCommand and UIButtonCommand * [TOBAGO-997] - Extend DebugPhaseListener: log RequestURI, RequestHeaders, ResponseCharset, ... For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12316297 The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-034/ The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd
Re: [VOTE] Release Tobago 1.0.36
+1 Am 09.05.11 22:52, schrieb Bernd Bohmann: Hello, I would like to release Tobago 1.0.36. Changes: ** Bug * [TOBAGO-980] - tc:attribute mode=valueIfSet not working in some cases * [TOBAGO-981] - Infinite loop in tobago-menu.js * [TOBAGO-983] - ComponentUtils.findDescendant returns the wrong component * [TOBAGO-995] - TextArea applies always style class tobago-TextArea-required, if length validator is present * [TOBAGO-996] - NonFacesRequestServlet doesn't work proper with JSF 1.2 * [TOBAGO-998] - Partially update while popup close drops User input ** Improvement * [TOBAGO-986] - Sheet can only sort UIOutput - Nothing happend with UILinkCommand and UIButtonCommand * [TOBAGO-997] - Extend DebugPhaseListener: log RequestURI, RequestHeaders, ResponseCharset, ... For a detail list please consult the release notes: http://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273styleName=Htmlversion=12316297 The version is available at the nexus staging repository. Staging repository: https://repository.apache.org/content/repositories/orgapachemyfaces-034/ The Vote is open for 72h. [ ] +1 [ ] +0 [ ] -1 Regards Bernd
[jira] [Commented] (MYFACES-3132) javax.faces.context.ResponseWriterWrapper implementation is overdone
[ https://issues.apache.org/jira/browse/MYFACES-3132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13030904#comment-13030904 ] Matt Benson commented on MYFACES-3132: -- I do feel it is important to distinguish the fact that MyFaces' implementation of the javax.faces APIs should _exactly_ implement the specification, making the implemention of these methods a deficit rather than a benefit. This would likely almost never be the case with any normal situation. In any event, thanks for addressing this! javax.faces.context.ResponseWriterWrapper implementation is overdone Key: MYFACES-3132 URL: https://issues.apache.org/jira/browse/MYFACES-3132 Project: MyFaces Core Issue Type: Bug Reporter: Matt Benson Assignee: Leonardo Uribe Fix For: 2.0.6, 2.1.0 Attachments: MYFACES-3132-1.patch When using IceFaces an NPE is encountered when one of the lower-level Writer calls is made against its DomResponseWriter (specifically this was a result of HtmlRendererUtils.renderSelectOptions() calling writer.write(TABULATOR)). This is because java.io.Writer delegates all forms of #write() back to the abstract write(char[], int, int) variant. MyFaces' version of ResponseWriterWrapper implements write(int) directly, whereas the spec actually not does declare this method as being implemented here and thus allows the default implementation from Writer to delegate to the char[], int, int version. Since the MyFaces version calls getWrapped().write(int), an NPE is thrown that would be avoided if IceFaces were permitted to proceed through the call sequence as implicitly promised by the spec. True implementation of the spec requires deleting each of: * append(char) * append(CharSequence) * append(CharSequence, int, int) * write(char[]) * write(int) * write(String) * write(String, int, int) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
