from:"Gerhard Petracek"

Re: Possible Problem -> MyFaces ExtVal on Payara 5

2019-01-11 Thread Gerhard Petracek

let's discuss it once it's clear that there are no other blockers with the
ee8 api.
this one is quite easy to fix, however, at least with the first few
versions of mojarra 2.2 an upgrade would have been quite time-consuming.

regards,
gerhard


Am Mi., 9. Jan. 2019 um 19:19 Uhr schrieb Thomas Andraschko <
andraschko.tho...@gmail.com>:

> Probably its also quite easy to make it compatible ;)
> Wdyt about a release Gerhard, If someone (Thomas?!) could make it
> compatible?
>
> Am Mi., 9. Jan. 2019, 19:04 hat Gerhard Petracek 
> geschrieben:
>
>> hi thomas,
>>
>> there are several (still) unique features.
>> i guess it's a mixture of: not migrated (applications), migrated away
>> from jsf and just not asked here.
>>
>> regards,
>> gerhard
>>
>>
>> Am Mi., 9. Jan. 2019 um 17:09 Uhr schrieb Thomas Kernstock <
>> t.kernst...@e-technologies.at>:
>>
>>> Hallo Gerhard,
>>>
>>>
>>>
>>> long time no hear  hope you are fine.
>>>
>>>
>>>
>>> Since there are some nice features in ExtVal (like cross validation with
>>> @Equals) that I still use and which I wanted simply to move to JEE8
>>> without much effort I kept the Extval libraries. I wasn’t aware of the fact
>>> that I seem to be the only one :-)
>>>
>>>
>>>
>>> Liebe Grüße
>>>
>>> Thomas
>>>
>>>
>>>
>>> *Von:* Gerhard Petracek 
>>> *Gesendet:* Dienstag, 08. Jänner 2019 19:09
>>> *An:* MyFaces Development 
>>> *Betreff:* Re: Possible Problem -> MyFaces ExtVal on Payara 5
>>>
>>>
>>>
>>> @thomas andraschko
>>>
>>> that's correct.
>>>
>>> jsf 2.0 was supported explicitly (and afair 2.1 implicitly) but we never
>>> received a request to support 2.2+.
>>>
>>>
>>>
>>> regards,
>>>
>>> gerhard
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Am Mo., 7. Jan. 2019 um 16:39 Uhr schrieb Thomas Andraschko <
>>> andraschko.tho...@gmail.com>:
>>>
>>> Hi,
>>>
>>> AFAIK ExtVal is in maintanence mode since years and was probably
>>> therefore never tested on JavaEE8.
>>>
>>> If you don't need it, just remove it.
>>>
>>> I just know that the last release was 2013.
>>>
>>> Best regards,
>>>
>>> Thomas
>>>
>>>
>>>
>>>
>>>
>>> Am Mo., 7. Jan. 2019 um 16:33 Uhr schrieb Thomas Kernstock <
>>> t.kernst...@e-technologies.at>:
>>>
>>> Hi guys,
>>>
>>>
>>>
>>> I’m migrating my JEE7 project from Payara 4.1.2.173 to Payara 5.184 and
>>> found a possible problem/error!?
>>>
>>>
>>>
>>> I run Payara 5 under Windows 7 with OracleJDK8 and use Extval Version
>>> 2.08. My project contains:
>>>
>>> myfaces-extval-bean-validation-2.08.jar
>>>
>>> myfaces-extval-core-2.0.8.jar
>>>
>>> myfaces-extval-property-validation-2.0.8.jar
>>>
>>>
>>>
>>> One last problem persists when I try to login into my application ->
>>>
>>>
>>>
>>> 2018-12-28T14:12:31.548+0100|INFORMATION: start init of
>>> org.apache.myfaces.extensions.validator.beanval.startup.JSF2AwareBeanValidationStartupListener
>>>
>>> 2018-12-28T14:12:31.557+0100|INFORMATION: global property
>>> [org.apache.myfaces.extensions.validator.core.ProjectStageResolver] added
>>>
>>> 2018-12-28T14:12:31.583+0100|INFORMATION: init of
>>> org.apache.myfaces.extensions.validator.beanval.startup.JSF2AwareBeanValidationStartupListener
>>> finished
>>>
>>> 2018-12-28T14:12:31.583+0100|INFORMATION: start init of
>>> org.apache.myfaces.extensions.validator.beanval.startup.BeanValidationStartupListener
>>>
>>> 2018-12-28T14:12:31.585+0100|INFORMATION: global property
>>> [javax.validation.ValidatorFactory] added
>>>
>>> 2018-12-28T14:12:31.686+0100|INFORMATION: global property
>>> [org.apache.myfaces.extensions.validator.beanval.payload.ViolationSeverity$Info]
>>> added
>>>
>>> 2018-12-28T14:12:31.688+0100|INFORMATION: global property
>>> [org.apache.myfaces.extensions.validator.beanval.payload.ViolationSeverity$Warn]
>>> added
>>>
>>> 2018-12-28T14:12:31.689+0100|INFORMATION: global property
>>

Re: Possible Problem -> MyFaces ExtVal on Payara 5

2019-01-09 Thread Gerhard Petracek

hi thomas,

there are several (still) unique features.
i guess it's a mixture of: not migrated (applications), migrated away from
jsf and just not asked here.

regards,
gerhard


Am Mi., 9. Jan. 2019 um 17:09 Uhr schrieb Thomas Kernstock <
t.kernst...@e-technologies.at>:

> Hallo Gerhard,
>
>
>
> long time no hear  hope you are fine.
>
>
>
> Since there are some nice features in ExtVal (like cross validation with
> @Equals) that I still use and which I wanted simply to move to JEE8
> without much effort I kept the Extval libraries. I wasn’t aware of the fact
> that I seem to be the only one :-)
>
>
>
> Liebe Grüße
>
> Thomas
>
>
>
> *Von:* Gerhard Petracek 
> *Gesendet:* Dienstag, 08. Jänner 2019 19:09
> *An:* MyFaces Development 
> *Betreff:* Re: Possible Problem -> MyFaces ExtVal on Payara 5
>
>
>
> @thomas andraschko
>
> that's correct.
>
> jsf 2.0 was supported explicitly (and afair 2.1 implicitly) but we never
> received a request to support 2.2+.
>
>
>
> regards,
>
> gerhard
>
>
>
>
>
>
>
> Am Mo., 7. Jan. 2019 um 16:39 Uhr schrieb Thomas Andraschko <
> andraschko.tho...@gmail.com>:
>
> Hi,
>
> AFAIK ExtVal is in maintanence mode since years and was probably therefore
> never tested on JavaEE8.
>
> If you don't need it, just remove it.
>
> I just know that the last release was 2013.
>
> Best regards,
>
> Thomas
>
>
>
>
>
> Am Mo., 7. Jan. 2019 um 16:33 Uhr schrieb Thomas Kernstock <
> t.kernst...@e-technologies.at>:
>
> Hi guys,
>
>
>
> I’m migrating my JEE7 project from Payara 4.1.2.173 to Payara 5.184 and
> found a possible problem/error!?
>
>
>
> I run Payara 5 under Windows 7 with OracleJDK8 and use Extval Version
> 2.08. My project contains:
>
> myfaces-extval-bean-validation-2.08.jar
>
> myfaces-extval-core-2.0.8.jar
>
> myfaces-extval-property-validation-2.0.8.jar
>
>
>
> One last problem persists when I try to login into my application ->
>
>
>
> 2018-12-28T14:12:31.548+0100|INFORMATION: start init of
> org.apache.myfaces.extensions.validator.beanval.startup.JSF2AwareBeanValidationStartupListener
>
> 2018-12-28T14:12:31.557+0100|INFORMATION: global property
> [org.apache.myfaces.extensions.validator.core.ProjectStageResolver] added
>
> 2018-12-28T14:12:31.583+0100|INFORMATION: init of
> org.apache.myfaces.extensions.validator.beanval.startup.JSF2AwareBeanValidationStartupListener
> finished
>
> 2018-12-28T14:12:31.583+0100|INFORMATION: start init of
> org.apache.myfaces.extensions.validator.beanval.startup.BeanValidationStartupListener
>
> 2018-12-28T14:12:31.585+0100|INFORMATION: global property
> [javax.validation.ValidatorFactory] added
>
> 2018-12-28T14:12:31.686+0100|INFORMATION: global property
> [org.apache.myfaces.extensions.validator.beanval.payload.ViolationSeverity$Info]
> added
>
> 2018-12-28T14:12:31.688+0100|INFORMATION: global property
> [org.apache.myfaces.extensions.validator.beanval.payload.ViolationSeverity$Warn]
> added
>
> 2018-12-28T14:12:31.689+0100|INFORMATION: global property
> [org.apache.myfaces.extensions.validator.beanval.payload.ViolationSeverity$Fatal]
> added
>
> 2018-12-28T14:12:31.691+0100|INFORMATION: global property
> [org.apache.myfaces.extensions.validator.beanval.payload.DisableClientSideValidation]
> added
>
> 2018-12-28T14:12:31.691+0100|INFORMATION: init of
> org.apache.myfaces.extensions.validator.beanval.startup.BeanValidationStartupListener
> finished
>
> 2018-12-28T14:12:31.691+0100|INFORMATION: start init of
> org.apache.myfaces.extensions.validator.core.startup.ExtValStartupListener
>
> 2018-12-28T14:12:31.691+0100|INFORMATION: config for key [class
> org.apache.myfaces.extensions.validator.core.DefaultExtValCoreConfiguration]
> added
>
> 2018-12-28T14:12:31.691+0100|INFORMATION: starting up MyFaces Extensions
> Validator v2.0.8
>
> 2018-12-28T14:12:31.737+0100|INFORMATION: class
> org.apache.myfaces.extensions.validator.core.validation.parameter.DefaultViolationSeverityInterpreter
> is used
>
> 2018-12-28T14:12:31.742+0100|INFORMATION: global property
> [org.apache.myfaces.extensions.validator.core.validation.parameter.ViolationSeverity]
> added
>
> 2018-12-28T14:12:31.743+0100|INFORMATION: global property
> [org.apache.myfaces.extensions.validator.core.validation.parameter.DisableClientSideValidation]
> added
>
> 2018-12-28T14:12:31.743+0100|INFORMATION: global property
> [mode:init:required] added
>
> 2018-12-28T14:12:31.743+0100|INFORMATION: global property
> [mode:reset:required] added
>
> 2018-12-28T14:12:31.

Re: Possible Problem -> MyFaces ExtVal on Payara 5

2019-01-08 Thread Gerhard Petracek

@thomas andraschko
that's correct.
jsf 2.0 was supported explicitly (and afair 2.1 implicitly) but we never
received a request to support 2.2+.

regards,
gerhard



Am Mo., 7. Jan. 2019 um 16:39 Uhr schrieb Thomas Andraschko <
andraschko.tho...@gmail.com>:

> Hi,
>
> AFAIK ExtVal is in maintanence mode since years and was probably therefore
> never tested on JavaEE8.
> If you don't need it, just remove it.
> I just know that the last release was 2013.
>
> Best regards,
> Thomas
>
>
> Am Mo., 7. Jan. 2019 um 16:33 Uhr schrieb Thomas Kernstock <
> t.kernst...@e-technologies.at>:
>
>> Hi guys,
>>
>>
>>
>> I’m migrating my JEE7 project from Payara 4.1.2.173 to Payara 5.184 and
>> found a possible problem/error!?
>>
>>
>>
>> I run Payara 5 under Windows 7 with OracleJDK8 and use Extval Version
>> 2.08. My project contains:
>>
>> myfaces-extval-bean-validation-2.08.jar
>>
>> myfaces-extval-core-2.0.8.jar
>>
>> myfaces-extval-property-validation-2.0.8.jar
>>
>>
>>
>> One last problem persists when I try to login into my application ->
>>
>>
>>
>> 2018-12-28T14:12:31.548+0100|INFORMATION: start init of
>> org.apache.myfaces.extensions.validator.beanval.startup.JSF2AwareBeanValidationStartupListener
>>
>> 2018-12-28T14:12:31.557+0100|INFORMATION: global property
>> [org.apache.myfaces.extensions.validator.core.ProjectStageResolver] added
>>
>> 2018-12-28T14:12:31.583+0100|INFORMATION: init of
>> org.apache.myfaces.extensions.validator.beanval.startup.JSF2AwareBeanValidationStartupListener
>> finished
>>
>> 2018-12-28T14:12:31.583+0100|INFORMATION: start init of
>> org.apache.myfaces.extensions.validator.beanval.startup.BeanValidationStartupListener
>>
>> 2018-12-28T14:12:31.585+0100|INFORMATION: global property
>> [javax.validation.ValidatorFactory] added
>>
>> 2018-12-28T14:12:31.686+0100|INFORMATION: global property
>> [org.apache.myfaces.extensions.validator.beanval.payload.ViolationSeverity$Info]
>> added
>>
>> 2018-12-28T14:12:31.688+0100|INFORMATION: global property
>> [org.apache.myfaces.extensions.validator.beanval.payload.ViolationSeverity$Warn]
>> added
>>
>> 2018-12-28T14:12:31.689+0100|INFORMATION: global property
>> [org.apache.myfaces.extensions.validator.beanval.payload.ViolationSeverity$Fatal]
>> added
>>
>> 2018-12-28T14:12:31.691+0100|INFORMATION: global property
>> [org.apache.myfaces.extensions.validator.beanval.payload.DisableClientSideValidation]
>> added
>>
>> 2018-12-28T14:12:31.691+0100|INFORMATION: init of
>> org.apache.myfaces.extensions.validator.beanval.startup.BeanValidationStartupListener
>> finished
>>
>> 2018-12-28T14:12:31.691+0100|INFORMATION: start init of
>> org.apache.myfaces.extensions.validator.core.startup.ExtValStartupListener
>>
>> 2018-12-28T14:12:31.691+0100|INFORMATION: config for key [class
>> org.apache.myfaces.extensions.validator.core.DefaultExtValCoreConfiguration]
>> added
>>
>> 2018-12-28T14:12:31.691+0100|INFORMATION: starting up MyFaces Extensions
>> Validator v2.0.8
>>
>> 2018-12-28T14:12:31.737+0100|INFORMATION: class
>> org.apache.myfaces.extensions.validator.core.validation.parameter.DefaultViolationSeverityInterpreter
>> is used
>>
>> 2018-12-28T14:12:31.742+0100|INFORMATION: global property
>> [org.apache.myfaces.extensions.validator.core.validation.parameter.ViolationSeverity]
>> added
>>
>> 2018-12-28T14:12:31.743+0100|INFORMATION: global property
>> [org.apache.myfaces.extensions.validator.core.validation.parameter.DisableClientSideValidation]
>> added
>>
>> 2018-12-28T14:12:31.743+0100|INFORMATION: global property
>> [mode:init:required] added
>>
>> 2018-12-28T14:12:31.743+0100|INFORMATION: global property
>> [mode:reset:required] added
>>
>> 2018-12-28T14:12:31.745+0100|INFORMATION: init of
>> org.apache.myfaces.extensions.validator.core.startup.ExtValStartupListener
>> finished
>>
>> 2018-12-28T14:12:31.745+0100|INFORMATION: start init of
>> org.apache.myfaces.extensions.validator.PropertyValidationModuleStartupListener
>>
>> 2018-12-28T14:12:31.746+0100|INFORMATION: config for key [class
>> org.apache.myfaces.extensions.validator.baseval.DefaultExtValBaseValidationModuleConfiguration]
>> added
>>
>> 2018-12-28T14:12:31.746+0100|INFORMATION: config for key [class
>> org.apache.myfaces.extensions.validator.crossval.DefaultExtValCrossValidationModuleConfiguration]
>> added
>>
>> 2018-12-28T14:12:31.754+0100|INFORMATION: adding support for
>> @SkipValidation
>>
>> 2018-12-28T14:12:31.773+0100|INFORMATION: class
>> org.apache.myfaces.extensions.validator.PropertyValidationSkipValidationEvaluator
>> is used
>>
>> 2018-12-28T14:12:31.782+0100|INFORMATION:
>> org.apache.myfaces.extensions.validator.JoinValidationMetaDataStorageFilter
>> added
>>
>> 2018-12-28T14:12:31.783+0100|INFORMATION: init of
>> org.apache.myfaces.extensions.validator.PropertyValidationModuleStartupListener
>> finished
>>
>> 2018-12-28T14:12:37.214+0100|FATAL: JSF1073:
>> java.lang.AbstractMethodError erfasst w�hrend Verarbeitung von
>> PROCESS_VALIDATIONS 3 : UIComponent-ClientId=,

