[jira] [Resolved] (MYFACES-4648) PushContextImpl - different behaviour when socket is not connected

2024-01-16 Thread Thomas Andraschko (Jira)


 [ 
https://issues.apache.org/jira/browse/MYFACES-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko resolved MYFACES-4648.

Resolution: Fixed

Thanks,
Great contribution as always

> PushContextImpl - different behaviour when socket is not connected
> --
>
> Key: MYFACES-4648
> URL: https://issues.apache.org/jira/browse/MYFACES-4648
> Project: MyFaces Core
>  Issue Type: Task
>  Components: General
>Affects Versions: 4.0.1, 4.0.2, 4.1.0, 5.0.0
>Reporter: Milan Siebenbürger
>Priority: Minor
> Fix For: 4.0.2, 4.1.0, 5.0.0
>
>
> Hi,
> when sending a message via PushContextImpl, the behaviour differs when using 
> methods with or without user specification.
> A new FacesException is thrown when the send() method is used without a user 
> specification and without an open channel:
> {code:java}
> throw new FacesException("CDI bean not found for push message");{code}
> When using send() with a user specified, an empty HashMap is returned.
>  
> I think the behavior should be the same - either Exception (not recommended) 
> or an empty result.
>  
> What do you think about this? I am able to prepare a PR (for whatever version 
> you need), but let me know what result you chose.
>  
> Br
> Milan
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


Re: [PR] MYFACES-4648 send without specifying user returns emptySet instead of Exception [myfaces]

2024-01-16 Thread via GitHub


tandraschko merged PR #673:
URL: https://github.com/apache/myfaces/pull/673


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] MYFACES-4648 send without specifying user returns emptySet instead of Exception [myfaces]

2024-01-16 Thread via GitHub


tandraschko merged PR #671:
URL: https://github.com/apache/myfaces/pull/671


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



Re: [PR] MYFACES-4648 send without specifying user returns emptySet instead of Exception [myfaces]

2024-01-16 Thread via GitHub


tandraschko merged PR #672:
URL: https://github.com/apache/myfaces/pull/672


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



[jira] [Commented] (MYFACES-4648) PushContextImpl - different behaviour when socket is not connected

2024-01-16 Thread Jira


[ 
https://issues.apache.org/jira/browse/MYFACES-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807393#comment-17807393
 ] 

Milan Siebenbürger commented on MYFACES-4648:
-

PRs were created..

> PushContextImpl - different behaviour when socket is not connected
> --
>
> Key: MYFACES-4648
> URL: https://issues.apache.org/jira/browse/MYFACES-4648
> Project: MyFaces Core
>  Issue Type: Task
>  Components: General
>Affects Versions: 4.0.1, 4.0.2, 4.1.0, 5.0.0
>Reporter: Milan Siebenbürger
>Priority: Minor
> Fix For: 4.0.2, 4.1.0, 5.0.0
>
>
> Hi,
> when sending a message via PushContextImpl, the behaviour differs when using 
> methods with or without user specification.
> A new FacesException is thrown when the send() method is used without a user 
> specification and without an open channel:
> {code:java}
> throw new FacesException("CDI bean not found for push message");{code}
> When using send() with a user specified, an empty HashMap is returned.
>  
> I think the behavior should be the same - either Exception (not recommended) 
> or an empty result.
>  
> What do you think about this? I am able to prepare a PR (for whatever version 
> you need), but let me know what result you chose.
>  
> Br
> Milan
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


Re: 4.1 M1 Release?

2024-01-16 Thread Volodymyr Siedlecki
Sounds good. I'll comment out the integration tests for the release. 

Expected a vote out sometime next week! 

Thanks,
Volodymyr

