[jira] [Created] (TOBAGO-1879) tc:date does not support Calendar and DateTime

[Henning Noeth (JIRA)]

Henning Noeth created TOBAGO-1879:
-

 Summary: tc:date does not support Calendar and DateTime
 Key: TOBAGO-1879
 URL: https://issues.apache.org/jira/browse/TOBAGO-1879
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Core
Affects Versions: 4.1.0
Reporter: Henning Noeth


Implement support for java.util.Calendar and org.joda.time.DateTime



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Who is list moderator for announces?

[Mike Kienenberger]

I'm now a moderator for announce as well.

On Tue, Mar 13, 2018 at 5:38 AM, Bernd Bohmann
 wrote:
> Hello,
>
> I'm moderator of the announce list. Please ping me if you need a quick
> moderation. I do not look in my myfaces folder every day,
>
> Regards
>
> Bernd
>
> On Mon, Mar 12, 2018 at 4:21 PM, Mike Kienenberger 
> wrote:
>>
>> Switching to MyFaces Development  as this
>> doesn't need to be on private.
>>
>> Back in July, we thought we had the annoucement mailing list straightened
>> out.
>>
>> https://issues.apache.org/jira/browse/INFRA-14696
>>
>> Bernd is a moderator.   I *should* be a moderator, but I never saw a
>> response to my email request to be added.
>>
>> To become a moderator, send an email to apm...@apache.org along the lines
>> of
>>
>> Please add me as a moderator for annou...@myfaces.apache.org.
>>
>> Note that in the issue it states:
>>
>> Please add me as a moderator for annou...@myfaces.apache.org.
>>
>> Also,  Gavin wrote,
>> 
>> I'll note that the announce list, like alot of others are set up that :-
>>
>> 1. must send from an @apache.org address
>> 2. When 1. is correct then send email to moderator for approval
>> (regardless of whether or not you are on the allow list)
>> 
>>
>>
>> On Mon, Mar 12, 2018 at 10:19 AM, Udo Schnurpfeil 
>> wrote:
>> > Hi,
>> >
>> > does somebody know, who is the list moderator? I've got this message for
>> > my
>> > announce some week ago.
>> >
>> > Regards,
>> >
>> > Udo
>> >
>> > Hi! This is the ezmlm program. I'm managing the
>> > annou...@myfaces.apache.org mailing list.
>> >
>> > I'm sorry, the list moderators for the announce list
>> > have failed to act on your post. Thus, I'm returning it to you.
>> > If you feel that this is in error, please repost the message
>> > or contact a list moderator directly.
>> >
>> >
>
>

Re: [VOTE] Release of MyFaces Master POM version 18

[Paul Nicolucci]

+1




From:   "Henning Nöth" 
To: dev@myfaces.apache.org
Date:   03/15/2018 08:36 AM
Subject:Re: [VOTE] Release of MyFaces Master POM version 18



+1

Am 15.03.18 um 13:27 schrieb Udo Schnurpfeil:
> Hi,
>
> I would like to release version 18 of the Apache MyFaces Master POM.
>
> You find the artifact in this Nexus staging repository:
>
> https://repository.apache.org/content/repositories/orgapachemyfaces-1131/
>
>
> Please vote now! (The vote is open for 72h.)
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Regards,
>
> Udo
>

[attachment "signature.asc" deleted by Paul Nicolucci/Durham/IBM]

[jira] [Commented] (TRINIDAD-2563) Trinidad with MyFaces leads to empty ajax-response when render="@all" is used

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRINIDAD-2563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16400349#comment-16400349
 ] 

Thomas Andraschko commented on TRINIDAD-2563:
-