Re: MyFaces 3.x - Remove "Impl Shaded" + "Impl Shaded Public"? @cc tobago-guys :P

2018-10-19 Thread Gerhard Petracek

+1!

regards,
gerhard


Am Do., 18. Okt. 2018 um 13:54 Uhr schrieb Thomas Andraschko <
andraschko.tho...@gmail.com>:

> Hi,
>
> MyFaces Core Impl Shaded + Shaded Public was used years ago in other
> component libaries like Trinidad, Tobago and Tomhawk, right?
>
> Currently neither Trinidad nor Tomhawk is still active - and Tobago
> doesn't use it, right?
>
> As i said already said, 3.x is a good time to cleanup the project, as some
> legacy parts of JSF like ManagedBeans and Faces EL will be removed.
>
> I think it would be the right time to also merge back the "Shared Impls"
> into the "Impl" module and remove some unused stuff.
>
> I really would see it as an chance now, to make MyFaces maintainable for
> the next years and cleanup as much as possible!
>
> Mojarra takes the chance and even moved away from their old ant-based
> builds! :D
>
> WDYT?
> I would do all the work. We have over 1000 unittests, so i don't think we
> will break something ;)
>
> Best regards,
> Thomas
>
>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

2017-09-02 Thread Gerhard Petracek

@thomas: +1
btw. FacesScopedContextImpl contains methods called #getFlowScopeBeanHolder
instead of #getFacesScopeBeanHolder

regards,
gerhard



2017-09-02 13:00 GMT+02:00 Thomas Andraschko <andraschko.tho...@gmail.com>:

> thats what i thought :) I think the correct scope is @FacesScoped.
>
> 2017-09-02 12:58 GMT+02:00 Gerhard Petracek <gpetra...@apache.org>:
>
>> hi thomas,
>>
>> +1 - that's wrong as well (since #getCurrentFlowScope just returns the
>> ConcurrentHashMap used internally).
>> it would just work if the producer returns a "proxy-map" which is using
>> lazy-delegation.
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2017-09-02 10:10 GMT+02:00 Thomas Andraschko <andraschko.tho...@gmail.com
>> >:
>>
>>> Will work on it now.
>>>
>>> What about this one:
>>>@Produces
>>>@Named("flowScope")
>>>@FlowMap
>>>@ApplicationScoped
>>>public Map<Object, Object> getFlowMap()
>>>{
>>>   return FacesContext.getCurrentInstanc
>>> e().getApplication().getFlowHandler().getCurrentFlowScope();
>>>}
>>>
>>> Is it really correct to produce this into ApplicationScoped?
>>>
>>> 2017-09-01 21:15 GMT+02:00 Leonardo Uribe <lu4...@gmail.com>:
>>>
>>>> +1 for ignore. @ResolveComponent is still the closest solution we could
>>>> have. That is MyFaces Core specific feature, at least in my mind.
>>>>
>>>> 2017-09-01 14:08 GMT-05:00 Thomas Andraschko <
>>>> andraschko.tho...@gmail.com>:
>>>>
>>>>> +1 for ignoring it for now and open a spec issue
>>>>>
>>>>>
>>>>> Am Freitag, 1. September 2017 schrieb Gerhard Petracek :
>>>>>
>>>>>> @leo:
>>>>>>
>>>>>> as i said: "...we have a spec. issue here..."
>>>>>> if we have to follow it, we need to use @Dependent.
>>>>>>
>>>>>> if there isn't a tck-test for it, we could even ignore the written
>>>>>> spec. (that isn't nice, but mojarra is also doing it in some cases...).
>>>>>>
>>>>>> regards,
>>>>>> gerhard
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2017-09-01 19:44 GMT+02:00 Leonardo Uribe <lu4...@gmail.com>:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> Use producers won't work. The reason? it is necessary to create a
>>>>>>> proper proxy for that injection. It is a bug in the spec, the intention 
>>>>>>> was
>>>>>>> never that, and the suggestion proposed for inject components was not
>>>>>>> included.
>>>>>>>
>>>>>>> Keep it simple, use el-resolver for that always.
>>>>>>>
>>>>>>> regards,
>>>>>>>
>>>>>>> Leonardo Uribe
>>>>>>>
>>>>>>> 2017-09-01 12:41 GMT-05:00 Gerhard Petracek <gpetra...@apache.org>:
>>>>>>>
>>>>>>>> hi paul,
>>>>>>>>
>>>>>>>> yes - imo it's the only useful alternative since the spec.
>>>>>>>> prohibits the implementation via el-resolver (for whatever reason...).
>>>>>>>> (at least there isn't an approach without issues.)
>>>>>>>>
>>>>>>>> + imo we should consider a config-parameter to activate the
>>>>>>>> el-resolver in any case...
>>>>>>>>
>>>>>>>> regards,
>>>>>>>> gerhard
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pnico...@us.ibm.com>:
>>>>>>>>
>>>>>>>>> Hi Gerhard,
>>>>>>>>>
>>>>>>>>> Thanks for the clarification. So you think MyFaces should use
>>>>>>>>> @Dependent instead of @FacesScoped and then document to ensure users 
>>>>>>>>> are
>>>>>>>>> aware of the pitfalls of it?
>>>>>>>>>
>>>>>>>>> This seems to allow us to abide by the

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

2017-09-02 Thread Gerhard Petracek

hi thomas,

+1 - that's wrong as well (since #getCurrentFlowScope just returns the
ConcurrentHashMap used internally).
it would just work if the producer returns a "proxy-map" which is using
lazy-delegation.

regards,
gerhard



2017-09-02 10:10 GMT+02:00 Thomas Andraschko <andraschko.tho...@gmail.com>:

> Will work on it now.
>
> What about this one:
>@Produces
>@Named("flowScope")
>@FlowMap
>@ApplicationScoped
>public Map<Object, Object> getFlowMap()
>{
>   return FacesContext.getCurrentInstance().getApplication().
> getFlowHandler().getCurrentFlowScope();
>}
>
> Is it really correct to produce this into ApplicationScoped?
>
> 2017-09-01 21:15 GMT+02:00 Leonardo Uribe <lu4...@gmail.com>:
>
>> +1 for ignore. @ResolveComponent is still the closest solution we could
>> have. That is MyFaces Core specific feature, at least in my mind.
>>
>> 2017-09-01 14:08 GMT-05:00 Thomas Andraschko <andraschko.tho...@gmail.com
>> >:
>>
>>> +1 for ignoring it for now and open a spec issue
>>>
>>>
>>> Am Freitag, 1. September 2017 schrieb Gerhard Petracek :
>>>
>>>> @leo:
>>>>
>>>> as i said: "...we have a spec. issue here..."
>>>> if we have to follow it, we need to use @Dependent.
>>>>
>>>> if there isn't a tck-test for it, we could even ignore the written
>>>> spec. (that isn't nice, but mojarra is also doing it in some cases...).
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>>
>>>>
>>>> 2017-09-01 19:44 GMT+02:00 Leonardo Uribe <lu4...@gmail.com>:
>>>>
>>>>> Hi
>>>>>
>>>>> Use producers won't work. The reason? it is necessary to create a
>>>>> proper proxy for that injection. It is a bug in the spec, the intention 
>>>>> was
>>>>> never that, and the suggestion proposed for inject components was not
>>>>> included.
>>>>>
>>>>> Keep it simple, use el-resolver for that always.
>>>>>
>>>>> regards,
>>>>>
>>>>> Leonardo Uribe
>>>>>
>>>>> 2017-09-01 12:41 GMT-05:00 Gerhard Petracek <gpetra...@apache.org>:
>>>>>
>>>>>> hi paul,
>>>>>>
>>>>>> yes - imo it's the only useful alternative since the spec. prohibits
>>>>>> the implementation via el-resolver (for whatever reason...).
>>>>>> (at least there isn't an approach without issues.)
>>>>>>
>>>>>> + imo we should consider a config-parameter to activate the
>>>>>> el-resolver in any case...
>>>>>>
>>>>>> regards,
>>>>>> gerhard
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pnico...@us.ibm.com>:
>>>>>>
>>>>>>> Hi Gerhard,
>>>>>>>
>>>>>>> Thanks for the clarification. So you think MyFaces should use
>>>>>>> @Dependent instead of @FacesScoped and then document to ensure users are
>>>>>>> aware of the pitfalls of it?
>>>>>>>
>>>>>>> This seems to allow us to abide by the specification as well as
>>>>>>> educate our users.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Paul Nicolucci
>>>>>>>
>>>>>>> [image: Inactive hide details for Gerhard Petracek ---09/01/2017
>>>>>>> 11:43:28 AM---hi paul, in this (unfortunate) case the only (simple) 
>>>>>>> op]Gerhard
>>>>>>> Petracek ---09/01/2017 11:43:28 AM---hi paul, in this (unfortunate) case
>>>>>>> the only (simple) option is a producer-method
>>>>>>>
>>>>>>> From: Gerhard Petracek <gpetra...@apache.org>
>>>>>>> To: MyFaces Development <dev@myfaces.apache.org>
>>>>>>> Date: 09/01/2017 11:43 AM
>>>>>>>
>>>>>>> Subject: Re: JSF 2.3: Scopes of new CDI artifact in
>>>>>>> FacesScopeObjectProducer
>>>>>>> --
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

2017-09-02 Thread Gerhard Petracek

@leo:

that's correct (that you won't get a proxy per default).
that's why i suggested a manual subclass-proxy initially (subclass of the
most concrete component-class based on the lookup in the producer),
however, as mentioned before it would break once the type of the resolved
component changes in a subsequent lookup within the subclass-proxy (in
dynamic constellations) and not just the instance + e.g. a component
library uses an instanceof check. that's a rare constellation, but at least
possible in theory.
-> since all approaches with producers have at least one issue (when it
comes to injection) and there isn't really a benefit imo (compared to an
el-resolver), you could just go with the simpler solution (which introduces
less overhead). furthermore, if you just do a lazy-lookup (instead of
injecting/storing the result), you won't see a (logical) issue at all. in
the end it's the same as if you get the result from an el-resolver. the
only difference to an el-resolver (in this case) is that you could inject
the result which can lead to a side-effect (-> if you don't use injection,
you get the same result).

in any case, just using a context which leads to a proxy is just wrong and
breaks in even more cases.
(only a component-context would work, but there would be the same issue as
with a manual subclass-proxy and the implementation would introduce
a significant overhead.)

regards,
gerhard



2017-09-01 21:10 GMT+02:00 Leonardo Uribe <lu4...@gmail.com>:

> Hi Gerhard
>
> It was a point discussed in the EG mailing list. @Dependent doesn't work
> because it means there is no proper proxy, and you need one that isolates
> the bean from the component.
>
> regards,
>
> Leonardo Uribe
>
> 2017-09-01 13:37 GMT-05:00 Gerhard Petracek <gpetra...@apache.org>:
>
>> @leo:
>>
>> as i said: "...we have a spec. issue here..."
>> if we have to follow it, we need to use @Dependent.
>>
>> if there isn't a tck-test for it, we could even ignore the written spec.
>> (that isn't nice, but mojarra is also doing it in some cases...).
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2017-09-01 19:44 GMT+02:00 Leonardo Uribe <lu4...@gmail.com>:
>>
>>> Hi
>>>
>>> Use producers won't work. The reason? it is necessary to create a proper
>>> proxy for that injection. It is a bug in the spec, the intention was never
>>> that, and the suggestion proposed for inject components was not included.
>>>
>>> Keep it simple, use el-resolver for that always.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2017-09-01 12:41 GMT-05:00 Gerhard Petracek <gpetra...@apache.org>:
>>>
>>>> hi paul,
>>>>
>>>> yes - imo it's the only useful alternative since the spec. prohibits
>>>> the implementation via el-resolver (for whatever reason...).
>>>> (at least there isn't an approach without issues.)
>>>>
>>>> + imo we should consider a config-parameter to activate the el-resolver
>>>> in any case...
>>>>
>>>> regards,
>>>> gerhard
>>>>
>>>>
>>>>
>>>> 2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pnico...@us.ibm.com>:
>>>>
>>>>> Hi Gerhard,
>>>>>
>>>>> Thanks for the clarification. So you think MyFaces should use
>>>>> @Dependent instead of @FacesScoped and then document to ensure users are
>>>>> aware of the pitfalls of it?
>>>>>
>>>>> This seems to allow us to abide by the specification as well as
>>>>> educate our users.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Paul Nicolucci
>>>>>
>>>>> [image: Inactive hide details for Gerhard Petracek ---09/01/2017
>>>>> 11:43:28 AM---hi paul, in this (unfortunate) case the only (simple) 
>>>>> op]Gerhard
>>>>> Petracek ---09/01/2017 11:43:28 AM---hi paul, in this (unfortunate) case
>>>>> the only (simple) option is a producer-method
>>>>>
>>>>> From: Gerhard Petracek <gpetra...@apache.org>
>>>>> To: MyFaces Development <dev@myfaces.apache.org>
>>>>> Date: 09/01/2017 11:43 AM
>>>>>
>>>>> Subject: Re: JSF 2.3: Scopes of new CDI artifact in
>>>>> FacesScopeObjectProducer
>>>>> --
>>>>>
>>>>>
>>>>>
>>>>> hi paul,
>>>>>
>>>>> in this (unfortunate) cas

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

2017-09-01 Thread Gerhard Petracek

@leo:

as i said: "...we have a spec. issue here..."
if we have to follow it, we need to use @Dependent.

if there isn't a tck-test for it, we could even ignore the written spec.
(that isn't nice, but mojarra is also doing it in some cases...).

regards,
gerhard



2017-09-01 19:44 GMT+02:00 Leonardo Uribe <lu4...@gmail.com>:

> Hi
>
> Use producers won't work. The reason? it is necessary to create a proper
> proxy for that injection. It is a bug in the spec, the intention was never
> that, and the suggestion proposed for inject components was not included.
>
> Keep it simple, use el-resolver for that always.
>
> regards,
>
> Leonardo Uribe
>
> 2017-09-01 12:41 GMT-05:00 Gerhard Petracek <gpetra...@apache.org>:
>
>> hi paul,
>>
>> yes - imo it's the only useful alternative since the spec. prohibits the
>> implementation via el-resolver (for whatever reason...).
>> (at least there isn't an approach without issues.)
>>
>> + imo we should consider a config-parameter to activate the el-resolver
>> in any case...
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pnico...@us.ibm.com>:
>>
>>> Hi Gerhard,
>>>
>>> Thanks for the clarification. So you think MyFaces should use @Dependent
>>> instead of @FacesScoped and then document to ensure users are aware of the
>>> pitfalls of it?
>>>
>>> This seems to allow us to abide by the specification as well as educate
>>> our users.
>>>
>>> Regards,
>>>
>>> Paul Nicolucci
>>>
>>> [image: Inactive hide details for Gerhard Petracek ---09/01/2017
>>> 11:43:28 AM---hi paul, in this (unfortunate) case the only (simple) 
>>> op]Gerhard
>>> Petracek ---09/01/2017 11:43:28 AM---hi paul, in this (unfortunate) case
>>> the only (simple) option is a producer-method
>>>
>>> From: Gerhard Petracek <gpetra...@apache.org>
>>> To: MyFaces Development <dev@myfaces.apache.org>
>>> Date: 09/01/2017 11:43 AM
>>>
>>> Subject: Re: JSF 2.3: Scopes of new CDI artifact in
>>> FacesScopeObjectProducer
>>> --
>>>
>>>
>>>
>>> hi paul,
>>>
>>> in this (unfortunate) case the only (simple) option is a producer-method
>>> with @Dependent instead of @FacesScoped (which doesn't make sense at all).
>>> + we have to document that users have to be careful (if they believe
>>> that they need to use it).
>>> i still don't really see the use-case outside the context of the
>>> component itself and artifacts like validators have access to the current
>>> component anyway.
>>>
>>> regards,
>>> gerhard
>>>
>>>
>>>
>>> 2017-09-01 15:33 GMT+02:00 Paul Nicolucci <*pnico...@us.ibm.com*
>>> <pnico...@us.ibm.com>>:
>>>
>>>It looks like the JSF 2.3 spec says the following about this:
>>>
>>>5.6.3 CDI for EL Resolution
>>>If the any of the managed beans in the application have the
>>>@javax.faces.annotation.FacesConfig
>>>annotation, the ImplicitObjectELResolver from Section 5.6.2.1
>>>“Implicit Object ELResolver for Facelets and
>>>Programmatic Access” is not present in the chain. Instead, CDI is
>>>used to perform EL resolution in the same manner is
>>>in Section TABLE 5-11 “ImplicitObjectELResolver for Programmatic
>>>Access” with the following additional implicit
>>>objects:
>>>? externalContext
>>>    ? the current ExternalContext from the current FacesContext
>>>
>>>This to me means that if you have the @FacesConfig annotation in
>>>your app the Implicit ELResolver is not available and we need to use CDI 
>>> to
>>>perform the implicit object lookup. So I don't think we can depend on the
>>>ELResolver in this instance.
>>>
>>>Regards,
>>>
>>>Paul Nicolucci
>>>
>>>
>>>[image: Inactive hide details for Gerhard Petracek ---09/01/2017
>>>09:17:05 AM---yes - there are some cases which would break with 
>>> interf]Gerhard
>>>Petracek ---09/01/2017 09:17:05 AM---yes - there are some cases which 
>>> would
>>>break with interface-proxies and some with subclass-proxies.
>>>
>>>From: Gerhard Petracek <*gpetra...@apache.org* <gpetra...@apache.org>
>>>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

2017-09-01 Thread Gerhard Petracek

hi paul,

yes - imo it's the only useful alternative since the spec. prohibits the
implementation via el-resolver (for whatever reason...).
(at least there isn't an approach without issues.)

+ imo we should consider a config-parameter to activate the el-resolver in
any case...

regards,
gerhard



2017-09-01 17:59 GMT+02:00 Paul Nicolucci <pnico...@us.ibm.com>:

> Hi Gerhard,
>
> Thanks for the clarification. So you think MyFaces should use @Dependent
> instead of @FacesScoped and then document to ensure users are aware of the
> pitfalls of it?
>
> This seems to allow us to abide by the specification as well as educate
> our users.
>
> Regards,
>
> Paul Nicolucci
>
> [image: Inactive hide details for Gerhard Petracek ---09/01/2017 11:43:28
> AM---hi paul, in this (unfortunate) case the only (simple) op]Gerhard
> Petracek ---09/01/2017 11:43:28 AM---hi paul, in this (unfortunate) case
> the only (simple) option is a producer-method
>
> From: Gerhard Petracek <gpetra...@apache.org>
> To: MyFaces Development <dev@myfaces.apache.org>
> Date: 09/01/2017 11:43 AM
>
> Subject: Re: JSF 2.3: Scopes of new CDI artifact in
> FacesScopeObjectProducer
> --
>
>
>
> hi paul,
>
> in this (unfortunate) case the only (simple) option is a producer-method
> with @Dependent instead of @FacesScoped (which doesn't make sense at all).
> + we have to document that users have to be careful (if they believe that
> they need to use it).
> i still don't really see the use-case outside the context of the component
> itself and artifacts like validators have access to the current component
> anyway.
>
> regards,
> gerhard
>
>
>
> 2017-09-01 15:33 GMT+02:00 Paul Nicolucci <*pnico...@us.ibm.com*
> <pnico...@us.ibm.com>>:
>
>It looks like the JSF 2.3 spec says the following about this:
>
>5.6.3 CDI for EL Resolution
>If the any of the managed beans in the application have the
>@javax.faces.annotation.FacesConfig
>annotation, the ImplicitObjectELResolver from Section 5.6.2.1
>“Implicit Object ELResolver for Facelets and
>Programmatic Access” is not present in the chain. Instead, CDI is used
>to perform EL resolution in the same manner is
>in Section TABLE 5-11 “ImplicitObjectELResolver for Programmatic
>Access” with the following additional implicit
>objects:
>? externalContext
>? the current ExternalContext from the current FacesContext
>
>This to me means that if you have the @FacesConfig annotation in your
>app the Implicit ELResolver is not available and we need to use CDI to
>perform the implicit object lookup. So I don't think we can depend on the
>ELResolver in this instance.
>
>Regards,
>
>Paul Nicolucci
>
>
>[image: Inactive hide details for Gerhard Petracek ---09/01/2017
>09:17:05 AM---yes - there are some cases which would break with 
> interf]Gerhard
>Petracek ---09/01/2017 09:17:05 AM---yes - there are some cases which would
>break with interface-proxies and some with subclass-proxies.
>
>From: Gerhard Petracek <*gpetra...@apache.org* <gpetra...@apache.org>>
>To: MyFaces Development <*dev@myfaces.apache.org*
><dev@myfaces.apache.org>>
>Date: 09/01/2017 09:17 AM
>Subject: Re: JSF 2.3: Scopes of new CDI artifact in
>FacesScopeObjectProducer
>--
>
>
>
>
>yes - there are some cases which would break with interface-proxies
>and some with subclass-proxies. subclass-proxies would just support the
>instanceof checks used by some component-libraries, but would only work if
>just the resolved instance but not the type of the resolved instance would
>change (per dependent-scoped subclass-proxy instance).
>
>-> therefore i (still) prefer the el-resolver (if possible).
>
>please notice that even dependent-scoped beans can cause side-effects
>here (depending on the scope of the instance which stores such a
>dependent-scoped bean).
>you could only bypass possible side-effects in this special case if
>consuming instances don't store the resolved bean + use an approach like
>org.apache.deltaspike.core.api.provider.DependentProvider for them.
>-> in this case you could use injected instances only if you know all
>the implications -> resovling the instances via el-resolver is easier...
>
>regards,
>gerhard
>
>
>
>2017-09-01 14:15 GMT+02:00 Thomas Andraschko <
>*andraschko.tho...@gmail.com* <andraschko.tho...@gmail.com>>:
>   I fear that even proxies would not solve this problem as the
>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

2017-09-01 Thread Gerhard Petracek

hi paul,

in this (unfortunate) case the only (simple) option is a producer-method
with @Dependent instead of @FacesScoped (which doesn't make sense at all).
+ we have to document that users have to be careful (if they believe that
they need to use it).
i still don't really see the use-case outside the context of the component
itself and artifacts like validators have access to the current component
anyway.

regards,
gerhard



2017-09-01 15:33 GMT+02:00 Paul Nicolucci <pnico...@us.ibm.com>:

> It looks like the JSF 2.3 spec says the following about this:
>
> 5.6.3 CDI for EL Resolution
> If the any of the managed beans in the application have the
> @javax.faces.annotation.FacesConfig
> annotation, the ImplicitObjectELResolver from Section 5.6.2.1 “Implicit
> Object ELResolver for Facelets and
> Programmatic Access” is not present in the chain. Instead, CDI is used to
> perform EL resolution in the same manner is
> in Section TABLE 5-11 “ImplicitObjectELResolver for Programmatic Access”
> with the following additional implicit
> objects:
> ? externalContext
> ? the current ExternalContext from the current FacesContext
>
> This to me means that if you have the @FacesConfig annotation in your app
> the Implicit ELResolver is not available and we need to use CDI to perform
> the implicit object lookup. So I don't think we can depend on the
> ELResolver in this instance.
>
> Regards,
>
> Paul Nicolucci
>
>
> [image: Inactive hide details for Gerhard Petracek ---09/01/2017 09:17:05
> AM---yes - there are some cases which would break with interf]Gerhard
> Petracek ---09/01/2017 09:17:05 AM---yes - there are some cases which would
> break with interface-proxies and some with subclass-proxies.
>
> From: Gerhard Petracek <gpetra...@apache.org>
> To: MyFaces Development <dev@myfaces.apache.org>
> Date: 09/01/2017 09:17 AM
> Subject: Re: JSF 2.3: Scopes of new CDI artifact in
> FacesScopeObjectProducer
> --
>
>
>
> yes - there are some cases which would break with interface-proxies and
> some with subclass-proxies. subclass-proxies would just support the
> instanceof checks used by some component-libraries, but would only work if
> just the resolved instance but not the type of the resolved instance would
> change (per dependent-scoped subclass-proxy instance).
>
> -> therefore i (still) prefer the el-resolver (if possible).
>
> please notice that even dependent-scoped beans can cause side-effects here
> (depending on the scope of the instance which stores such a
> dependent-scoped bean).
> you could only bypass possible side-effects in this special case if
> consuming instances don't store the resolved bean + use an approach like
> org.apache.deltaspike.core.api.provider.DependentProvider for them.
> -> in this case you could use injected instances only if you know all the
> implications -> resovling the instances via el-resolver is easier...
>
> regards,
> gerhard
>
>
>
> 2017-09-01 14:15 GMT+02:00 Thomas Andraschko <
> *andraschko.tho...@gmail.com* <andraschko.tho...@gmail.com>>:
>
>I fear that even proxies would not solve this problem as the compoent
>classes can be different (e.g. HtmlInputText <> HtmlCommandButton).
>So the only solution is to use @Dependent which leads to worse
>performance.
>
>As you already said Gerhard, a producer doesn't make sense here.
>Neither as a ELResolver replacement, nor for using @Inject UIComponent.
>
>2017-09-01 12:25 GMT+02:00 Gerhard Petracek <*gpetra...@apache.org*
><gpetra...@apache.org>>:
>@thomas: +1
>
>if we don't need to use producers here, we should drop them again.
>(if someone would use it as a kind of "component-binding", it would be
>broken in almost every case.)
>-> the el-resolver approach mentioned by thomas is the only reliable
>way here.
>if we have to keep those producers, we have a spec. issue here and the
>best chance to limit the possible side-effects to a minimum are
>dependent-scoped instances and/or subclass-proxies which intercept all
>public method-calls to resolve the current instance lazily.
>
>regards,
>gerhard
>
>
>
>2017-09-01 9:42 GMT+02:00 Thomas Andraschko <
>*andraschko.tho...@gmail.com* <andraschko.tho...@gmail.com>>:
>   Hi,
>
>   i just checked the FacesScopeObjectProducer:
>
>  @Produces
>  @Named("component")
>  @FacesScoped
>  public UIComponent getComponent()
>  {
>  return UIComponent.getCurrentComponen
>   t(FacesContext.getCurrentInstance());
>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

2017-09-01 Thread Gerhard Petracek

yes - there are some cases which would break with interface-proxies and
some with subclass-proxies. subclass-proxies would just support the
instanceof checks used by some component-libraries, but would only work if
just the resolved instance but not the type of the resolved instance would
change (per dependent-scoped subclass-proxy instance).

-> therefore i (still) prefer the el-resolver (if possible).

please notice that even dependent-scoped beans can cause side-effects here
(depending on the scope of the instance which stores such a
dependent-scoped bean).
you could only bypass possible side-effects in this special case if
consuming instances don't store the resolved bean + use an approach like
org.apache.deltaspike.core.api.provider.DependentProvider for them.
-> in this case you could use injected instances only if you know all the
implications -> resovling the instances via el-resolver is easier...

regards,
gerhard



2017-09-01 14:15 GMT+02:00 Thomas Andraschko <andraschko.tho...@gmail.com>:

> I fear that even proxies would not solve this problem as the compoent
> classes can be different (e.g. HtmlInputText <> HtmlCommandButton).
> So the only solution is to use @Dependent which leads to worse performance.
>
> As you already said Gerhard, a producer doesn't make sense here.
> Neither as a ELResolver replacement, nor for using @Inject UIComponent.
>
> 2017-09-01 12:25 GMT+02:00 Gerhard Petracek <gpetra...@apache.org>:
>
>> @thomas: +1
>>
>> if we don't need to use producers here, we should drop them again.
>> (if someone would use it as a kind of "component-binding", it would be
>> broken in almost every case.)
>> -> the el-resolver approach mentioned by thomas is the only reliable way
>> here.
>> if we have to keep those producers, we have a spec. issue here and the
>> best chance to limit the possible side-effects to a minimum are
>> dependent-scoped instances and/or subclass-proxies which intercept all
>> public method-calls to resolve the current instance lazily.
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2017-09-01 9:42 GMT+02:00 Thomas Andraschko <andraschko.tho...@gmail.com>
>> :
>>
>>> Hi,
>>>
>>> i just checked the FacesScopeObjectProducer:
>>>
>>>@Produces
>>>@Named("component")
>>>@FacesScoped
>>>public UIComponent getComponent()
>>>{
>>>return UIComponent.getCurrentComponen
>>> t(FacesContext.getCurrentInstance());
>>>}
>>>
>>>@Produces
>>>@Named("cc")
>>>@FacesScoped
>>>public UIComponent getCompositeComponent()
>>>{
>>>return UIComponent.getCurrentComposit
>>> eComponent(FacesContext.getCurrentInstance());
>>>}
>>>
>>> I wonder if this is this the right scope for it?
>>> Shoudln't it be @Dependendent as the component changes multiple times?
>>> Not sure about the performance then... I think it would be perform much
>>> slower as in 2.2.
>>> Does 2.3 force us to use @Named instead ElResolver for it?
>>>
>>> Regards,
>>> Thomas
>>>
>>
>>
>

Re: JSF 2.3: Scopes of new CDI artifact in FacesScopeObjectProducer

2017-09-01 Thread Gerhard Petracek

@thomas: +1

if we don't need to use producers here, we should drop them again.
(if someone would use it as a kind of "component-binding", it would be
broken in almost every case.)
-> the el-resolver approach mentioned by thomas is the only reliable way
here.
if we have to keep those producers, we have a spec. issue here and the best
chance to limit the possible side-effects to a minimum are dependent-scoped
instances and/or subclass-proxies which intercept all public method-calls
to resolve the current instance lazily.

regards,
gerhard



2017-09-01 9:42 GMT+02:00 Thomas Andraschko :

> Hi,
>
> i just checked the FacesScopeObjectProducer:
>
>@Produces
>@Named("component")
>@FacesScoped
>public UIComponent getComponent()
>{
>return UIComponent.getCurrentComponent(FacesContext.
> getCurrentInstance());
>}
>
>@Produces
>@Named("cc")
>@FacesScoped
>public UIComponent getCompositeComponent()
>{
>return UIComponent.getCurrentCompositeComponent(FacesContext.
> getCurrentInstance());
>}
>
> I wonder if this is this the right scope for it?
> Shoudln't it be @Dependendent as the component changes multiple times?
> Not sure about the performance then... I think it would be perform much
> slower as in 2.2.
> Does 2.3 force us to use @Named instead ElResolver for it?
>
> Regards,
> Thomas
>

Re: Migrate all MyFaces projects to Git

2017-04-20 Thread Gerhard Petracek

hi @ all,

just fyi:
[1] works very well for ds since the beginning.

regards,
gerhard

[1] https://deltaspike.apache.org/suggested-git-workflows.html



2017-04-19 14:45 GMT+02:00 Kito Mann :

> Hello Bernd,
>
> I like GitFlow for coordinating with multiple developers. However, if
> everyone is sending pull requests anyway, it's not quite as useful. It
> makes sense when you have multiple developers that are committing to a
> "develop" branch and provides guidelines for working with master for new
> releases and hot fixes.
>
> ___
>
> 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 <(203)%20998-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 8:38 AM, Bernd Bohmann <
> bernd.bohm...@googlemail.com> wrote:
>
>> Until now, nobody could explain me the real technical improvement of
>> GitFlow.
>> We are talking about using git and not GitFlow. Git does not require
>> GitFlow
>>
>> At Apache we are only using process as much as needed and not as possible!
>> And my personal advice is:
>> Start with a model as simple as possible.
>>
>> Regards
>>
>> Bernd
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Apr 19, 2017 at 12:57 PM, Kito Mann  wrote:
>>
>>> +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 <(203)%20998-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 <
>>> bernd.bohm...@googlemail.com> 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
> 
> <#m_-6826021186946778376_m_-135240448576325838_m_-1665615671155989291_m_312095376341812428_m_228356912083513587_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> 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 <
>> bernd.bohm...@atanion.com> 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" <
>>> andraschko.tho...@gmail.com>:
>>>
 +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-12 Thread Gerhard Petracek

hi mike,

for CODI such a hint is in place since 2013 (see the bold red text in the
first line at [1]).

regards,
gerhard

[1] https://cwiki.apache.org/confluence/display/EXTCDI/Index



2016-10-12 21:09 GMT+02:00 Mike Kienenberger :

> 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: [core] release plans for MyFaces Core 2.2.10, 2.1.18 and 2.0.24

2016-03-15 Thread Gerhard Petracek

+1

regards,
gerhard



2016-03-14 21:19 GMT+01:00 Leonardo Uribe :

> Hi
>
> I think this is a good time to run a release for MyFaces Core 2.2.10,
> 2.1.18 and 2.0.24, maybe starting at the end of this week.
>
> If there are pending issues this is a good time to say it.
>
> regards,
>
> Leonardo Uribe
>

Re: Trinidad 2.1.1 Release Plans

2016-01-13 Thread Gerhard Petracek

+1 for starting the vote (as it is right now).

regards,
gerhard



2016-01-13 2:48 GMT+01:00 Leonardo Uribe :

> Hi
>
> I have run the release process and it works, so we can send a vote at any
> time we want. I would like to do a release soon, but I think we can wait a
> little.
>
> regards,
>
> Leonardo
>
> 2016-01-12 18:31 GMT-05:00 Mike Kienenberger :
>
>> Leonardo,
>>
>> That is an excellent idea, and I was planning on suggesting something
>> similar.  Thank you!
>>
>> However, there are some recent issues that I would like to see dealt
>> with, particularly 2531, which seems to indicate that the patch for
>> 2525 may have introduced other issues.
>>
>> Can we give it a couple of weeks and see if any of the issues to which
>> I've just added comments generates a response?
>>
>> On Tue, Jan 12, 2016 at 6:26 PM, Leonardo Uribe  wrote:
>> > Hi
>> >
>> > I would like to do a release of trinidad 2.1.1. I'm checking if the
>> release
>> > process is working and it looks good. So just one question: is there any
>> > pending issue we need to solve before release?
>> >
>> > regards,
>> >
>> > Leonardo Uribe
>>
>
>

Re: cwiki permissions

2015-12-15 Thread Gerhard Petracek

hi @ all,

thomas has all permissions which are available.
however, (as far as i was told) the roles which are (still) in place are
deprecated/read-only (because they shouldn't be used any longer).

regards,
gerhard



2015-12-15 15:07 GMT+01:00 Mike Kienenberger :

> Thomas Andraschko commented on MYFACES-4012:
> > [~mkienenb] Would you please check my wiki role? I would like to change
> it but AFAICS i have no edit role.
>
> There is a myfaces-committers entry with all permissions set.
> I have no idea how to add people to that entry, and a search on "apache
> cwiki permissions" only shows setting up individual permissions.I've
> gone ahead and added tandraschko with full permissions.
>

Re: Request for comments on Myfaces project statuses

2015-10-06 Thread Gerhard Petracek

@mark: +1

regards,
gerhard



2015-10-06 9:44 GMT+02:00 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: MyFaces Core Issue Tracker Cleanup

2015-08-20 Thread Gerhard Petracek

+1

regards,
gerhard



2015-08-20 11:00 GMT+02:00 Thomas Andraschko andraschko.tho...@gmail.com:

 Hi,

 i would invest some hours to do a big cleanup of our issue tracker.
 There are tickets available which are 10 years old!
 I think such a cleanup is really required. AFAIR mojarra did the same some
 months ago.

 I would do the following:

 1) Close every issue older than 2010. The most issues still targets 1.x.
 It's a litte bit hard to just close them but nobody will take care of them
 in the future.
 I would close them with a comment similiar like: Outdated, please reopen
 if still interessted/required.

 2) Close duplicate issues

 3) Close improvements/enhancements tickets without a patch which targets
 1.x - 2.1 (e.g. https://issues.apache.org/jira/browse/MYFACES-3402)

 4) Close issues without feedback - same comment as 1)

 5) Close issues which are untouched and feedback would be required - same
 comment as 1) (e.g. https://issues.apache.org/jira/browse/MYFACES-3670)

 Maybe each commiter could also go through his own tickets and close them
 if not required anymore (e.g. like
 https://issues.apache.org/jira/browse/MYFACES-2635 ?)

 WDYT?

Re: [COMMUNITY] Thomas Andraschko - Committer

2015-07-03 Thread Gerhard Petracek

welcome!

regards,
gerhard



2015-07-02 23:16 GMT+02:00 Mike Kienenberger mkien...@gmail.com:

 The MyFaces PMC is proud to announce a new addition to our community.

 Please welcome Thomas Andraschko as the newest MyFaces committer!
 Thomas is a long-time active member of the MyFaces community,
 especially in MyFaces Core, and has worked in the past on MyFaces
 External Validator and MyFaces Extensions CDI.   Thomas is also part
 of the Apache DeltaSpike community, a related JSF project at the
 Apache Software Foundation.

 Welcome  regards,
 Mike

Re: usage of notifications mailing list

2015-05-29 Thread Gerhard Petracek

@mike:
yes - that was the reason (+ back then ~nobody reacted on notifications
about broken builds which were sent to the notifications-list).

regards,
gerhard



2015-05-29 13:05 GMT+02:00 Udo Schnurpfeil u...@schnurpfeil.de:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 Hi,

 I think its reasonable to distinct:

 Jenkins sends only mails for failed builds and when the build is
 stable again.

 So, I might be interested in knowing that builds are stable, but don't
 want to see all commits.

 Regards,

 Udo

 Am 29.05.15 um 12:53 schrieb Mike Kienenberger:
  I don't have any direct experience with the change, but my guess
  would be that it didn't seem necessary to have both a commits@
  notification list and a [builds] notifications@ list since they are
  directly related.  If you are interested in seeing code change
  notifications, you are also interested in knowing if those code
  changes are going to break something.
 
  On Fri, May 29, 2015 at 3:24 AM, Dennis Kieselhorst
  m...@dekies.de wrote:
  Hi,
 
  we have a notifications list (notificati...@myfaces.apache.org)
  which was used for Continuum build mails in the past. However
  with switch to Jenkins build notifications are sent to
  comm...@myfaces.apache.org. Does anyone know why this was
  changed?
 
  Cheers Dennis
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
 Comment: GPGTools - https://gpgtools.org

 iQIcBAEBCgAGBQJVaEfgAAoJEAEbRra2zTKAXBQP/263m/8VSPY799FvrAYcKDsw
 SfTFLYfdubh+URiKlxPFxFIKnKNU1fhriaX5DKXzG8evAw/K5LAVur1E1g3DJpHv
 TnL7jY7t5hu6pQVEMMH5pok0bSmoyp4szD+LfSYb3WxOOQaYFUN0SHvgPoEaXFrh
 7FB/ThNo3FjIsX9b2OWXsFIHc749O6cyK9XmFyMjTubHWaihYJQsVF9A+sgACDKv
 DcZ6Ev0lYohxA/xtdVwE7cijnupZSkawxdX/YXEEetybBcB4t9GeU//1+8JWMZuW
 qmQA3azlw8XE+Qi6eJYlYKAyNC1J2ptxy/86wnLMMP7hdcGx1PL7FrqjtTjeBvv+
 q3xRlj6tNEdp9K3tMdP8aqXzhL5u+1quO8CMBJ/Wz25PxFpB3C6VeCEv8T9GppS4
 7XTddIkiAMv9qGuXklAFbvQwndCwIWgRbtBLgOqQ6T9BvOGuHkP4xhEBVUf0DHRN
 n5YWdNm5N10aBpraXUi2Mm8B+c5fu4U9LXQc+NOpUb/Dy4QPx5Q8cDC1DTiLp9P7
 JXI6ZhKF4YG4F/VpCNJzR05+OIJdvOz9GadMadyebZfAOYqnqwvULRtdsjJ29h6C
 B4Sz2LiOWOoZkacsoDpGuS2HQJEtqA7Oo9Mc7OLxd3O27o7o+VA91kj3LeUgpXrA
 ZucflsZCJ7jPlM9o7een
 =9cDd
 -END PGP SIGNATURE-

Re: MyFaces Jira administrator permissions

2015-05-12 Thread Gerhard Petracek

hi mike,

you are jira administrator for myfaces already.

regards,
gerhard



2015-05-12 16:14 GMT+02:00 Mike Kienenberger mkien...@gmail.com:

 Who in MyFaces has the Jira Administrator permission?
 I need to be added to that group.

 I guess if I don't hear from anyone in the next day or two, I will
 assume those with that privilege are no longer active and submit an
 INFRA issue to have myself added.

PMC chair rotation

2015-05-03 Thread Gerhard Petracek

Hi @ all,

I'm stepping back from being the Apache MyFaces PMC chair, because it's
time for a rotation after four years!

As usual there was an internal vote and the result was approved by the ASF
board during the previous meeting.

- Please join me in welcoming our new PMC chair: Mike Kienenberger

Regards,
Gerhard

Re: MyFaces 2.2.8 release

2015-03-27 Thread Gerhard Petracek

+1

regards,
gerhard



2015-03-27 15:04 GMT+01:00 Leonardo Uribe lu4...@gmail.com:

 Hi

 Yes, I was thinking the same. I hope to start the release process next
 week.

 regards,

 Leonardo Uribe

 2015-03-27 2:46 GMT-05:00 Dennis Kieselhorst m...@dekies.de:
  Hi,
 
  I suggest to do a 2.2.8 release soon. Although there is a workaround for
  MYFACES-3948, several devs told me that latest MyFaces release is
 unusable
  for them. And everybody who is not aware of that issue spends time in
  analyzing and fixing it. We already have five duplicates.
 
  Cheers
  Dennis
 
 
 
  --
  View this message in context:
 http://myfaces.10567.n7.nabble.com/MyFaces-2-2-8-release-tp119589.html
  Sent from the My Faces - Dev mailing list archive at Nabble.com.

[jira] [Resolved] (EXTCDI-317) @ViewAccessScope with faces-redirect=true

2014-12-10 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-317.
-
Resolution: Won't Fix

that's a known issue and should be fixed with wls 12.1.3 (and not a bug in 
codi).
at least apache deltaspike was tested with it.
it sounds like you are starting to use codi - in that case you should move to 
deltaspike (also this scope is ported to deltaspike already).
if you have to stick with wls 12.1.2, it won't be the last issue you will face 
(most blockers are fixed in 12.1.3 and tested with deltaspike).

 @ViewAccessScope with faces-redirect=true
 -

 Key: EXTCDI-317
 URL: https://issues.apache.org/jira/browse/EXTCDI-317
 Project: MyFaces CODI
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.6
 Environment: Windows 7
 WebLogic 12.1.2.0
Reporter: Kua Yan Xu
 Attachments: javaee-redirect.zip

   Original Estimate: 168h
  Remaining Estimate: 168h

 Hi,
 I had create a simple application which have a page bean with a variable.
 In index.xhtml page, I have a button to set the variable to some value, and 
 another button to redirect to a new xhtml page using faces-redirect=true.
 When in GlassFish, the newly set variable value is display in the new page, 
 but not in WebLogic server.
 I can provide the simple application for you to test with.
 Regards,
 Yanxu



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

[jira] [Commented] (EXTCDI-317) @ViewAccessScope with faces-redirect=true

2014-12-10 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTCDI-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14240874#comment-14240874
 ] 

Gerhard Petracek commented on EXTCDI-317:
-

afaik the patch for 12.1.3 was backported to 12.1.2. you have to ask them, if 
they provide it officially.
however, in any case i would upgrade to 12.1.3 asap.

 @ViewAccessScope with faces-redirect=true
 -

 Key: EXTCDI-317
 URL: https://issues.apache.org/jira/browse/EXTCDI-317
 Project: MyFaces CODI
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.6
 Environment: Windows 7
 WebLogic 12.1.2.0
Reporter: Kua Yan Xu
 Attachments: javaee-redirect.zip

   Original Estimate: 168h
  Remaining Estimate: 168h

 Hi,
 I had create a simple application which have a page bean with a variable.
 In index.xhtml page, I have a button to set the variable to some value, and 
 another button to redirect to a new xhtml page using faces-redirect=true.
 When in GlassFish, the newly set variable value is display in the new page, 
 but not in WebLogic server.
 I can provide the simple application for you to test with.
 Regards,
 Yanxu



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

[jira] [Commented] (EXTCDI-317) @ViewAccessScope with faces-redirect=true

2014-12-05 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTCDI-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14235407#comment-14235407
 ] 

Gerhard Petracek commented on EXTCDI-317:
-

please provide the concrete version of wls you are using.

 @ViewAccessScope with faces-redirect=true
 -

 Key: EXTCDI-317
 URL: https://issues.apache.org/jira/browse/EXTCDI-317
 Project: MyFaces CODI
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.6
 Environment: Windows 7
 WebLogic 12.1.2.0
Reporter: Kua Yan Xu
 Attachments: javaee-redirect.zip

   Original Estimate: 168h
  Remaining Estimate: 168h

 Hi,
 I had create a simple application which have a page bean with a variable.
 In index.xhtml page, I have a button to set the variable to some value, and 
 another button to redirect to a new xhtml page using faces-redirect=true.
 When in GlassFish, the newly set variable value is display in the new page, 
 but not in WebLogic server.
 I can provide the simple application for you to test with.
 Regards,
 Yanxu



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

[jira] [Comment Edited] (EXTCDI-317) @ViewAccessScope with faces-redirect=true

2014-12-05 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTCDI-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14235407#comment-14235407
 ] 

Gerhard Petracek edited comment on EXTCDI-317 at 12/5/14 12:09 PM:
---

please try it with wls 12.1.3


was (Author: gpetracek):
please provide the concrete version of wls you are using.

 @ViewAccessScope with faces-redirect=true
 -

 Key: EXTCDI-317
 URL: https://issues.apache.org/jira/browse/EXTCDI-317
 Project: MyFaces CODI
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.6
 Environment: Windows 7
 WebLogic 12.1.2.0
Reporter: Kua Yan Xu
 Attachments: javaee-redirect.zip

   Original Estimate: 168h
  Remaining Estimate: 168h

 Hi,
 I had create a simple application which have a page bean with a variable.
 In index.xhtml page, I have a button to set the variable to some value, and 
 another button to redirect to a new xhtml page using faces-redirect=true.
 When in GlassFish, the newly set variable value is display in the new page, 
 but not in WebLogic server.
 I can provide the simple application for you to test with.
 Regards,
 Yanxu



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

Re: Not able to access source repository

2014-12-04 Thread Gerhard Petracek

hi prakash,

it should be fine again soon (see [1]).

regards,
gerhard

[1]
https://blogs.apache.org/infra/entry/subversion_master_undergoing_emergency_maintenance



2014-12-04 20:47 GMT+01:00 Prakash Udupa prakash.ud...@oracle.com:

  Hi,

 I get the following error when trying to checkout sources from Trinidad
 trunk:

 

 Command: Checkout from
 https://svn.apache.org/repos/asf/myfaces/trinidad/trunk, revision HEAD,
 Fully recursive, Externals included
 Error: Unable to connect to a repository at URL
 Error:  'https://svn.apache.org/repos/asf/myfaces/trinidad/trunk'
 Error: Server sent unexpected return value (502 cannotconnect) in response
 to OPTIONS
 Error:  request for '
 https://svn.apache.org/repos/asf/myfaces/trinidad/trunk'
 Completed!:

 

 The HTTP diff / revision checking tool is also not working, for example
 this link...
 http://svn.apache.org/viewvc?view=revisionrevision=1600529

 If the server is down, can someone that has access please bring it up.

 Thanks,
 Prakash

[jira] [Commented] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page

2014-09-19 Thread Gerhard Petracek (JIRA)

[
https://issues.apache.org/jira/browse/EXTCDI-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14140330#comment-14140330
]

Gerhard Petracek commented on EXTCDI-316:
-

please don't mix the view-scope (@ViewScoped) and the codi scopes (per window):
@WindowScoped, @ConversationScoped, @ViewAccessScoped.
the bridge for the view-scope just transforms a jsf-bean to a cdi bean and via
a PreDestroyViewMapEvent listener codi gets notified by the jsf-implementation
to destroy the corresponding cdi-beans. however, afair esp. mojarra used to
have issues with those events in the beginning - so i wouldn't use it before
ee7 (which supports that out-of-the-box and has to handle it internally).

#closeWindowContext is just a helper to do a full cleanup including the
component-tree. in deltaspike we don't have that any longer to keep it simpler.

@timeout:
yes and no - if the user-session gets closed (due to a timeout or manually) all
those codi-scoped beans get dropped as well.
however, there is e.g. also a window-timeout which is shorter than the
session-timeout (usually - see
WindowContextConfig#getWindowContextTimeoutInMinutes). in deltaspike we dropped
that as well - there you only have the session-timeout which destroys the
windows as well.

yes @WindowScoped (and WindowContext) can get to a session per browser-tab
easily. that is the use-case for it/them. therefore you have
@ConversationScoped and @ViewAccessScoped which are more fine-grained. using
@WindowScoped isn't that usual compared to the other two scopes (which are also
stored in the current window and therefore support the window-id implicitly -
see e.g.
https://cwiki.apache.org/confluence/display/EXTCDI/JSF+Usage#JSFUsage-Scopes).
@WindowScoped helps e.g. if you like to store the nav.history per window or the
menu-state independent of the component-tree. WindowContext is just the storage
per window you (as user) usually don't need to touch manually. (you just need
it to handle your use-case with iframes.)

you could introduce a new url-parameter and add it on the client-side once you
replace the iframe-content there. something like oldWindowIdToDrop - just
destroy the window on the server-side via a phase-listener (or in your own
WindowHandler) once you detect your custom url-parameter.

Close window context view leakge - JSF 2.1 Multiple Iframes per page

Key: EXTCDI-316
URL: https://issues.apache.org/jira/browse/EXTCDI-316
Project: MyFaces CODI
Issue Type: Bug
Components: Core
Affects Versions: 1.0.3
Environment: Oracle GlassFish Server 3.1.2.5 (build 2), jdk1.6.0_45
Reporter: Nuno G. de M
Original Estimate: 72h
Remaining Estimate: 72h

[jira] [Commented] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page

2014-09-18 Thread Gerhard Petracek (JIRA)

[
https://issues.apache.org/jira/browse/EXTCDI-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14138666#comment-14138666
]

Gerhard Petracek commented on EXTCDI-316:
-

no - that's the reason i didn't mention it (mojarra vs. myfaces-core).
codi is compatible with both and we know users with huge codi/jsf (with
mojarra) based projects.
leo just mentioned that myfaces-core is smarter when it comes to state-saving
and the chance is higher that you won't see (some of) the issues you saw with
mojarra caused by the usage of iframes.
e.g. once the fallback to WindowContextIdHolderComponent is used to resolve the
window-id, the proper handling depends on the quality of the state-saving
algorithm (provided by the jsf implementation).

once you call #close for the correct window manually, you don't see a leak in
codi.
however, since there is no jsf-api for it, codi can't trigger a cleanup of the
view-state.
jsf 2.2 introduced the window-concept (based on apis introduced by codi and
similar frameworks).
however, even with jsf 2.2, the jsf implementation is responsible for doing a
cleanup of the state internally (there is no explicit api for it).
the benefit for users is that the jsf implementation is aware of windows (as a
concept) and can do improvements (more easily) for handling the state in a
better way (but there is no specified rule for it).

@iframes:
it sounds like the major issue in your case is that you replace the content
of the iframe on the client-side.
a lot really depends on details of your implementation and maybe even on other
details like the used browser (you wouldn't belief how hard it is to support
something simple like the proper handling after open in new tab across the
major browsers).

Close window context view leakge - JSF 2.1 Multiple Iframes per page

[jira] [Commented] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page

2014-09-17 Thread Gerhard Petracek (JIRA)

[
https://issues.apache.org/jira/browse/EXTCDI-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14137035#comment-14137035
]

Gerhard Petracek commented on EXTCDI-316:
-

i'm not sure about all the details you have in your application.

if you need such manual manipulations (on the client-side), you have to ensure
(yourself) that those changes are recognized correctly (and immediately) on
the server-side. further hints for implementing a custom WindowHandler for your
setup are quite hard to provide without a (maven based) demo-app which
illustrates the details of your setup (and even then it won't be a easy task
since the std. cases for window-handling are quite complex already). some parts
you need should be in the wiki - e.g. see
https://cwiki.apache.org/confluence/display/EXTCDI/Alternative+Configuration#AlternativeConfiguration-Providingotheralternativeimplementations
the contract specified by WindowHandler is quite simple, however, a proper
implementation for your cases isn't an easy task.
imo you have to fix the state-saving issues first. otherwise you have almost no
chance to get a solid result.
(e.g. you would get issues with WindowContextIdHolderComponent and many other
topics).

Close window context view leakge - JSF 2.1 Multiple Iframes per page

Hi, and thank you for your support.
First, I would just like to stat that I am unsure if the issue detected in
our application is a real issue within CODI, or if it is we that are misusing
the framework. Therefore, I would be happy to get your input on the issue I
am about to detail.
ISSUE SUMMARY:
- we have a ui architecture comprised by several Iframes within a main page,
where each iframe has its own CODI window context. After several clicks
replacing the content that of a targetIfram by new content, we were having
CODI view context leakage as well as JSF view state leakage.
ISSUE DETAILS:
For historical as well performance reasons reasons, we have a UI that is
composed into several IFrames within a parent portal iframe. This decomposing
of the view into sub-views means the JSF context to serialize-deserialize per
iframe/.xhtml present in the UI is smaller. As opposed to a single big-ui
view state.
An overview of the core iframes invovled would be:
(1) window.top - Contains the Header and a left-side navigation menu
(2) window.top.contentIfram - Iframe Contains your typical page conent
(.xhtml)
(3) window.top.footer - iframe containing a dynamic footer (its own .xhtml)
(4) wintow.top.applet - Iframe that includes an applet
(5) window.top.special - an auxiliary .xhtml that complements the applet data
(6) window.top.clean - iframe that contains an .xhtml to do CODI window
context and JSF sever state cleanup (created to deal with the issue being
explained here)
The BUG in view navigation is the following:
Each time the user interacts with the UI, e.g by clicing on an menu command
button, or on a applet view element, prompting for a new .xhtml view to be
loaded and replace the old .xhtml loaded on a target iframe we leak both a
JSF and CODI window context.
Our steps are the following:
(1) we change the src of the iframe to point to the new view to be loaded
e.g iframe.src = 'urlTonewPageToBeLoaded.xhtml?requestViewParameters'
In this request we do not inclode the old windowId of the iframe being
replaced. Meaning codi will have to create a new view ID for this new page
load.
(2) We also trigger an ajax request to server to have the old codi window
context being closed.
Intially here did:
(2.1)WindowContext wContext =
windowContextManager.getWindowContext('windowIdToClose);
wContext.close()
It turns out that as we did these two steps we had two leakages.
After about 64 clicks on the applet, if we interatcted with views that the
applet had been loading we would have no issues. If we clicked on some of
the older views that had been loaded after the login and not interacted with
since then (e.g. the footer) we would have a view timeout exception.
This happened because with each new iframe.src='newView', CODI was not
cleaning up its window context map, namely the following line:
this.windowContextMap.remove(editableWindowContext.getId());
is not executed during a WindowContext.close().
So despite our class to close the window context, the map would continue to
hold the view just closed. After 64 clicks the view uffer of CODI would

[jira] [Resolved] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page

2014-09-17 Thread Gerhard Petracek (JIRA)

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

Gerhard Petracek resolved EXTCDI-316.
-
Resolution: Won't Fix

reason:
we could just support such use-cases with a separated WindowHandler (like it's
done with ServerSideWindowHandler, ClientSideWindowHandler). however, an
implementation would depend a lot on the manipulation (and its details) used on
the client-side and therefore we can't provide a generic solution for it.

Close window context view leakge - JSF 2.1 Multiple Iframes per page

[jira] [Resolved] (EXTCDI-175) introduce @ViewParam annotation for page beans

2014-09-17 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-175.
-
Resolution: Won't Fix

 introduce @ViewParam annotation for page beans
 --

 Key: EXTCDI-175
 URL: https://issues.apache.org/jira/browse/EXTCDI-175
 Project: MyFaces CODI
  Issue Type: New Feature
Reporter: Mark Struberg

 When using the ViewConfig in CODI we not only get type safe navigation but 
 also know the 'connection' between views and their backing beans. We already 
 support annotations like @PreRenderView and likes for such beans. 
 We should also support the direct annotation of view parameters directly in 
 the backing beans.
 instead of declaring the view parameters in the xhtml:
 f:metadata
   f:viewParam id=versionParam name=version 
 value=#{backingbean.versionString} required=false/
   f:viewParam id=searchString name=s value=#{backingbean.searchString} 
 required=false/
 /f:metadata
 we can maybe use an annotation directly in the backing bean:
 @Named
 @RequestScoped
 public class Backingbean {
   @ViewParam(required=false, name=version)
   private String versionString;
   @ViewParam(required=false, name=s)
   private String searchString;
   @PreRenderView
   private void dosomeinit() {
   ...
   }
 }



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

[jira] [Commented] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page

2014-09-16 Thread Gerhard Petracek (JIRA)

[
https://issues.apache.org/jira/browse/EXTCDI-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136267#comment-14136267
]

Gerhard Petracek commented on EXTCDI-316:
-

#1 if your view-state leaks, it's the first indication that your approach is
just not correct for jsf.
#2 codi doesn't support multiple logical pages per physical page (per default).
however, you can provide your own approach with a custom
org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.spi.WindowHandler
#3 the number of windows (per user-session) is restricted by
WindowContextConfig#getMaxWindowContextCount - per default 64 windows per
session are allowed. - the eldest window in the session gets closed to get a
free slot for the new window. you can change this default (just provide a
specialized WindowContextConfig or implement a custom
WindowContextQuotaHandler).

Close window context view leakge - JSF 2.1 Multiple Iframes per page

[jira] [Commented] (EXTVAL-161) ExtVal breaks JSF 2.2 ClientWindow support

2014-06-28 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTVAL-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14046952#comment-14046952
 ] 

Gerhard Petracek commented on EXTVAL-161:
-

right now we don't have a version for 2.2.
as you said - there are some incompatible spec changes and therefore we need a 
separated version.

 ExtVal breaks JSF 2.2 ClientWindow support
 --

 Key: EXTVAL-161
 URL: https://issues.apache.org/jira/browse/EXTVAL-161
 Project: MyFaces Extensions Validator
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.8
Reporter: Moritz Bechler
Assignee: Gerhard Petracek
Priority: Critical
 Attachments: EXTVAL-161.patch


 ExtValLifecycleWrapper implements a wrapper for Lifecycle and lacks the 
 attachWindow method. Therefore calls to attachWindow never get delegated. 



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

[ANNOUNCE] Release of Apache MyFaces Extensions Validator 2.0.8

2014-06-26 Thread Gerhard Petracek

The Apache MyFaces team is pleased to announce the 8th release of
Apache MyFaces Extensions Validator (for JSF 2.x).

Apache MyFaces Extensions Validator is an extensible framework to validate
user input based on annotations.

The release contains several improvements.

Apache MyFaces Extensions Validator is available in both binary and source
distributions:
http://myfaces.apache.org/extensions/validator/download.html

Apache MyFaces Extensions Validator is available in the central Maven
repository under
Group ID org.apache.myfaces.extensions.validator.*.

Release Notes:
http://s.apache.org/EXTVAL_208

Enjoy!

Gerhard Petracek

Result (was: Re: [VOTE] Release of Extensions Validator 2.0.8)

2014-05-31 Thread Gerhard Petracek

thank you for voting!

4 binding +1 votes (pmc):
 - Werner Punz
 - Jakob Korherr
 - Grant Smith
 - Gerhard Petracek

1 non-binding +1 votes:
 - Hazem Saleh

no -1 votes

regards,
gerhard



2014-05-27 8:29 GMT+02:00 Gerhard Petracek gpetra...@apache.org:

 Hi,

 we were running the needed tasks to get the 8th release of Apache MyFaces
 Extensions Validator out.
 The artifacts are deployed to Nexus [1].

 The release contains the following modules for JSF 2.x:
  - ExtVal Core
  - ExtVal Property-Validation
  - ExtVal Bean-Validation
  - Trinidad-Support-Module
  - Generic-Support-Module

 Please take a look at the 2.0.8 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-1024/org/apache/myfaces/extensions/validator/
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes

[jira] [Commented] (EXTVAL-159) Duplicate NotNull Validation of Primefaces-SelectOneMenu

2014-05-31 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTVAL-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14014569#comment-14014569
 ] 

Gerhard Petracek commented on EXTVAL-159:
-

i haven't tried it, however, you could try to use 
http://sandbox890.googlecode.com/svn/trunk/addons/uniqueValidationMessage/ for 
now.

 Duplicate NotNull Validation of Primefaces-SelectOneMenu
 

 Key: EXTVAL-159
 URL: https://issues.apache.org/jira/browse/EXTVAL-159
 Project: MyFaces Extensions Validator
  Issue Type: Bug
  Components: Bean Validation
Affects Versions: 2.0.7
 Environment: Java 7, JBoss AS 7.1.3, Primefaces 4.0
Reporter: Martin Steinbauer
Assignee: Gerhard Petracek
 Attachments: test-jsf-extval.zip


 The bean validation displays the error-message twice, if it validates a 
 Primefaces-SelectOneMenu and a @NotNull annotation is present on the 
 property. 
 {code}
 @NotNull
 private String selectedItemP;
 @NotNull
 private String selectedItemH;
 {code}
 {code}
 h:outputLabel for=pf value=SelectMenue PF /
 p:selectOneMenu id=pf value=#{validationBean.selectedItemP}
   f:selectItem itemLabel= no selection  noSelectionOption=true /
   f:selectItems value=#{validationBean.items} /
 /p:selectOneMenu
 h:outputLabel for=jsf value=SelectMenue JSF /
 h:selectOneMenu id=jsf value=#{validationBean.selectedItemH}
   f:selectItem itemLabel= no selection  noSelectionOption=true/
   f:selectItems value=#{validationBean.items} /
 /h:selectOneMenu
 {code}
 This behaviour does not occur using the JSF-SelectOneMenu and also if the 
 PF-Menu is replaced with a PF-InputText.
 In those cases the validation displays only one error message.



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

[jira] [Resolved] (EXTVAL-159) Duplicate NotNull Validation of Primefaces-SelectOneMenu

2014-05-31 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTVAL-159.
-

Resolution: Won't Fix

primefaces is creating a renderer in a renderer.

see SelectOneMenuRenderer#getConvertedValue
calls
context.getRenderKit().getRenderer(javax.faces.SelectOne, 
javax.faces.Menu).getConvertedValue(...);

we could only fix that by inspecting the callstack (in 
ExtValRenderKit#createWrapper) which introduces an overhead. since both 
(primefaces as well as extval) are using tricks, one side needs to improve it. 
please reopen this ticket, if they can't change it.

 Duplicate NotNull Validation of Primefaces-SelectOneMenu
 

 Key: EXTVAL-159
 URL: https://issues.apache.org/jira/browse/EXTVAL-159
 Project: MyFaces Extensions Validator
  Issue Type: Bug
  Components: Bean Validation
Affects Versions: 2.0.7
 Environment: Java 7, JBoss AS 7.1.3, Primefaces 4.0
Reporter: Martin Steinbauer
Assignee: Gerhard Petracek
 Attachments: test-jsf-extval.zip


 The bean validation displays the error-message twice, if it validates a 
 Primefaces-SelectOneMenu and a @NotNull annotation is present on the 
 property. 
 {code}
 @NotNull
 private String selectedItemP;
 @NotNull
 private String selectedItemH;
 {code}
 {code}
 h:outputLabel for=pf value=SelectMenue PF /
 p:selectOneMenu id=pf value=#{validationBean.selectedItemP}
   f:selectItem itemLabel= no selection  noSelectionOption=true /
   f:selectItems value=#{validationBean.items} /
 /p:selectOneMenu
 h:outputLabel for=jsf value=SelectMenue JSF /
 h:selectOneMenu id=jsf value=#{validationBean.selectedItemH}
   f:selectItem itemLabel= no selection  noSelectionOption=true/
   f:selectItems value=#{validationBean.items} /
 /h:selectOneMenu
 {code}
 This behaviour does not occur using the JSF-SelectOneMenu and also if the 
 PF-Menu is replaced with a PF-InputText.
 In those cases the validation displays only one error message.



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

[jira] [Commented] (EXTVAL-159) Duplicate NotNull Validation of Primefaces-SelectOneMenu

2014-05-31 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTVAL-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14014603#comment-14014603
 ] 

Gerhard Petracek commented on EXTVAL-159:
-

basically you can use 
http://sandbox890.googlecode.com/svn/trunk/addons/uniqueValidationMessage/ for 
now.
due to the constellation in primefaces it won't work as it is.
in UniqueFacesMessageStorage#isUnique you need an additional check against 
FacesContext.getCurrentInstance().getMessageList().

add e.g.:
{code}
//...
if (result)
{
for(FacesMessage currentMessage : 
FacesContext.getCurrentInstance().getMessageList())
{
if (isSame(currentMessage, facesMessage)
{
return false;
}
}
   }
return result;
}
{code}

with that you still have the duplicated validation, but only one message.

 Duplicate NotNull Validation of Primefaces-SelectOneMenu
 

 Key: EXTVAL-159
 URL: https://issues.apache.org/jira/browse/EXTVAL-159
 Project: MyFaces Extensions Validator
  Issue Type: Bug
  Components: Bean Validation
Affects Versions: 2.0.7
 Environment: Java 7, JBoss AS 7.1.3, Primefaces 4.0
Reporter: Martin Steinbauer
Assignee: Gerhard Petracek
 Attachments: test-jsf-extval.zip


 The bean validation displays the error-message twice, if it validates a 
 Primefaces-SelectOneMenu and a @NotNull annotation is present on the 
 property. 
 {code}
 @NotNull
 private String selectedItemP;
 @NotNull
 private String selectedItemH;
 {code}
 {code}
 h:outputLabel for=pf value=SelectMenue PF /
 p:selectOneMenu id=pf value=#{validationBean.selectedItemP}
   f:selectItem itemLabel= no selection  noSelectionOption=true /
   f:selectItems value=#{validationBean.items} /
 /p:selectOneMenu
 h:outputLabel for=jsf value=SelectMenue JSF /
 h:selectOneMenu id=jsf value=#{validationBean.selectedItemH}
   f:selectItem itemLabel= no selection  noSelectionOption=true/
   f:selectItems value=#{validationBean.items} /
 /h:selectOneMenu
 {code}
 This behaviour does not occur using the JSF-SelectOneMenu and also if the 
 PF-Menu is replaced with a PF-InputText.
 In those cases the validation displays only one error message.



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

[jira] [Comment Edited] (EXTVAL-159) Duplicate NotNull Validation of Primefaces-SelectOneMenu

2014-05-31 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTVAL-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14014603#comment-14014603
 ] 

