from:"Mark Struberg"


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

Mark Struberg edited comment on MYFACES-4224 at 4/12/18 9:45 PM:
-

It didn't stop there :(

{noformat}
SCHWERWIEGEND: An error occured while initializing MyFaces: It's not allowed to 
call getBeans(Type, Annotation...) before AfterBeanDiscovery
java.lang.IllegalStateException: It's not allowed to call getBeans(Type, 
Annotation...) before AfterBeanDiscovery
at 
org.apache.webbeans.container.InjectableBeanManager.checkAfterBeanDiscoveryProcessed(InjectableBeanManager.java:423)
at 
org.apache.webbeans.container.InjectableBeanManager.getBeans(InjectableBeanManager.java:129)
at org.apache.myfaces.cdi.util.CDIUtils.lookup(CDIUtils.java:45)
at 
org.apache.myfaces.cdi.impl.CDIManagedBeanHandlerImpl.(CDIManagedBeanHandlerImpl.java:54)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at 
org.apache.myfaces.shared.util.ClassUtils.newInstance(ClassUtils.java:429)
at 
org.apache.myfaces.shared.util.ClassUtils.newInstance(ClassUtils.java:392)
at 
org.apache.myfaces.spi.impl.DefaultViewScopeProviderFactory.getViewScopeHandler(DefaultViewScopeProviderFactory.java:49)
at 
org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:177)
at 
org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:121)
at 
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4937)
at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5434)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}


was (Author: struberg):
It didn't stop there :(

{noscript}
SCHWERWIEGEND: An error occured while initializing MyFaces: It's not allowed to 
call getBeans(Type, Annotation...) before AfterBeanDiscovery
java.lang.IllegalStateException: It's not allowed to call getBeans(Type, 
Annotation...) before AfterBeanDiscovery
at 
org.apache.webbeans.container.InjectableBeanManager.checkAfterBeanDiscoveryProcessed(InjectableBeanManager.java:423)
at 
org.apache.webbeans.container.InjectableBeanManager.getBeans(InjectableBeanManager.java:129)
at org.apache.myfaces.cdi.util.CDIUtils.lookup(CDIUtils.java:45)
at 
org.apache.myfaces.cdi.impl.CDIManagedBeanHandlerImpl.(CDIManagedBeanHandlerImpl.java:54)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at 
org.apache.myfaces.shared.util.ClassUtils.newInstance(ClassUtils.java:429)
at 
org.apache.myfaces.shared.util.ClassUtils.newInstance(ClassUtils.java:392)
at 
org.apache.myfaces.spi.impl.DefaultViewScopeProviderFactory.getViewScopeHandler(DefaultViewScopeProviderFactory.java:49)
at 
org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:177)
at 
org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:121)
at 
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4937)
at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5434)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask.run(FutureTask.java:266

[jira] [Commented] (MYFACES-4224) AnnotatedFlowConfigurator.configureAnnotatedFlows is broken


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

Mark Struberg commented on MYFACES-4224:


It didn't stop there :(

{noscript}
SCHWERWIEGEND: An error occured while initializing MyFaces: It's not allowed to 
call getBeans(Type, Annotation...) before AfterBeanDiscovery
java.lang.IllegalStateException: It's not allowed to call getBeans(Type, 
Annotation...) before AfterBeanDiscovery
at 
org.apache.webbeans.container.InjectableBeanManager.checkAfterBeanDiscoveryProcessed(InjectableBeanManager.java:423)
at 
org.apache.webbeans.container.InjectableBeanManager.getBeans(InjectableBeanManager.java:129)
at org.apache.myfaces.cdi.util.CDIUtils.lookup(CDIUtils.java:45)
at 
org.apache.myfaces.cdi.impl.CDIManagedBeanHandlerImpl.(CDIManagedBeanHandlerImpl.java:54)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at java.lang.Class.newInstance(Class.java:442)
at 
org.apache.myfaces.shared.util.ClassUtils.newInstance(ClassUtils.java:429)
at 
org.apache.myfaces.shared.util.ClassUtils.newInstance(ClassUtils.java:392)
at 
org.apache.myfaces.spi.impl.DefaultViewScopeProviderFactory.getViewScopeHandler(DefaultViewScopeProviderFactory.java:49)
at 
org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:177)
at 
org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:121)
at 
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4937)
at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5434)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noscript}

> AnnotatedFlowConfigurator.configureAnnotatedFlows is broken
> ---
>
> Key: MYFACES-4224
> URL: https://issues.apache.org/jira/browse/MYFACES-4224
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: JSR-372
>Affects Versions: 2.2.12, 2.3.0
>    Reporter: Mark Struberg
>    Assignee: Mark Struberg
>Priority: Major
>
> When running MyFaces on Tomcat with any CDI container 
> AnnotatedFlowConfigurator.configureAnnotatedFlows get's called way too early 
> which leads to the following Exception:
> {noformat}
> Apr 12, 2018 4:00:55 PM org.apache.myfaces.webapp.AbstractFacesInitializer 
> initFaces
> SCHWERWIEGEND: An error occured while initializing MyFaces: It's not allowed 
> to call getBeans(Type, Annotation...) before AfterBeanDiscovery
> java.lang.IllegalStateException: It's not allowed to call getBeans(Type, 
> Annotation...) before AfterBeanDiscovery
>   at 
> org.apache.webbeans.container.InjectableBeanManager.checkAfterBeanDiscoveryProcessed(InjectableBeanManager.java:423)
>   at 
> org.apache.webbeans.container.InjectableBeanManager.getBeans(InjectableBeanManager.java:129)
>   at org.apache.myfaces.cdi.util.CDIUtils.lookup(CDIUtils.java:45)
>   at 
> org.apache.myfaces.flow.cdi.DefaultCDIFacesFlowProvider.getAnnotatedFlows(DefaultCDIFacesFlowProvider.java:52)
>   at 
> org.apache.myfaces.flow.impl.AnnotatedFlowConfigurator.configureAnnotatedFlows(AnnotatedFlowConfigurator.java:42)
>   at 
> org.apache.myfaces.config.FacesConfigurator.configureFlowHandler(FacesConfigurator.java:1672)
>   at 
> org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:614)
>   at 
> org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:416)
>   at 
> org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:74)
>   at 
> org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:172)
&

[jira] [Created] (MYFACES-4224) AnnotatedFlowConfigurator.configureAnnotatedFlows is broken

Mark Struberg created MYFACES-4224:
--

 Summary: AnnotatedFlowConfigurator.configureAnnotatedFlows is 
broken
 Key: MYFACES-4224
 URL: https://issues.apache.org/jira/browse/MYFACES-4224
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-372
Affects Versions: 2.3.0, 2.2.12
Reporter: Mark Struberg
Assignee: Mark Struberg


When running MyFaces on Tomcat with any CDI container 
AnnotatedFlowConfigurator.configureAnnotatedFlows get's called way too early 
which leads to the following Exception:

{noformat}
Apr 12, 2018 4:00:55 PM org.apache.myfaces.webapp.AbstractFacesInitializer 
initFaces
SCHWERWIEGEND: An error occured while initializing MyFaces: It's not allowed to 
call getBeans(Type, Annotation...) before AfterBeanDiscovery
java.lang.IllegalStateException: It's not allowed to call getBeans(Type, 
Annotation...) before AfterBeanDiscovery
at 
org.apache.webbeans.container.InjectableBeanManager.checkAfterBeanDiscoveryProcessed(InjectableBeanManager.java:423)
at 
org.apache.webbeans.container.InjectableBeanManager.getBeans(InjectableBeanManager.java:129)
at org.apache.myfaces.cdi.util.CDIUtils.lookup(CDIUtils.java:45)
at 
org.apache.myfaces.flow.cdi.DefaultCDIFacesFlowProvider.getAnnotatedFlows(DefaultCDIFacesFlowProvider.java:52)
at 
org.apache.myfaces.flow.impl.AnnotatedFlowConfigurator.configureAnnotatedFlows(AnnotatedFlowConfigurator.java:42)
at 
org.apache.myfaces.config.FacesConfigurator.configureFlowHandler(FacesConfigurator.java:1672)
at 
org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:614)
at 
org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:416)
at 
org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:74)
at 
org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:172)
at 
org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:121)
at 
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4937)
at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5434)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1559)
at 
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1549)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)

{noformat}


This happens because the CDI spec disallows to call BeanManager#getBeans() 
before the container is started (AfterDeploymentValidation and later)




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

[jira] [Commented] (MYFACES-4160) ViewState not written for Ajax request


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

Mark Struberg commented on MYFACES-4160:


Folks, I also get the following issue when starting up MyFaces with plain 
tomcat and OWB:
{noformat}
An error occured while initializing MyFaces: It's not allowed to call 
getBeans(Type, Annotation...) before AfterBeanDiscovery
java.lang.IllegalStateException: It's not allowed to call getBeans(Type, 
Annotation...) before AfterBeanDiscovery
at 
org.apache.webbeans.container.InjectableBeanManager.checkAfterBeanDiscoveryProcessed(InjectableBeanManager.java:423)
at 
org.apache.webbeans.container.InjectableBeanManager.getBeans(InjectableBeanManager.java:129)
at org.apache.myfaces.cdi.util.CDIUtils.lookup(CDIUtils.java:45)
at 
org.apache.myfaces.flow.cdi.DefaultCDIFacesFlowProvider.getAnnotatedFlows(DefaultCDIFacesFlowProvider.java:52)
at 
org.apache.myfaces.flow.impl.AnnotatedFlowConfigurator.configureAnnotatedFlows(AnnotatedFlowConfigurator.java:42)
at 
org.apache.myfaces.config.FacesConfigurator.configureFlowHandler(FacesConfigurator.java:1672)
at 
org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:614)
at 
org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:416)
at 
org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:74)
at 
org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:172)
at 
org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:121)
{noformat}

Should this be fixed with this commit or is this another issue which we need to 
address?

> ViewState not written for Ajax request
> --
>
> Key: MYFACES-4160
> URL: https://issues.apache.org/jira/browse/MYFACES-4160
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Thomas Andraschko
>Assignee: Werner Punz
>Priority: Major
> Fix For: 2.3.0
>
> Attachments: test1.xhtml
>
>
> If you run the application from MYFACES-4156 via mvn jetty:run, the 
> viewStateId isn't rendered again after the first ajax request.
> Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it 
> skips.
> [~lu4242] Could you please check that?



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

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

2018-03-18 Thread Mark Struberg

+1
txs and LieGrue,strub
 

On Thursday, 15 March 2018, 13:26:27 CET, Udo Schnurpfeil 
 wrote:  
 
 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

Re: Only 3 Issues Left for MyFaces 2.3.0-beta release

2017-05-24 Thread Mark Struberg

Trying to test it as well.
Txs, Leo!

LieGrue,
Strub

> Am 16.05.2017 um 12:33 schrieb Dennis Kieselhorst :
> 
> Thanks a lot Leo, looking forward to it.
> 
> Cheers
> Dennis

Re: Migrate all MyFaces projects to Git

2017-04-20 Thread Mark Struberg

gitflow is pure pita ;)
It basically only works for companies where you have a single manager who 
decides what goes in and what not. 

But GIT != gitflow. gitflow has nothing to do with the GIT scm itself, but is 
just a fancy name for a development process with an explicit build-branch and a 
build-master.

+0 on moving to GIT. 
SVN works good enough imo, but GIT ofc also would work.

LIeGrue,
strub

> Am 19.04.2017 um 12:57 schrieb Kito Mann :
> 
> +1
> 
> Wha's wrong with GitFlow?
> 
> ___
> 
> Kito D. Mann | @kito99 | Author, JSF in Action
> Web Components, Polymer, JSF, PrimeFaces, Java EE training and consulting
> Virtua, Inc. | virtua.tech 
> JSFCentral.com | @jsfcentral | knowesis.io - fresh Web Components info
> +1 203-998-0403
> 
> * See me speak at the ng-conf April 5th-8th: http://bit.ly/2mw7HBj
> * Listen to the Enterprise Java Newscast: http://enterprisejavanews.com
> 
> 
> On Wed, Apr 19, 2017 at 4:29 AM, Bernd Bohmann  
> wrote:
> Hello
> 
> I think the changes will be not so complicated. The deltaspike pom looks nice 
> :-) 
> If someone talks about git-flow process i'm out.
> 
> Regards
> 
> Bernd
> 
> On Wed, Apr 19, 2017 at 12:28 AM, Leonardo Uribe  wrote:
> +1
> 
> Change the release process is a pain, but I agree there are some benefits 
> moving to git.
> 
> But when I see here:
> 
> https://github.com/apache/myfaces
> 
> It says:
> 
> mirrored from git://git.apache.org/myfaces.git
> 
> But I have never checked where that file is or how to change it.
> 
> Looking in deltaspike, the svn repo only has the site (for the CMS) and the 
> source code lives on git. If that so, we still need the svn, so I agree it is 
> a good idea to move only some subprojects to git.
> 
> regards,
> 
> Leonardo Uribe
> 
> 
>   Virus-free. www.avast.com
> 
> 2017-04-17 11:40 GMT-05:00 Grant Smith :
> +1 
> 
> Couldn't agree more.
> 
> Grant Smith - V.P. Information Technology
> Marathon Computer Systems, LLC.
> 
> On Thu, Apr 13, 2017 at 2:39 AM, Bernd Bohmann  
> wrote:
> From my side a big
> 
> +1
> 
> I'm still happy with subversion but for others the collaboration is easier 
> and the project visibility a little bit better.
> 
> Regards
> 
> Bernd
> 
> Am 13.04.2017 09:41 schrieb "Thomas Andraschko" :
> +0
> I usually just work on MF core and there it doesn't make much difference.
> 
> 2017-04-13 8:57 GMT+02:00 Dennis Kieselhorst :
> Hi,
> 
> have you ever thought of migrating to Git? I see more and more Apache
> projects moving. In the past SVN or Git didn't make any difference to me
> but now I'm thinking that as an Open Source project you need to be
> present on GitHub to get Pull Requests from the community. It's much
> more fun contributing there than attaching patches to JIRA issues.
> 
> We could start with Trinidad and Tobago to avoid conflicts with the 2.3
> release.
> 
> Cheers
> Dennis
> 
> 
> 
> 
>

Re: Redirect MyFaces Orchestra/CODI to DeltaSpike

2016-10-14 Thread Mark Struberg

Orchestra initially targeted Spring. DeltaSpike is for CDI. 

Nonetheless I think it is ok to redirect to DeltaSpike as we moved the 
functionality over to CDI and Spring did reimplement most Orchestra features in 
their own way themselves.
In other words Orchestra is now legacy and we should mark that it's not 
actively supported anymore.

LieGrue,
strub

> On Wednesday, 12 October 2016, 21:09, Mike Kienenberger  
> wrote:
> > During the last MyFaces board report, a board member made the following 
> > comment:
> 
>   A quick look at myfaces.a.o doesn't make it clear that
>   CDI/Deltaspike is the recommended approach for new users.
> 
> Is there someone in either the MyFaces or DeltaSpike community who
> would be willing to review and update the MyFaces Orchestra/CODI
> documentation to redirect those individuals looking at Orchestra and
> CODI to DeltaSpike?
>