AFAIK we currently don't have any active developer working on Trinidad.
So the only chance may be a PR here: 
[https://github.com/apache/myfaces-trinidad/]

> Trinidad with MyFaces leads to empty ajax-response when render="@all" is used
> -
>
> Key: TRINIDAD-2563
> URL: https://issues.apache.org/jira/browse/TRINIDAD-2563
> Project: MyFaces Trinidad
>  Issue Type: Bug
>Affects Versions: 2.2.1-core
>Reporter: Matthias Füssel
>Priority: Major
>
> Trindidad pvovides its own XmlHttpServletResponse for ajax requests. This 
> response puts Tinidad's XmlOutput into its ResponseWriter chain which causes 
> everything written before a "" header to be thrown 
> away. I have no idea why.
> Trinidad's PartialViewContextImpl uses two different writer chains:
>  * for "real" partial renderings, it uses its own PPResponseWriter -> 
> XmlResponseWriter -> ... . This combination creates a " ?>" header at the begin of the output, so everything works as expected.
>  * for "render all" requests, it uses a standard PartialResponseWriter from 
> the JSF API. The PartialResponseWriter from MyFaces doesn't create any xml 
> header. So everything "written" will be ignored and the request returns a 
> completely empty response which causes a javascript error on the client.
> Options:
>  * remove XmlOutput from XmlHttpServletResponse's writer chain or
>  * use Trinidad's writer chain also for "render all" requests, as there is no 
> guarantee that PartialResponseWriter will use an xml header
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (TRINIDAD-2563) Trinidad with MyFaces leads to empty ajax-response when render="@all" is used

[JIRA]

Matthias Füssel created TRINIDAD-2563:
-

 Summary: Trinidad with MyFaces leads to empty ajax-response when 
render="@all" is used
 Key: TRINIDAD-2563
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2563
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.2.1-core
Reporter: Matthias Füssel


Trindidad pvovides its own XmlHttpServletResponse for ajax requests. This 
response puts Tinidad's XmlOutput into its ResponseWriter chain which causes 
everything written before a "" header to be thrown away. 
I have no idea why.

Trinidad's PartialViewContextImpl uses two different writer chains:
 * for "real" partial renderings, it uses its own PPResponseWriter -> 
XmlResponseWriter -> ... . This combination creates a "" 
header at the begin of the output, so everything works as expected.
 * for "render all" requests, it uses a standard PartialResponseWriter from the 
JSF API. The PartialResponseWriter from MyFaces doesn't create any xml header. 
So everything "written" will be ignored and the request returns a completely 
empty response which causes a javascript error on the client.

Options:
 * remove XmlOutput from XmlHttpServletResponse's writer chain or
 * use Trinidad's writer chain also for "render all" requests, as there is no 
guarantee that PartialResponseWriter will use an xml header

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release of MyFaces Master POM version 18

[Henning Nöth]

+1

Am 15.03.18 um 13:27 schrieb Udo Schnurpfeil:
> Hi,
> 
> I would like to release version 18 of the Apache MyFaces Master POM.
> 
> You find the artifact in this Nexus staging repository:
> 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1131/
> 
> 
> Please vote now! (The vote is open for 72h.)
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> 
> Regards,
> 
> Udo
> 



signature.asc
Description: OpenPGP digital signature

[VOTE] Release of MyFaces Master POM version 18

[Udo Schnurpfeil]

Hi,

I would like to release version 18 of the Apache MyFaces Master POM.

You find the artifact in this Nexus staging repository:

https://repository.apache.org/content/repositories/orgapachemyfaces-1131/


Please vote now! (The vote is open for 72h.)

[ ] +1
[ ] +0
[ ] -1


Regards,

Udo



signature.asc
Description: OpenPGP digital signature

[jira] [Created] (TOBAGO-1878) Duplicated IDs for tc:tree inside tc:flexLayout with mojarra

[Henning Noeth (JIRA)]

Henning Noeth created TOBAGO-1878:
-

 Summary: Duplicated IDs for tc:tree inside tc:flexLayout with 
mojarra
 Key: TOBAGO-1878
 URL: https://issues.apache.org/jira/browse/TOBAGO-1878
 Project: MyFaces Tobago
  Issue Type: New Feature
  Components: Core
Reporter: Henning Noeth


Tested with Mojarra 2.0, 2.1, 2.3

The bug appears if columns attribute have the value '1fr'.
The duplicated IDs are from 

[jira] [Created] (TOBAGO-1877) Implement tc:selectBooleanSwitch

[Henning Noeth (JIRA)]

Henning Noeth created TOBAGO-1877:
-

 Summary: Implement tc:selectBooleanSwitch
 Key: TOBAGO-1877
 URL: https://issues.apache.org/jira/browse/TOBAGO-1877
 Project: MyFaces Tobago
  Issue Type: New Feature
  Components: Core, Themes
Affects Versions: 4.1.0
Reporter: Henning Noeth


The component should be based on tc:selectBooleanCheckbox.
The design should be like: https://www.w3schools.com/howto/howto_css_switch.asp



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TOBAGO-1870) The file attribute of tc:style is not rendered after a submit.

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOBAGO-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16400137#comment-16400137
 ] 

Hudson commented on TOBAGO-1870:


SUCCESS: Integrated in Jenkins build Tobago Trunk #1342 (See 
[https://builds.apache.org/job/Tobago%20Trunk/1342/])
(TOBAGO-1870) The file attribute of tc:style is not rendered after a (bommel: 
rev b11d3e0f1f50b64be2af6154d80f5c57633cd8b9)
* (edit) 
tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIStyle.java
* (edit) 
tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIMeta.java
* (edit) 
tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIScript.java
(TOBAGO-1870) The file attribute of tc:style is not rendered after a (bommel: 
rev 6e8f4baf4ac60e431cb00c66f5eff49e606bf17a)
* (edit) 
tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIStyle.java
* (edit) 
tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIMeta.java
* (edit) 
tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIScript.java


> The file attribute of tc:style is not rendered after a submit.
> --
>
> Key: TOBAGO-1870
> URL: https://issues.apache.org/jira/browse/TOBAGO-1870
> Project: MyFaces Tobago
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 4.1.0
>Reporter: Henning Noeth
>Assignee: Bernd Bohmann
>Priority: Major
> Fix For: 4.2.1
>
>
> An example could be found in the v4.2.0-SNAPSHOT demo:
>  
> [http://localhost:8080/content/40-test/6000-event/event.xhtml|http://localhost:8080/content/40-test/6000-event/event-1870.xhtml]
> After clicking on "reload", the link to "demo.css" file is not rendered 
> inside the  tag.
> The problem only occures with .
> The problem NOT occures with , but the EL 
> should resolve to excactly the same string.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] bohmber closed pull request #10: Tobago-1870

[GitBox]

bohmber closed pull request #10: Tobago-1870
URL: https://github.com/apache/myfaces-tobago/pull/10
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIMeta.java
 
b/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIMeta.java
index 2edf4b9c5..8a027d839 100644
--- 
a/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIMeta.java
+++ 
b/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIMeta.java
@@ -25,15 +25,27 @@
 import javax.faces.event.ComponentSystemEvent;
 import javax.faces.event.ListenerFor;
 import javax.faces.event.PostAddToViewEvent;
+import javax.faces.event.PreRenderViewEvent;
 
 @ListenerFor(systemEventClass = PostAddToViewEvent.class)
 public abstract class AbstractUIMeta extends UIComponentBase {
 
   @Override
   public void processEvent(final ComponentSystemEvent event) {
-final FacesContext facesContext = getFacesContext();
-final UIViewRoot root = facesContext.getViewRoot();
-root.addComponentResource(facesContext, this);
+
+super.processEvent(event);
+
+if (event instanceof PreRenderViewEvent) {
+  final FacesContext facesContext = getFacesContext();
+  final UIViewRoot root = facesContext.getViewRoot();
+  root.addComponentResource(facesContext, this);
+} else if (event instanceof PostAddToViewEvent) {
+  // MyFaces core is removing the component resources in head if the view 
will be recreated before rendering.
+  // The view will be recreated because of expressions. For example  
expressins in the ui:include src attribute
+  // The PostAddToViewEvent will not be broadcasted in this case again.
+  // A subscription to the PreRenderViewEvent avoids this problem
+  
getFacesContext().getViewRoot().subscribeToEvent(PreRenderViewEvent.class, 
this);
+}
   }
 
   public abstract String getCharset();
diff --git 
a/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIScript.java
 
b/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIScript.java
index 1ed52bb9a..b53bfb7bb 100644
--- 
a/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIScript.java
+++ 
b/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIScript.java
@@ -25,6 +25,7 @@
 import javax.faces.event.ComponentSystemEvent;
 import javax.faces.event.ListenerFor;
 import javax.faces.event.PostAddToViewEvent;
+import javax.faces.event.PreRenderViewEvent;
 
 /**
  * {@link 
org.apache.myfaces.tobago.internal.taglib.component.ScriptTagDeclaration}
@@ -36,9 +37,20 @@
 
   @Override
   public void processEvent(final ComponentSystemEvent event) {
-final FacesContext facesContext = getFacesContext();
-final UIViewRoot root = facesContext.getViewRoot();
-root.addComponentResource(facesContext, this);
+
+super.processEvent(event);
+
+if (event instanceof PreRenderViewEvent) {
+  final FacesContext facesContext = getFacesContext();
+  final UIViewRoot root = facesContext.getViewRoot();
+  root.addComponentResource(facesContext, this);
+} else if (event instanceof PostAddToViewEvent) {
+  // MyFaces core is removing the component resources in head if the view 
will be recreated before rendering.
+  // The view will be recreated because of expressions. For example  
expressins in the ui:include src attribute
+  // The PostAddToViewEvent will not be broadcasted in this case again.
+  // A subscription to the PreRenderViewEvent avoids this problem
+  
getFacesContext().getViewRoot().subscribeToEvent(PreRenderViewEvent.class, 
this);
+}
   }
 
   public abstract String getFile();
diff --git 
a/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIStyle.java
 
b/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIStyle.java
index ea7d99a69..5f5876a2b 100644
--- 
a/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIStyle.java
+++ 
b/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIStyle.java
@@ -40,6 +40,7 @@
 import javax.faces.event.ComponentSystemEvent;
 import javax.faces.event.ListenerFor;
 import javax.faces.event.PostAddToViewEvent;
+import javax.faces.event.PreRenderViewEvent;
 
 /**
  * {@link 
org.apache.myfaces.tobago.internal.taglib.component.StyleTagDeclaration}
@@ -53,17 +54,23 @@
 
   @Override
   public void processEvent(final ComponentSystemEvent event) {
-
+super.processEvent(event);
 final FacesContext facesContext = getFacesContext();
 
-if (event instanceof