Gerhard Petracek edited comment on EXTVAL-159 at 5/31/14 10:52 AM:
---

basically you can use 
http://sandbox890.googlecode.com/svn/trunk/addons/uniqueValidationMessage/ for 
now.
due to the constellation in primefaces it won't work as it is.
in UniqueFacesMessageStorage#isUnique you need an additional check against 
FacesContext.getCurrentInstance().getMessageList().

add e.g.:
{code}
//...
if (result)
{
for(FacesMessage currentMessage : 
FacesContext.getCurrentInstance().getMessageList())
{
if (isSame(currentMessage, facesMessage)
{
return false;
}
}
}
return result;
}
{code}

with that you still have the duplicated validation, but only one message.


was (Author: gpetracek):
basically you can use 
http://sandbox890.googlecode.com/svn/trunk/addons/uniqueValidationMessage/ for 
now.
due to the constellation in primefaces it won't work as it is.
in UniqueFacesMessageStorage#isUnique you need an additional check against 
FacesContext.getCurrentInstance().getMessageList().

add e.g.:
{code}
//...
if (result)
{
for(FacesMessage currentMessage : 
FacesContext.getCurrentInstance().getMessageList())
{
if (isSame(currentMessage, facesMessage)
{
return false;
}
}
   }
return result;
}
{code}