Re: proposed [REPORT] MyFaces - October 2016

2016-10-14 Thread Mark Struberg

+1

LieGrue,
strub




On Thursday, 13 October 2016, 20:43, Bill Lucy  wrote:


>
>
>+1
>
>Thanks,
>Bill Lucy
>
>
>
>On Wed, Oct 12, 2016 at 3:16 PM, Mike Kienenberger  wrote:
>
>Please comment.  I will be submitting the report Friday.
>>
>>## Description: The Apache MyFaces project is an umbrella project of the
>>Apache Software Foundation for projects relating to the JavaServer Faces (JSF)
>>technology.
>>
>>## Activity and health:
>>- Apache Myfaces Core is healthy and in maintenance mode.
>>
>>UI-Component Sets:
>>- Apache Tobago is healthy and active.
>>- Apache Trinidad is in maintenance mode.  Last developer commit
>> was May 2016.  Last commit on behalf of a contributor was Sept 2016.
>>- Myfaces Tomahawk is in maintenance mode. Last developer commit
>> was May 2016.  Last commit on behalf of a contributor was May 2016.
>>
>>Add-ons and Extensions:
>>- Apache MyFaces Portlet Bridge is in maintenance mode.  Last developer commit
>> was Jan 2014.  Last commit on behalf of a contributor was May 2015.
>>- Apache MyFaces CODI is in maintenance mode. CODI was replaced by Apache
>> DeltaSpike so new development happens there.  Last commit March 2014.
>>- Apache MyFaces Orchestra is in maintenance mode.  New projects use CDI and
>> DeltaSpike instead.  Last commit on behalf of a contributor was August 2016.
>>- Apache MyFaces ExtVal is in maintenance mode. Last commit June 2014.
>>- Apache MyFaces Commons is in maintenance mode.  Last commit August 2012.
>>- Apache MyFaces Ext-Scripting is in maintenance mode.  Last commit Dec 2012.
>>- Apache MyFaces Test is in maintenance mode (Used by Myfaces Core).  Last
>> commit June 2014.
>>
>>Security:
>>- We received a vulnerability report against MyFaces Trinidad on July 20th and
>>  responded to the reporter the same day.  We released patched versions of
>>  Trinidad 1.2.x, 2.0.x, and 2.1.x on Sept 29th along with CVE-2016-5019.
>>
>>Issues:
>>   mt asked: Is it time to retire CODI and Orchestra? Also, a quick look at
>>  myfaces.a.o doesn't make it clear that CDI/Deltaspike is the
>>  recommended approach for new users.
>>
>>  There was no comment by the MyFaces PMC on these questions.   There was a
>>  trivial contribution for Orchestra on Aug 10th which was applied on Aug
>>  11th, so support is still being provided when requested.  My personal
>>  opinion is that it is time to retire these projects, but I do not know of
>>  anyone who is willing to take the time to accomplish these tasks.  On Oct
>>  12th, I posted a request for help on the dev@deltaspike and dev@myfaces
>>  lists to see if anyone there would be willing to update the pages for CODI
>>  and Orchestra.
>>
>>## Community changes:
>>
>>- Currently 76 committers and 42 PMC members.
>>- Last committer addition was Thomas Andraschko at Thu Jul 02 2015
>>- Last PMC additions were Bill Lucy and Thomas Andraschko on Fri Jan 15 2016
>>
>>## Releases:
>>
>> - Apache MyFaces Core-2.2.11 was released on Sun Sep 18 2016
>> - Apache Tobago-2.0.10 was released on Wed Sep 07 2016
>> - Apache Tobago-3.0.0-alpha-4 was released on Sat Jul 16 2016
>> - Apache Tobago-3.0.0-alpha-5 was released on Sat Aug 27 2016
>> - Apache Tobago-3.0.0-alpha-6 was released on Mon Sep 19 2016
>> - Apache Trinidad-1.2.15 was released on Mon Sep 26 2016
>> - Apache Trinidad-2.0.2 was released on Mon Sep 26 2016
>> - Apache Trinidad-2.1.2 was released on Mon Sep 26 2016
>>
>>## JIRA activity:
>>
>> - 48 JIRA tickets created in the last 3 months
>> - 41 JIRA tickets closed/resolved in the last 3 months
>>
>
>
>

Re: [VOTE] Release Tobago 3.0.0-alpha-3

2016-04-18 Thread Mark Struberg

+1

LieGrue,
strub




> On Friday, 15 April 2016, 15:49, Udo Schnurpfeil  wrote:
> > Hello,
> 
> I would like to release Tobago 3.0.0-alpha-3.
> 
> Major change is upgrading from Bootstrap 3 and
> using Servlet 3.0 API for uploading files
> (instead of commons-fileupload).
> 
> For a detail list please consult the release notes:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273=12334363
> The version is available at the staging repository (Nexus).
> 
> Staging repository:
> 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1066/
> 
> The vote is open for 72h.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> Regards,
> 
> Udo
>

Re: [VOTE] Release of MyFaces Core 2.2.9

2015-12-01 Thread Mark Struberg

LieGrue,
strub


> Am 24.11.2015 um 04:16 schrieb Leonardo Uribe :
> 
> Hi,
> 
> I was running the needed tasks to get the 2.2.9 release of Apache
> MyFaces core out.
> 
> The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip).
> 
> Please note that this vote concerns all of the following parts:
>  1. Maven artifact group "org.apache.myfaces.shared" v4.2.7  [1]
>  2. Maven artifact group "org.apache.myfaces.core" v2.2.9  [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.2.9" 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-1057/org/apache/myfaces/
> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
> [3] http://people.apache.org/~lu4242/myfaces229binsrc
> [4] 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12331973

Re: [VOTE] Release of MyFaces Core 2.2.9

2015-12-01 Thread Mark Struberg

woha my cat did eat my  +1 :)

LieGrue,
strub

PS: don’t have any cat…


> Am 01.12.2015 um 16:55 schrieb Mark Struberg <strub...@yahoo.de>:
> 
> LieGrue,
> strub
> 
> 
>> Am 24.11.2015 um 04:16 schrieb Leonardo Uribe <lu4...@gmail.com>:
>> 
>> Hi,
>> 
>> I was running the needed tasks to get the 2.2.9 release of Apache
>> MyFaces core out.
>> 
>> The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip).
>> 
>> Please note that this vote concerns all of the following parts:
>> 1. Maven artifact group "org.apache.myfaces.shared" v4.2.7  [1]
>> 2. Maven artifact group "org.apache.myfaces.core" v2.2.9  [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.2.9" 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-1057/org/apache/myfaces/
>> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
>> [3] http://people.apache.org/~lu4242/myfaces229binsrc
>> [4] 
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12331973
>

[jira] [Commented] (MYFACES-4021) blacklist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in MyFacesObjectInputStream

2015-11-29 Thread Mark Struberg (JIRA)


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

Mark Struberg commented on MYFACES-4021:


The serialisation used to be required by the spec. But we do this actually 
_before_ we store it in the Http session. The point is that you can only make 
sure a view state is truly separated from the previous version by serialising 
it. You kind of need to get a deep copy, otherwise changes done on references 
will also modify old view states. This requirement only got dropped from the 
spec as it was made clear that the RI itself doesn't implement it ;)

> blacklist 
> org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan
>  in  MyFacesObjectInputStream
> -
>
> Key: MYFACES-4021
> URL: https://issues.apache.org/jira/browse/MYFACES-4021
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Romain Manni-Bucau
>Priority: Blocker
>
> https://github.com/apache/incubator-batchee/commit/cfd133c309c21a82fb24cfcc9a7c2365aee4678a#diff-acd0bc06477ce776b0ad8fdda76f8b7eR56
>  mecanism can be used
> (due to recent vulnerability discovered in [collections], spring, groovy we 
> can't suppose we don't run with these libraries so we need this fix as well)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MYFACES-4021) blacklist org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan in MyFacesObjectInputStream

2015-11-27 Thread Mark Struberg (JIRA)


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

Mark Struberg commented on MYFACES-4021:


If someone uses client side state saving and no encryption, then he is doomed 
anyway imo ;)

Serious: we should probably update our docs. If the client state is encrypted 
then there is no problem imo. 

> blacklist 
> org.codehaus.groovy.runtime.,org.apache.commons.collections.functors.,org.apache.xalan
>  in  MyFacesObjectInputStream
> -
>
> Key: MYFACES-4021
> URL: https://issues.apache.org/jira/browse/MYFACES-4021
> Project: MyFaces Core
>  Issue Type: Bug
>Reporter: Romain Manni-Bucau
>Priority: Blocker
>
> https://github.com/apache/incubator-batchee/commit/cfd133c309c21a82fb24cfcc9a7c2365aee4678a#diff-acd0bc06477ce776b0ad8fdda76f8b7eR56
>  mecanism can be used
> (due to recent vulnerability discovered in [collections], spring, groovy we 
> can't suppose we don't run with these libraries so we need this fix as well)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Tobago 3.0.0-alpha-1

2015-11-07 Thread Mark Struberg

+1

LieGrue,
strub


> Am 04.11.2015 um 10:17 schrieb Udo Schnurpfeil :
> 
> Hello,
> 
> I would like to release Tobago 3.0.0-alpha-1.
> 
> For a detail list please consult the release notes:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273=12325881
> The version is available at the staging repository (Nexus).
> 
> Staging repository:
> 
> https://repository.apache.org/content/repositories/orgapachemyfaces-1055/
> 
> The vote is open for 72h.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> Regards,
> 
> Udo
>

Re: Request for comments on Myfaces project statuses

2015-10-06 Thread Mark Struberg

Hi Mike!

Comments inline

txs and LieGrue,
staub


> Am 05.10.2015 um 20:05 schrieb Mike Kienenberger :
> 
> I'm in the process of compiling the Myfaces board report for October.
> 
> Would anyone care to comment on the activity and health of the
> following subprojects?  I've already written something up for
> Trinidad, Tobago, and PortletBridge, which I've posted at the bottom,
> but we can revise those if necessary.
> 
> JSF Implementation:
> - Apache Myfaces Core is …
active and doing well

> 
> UI-Component Sets:
> - Myfaces Tomahawk is …
still JSF-1.2 only and although it contains a few _very_ cool components it is 
dormant since a long time.


> 
> Add-ons and Extensions:
> 
> - Apache MyFaces CODI is …
Basically deprecated and replaced by Apache DeltaSpike. I think we ported over 
all the features already

> - Apache MyFaces Orchestra is …
dormant afaik. Not updated since ages imo

> - Apache MyFaces ExtVal is …
in use in production and still maintained

> - Apache MyFaces Test is …
not quite sure on this one. Guess it’s used as well

> - Apache MyFaces Commons is …
contains a few nice parts which are still needed even with JSF-2.3. E.g. the 
resource handler

> - Apache MyFaces Ext-Scripting is …
no idea, Werner should know better

> - Apache MyFaces Sandbox is …
a sandbox? :) 

> 
> 
> UI-Component Sets:
> - Apache Tobago is healthy and active.
+1

> 
> - Apache Trinidad had three maintenance commits by two different new
> contributors this quarter, which was encouraged by having issue
> reporters submit fixes for their own issues.  There may still be life
> in this project.
+1

> 
> Add-ons and Extensions:
> - Apache MyFaces Portlet Bridge is dead.  Last developer commit was
> Jan 2014.  We added a contributor who indicated interest in the
> project in May, but no activity has been forthcoming.  We will
> probably need assistance in moving this project to the attic.
+1

Re: Apache MyFaces dependencies on JDK-Internal APIs

2015-06-23 Thread Mark Struberg

I’ve checked core api + impl with 1.8.0_45 and didn’t find anything popping up.


find . -name „*.jar | xargs $JAVA_HOME/bin/jdeps -P -jdkinternals

LieGrue,
strub


 Am 22.06.2015 um 19:29 schrieb Mike Kienenberger mkien...@gmail.com:
 
 MyFaces encompasses 11 subprojects, so it's going to take a lot of
 resources to check all of them.
 
 I know that there was a dependency fixed for the MyFaces Tomahawk
 examples to the sun image package in the last couple of months.
 
 On Mon, Jun 22, 2015 at 1:03 PM, Mark Struberg strub...@yahoo.de wrote:
 I quickly checked but had not enough spare time to dig deeper.
 Probably doing in the next days.
 
 Txs for the ping though, higly appreciated!
 
 LieGrue,
 strub
 
 
 
 Am 22.06.2015 um 13:30 schrieb Rory O'Donnell rory.odonn...@oracle.com:
 
 Hi,
 
 Just wondering if anyone has had a chance to run the jdeps tool to check 
 for dependencies on JDK-Internal APIs ?
 
 Rgds,Rory
 
 On 15/06/2015 14:08, Rory O'Donnell wrote:
 
 Hi,
 
 My name is Rory O'Donnell, I am the OpenJDK Quality Group Lead.
 
 I'm contacting you because your open source project seems to be a very 
 popular dependency for other open source projects.
 As part of the preparations for JDK 9, Oracle’s engineers have been 
 analyzing open source projects like yours to understand usage. One area of 
 concern involves identifying compatibility problems, such as reliance on 
 JDK-internal APIs.
 
 Our engineers have already prepared guidance on migrating some of the more 
 common usage patterns of JDK-internal APIs to supported public interfaces. 
  The list is on the OpenJDK wiki [0].
 
 As part of the ongoing development of JDK 9, I would like to inquire about 
 your usage of  JDK-internal APIs and to encourage migration towards 
 supported Java APIs if necessary.
 
 The first step is to identify if your application(s) is leveraging 
 internal APIs.
 
 Step 1: Download JDeps.
 Just download a preview release of JDK8(JDeps Download). You do not need 
 to actually test or run your application on JDK8.  JDeps(Docs) looks 
 through JAR files and identifies which JAR files use internal APIs and 
 then lists those APIs.
 Step 2: To run JDeps against an application. The command looks like:
 jdk8/bin/jdeps -P -jdkinternals *.jar  your-application.jdeps.txt
 
 The output inside your-application.jdeps.txt will look like:
 
 your.package (Filename.jar)
 - com.sun.corba.seJDK internal API (rt.jar)
 3rd party library using Internal APIs:
 If your analysis uncovers a third-party component that you rely on, you 
 can contact the provider and let them know of the upcoming changes. You 
 can then either work with the provider to get an updated library that 
 won't rely on Internal APIs, or you can find an alternative provider for 
 the capabilities that the offending library provides.
 
 Dynamic use of Internal APIs:
 JDeps can not detect dynamic use of internal APIs, for example through 
 reflection, service loaders and similar mechanisms.
 
 Rgds,Rory
 
 [0] 
 https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
 --
 Rgds,Rory O'Donnell
 Quality Engineering Manager
 Oracle EMEA , Dublin, Ireland
 
 
 --
 Rgds,Rory O'Donnell
 Quality Engineering Manager
 Oracle EMEA , Dublin, Ireland

Re: Apache MyFaces dependencies on JDK-Internal APIs

