Hi Ok, so can we agree on use a name like org.apache.myfaces.STRICT_JSF_2_EL_RESOLVER_COMPATIBILITY?
I strongly suggest the default value of this param should be "false" by the following reasons: 1. I don't believe the TCK check this specific part. Only if the change cause a test to fail, we are forced to set the param by default to "true". 2. If somebody needs to change from myfaces to mojarra by some reason, it is possible to create a fix without change mojarra internals (a custom EL resolver), keeping interoperability between both jsf implementations. Implementors of composite component libraries can include a fix, but if we include it on myfaces, checking the version and the param they can decide if the resolver needs to return something different than null on getType() or not. 3. Users see this issue as a problem over the implementation. Enabling the fix over getType() by default will make users happier, because its composite components that relies on this effect will work as expected. 4. In practice, only (very few) people interested in "strict" jsf 2 compatibility will enable this param. regards, Leonardo 2011/9/22 Michael Kurz <[email protected]>: > +1 :) > > Am 22.09.2011 um 14:15 schrieb Bernd Bohmann: > >> Sorry I suggested to enable this parameter as default >> You only need to know this parameter if you need the old behavoir >> >> Regards >> >> Bernd >> >> On Thu, Sep 22, 2011 at 1:30 PM, Michael Kurz <[email protected]> wrote: >>> OK, good. But: This would then be parameter 94 to consider? >>> >>> Best regards >>> Michi >>> >>> Am 22.09.2011 13:17, schrieb Mark Struberg: >>>> >>>> of course there is: >>>> >>>> http://myfaces.apache.org/core20/myfaces-impl/webconfig.html >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> >>>>> From: Michael Kurz<[email protected]> >>>>> To: MyFaces Development<[email protected]> >>>>> Cc: >>>>> Sent: Thursday, September 22, 2011 1:14 PM >>>>> Subject: Re: [VOTE] fix MYFACES-2552 for 2.0.x and 2.1.x branches >>>>> >>>>> I agree with Jakob, nobody will know about a parameter like this (are >>>>> they documented anywhere btw?). The effect (without setting it): for >>>>> application developers JSF seems to be broken. >>>>> >>>>> Best regards >>>>> Michi >>>>> >>>>> Am 22.09.2011 12:16, schrieb Jakob Korherr: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Both suggestions for a name are reasonable, because they suggest >>>>>> different things! >>>>>> >>>>>> What Leo suggested (STRICT_JSF_2_COMPATIBILITY), is the flag we >>>>>> (internally) have been discussing (and postponing) for a long time. >>>>>> This config parameter would enable us to include non-spec behavior in >>>>>> MyFaces core, which would make us fail the TCK, if we included it by >>>>>> default. However, by enabling it via config parameter only >>>>>> (STRICT_JSF_2_COMPATIBILITY=false), we would be able to fix obvious >>>>>> spec issues already in MyFaces core 2.0 (e.g. MYFACES-2552) and still >>>>>> passing the TCK. Thus we would not need to wait for the next spec >>>>>> release (which may not even contain the fix....), to fix critical >>>>>> issues. >>>>>> >>>>>> What Mark and Bernd suggested is to include the fix for MYFACES-2552 >>>>>> and make a config parameter just for this behavior. >>>>>> >>>>>> >>>>>> Actually, I think introducing yet another config parameter for (in >>>>>> this case) very specific behavior is not the best idea, b/c no-one >>>>>> outside of the MyFaces developers will use it. Introducing a more >>>>>> generic config param, which would allow us to fix a lot more issues >>>>>> which are just like this one, is IMO a far better idea. >>>>>> >>>>>> Thus, my vote is +1 for STRICT_JSF_2_COMPATIBILITY and +0 for Bernd's >>>>>> suggestion. >>>>>> >>>>>> Regards, >>>>>> Jakob >>>>>> >>>>>> 2011/9/22 Martin Marinschek<[email protected]>: >>>>>>> >>>>>>> +1 in general, +1 to Bernd's suggestion. >>>>>>> >>>>>>> best regards, >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> On Thu, Sep 22, 2011 at 9:59 AM, Gerhard Petracek >>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> @bernd: +1 >>>>>>>> regards, >>>>>>>> gerhard >>>>>>>> >>>>>>>> http://www.irian.at >>>>>>>> >>>>>>>> Your JSF powerhouse - >>>>>>>> JSF Consulting, Development and >>>>>>>> Courses in English and German >>>>>>>> >>>>>>>> Professional Support for Apache MyFaces >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2011/9/22 Bernd Bohmann<[email protected]> >>>>>>>>> >>>>>>>>> I agree STRICT_JSF_2_COMPATIBILITY is too generic. I think the >>>>> >>>>> param >>>>>>>>> >>>>>>>>> should contain EL, TYPE, MAP, RESOLVER, NULL. And it should >>>>> >>>>> enabled by >>>>>>>>> >>>>>>>>> default. >>>>>>>>> >>>>>>>>> Regards >>>>>>>>> >>>>>>>>> Bernd >>>>>>>>> >>>>>>>>> On Wed, Sep 21, 2011 at 11:50 PM, Mark >>>>> >>>>> Struberg<[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> Shouldnt the config contain the text EL_TYPE or so? >>>>>>>>>> We have far too many strict JSF spec flags already ;) >>>>>>>>>> >>>>>>>>>> LieGrue, >>>>>>>>>> strub >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ----- Original Message ----- >>>>>>>>>>> >>>>>>>>>>> From: Jakob Korherr<[email protected]> >>>>>>>>>>> To: MyFaces Development<[email protected]> >>>>>>>>>>> Cc: [email protected] >>>>>>>>>>> Sent: Wednesday, September 21, 2011 10:20 PM >>>>>>>>>>> Subject: Re: [VOTE] fix MYFACES-2552 for 2.0.x and >>>>> >>>>> 2.1.x branches >>>>>>>>>>> >>>>>>>>>>> +1 for including the fix in 2.0.x and 2.1.x + adding >>>>>>>>>>> org.apache.myfaces.STRICT_JSF_2_COMPATIBILITY >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Jakob >>>>>>>>>>> >>>>>>>>>>> 2011/9/21 Leonardo Uribe<[email protected]>: >>>>>>>>>>>> >>>>>>>>>>>> Hi >>>>>>>>>>>> >>>>>>>>>>>> @Matt Benson: Could you attach at least the >>>>> >>>>> fragment with the >>>>>>>>>>>> >>>>>>>>>>>> solution >>>>>>>>>>>> for MYFACES-2552 ? so I can check it, create a >>>>> >>>>> patch for myfaces and >>>>>>>>>>>> >>>>>>>>>>>> write a page on: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>> https://cwiki.apache.org/confluence/display/MYFACES/Composite+Components >>>>>>>>>>>> >>>>>>>>>>>> with the explanation and the solution using a >>>>> >>>>> custom EL resolver. >>>>>>>>>>>> >>>>>>>>>>>> That >>>>>>>>>>>> would be very helpful. >>>>>>>>>>>> >>>>>>>>>>>> regards, >>>>>>>>>>>> >>>>>>>>>>>> Leonardo Uribe >>>>>>>>>>>> >>>>>>>>>>>> 2011/9/21 Leonardo Uribe<[email protected]>: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi >>>>>>>>>>>>> >>>>>>>>>>>>> It should be a param starting with >>>>> >>>>> org.apache.myfaces, like >>>>>>>>>>>>> >>>>>>>>>>>>> org.apache.myfaces.STRICT_JSF_2_COMPATIBILITY >>>>>>>>>>>>> >>>>>>>>>>>>> The important part is that by default it >>>>> >>>>> should be disabled, to >>>>>>>>>>>>> >>>>>>>>>>>>> prevent receive over and over the same >>>>> >>>>> report. >>>>>>>>>>>>> >>>>>>>>>>>>> In theory, it is possible to write a custom >>>>> >>>>> EL resolver that check >>>>>>>>>>>>> >>>>>>>>>>>>> if >>>>>>>>>>>>> the base object implements >>>>>>>>>>>>> >>>>> javax.faces.el.CompositeComponentExpressionHolder and if that so, do >>>>>>>>>>>>> >>>>>>>>>>>>> the required stuff only on getType(). So, if >>>>> >>>>> somebody is writing a >>>>>>>>>>>>> >>>>>>>>>>>>> composite component that relies on this >>>>> >>>>> behavior, it is possible to >>>>>>>>>>>>> >>>>>>>>>>>>> write the fix in a portable way to both >>>>> >>>>> Mojarra and MyFaces (thanks >>>>>>>>>>>>> >>>>>>>>>>>>> to >>>>>>>>>>>>> CompositeComponentExpressionHolder). >>>>>>>>>>>>> >>>>>>>>>>>>> Note the change does not cause any side >>>>> >>>>> effects, because nobody >>>>>>>>>>>>> >>>>>>>>>>>>> relies >>>>>>>>>>>>> on the "wrong" behavior, and what >>>>> >>>>> user wants is components >>>>>>>>>>> >>>>>>>>>>> work as >>>>>>>>>>>>> >>>>>>>>>>>>> expected. >>>>>>>>>>>>> >>>>>>>>>>>>> regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Leonardo Uribe >>>>>>>>>>>>> >>>>>>>>>>>>> 2011/9/21 Mark >>>>> >>>>> Struberg<[email protected]>: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Not sure about that. >>>>>>>>>>>>>> Does the param start with javax.faces? In >>>>> >>>>> this case we should >>>>>>>>>>> >>>>>>>>>>> rather use an own internal one. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Btw, if it's not in the spec even >>>>> >>>>> Mojarra would not be allowed >>>>>>>>>>> >>>>>>>>>>> to use a proprietary parameter with >>>>> >>>>> "javax...." >>>>>>>>>>>>>> >>>>>>>>>>>>>> LieGrue, >>>>>>>>>>>>>> strub >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> From: Matt >>>>> >>>>> Benson<[email protected]> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> To: MyFaces >>>>> >>>>> Development<[email protected]> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cc: >>>>>>>>>>>>>>> Sent: Wednesday, September 21, 2011 >>>>> >>>>> 6:29 PM >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Subject: Re: [VOTE] fix MYFACES-2552 >>>>> >>>>> for 2.0.x and 2.1.x >>>>>>>>>>> >>>>>>>>>>> branches >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> However, let's simplify the >>>>> >>>>> context parameter by giving it >>>>>>>>>>> >>>>>>>>>>> a name >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> relating to JSF 2.2 compatibility. I >>>>> >>>>> submitted the final >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> implementation for Mojarra, so have >>>>> >>>>> every right to add the same >>>>>>>>>>> >>>>>>>>>>> to >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> MyFaces. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Matt >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Sep 21, 2011 at 11:19 AM, >>>>> >>>>> Gerhard Petracek >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <[email protected]> >>>>> >>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> +1 for it in combination with >>>>> >>>>> the context parameter >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> regards, >>>>>>>>>>>>>>>> gerhard >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> http://www.irian.at >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Your JSF powerhouse - >>>>>>>>>>>>>>>> JSF Consulting, Development and >>>>>>>>>>>>>>>> Courses in English and German >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Professional Support for Apache >>>>> >>>>> MyFaces >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2011/9/21 Rudy De >>>>> >>>>> Busscher<[email protected]> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>>>> And if we create a context >>>>> >>>>> parameter, it should behave >>>>>>>>>>> >>>>>>>>>>> by default as in >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> the JSF 2.2 Spec. If users >>>>> >>>>> want strict spec >>>>>>>>>>> >>>>>>>>>>> (2.0/2.1)behaviour they >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> have to >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> set the parameter value. >>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>> Rudy >>>>>>>>>>>>>>>>> On 21 September 2011 17:08, >>>>> >>>>> Grant Smith >>>>>>>>>>> >>>>>>>>>>> <[email protected]> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> +1 if it's >>>>> >>>>> configurable in a >>>>>>>>>>> >>>>>>>>>>> <context-param>. How about >>>>>>>>>>>>>>>>>> >>>>>>>>>>> org.apache.myfaces.EL_RESOLVER_GETTYPE_RETURNS_NULL ? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Wed, Sep 21, 2011 at >>>>> >>>>> 5:35 AM, Michael Kurz >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Am 21.09.2011 um >>>>> >>>>> 14:20 schrieb Leonardo Uribe: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> > +1 >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > 2011/9/21 >>>>> >>>>> Leonardo Uribe >>>>>>>>>>> >>>>>>>>>>> <[email protected]>: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> Hi >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> More than >>>>> >>>>> a year ago, it was found >>>>>>>>>>> >>>>>>>>>>> that EL expressions >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> like >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> >>>>> >>>>> #{cc.attrs.test} does not resolve its >>>>>>>>>>> >>>>>>>>>>> type correctly, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> because the >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> composite >>>>> >>>>> component EL resolver is >>>>>>>>>>> >>>>>>>>>>> not able to find >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> the right type. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> Instead, >>>>> >>>>> MapELResolver always return >>>>>>>>>>> >>>>>>>>>>> Object.class as >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> type, breaking >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> composite >>>>> >>>>> components that use >>>>>>>>>>> >>>>>>>>>>> h:selectOneXXX into its >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> internals. See >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>> >>>>>>>>>>> https://issues.apache.org/jira/browse/MYFACES-2552 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> The >>>>> >>>>> problem with this issue is we >>>>>>>>>>> >>>>>>>>>>> need to change the >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> way how >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >>>>>>>>>>> >>>>> org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> works. JSF >>>>> >>>>> 2.0 spec clearly says in >>>>>>>>>>> >>>>>>>>>>> its section >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 5.6.2.2 that >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> getType() >>>>>>>>>>>>>>>>>>> >> for that >>>>> >>>>> EL resolver should return >>>>>>>>>>> >>>>>>>>>>> null. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> The issue >>>>> >>>>> was reported to the EG and >>>>>>>>>>> >>>>>>>>>>> a fix was >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> included in JSF 2.2. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> spec, see: >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >>>>> http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-745 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> but we >>>>> >>>>> still receive reports about >>>>>>>>>>> >>>>>>>>>>> the same issue >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> (MYFACES-3311 and >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> others >>>>> >>>>> (last comment on MYFACES-1890) >>>>>>>>>>> >>>>>>>>>>> ). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> So, the >>>>> >>>>> current behavior even if is >>>>>>>>>>> >>>>>>>>>>> described by the >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> spec is too >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> >>>>> >>>>> inconvenient. Note we already have >>>>>>>>>>> >>>>>>>>>>> some places in our >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> implementation >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> that does >>>>> >>>>> not follow strictly the >>>>>>>>>>> >>>>>>>>>>> spec, to keep things >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> working as >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> users >>>>> >>>>> expect. To follow the protocol >>>>>>>>>>> >>>>>>>>>>> in these cases, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> we need an >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> official >>>>> >>>>> community decision about >>>>>>>>>>> >>>>>>>>>>> include it in 2.0.x >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> and 2.1.x >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> branches. >>>>> >>>>> Please vote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> +1 if you >>>>> >>>>> want this fix included in >>>>>>>>>>> >>>>>>>>>>> 2.0.x and 2.1.x. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> +0 >>>>>>>>>>>>>>>>>>> >> -1 and the >>>>> >>>>> reason why if you see this >>>>>>>>>>> >>>>>>>>>>> could cause any >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> problem. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> regards, >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> Leonardo >>>>> >>>>> Uribe >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> [1] >>>>>>>>>>>>>>> >>>>> http://www.apache.org/foundation/voting.html#ReleaseVotes >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Grant Smith - V.P. >>>>> >>>>> Information Technology >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Marathon Computer >>>>> >>>>> Systems, LLC. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Rudy De Busscher >>>>>>>>>>>>>>>>> http://www.c4j.be >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Jakob Korherr >>>>>>>>>>> >>>>>>>>>>> blog: http://www.jakobk.com >>>>>>>>>>> twitter: http://twitter.com/jakobkorherr >>>>>>>>>>> work: http://www.irian.at >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> http://www.irian.at >>>>>>> >>>>>>> Your JSF powerhouse - >>>>>>> JSF Consulting, Development and >>>>>>> Courses in English and German >>>>>>> >>>>>>> Professional Support for Apache MyFaces >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>> > >