with that you still have the duplicated validation, but only one message.

 Duplicate NotNull Validation of Primefaces-SelectOneMenu
 

 Key: EXTVAL-159
 URL: https://issues.apache.org/jira/browse/EXTVAL-159
 Project: MyFaces Extensions Validator
  Issue Type: Bug
  Components: Bean Validation
Affects Versions: 2.0.7
 Environment: Java 7, JBoss AS 7.1.3, Primefaces 4.0
Reporter: Martin Steinbauer
Assignee: Gerhard Petracek
 Attachments: test-jsf-extval.zip


 The bean validation displays the error-message twice, if it validates a 
 Primefaces-SelectOneMenu and a @NotNull annotation is present on the 
 property. 
 {code}
 @NotNull
 private String selectedItemP;
 @NotNull
 private String selectedItemH;
 {code}
 {code}
 h:outputLabel for=pf value=SelectMenue PF /
 p:selectOneMenu id=pf value=#{validationBean.selectedItemP}
   f:selectItem itemLabel= no selection  noSelectionOption=true /
   f:selectItems value=#{validationBean.items} /
 /p:selectOneMenu
 h:outputLabel for=jsf value=SelectMenue JSF /
 h:selectOneMenu id=jsf value=#{validationBean.selectedItemH}
   f:selectItem itemLabel= no selection  noSelectionOption=true/
   f:selectItems value=#{validationBean.items} /
 /h:selectOneMenu
 {code}
 This behaviour does not occur using the JSF-SelectOneMenu and also if the 
 PF-Menu is replaced with a PF-InputText.
 In those cases the validation displays only one error message.



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