2015-06-22 Thread Mark Struberg

I quickly checked but had not enough spare time to dig deeper. 
Probably doing in the next days.

Txs for the ping though, higly appreciated!

LieGrue,
strub



 Am 22.06.2015 um 13:30 schrieb Rory O'Donnell rory.odonn...@oracle.com:
 
 Hi,
 
 Just wondering if anyone has had a chance to run the jdeps tool to check for 
 dependencies on JDK-Internal APIs ?
 
 Rgds,Rory
 
 On 15/06/2015 14:08, Rory O'Donnell wrote:
 
 Hi, 
 
 My name is Rory O'Donnell, I am the OpenJDK Quality Group Lead.  
 
 I'm contacting you because your open source project seems to be a very 
 popular dependency for other open source projects.
 As part of the preparations for JDK 9, Oracle’s engineers have been 
 analyzing open source projects like yours to understand usage. One area of 
 concern involves identifying compatibility problems, such as reliance on 
 JDK-internal APIs. 
 
 Our engineers have already prepared guidance on migrating some of the more 
 common usage patterns of JDK-internal APIs to supported public interfaces.  
 The list is on the OpenJDK wiki [0].
 
 As part of the ongoing development of JDK 9, I would like to inquire about 
 your usage of  JDK-internal APIs and to encourage migration towards 
 supported Java APIs if necessary.
 
 The first step is to identify if your application(s) is leveraging internal 
 APIs. 
 
   Step 1: Download JDeps. 
 Just download a preview release of JDK8(JDeps Download). You do not need to 
 actually test or run your application on JDK8.  JDeps(Docs) looks through 
 JAR files and identifies which JAR files use internal APIs and then lists 
 those APIs.
   Step 2: To run JDeps against an application. The command looks like:
 jdk8/bin/jdeps -P -jdkinternals *.jar  your-application.jdeps.txt
 
 The output inside your-application.jdeps.txt will look like:
 
 your.package (Filename.jar)
   - com.sun.corba.seJDK internal API (rt.jar)
 3rd party library using Internal APIs:
 If your analysis uncovers a third-party component that you rely on, you can 
 contact the provider and let them know of the upcoming changes. You can then 
 either work with the provider to get an updated library that won't rely on 
 Internal APIs, or you can find an alternative provider for the capabilities 
 that the offending library provides.
 
 Dynamic use of Internal APIs:
 JDeps can not detect dynamic use of internal APIs, for example through 
 reflection, service loaders and similar mechanisms.
 
 Rgds,Rory 
 
 [0] https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool
 -- 
 Rgds,Rory O'Donnell
 Quality Engineering Manager
 Oracle EMEA , Dublin, Ireland 
 
 
 -- 
 Rgds,Rory O'Donnell
 Quality Engineering Manager
 Oracle EMEA , Dublin, Ireland

[jira] [Created] (MYFACES-3998) improve BanManger lookup for CDI-1.1

Mark Struberg created MYFACES-3998:
--

 Summary: improve BanManger lookup for CDI-1.1
 Key: MYFACES-3998
 URL: https://issues.apache.org/jira/browse/MYFACES-3998
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.8
Reporter: Mark Struberg
Assignee: Mark Struberg


We currently do partly unportable stuff to look up the BeanManager. This could 
be replaced by dynamically using CDI.current().get(). 
This should be done via reflection to avoid blowing up if no CDI-1.1 
environment is present.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (MYFACES-3999) Contextual Instance lookup code is broken

Mark Struberg created MYFACES-3999:
--

 Summary: Contextual Instance lookup code is broken
 Key: MYFACES-3999
 URL: https://issues.apache.org/jira/browse/MYFACES-3999
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.8
Reporter: Mark Struberg
Assignee: Mark Struberg


Our CDI instance lookup code is wrong. We must not simply put the first 
instance from the iterator but use BeanManager#resolve etc to get it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (MYFACES-3998) improve BanManger lookup for CDI-1.1


[ 
https://issues.apache.org/jira/browse/MYFACES-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14583558#comment-14583558
 ] 

Mark Struberg commented on MYFACES-3998:


CDI.current() is designed to give you the correct BeanManager in that case. We 
have exactly the correct TCCL when CDI.current() is used.

 improve BanManger lookup for CDI-1.1
 

 Key: MYFACES-3998
 URL: https://issues.apache.org/jira/browse/MYFACES-3998
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.8
Reporter: Mark Struberg
Assignee: Mark Struberg

 We currently do partly unportable stuff to look up the BeanManager. This 
 could be replaced by dynamically using CDI.current().get(). 
 This should be done via reflection to avoid blowing up if no CDI-1.1 
 environment is present.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (MYFACES-3998) improve BanManger lookup for CDI-1.1


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

Mark Struberg resolved MYFACES-3998.

Resolution: Fixed

 improve BanManger lookup for CDI-1.1
 

 Key: MYFACES-3998
 URL: https://issues.apache.org/jira/browse/MYFACES-3998
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.8
Reporter: Mark Struberg
Assignee: Mark Struberg

 We currently do partly unportable stuff to look up the BeanManager. This 
 could be replaced by dynamically using CDI.current().get(). 
 This should be done via reflection to avoid blowing up if no CDI-1.1 
 environment is present.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (MYFACES-3999) Contextual Instance lookup code is broken


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

Mark Struberg resolved MYFACES-3999.

Resolution: Fixed

 Contextual Instance lookup code is broken
 -

 Key: MYFACES-3999
 URL: https://issues.apache.org/jira/browse/MYFACES-3999
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.8
Reporter: Mark Struberg
Assignee: Mark Struberg

 Our CDI instance lookup code is wrong. We must not simply put the first 
 instance from the iterator but use BeanManager#resolve etc to get it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Release Tobago 2.0.4

2014-11-19 Thread Mark Struberg

+1

LieGrue,
strub




 On Wednesday, 19 November 2014, 11:56, Udo Schnurpfeil u...@schnurpfeil.de 
 wrote:
  Hello,
 
 I would like to release Tobago 2.0.4.
 
 For a detail list please consult the release notes:
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273version=12328041
 The version is available at the staging repository (Nexus).
 
 Staging repository:
 
 https://repository.apache.org/content/repositories/orgapachemyfaces-1036/
 
 The Vote is open for 72h.
 
 [ ] +1
 [ ] +0
 [ ] -1
 
 Regards,
 
 Udo

Re: [VOTE] Release of MyFaces Core 2.2.5

2014-09-19 Thread Mark Struberg

+1

LieGrue,
strub




 On Friday, 19 September 2014, 17:46, Bernd Bohmann 
 bernd.bohm...@atanion.com wrote:
  Here is my
 
 +1
 
 Regards
 
 Bernd
 
 
 On Thu, Sep 18, 2014 at 6:09 PM, Martin Marinschek
 mmarinsc...@apache.org wrote:
  +1
 
  Regards,
 
  Martin
 
  Am 18.09.2014 13:10 schrieb Werner Punz 
 werner.p...@gmail.com:
 
  +1
 
  Am 16.09.14 20:53, schrieb Leonardo Uribe:
 
  +1
 
  2014-09-16 13:53 GMT-05:00 Leonardo Uribe 
 lu4...@apache.org:
 
  Hi,
 
  I was running the needed tasks to get the 2.2.5 release of 
 Apache
  MyFaces core out.
 
  The artifacts passed the TCK test of Feb 2013
  (jsftck-2.2_26-Feb-2013.zip).
 
  Please note that this vote concerns all of the following parts:
1. Maven artifact group org.apache.myfaces.shared 
 v4.2.4  [1]
2. Maven artifact group org.apache.myfaces.core 
 v2.2.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.2.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-1031/org/apache/myfaces/
  [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
  [3] http://people.apache.org/~lu4242/myfaces225binsrc
  [4]
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12327190

Re: [VOTE] Release of MyFaces Core 2.2.3

2014-04-17 Thread Mark Struberg

+1

LieGrue,
strub


On Wednesday, 16 April 2014, 19:18, Leonardo Uribe lu4...@gmail.com wrote:
 
+1


2014-04-16 19:17 GMT+02:00 Leonardo Uribe lu4...@gmail.com:
 Hi,

 I was running the needed tasks to get the 2.2.3 release of Apache
 MyFaces core out.

 The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip).

 Please note that this vote concerns all of the following parts:
  1. Maven artifact group org.apache.myfaces.shared v4.2.2  [1]
  2. Maven artifact group org.apache.myfaces.core v2.2.3  [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.2.3 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-1018/org/apache/myfaces/
    
https://repository.apache.org/content/repositories/orgapachemyfaces-1017/org/apache/myfaces/
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
 [3] http://people.apache.org/~lu4242/myfaces223binsrc
 [4] 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12326543

Re: [VOTE] release of MyFaces Core 2.2.1

2014-03-05 Thread Mark Struberg

+1

LieGrue,
strub





On Wednesday, 5 March 2014, 16:58, Grant Smith gr...@marathonpm.com wrote:
 
+1



On Tue, Mar 4, 2014 at 10:22 PM, Martin Kočí martin.kocicak.k...@gmail.com 
wrote:

+1




2014-03-04 6:40 GMT+01:00 Leonardo Uribe lu4...@gmail.com:


Hi,

I was running the needed tasks to get the 2.2.1 release of Apache
MyFaces core out.

The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip).

Please note that this vote concerns all of the following parts:
 1. Maven artifact group org.apache.myfaces.core v2.2.1  [1]

Keep in mind that this vote also include the new myfaces-impl-test module.
The documentation of this feature can be found here:

http://myfaces.staging.apache.org/wiki/core/user-guide/jsf-and-myfaces-howtos/unit-testing/setup-with-maven.html
http://myfaces.staging.apache.org/wiki/core/user-guide/jsf-and-myfaces-howtos/unit-testing/create-test-junit-runner.html

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.2.1 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-1005/org/apache/myfaces/
[2] http://www.apache.org/foundation/voting.html#ReleaseVotes
[3] http://people.apache.org/~lu4242/myfaces221binsrc
[4] 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12325868





-- 
Grant Smith - V.P. Information Technology
Marathon Computer Systems, LLC.

[jira] [Commented] (MYFACES-3863) Possible performance enchanchment in postback lifecycle processing

2014-03-02 Thread Mark Struberg (JIRA)

[
https://issues.apache.org/jira/browse/MYFACES-3863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13917788#comment-13917788
]

Mark Struberg commented on MYFACES-3863:

Agree with Leo. Usually the performance issues don't come from the JSF
container itself but from expensive calls to backing beans or tons of complex
EL expressions. I have really huge and pretty complex pages with 1600 rows in a
h:dataTable and they still render in below 200ms (for the whole page).
Try to use a profiler like YourKit and count the invocations to your backing
beans and you will be surprised. If those operations are dirt cheyp, then you
will not have much issue. If they operate against the db without using some
init in a preRenderView phase, then this might be the bummer.

Possible performance enchanchment in postback lifecycle processing
--

Key: MYFACES-3863
URL: https://issues.apache.org/jira/browse/MYFACES-3863
Project: MyFaces Core
Issue Type: Improvement
Reporter: Karl Trumstedt
Assignee: Leonardo Uribe
Priority: Minor

Hello,
I've been looking and reading a lot about JSF's lifecycle. I'm no expert in
any sense and have not fully grasped what happens in each phase.
I have debugged our application and seen how much time is spent in each
cycle. For larger pages it can be quite a lot (500 ms for each APPLY,
VALIDATION, UPDATE). Even for smaller pages there can be ~10-20ms in the
cycle when posting to the server. As far as I have gathered, the component
tree is traversed for each of these cycles. For us, every ms counts :)
Now, my application doesn't use the JSF validation framework. There isn't any
f:validator stuff anywhere. For me, I don't see that I need to execute that
phase, ever. So I would like to turn off that phase. But even better, maybe
when parsing the XHTML facelet (or constructing the view or something),
couldn't the UIViewRoot have information on if there are any f:validator
stuff on the page? If not, it could skip the validation phase completely?
As I said, I don't fully grasp what's happening behind the scenes so maybe
something else would stop working? And maybe the validation phase does more
the execute f:validator tags.
I realize this scenario might be special since we don't use the f:validator
stuff, we reuse our own legacy validation framework, but there still could be
pages in a regular JSF application with lots of components (big tables etc)
and no validation (or custom validation). Any pointers for how I could patch
and skip the validation phase myself would be nice:)
Thanks

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Re: [VOTE] release of MyFaces Core 2.1.15

2014-02-28 Thread Mark Struberg



+1

gpg fine, hash fine, rat fine, source-zip builds and checkstyle passes.

LieGrue,
strub


On Friday, 28 February 2014, 14:12, Paul Nicolucci pnico...@us.ibm.com wrote:

+1

Regards,

Paul Nicolucci

Leonardo Uribe ---02/27/2014 08:04:57 PM---Hi, I was running the needed tasks 
to get the 2.1.15 release of Apache


From: Leonardo Uribe lu4...@gmail.com
To: MyFaces Development dev@myfaces.apache.org, 
Date: 02/27/2014 08:04 PM
Subject: [VOTE] release of MyFaces Core 2.1.15






Hi,

I was running the needed tasks to get the 2.1.15 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.core v2.1.15  [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.1.15 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-1003/org/apache/myfaces/
[2] http://www.apache.org/foundation/voting.html#ReleaseVotes
[3] http://people.apache.org/~lu4242/myfaces2115binsrc
[4] 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12325870

Re: [VOTE] Release of Extensions CDI (CODI) 1.0.6

2014-02-28 Thread Mark Struberg

+1

source zip passes my quality criterias.

LieGrue,
strub





On Friday, 28 February 2014, 14:11, Hazem Saleh haz...@apache.org wrote:
 
+1



On Fri, Feb 28, 2014 at 2:29 PM, Gerhard Petracek gerhard.petra...@gmail.com 
wrote:

+1


regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2014-02-28 13:29 GMT+01:00 Gerhard Petracek gpetra...@apache.org:


Hi,


I was running the needed tasks to get the 13th 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.x)
 - CODI JPA Module
 - CODI BV Module
 - CODI I18N-Message Module
 - CODI Scripting Module
 - CODI Trinidad Support Module (for 1.x and 2.x)
 - CODI Java-EE5 Support Module (for OpenWebBeans and Weld)
 - CODI Bundles
 - CODI OSGi Bundles
 - 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 1.0.6 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-1004/
[2] 
https://repository.apache.org/content/repositories/orgapachemyfaces-1004/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/1.0.6/myfaces-extcdi-parent-1.0.6-source-release.zip
[3] http://www.apache.org/foundation/voting.html#ReleaseVotes




-- 

Hazem Saleh

Author of Pro JSF and HTML5 book:
http://www.amazon.com/Pro-JSF-HTML5-Building-Components/dp/1430250100/

Author of JavaScript Unit Testing book:
http://www.amazon.com/dp/1782160620/

Co-author of (The Definitive Guide to Apache MyFaces and Facelets) book:
http://www.amazon.com/-/e/B002M052KY