On 2024/01/16 13:45:46 Thomas Andraschko wrote:
> Hi,
> 
> in worst case you can comment out the integration modules in POM for now.
> i currently fix some bugs in MF 4.0.x and will merge them into 4.1 and 5.0.
> If you could do a release next week, it would be great (both 4.0 and 4.1).
> 
> Best regards,
> Thomas
> 
> 
> Am Mi., 10. Jan. 2024 um 16:57 Uhr schrieb Volodymyr Siedlecki <
> volos...@apache.org>:
> 
> > Hi,
> >
> > I've been trying to get a successful build locally on my machine for the
> > release, but I've encountered errors with the integration tests:
> >
> > Caused by:
> > org.jboss.arquillian.drone.webdriver.binary.downloading.source.MissingBinaryException:
> > There wasn’t found any binary on the url:
> > https://chromedriver.storage.googleapis.com/114.0.5735.90/chromedriver_mac64_m1.zip
> > at
> > org.jboss.arquillian.drone.webdriver.binary.handler.ChromeDriverBinaryHandler$ChromeStorageSources.getLatestRelease(ChromeDriverBinaryHandler.java:129)
> > at
> > org.jboss.arquillian.drone.webdriver.binary.downloading.source.UrlStorageSource.getLatestRelease(UrlStorageSource.java:59)
> > at
> > org.jboss.arquillian.drone.webdriver.binary.handler.AbstractBinaryHandler.downloadAndPrepare(AbstractBinaryHandler.java:175)
> > at
> > org.jboss.arquillian.drone.webdriver.binary.handler.AbstractBinaryHandler.checkAndSetBinary(AbstractBinaryHandler.java:61)
> > … 14 more
> >
> > The problem above should be fixed via
> > https://github.com/arquillian/arquillian-extension-drone/pull/401
> >
> > I then tried on Linux, but I can’t get it running either
> >
> > java.lang.RuntimeException:
> > Unable to instantiate Drone via
> > org.openqa.selenium.chrome.ChromeDriver(ChromeOptions):
> > org.openqa.selenium.SessionNotCreatedException: Could not start a new
> > session. Response code 500. Message: unknown error: Chrome failed to start:
> > exited abnormally.
> >   (unknown error: DevToolsActivePort file doesn’t exist)
> >   (The process started from chrome location /usr/bin/google-chrome is no
> > longer running, so ChromeDriver is assuming that Chrome has crashed.)
> >
> >
> > https://chromedriver.chromium.org/downloads recommends to use "chrome for
> > testing" instead.
> >
> > https://googlechromelabs.github.io/chrome-for-testing/
> >
> > Current chrome binary is 120.0.6099.199, but the endpoints are down for
> > the stable upcoming API for a previous version.  This also causes errors
> > since chrome binary and the chromedriver need to match versions (which I
> > also tried via '-Dwebdriver.chrome.driver', but it still failed).
> >
> > I'll try a few other things, and hope there are more updates to chrome,
> > selenium, and arquillian. Right now I'm a bit stuck.
> >
> > Volodymyr
> >
> > On 2024/01/04 10:04:14 Paul Nicolucci wrote:
> > > +1 from me!
> > >
> > > Thanks,
> > >
> > > Paul Nicolucci
> > >
> > > On Thu, Jan 4, 2024, 4:32 AM Thomas Andraschko <
> > andraschko.tho...@gmail.com>
> > > wrote:
> > >
> > > > +1 (both 4.1 and 4.0)
> > > > just fixing some minor issues and applying PRs, we are ready tomorrow
> > > >
> > > >
> > > > Am Mi., 3. Jan. 2024 um 22:17 Uhr schrieb Melloware <
> > > > melloware...@gmail.com>:
> > > >
> > > >> No objection from me.
> > > >>
> > > >> On 1/3/2024 4:14 PM, Volodymyr Siedlecki wrote:
> > > >> > Hello,
> > > >> >
> > > >> > May I start a 4.1 M1 release for MyFaces? Let me know if there are
> > > >> > objections.
> > > >> >
> > > >> > Additionally, I'm still working on a 4.0.2 release, but focusing on
> > > >> > getting a passing TCK first.
> > > >> >
> > > >> > Best,
> > > >> >
> > > >> > Volodymyr
> > > >>
> > > >> --
> > > >> Melloware
> > > >> melloware@
> > > >>
> > > >>
> > >
> >
> 