[jira] [Commented] (EXTVAL-159) Duplicate NotNull Validation of Primefaces-SelectOneMenu

2014-05-31 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTVAL-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14014604#comment-14014604
 ] 

Gerhard Petracek commented on EXTVAL-159:
-

changed to minor since there is a workaround and the issue isn't caused by 
extval only.

 Duplicate NotNull Validation of Primefaces-SelectOneMenu
 

 Key: EXTVAL-159
 URL: https://issues.apache.org/jira/browse/EXTVAL-159
 Project: MyFaces Extensions Validator
  Issue Type: Bug
  Components: Bean Validation
Affects Versions: 2.0.7
 Environment: Java 7, JBoss AS 7.1.3, Primefaces 4.0
Reporter: Martin Steinbauer
Assignee: Gerhard Petracek
Priority: Minor
 Attachments: test-jsf-extval.zip


 The bean validation displays the error-message twice, if it validates a 
 Primefaces-SelectOneMenu and a @NotNull annotation is present on the 
 property. 
 {code}
 @NotNull
 private String selectedItemP;
 @NotNull
 private String selectedItemH;
 {code}
 {code}
 h:outputLabel for=pf value=SelectMenue PF /
 p:selectOneMenu id=pf value=#{validationBean.selectedItemP}
   f:selectItem itemLabel= no selection  noSelectionOption=true /
   f:selectItems value=#{validationBean.items} /
 /p:selectOneMenu
 h:outputLabel for=jsf value=SelectMenue JSF /
 h:selectOneMenu id=jsf value=#{validationBean.selectedItemH}
   f:selectItem itemLabel= no selection  noSelectionOption=true/
   f:selectItems value=#{validationBean.items} /
 /h:selectOneMenu
 {code}
 This behaviour does not occur using the JSF-SelectOneMenu and also if the 
 PF-Menu is replaced with a PF-InputText.
 In those cases the validation displays only one error message.



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

[jira] [Resolved] (EXTVAL-127) Support for noSelectionOption on selectItem (JSF 2.0)

2014-05-31 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTVAL-127.
-

   Resolution: Fixed
Fix Version/s: 2.0.7

i just saw a working demo with it. please reopen the issue, if you have issues 
with it.

 Support for noSelectionOption on selectItem (JSF 2.0)
 -

 Key: EXTVAL-127
 URL: https://issues.apache.org/jira/browse/EXTVAL-127
 Project: MyFaces Extensions Validator
  Issue Type: New Feature
  Components: Bean Validation, Property Validation
Affects Versions: 2.0.4
Reporter: Rudy De Busscher
Assignee: Rudy De Busscher
Priority: Minor
 Fix For: 2.0.7


 With JSF 2.0, there is a new attribute noSelectionOption available on 
 f:selectItem tag.  When the attribute value evaluates to true and the 
 selectXXXmenu is required, selecting this item should results in a validation 
 error.
 See for example JSF 2.0 javadoc spec, UISelectOne#validateValue



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

[jira] [Resolved] (EXTVAL-127) Support for noSelectionOption on selectItem (JSF 2.0)

2014-05-31 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTVAL-127.
-

Resolution: Not a Problem

 Support for noSelectionOption on selectItem (JSF 2.0)
 -

 Key: EXTVAL-127
 URL: https://issues.apache.org/jira/browse/EXTVAL-127
 Project: MyFaces Extensions Validator
  Issue Type: New Feature
  Components: Bean Validation, Property Validation
Affects Versions: 2.0.4
Reporter: Rudy De Busscher
Assignee: Rudy De Busscher
Priority: Minor

 With JSF 2.0, there is a new attribute noSelectionOption available on 
 f:selectItem tag.  When the attribute value evaluates to true and the 
 selectXXXmenu is required, selecting this item should results in a validation 
 error.
 See for example JSF 2.0 javadoc spec, UISelectOne#validateValue



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

[jira] [Reopened] (EXTVAL-127) Support for noSelectionOption on selectItem (JSF 2.0)

2014-05-31 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek reopened EXTVAL-127:
-


 Support for noSelectionOption on selectItem (JSF 2.0)
 -

 Key: EXTVAL-127
 URL: https://issues.apache.org/jira/browse/EXTVAL-127
 Project: MyFaces Extensions Validator
  Issue Type: New Feature
  Components: Bean Validation, Property Validation
Affects Versions: 2.0.4
Reporter: Rudy De Busscher
Assignee: Rudy De Busscher
Priority: Minor

 With JSF 2.0, there is a new attribute noSelectionOption available on 
 f:selectItem tag.  When the attribute value evaluates to true and the 
 selectXXXmenu is required, selecting this item should results in a validation 
 error.
 See for example JSF 2.0 javadoc spec, UISelectOne#validateValue



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

[VOTE] Release of Extensions Validator 2.0.8

2014-05-27 Thread Gerhard Petracek

Hi,

we were running the needed tasks to get the 8th release of Apache MyFaces
Extensions Validator out.
The artifacts are deployed to Nexus [1].

The release contains the following modules for JSF 2.x:
 - ExtVal Core
 - ExtVal Property-Validation
 - ExtVal Bean-Validation
 - Trinidad-Support-Module
 - Generic-Support-Module

Please take a look at the 2.0.8 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-1024/org/apache/myfaces/extensions/validator/
[2] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: [VOTE] Release of Extensions Validator 2.0.8

2014-05-27 Thread Gerhard Petracek

+1

regards,
gerhard



2014-05-27 8:29 GMT+02:00 Gerhard Petracek gpetra...@apache.org:

 Hi,

 we were running the needed tasks to get the 8th release of Apache MyFaces
 Extensions Validator out.
 The artifacts are deployed to Nexus [1].

 The release contains the following modules for JSF 2.x:
  - ExtVal Core
  - ExtVal Property-Validation
  - ExtVal Bean-Validation
  - Trinidad-Support-Module
  - Generic-Support-Module

 Please take a look at the 2.0.8 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-1024/org/apache/myfaces/extensions/validator/
 [2] http://www.apache.org/foundation/voting.html#ReleaseVotes

[jira] [Commented] (EXTVAL-159) Duplicate NotNull Validation of Primefaces-SelectOneMenu

2014-05-26 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTVAL-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14008669#comment-14008669
 ] 

Gerhard Petracek commented on EXTVAL-159:
-

ok - if you have a demo-application which illustrates the issue, it would be 
great if you attach it here.

 Duplicate NotNull Validation of Primefaces-SelectOneMenu
 

 Key: EXTVAL-159
 URL: https://issues.apache.org/jira/browse/EXTVAL-159
 Project: MyFaces Extensions Validator
  Issue Type: Bug
  Components: Bean Validation
Affects Versions: 2.0.7
 Environment: Java 7, JBoss AS 7.1.3, Primefaces 4.0
Reporter: Martin Steinbauer
Assignee: Gerhard Petracek

 The bean validation displays the error-message twice, if it validates a 
 Primefaces-SelectOneMenu and a @NotNull annotation is present on the 
 property. 
 {code}
 @NotNull
 private String selectedItemP;
 @NotNull
 private String selectedItemH;
 {code}
 {code}
 h:outputLabel for=pf value=SelectMenue PF /
 p:selectOneMenu id=pf value=#{validationBean.selectedItemP}
   f:selectItem itemLabel= no selection  noSelectionOption=true /
   f:selectItems value=#{validationBean.items} /
 /p:selectOneMenu
 h:outputLabel for=jsf value=SelectMenue JSF /
 h:selectOneMenu id=jsf value=#{validationBean.selectedItemH}
   f:selectItem itemLabel= no selection  noSelectionOption=true/
   f:selectItems value=#{validationBean.items} /
 /h:selectOneMenu
 {code}
 This behaviour does not occur using the JSF-SelectOneMenu and also if the 
 PF-Menu is replaced with a PF-InputText.
 In those cases the validation displays only one error message.



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

[jira] [Created] (EXTVAL-160) update notice files

2014-05-25 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created EXTVAL-160:
---

 Summary: update notice files
 Key: EXTVAL-160
 URL: https://issues.apache.org/jira/browse/EXTVAL-160
 Project: MyFaces Extensions Validator
  Issue Type: Task
Affects Versions: 2.0.7
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek






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

[jira] [Resolved] (EXTVAL-160) update notice files

2014-05-25 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTVAL-160.
-

   Resolution: Fixed
Fix Version/s: 2.0.8

 update notice files
 ---

 Key: EXTVAL-160
 URL: https://issues.apache.org/jira/browse/EXTVAL-160
 Project: MyFaces Extensions Validator
  Issue Type: Task
Affects Versions: 2.0.7
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 2.0.8






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

[jira] [Commented] (EXTVAL-159) Duplicate NotNull Validation of Primefaces-SelectOneMenu

2014-05-25 Thread Gerhard Petracek (JIRA)