DeveloperWorks Contributing Author
https://www.ibm.com/developerworks/mydeveloperworks/blogs/hazem/entry/ibm_developerworks_contributing_author?lang=en_us

An Apache committer, IBMer, and a technical speaker

Twitter: http://www.twitter.com/hazems

Re: svn commit: r1547708 - /myfaces/myfaces-master-pom/trunk/pom.xml

2014-02-13 Thread Mark Struberg

hiho and welcome!

The most important (and authoritative) source is here:
http://people.apache.org/committers-by-project.html#myfaces


Leo should be able to update the myfaces page itself. But probably only happens 
after an official release.


LieGrue,
strub




On Thursday, 13 February 2014, 18:44, Paul Nicolucci pnico...@us.ibm.com 
wrote:
 
I recently became a committer and as my first commit I added myself to the 
developers section as recommended when I got commit rights.

However, I don't see this reflected on the webpage yet.  Is there another 
action I must take to have the site rebuilt?  Just trying to 
learn my way around and pick up any new processes.

Thanks,

Paul 

paulnicolucci---12/03/2013 11:50:50 PM---Author: paulnicolucci Date: Wed Dec  
4 04:50:21 2013

From: paulnicolu...@apache.org
To: comm...@myfaces.apache.org, 
Date: 12/03/2013 11:50 PM
Subject: svn commit: r1547708 - /myfaces/myfaces-master-pom/trunk/pom.xml





Author: paulnicolucci
Date: Wed Dec  4 04:50:21 2013
New Revision: 1547708

URL: http://svn.apache.org/r1547708
Log:
Fixing whitespaces

Modified:
   myfaces/myfaces-master-pom/trunk/pom.xml

Modified: myfaces/myfaces-master-pom/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/myfaces/myfaces-master-pom/trunk/pom.xml?rev=1547708r1=1547707r2=1547708view=diff
==
--- myfaces/myfaces-master-pom/trunk/pom.xml (original)
+++ myfaces/myfaces-master-pom/trunk/pom.xml Wed Dec  4 04:50:21 2013
@@ -547,17 +547,17 @@
            /roles
            timezone+1/timezone
        /developer
-   developer
-           idpaulnicolucci/id        
-           namePaul Nicolucci/name
-           emailpaulnicolu...@apache.org/email      
-           organizationIBM/organization      
-           organizationUrlhttp://www.ibm.com/organizationUrl           
-           roles
-              rolecommitter/role
-           /roles
-            timezone-5/timezone           
-        /developer        
+        developer
+            idpaulnicolucci/id
+            namePaul Nicolucci/name
+            emailpaulnicolu...@apache.org/email
+            organizationIBM/organization
+            organizationUrlhttp://www.ibm.com/organizationUrl
+            roles
+                rolecommitter/role
+            /roles
+            timezone-5/timezone
+        /developer
    /developers
    contributors
        contributor

Re: [VOTE] release of MyFaces Core 2.2.0

2014-01-10 Thread Mark Struberg

+1

LieGrue,
strub