[jira] [Commented] (MYFACES-4648) PushContextImpl - different behaviour when socket is not connected

2024-01-16 Thread Thomas Andraschko (Jira)


[ 
https://issues.apache.org/jira/browse/MYFACES-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807272#comment-17807272
 ] 

Thomas Andraschko commented on MYFACES-4648:


as long there is no reason, i think we can stick with empty hashmap.
please provide a PR ASAP, we discussed already about the next release

> PushContextImpl - different behaviour when socket is not connected
> --
>
> Key: MYFACES-4648
> URL: https://issues.apache.org/jira/browse/MYFACES-4648
> Project: MyFaces Core
>  Issue Type: Task
>  Components: General
>Affects Versions: 4.0.1, 4.0.2, 4.1.0, 5.0.0
>Reporter: Milan Siebenbürger
>Priority: Minor
>
> Hi,
> when sending a message via PushContextImpl, the behaviour differs when using 
> methods with or without user specification.
> A new FacesException is thrown when the send() method is used without a user 
> specification and without an open channel:
> {code:java}
> throw new FacesException("CDI bean not found for push message");{code}
> When using send() with a user specified, an empty HashMap is returned.
>  
> I think the behavior should be the same - either Exception (not recommended) 
> or an empty result.
>  
> What do you think about this? I am able to prepare a PR (for whatever version 
> you need), but let me know what result you chose.
>  
> Br
> Milan
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (MYFACES-4649) ViewScoped bean handling broken because of refactoring

2024-01-16 Thread Thomas Andraschko (Jira)


 [ 
https://issues.apache.org/jira/browse/MYFACES-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko resolved MYFACES-4649.

Resolution: Fixed

> ViewScoped bean handling broken because of refactoring
> --
>
> Key: MYFACES-4649
> URL: https://issues.apache.org/jira/browse/MYFACES-4649
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
>Priority: Major
> Fix For: 4.0.2, 4.1.0, 5.0.0
>
>
> i restored the 2.3.x behavior
> this occured because of DeltaSpike putAll values from oldViewMap to 
> newViewMap on redirect via SecurityAwareViewHandler



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MYFACES-4648) PushContextImpl - different behaviour when socket is not connected

2024-01-16 Thread Jira


[ 
https://issues.apache.org/jira/browse/MYFACES-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807243#comment-17807243
 ] 

Milan Siebenbürger commented on MYFACES-4648:
-

yes, mojarra returns an empty collection in both cases - so we should remove 
the FacesException throwing as well.

in the second case (with user specifying) there is a slight difference - in the 
Mojarra implementation the result is a HashMap filled with empty HashSets (one 
for each user). In the MyFaces implementation, the result is just an empty 
HashMap. That's fine with me, but if you want, I could change it.

 

 

> PushContextImpl - different behaviour when socket is not connected
> --
>
> Key: MYFACES-4648
> URL: https://issues.apache.org/jira/browse/MYFACES-4648
> Project: MyFaces Core
>  Issue Type: Task
>  Components: General
>Affects Versions: 4.0.1, 4.0.2, 4.1.0, 5.0.0
>Reporter: Milan Siebenbürger
>Priority: Minor
>
> Hi,
> when sending a message via PushContextImpl, the behaviour differs when using 
> methods with or without user specification.
> A new FacesException is thrown when the send() method is used without a user 
> specification and without an open channel:
> {code:java}
> throw new FacesException("CDI bean not found for push message");{code}
> When using send() with a user specified, an empty HashMap is returned.
>  
> I think the behavior should be the same - either Exception (not recommended) 
> or an empty result.
>  
> What do you think about this? I am able to prepare a PR (for whatever version 
> you need), but let me know what result you chose.
>  
> Br
> Milan
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (MYFACES-4649) ViewScoped bean handling broken because of refactoring

2024-01-16 Thread Thomas Andraschko (Jira)
Thomas Andraschko created MYFACES-4649:
--

 Summary: ViewScoped bean handling broken because of refactoring
 Key: MYFACES-4649
 URL: https://issues.apache.org/jira/browse/MYFACES-4649
 Project: MyFaces Core
  Issue Type: Bug