[ 
https://issues.apache.org/jira/browse/EXTVAL-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14008375#comment-14008375
 ] 

Gerhard Petracek commented on EXTVAL-159:
-

please provide more information about it. e.g. if it also happens with other 
input-components from primefaces.

 Duplicate NotNull Validation of Primefaces-SelectOneMenu
 

 Key: EXTVAL-159
 URL: https://issues.apache.org/jira/browse/EXTVAL-159
 Project: MyFaces Extensions Validator
  Issue Type: Bug
  Components: Bean Validation
Affects Versions: 2.0.7
 Environment: Java 7, JBoss AS 7.1.3, Primefaces 4.0
Reporter: Martin Steinbauer

 The bean validation displays the error-message twice, if it validates a 
 Primefaces-SelectOneMenu and a @NotNull annotation is present on the 
 property. 
 {code}
 @NotNull
 private String selectedItemP;
 @NotNull
 private String selectedItemH;
 {code}
 {code}
 h:outputLabel for=pf value=SelectMenue PF /
 p:selectOneMenu id=pf value=#{validationBean.selectedItemP}
   f:selectItem itemLabel= no selection  noSelectionOption=true /
   f:selectItems value=#{validationBean.items} /
 /p:selectOneMenu
 h:outputLabel for=jsf value=SelectMenue JSF /
 h:selectOneMenu id=jsf value=#{validationBean.selectedItemH}
   f:selectItem itemLabel= no selection  noSelectionOption=true/
   f:selectItems value=#{validationBean.items} /
 /h:selectOneMenu
 {code}
 This behaviour does not occur using the JSF-SelectOneMenu and also if the 
 PF-Menu is replaced with a PF-InputText.
 In those cases the validation displays only one error message.



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

[extval] first steps for the next release

2014-05-19 Thread Gerhard Petracek

hi @ all,

if there are no objections, i'll start with the first steps for the next
release (review,...) by the end of the week.

regards,
gerhard

http://www.irian.at

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

Professional Support for Apache MyFaces

[jira] [Created] (MYFACESTEST-70) customizable ClassLoader

2014-05-19 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created MYFACESTEST-70:
---

 Summary: customizable ClassLoader
 Key: MYFACESTEST-70
 URL: https://issues.apache.org/jira/browse/MYFACESTEST-70
 Project: MyFaces Test
  Issue Type: Improvement
Affects Versions: 1.0.6
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe


per default 
 - AbstractJsfTestContainer
 - AbstractMyFacesTestCase
 - AbstractJsfTestContainer
 - AbstractMyFacesTestCase
use URLClassLoader which causes issues with other libs.

we should extract that part (protected method...) - if needed, it's possible 
to customize the active ClassLoader.



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

[jira] [Resolved] (EXTVAL-156) Add support for BehaviorEvent/AjaxBehaviorEvent in ExtValViewRootInterceptor

2014-04-07 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTVAL-156.
-

Resolution: Fixed

 Add support for BehaviorEvent/AjaxBehaviorEvent in ExtValViewRootInterceptor
 

 Key: EXTVAL-156
 URL: https://issues.apache.org/jira/browse/EXTVAL-156
 Project: MyFaces Extensions Validator
  Issue Type: New Feature
Affects Versions: 2.0.7
Reporter: Alexey Shakov
Assignee: Gerhard Petracek
 Fix For: 2.0.8

 Attachments: EXTVAL-156_first_step.patch, 
 EXTVAL-156_second_step.patch, EXTVAL-156_third_step.patch


 Following use case does not work:
   h:selectOneMenu ...
 f:ajax event=change render=main 
 listener=#{bean.bypassValidation} execute=@form /
   /h:selectOneMenu
 where bean.bypassValidation is defined as:
 @SkipConstraintValidation
 public String bypassValidation() {
 return success;
 }
 @SkipConstraintValidation is not evaluated in this case:  onchange-event 
 forces all form fields to be validated.



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

[jira] [Resolved] (EXTVAL-155) Re-implement @BypassValidation for EXTVAL 2.x

2014-04-07 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTVAL-155.
-

Resolution: Fixed

 Re-implement @BypassValidation for EXTVAL 2.x
 -

 Key: EXTVAL-155
 URL: https://issues.apache.org/jira/browse/EXTVAL-155
 Project: MyFaces Extensions Validator
  Issue Type: New Feature
  Components: Core
Reporter: Alexey Shakov
Assignee: Gerhard Petracek
 Fix For: 2.0.8

 Attachments: EXTVAL-155.patch


 bypass add-on (which defines @BypassValidation) is not compatible with EXTVAL 
 2.x. 
 Please re-implement it (if possible, than integrate in EXTVAL)
 see also 
 http://mail-archives.apache.org/mod_mbox/myfaces-users/201311.mbox/%3CCAGJtJfH10ZypWbhcc%2ByW0_1WYHochiNHqrYS9%3DsN%2BJY%2BnPvudw%40mail.gmail.com%3E



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

[jira] [Created] (MYFACES-3878) ViewHandlerWrapper is broken

2014-04-03 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created MYFACES-3878:
-

 Summary: ViewHandlerWrapper is broken
 Key: MYFACES-3878
 URL: https://issues.apache.org/jira/browse/MYFACES-3878
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.2
Reporter: Gerhard Petracek
Priority: Blocker


ViewHandlerWrapper doesn't contain the new methods
addProtectedView, removeProtectedView, getProtectedViewsUnmodifiable



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

[jira] [Resolved] (EXTVAL-158) improve ProxyHelper

2014-03-28 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTVAL-158.
-

   Resolution: Fixed
Fix Version/s: 2.0.8

 improve ProxyHelper
 ---

 Key: EXTVAL-158
 URL: https://issues.apache.org/jira/browse/EXTVAL-158
 Project: MyFaces Extensions Validator
  Issue Type: Improvement
  Components: Core
Affects Versions: 2.0.7
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 2.0.8

 Attachments: EXTVAL-158.patch






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

[jira] [Created] (EXTVAL-158) improve ProxyHelper

2014-03-27 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created EXTVAL-158:
---

 Summary: improve ProxyHelper
 Key: EXTVAL-158
 URL: https://issues.apache.org/jira/browse/EXTVAL-158
 Project: MyFaces Extensions Validator
  Issue Type: Improvement
  Components: Core
Affects Versions: 2.0.7
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Attachments: EXTVAL-158.patch





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

[jira] [Created] (EXTCDI-315) merge back DELTASPIKE-546

2014-03-24 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created EXTCDI-315:
---

 Summary: merge back DELTASPIKE-546
 Key: EXTCDI-315
 URL: https://issues.apache.org/jira/browse/EXTCDI-315
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.0.6
Reporter: Rafael
Assignee: Gerhard Petracek






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

[jira] [Resolved] (EXTCDI-315) merge back DELTASPIKE-546

2014-03-24 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-315.
-

   Resolution: Fixed
Fix Version/s: 1.0.7

 merge back DELTASPIKE-546
 -

 Key: EXTCDI-315
 URL: https://issues.apache.org/jira/browse/EXTCDI-315
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.0.6
Reporter: Rafael
Assignee: Gerhard Petracek
 Fix For: 1.0.7






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

Re: Result (Was: [VOTE] release of MyFaces Core 2.2.2)

2014-03-20 Thread Gerhard Petracek

hi leo,

we don't have 3 binding votes (see [1]).

regards,
gerhard

[1] https://www.apache.org/foundation/voting.html#ReleaseVotes



2014-03-20 19:20 GMT+01:00 Leonardo Uribe lu4...@gmail.com:

 Hi

 Thanks to all people who vote

 We have 4 +1

 Michael Kurz
 Werner Punz
 Thomas Andraschko
 Leonardo Uribe

 so we can continue with the necessary steps to release MyFaces Core 2.2.2

 regards,

 Leonardo Uribe

Re: Result (Was: [VOTE] release of MyFaces Core 2.2.2)

2014-03-20 Thread Gerhard Petracek

thx martin for reviewing it!

regards,
gerhard



2014-03-20 20:48 GMT+01:00 Martin Marinschek martin.marinsc...@gmail.com:

 +1 for the release,

 Best regards,

 Martin
 --
 Sent from Mailbox https://www.dropbox.com/mailbox for iPhone


 On Thu, Mar 20, 2014 at 7:51 PM, Leonardo Uribe lu4...@gmail.com wrote:

 Hi

 Ouch, I didn't noticed that Michael is committer, not PMC. I have
 already released the maven repo, so there is no way back. I'll
 appreciate if some PMC can check the artifacts, and give the extra
 vote. After all, this is a quick fix release, there is no extra
 features added, so these artifacts are pretty much the same as 2.2.1.

 regards,

 Leonardo Uribe

 2014-03-20 13:45 GMT-05:00 Gerhard Petracek gpetra...@apache.org:
  hi leo,
 
  we don't have 3 binding votes (see [1]).
 
  regards,
  gerhard
 
  [1] https://www.apache.org/foundation/voting.html#ReleaseVotes
 
 
 
  2014-03-20 19:20 GMT+01:00 Leonardo Uribe lu4...@gmail.com:
 
  Hi
 
  Thanks to all people who vote
 
  We have 4 +1
 
  Michael Kurz
  Werner Punz
  Thomas Andraschko
  Leonardo Uribe
 
  so we can continue with the necessary steps to release MyFaces Core
 2.2.2
 
  regards,
 
  Leonardo Uribe

Re: JSF 2.2 ViewScoped - Passivation?

2014-03-13 Thread Gerhard Petracek

hi thomas,

the annotation is given by the spec., however, the registration in
ViewScopeContextExtension is fine: event.addScope(ViewScoped.class, true,
true);

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-03-13 17:06 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com:

 Hi,

 i found the following issue in mojarras issue tracker:
 https://java.net/jira/browse/JAVASERVERFACES-3191

 Do we have a unit test for testing passivation?
 I just looked at our sources but we are missing the passivating attribute,
 too.

 Regards,
 Thomas

[ANNOUNCE] Release of Apache MyFaces Extensions CDI 1.0.6

2014-03-04 Thread Gerhard Petracek

The Apache MyFaces team is pleased to announce the 13th release of
Apache MyFaces Extensions CDI (aka CODI).

Apache MyFaces CODI provides portable CDI extensions for
the Java-Platform (SE and EE). CODI is a modularized and
extensible toolbox for CDI based applications.

The release of CODI v1.0.6 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 Modules
 - 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

Apache MyFaces CODI is available in both binary and source distributions:
http://myfaces.apache.org/extensions/cdi/download.html

Apache MyFaces CODI is available in the central Maven repository under
Group ID org.apache.myfaces.extensions.cdi.*.

Release Notes:
http://s.apache.org/CODI_106

Enjoy!

Gerhard Petracek

Re: Possible performance enchancement?

2014-03-04 Thread Gerhard Petracek

you need the traversal anyway e.g. to convert the values (which is done
during the same traversal).
your numbers sound way too high - imo you have a different issue in your
application.
- we need more details about your setup.

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-03-04 11:20 GMT+01:00 Thomas Andraschko andraschko.tho...@gmail.com:

 As the scenario is really special, what about overwriting the JSF
 Lifecycle and modify it for your requirements?


 2014-03-01 9:28 GMT+01:00 Karl Trumstedt karl...@gmail.com:

 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 of 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

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

2014-03-03 Thread Gerhard Petracek

thank you for voting!

3 binding +1 votes (pmc):
 - Mark Struberg
 - Werner Punz
 - Gerhard Petracek

1 non-binding +1 votes:
 - Hazem Saleh

no -1 votes

regards,
gerhard



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

[jira] [Resolved] (EXTCDI-308) EAR support for Websphere 8

2014-02-28 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-308.
-

Resolution: Fixed

 EAR support for Websphere 8
 ---

 Key: EXTCDI-308
 URL: https://issues.apache.org/jira/browse/EXTCDI-308
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: JEE-JSF20-Module
Affects Versions: 1.0.5
Reporter: gonzalad
 Fix For: 1.0.6


 When codi-bundle is packaged in EAR, I get the following exception [1] on 
 application startup on Websphere 8.0.0.4.
 It seems package level access is not supported for CDI bean classes or CDI 
 bean methods on WAS 8.0.0.4.
 [1]
 {code}
 [3/26/13 16:52:53:494 CET] 00bc
 webappE
 com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet
 Error]-[Faces Servlet]: java.lang.RuntimeException: by
 java.lang.IllegalAccessError:
 org.apache.myfaces.extensions.cdi.jsf.impl.scope.conversation.DefaultBeanEntryFactory
 at
 javassist.util.proxy.ProxyFactory.createClass3(ProxyFactory.java:509)
 at javassist.util.proxy.ProxyFactory.createClass2(ProxyFactory.java:486)
 at javassist.util.proxy.ProxyFactory.createClass1(ProxyFactory.java:422)
 at javassist.util.proxy.ProxyFactory.createClass(ProxyFactory.java:394)
 {code}
 See also 
 http://mail-archives.apache.org/mod_mbox/myfaces-users/201303.mbox/%3c1364314920.26443.yahoomail...@web172405.mail.ir2.yahoo.com%3E.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-307) EAR support for JBoss 7

2014-02-28 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-307.
-

Resolution: Won't Fix

please test the phase-listener handling with deltaspike

 EAR support for JBoss 7
 ---

 Key: EXTCDI-307
 URL: https://issues.apache.org/jira/browse/EXTCDI-307
 Project: MyFaces CODI
  Issue Type: Bug
  Components: JEE-JSF20-Module
Affects Versions: 1.0.5
Reporter: gonzalad

 @ViewAccessScoped is not working when deploying an EAR on JBoss 7.1.0 (tested 
 it with 7.1.3
 same result).
 The @ViewAccessScoped bean is reinstantiated each time we call a page (even 
 if it's the same page as the previous one).
 See 
  * 
 http://mail-archives.apache.org/mod_mbox/myfaces-users/201303.mbox/%3c1363791901.52665.yahoomail...@web172402.mail.ir2.yahoo.com%3E



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-309) look for phase listeners in parent classloader too

2014-02-28 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-309.
-

Resolution: Won't Fix

it's just a minor feature. it's always possible to use a std. phase-listener.

 look for phase listeners in parent classloader too
 --

 Key: EXTCDI-309
 URL: https://issues.apache.org/jira/browse/EXTCDI-309
 Project: MyFaces CODI
  Issue Type: Improvement
Reporter: Romain Manni-Bucau

 In ear phaselisteners can be in lib part of the ear too so in 
 org.apache.myfaces.extensions.cdi.jsf.impl.listener.phase.PhaseListenerExtension#consumePhaseListeners
  the phaselisteners should be looked up from parent loader too (if 
 (classloader != systemLoader) ...)
 It is underspecified but it doesn't work in tomee for instance



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-230) Tobago Support Module for CODI

2014-02-28 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-230.
-

Resolution: Won't Fix

afaik it isn't needed any longer

 Tobago Support Module for CODI
 --

 Key: EXTCDI-230
 URL: https://issues.apache.org/jira/browse/EXTCDI-230
 Project: MyFaces CODI
  Issue Type: Wish
Reporter: Bernd Bohmann
Priority: Minor

 It would be nice to have a Tobago Support Module for CODI. This module should 
 provide a solution for adding the WindowContextIdHolderComponent without 
 intercepting the ResponseWriter.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-224) Support REQUIRES_NEW and other javax.ejb.TransactionAttributeTypes in our @Transactional

2014-02-28 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-224.
-

Resolution: Won't Fix

 Support REQUIRES_NEW and other javax.ejb.TransactionAttributeTypes in our 
 @Transactional
 

 Key: EXTCDI-224
 URL: https://issues.apache.org/jira/browse/EXTCDI-224
 Project: MyFaces CODI
  Issue Type: New Feature
  Components: JEE-JPA1-Module