- Original Message -
 From: Michael Kurz michi.k...@gmx.at
 To: dev@myfaces.apache.org
 Cc: 
 Sent: Friday, 10 January 2014, 7:37
 Subject: Re: [VOTE] release of MyFaces Core 2.2.0
 
 +1
 
 Am 09.01.2014 18:46, schrieb Grant Smith:
  +1
 
 
 
  On Thu, Jan 9, 2014 at 9:07 AM, Paul Nicolucci pnico...@us.ibm.com
  mailto:pnico...@us.ibm.com wrote:
 
      +1
 
      Regards,
 
      Paul Nicolucci
 
 
      Inactive hide details for Leonardo Uribe ---01/07/2014 11:00:23
      PM---Hi, I was running the needed tasks to get the 2.2.0
      releasLeonardo Uribe ---01/07/2014 11:00:23 PM---Hi, I was running
      the needed tasks to get the 2.2.0 release of Apache
 
      From: Leonardo Uribe lu4...@gmail.com 
 mailto:lu4...@gmail.com
      To: MyFaces Development dev@myfaces.apache.org
      mailto:dev@myfaces.apache.org,
 
      Date: 01/07/2014 11:00 PM
      Subject: [VOTE] release of MyFaces Core 2.2.0
 
     
 
 
 
 
      Hi,
 
      I was running the needed tasks to get the 2.2.0 release of Apache
      MyFaces core out.
 
      The artifacts passed the TCK test of Feb 2013
      (jsftck-2.2_26-Feb-2013.zip).
 
      Please note that this vote concerns all of the following parts:
      1. Maven artifact group org.apache.myfaces.shared v4.2.1  
 [1]
      2. Maven artifact group org.apache.myfaces.core v2.2.0  [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.2.0 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-018/org/apache/myfaces/
      [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
      [3] http://people.apache.org/~lu4242/myfaces220binsrc
      [4]
     
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316396
 
 
 
 
 
  --
  Grant Smith - V.P. Information Technology
  Marathon Computer Systems, LLC.

Re: [VOTE] release of MyFaces Core 2.0.20

2014-01-10 Thread Mark Struberg

+1

LieGrue,
strub





 From: Grant Smith gr...@marathonpm.com
To: MyFaces Development dev@myfaces.apache.org 
Sent: Thursday, 9 January 2014, 18:47
Subject: Re: [VOTE] release of MyFaces Core 2.0.20
 


+1



On Thu, Jan 9, 2014 at 9:07 AM, Paul Nicolucci pnico...@us.ibm.com wrote:

+1 

Regards,

Paul Nicolucci


Leonardo Uribe ---01/07/2014 10:58:13 PM---Hi, I was running the needed tasks 
to get the 2.0.20 release of Apache

From: Leonardo Uribe lu4...@gmail.com
To: MyFaces Development dev@myfaces.apache.org, 
Date: 01/07/2014 10:58 PM
Subject: [VOTE] release of MyFaces Core 2.0.20






Hi,

I was running the needed tasks to get the 2.0.20 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.20  [1]
2. Maven artifact group org.apache.myfaces.core v2.0.20  [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.20 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-016/org/apache/myfaces/
[2] http://www.apache.org/foundation/voting.html#ReleaseVotes
[3] http://people.apache.org/~lu4242/myfaces2020binsrc
[4] 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12325349






-- 
Grant Smith - V.P. Information Technology
Marathon Computer Systems, LLC.

adding jdk8 CI for MyFaces

2013-11-22 Thread Mark Struberg

Hi folks!

FYI: I will add a few CI jobs for Java8 (on arm).


This will help us to be prepared for the future ;)


LieGrue,
strub

Re: [VOTE] Release Tobago 1.5.11

2013-11-08 Thread Mark Struberg

+1

just quickly checked license stuff and this is fine.

LieGrue,
strub




- Original Message -
 From: Werner Punz werner.p...@gmail.com
 To: MyFaces Development dev@myfaces.apache.org
 Cc: 
 Sent: Friday, 8 November 2013, 15:21
 Subject: Re: [VOTE] Release Tobago 1.5.11
 
 +1
 
 
 Am 05.11.13 00:20, schrieb Udo Schnurpfeil:
  Hello,
 
  I would like to release Tobago 1.5.11.
 
  For a detail list please consult the release notes:
 
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273version=12324453
 
  The version is available at the staging repository (Nexus).
 
  Staging repository:
 
  https://repository.apache.org/content/repositories/orgapachemyfaces-071/
 
  The Vote is open for 72h.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  Regards,
 
  Udo

Re: [VOTE] release of MyFaces Core 2.1.13

2013-10-24 Thread Mark Struberg

+1

did a quick test on our app.

LieGrue,
strub




 From: Hazem Saleh haz...@apache.org
To: MyFaces Development dev@myfaces.apache.org 
Sent: Tuesday, 22 October 2013, 19:36
Subject: Re: [VOTE] release of MyFaces Core 2.1.13
 


+1



On Tue, Oct 22, 2013 at 6:46 PM, Leonardo Uribe lu4...@gmail.com wrote:

+1




2013/10/22 Leonardo Uribe lu4...@gmail.com

Hi,

I was running the needed tasks to get the 2.1.13 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.1.11  [1]
 2. Maven artifact group org.apache.myfaces.core v2.1.13  [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.1.13 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-015/org/apache/myfaces/
[2] http://www.apache.org/foundation/voting.html#ReleaseVotes
[3] http://people.apache.org/~lu4242/myfaces2113binsrc
[4] 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12324571





-- 

Hazem Saleh

Author of JavaScript Unit Testing book:
http://www.amazon.com/dp/1782160620/

Co-author of (The Definitive Guide to Apache MyFaces and Facelets) book:
http://www.amazon.com/-/e/B002M052KY

DeveloperWorks Contributing Author
https://www.ibm.com/developerworks/mydeveloperworks/blogs/hazem/entry/ibm_developerworks_contributing_author?lang=en_us

An Apache committer, IBMer, and a technical speaker

Twitter: http://www.twitter.com/hazems

Re: [VOTE] release of MyFaces Core 2.0.19

2013-10-24 Thread Mark Struberg

+1

did no tests :( but license and other stuff looks ok.

LieGrue,
strub





 From: Werner Punz werner.p...@gmail.com
To: MyFaces Development dev@myfaces.apache.org 
Sent: Tuesday, 22 October 2013, 20:55
Subject: Re: [VOTE] release of MyFaces Core 2.0.19
 

+1


Am 22.10.13 18:43, schrieb Leonardo Uribe:
 Hi,

 I was running the needed tasks to get the 2.0.19 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.19  [1]
   2. Maven artifact group org.apache.myfaces.core v2.0.19  [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.19 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-013/org/apache/myfaces/
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
 [3] http://people.apache.org/~lu4242/myfaces2019binsrc
 [4]
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12324287

Re: [VOTE] svn-keywords and @author tags

2013-10-15 Thread Mark Struberg



+1


All the 'hard facts' (means who committed what and when) are in our SCM anyway.
Noone need to fear that his merrit vanishes only because we remove the @author 
tags. People know exactly who does the vast majority of the work - so it's also 
time to say txs to Leo and all other passionate MyFaces hackers for putting so 
much heart into it :)


LieGrue,
strub


 From: Matthias Wessendorf mat...@apache.org
To: MyFaces Development dev@myfaces.apache.org 
Sent: Monday, 14 October 2013, 17:20
Subject: Re: [VOTE] svn-keywords and @author tags
 


+1 
On Oct 14, 2013 3:46 PM, Gerhard Petracek gpetra...@apache.org wrote:

hi @ all,


we already had a discussion as well as an agreement about it (starting point: 
[1]). in several modules the cleanup is finished.
however, since we still have (even new) parts which contain svn-keywords 
and/or @author tags, i start this formal vote.


please vote with


-
[ ] +1 for: stop using svn-keywords and @author tags (+ remove the remaining)
[ ] +0
[ ] -1 for: we should keep svn-keywords and @author tags
-


regards,
gerhard


[1] http://s.apache.org/ZtS

Re: [VOTE] release of MyFaces Core 2.0.18

2013-06-01 Thread Mark Struberg

+1

LieGrue,
strub




- Original Message -
 From: Leonardo Uribe lu4...@gmail.com
 To: MyFaces Development dev@myfaces.apache.org
 Cc: 
 Sent: Wednesday, 29 May 2013, 20:52
 Subject: [VOTE] release of MyFaces Core 2.0.18
 
 Hi,
 
 I was running the needed tasks to get the 2.0.18 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.18  [1]
 2. Maven artifact group org.apache.myfaces.core v2.0.18  [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.18 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-027/org/apache/myfaces/
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
 [3] http://people.apache.org/~lu4242/myfaces2018binsrc
 [4] 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12324287

Re: [VOTE] release of MyFaces Core 2.1.12

2013-06-01 Thread Mark Struberg

+1

LieGrue,
strub




- Original Message -
 From: Leonardo Uribe lu4...@gmail.com
 To: MyFaces Development dev@myfaces.apache.org
 Cc: 
 Sent: Wednesday, 29 May 2013, 20:53
 Subject: [VOTE] release of MyFaces Core 2.1.12
 
 Hi,
 
 I was running the needed tasks to get the 2.1.12 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.1.10  [1]
 2. Maven artifact group org.apache.myfaces.core v2.1.12  [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.1.12 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-029/org/apache/myfaces/
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
 [3] http://people.apache.org/~lu4242/myfaces2112binsrc
 [4] 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12324285

Re: [VOTE] Release Tobago 1.5.10

2013-05-25 Thread Mark Struberg

rat is fine, licenses are ok, key is fine, source builds locally.

Side note: You currently ship an examples WAR file which contains quite some
binaries in WEB-INF/lib. Some of them are MPL (javassist) thus you might need a
NOTICE file in your sample. We had the same issue in OWB and we solved this by
not shipping the samples as WAR binaries at all. Users can still build it
themselfs but we don't ship any WARs anymore.

It's not a blocker right now, but those WAR files are most times useless for
users and just fill up the repo anyway. Imo it's not worth the hassle to
include them in the distribution and my suggestion is to just configure the
maven-deploy-plugin to skip deployment for the samples. I'm not 100% sure about
the license of jsf-facelets-1.1.14.jar and if you need this at all. I'd rather
remove it from the dependencies, or does your sample still target JSF 2.0?

LieGrue,
strub

- Original Message -
From: Werner Punz werner.p...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Cc:
Sent: Friday, 24 May 2013, 22:56
Subject: Re: [VOTE] Release Tobago 1.5.10

Werner

Am 24.05.13 13:52, schrieb Bernd Bohmann:
Hello,

I would like to release Tobago 1.5.10

For a detail list please consult the release notes:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273version=12324008

The version is available at the nexus staging repository.

Staging repository:

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

The Vote is open for 72h.

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

Regards

Bernd

Re: Wiki Spam

2013-04-20 Thread Mark Struberg

go for it, Mike!

txs and LieGrue,
strub




- Original Message -
 From: Mike Kienenberger mkien...@gmail.com
 To: MyFaces Development dev@myfaces.apache.org
 Cc: 
 Sent: Friday, 19 April 2013, 22:28
 Subject: Re: Wiki Spam
 
 As soon as we have a concensus that we want to enable
 AdminGroup/ContributorsGroup, I'll do whatever needs to be done if no
 one else is available to make the change.
 
 Looks like http://wiki.apache.org/general/HowToBeWikiAdministrator
 contains the information necessary without needing to go through
 infra.
 
 On Fri, Apr 19, 2013 at 4:19 PM, Mike Kienenberger mkien...@gmail.com 
 wrote:
  My recommendation is that we set up an AdminGroup, probably with all
  committers in it.
 
  Then we add additional people to the ContributorsGroup as desired.
 
 
  http://wiki.apache.org/general/WikiFrequentlyAskedQuestions
 
  http://wiki.apache.org/general/OurWikiFarm
  =
  per wiki access control - tighten your wiki just a little, benefit just a 
 lot
 
  Long sub-title for a fairly long subject.
 
  The MoinMoin wiki is very configurable, more so than some might think.
  Of course, wikis are meant to be open, for complete and utter open
  collaboration. That is appreciated. However, there are some that would
  like a balance between open wiki and having to spend time cleaning up
  spam each week. Times change, and the reality is, spammers are here
  and in greater numbers than before. What can we do? Well, here is a
  suggestion - and one that can be easily implemented and takes but 2
  minutes (for infra) to set up.
 
  Have your project wiki editable only by a custom trusted group - that
  need not be committers only - it can in fact still be anybody who
  wants to edit your wiki, they just need to ask one time for edit
  access and thats it. Is this an incovenience? To ask once for access,
  I don't think so. After all as a potential contributor to your wiki
  you (project) will already be conversing with the potential
  contributor via the mailing lists right? How much pain is it to add
  someone to the custom trusted group once it has been set up? , no pain
  at all, a member of the projects AdminGroup edits one wiki page, adds
  the users WikiuserName to the bottom of the list and save the page! 10
  seconds maybe and your done. For the amount of times you will have to
  do that as opposed to the amount of times you spend cleaning up spam -
  you work out which is better.
 
  The spamassassin wiki is a good example - those in the project wikis
  AdminGroup can add folks to the projects ContributorsGroup and that's
  it. How much spam has spamassassin received since this was setup ?
  Zero, Zilch, Nil, Nada.
 
  Remember also, any page can have its own access control which
  overrides and per wiki and per farm defaults - This page does just
  that, as does LocalBadContent and BadContent pages.
  =
 
 
 
  On Fri, Apr 19, 2013 at 3:47 PM, Mike Kienenberger 
 mkien...@gmail.com wrote:
  Probably it's time to enable some kind of protection for the wiki.
 
  I've been hoping to avoid that, but the amount of spam the past two
  weeks has finally exceeded my willingness to continue fixing by hand.
 
  Is anyone who is subscribed to infrastructure willing to look into
  this?   If no takers, I guess I'll sign up and see what can be 
 done.
 
 
  On Fri, Apr 19, 2013 at 3:41 PM, Cagatay Civici
  cagatay.civ...@gmail.com wrote:
  Hi,
 
  Does anyone know how can I unsubscribe from wiki as it is full of 
 spam
  everyday.
 
  Thanks,
 
  Cagatay Civici
  PrimeFaces Lead
  www.primefaces.org

Re: [VOTE] release of MyFaces Core 2.0.17

2013-03-30 Thread Mark Struberg

+1

LieGrue,
strub




- Original Message -
 From: Leonardo Uribe lu4...@gmail.com
 To: MyFaces Development dev@myfaces.apache.org
 Cc: 
 Sent: Thursday, March 28, 2013 5:40 PM
 Subject: [VOTE] release of MyFaces Core 2.0.17
 
 Hi,
 
 I was running the needed tasks to get the 2.0.17 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.17  [1]
 2. Maven artifact group org.apache.myfaces.core v2.0.17  [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.17 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-028/org/apache/myfaces/
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
 [3] http://people.apache.org/~lu4242/myfaces2017binsrc
 [4] 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12323554

Re: [VOTE] release of MyFaces Core 2.1.11

2013-03-30 Thread Mark Struberg

+1

LieGrue,
strub




- Original Message -
 From: Leonardo Uribe lu4...@gmail.com
 To: MyFaces Development dev@myfaces.apache.org
 Cc: 
 Sent: Thursday, March 28, 2013 5:41 PM
 Subject: [VOTE] release of MyFaces Core 2.1.11
 
 Hi,
 
 I was running the needed tasks to get the 2.1.11 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.1.9  [1]
 2. Maven artifact group org.apache.myfaces.core v2.1.11  [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.1.11 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-029/org/apache/myfaces/
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
 [3] http://people.apache.org/~lu4242/myfaces2111binsrc
 [4] 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12323553

Re: wiki spammers

2013-03-13 Thread Mark Struberg

+1 it's a real pain atm. We should switch to CMS and/or disable wiki access for 
all non-asf committers.

LieGrue,
strub




- Original Message -
 From: Mike Kienenberger mkien...@gmail.com
 To: MyFaces Development dev@myfaces.apache.org
 Cc: 
 Sent: Tuesday, March 12, 2013 7:31 PM
 Subject: wiki spammers
 
 On Tue, Mar 12, 2013 at 2:27 PM, Matt Cooper mcoo...@apache.org wrote:
  Maybe we just need to ask the spammers who keep adding pages to our wiki ;)
 
 Speaking of which, is someone who's subscribed to infra willing to ask
 about disabling wiki home pages?
 99% of our spam comes from wiki home page creation, which we don't use.

Re: [core][discuss] Is it worth to include Stateless JSF / View Pooling concept into MyFaces?

2013-02-08 Thread Mark Struberg

-0.2 it is imo not really worth it. The benefits are just too small, and the 
complexity is too high.

LieGrue,
strub








 From: Thomas Andraschko andraschko.tho...@gmail.com
To: MyFaces Development dev@myfaces.apache.org 
Sent: Friday, February 8, 2013 6:31 PM
Subject: Re: [core][discuss] Is it worth to include Stateless JSF / View 
Pooling concept into MyFaces?
 

+0 from my side.
Hacking third party libraries is actually a no-go.


2013/2/5 Leonardo Uribe lu4...@gmail.com

Hi

2013/2/5 Thomas Andraschko andraschko.tho...@gmail.com:

 Hi,

 from the performance perspective, it's a great feature. 8% and more are
 really much.
 On the other hand, i thought it would be more improvement (like 15-20%).


That's the point. It is because the previous improvements done that the
difference now is only 8%.


 I don't know about the maintenance effort, maybe it would be better to
 search optimizations in other places.


In this moment we have exhausted almost all the possibilities. We can
always improve the code, but in my opinion the gain if possible will be
very small (less than 1% or 2%).

From maintenance perspective, the problem is that the hack requires some
changes in the component classes (specifically give the ability to reset
the state). So, it is necessary to change third party libraries to make it
work, and at the end the scope of the technique will be limited.

Is maintenance a problem? in my opinion only if there is enough people
interested in use the code proposed.

regards,

Leonardo Uribe

 Regards,
 Thomas

[jira] [Resolved] (EXTCDI-305) review validation of EXTCDI-265

2013-01-31 Thread Mark Struberg (JIRA)


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

Mark Struberg resolved EXTCDI-305.
--

   Resolution: Fixed
Fix Version/s: 1.0.6

The check will now only be done for EntityManagers

 review validation of EXTCDI-265
 ---

 Key: EXTCDI-305
 URL: https://issues.apache.org/jira/browse/EXTCDI-305
 Project: MyFaces CODI
  Issue Type: Bug
  Components: JEE-JPA1-Module
Affects Versions: 1.0.5
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 1.0.6

 Attachments: OWB-305.patch


 CODI-1.0.5 added a 'validation' for qualifiers of the bean. In fact this is 
 too strict. This only makes sense for injected EntityManagers, but not if you 
 like to store information which has nothing to do with EntityManagers. 
 In our case we e.g. like to track information we collect via @PostUpdate JPA 
 EntityListeners and evaluate them in the @PreDestroy of an @TransactionScoped 
 bean. This is *explicitely* default scoped and not assigned to any special 
 EntityManager!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[DISCUSS] new CODI release?

2013-01-30 Thread Mark Struberg

Hi folks!

I'm tempted to release a new version of CODI. There are a few bugs in the chain 
which would be nice to ship.
If there is no objection, then I'd start with the release task sunday-ish...


txs and LieGrue,
strub

[jira] [Created] (EXTCDI-305) review validation of EXTCDI-265

2013-01-29 Thread Mark Struberg (JIRA)

Mark Struberg created EXTCDI-305:


 Summary: review validation of EXTCDI-265
 Key: EXTCDI-305
 URL: https://issues.apache.org/jira/browse/EXTCDI-305
 Project: MyFaces CODI
  Issue Type: Bug
  Components: JEE-JPA1-Module
Affects Versions: 1.0.5
Reporter: Mark Struberg
Assignee: Mark Struberg


CODI-1.0.5 added a 'validation' for qualifiers of the bean. In fact this is too 
strict. This only makes sense for injected EntityManagers, but not if you like 
to store information which has nothing to do with EntityManagers. 
In our case we e.g. like to track information we collect via @PostUpdate JPA 
EntityListeners and evaluate them in the @PreDestroy of an @TransactionScoped 
bean. This is *explicitely* default scoped and not assigned to any special 
EntityManager!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Release of Apache MyFaces Extension Scripting 1.0.5

2012-12-08 Thread Mark Struberg

+1

LieGrue,
strub




- Original Message -
 From: Werner Punz werner.p...@gmail.com
 To: MyFaces Development dev@myfaces.apache.org
 Cc: 
 Sent: Thursday, December 6, 2012 2:51 PM
 Subject: Re: [VOTE] Release of Apache MyFaces Extension Scripting 1.0.5
 
 +1
 
 
 
 
 Am 06.12.12 14:42, schrieb Werner Punz:
  Hello Everyone:
 
  I was running the needed tasks to get the 1.0.5 release of Apache
  MyFaces Extension Scripting out.
 
  This release is a bugfix and improvement release, it introduces Spring
  support and adds JRuby support.
 
  The artifacts are deployed to Nexus [1] [2].
 
  Release Notes:
 
 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310964version=12323447
 
 
 
  Please take a look at the 1.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,
  Werner
 
  [1]
 
 https://repository.apache.org/content/repositories/orgapachemyfaces-119/org/apache/myfaces/extensions/scripting/
 
 
  [2]
 
 https://repository.apache.org/content/repositories/orgapachemyfaces-119/org/apache/myfaces/extensions/scripting/extscript-root/1.0.5/extscript-root-1.0.5-source-release.zip
 
 
  [3] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: AW: Re: Re: Regression between myfaces-extval-core and primefaces: System-Event-Listeners are called too late.

2012-12-07 Thread Mark Struberg

What I meant is f:validateBean disabled=#{yourElExpression}

I e.g. use this when I need open a search dialogue in a new window. Most people 
use immediate=true for that but that has the nasty side effect that you loose 
all the entered value in the other fields of your dialogue. A conditional 
validateBean works great for that.

LieGrue,
strub








 From: it-media.k...@daimler.com it-media.k...@daimler.com
To: dev@myfaces.apache.org 
Sent: Friday, December 7, 2012 8:15 AM
Subject: Re: AW: Re: Re: Regression between myfaces-extval-core and 
primefaces: System-Event-Listeners are called too late.
 


Hello,

thanks for your reply. I do not want
to disable validation completely, just prevent client side behavior (if
thats possible). 

Heiko




strub...@yahoo.de 
07.12.2012 08:10
Bitte antworten an
dev@myfaces.apache.org 
 An dev@myfaces.apache.org 
Kopie  
Thema AW: Re: Re: Regression between myfaces-extval-core
and primefaces: System-Event-Listeners are called too late. 
  
 



maybe try disabling the block with f:validateBean?


--
it-media.k...@daimler.com schrieb am Do., 6. Dez 2012 21:53 PST:

Hello Gerhard,

I will do so. I tried a very simple example just yet, but this does
not 
show the issue. I've a feeling that I need to add at last some bean 
validation annotations to a used bean in the view to trigger the extval 
proxy to do its work. My assumtion is that extval tries to parse the
page 
to include maybe client side validation parts and does so before any 
system event handlers have been initialized.

I'll head back to you with a link for an example.

Just because I'm curious, is there a configuration option to temporarily 
disable any client side validation?

Best regards,

Heiko




gerhard.petra...@gmail.com 
06.12.2012 10:47
Bitte antworten an
dev@myfaces.apache.org


An
dev@myfaces.apache.org
Kopie

Thema
Re: Regression between myfaces-extval-core and primefaces: 
System-Event-Listeners are called too late.






hi heiko,

it would be great if you can provide a link to a small example which 
illustrates the issue.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/12/6 it-media.k...@daimler.com

Hello,

We have come across an issue that occurs in the combination of 
myfaces-extval and primefaces.

We use the following configuration:

myfaces-extcdi-bundle-jsf20 (1.0.6)
myfaces-extval-core (2.0.6)
myfaces-extval-bean-validation (2.0.6)
myfaces-extval-property-validation (2.0.6)
primefaces-3.5 (revision 8433)

The new primefaces uses a JSF System-Event-Listener to register a widget 
builder in the context. 

system-event-listener
    source-classjavax.faces.component.UIViewRoot/source-class
    
system-event-classjavax.faces.event.PreRenderViewEvent/system-event-class
    
system-event-listener-classorg.primefaces.webapp.PreRenderViewListener/system-event-listener-class
/system-event-listener 

with the following content:

public class PreRenderViewListener implements SystemEventListener {
    public boolean isListenerForSource(Object source) {
        return true;
    }

    public void processEvent(SystemEvent event) throws 
AbortProcessingException {
        
FacesContext.getCurrentInstance().getAttributes().put(Constants.WIDGET_BUILDER_ATTR,
 
new WidgetBuilder());
    }
}

However, this system event listener seems to be called too late, as
the 
ExtValLazyRendererProxy tries to encode components first. This leads
to an 
exception at application start:

java.lang.NullPointerException
at 
org.primefaces.component.dialog.DialogRenderer.encodeScript(DialogRenderer.java:51)
at 
org.primefaces.component.dialog.DialogRenderer.encodeEnd(DialogRenderer.java:43)
at 
org.apache.myfaces.extensions.validator.core.renderkit.ExtValLazyRendererProxy.encodeEnd(ExtValLazyRendererProxy.java:76)
at 
org.apache.myfaces.extensions.validator.core.renderkit.ExtValRendererWrapper.encodeEnd(ExtValRendererWrapper.java:358)
at 
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:535)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:626)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:622)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:622)
at 
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1320)
at 
org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:263)
at 
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
at 
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
at 
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:85)


Primefaces rejected this an an error in their code. Is there a way
that 
within myfaces-extval-core, it can be made sure that system event 
listeners

AW: Re: Re: Regression between myfaces-extval-core and primefaces: System-Event-Listeners are called too late.

2012-12-06 Thread Mark Struberg


maybe try disabling the block with f:validateBean?


--
it-media.k...@daimler.com schrieb am Do., 6. Dez 2012 21:53 PST:

Hello Gerhard,

I will do so. I tried a very simple example just yet, but this does not 
show the issue. I've a feeling that I need to add at last some bean 
validation annotations to a used bean in the view to trigger the extval 
proxy to do its work. My assumtion is that extval tries to parse the page 
to include maybe client side validation parts and does so before any 
system event handlers have been initialized.

I'll head back to you with a link for an example.

Just because I'm curious, is there a configuration option to temporarily 
disable any client side validation?

Best regards,

Heiko




gerhard.petra...@gmail.com 
06.12.2012 10:47
Bitte antworten an
dev@myfaces.apache.org


An
dev@myfaces.apache.org
Kopie

Thema
Re: Regression between myfaces-extval-core and primefaces: 
System-Event-Listeners are called too late.






hi heiko,

it would be great if you can provide a link to a small example which 
illustrates the issue.

regards,
gerhard

http://www.irian.at

Your JSF/JavaEE powerhouse -
JavaEE Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces



2012/12/6 it-media.k...@daimler.com