Reporter: Thomas Andraschko


i restored the 2.3.x behavior



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


Re: 4.1 M1 Release?

2024-01-16 Thread Thomas Andraschko
Hi,

in worst case you can comment out the integration modules in POM for now.
i currently fix some bugs in MF 4.0.x and will merge them into 4.1 and 5.0.
If you could do a release next week, it would be great (both 4.0 and 4.1).

Best regards,
Thomas


Am Mi., 10. Jan. 2024 um 16:57 Uhr schrieb Volodymyr Siedlecki <
volos...@apache.org>:

> Hi,
>
> I've been trying to get a successful build locally on my machine for the
> release, but I've encountered errors with the integration tests:
>
> Caused by:
> org.jboss.arquillian.drone.webdriver.binary.downloading.source.MissingBinaryException:
> There wasn’t found any binary on the url:
> https://chromedriver.storage.googleapis.com/114.0.5735.90/chromedriver_mac64_m1.zip
> at
> org.jboss.arquillian.drone.webdriver.binary.handler.ChromeDriverBinaryHandler$ChromeStorageSources.getLatestRelease(ChromeDriverBinaryHandler.java:129)
> at
> org.jboss.arquillian.drone.webdriver.binary.downloading.source.UrlStorageSource.getLatestRelease(UrlStorageSource.java:59)
> at
> org.jboss.arquillian.drone.webdriver.binary.handler.AbstractBinaryHandler.downloadAndPrepare(AbstractBinaryHandler.java:175)
> at
> org.jboss.arquillian.drone.webdriver.binary.handler.AbstractBinaryHandler.checkAndSetBinary(AbstractBinaryHandler.java:61)
> … 14 more
>
> The problem above should be fixed via
> https://github.com/arquillian/arquillian-extension-drone/pull/401
>
> I then tried on Linux, but I can’t get it running either
>
> java.lang.RuntimeException:
> Unable to instantiate Drone via
> org.openqa.selenium.chrome.ChromeDriver(ChromeOptions):
> org.openqa.selenium.SessionNotCreatedException: Could not start a new
> session. Response code 500. Message: unknown error: Chrome failed to start:
> exited abnormally.
>   (unknown error: DevToolsActivePort file doesn’t exist)
>   (The process started from chrome location /usr/bin/google-chrome is no
> longer running, so ChromeDriver is assuming that Chrome has crashed.)
>
>
> https://chromedriver.chromium.org/downloads recommends to use "chrome for
> testing" instead.
>
> https://googlechromelabs.github.io/chrome-for-testing/
>
> Current chrome binary is 120.0.6099.199, but the endpoints are down for
> the stable upcoming API for a previous version.  This also causes errors
> since chrome binary and the chromedriver need to match versions (which I
> also tried via '-Dwebdriver.chrome.driver', but it still failed).
>
> I'll try a few other things, and hope there are more updates to chrome,
> selenium, and arquillian. Right now I'm a bit stuck.
>
> Volodymyr
>
> On 2024/01/04 10:04:14 Paul Nicolucci wrote:
> > +1 from me!
> >
> > Thanks,
> >
> > Paul Nicolucci
> >
> > On Thu, Jan 4, 2024, 4:32 AM Thomas Andraschko <
> andraschko.tho...@gmail.com>
> > wrote:
> >
> > > +1 (both 4.1 and 4.0)
> > > just fixing some minor issues and applying PRs, we are ready tomorrow
> > >
> > >
> > > Am Mi., 3. Jan. 2024 um 22:17 Uhr schrieb Melloware <
> > > melloware...@gmail.com>:
> > >
> > >> No objection from me.
> > >>
> > >> On 1/3/2024 4:14 PM, Volodymyr Siedlecki wrote:
> > >> > Hello,
> > >> >
> > >> > May I start a 4.1 M1 release for MyFaces? Let me know if there are
> > >> > objections.
> > >> >
> > >> > Additionally, I'm still working on a 4.0.2 release, but focusing on
> > >> > getting a passing TCK first.
> > >> >
> > >> > Best,
> > >> >
> > >> > Volodymyr
> > >>
> > >> --
> > >> Melloware
> > >> melloware@
> > >>
> > >>
> >
>