Affects Versions: 1.0.1
Reporter: Mark Struberg
Assignee: Mark Struberg

 We currently have the REQUIRED behaviour as default for our @Transactional 
 interceptor. 
 Imo we should _not_ import the javax.ejb.TransactionAttributeType to not add 
 any additional dependency, but we should stay very close to it.
 I intend to implement the following TransactionAttributeTypes:
 * REQUIRED (as default)
 * REQUIRES_NEW
 * NEVER
 * SUPPORTS
 * MANDATORY
 not sure about the other ones
 A good overview can be found in OpenEJB: 
 http://openejb.apache.org/3.0/transaction-annotations.html



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-245) update bundle configs

2014-02-28 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-245.
-

Resolution: Won't Fix

 update bundle configs
 -

 Key: EXTCDI-245
 URL: https://issues.apache.org/jira/browse/EXTCDI-245
 Project: MyFaces CODI
  Issue Type: Task
Affects Versions: 1.0.1
Reporter: Gerhard Petracek
Assignee: Mark Struberg





--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-306) lightweight dialogs aren't supported by default

2014-02-28 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-306.
-

Resolution: Won't Fix

 lightweight dialogs aren't supported by default
 ---

 Key: EXTCDI-306
 URL: https://issues.apache.org/jira/browse/EXTCDI-306
 Project: MyFaces CODI
  Issue Type: Bug
  Components: Trinidad Support
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Priority: Minor

 workaround: disable parts only needed by alternative window-handlers



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-282) interceptors should support lifecycle-callbacks

2014-02-28 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-282.
-

Resolution: Won't Fix

 interceptors should support lifecycle-callbacks
 ---

 Key: EXTCDI-282
 URL: https://issues.apache.org/jira/browse/EXTCDI-282
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: JEE-JPA1-Module, JEE-JSF12-Module, JEE-JSF20-Module
Reporter: Gerhard Petracek
Priority: Minor

 important restrictions are analyzed at:
 http://blog.dblevins.com/2010/09/ejbnext-interceptor-improvements-method.html
 workaround (- minor issue):
 implementation of a custom interceptor binding
 - inject the corresponding InterceptorStrategy and delegate to it.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-297) merge back DELTASPIKE-212

2014-02-28 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-297.
-

Resolution: Fixed

 merge back DELTASPIKE-212
 -

 Key: EXTCDI-297
 URL: https://issues.apache.org/jira/browse/EXTCDI-297
 Project: MyFaces CODI
  Issue Type: Task
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 1.0.6






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-295) merge back DELTASPIKE-175

2014-02-28 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-295.
-

Resolution: Won't Fix

 merge back DELTASPIKE-175
 -

 Key: EXTCDI-295
 URL: https://issues.apache.org/jira/browse/EXTCDI-295
 Project: MyFaces CODI
  Issue Type: Task
  Components: JEE-JPA1-Module
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 1.0.6






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-281) merge back DELTASPIKE-67

2014-02-28 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-281.
-

Resolution: Won't Fix

 merge back DELTASPIKE-67
 

 Key: EXTCDI-281
 URL: https://issues.apache.org/jira/browse/EXTCDI-281
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: Core
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
Priority: Trivial





--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-294) merge back DELTASPIKE-191

2014-02-28 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-294.
-

   Resolution: Won't Fix
Fix Version/s: (was: 1.0.6)

 merge back DELTASPIKE-191
 -

 Key: EXTCDI-294
 URL: https://issues.apache.org/jira/browse/EXTCDI-294
 Project: MyFaces CODI
  Issue Type: Task
  Components: Core
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek





--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-235) add javadoc to DefaultWindowContextManager#closeAllWindowContexts

2014-02-28 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-235.
-

Resolution: Won't Fix

 add javadoc to DefaultWindowContextManager#closeAllWindowContexts
 -

 Key: EXTCDI-235
 URL: https://issues.apache.org/jira/browse/EXTCDI-235
 Project: MyFaces CODI
  Issue Type: Task
  Components: JEE-JSF12-Module, JEE-JSF20-Module
Affects Versions: 1.0.2
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
Priority: Trivial

 esp. the difference to WindowContext#close (see e.g. attributes.clear())



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-283) support for multiple entity-managers

2014-02-28 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-283.
-

Resolution: Won't Fix

 support for multiple entity-managers
 

 Key: EXTCDI-283
 URL: https://issues.apache.org/jira/browse/EXTCDI-283
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: JEE-JPA1-Module
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek

 the default PersistenceStrategy should use the injected entity-manager/s - 
 no qualifier is needed for @Transactional and multiple entity-managers per 
 transactional bean(-method) are supported - only a manual lookup of an 
 entity-manager won't work



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-251) support @javax.decorator.Delegate in ConfiguredArtifactUtils#findInjectionPointForDefaultImplementation

2014-02-28 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-251.
-

Resolution: Won't Fix

 support @javax.decorator.Delegate in 
 ConfiguredArtifactUtils#findInjectionPointForDefaultImplementation
 ---

 Key: EXTCDI-251
 URL: https://issues.apache.org/jira/browse/EXTCDI-251
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.0.2
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
Priority: Minor





--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (EXTCDI-314) preparations for v1.0.6

2014-02-28 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created EXTCDI-314:
---

 Summary: preparations for v1.0.6
 Key: EXTCDI-314
 URL: https://issues.apache.org/jira/browse/EXTCDI-314
 Project: MyFaces CODI
  Issue Type: Task
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-314) preparations for v1.0.6

2014-02-28 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-314.
-

   Resolution: Fixed
Fix Version/s: 1.0.6

 preparations for v1.0.6
 ---

 Key: EXTCDI-314
 URL: https://issues.apache.org/jira/browse/EXTCDI-314
 Project: MyFaces CODI
  Issue Type: Task
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 1.0.6






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[VOTE] Release of Extensions CDI (CODI) 1.0.6

2014-02-28 Thread Gerhard Petracek

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

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

2014-02-28 Thread Gerhard Petracek

+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

[jira] [Resolved] (MYFACESTEST-66) pre-configured containers

2014-02-05 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved MYFACESTEST-66.
-

   Resolution: Fixed
Fix Version/s: 1.0.6-SNAPSHOT

 pre-configured containers
 -

 Key: MYFACESTEST-66
 URL: https://issues.apache.org/jira/browse/MYFACESTEST-66
 Project: MyFaces Test
  Issue Type: New Feature
  Components: Mock Objects
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe
 Fix For: 1.0.6-SNAPSHOT


 currently other frameworks like deltaspike have to use mocked containers for 
 every version of jsf (one example can be found at 
 https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob;f=deltaspike/modules/test-control/impl/src/main/java/org/apache/deltaspike/testcontrol/impl/jsf/MockedJsf2TestContainer.java;h=e6e2b2bec6cf443c141035643cb5816e1118e6d6;hb=HEAD
  ). in a lot of cases it's just required to have a simple control over the 
 mocked container (methods like #addConfigEntry, #boot, #shutdown, 
 #activateView, #startScope, #stopScope). those methods are independent of the 
 jsf-api. - if every new version of myfaces-test provides a correctly mocked 
 container with such independent methods, frameworks like deltaspike could 
 delegate to it (instead of hosting a correctly mocked container for every 
 version of the jsf-api).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (MYFACES-3851) replace listener-config

2014-01-28 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek updated MYFACES-3851:
--

Status: Patch Available  (was: Open)

 replace listener-config
 ---

 Key: MYFACES-3851
 URL: https://issues.apache.org/jira/browse/MYFACES-3851
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-344
Affects Versions: 2.2.0
Reporter: Gerhard Petracek
 Attachments: MYFACES-3851.patch


 tld - web-fragment.xml
 users who need to use servlet 2.5 + myfaces-core 2.2+ can still add the 
 listener to the web.xml



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (MYFACES-3851) replace listener-config

2014-01-28 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created MYFACES-3851:
-

 Summary: replace listener-config
 Key: MYFACES-3851
 URL: https://issues.apache.org/jira/browse/MYFACES-3851
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-344
Affects Versions: 2.2.0
Reporter: Gerhard Petracek
 Attachments: MYFACES-3851.patch

tld - web-fragment.xml

users who need to use servlet 2.5 + myfaces-core 2.2+ can still add the 
listener to the web.xml



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (MYFACES-3844) move StartupServletContextListener config to web-fragment.xml

2014-01-18 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created MYFACES-3844:
-

 Summary: move StartupServletContextListener config to 
web-fragment.xml
 Key: MYFACES-3844
 URL: https://issues.apache.org/jira/browse/MYFACES-3844
 Project: MyFaces Core
  Issue Type: Improvement
  Components: JSR-344
Affects Versions: 2.2.0
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe


users who need to use servlet 2.5 + myfaces-core 2.2+ can still add the 
listener to the web.xml



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (EXTCDI-313) ee7 support

2014-01-13 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created EXTCDI-313:
---

 Summary: ee7 support
 Key: EXTCDI-313
 URL: https://issues.apache.org/jira/browse/EXTCDI-313
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: Core, JEE-BV1-Module, JEE-JSF12-Module
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek






--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-313) ee7 support

2014-01-13 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-313.
-

Resolution: Fixed

tested with GF4

 ee7 support
 ---

 Key: EXTCDI-313
 URL: https://issues.apache.org/jira/browse/EXTCDI-313
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: Core, JEE-BV1-Module, JEE-JSF12-Module
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek





--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (MYFACESTEST-66) preconfigred containers

2014-01-08 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created MYFACESTEST-66:
---

 Summary: preconfigred containers
 Key: MYFACESTEST-66
 URL: https://issues.apache.org/jira/browse/MYFACESTEST-66
 Project: MyFaces Test
  Issue Type: New Feature
  Components: Mock Objects
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe


currently other frameworks like deltaspike have to use mocked containers for 
every version of jsf (one example can be found at 
https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=blob;f=deltaspike/modules/test-control/impl/src/main/java/org/apache/deltaspike/testcontrol/impl/jsf/MockedJsf2TestContainer.java;h=e6e2b2bec6cf443c141035643cb5816e1118e6d6;hb=HEAD
 ). in a lot of cases it's just required to have a simple control over the 
mocked container (methods like #addConfigEntry, #boot, #shutdown, 
#activateView, #startScope, #stopScope). those methods are independent of the 
jsf-api. - if every new version of myfaces-test provides a correctly mocked 
container with such independent methods, frameworks like deltaspike could 
delegate to it (instead of hosting a correctly mocked container for every 
version of the jsf-api).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (EXTCDI-312) support for weld 2.0.x

2014-01-07 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created EXTCDI-312:
---

 Summary: support for weld 2.0.x
 Key: EXTCDI-312
 URL: https://issues.apache.org/jira/browse/EXTCDI-312
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: JEE-JSF12-Module, JEE-JSF20-Module
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek


in case of weld 1.x and 2.1.x instances of type 
javax.enterprise.context.spi.Contextual also implement 
javax.enterprise.inject.spi.Bean. however, that isn't the case with weld 2.0.x.
- we can backport the workaround used in deltaspike.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Resolved] (EXTCDI-312) support for weld 2.0.x

2014-01-07 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-312.
-

   Resolution: Fixed
Fix Version/s: 1.0.6

 support for weld 2.0.x
 --

 Key: EXTCDI-312
 URL: https://issues.apache.org/jira/browse/EXTCDI-312
 Project: MyFaces CODI
  Issue Type: Improvement
  Components: JEE-JSF12-Module, JEE-JSF20-Module
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 1.0.6


 in case of weld 1.x and 2.1.x instances of type 
 javax.enterprise.context.spi.Contextual also implement 
 javax.enterprise.inject.spi.Bean. however, that isn't the case with weld 
 2.0.x.
 - we can backport the workaround used in deltaspike.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (EXTCDI-311) merge back DELTASPIKE-471

2013-12-17 Thread Gerhard Petracek (JIRA)

Gerhard Petracek created EXTCDI-311:
---

 Summary: merge back DELTASPIKE-471
 Key: EXTCDI-311
 URL: https://issues.apache.org/jira/browse/EXTCDI-311
 Project: MyFaces CODI
  Issue Type: Bug
  Components: JEE-JSF20-Module
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek






--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Resolved] (EXTCDI-311) merge back DELTASPIKE-471

2013-12-17 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek resolved EXTCDI-311.
-

   Resolution: Fixed
Fix Version/s: 1.0.6

 merge back DELTASPIKE-471
 -

 Key: EXTCDI-311
 URL: https://issues.apache.org/jira/browse/EXTCDI-311
 Project: MyFaces CODI
  Issue Type: Bug
  Components: JEE-JSF20-Module
Affects Versions: 1.0.5
Reporter: Gerhard Petracek
Assignee: Gerhard Petracek
 Fix For: 1.0.6






--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

[jira] [Updated] (EXTVAL-156) Add support for BehaviorEvent/AjaxBehaviorEvent in ExtValViewRootInterceptor

2013-11-21 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek updated EXTVAL-156:


Status: Patch Available  (was: Open)

 Add support for BehaviorEvent/AjaxBehaviorEvent in ExtValViewRootInterceptor
 

 Key: EXTVAL-156
 URL: https://issues.apache.org/jira/browse/EXTVAL-156
 Project: MyFaces Extensions Validator
  Issue Type: New Feature
Affects Versions: 2.0.7
Reporter: Alexey Shakov
Assignee: Gerhard Petracek
 Fix For: 2.0.8

 Attachments: EXTVAL-156_first_step.patch


 Following use case does not work:
   h:selectOneMenu ...
 f:ajax event=change render=main 
 listener=#{bean.bypassValidation} execute=@form /
   /h:selectOneMenu
 where bean.bypassValidation is defined as:
 @SkipConstraintValidation
 public String bypassValidation() {
 return success;
 }
 @SkipConstraintValidation is not evaluated in this case:  onchange-event 
 forces all form fields to be validated.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests

2013-11-04 Thread Gerhard Petracek (JIRA)

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

Gerhard Petracek commented on MYFACES-3816:
---

@dora:
that wasn't the topic. without an initial redirect or including the window-id
in ajax-requests and/or rewriting the url via js, users get unexpected issues
even after the second request (if you only use ajax-requests until a
browser-refresh).

if we would get issues with the tck, we could still do #2 and #3.

i never said that a redirect is the only choice we have.
(it just has less unexpected effects, esp. if you have special logic in your
application.)

missing window-handling for initial requests

Key: MYFACES-3816
URL: https://issues.apache.org/jira/browse/MYFACES-3816
Project: MyFaces Core
Issue Type: Bug
Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

for an initial request there is no window-id added to the url.
(tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
- in case of a page refresh a new window-id will be created and it isn't
possible to get back the original one. that can also happen with a
page-refresh after multiple requests, if only ajax requests are used.
that's a major issue for all scopes based on the window-id.
it can be done with an initial redirect (default in codi) or js (with html5
compliant browsers)

--
This message was sent by Atlassian JIRA
(v6.1#6144)

[jira] [Commented] (MYFACES-3816) missing window-handling for initial requests

2013-11-04 Thread Gerhard Petracek (JIRA)


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

Gerhard Petracek commented on MYFACES-3816:
---

that's a completely different story.
an initial redirect (to the same url+window-id) would happen even before the 
jsf-request-lifecycle starts (after Lifecycle#attachWindow and before 
Lifecycle#execute).

a std. redirect-url should always contain the window-id.

 missing window-handling for initial requests
 

 Key: MYFACES-3816
 URL: https://issues.apache.org/jira/browse/MYFACES-3816
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-344
Affects Versions: 2.2.0-beta
Reporter: Gerhard Petracek
Assignee: Leonardo Uribe

 for an initial request there is no window-id added to the url.
 (tested with 'url' for javax.faces.CLIENT_WINDOW_MODE)
 - in case of a page refresh a new window-id will be created and it isn't 
 possible to get back the original one. that can also happen with a 
 page-refresh after multiple requests, if only ajax requests are used.
 that's a major issue for all scopes based on the window-id.
 it can be done with an initial redirect (default in codi) or js (with html5 
 compliant browsers)



--
This message was sent by Atlassian JIRA
(v6.1#6144)

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 1738 matches

Mail list logo