Hello,

We have come across an issue that occurs in the combination of 
myfaces-extval and primefaces.

We use the following configuration:

myfaces-extcdi-bundle-jsf20 (1.0.6)
myfaces-extval-core (2.0.6)
myfaces-extval-bean-validation (2.0.6)
myfaces-extval-property-validation (2.0.6)
primefaces-3.5 (revision 8433)

The new primefaces uses a JSF System-Event-Listener to register a widget 
builder in the context. 

system-event-listener
source-classjavax.faces.component.UIViewRoot/source-class

system-event-classjavax.faces.event.PreRenderViewEvent/system-event-class

system-event-listener-classorg.primefaces.webapp.PreRenderViewListener/system-event-listener-class
/system-event-listener 

with the following content:

public class PreRenderViewListener implements SystemEventListener {
public boolean isListenerForSource(Object source) {
return true;
}

public void processEvent(SystemEvent event) throws 
AbortProcessingException {

FacesContext.getCurrentInstance().getAttributes().put(Constants.WIDGET_BUILDER_ATTR,
 
new WidgetBuilder());
}
}

However, this system event listener seems to be called too late, as the 
ExtValLazyRendererProxy tries to encode components first. This leads to an 
exception at application start:

java.lang.NullPointerException
at 
org.primefaces.component.dialog.DialogRenderer.encodeScript(DialogRenderer.java:51)
at 
org.primefaces.component.dialog.DialogRenderer.encodeEnd(DialogRenderer.java:43)
at 
org.apache.myfaces.extensions.validator.core.renderkit.ExtValLazyRendererProxy.encodeEnd(ExtValLazyRendererProxy.java:76)
at 
org.apache.myfaces.extensions.validator.core.renderkit.ExtValRendererWrapper.encodeEnd(ExtValRendererWrapper.java:358)
at 
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:535)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:626)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:622)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:622)
at 
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1320)
at 
org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:263)
at 
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
at 
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
at 
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:85)


Primefaces rejected this an an error in their code. Is there a way that 
within myfaces-extval-core, it can be made sure that system event 
listeners are called before the lazy renderer starts its work?

Thank you very much for your help,

Best regards,

Heiko

If you are not the intended addressee, please inform us immediately that 
you have received this e-mail in error, and delete it. We thank you for 
your cooperation. 



If you are not the intended addressee, please inform us immediately that you 
have received this e-mail in error, and delete it. We thank you for your 
cooperation.  dis

Re: [VOTE][core] fix for MYFACES-3586 (performance of resources in jar files served by ResourceHandlerImpl)

2012-11-30 Thread Mark Struberg



+1

LieGrue,
strub






 From: Leonardo Uribe lu4...@gmail.com
To: MyFaces Development dev@myfaces.apache.org 
Sent: Friday, November 30, 2012 6:47 PM
Subject: Re: [VOTE][core] fix for MYFACES-3586 (performance of resources in 
jar files served by ResourceHandlerImpl)
 
Hi

Just to remember this vote is still active. There is interest in fix
MYFACES-3586, but without the minimun 3 +1 votes, according to
the rules I can't propose a possible patch.

regards

Leonardo Uribe

2012/11/28 Leonardo Uribe lu4...@gmail.com:
 Hi

 This vote is only for fix the performance problem over the
 default ResourceHandlerImpl bundled in MyFaces Core. The
 idea is create a temporal folder and uncompress the resources
 there. Also, adopt the idea of use a soft reference map to avoid
 read the file, but that memory cache needs some rules.

 In theory, nothing has happened in JSF 2.2, but Jakob, should
 know that better than me (I don't see any changes on the spec
 for this part).

 I know there are more problems and tha a full solution for
 ResourceHandler stuff is use only RESTful URLs, but that's for
 another discussion. We need a proposal and check point by point
 what to do, but that's for another discussion. If you want to start
 the discussion, please do it but in another mail, because it is a
 different topic.

 EL expressions inside css files are considered application-scoped,
 which means once evaluated they never change. It is not a problem
 for the cache here. The solution proposed is feasible, but it cannot
 be enabled by default.

 Please vote +1, +0 or -1 over provide a fix for MYFACES-3586 inside
 MyFaces Core.

 regards,

 Leonardo Uribe

 2012/11/28 Mark Struberg strub...@yahoo.de:
 The only _real_ solution is to not use the JSF specced resource handling 
 and instead only use RESTful URLs.
 Since JSF resources may contain EL expressions, they are _not_ cacheable. 
 We currently deliver them with a expiry of 14 days, but this is actually 
 wrong! The RI has the same bug, so it's at least broken in the same way ;)

 To shed more light on the topic you should also quote the original thread 
 about Jakobs RelativeResourceHandler.

 http://markmail.org/thread/glr356g45uta5yys

 This contains all the really important discussions.
 Jakob continued his project over at google code [1]


 Fazit:
 * We must NOT cache for JSF spec compliant resource handling because the EL 
 inside CSS, etc can change for _every_ request.

 * If we like to have a fully cacheable solution, then we should finally go 
 a step back and again remove all the superfluous stuff added to 
 commons-resourcehandler and do it cleanly.

 We might scan the resources for '#{' but that might become expensive as 
 well.
 There was some proposal for JSF-2.2, do you have an update what happened 
 with that?



 LieGrue,
 strub



 [1] http://code.google.com/a/apache-extras.org/p/relative-resource-handler/


 - Original Message -
 From: Werner Punz werner.p...@gmail.com
 To: MyFaces Development dev@myfaces.apache.org
 Cc:
 Sent: Wednesday, November 28, 2012 9:39 AM
 Subject: Re: [VOTE][core] fix for MYFACES-3586 (performance of resources 
 in jar files served by ResourceHandlerImpl)

 +1
 I have had similar situations and people definitely need a fix this has
 higher priority than having no new config params.


 Werner


 Am 27.11.12 16:56, schrieb Leonardo Uribe:
  +1, if there are people with interest to get a problem solved,
        it's worth a shot to hear what people says and get it done.


  2012/11/27 Leonardo Uribe lu4...@gmail.com:
  Hi

  Some time ago, it was mentioned the controversy behind a fix
  for MYFACES-3586


 http://markmail.org/message/xycbf77ku7x5wygj#query:+page:1+mid:jhmcr6a435xma3lu+state:results

  Maybe we should reconsider the previous position about this
  one and try to fix it, even if that means to include additional web
  config params, even if exists better solutions for this one or
  even if suppose more work to do.

  The reason why we should change our position is users start to
  fall on the same hole over and over again. Given the interest on
  the problem, it starts to sound better to provide an alternate fix
  bundled in myfaces core instead say to the people ... setup a
  load balancer in front of your server and cache the resources
  there to fix your problem 

  Things become a ridiculousness, when you find a similar problem:

  https://issues.apache.org/jira/browse/MYFACES-3656
  ViewScoped bean fails when SERIALIZE_STATE_IN_SESSION is set to true

  Both problems are similar because:

  1. Both problems has a known solution.
  2. The solution is not perfect / cannot be enabled by default / there
 are
       better alternatives
  3. The typical answer is say ... woops ... try this alternative
 strategy and
       try to live with the problem ...

  Given the latest feedback about MYFACES-3586 and MYFACES-3656,
  I think it is desirable to take a look and revote

Re: [VOTE][core] fix for MYFACES-3586 (performance of resources in jar files served by ResourceHandlerImpl)

2012-11-28 Thread Mark Struberg

The only _real_ solution is to not use the JSF specced resource handling and
instead only use RESTful URLs.
Since JSF resources may contain EL expressions, they are _not_ cacheable. We
currently deliver them with a expiry of 14 days, but this is actually wrong!
The RI has the same bug, so it's at least broken in the same way ;)

To shed more light on the topic you should also quote the original thread about
Jakobs RelativeResourceHandler.

http://markmail.org/thread/glr356g45uta5yys

This contains all the really important discussions.
Jakob continued his project over at google code [1]

Fazit:
* We must NOT cache for JSF spec compliant resource handling because the EL
inside CSS, etc can change for _every_ request.

* If we like to have a fully cacheable solution, then we should finally go a
step back and again remove all the superfluous stuff added to
commons-resourcehandler and do it cleanly.

We might scan the resources for '#{' but that might become expensive as well.
There was some proposal for JSF-2.2, do you have an update what happened with
that?

LieGrue,
strub

[1] http://code.google.com/a/apache-extras.org/p/relative-resource-handler/

- Original Message -
From: Werner Punz werner.p...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Cc:
Sent: Wednesday, November 28, 2012 9:39 AM
Subject: Re: [VOTE][core] fix for MYFACES-3586 (performance of resources in
jar files served by ResourceHandlerImpl)

+1
I have had similar situations and people definitely need a fix this has
higher priority than having no new config params.

Werner

Am 27.11.12 16:56, schrieb Leonardo Uribe:
+1, if there are people with interest to get a problem solved,
it's worth a shot to hear what people says and get it done.

2012/11/27 Leonardo Uribe lu4...@gmail.com:
Hi

Some time ago, it was mentioned the controversy behind a fix
for MYFACES-3586

http://markmail.org/message/xycbf77ku7x5wygj#query:+page:1+mid:jhmcr6a435xma3lu+state:results

Maybe we should reconsider the previous position about this
one and try to fix it, even if that means to include additional web
config params, even if exists better solutions for this one or
even if suppose more work to do.

The reason why we should change our position is users start to
fall on the same hole over and over again. Given the interest on
the problem, it starts to sound better to provide an alternate fix
bundled in myfaces core instead say to the people ... setup a
load balancer in front of your server and cache the resources
there to fix your problem

Things become a ridiculousness, when you find a similar problem:

https://issues.apache.org/jira/browse/MYFACES-3656
ViewScoped bean fails when SERIALIZE_STATE_IN_SESSION is set to true

Both problems are similar because:

1. Both problems has a known solution.
2. The solution is not perfect / cannot be enabled by default / there
are
better alternatives
3. The typical answer is say ... woops ... try this alternative
strategy and
try to live with the problem ...

Given the latest feedback about MYFACES-3586 and MYFACES-3656,
I think it is desirable to take a look and revote a solution to this
problem
again.

Please vote:

+1 if you consider we need to fix this one once for all.
+0 if you don't care about
-1 if you consider do nothing is better and why

Note we need minimum 3 +1 votes to support this initiative and override
the previous decision of the community.

regards,

Leonardo Uribe

Re: Result (was: Re: [VOTE] Release of Extensions Validator 1.2.6 and 2.0.6)

2012-11-28 Thread Mark Struberg



count me in for another +1 ;)
Sorry that I missed the eot, pretty busy around here...


LieGrue,
strub




 From: Gerhard Petracek gpetra...@apache.org
To: dev@myfaces.apache.org 
Sent: Wednesday, November 28, 2012 7:49 PM
Subject: Result (was: Re: [VOTE] Release of Extensions Validator 1.2.6 and 
2.0.6)
 

thank you for voting!


3 binding +1 votes (pmc):
 - Grant Smith
 - Werner Punz
 - Gerhard Petracek


2 non-binding +1 votes:
 - Hazem Saleh
 - Thomas Andraschko


no -1 votes


regards,
gerhard




2012/11/25 Gerhard Petracek gpetra...@apache.org

Hi,


I was running the needed tasks to get the 6th release of Apache MyFaces 
Extensions Validator out.
The artifacts are deployed to Nexus [1].


These 2 releases contain the following modules for JSF 1.2, JSF 2.x:
 - ExtVal Core
 - ExtVal Property-Validation
 - ExtVal Bean-Validation (Integration + additional features for using JSR 
303 with JSF 1.2 and 2.x)
 - Trinidad-Support-Module
 - Generic-Support-Module


Please take a look at the 1.2.6 and 2.0.6 artifacts and vote!


Please note:
This vote is majority approval with a minimum of three +1 votes (see [2]).



[ ] +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-071/org/apache/myfaces/extensions/validator/
[2] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: [VOTE] release of MyFaces Core 2.0.16

2012-11-23 Thread Mark Struberg

+1

LieGrue,
strub




- Original Message -
 From: Leonardo Uribe lu4...@apache.org
 To: MyFaces Development dev@myfaces.apache.org
 Cc: 
 Sent: Wednesday, November 21, 2012 1:11 AM
 Subject: [VOTE] release of MyFaces Core 2.0.16
 
 Hi,
 
 I was running the needed tasks to get the 2.0.16 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.core v2.0.16  [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.16 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-049/org/apache/myfaces/
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
 [3] http://people.apache.org/~lu4242/myfaces2016binsrc
 [4] 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12323261

Re: [VOTE] release of MyFaces Core 2.1.10

2012-11-23 Thread Mark Struberg

+1

LieGrue,
strub




- Original Message -
 From: Leonardo Uribe lu4...@apache.org
 To: MyFaces Development dev@myfaces.apache.org
 Cc: 
 Sent: Wednesday, November 21, 2012 1:13 AM
 Subject: [VOTE] release of MyFaces Core 2.1.10
 
 Hi,
 
 I was running the needed tasks to get the 2.1.10 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.core v2.1.10  [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.1.10 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-050/org/apache/myfaces/
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
 [3] http://people.apache.org/~lu4242/myfaces2110binsrc
 [4] 
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12323259

CI Job for myfaces-2.2.x branch?

2012-11-23 Thread Mark Struberg

Hi folks!

Who is setting this up? 

If you point me to a job I can copy then I can also handle it.

LieGrue,
strub

Re: [VOTE] [RESULT] switching MyFaces-2.0.x to maintenance mode

2012-11-23 Thread Mark Struberg


 [+1] move MyFaces-2.0.x into maintenance mode

The VOTE succeeded with the following +1: Mark Struberg, Mike Kienenberger, Leo 
Uribe, Grant Smith, Hazem Saleh, Gerhard Petracek, Werner Punz.



MyFaces-2.0.x will be switched in to maintenance mode which means that we will 
only touch it for fixing blockers and security vulnerabilities.

LieGrue,
strub






- Original Message -
 From: Mark Struberg strub...@yahoo.de
 To: My Faces Development dev@myfaces.apache.org
 Cc: 
 Sent: Friday, November 16, 2012 8:25 AM
 Subject: [VOTE] switching MyFaces-2.0.x to maintenance mode
 
T he JSF-2.0 spec came out in early 2009. There is a clarification/bugfix 
release 
 2.1 of the spec available since over 2 years now and we actively maintain 
 MyFaces-2.1.x
 
 Thus I like to suggest moving MyFaces-2.0.x into maintenance mode. 
 
 It's purely crazy that we backport any change from 2.1.x to 2.0.x still. 
 This is perfectly fine for heavy bugs of course, but not for new enhancements 
 and 'featuers'. As we've seen recently this introduces bugs which 
 are avoidable.
 
 Maintenance mode means that we will fix blockers and security vulnerabilities 
 like we still do in 1.x if required. But we will not do any further 
 development.
 
 
 
 [+1] move MyFaces-2.0.x into maintenance mode
 [+0] I don't care
 [-1] no, we still need the latest and greatest improvements in MyFaces-2.0.x
 
 LieGrue,
 strub

Re: [VOTE] [RESULT] usage of ProjectStage

2012-11-23 Thread Mark Struberg

There has been 2 +1, no -1, no +1 thus due to lazy consensus I declare this 
VOTE closed with the decision:

 [ ] only use ProjectStage depending functions if it is really necessary. E.g. 
 for disabling dynamic reload

LieGrue,
strub



- Original Message -
 From: Mark Struberg strub...@yahoo.de
 To: My Faces Development dev@myfaces.apache.org
 Cc: 
 Sent: Thursday, November 15, 2012 7:45 PM
 Subject: [VOTE] usage of ProjectStage
 
 We currently have the discussion about how we use the ProjectStage. Do we 
 like 
 to use it excessively for all kind of tweaks or only where it is needed to 
 enable caching for production.
 
 The reason for this vote is that we had some usage of 
 if(ProjectStage.Production) which caused a bug in production but not 
 when debugging/developing.
 
 [ ] only use ProjectStage depending functions if it is really necessary. E.g. 
 for disabling dynamic reload
 [ ] I don't care
 [ ] Use it whenever we need some debugging info or similar.
 
 Here is my vote:
 [X] only use ProjectStage depending functions if it is really necessary. E.g. 
 for disabling dynamic reload
 
 LieGrue,
 strub

Re: state of 2.2.x branch

2012-11-22 Thread Mark Struberg

Hi Werner, no worries - it's long time resolved already.

I was just a bit emotional as I faced lots of issues at the same time. 
My concern (also for the other issues) was less that someone introduced a bug 
(only the ones who do not work anything don't make failures) but that no one 
saw it yet and reviewed it. 

Just to emphase what I already said to Leo during our discussion: This is 
clearly something which is not the fault of the ones who did the code changes 
(which are as usually of high quality) but a fault of all other committers to 
not properly review the changes being made.


LieGrue,
strub



- Original Message -
 From: Werner Punz werner.p...@gmail.com
 To: MyFaces Development dev@myfaces.apache.org
 Cc: 
 Sent: Thursday, November 22, 2012 9:13 AM
 Subject: Re: state of 2.2.x branch
 
 Am 16.11.12 09:32, schrieb Mark Struberg:
  I tried to keep trunk and core/branches/2.2.x in sync. But this is 
 currently totally broken
 
 
  A.) it doesn't compile
  B.) there are JavaScript compilation errors
  c.) it still states a mixture of 2.0.0-SNAPSHOT and description says 2.1 in 
 the poms
 
  https://svn.apache.org/repos/asf/myfaces/core/branches/2.2.x/pom.xml
 
  Please tell me that I'm wrong and are looking at the wrong files. 
 Otherwise I gonna cry now.
 
  I hope we didn't CI deploy that broken stuff already...
 
 
  LieGrue,
  strub
 
 
 Hi regarding the javascript compilation errors, this is an idea bug, 
 usually it happens that || somecode introduces invisible non utf 
 characters after the or, normally I catch those bugs at a separate 
 compilation check. Sorry about it.
 
 
 Werner