[jira] [Commented] (MYFACES-4648) PushContextImpl - different behaviour when socket is not connected

2024-01-16 Thread Thomas Andraschko (Jira)


[ 
https://issues.apache.org/jira/browse/MYFACES-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807207#comment-17807207
 ] 

Thomas Andraschko commented on MYFACES-4648:


+1
could you also check mojarra here?

> PushContextImpl - different behaviour when socket is not connected
> --
>
> Key: MYFACES-4648
> URL: https://issues.apache.org/jira/browse/MYFACES-4648
> Project: MyFaces Core
>  Issue Type: Task
>  Components: General
>Affects Versions: 4.0.1, 4.0.2, 4.1.0, 5.0.0
>Reporter: Milan Siebenbürger
>Priority: Minor
>
> Hi,
> when sending a message via PushContextImpl, the behaviour differs when using 
> methods with or without user specification.
> A new FacesException is thrown when the send() method is used without a user 
> specification and without an open channel:
> {code:java}
> throw new FacesException("CDI bean not found for push message");{code}
> When using send() with a user specified, an empty HashMap is returned.
>  
> I think the behavior should be the same - either Exception (not recommended) 
> or an empty result.
>  
> What do you think about this? I am able to prepare a PR (for whatever version 
> you need), but let me know what result you chose.
>  
> Br
> Milan
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (MYFACES-4648) PushContextImpl - different behaviour when socket is not connected

2024-01-16 Thread Jira
Milan Siebenbürger created MYFACES-4648:
---

 Summary: PushContextImpl - different behaviour when socket is not 
connected
 Key: MYFACES-4648
 URL: https://issues.apache.org/jira/browse/MYFACES-4648
 Project: MyFaces Core
  Issue Type: Task
  Components: General
Affects Versions: 4.0.1, 4.0.2, 4.1.0, 5.0.0
Reporter: Milan Siebenbürger


Hi,

when sending a message via PushContextImpl, the behaviour differs when using 
methods with or without user specification.

A new FacesException is thrown when the send() method is used without a user 
specification and without an open channel:
{code:java}
throw new FacesException("CDI bean not found for push message");{code}
When using send() with a user specified, an empty HashMap is returned.
 
I think the behavior should be the same - either Exception (not recommended) or 
an empty result.
 
What do you think about this? I am able to prepare a PR (for whatever version 
you need), but let me know what result you chose.
 
Br
Milan
 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Resolved] (TOBAGO-2224) Ajax rendering for grid layout doesn't work correctly

2024-01-16 Thread Jira


 [ 
https://issues.apache.org/jira/browse/TOBAGO-2224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henning Nöth resolved TOBAGO-2224.
--
Fix Version/s: 5.9.1
   6.1.1
   Resolution: Fixed

> Ajax rendering for grid layout doesn't work correctly
> -
>
> Key: TOBAGO-2224
> URL: https://issues.apache.org/jira/browse/TOBAGO-2224
> Project: MyFaces Tobago
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 5.7.0
>Reporter: Henning Nöth
>Assignee: Henning Nöth
>Priority: Minor
> Fix For: 5.9.1, 6.1.1
>
>
> See the following example and notice that the ouput component has the 
> attribute labelLayout="gridLeft" set:
> {code:xml}
> 
>    value="#\{gridLayoutTestController.value}">
>     
>   
>    value="#\{gridLayoutTestController.value}"/>
> 
> {code}
> Steps to reproduce:
> 1. select input field
> 2. change value
> 3. leave input field
> Expected result:
> An ajax event is executed and the value in the output field is changed.
> Actual result:
> The ajax event is executed. The old  element stays in DOM. The output 
> field is replaced with a new output field and a second label. There is one 
>  element too much.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)