[jira] [Commented] (MYFACES-3652) Define default view key algorithm

[
https://issues.apache.org/jira/browse/MYFACES-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501109#comment-13501109
]

Mark Struberg commented on MYFACES-3652:

Hi Leo, thanks for the feedback.

I did a quick test and while the SessionIdGenerator from tomcat creates a much
more unpredictable value it is also much slower than XorShiftRandom. And
currently we encrypt that as well, so this looks a bit like an overkill to me.

- the viewId hashcode protects against use one valid key for one view in
other view,
But an attacker can easily disable this vector by using the same view for the
hack. So this information is not of stellar use in practice.

I agree that with B we _theoretically_ would not need encryption + mac. But I
have my doubts as well.

Please look at the ThreadsafeXorShiftRandom I committed in 2.2.x. Imo this also
creates the unpredictability we need. Even if the random sequence can be
predicted if you know the algorighm and the former seed value, you actually
don't know which thread you will hit next and if there are requests from
different users inbetween. In any case it's way superior than just adding the
viewId which always remains the same.

Define default view key algorithm
-

Key: MYFACES-3652
URL: https://issues.apache.org/jira/browse/MYFACES-3652
Project: MyFaces Core
Issue Type: Sub-task
Components: JSR-344
Affects Versions: 2.2.0, 2.1.9
Reporter: Mark Struberg
Assignee: Mark Struberg

Currently we have a few different viewkey generator implementations. Those
got added only in 2.1.9. Before that the only had a TicketCounter in each
Session.
The original implementation also had no viewId in the key.
If you think about it, then it makes no sense at all to add the viewId.
Despite it's an int hashCode we have 2 problems which completely trashes the
purpose:
a.) hashCode is not guaranteed to be unique
b.) the hashCode is always the same for the same view.
Think about an application with only one xhtml page. In that case the viewId
would add no additional info.
With 4 pages you would only reduce the collision rate to over 25%. Since the
application will most times mainly hit by a few entry points like index.html
you gain barely anything from adding this information.
IF we have had problems with any collisions, then we shall add an XorShift
random generator instead of the viewId. Leo, I didn't an issue report for
such a problem. Do you have any tip for me where I can find that?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (MYFACES-3655) add pluggable Serialization strategies

Mark Struberg created MYFACES-3655:
--

 Summary: add pluggable Serialization strategies
 Key: MYFACES-3655
 URL: https://issues.apache.org/jira/browse/MYFACES-3655
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.0
Reporter: Mark Struberg
Assignee: Mark Struberg


We might check if we can get an even better performance by using a different 
serialisation strategy. This might heavily improve the performance of 
ClientSideStateSaving and ViewMap serialisation(if enabled).

There are a few alternative libraries like XStream and Kryo available:

* http://xstream.codehaus.org
* http://code.google.com/p/kryo/

Thomas from the OWB team did a nice benchmark for his clustering project:
http://code.google.com/p/memcached-session-manager/wiki/SerializationStrategyBenchmark

Definitely worth taking a look imo.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3652) Define default view key algorithm

[
https://issues.apache.org/jira/browse/MYFACES-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501142#comment-13501142
]

Mark Struberg commented on MYFACES-3652:

a few more thoughts:

The xorshiftrandom is _only_ predictable if we serialize the _full_ long number
to the client. So lets just cut off the two least significant bytes. Or even
from somewhere in the middle. In that case we still have 48 bits random which
is good enough as the sequencer is there as well. But an attacker doesn't have
the seed and thus is not able to generate the next number.

The hit ratio would be:

1 : 2^16 * threadcount * chance_of_other_user_request_inbetween

and a new game with even better ratio on each subsequent retry.

I think even unencoded this is superior to our current sequencer + viewid_hash
+ encoding +mac.

The reason is that any encoding which only generates a low number of bytes can
be cracked. And the entropy of the encoded values is really low:
* the viewIdHash is easy to predict
* the MAC is stable
* the sequencer is easy to predict too

did I miss something?

Define default view key algorithm
-

[jira] [Commented] (MYFACES-3652) Define default view key algorithm

[
https://issues.apache.org/jira/browse/MYFACES-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13501150#comment-13501150
]

Mark Struberg commented on MYFACES-3652:

btw:
- It should not be possible to use the key for one view in other view.

I do _not_ agree with this. Instead I'd say:
- It must not be possible to use the key for a different request in the
session.

The view itself really doesn't matter. Usually XSRF happens on the same view
via javascript so the viewId has not much practical impact from my experience.

Define default view key algorithm
-

[jira] [Created] (MYFACES-3651) review/refactor/document ViewState handling in JSF-2.2

Mark Struberg created MYFACES-3651:
--

 Summary: review/refactor/document ViewState handling in JSF-2.2
 Key: MYFACES-3651
 URL: https://issues.apache.org/jira/browse/MYFACES-3651
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-314
Reporter: Mark Struberg
Assignee: Mark Struberg


We currently have a few things in our ViewState handling which could get even 
further improved.
There are 3 main goals we achieve (in order of importance):

1.) security - it should not be easily possible to create state key clashes
2.) performance - we still use java 1.3 tricks and e.g. barely use 
java.util.concurrent
3.) memory - we shall keep the mem footprint as low as possible

 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (MYFACES-3652) Define default view key algorithm

Mark Struberg created MYFACES-3652:
--

 Summary: Define default view key algorithm
 Key: MYFACES-3652
 URL: https://issues.apache.org/jira/browse/MYFACES-3652
 Project: MyFaces Core
  Issue Type: Sub-task
  Components: JSR-344
Affects Versions: 2.1.9, 2.2.0
Reporter: Mark Struberg
Assignee: Mark Struberg


Currently we have a few different viewkey generator implementations. Those got 
added only in 2.1.9. Before that the only had a TicketCounter in each Session. 

The original implementation also had no viewId in the key.
If you think about it, then it makes no sense at all to add the viewId. Despite 
it's an int hashCode we have 2 problems which completely trashes the purpose: 
a.) hashCode is not guaranteed to be unique
b.) the hashCode is always the same for the same view.

Think about an application with only one xhtml page. In that case the viewId 
would add no additional info.
With 4 pages you would only reduce the collision rate to over 25%. Since the 
application will most times mainly hit by a few entry points like index.html 
you gain barely anything from adding this information.

IF we have had problems with any collisions, then we shall add an XorShift 
random generator instead of the viewId. Leo, I didn't an issue report for such 
a problem. Do you have any tip for me where I can find that?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3652) Define default view key algorithm

[
https://issues.apache.org/jira/browse/MYFACES-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13500255#comment-13500255
]

Mark Struberg commented on MYFACES-3652:

Also please note that the XorShift random long generator would also easily
fulfil our security requirements and allows us to get rid of the pretty
expensive SecureRandom SessionIdGenerator as well.

Btw no need for a pluggable ViewKey. All the abstraction is done in
SessionViewStorageFactory anyway. And even this currently is not fully
pluggable. We have 4 different abstractions for this area and none of them is
clean atm. I prefer having slightly less but more general SPI interfaces. And
fully pluggable of course!

I'm not sure about StateCache. There is currently no documentation what the
generic types K and V represent. But that might be a good point of abstraction
granularity.

Define default view key algorithm
-

[jira] [Created] (MYFACES-3654) implement small threadsafe Random algorithm

Mark Struberg created MYFACES-3654:
--

 Summary: implement small threadsafe Random algorithm
 Key: MYFACES-3654
 URL: https://issues.apache.org/jira/browse/MYFACES-3654
 Project: MyFaces Core
  Issue Type: Sub-task
  Components: JSR-344
Affects Versions: 2.2.0
Reporter: Mark Struberg
Assignee: Mark Struberg


java.util.Random always locks and thus creates a bottleneck in heavy threaded 
server scenarios. In Java 7 a new ThreadLocalRandom got introduced which fixes 
that but we cannot use this as we still need to support java5 and 6.

The algorithm used in java.util.Random also is not the best in terms of 
spreading. 

I propose to introduce a small XorShift random generator which has a very good 
spreading and is vastly faster than java.util.Random as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (MYFACES-3654) implement small threadsafe Random algorithm


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

Mark Struberg resolved MYFACES-3654.


   Resolution: Fixed
Fix Version/s: 2.2.0

 implement small threadsafe Random algorithm
 ---

 Key: MYFACES-3654
 URL: https://issues.apache.org/jira/browse/MYFACES-3654
 Project: MyFaces Core
  Issue Type: Sub-task
  Components: JSR-344
Affects Versions: 2.2.0
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 2.2.0


 java.util.Random always locks and thus creates a bottleneck in heavy threaded 
 server scenarios. In Java 7 a new ThreadLocalRandom got introduced which 
 fixes that but we cannot use this as we still need to support java5 and 6.
 The algorithm used in java.util.Random also is not the best in terms of 
 spreading. 
 I propose to introduce a small XorShift random generator which has a very 
 good spreading and is vastly faster than java.util.Random as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3654) implement small threadsafe Random algorithm


[ 
https://issues.apache.org/jira/browse/MYFACES-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13500481#comment-13500481
 ] 

Mark Struberg commented on MYFACES-3654:


implemented in XorShiftRandom and ThreadsafeXorShiftRandom

 implement small threadsafe Random algorithm
 ---

 Key: MYFACES-3654
 URL: https://issues.apache.org/jira/browse/MYFACES-3654
 Project: MyFaces Core
  Issue Type: Sub-task
  Components: JSR-344
Affects Versions: 2.2.0
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 2.2.0


 java.util.Random always locks and thus creates a bottleneck in heavy threaded 
 server scenarios. In Java 7 a new ThreadLocalRandom got introduced which 
 fixes that but we cannot use this as we still need to support java5 and 6.
 The algorithm used in java.util.Random also is not the best in terms of 
 spreading. 
 I propose to introduce a small XorShift random generator which has a very 
 good spreading and is vastly faster than java.util.Random as well.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Documentation

2012-11-19 Thread Mark Struberg



Hi Grant!



Werner already created http://svn.apache.org/repos/asf/myfaces/cms-site/trunk

The CMS documentation can be found here: http://www.apache.org/dev/cms.html


There is a maven plugin for doing the svnpubsub from a mvn site:
http://maven.apache.org/sandbox/plugins/asf-svnpubsub-plugin/examples/importing-maven-site.html


hope that helps getting started.

LieGrue,
strub


 From: Grant Smith grantsm...@apache.org
To: MyFaces Development dev@myfaces.apache.org 
Sent: Monday, November 19, 2012 11:37 PM
Subject: Documentation
 

Hi all,

I'm going through some of the site documentation, and I can't for the life of 
me remember how to build and publish the xdocs so that they appear on the 
website. I remember a few emails a while back by Leo regarding svnpubsub.. is 
this related ? If so, how does it work ?

It seems the wiki is down right now...

-- 
Grant Smith - V.P. Information Technology
Marathon Computer Systems, LLC.

Re: CODI: @ViewScoped implementation possibly flawed.

2012-11-18 Thread Mark Struberg

Hi Radu!

Thansk for the feedback. Yes, observing session events would be a possible 
workaround for broken JSF containers/spec issues.

 Did CODI join forces with Seam? 
Yes, the Apache DeltaSpike project is the joined effort in this area. For the 
@ViewScoped implementation this doesn't have any impact because I (together 
with the help Jakob and Gerhard)  wrote both of them ;)



LieGrue,
strub



- Original Message -
 From: Radu Creanga rdc...@gmail.com
 To: MyFaces Development dev@myfaces.apache.org
 Cc: 
 Sent: Sunday, November 18, 2012 6:28 PM
 Subject: Re: CODI: @ViewScoped implementation possibly flawed.
 
 Stan,
 
 I reviewed the spec changes. What they do is monitor session, session
 attribute, context, context attributes, context, and context attribute
 events then properly fire PreDestroyViewMapEvents. This change would
 actually fix CODI's implementation as it stand since this is the event
 that CODI's implementation monitors.
 
 Mark,
 
 It actually has nothing to do with CODI nor CDI. - please allow me
 to argue otherwise. The CDI spec says that Context implementations are
 responsible for destroying beans, see here
 (http://docs.jboss.org/cdi/spec/1.0/html_single/#contextual). Whoever
 wrote the CODI implementation thought that listening for
 PreDestroyViewMapEvents would be enough to ensure that, which I don't
 blame them, look at the comments:
 
 /**
      * We get PreDestroyViewMapEvent events from the JSF servlet and
 destroy our contextual
      * instances. This should (theoretically!) also get fired if the
 webapp closes, so there
      * should be no need to manually track all view scopes and destroy
 them at a shutdown.
      *
      * @see 
 javax.faces.event.SystemEventListener#processEvent(javax.faces.event.SystemEvent)
      */
 
 But, this event does not get fired, therefore a better implementation
 would monitor for at least HttpSessionEvents and destroy the instances
 it creates.
 
 Also, you say that it's a similar problem with every passivation
 capable bean. Sure, in the case that the beans would be passivated or
 replicated across the domain, I wouldn't blame the context for not
 being able to destroy them. But, there are plenty of instances when
 view scoped beans never get passivated, just like sessions. And the
 current implementation doesn't even destroy those.
 
 Now, it is not possible (to the best of my knowledge) to register for
 session events directly from the Contextual implementation, since by
 then the servlet would be initialized. Therefore, writing a CDI
 extension that propagates the servlet and session lifecycle events to
 CDI, then having the Contextual implementation observe those events in
 order to properly destroy instance it creates would be one solution.
 
 I understand that this may be overkill since the new JSF spec will fix
 this in a few months. Also, from what I understand CODI does not
 currently have an extension that monitors for servlet related events
 so it would be quite a lot of work to get there.
 
 Did CODI join forces with Seam? If so, it may be worth bringing this
 up to them. I'd be happy to work on it, since I already have to anyway
 for my internal project. Pointers would be appreciated.
 
 Radu Creanga
 
 
 On Fri, Nov 16, 2012 at 12:14 PM,  ssilv...@redhat.com wrote:
  Problems with @ViewScoped and @PreDestroy have been identified in the
  spec and a fix is slated for JSF 2.2:
  http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-905
 
  You guys might want to comment on it.
 
  Stan
 
  On 11/16/2012 9:50 AM, Mark Struberg wrote:
 
  Hi Radu!
 
  Congratulations, you spotted a very deeply buried problem :) It 
 actually has nothing to do with CODI nor CDI. The problem is similar with 
 every 
 passivation capable (==Serializable) bean: @PreDestroy is not 100% guaranteed 
 to 
 get fired.
 
  I'm not sure if you really did hit a bug in the 2 JSF impls  or a 
 systematic consequence of serializable objects I like to explain now:
 
 
  Think about a @ViewScoped bean. The @PreDestroy invokes a user.logout() 
 for example. Now you navigate away from the page and  the @ViewScoped bean 
 gets 
 closed. Then press the browser back button and you will have the bean again 
 (restored from the viewstate map). That might lead to @PreDestroy getting 
 invoked multiple times.
 
 
  Now another case: a user opens a page.xhtml in his browser. A 
 @ViewScoped bean gets called and if ClientSideStateSaving is activated it 
 gets 
 serialized and stored inside the html page. The user just goes away or closes 
 his browser and this bean will never get the @PreDestroy being called.
 
  Something similar happens with all @SessionScoped or session related 
 beans if a server shuts down and passivates it's sessions. If there is a 
 redeployment inbetween which is not binary compatible, then those beans will 
 never get resurrected and never get properly destroyed because of that.
 
  It get's even worse if you think about Session

Re: StateSaving reviews

2012-11-16 Thread Mark Struberg

Yes full +1.

It seems that Leo still has auto-generating the @author in the files he 
touches. Even if this file is a close to 1:1 clone of an almost 10 year old 
file originally written by Tom.
We already voted in favour to get rid of the @author tags apart from the 
ancient ones which have been there before. And I assume this decision is 
binding for all of us and will be followed.


LieGrue,
strub



- Original Message -
 From: Mike Kienenberger mkien...@gmail.com
 To: MyFaces Development dev@myfaces.apache.org; Mark Struberg 
 strub...@yahoo.de
 Cc: 
 Sent: Friday, November 16, 2012 2:11 AM
 Subject: Re: StateSaving reviews
 
 On Thu, Nov 15, 2012 at 7:41 PM, Mark Struberg strub...@yahoo.de wrote:
  Btw you should either copy over Tom and Manfreds @author from the 
 JspViewStateManager or remove your own @author from the copied class as it is 
 still 80% the old code.
 
 I am fairly certain we did away with @author tags intentionally
 because no one individual owns a piece of code nor is responsible
 for it.   It took a few minutes to find it, but Feb/March 07 has the
 thread, some of which was unfortunately discussed on the private
 mailing list, but I think it eventually moved to dev.

Re: StateSaving reviews

2012-11-16 Thread Mark Struberg

Btw, you wrote
 that code has been there for years!! 

I checked the logs now.

Actually most of the changes got only introduced in 2.1.9!


LieGrue,
strub



- Original Message -
 From: Leonardo Uribe lu4...@gmail.com
 To: MyFaces Development dev@myfaces.apache.org; Mark Struberg 
 strub...@yahoo.de
 Cc: 
 Sent: Friday, November 16, 2012 2:09 AM
 Subject: Re: StateSaving reviews
 
 Hi
 
 I'll proceed with the necessary changes now. I hope to get it done tomorrow.
 
 regards,
 
 Leonardo
 
 2012/11/15 Leonardo Uribe lu4...@gmail.com:
  Hi
 
  2012/11/15 Mark Struberg strub...@yahoo.de:
  The usual release cycle is  2 to 3 months. The next expected release is 
 early/mid November and not next week. If you are too stressed I can take over 
 doing the release.
 
 
  Today is 15 of November, I plan start release one week, if there is a
  problem, I have
  2 weeks more to fix them, and I take my vacations from December 22.
  That's the plan.
 
 
  Let's make a deal, let me do it myself. I just take a snapshot 
 of your
  changes,
  revert, and apply only the refactoring step by step, then I compare 
 it. In that
  way, I'll be 100% sure the change is correct. Sounds good for 
 you?
  Leo, please learn to read foreign peoples code! It's really not 
 that complicated. It's the same others have to do over and over again with 
 your code as well. You can perfectly achieve the same by just reading through 
 the diffs. That's the reason we send them to the committers list. Those 
 diffs contain all the changes.
 
 
  We have 4 branches to maintain:
 
  2.0.x
  2.1.x
  2.1.x-client-window
  2.2.x
 
  I want to keep all of them in sync. Redo the work you already done is 
 necessary
  for me, because I need to do the same steps in all branches. You are doing 
 the
  funny part, but I have to clean the dishes.
 
 
  Going back to the old source is also not really an option in my 
 personal opinion as it
 
  a.) contained a bug (NPE). There is a unit test for it now btw.
 
  b.) worked _completely_ different in ProjectStage.Production and all 
 others ProjectStages thus made it tremendously hard to debug/reproduce for 
 developers.
 
  And I'm not yet talking about stylistics like ode duplications, 
 unused fields and generic types and endless inner classes.
 
 
  And also we had this kind of discussion quite a few times already and 
 you always ended up reverting without giving any technical reasoning. That 
 sucks 
 to be honest.
 
 
  That's not true. I give technical reasons, it is just that we have 
 different
  opinions, that's it.
 
 
  For gods sake, a very last time I let you revert something.
 
  Please first rethink (and then probably do if you are still convinced 
 about it's necessity) the following:
  * revert to the old state
 
  Ok, let's go back to rev 1409476.
 
  * remove the ProjectStage.Production and always use the same key 
 strategy. This is really crucial for stability!
 
  Ok, just one strategy.
 
  * apply the unit test I created and fix the NPE.
 
  Already done in 1408093
 
  * move the viewId.hashCode() to the key strategy constructor and you 
 will clearly see the code duplication all over the place
 
 
  Ok.
 
  * you can also spare the byte[] variant as this can be perfectly done 
 inside the key strategy. There goes another code duplication. That will btw 
 remove a broken unchecked upcast as well.
 
 
  Ok
 
  * remove the bloody src/main/old
 
  Ok
 
  * I bet I forgot some other cleanup I did
 
 
  Ok
 
 
  I will drop/cleanup the rest do the windowId handling after this 
 release if you get it out of the door this week.
 
 
  Add windowId concept in 2.1.x branch has not been discussed.
  In theory, the idea was test and improve 2.1.x-client-window branch
  (target JSF 2.2) and only when the code is stable enough, backport
  it to 2.1.x.
 
 
  Btw you should either copy over Tom and Manfreds @author from the 
 JspViewStateManager or remove your own @author from the copied class as it is 
 still 80% the old code.
 
 
  No worries about @author tag. Nobody cares about that, because the
  license is ASF. It only matters if you hold the intellectual
  copyright, which is not the case.
 
  regards,
 
  Leonardo
 
 
  LieGrue,
  strub
 
 
  - Original Message -
  From: Leonardo Uribe lu4...@gmail.com
  To: MyFaces Development dev@myfaces.apache.org; Mark 
 Struberg strub...@yahoo.de
  Cc:
  Sent: Friday, November 16, 2012 1:11 AM
  Subject: Re: StateSaving reviews
 
  Hi
 
  2012/11/15 Mark Struberg strub...@yahoo.de:
   Kito, there was no single word inside the PMC that the release 
 will be next
  week. I just again scanned our internal mailboxes to verify that. 
 Leo is just
  adding another messy argument which is not funded.
   Of course there will be a release soon, but there was no 
 agreed date yet.
 
 
  There is an agreement of make a release each two months, or earlier
  if something happen. Check the dates, and you will see the 
 systematic
  pattern

2.1-windowId branch

2012-11-16 Thread Mark Struberg

I checked the work done in there and Imo this is far from usable. Let's get the 
windowId right in 2.2 an backport it later. 


It doesn't make any sense to have 2 branches to do try  error in this area. To 
stress your butterfly analogy: there is a difference between a cocoon and a 
hydra ;)

LieGrue,
strub

state of 2.2.x branch

2012-11-16 Thread Mark Struberg

I tried to keep trunk and core/branches/2.2.x in sync. But this is currently 
totally broken


A.) it doesn't compile
B.) there are JavaScript compilation errors
c.) it still states a mixture of 2.0.0-SNAPSHOT and description says 2.1 in the 
poms

https://svn.apache.org/repos/asf/myfaces/core/branches/2.2.x/pom.xml

Please tell me that I'm wrong and are looking at the wrong files. Otherwise I 
gonna cry now.

I hope we didn't CI deploy that broken stuff already...


LieGrue,
strub

Re: state of 2.2.x branch

2012-11-16 Thread Mark Struberg

PS: again, this should not be a personal critic. Every one makes errors. Only 
the ones who do not work at all don't make errors :)


It just makes it clear that all of us must contribute more, actively review 
changes and help out!
And Leo, you must open your mind to ideas of other people to let this happen 
without endless (not technically backed) discussions.

LieGrue,
strub




- Original Message -
 From: Mark Struberg strub...@yahoo.de
 To: My Faces Development dev@myfaces.apache.org
 Cc: 
 Sent: Friday, November 16, 2012 9:32 AM
 Subject: state of 2.2.x branch
 
 I tried to keep trunk and core/branches/2.2.x in sync. But this is currently 
 totally broken
 
 
 A.) it doesn't compile
 B.) there are JavaScript compilation errors
 c.) it still states a mixture of 2.0.0-SNAPSHOT and description says 2.1 in 
 the 
 poms
 
 https://svn.apache.org/repos/asf/myfaces/core/branches/2.2.x/pom.xml
 
 Please tell me that I'm wrong and are looking at the wrong files. Otherwise 
 I gonna cry now.
 
 I hope we didn't CI deploy that broken stuff already...
 
 
 LieGrue,
 strub

[jira] [Created] (MYFACES-3648) some jsf files contain illegal UTF characters

Mark Struberg created MYFACES-3648:
--

 Summary: some jsf files contain illegal UTF characters
 Key: MYFACES-3648
 URL: https://issues.apache.org/jira/browse/MYFACES-3648
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.0
Reporter: Mark Struberg
Assignee: Mark Struberg


some jsf files contain illegal UTF characters and thus our 2.2 build is broken

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (MYFACES-3648) some jsf files contain illegal UTF characters


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

Mark Struberg resolved MYFACES-3648.


   Resolution: Fixed
Fix Version/s: 2.2.0

 some jsf files contain illegal UTF characters
 -

 Key: MYFACES-3648
 URL: https://issues.apache.org/jira/browse/MYFACES-3648
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.0
Reporter: Mark Struberg
Assignee: Mark Struberg
 Fix For: 2.2.0


 some jsf files contain illegal UTF characters and thus our 2.2 build is broken

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (MYFACES-3649) myfaces-shaded-impl always unpacks myfaces-2.1.1

Mark Struberg created MYFACES-3649:
--

 Summary: myfaces-shaded-impl always unpacks myfaces-2.1.1
 Key: MYFACES-3649
 URL: https://issues.apache.org/jira/browse/MYFACES-3649
 Project: MyFaces Core
  Issue Type: Bug
  Components: build process
Affects Versions: 2.1.9, 2.2.0, 2.1.10
Reporter: Mark Struberg
Assignee: Mark Struberg
Priority: Blocker


myfaces-shared-impl hardcoded unpacks mf-2.1.1 right now. How can this work?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3649) myfaces-shaded-impl always unpacks myfaces-2.1.1


[ 
https://issues.apache.org/jira/browse/MYFACES-3649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13498690#comment-13498690
 ] 

Mark Struberg commented on MYFACES-3649:


I added the implicit dependency and got the following:

[ERROR] The projects in the reactor contain a cyclic reference: Edge between 
'Vertex{label='org.apache.myfaces.core:myfaces-impl:2.1.10-SNAPSHOT'}' and 
'Vertex{label='org.apache.myfaces.core.internal:myfaces-impl-ee6:2.1.10-SNAPSHOT'}'
 introduces to cycle in the graph 
org.apache.myfaces.core.internal:myfaces-impl-ee6:2.1.10-SNAPSHOT -- 
org.apache.myfaces.core.internal:myfaces-shaded-impl:2.1.10-SNAPSHOT -- 
org.apache.myfaces.core:myfaces-impl:2.1.10-SNAPSHOT -- 
org.apache.myfaces.core.internal:myfaces-impl-ee6:2.1.10-SNAPSHOT - [Help 1]

And guess what? Maven is right! We have a perfect build cycle which messes up 
all our releases.

 myfaces-shaded-impl always unpacks myfaces-2.1.1
 

 Key: MYFACES-3649
 URL: https://issues.apache.org/jira/browse/MYFACES-3649
 Project: MyFaces Core
  Issue Type: Bug
  Components: build process
Affects Versions: 2.2.0, 2.1.9, 2.1.10
Reporter: Mark Struberg
Assignee: Mark Struberg
Priority: Blocker

 myfaces-shared-impl hardcoded unpacks mf-2.1.1 right now. How can this work?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MYFACES-3649) myfaces-shaded-impl always unpacks myfaces-2.1.1