[ANNOUNCE] MyFaces Core v2.3.0-beta Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces Core
2.3.0-beta.

MyFaces Core is a JavaServer(tm) Faces 2.3 implementation as specified by
JSR-372.

MyFaces Core 2.3.0-beta is available in both binary and source
distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under Group
ID "org.apache.myfaces.core".

Release Notes - MyFaces Core - Version 2.3.0-beta

Sub-task

[MYFACES-4092] - Implement CDI extension for @FacesDataModel
[MYFACES-4093] - Implement CDI extension for @FacesConverter
[MYFACES-4094] - Implement CDI extension for @FacesValidator
[MYFACES-4095] - Implement CDI extension for @FacesBehavior
[MYFACES-4096] - Implement CDI extension for @ManagedProperty
[MYFACES-4097] - Implement CDI changes for @FacesConfig

Bug

[MYFACES-3644] - cleanup ViewState handling
[MYFACES-4104] - Update plugins to compile java 8 code in JSF 2.3 branch
[MYFACES-4105] - Implement extensionless mapping of views
[MYFACES-4107] - StringIndexOutOfBoundsException in getResourceVersion
[MYFACES-4117] - No default name for @FacesComponent with
createTag=true and no tagName
[MYFACES-4119] - Disposal method from PushContextFactoryBean is missing
@Push annotation

Improvement

[MYFACES-4099] - Allow resolve #{cc} inside templates called from a
composite component
[MYFACES-4102] - Check improvements in FlowHandler for JSF 2.3

New Feature

[MYFACES-4069] - Implement f:websocket and related api
[MYFACES-4070] - Implement h:commandScript and related api
[MYFACES-4071] - Implement dynamic resource loading in ajax requests
[MYFACES-4075] - SearchExpression API
[MYFACES-4078] - Expose StateCacheFactory/StateCache as a SPI service
[MYFACES-4079] - Implement CDI changes for JSF 2.3
[MYFACES-4083] - Add copy constructor to wrappers
[MYFACES-4084] - Implement f:importConstants
[MYFACES-4085] - Constants for "jsf.js", "javax.faces" and postback
parameters
[MYFACES-4086] - Deprecate native managed beans annotations
[MYFACES-4087] - Add PostRenderViewEvent
[MYFACES-4088] - Add constructor with facesContext to event classes
[MYFACES-4089] - Add Iterable support in UIData and UIRepeat
[MYFACES-4090] - Add Map support in UIData and UIRepeat
[MYFACES-4091] - Add custom type support in UIData and UIRepeat
[MYFACES-4098] - Implement ResourceHandler.getViewResources(...)
[MYFACES-4101] - Implement f:importConstants
[MYFACES-4103] - Implement ViewHandler.getViews(...)
[MYFACES-4106] - Implement ResourceHandler.markResourceRendered(...)
and ResourceHandler.isResourceRendered(...)
[MYFACES-4108] - Implement FaceletCache.setCacheFactories(...)
[MYFACES-4109] - Implement f:validateWholeBean
[MYFACES-4110] - Implement javax.faces.model.IterableDataModel
[MYFACES-4111] - Implement h:column styleClass property
[MYFACES-4112] - Implement h:dataTable rowClass
[MYFACES-4113] - Implement h:panelGrid rowClass
[MYFACES-4115] - Implement h:selectOneRadio "group" (distributed radio
button)
[MYFACES-4116] - Implement JDK 8 time support in f:convertDateTime
[MYFACES-4118] - Implement new changes of javax.faces.ViewState update
on ajax for multiple forms

Task

[MYFACES-4121] - Fix javadoc for 2.3 branch and update
maven-javadoc-plugin

regards,

Leonardo Uribe

[ANNOUNCE] MyFaces Core v2.2.12 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces Core
2.2.12.

MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified by
JSR-344.

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

MyFaces Core 2.2.12 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under Group
ID "org.apache.myfaces.core".

Release Notes - MyFaces Core - Version 2.2.12

Bug

[MYFACES-4064] - EL 3.0 Collection construction broken
[MYFACES-4066] - FlowBuilderFactoryBean Concurrency Issue
[MYFACES-4068] - Ajax-Listener (PrimeFaces) is not called for some
selection-components
[MYFACES-4072] - passthrough checked always set

regards,

Leonardo Uribe

Re: Reg vulnerability for Server State saving

[Leonardo Uribe]

Hi

It is in the wiki page. See org.apache.myfaces.ALGORITHM.IV web config
param for details.

If you want to take a look at the class where the encryption happens, see
org.apache.myfaces.shared.util.StateUtils in

http://svn.apache.org/repos/asf/myfaces/core/trunk/shared/src/main/java/org/apache/myfaces/shared/util/StateUtils.java

regards,

Leonardo Uribe


2017-01-29 23:39 GMT-05:00 karthik kn <keyan...@gmail.com>:

> Any thoughts on the below ?
>
> On Fri, Jan 27, 2017 at 10:57 AM, karthik kn <keyan...@gmail.com> wrote:
>
> > Hi All,
> > We were able to update the jsf version to the lates and randomly generate
> > the enc key as mentioned in
> > https://wiki.apache.org/myfaces/Secure_Your_Application
> >
> > However, the Initialization vector for CBC needs to be mentioned. Can we
> > not generate it randomly ?
> >
> > Is this a bug in JSF ?
> >
> > If i could generate the Enc key, then the IV should have been generated
> > randomly.
> >
> > Please let know
> >
> > On Fri, Dec 23, 2016 at 3:54 PM, Thomas Andraschko <
> > andraschko.tho...@gmail.com> wrote:
> >
> >> Hi,
> >>
> >> i don't think there is any other way to configure it but you can still
> >> check the sources: http://svn.apache.org/viewvc/m
> >> yfaces/core/branches/1.1.x/
> >>
> >> Regards,
> >> Thomas
> >>
> >> 2016-12-23 11:21 GMT+01:00 karthik kn <keyan...@gmail.com>:
> >>
> >> > Hi All,
> >> > Any thoughts on the below ?
> >> >
> >> > On Wed, Dec 21, 2016 at 10:22 AM, karthik kn <keyan...@gmail.com>
> >> wrote:
> >> >
> >> > > Hi,
> >> > > If i use a new key in web.xml as SECRET, it could be still  exposed
> to
> >> > the
> >> > > Administrator on accessing the system.
> >> > >
> >> > > Wont this cause a vulnerability ? Is there any other mechanism of
> >> storing
> >> > > the secret ?
> >> > >
> >> > > On Tue, Dec 20, 2016 at 6:52 PM, Moritz Bechler <bech...@agno3.eu>
> >> > wrote:
> >> > >
> >> > >> Hi,
> >> > >>
> >> > >> > Thank you for clarification. Using the secret mentioned in the
> >> below
> >> > >> page
> >> > >> > would suffice or there is some mechanism to generate the SECRET ?
> >> > >> >
> >> > >>
> >> > >> You must not use the keys specified on this page but generate your
> >> own
> >> > >> secret ones. An attacker using the same key can then produce a
> valid
> >> > >> ViewState token containing an exploit. Also, as noted on the
> security
> >> > >> page and by Leonardo, version up to and including 1.1.7, 1.2.8,
> 2.0.0
> >> > >> are vulnerable to padding oracle attacks (I haven't had a close
> look
> >> but
> >> > >> I would be pretty sure that also applies to server side state
> >> saving).
> >> > >> That means that an attacker may be able to create such tokens
> without
> >> > >> the knowledge of the key - again allowing for the same exploits.
> >> > >>
> >> > >> So I guess there is no way to be really safe without upgrading.
> >> > >>
> >> > >>
> >> > >> Moritz
> >> > >>
> >> > >> PS: you also might want to consider using something stronger than
> >> DES.
> >> > >>
> >> > >>
> >> > >> --
> >> > >> AgNO3 GmbH & Co. KG, Sitz Tübingen, Amtsgericht Stuttgart HRA
> 728731
> >> > >> Persönlich haftend:
> >> > >> Metagesellschaft mbH, Sitz Tübingen, Amtsgericht Stuttgart HRB
> >> 744820,
> >> > >> Vertreten durch Joachim Keltsch
> >> > >>
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > -
> >> > > Thanks & Regards
> >> > >
> >> > > Karthik.K.N
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > -
> >> > Thanks & Regards
> >> >
> >> > Karthik.K.N
> >> >
> >>
> >
> >
> >
> > --
> > -
> > Thanks & Regards
> >
> > Karthik.K.N
> >
>
>
>
> --
> -
> Thanks & Regards
>
> Karthik.K.N
>

Re: Reg vulnerability for Server State saving

[Leonardo Uribe]

Hi

1.1.5 is too old. Please update to 1.1.8 or upper versions.

See https://wiki.apache.org/myfaces/Secure_Your_Application  for details.

regards,

Leonardo Uribe

2016-12-19 5:44 GMT-05:00 karthik kn <keyan...@gmail.com>:

> Hi,
> I am using myfaces-1.1.5 and using the following state saving method
>
> javax.faces.STATE_SAVING_
> METHODserver
>
> However,i see that the object identifier is being sent to the server as
> following
>
>  id="javax.faces.ViewState"
> value="rO0ABXVyABNbTGphdmEubGFuZy5PYmplY3Q7kM5YnxBzKWwCAAB4cAN0
> AAEzcHQAJi9qc3AvaGxyL2FjX3N1YnNjcmliZXIvY3J0U2luZ2xlQUMuanNw"
> />
>
> This is the serialized object identifier sent over the network
>
> We are using only https and not http.
>
> Does sending this serialized object identifier without encrypting open any
> vulnerability which the attacker could use to his/her advantage ?
>
> --
> -
> Thanks & Regards
>
> Karthik.K.N
>

[ANNOUNCE] MyFaces Core v2.2.11 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces Core
2.2.11.

MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified by
JSR-344.

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

MyFaces Core 2.2.11 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under Group
ID "org.apache.myfaces.core".

Release Notes - MyFaces Core - Version 2.2.11

Bug

[MYFACES-4036] - UIData state is not restorable when rowStatePreserved
is set to true
[MYFACES-4047] - @PreDestroy method not invokved on
javax.faces.bean.ViewScoped beans on Session invalidation
[MYFACES-4048] - TransientStateHolder values must be stored in the
state if current phase is before render response
[MYFACES-4049] - JSF myfaces unsynchronized access to a WeakHashMap
[MYFACES-4050] - Validators not invoked for empty selectManyCheckbox
components
[MYFACES-4051] - FacesMessage.Severity always set to ERROR after
ValidatorException
[MYFACES-4052] - Multiple  with same name encodes only last
one in link URL
[MYFACES-4057] - Serializable ViewScopeContextualStorage references
non-serializable BeanManager
[MYFACES-4060] - Required attribute of h:inputFile tag is not working

Improvement

[MYFACES-4046] - Allow programmatic component with ui:include with
ui:param

Task

[MYFACES-4045] - Review Faces Flow reentrant condition

regards,

Leonardo Uribe

Re: MyFaces 2.2.10 and Red Hat EAP 6.4.8 issue with memory leak of @viewscope

[Leonardo Uribe]

Hi

I'm cc to MyFaces users list, because these issues should be discussed
there.

It is a known issue, in resume it is JBossWeb fault, because that map
should be a WeakHashMap but synchronized, to ensure the instances are
discarded when the beans are serialised into session (in that case destroy
will not be called). The fix should be done in WebInjectionContainer, but
set org.apache.myfaces.SERIALIZE_STATE_IN_SESSION
<https://myfaces.apache.org/core20/myfaces-impl/webconfig.html#org_apache_myfaces_SERIALIZE_STATE_IN_SESSION>
to
false could help to mitigate a bit the leak.

There is an issue related to @PreDestroy and view scope in

https://issues.apache.org/jira/browse/MYFACES-4047

but I guess it won't help in your case, because the leak is caused by the
map itself.

regards,

Leonardo Uribe


2016-09-01 3:34 GMT-05:00 Thony Lundin <thony.lun...@tieto.com>:

> Hi Leonardo,
>
> writing you since you are MyFaces core project lead and want to ask about
> a possible issue in MyFaces 2.2.10 regarding not released viewscope beans.
>
> I have seen on Internet that there was multiple such issues reported for
> mojarra in the past and Red Hat did some fix in their EAP 6.1.1 or
> so (in the mojarra module) to solve this issue.
>
> Problem for us is that we came from using tomcat and went on top of Red
> Hat EAP with JBossWeb and wanted to keep MyFaces (since it provided us with
> best performance and configuration options) but we are hit by this memory
> leak that somehow MyFaces and JBossWeb do not interact properly when a
> viewscope bean is getting invalidated. Problem is that when viewscope is
> invalidated the reference to our controllers are still kept in JBossWeb
> WebInjectionContainer and it is kept there forever, even if session expires?
>
> org.jboss.as.web.deployment.WebInjectionContainer @ 0xc45318d8 | 32 |
> 649,769,928 | 73.07% |- org.jboss.as.web.deployment.ConcurrentReferenceHashMap
> @ 0xc4532518 | 48 | 649,766,792 | 73.07% | '- org.jboss.as.web.deployment.
> ConcurrentReferenceHashMap$Segment[4] @ 0xc4532548| 32 | 649,766,744 |
> 73.07% | |- org.jboss.as.web.deployment.ConcurrentReferenceHashMap$Segment
> @ 0xc4532568| 56 | 187,909,296 | 21.13%
>
> Red Hat will not do anything due to that they only support mojarra so I am
> asking if this is something known on MyFaces project and if there is
> something that could be done on MyFaces core side about it (just asking
> since same problem for JBossWeb was solved somehow on mojarra side)
> or if you think this is a JBossWeb fault?
>
> Grateful for any information you can share on this issue.
>
> Best Regards,
> Thony
>

[ANNOUNCE] MyFaces Trinidad v2.1.1 Release

[Leonardo Uribe]

 FacesMessageWrapper and Skin Addition enhancements
[TRINIDAD-2476] - MApplication.java needs to override subscribeToEvent
[TRINIDAD-2496] - Support custom negative prefix and suffix on
af:convertNumber
[TRINIDAD-2501] - Renderkit Test Improvements
[TRINIDAD-2502] - Finish RenderKit Test Improvements so we can always
run all tests
[TRINIDAD-2507] - Allow CoreRenderer to take part in broadcast of a
FacesEvent
[TRINIDAD-2510] - make SkinTestCase more extendable
[TRINIDAD-2514] - Make isEmailMode check more lenient

New Feature

[TRINIDAD-2459] - Addition of ValueUpdatedEvent + ValueUpdatedListener

regards,

Leonardo Uribe

Re: addResource to add CSS JS - Only working on PostBack

[Leonardo Uribe]

Hi

Add the resource in afterPhase(...) is too late in the lifecycle, because
if the response was flushed the script could not be rendered. Add it in
beforePhase(...)  of render response should work.

Just FYI, ExtensionsFilter class is the one responsible to create the
buffer and then parse the response and insert the code.

The API was meant to be used in components, but I do not see any reason why
it should not work. It could be an old bug that was fixed at some point in
time.

regards,

Leonardo Uribe

2016-04-19 14:14 GMT-05:00 Mike Kienenberger <mkien...@gmail.com>:

> I guess it probably doesn't help -- it looks like your phase listener
> was already using RENDER_RESPONSE.
>
> On Tue, Apr 19, 2016 at 3:13 PM, Mike Kienenberger <mkien...@gmail.com>
> wrote:
> > There is only a RENDER_RESPONSE phase for the initial request in a
> > phase listener, but all of the phases in a postback.
> >
> > Does that help?
> >
> >
> > On Tue, Apr 19, 2016 at 2:09 PM, fischman_98
> > <mfisc...@powerconsultantsinc.com> wrote:
> >> *FYI*: When added the call to addResource in encodeEnd method of a
> Custom
> >> Component it works on both /*initial request*/ and /*postback */.
> >>
> >> Here's the initial request;
> >>
> >> RESTORE_VIEW(1) :: Before
> >> RESTORE_VIEW(1) :: After
> >> RENDER_RESPONSE(6) :: Before
> >> *AddResource Here!*
> >> RENDER_RESPONSE(6) :: After
> >>
> >> Same code I had in the listener in the encodeEnd;
> >>
> >> AddResource ar = AddResourceFactory.getInstance(facesContext);
> >> ar.addInlineScriptAtPosition(facesContext,
> AddResource.HEADER_BEGIN,
> >> "window.open()");
> >> System.out.println("AddResource Here!");
> >>
> >> Soany thoughts why it works from the component and not from the
> phase
> >> listener?
> >>
> >> Thanks.
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context:
> http://myfaces.10567.n7.nabble.com/addResource-to-add-CSS-JS-Only-working-on-PostBack-tp121593p121619.html
> >> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>

Re: addResource to add CSS JS - Only working on PostBack

[Leonardo Uribe]

Hi

AddResource API in its default implementation use a buffer to render
resources, but on render response phase, so you should aim to add your
resources in that phase. A custom phase listener or a custom component
using the code in encodeXXX should work.

Regards,

Leonardo
On Apr 19, 2016 8:05 AM, "fischman_98" 
wrote:

> So are you confirming/agreeing that the result of an addResource call is
> handled in the Apply Request phase?
>
> And as to /only need to adjust the code a bit/, what code and where?  I was
> trying in a phaselistener, are you suggesting a custom ViewHandler, custom
> component or ?
>
> Matt
>
>
>
> --
> View this message in context:
> http://myfaces.10567.n7.nabble.com/addResource-to-add-CSS-JS-Only-working-on-PostBack-tp121593p121611.html
> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>

Re: addResource to add CSS JS - Only working on PostBack

[Leonardo Uribe]

Hi

"apply request value" phase is invoked on postback only. In the initial
request, only 2 phases are executed: restore view phase and render view
phase. Probably you only need to adjust the code a bit.

regards,

Leonardo Uribe

2016-04-14 21:31 GMT-05:00 fischman_98 <mfisc...@powerconsultantsinc.com>:

> To all,
>
> I still have a MyFaces 1.1.6/Tomahawk 1.1.10 in production, client not
> giving the time to migrate to 2.X.
>
> That said, I'm trying to add javascript to specific pages  section (security code to stop the page from being included in frames;  href="https://www.owasp.org/index.php/Cross_Frame_Scripting
> ">Cross_Frame_Scripting
> ).
>
> Instead of just adding it to the pages between 
> tags, I am trying to use org.apache.myfaces.renderkit.html.util.AddResource
> to inject the CSS and JS (/analyze the directories and add it to specific
> pages/).
>
> I thought to do it in a phaseListener.
>
> Problem is, I can't get it to work on the *initial reques*t, only on
> *PostBacks* (/is it done in the *Apply Requests* phase/?).
>
> Seems like I should be able to intercept the response and add this...I have
> the Extensions Filter (Tomahawk) set up and have added ADD_RESOURCE_CLASS
> (DefaultAddResource) to the context in web.xml.
>
> Anyone have any thoughts?
>
> I haven't posted a question in a long while...I would love to hear a
> solution for this (/relatively/) Old School set up!
>
> Thanks.
>
>
>
>
>
>
>
> --
> View this message in context:
> http://myfaces.10567.n7.nabble.com/addResource-to-add-CSS-JS-Only-working-on-PostBack-tp121593.html
> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>

[ANNOUNCE] MyFaces Core v2.2.10 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces Core
2.2.10.

MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified by
JSR-344.

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

MyFaces Core 2.2.10 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under Group
ID "org.apache.myfaces.core".

Release Notes - MyFaces Core - Version 2.2.10

Bug

[MYFACES-3904] - jsf.util.Chain() is rendered with wrong event source
[MYFACES-3905] - The caption facet is not documented for the tag
.
[MYFACES-3926] - Disabled h:outputLink renders invalid attributes
[MYFACES-3959] - f:metadata inside ui:remove will be also executed
[MYFACES-3987] - NPE in FlashImpl.isKeepMessages
[MYFACES-4022] - Faces Flows are not discovered when the web
application is packaged inside an EAR
[MYFACES-4024] - Update the NOTICE.txt file in jsf.myfaces
[MYFACES-4025] - Incorrect JS content-type
[MYFACES-4030] - MyFaces CDI support is disabled if non-CDI application
is loaded first
[MYFACES-4031] - Facelets does not render empty XHTML attribute
[MYFACES-4032] - upgrade common-beanutils to 1.9.2
[MYFACES-4034] - submitForm() not defined for myfaces.JSF_JS_MODE
'minimal-modern'
[MYFACES-4038] - Flow beans are destroyed before flow is finalized
[MYFACES-4041] - EL evaluation fails when state is saved because
FaceletState object is not present

Improvement

[MYFACES-3497] - [perf] Improve EventHandler
[MYFACES-3552] - [perf] pps: reduce amout of Object [] created in
_DeltaList.saveState
[MYFACES-3892] - Create a option to execute BeanValidation before
JSF-Validation
[MYFACES-4027] - Increase import range for javax.el-api to include
version 3.0 of javax.el-api
[MYFACES-4042] - Improve startup time by skipping classpath jar scan
for *.faces-config.xml

Task

[MYFACES-4020] - Update commons-collections to 3.2.2


regards,

Leonardo Uribe

[ANNOUNCE] MyFaces Core v2.1.18 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces Core
2.1.18.

MyFaces Core is a JavaServer(tm) Faces 2.1 implementation as specified by
JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100% compliant
with the JSR-314 specification.

MyFaces Core 2.1.18 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under Group
ID "org.apache.myfaces.core".

Release Notes - MyFaces Core - Version 2.1.18

Bug

[MYFACES-3233] - f:ajax event - type="javax.el.ValueExpression (must
evaluate to java.lang.String)" not supported
[MYFACES-3949] - javax.faces.ViewState autocomplete
[MYFACES-3951] - Action not performed on first click
[MYFACES-3957] - Disabled h:commandLink results in rendering of a span
with onclick
[MYFACES-3960] - AjaxBehaviorEvent should be queued before ActionEvent
[MYFACES-3965] - SKIP_ITERATION visit hint not set when component tree
is visited during navigation
[MYFACES-3988] - An empty tag in a custom tag-lib causes an Exception
[MYFACES-4025] - Incorrect JS content-type
[MYFACES-4031] - Facelets does not render empty XHTML attribute

regards,

Leonardo Uribe

[ANNOUNCE] MyFaces Core v2.0.24 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces Core
2.0.24.

MyFaces Core is a JavaServer(tm) Faces 2.0 implementation as specified by
JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100% compliant
with the JSR-314 specification.

MyFaces Core 2.0.24 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under Group
ID "org.apache.myfaces.core".

Release Notes - MyFaces Core - Version 2.0.24

Bug

[MYFACES-3949] - javax.faces.ViewState autocomplete
[MYFACES-3951] - Action not performed on first click
[MYFACES-3957] - Disabled h:commandLink results in rendering of a span
with onclick
[MYFACES-3960] - AjaxBehaviorEvent should be queued before ActionEvent
[MYFACES-3988] - An empty tag in a custom tag-lib causes an Exception
[MYFACES-4025] - Incorrect JS content-type

regards,

Leonardo Uribe

Re: FW: Tomcat Security Exceptions on deployment of example war (reformatted)

[Leonardo Uribe]

Hi

I think the problem here is that it is not clear what needs to be fixed.
Looking on the stack trace and in the code:

protected JspFactory getJspFactory()
{
if (jspFactory == null)
{
// TODO: this Class.forName will be removed when Tomcat fixes a
bug
// also, we should then be able to remove jasper.jar from the
deployment
try
{

Class.forName("org.apache.jasper.compiler.JspRuntimeContext");
}
catch (ClassNotFoundException e)
{
// ignore
}
catch (Exception ex)
{
log.log(Level.FINE, "An unexpected exception occured "
+ "while loading the JspRuntimeContext.", ex);
}

jspFactory = JspFactory.getDefaultFactory();
}

return jspFactory;
}

These lines are very old. Looking on the svn it comes from 1.2.x, see:

https://issues.apache.org/jira/browse/MYFACES-1693

Probably the solution could be catch a Throwable instead an Exception and
swallow it (just log but continue startup). I mean, this line looks like
something done by some reason long time ago by a bug in Tomcat.

It is clear the security manager is causing trouble in this case, but since
JSP was deprecated since JSF 2.0, should we worry about this one?

Please note there is a web config param called
org.apache.myfaces.FACES_INITIALIZER that allows you to bypass the default
initializer and provide a custom one (so you can copy the default
initializer and customize it to your needs), or set
org.apache.myfaces.SUPPORT_JSP_AND_FACES_EL disable JSP and uses
org.apache.myfaces.webapp.FaceletsInitilializer instead.

There are plenty of options to deal with this issue. Please try the options
I have described here and let us know if that works for you or not, so if
necessary we can fix the lines if necessary.

regards,

Leonardo Uribe


2016-03-30 11:40 GMT-05:00 Neil Richards <neilricha...@iname.com>:

> OK thanks :)
>
> -Original Message-
> From: Mike Kienenberger [mailto:mkien...@gmail.com]
> Sent: 30 March 2016 16:47
> To: MyFaces Discussion <users@myfaces.apache.org>
> Subject: Re: FW: Tomcat Security Exceptions on deployment of example war
> (reformatted)
>
> MyFaces is a project staffed by volunteers.   While things are
> normally fixed rather quickly, it all depends on the various individuals
> involved with that particular area and their available free time.
>
> One thing that would greatly speed up the process is if you were to submit
> a unified diff patch fixing the problem.
>
> On Wed, Mar 30, 2016 at 11:28 AM, Neil Richards <neilricha...@iname.com>
> wrote:
> > Hi,
> >
> > As you can imagine this has become a bit of a showstopper for me. I've
> > added a bug report but as yet it has not been assigned or commented on
> > etc. Just wondering how long these issues take to fix? Assume we're
> talking months?
> > Need to have some idea to determine how to move forward.
> >
> > Many thanks,
> > Neil
> >
> > -Original Message-
> > From: Werner Punz [mailto:werner.p...@gmail.com]
> > Sent: 04 March 2016 07:36
> > To: users@myfaces.apache.org
> > Subject: Re: FW: Tomcat Security Exceptions on deployment of example
> > war
> > (reformatted)
> >
> > Hi this is clearly a bug.
> > Can you please put a bugreport on
> >
> > https://issues.apache.org/jira/browse/MYFACES
> >
> > Werner
> >
> >
> >
> > Am 02.03.16 um 23:12 schrieb Neil Richards:
> >> Hi,
> >>
> >> I've been having trouble deploying my MyFaces(2.2.9) app on Tomcat 8
> >> with the security manager enabled, so I then tried deploying the
> >> myfaces-example-simple-1.1.14.war and had the same problem. I need
> >> the security manager enabled as I am deploying in production on a
> >> shared
> > Tomcat
> >> instance and the hosts will not allow the   RuntimePermissions on
> >> org.apache.catalina.core, org.apache.catalina.servlets or
> >> org.apache.jasper.compiler. These are the stack traces I get:
> >>
> >> 02-Mar-2016 22:08:54.902 INFO [localhost-startStop-1]
> >> org.apache.catalina.loader.WebappClassLoaderBase.loadClass Security
> >> Violation, attempt to use Re stricted Class:
> >> org.apache.catalina.servlets.DefaultServlet
> >>   java.security.AccessControlException: access denied
> >> ("java.lang.RuntimePermission"
> >> "accessClassInPackage.org.apache.catalina.servlets")
> >>  at
> >> java.security.AccessControlContex

Re: bug in FacesServlet?

[Leonardo Uribe]

Hi

It could be possible, I do not have all the details, but I have the
impression that happens on jsp, or at least I have seen that before.
MyFaces does what the spec says, but this part could not be well defined.

It is clear the release should happen after the end of the lifecycle, but
since the rendering step is delegated to jsp in this case, after that point
there is no control, so the code just release in that point. The problem
here is we don't know what happens for different jsp containers. In my
understanding not every jsp implementation works the same, but as I said, I
have not entered into details.

regards,

Leonardo Uribe

2016-03-25 13:15 GMT-05:00 Romain Manni-Bucau <rmannibu...@gmail.com>:

> Hi guys,
>
> org.apache.myfaces.context.servlet.FacesContextImpl#release does the
> release but javax.faces.webapp.FacesServlet#service doesn't handle
> context push/pop so if a JSF request does a JSF include (and retrigger
> the servlet) it will likely reset too early the context.
>
> Here a diagram hoping it helps:
>
> -> request
> -> FacesServlet
>   -> setFacesContext
>  -> FacesServlet
>  -> anything relaunching a JSF "request"
> org.apache.myfaces.view.jsp.JspViewDeclarationLanguage#buildView does
> a forward for instance)
>  -> setFacesContext
>   -> setFacesContext
>   -> releaseFacesContext
>   -> end of lifecycle // oops faces context is null
>   -> releaseFacesContext
>
> Romain Manni-Bucau
> @rmannibucau |  Blog | Github | LinkedIn | Tomitriber
>

Re: No tag defined for name

[Leonardo Uribe]

Hi

Have you tried this web config param?

org.apache.myfaces.STRICT_JSF_2_ALLOW_SLASH_LIBRARY_NAME

set it to true. It was added on this issue:

https://issues.apache.org/jira/browse/MYFACES-3454

regards,

Leonardo Uribe


2015-12-17 12:34 GMT-05:00 Mike Kienenberger <mkien...@gmail.com>:

> It looks right to me.
>
> Is "commons/paging.xhtml" the only component not working?
> Do other components in "components/commons/" work?
> Do other components in "components" work?
>
>
> My app uses .../resources/component/thing.xhtml" but moving "thing.xhtml"
> to "component/common" seems to still work.   I didn't try renaming
> "component" to "components" and I suppose my test of the process may have
> been flawed.   This was under MyFaces 2.1.14.
>
> Maybe creating a simple test app would help you track it down, or at least
> provide an example to use for opening a JIRA issue.   It'd be helpful to
> know if it's only a problem with MyFaces 2.2.x or if it wasn't working for
> you under 2.1.x either.
>
> On Thu, Dec 17, 2015 at 10:40 AM, Chris Baumgartner <
> chris.baumgart...@fujifilm.com> wrote:
>
> > Hello,
> >
> > I have a JSF application that has been using Mojarra for the past 2
> > years. I am attempting to switch to MyFaces 2.2.9, but I am having
> > problems.
> >
> > It doesn't seem to like my composite components. I am getting numerous
> > exceptions like:
> >
> > javax.faces.view.facelets.TagException: /views/records/records.xhtml
> > @81,57  Tag Library supports namespace:
> > http://java.sun.com/jsf/composite/components/common, but no tag was
> > defined for name: paging
> >
> > This worked in Mojarra, but for some reason is not working in MyFaces.
> >
> > My namespace declarations in records.xhtml look like:
> >
> >  >   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;>
> > http://www.w3.org/1999/xhtml;
> >  xmlns:c="http://java.sun.com/jsp/jstl/core;
> >  xmlns:common="
> http://java.sun.com/jsf/composite/components/common
> > "
> >  xmlns:h="http://java.sun.com/jsf/html;
> >  xmlns:f="http://java.sun.com/jsf/core;
> >  xmlns:ui="http://java.sun.com/jsf/facelets;>
> > 
> >
> >
> > My project structure looks like:
> >
> > webapp/resources/components/common/paging.xhtml
> > webapp/templates/template.xhtml
> > webapp/views/records/records.xhtml
> >
> >
> > Any ideas on what is causing this?
> >
> > Thanks.
> >
> >
> > --
> >
> > Chris Baumgartner
> > Java Software Developer
> > FUJIFILM Medical Systems U.S.A., Inc.
> > TeraMedica Division
> > 10400 Innovation Drive, Suite 200
> > Milwaukee, WI 53226
> > Office: (414) 908-7724
> > www.teramedica.com
> >
> > --
> > NOTICE: This message, including any attachments, is only for the use of
> the
> > intended recipient(s) and may contain confidential and privileged
> > information, or information otherwise protected from disclosure by law.
> If
> > the reader of this message is not the intended recipient, you are hereby
> > notified that any use, disclosure, copying, dissemination or distribution
> > of this message or any of its attachments is strictly prohibited.  If you
> > received this message in error, please contact the sender immediately by
> > reply email and destroy this message, including all attachments, and any
> > copies thereof.
> >
>

[ANNOUNCE] MyFaces Core v2.2.9 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces Core
2.2.9.

MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified by
JSR-344.

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

MyFaces Core 2.2.9 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under Group
ID "org.apache.myfaces.core".

Release Notes - MyFaces Core - Version 2.2.9

Bug

[MYFACES-3957] - Disabled h:commandLink results in rendering of a span
with onclick
[MYFACES-3978] - NullPointerException in FaceletStateValueExpression
when ViewPooling enabled
[MYFACES-3980] - c:forEach varStatus is assigned with the wrong base
[MYFACES-3981] - Unable to resolve Integer API as Lambda expression in
a facelet
[MYFACES-3982] - javax.faces.context.ExternalContext#getInitParameter
should throw NPE when name is null
[MYFACES-3983] - ViewScopeBinding does not work, results in an
exception when using a datatable
[MYFACES-3986] - viewScope implicit object not resolved in a JSP page
[MYFACES-3988] - An empty tag in a custom tag-lib causes an Exception
[MYFACES-3989] - MalformedURLException when
javax.faces.FACELETS_LIBRARIES contains line feed
[MYFACES-3992] - f:ajax doesn't append javax.faces.ViewState back on
re-render of form in stateless view
[MYFACES-3996] - Value of HTML-Attribute class on Passthrough element
is casted to java.lang.Class if coming from EL
[MYFACES-4000] - Some MyFaces JSF 2.2 API signatures do not match the
Java EE 7 API
[MYFACES-4003] - Allow the "class" Attribute To Be Set For Custom Tags
[MYFACES-4008] - AbstractMethodError thrown by
javax.servlet.http.Part.getSubmittedFileName()
[MYFACES-4010] - MyFaces 2.2 throws UnsupportedOperationException with
an eager ManagedBean with ManagedProperty
[MYFACES-4016] - Error when submitting an Ajax request for an element
without an ID
[MYFACES-4017] - custom expression factory not correctly loaded
[MYFACES-4019] - Updating a bound value not possible if input component
is within c:forEach

Improvement

[MYFACES-3063] - code cleanup and performance review
[MYFACES-3985] - [perf] avoid field initialization on CDI beans
[MYFACES-4001] - Outdated java.sun.com XML namespaces in 2.2 tagdoc
[MYFACES-4014] - Log required startup time
[MYFACES-4015] - [perf] provide annotation scanning via CDI extension

Task

[MYFACES-4005] - Classloading conflict with httpclient (update
commons-codec to 1.10)


regards,

Leonardo Uribe

[ANNOUNCE] MyFaces Core v2.2.8 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces
Core 2.2.8.

MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified
by JSR-344.

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

MyFaces Core 2.2.8 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under
Group ID org.apache.myfaces.core.

Release Notes - MyFaces Core - Version 2.2.8

Bug

[MYFACES-3233] - f:ajax event - type=javax.el.ValueExpression
(must evaluate to java.lang.String) not supported
[MYFACES-3947] - Passthrough Element textarea doesn't work
[MYFACES-3948] - Wrong check of facelets libraries last
modification time in FacesConfigurator
[MYFACES-3949] - javax.faces.ViewState autocomplete
[MYFACES-3951] - Action not performed on first click
[MYFACES-3956] - ResourceHandler.libraryExists(...) does not work
for resource library contracts
[MYFACES-3960] - AjaxBehaviorEvent should be queued before ActionEvent
[MYFACES-3964] - c:foreach not working when using custom equals or
non serializable objects
[MYFACES-3965] - SKIP_ITERATION visit hint not set when component
tree is visited during navigation
[MYFACES-3966] - Setting oamEnableViewPool=false causes
NullPointerException in ViewPoolProcessor.pushPartialView()
[MYFACES-3967] - View Pooling - ViewScope missing for Static Structure Views
[MYFACES-3969] - Flow initalizer called before inbound parameters are set
[MYFACES-3970] - 11.4.2.1 topic Each contract-mapping element
can have one or more contract elements.
[MYFACES-3973] - partial-response element does not contain an
id attribute
[MYFACES-3974] - Ajax delay attribute with a value of none does not work
[MYFACES-3975] - PreClearFlashEvent called on every JSF request
regardless of Flash use
[MYFACES-3976] - f:viewAction phase attribute reverts to INVOKE_APPLICATION
[MYFACES-3977] - 12.1.3 add this text to the
javax.faces.STATE_SAVING_METHOD spec. When examining the value, the
runtime must ignore the case.

Improvement

[MYFACES-3954] - [perf] Use ResourceLoaderCache for
ResourceHandler.libraryExists(...)


regards,

Leonardo Uribe

Re: EL 3.0 Static Field References

[Leonardo Uribe]

Hi

I think it is a bug in JSF 2.2 spec. The behavior for
ScopedAttributeELResolver (for facelets) is defined in section
5.6.2.9. To solve it (for 2.3) you should raise an issue on:

https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC

But I found this one already created on Mojarra issue tracker:

https://java.net/jira/browse/JAVASERVERFACES-3362

Please create an issue on the spec issue tracker. MyFaces already has
some params to control the EL Resolver ordering, so I suppose this
feature will help to fix the problem for 2.2.x. Besides that, we can't
do anything else from this side.

regards,

Leonardo Uribe

2015-03-27 9:19 GMT-05:00 William Lucy wtl...@us.ibm.com:

 Thanks for the response, Leonardo.

 From what I can tell, the issue isn't that MyFaces can't find the
 StaticFieldELResolver - that is loaded correctly.  JSP static field EL
 references do work properly through MyFaces, so there does seem to be some
 JSF issue.

 I think there may be a spec issue here?  (What I believe to be) a similar
 issue had to be addressed for JSP 2.3:
 https://bz.apache.org/bugzilla/show_bug.cgi?id=57141

 MyFaces has a resolver, ScopedAttributeResolver, which always sets the
 resolved field on the EvaluationContext to true if the EL expression's
 property isn't null.  The issue with that is when we're trying to resolve
 the EL expression base (eg. Boolean in the expression Boolean.TRUE) EL
 3.0 never has a chance to resolve the import the base ELClass, since it
 first runs through the EL Resolvers.

 My testing has shown that if we don't set context.setPropertyResolved(true)
 in the ScopedAttributeResolver, this particular case (#{Boolean.TRUE})
 works as expected.

 Any thoughts on this?  Let me know if I need to clarify anything.

 Regards,

 Bill Lucy


 Leonardo Uribe lu4...@gmail.com wrote on 03/25/2015 06:10:00 PM:

 From: Leonardo Uribe lu4...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org
 Date: 03/25/2015 06:11 PM
 Subject: Re: EL 3.0 Static Field References

 Hi

 It is in the spec, it should work.

 There is some code in
 org.apache.myfaces.el.unified.ResolverBuilderForFaces that deals with
 this:

 if (STATIC_FIELD_EL_RESOLVER_CLASS != null 
 GET_STREAM_EL_RESOLVER_METHOD != null)
 {
 try
 {
 ELResolver streamElResolver = (ELResolver)
 GET_STREAM_EL_RESOLVER_METHOD.invoke(
 getRuntimeConfig().getExpressionFactory());
 if (streamElResolver != null)
 {
 // By default return null, but in a EL 3
 implementation it should be there,
 // this is just to avoid exceptions in junit testing
 list.add(streamElResolver);
 }
 list.add((ELResolver)
 STATIC_FIELD_EL_RESOLVER_CLASS.newInstance());
 }

 The code checks for javax.el.StaticFieldELResolver class and
 ExpressionFactory.getStreamELResolver(...) method before
 add both EL resolvers.

 If MyFaces jars cannot locate these classes, the EL resolvers
 are not loaded (because it assumes EL  3.0), and the
 described behavior will happen.

 regards,

 Leonardo Uribe

 2015-03-25 15:14 GMT-05:00 William Lucy wtl...@us.ibm.com:
 
 
  Hi All,
 
  I'm running into some issues trying to test the EL 3.0 functionality on
  MyFaces 2.2.7 + Tomcat 8.0.16.  My understanding is that we should be
 able
  to reference static fields/methods directly from facelets, eg.
 
Boolean.TRUE test: [h:outputText id=out2
value=#{Boolean.TRUE}/]
 
  should return Boolean.TRUE test: [true].  This isn't the case,
 however;
  no value is returned, and nothing's logged.  Additionally, when I try
 to
  access a static field on a local ManagedBean, I get
 
...
javax.el.PropertyNotFoundException: Property 'staticReference'
 not
found on type beans.EL30StaticFieldsAndMethodsBean
   at javax.el.BeanELResolver$BeanProperties.get
   (BeanELResolver.java:244)
   at javax.el.BeanELResolver$BeanProperties.access$300
   (BeanELResolver.java:221)
   at javax.el.BeanELResolver.property(BeanELResolver.java:331)
   at javax.el.BeanELResolver.getValue(BeanELResolver.java:95)
   at javax.el.CompositeELResolver.getValue
   (CompositeELResolver.java:66)
   at
 
 org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue
  (FacesCompositeELResolver.java:179)
   ... 1 more
 
  Where the ManagedBean is defined simply as
 
package beans;
import javax.faces.bean.ApplicationScoped;
import javax.faces.bean.ManagedBean;
 
@ManagedBean(name = staticbean)
@ApplicationScoped
public class EL30StaticFieldsAndMethodsBean {
   ...
public static final String staticReference = static
 reference;
   ...
}
 
  Has anyone else tried working with these kinds of EL 3.0 features

Re: Issues using View Pooling - ViewScope is missing for static structure views?

[Leonardo Uribe]

Hi

I was able to reproduce the problem. Thanks for the log, it helped a
lot to understand what's going on. It looks like the call to
restoreState was overriding view scope, so the fix done was add some
lines to check that case and avoid it. I added some junit tests and on
the way I fixed a small issue with view root metadata facet.

I hope these fixes will solve your problem. Let us know if that is the
case or not.

regards,

Leonardo Uribe

2015-03-24 16:39 GMT-05:00 Chris Kulinski chriskulin...@yahoo.com:
 Leonardo - Thanks for the research and updated cases on the patch. We'll
 apply your recent changes to our testing and try again.

 Unfortunately, the additional fixes for this defect didn't fix our other
 defect with missing View Scope.  I'll create a new issue in the issue
 tracker to watch this. We'll work on assembling a simple demo that shows the
 problem.

 The issue might happen because the View Pooling code doesn't always run
 during RESTORE_VIEW phase.  It only seems to run in RESTORE_VIEW for AJAX
 post-backs.  Any changes to our ViewScope objects that happen before
 RENDER_RESPONSE are lost because it looks like the ViewScope is sometimes
 reattached at RENDER_RESPONSE.

 We've added manual debugging to the MyFaces source to attempt to show the
 problem.   Does this help enough to troubleshoot what's happening?

 On the very first request to the view after application startup, the
 behavior is correct. I guess this is because the View hasn't been flushed
 and remapped by the pool yet.  There is a second instance of the Bean
 created, but that's maybe after the view is rendered (in saveViewRootState,
 storeStatic and pushStaticStructureView).

 2015-03-24 16:48:23,235 DEBUG
 [com.autotrader.enterprise.common.context.LogPhaseListener] (default task-1)
 Start Phase RESTORE_VIEW(1)
 2015-03-24 16:48:23,374 DEBUG
 [com.autotrader.enterprise.common.context.LogPhaseListener] (default task-1)
 End Phase RESTORE_VIEW(1)
 2015-03-24 16:48:23,400 INFO  [stdout] (default task-1)
 HelloCdiTwoScopedBean - constructed new instance
 2015-03-24 16:48:23,406 DEBUG
 [com.autotrader.enterprise.common.context.LogPhaseListener] (default task-1)
 Start Phase RENDER_RESPONSE(6)
 2015-03-24 16:48:23,420 INFO  [stdout] (default task-1) POOLING:
 retrieveStaticStructureMetadata root:/examples/ajaxsamples/helloAjax.xhtml
 key:org.apache.myfaces.view.facelets.pool.impl.MetadataViewKeyImpl@f7711892
 2015-03-24 16:48:23,420 INFO  [stdout] (default task-1) POOLING:
 retrieveStaticStructureMetadata metadatanull
 2015-03-24 16:48:23,505 INFO  [stdout] (default task-1) POOLING
 root:/examples/ajaxsamples/helloAjax.xhtml dynamic:false
 2015-03-24 16:48:23,505 INFO  [stdout] (default task-1) POOLING:
 saveViewRootState root:/examples/ajaxsamples/helloAjax.xhtml
 2015-03-24 16:48:23,506 INFO  [stdout] (default task-1) POOLING: storeStatic
 root:/examples/ajaxsamples/helloAjax.xhtml
 keyorg.apache.myfaces.view.facelets.pool.impl.MetadataViewKeyImpl@f7711892
 2015-03-24 16:48:23,551 INFO  [stdout] (default task-1)
 HelloCdiTwoViewScopedBean - constructed new instance
 2015-03-24 16:48:23,681 INFO  [stdout] (default task-1) POOLING:
 pushStaticStructureView
 key:org.apache.myfaces.view.facelets.pool.impl.MetadataViewKeyImpl@f7711892
 entry:org.apache.myfaces.view.facelets.pool.impl.SoftViewEntry@27ed7f
 2015-03-24 16:48:23,683 DEBUG
 [com.autotrader.enterprise.common.context.LogPhaseListener] (default task-1)
 End Phase RENDER_RESPONSE(6)

 On the next request, Pooling isn't executed until during RENDER_RESPONSE.
 This bean is created after RESTORE_VIEW, but before RENDER_RESPONSE (via
 PrettyFaces).  The view is using a 2nd instance of the Bean for rendering,
 without the values from the initial instance (after popStaticStructureView).

 2015-03-24 17:18:51,090 DEBUG
 [com.autotrader.enterprise.common.context.LogPhaseListener] (default task-6)
 Start Phase RESTORE_VIEW(1)
 2015-03-24 17:18:51,091 DEBUG
 [com.autotrader.enterprise.common.context.LogPhaseListener] (default task-6)
 End Phase RESTORE_VIEW(1)
 2015-03-24 17:18:51,093 INFO  [stdout] (default task-6)
 HelloCdiTwoScopedBean - constructed new instance
 2015-03-24 17:18:51,094 DEBUG
 [com.autotrader.enterprise.common.context.LogPhaseListener] (default task-6)
 Start Phase RENDER_RESPONSE(6)
 2015-03-24 17:18:51,094 INFO  [stdout] (default task-6) POOLING:
 retrieveStaticStructureMetadata root:/examples/ajaxsamples/helloAjax.xhtml
 key:org.apache.myfaces.view.facelets.pool.impl.MetadataViewKeyImpl@f7711892
 2015-03-24 17:18:51,094 INFO  [stdout] (default task-6) POOLING:
 retrieveStaticStructureMetadata
 metadataorg.apache.myfaces.view.facelets.pool.impl.ViewStructureMetadataImpl@15744d1
 2015-03-24 17:18:51,094 INFO  [stdout] (default task-6) POOLING:
 popStaticStructureView
 key:org.apache.myfaces.view.facelets.pool.impl.MetadataViewKeyImpl@f7711892
 q:org.apache.myfaces.view.facelets.pool.impl.ViewPoolEntryHolder@672a58
 2015-03-24 17:18:51,098 INFO  [stdout] (default

Re: EL 3.0 Static Field References

[Leonardo Uribe]

Hi

It is in the spec, it should work.

There is some code in
org.apache.myfaces.el.unified.ResolverBuilderForFaces that deals with
this:

if (STATIC_FIELD_EL_RESOLVER_CLASS != null 
GET_STREAM_EL_RESOLVER_METHOD != null)
{
try
{
ELResolver streamElResolver = (ELResolver)
GET_STREAM_EL_RESOLVER_METHOD.invoke(
getRuntimeConfig().getExpressionFactory());
if (streamElResolver != null)
{
// By default return null, but in a EL 3
implementation it should be there,
// this is just to avoid exceptions in junit testing
list.add(streamElResolver);
}
list.add((ELResolver)
STATIC_FIELD_EL_RESOLVER_CLASS.newInstance());
}

The code checks for javax.el.StaticFieldELResolver class and
ExpressionFactory.getStreamELResolver(...) method before
add both EL resolvers.

If MyFaces jars cannot locate these classes, the EL resolvers
are not loaded (because it assumes EL  3.0), and the
described behavior will happen.

regards,

Leonardo Uribe

2015-03-25 15:14 GMT-05:00 William Lucy wtl...@us.ibm.com:


 Hi All,

 I'm running into some issues trying to test the EL 3.0 functionality on
 MyFaces 2.2.7 + Tomcat 8.0.16.  My understanding is that we should be able
 to reference static fields/methods directly from facelets, eg.

   Boolean.TRUE test: [h:outputText id=out2
   value=#{Boolean.TRUE}/]

 should return Boolean.TRUE test: [true].  This isn't the case, however;
 no value is returned, and nothing's logged.  Additionally, when I try to
 access a static field on a local ManagedBean, I get

   ...
   javax.el.PropertyNotFoundException: Property 'staticReference' not
   found on type beans.EL30StaticFieldsAndMethodsBean
  at javax.el.BeanELResolver$BeanProperties.get
  (BeanELResolver.java:244)
  at javax.el.BeanELResolver$BeanProperties.access$300
  (BeanELResolver.java:221)
  at javax.el.BeanELResolver.property(BeanELResolver.java:331)
  at javax.el.BeanELResolver.getValue(BeanELResolver.java:95)
  at javax.el.CompositeELResolver.getValue
  (CompositeELResolver.java:66)
  at
  
 org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue
 (FacesCompositeELResolver.java:179)
  ... 1 more

 Where the ManagedBean is defined simply as

   package beans;
   import javax.faces.bean.ApplicationScoped;
   import javax.faces.bean.ManagedBean;

   @ManagedBean(name = staticbean)
   @ApplicationScoped
   public class EL30StaticFieldsAndMethodsBean {
  ...
   public static final String staticReference = static reference;
  ...
   }

 Has anyone else tried working with these kinds of EL 3.0 features?  Or am I
 possibly just missing something here?

 Thanks,
 Bill Lucy

Re: Issues using View Pooling - ViewScope is missing for static structure views?

[Leonardo Uribe]

Hi

Thanks for your kind words about the view pooling algorithm :-).

It looks there are two issues here.

- Add null check on pushPartialView(...) : The solution is correct,
I'll commit it soon.

- View scope not restored correctly on static structure views : I have
not been able to reproduce the problem (it works for me with the
latest code, and I do not see a bug in the code). The algorithm used
to deal with static/partial and the algorithm for dynamic views has
some differences, so it should be something very specific that
activates the problem. If you can provide a simple demo that shows the
problem, that would be very helpful. The problem with these kind of
issues is they are usually really hard to debug, because reproduce
them can be very difficult. Anyway, please open a new issue on myfaces
issue tracker, so we can keep track on this.

regards,

Leonardo Uribe


2015-03-22 20:04 GMT-05:00 Chris Kulinski chriskulin...@yahoo.com.invalid:
 We're testing the View Pooling features of MyFaces 2.2.x on a large 
 pre-existing JSF site with very complex and heavy views with lots of 
 composite components.
 The performance improvement is frankly amazing - we've gone from GC events 
 every few seconds under heavy load to virtually no GC events at all...   
 Kudos to Leonardo for building in this feature!
 We've encountered one specific issue - a NullPointerException when using 
 oamEnableViewPool=false to disable pooling for specific views.  We've 
 created https://issues.apache.org/jira/browse/MYFACES-3966 for this issue.
 We needed to disable pooling for certain views because we noticed issues with 
 static structure views when using ViewScope.  Our ViewScope beans are 
 available in our controller code, but are no longer available during the 
 Render Response phase in our xhtml pages - via expression language lookups.
- On the very first request to the view (before its placed in the pool), 
 the state is applied correctly - but then every subsequent request to the 
 pooled view doesn't have the correct view state.

- It looks like the view state hasn't been correctly applied on the view 
 after its retrieved from the pool.
 Ways we've been able to work around this issue:
- If we disable view pooling for these views, then the beans are correctly 
 available in ViewScope.

- We don't see this issue on any of our dynamic structure views - in 
 fact, if we convert the static structure view to a dynamic structure view 
 (via an extra ui:include with EL, etc), then the view state is mapped 
 correctly and the viewscope beans are available. There must some pooling 
 state restore logic that's missing from static structure logic?

 Has anyone else seen this issue?  Or has anyone implemented view pooling with 
 static and dynamic structure views and view scope?
 Thanks!Chris Kulinski

[ANNOUNCE] MyFaces Core v2.0.23 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces
Core 2.0.23.

MyFaces Core is a JavaServer(tm) Faces 2.0 implementation as specified
by JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100%
compliant with the JSR-314 specification.

MyFaces Core 2.0.23 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under
Group ID org.apache.myfaces.core.

Release Notes - MyFaces Core - Version 2.0.23

Bug

[MYFACES-3930] - java.lang.IllegalArgumentException: null at
HtmlRenderKitImpl.createResponseWriter
[MYFACES-3931] - RelocatableResourceHandler tag + inner f:facet =
NullPointerException
[MYFACES-3935] - h:inputTextarea with null value throws NullPointerException
[MYFACES-3945] - _ClassByteCodeAnnotationFilter does not handle
SE8 .class files properly

regards,

Leonardo Uribe

[ANNOUNCE] MyFaces Core v2.1.17 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces
Core 2.1.17.

MyFaces Core is a JavaServer(tm) Faces 2.1 implementation as specified
by JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100%
compliant with the JSR-314 specification.

MyFaces Core 2.1.17 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under
Group ID org.apache.myfaces.core.

Release Notes - MyFaces Core - Version 2.1.17

Bug

[MYFACES-3928] - MyFaces doesn't resolve in OSGi environment when
Servlet API 3.1 is present
[MYFACES-3930] - java.lang.IllegalArgumentException: null at
HtmlRenderKitImpl.createResponseWriter
[MYFACES-3931] - RelocatableResourceHandler tag + inner f:facet =
NullPointerException
[MYFACES-3935] - h:inputTextarea with null value throws NullPointerException
[MYFACES-3941] - FaceletCacheImpl#isFaceletCached(URL) always returns false
[MYFACES-3945] - _ClassByteCodeAnnotationFilter does not handle
SE8 .class files properly

regards,

Leonardo Uribe

[ANNOUNCE] MyFaces Core v2.2.7 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces
Core 2.2.7.

MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified
by JSR-344.

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

MyFaces Core 2.2.7 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under
Group ID org.apache.myfaces.core.

Release Notes - MyFaces Core - Version 2.2.7

Bug

[MYFACES-3929] - Update org.apache.myfaces.CONFIG_REFRESH_PERIOD to JSF 2.2
[MYFACES-3940] - FlowScopeBeanHolder calls ApplicationContextBean
on PreDestroy
[MYFACES-3941] - FaceletCacheImpl#isFaceletCached(URL) always returns false
[MYFACES-3942] - f:viewParam binding causes NPE because UIViewRoot is null
[MYFACES-3944] - Calls to fcc.startComponentUniqueIdSection(...)
and fcc.endComponentUniqueIdSection(...) should be surrounded in a try
finally block
[MYFACES-3945] - _ClassByteCodeAnnotationFilter does not handle
SE8 .class files properly
[MYFACES-3946] - Ajax listener on JsfElement components not invoked

regards,

Leonardo Uribe

Re: javax.faces.ViewState autocomplete

[Leonardo Uribe]

Hi

Yes, it could be considered a bug. But it looks strange to set it on a
hidden field. Anyway, the argumentation is solid, so please create an
issue. It could be great if you can say in which browsers this
behavior happens.

regards,

Leonardo Uribe

2015-01-13 14:31 GMT-05:00 Werner Punz werner.p...@gmail.com:
 Am 09.01.15 um 11:58 schrieb Dan Østerberg:

 Hi,

 We have a JSF application where we mainly use ViewScoped beans, and add
 no-cache headers for all JSF pages. Navigating back to a previous page
 correctly recreates the beans, and renders new HTML, with a new ViewState
 ID. But... some browsers autocomplete some of the hidden ViewState inputs,
 overriding the new value with an old ViewState value. We have verified this
 in the browser dev-tools by looking at the response, which is correct, and
 the resulting HTML which is not.

 In short, this is a known autocomplete issue, which Mojarra has fixed
 since 1.2, by adding 'autocomplete=off' to the hidden ViewState input.
 Plus a context parameter com.sun.faces.autoCompleteOffOnViewState for
 opting not to use it, since it results in invalid XHTML. Adding
 'pa:autocomplete=off' explicitly to the whole form also fixes this issue.
 However, at least the MyFaces version that we use (2.2.4) doesn't add this
 attribute, and doesn't seem to have any corresponding configuration either.
 We also failed to google up alternatives/explanations for this issue
 explicitly in MyFaces. Naturally, we would like to avoid javascript hacks
 and custom components and renderers.

 So the question is - are we missing something? Or should MyFaces be
 patched to simply render 'autocomplete=off' for its hidden
 javax.faces.ViewState inputs?

 Thanx,
 Dan Østerberg

 Hi this looks like a bug to me, please file a bugreport in the MyFaces
 Bugtracker.
 https://issues.apache.org/jira/browse/myfaces


 Kind regards

 Werner Punz

Re: [Ljava.lang.Object; cannot be cast to javax.faces.component._DeltaList

[Leonardo Uribe]

Hi

There is a problem with the id generation, already fixed on:

https://issues.apache.org/jira/browse/MYFACES-3944

Probably this case is related too.

regards,

Leonardo Uribe

2014-11-30 10:10 GMT-05:00 Donatas Čiukšys donatas.ciuk...@mitsoft.lt:

 I‘m on TomEE 1.7.1, MyFaces 2.2.6, PrimeFaces 5.1.5. Log’s are currently
 exploding with the error messages like one at the bottom.

 The page /portal/legalAct is using templating; many ui:decorate that are
 using many ui:decorate again; often ui:decorate template is like this:



 ui:decorate
 template=/WEB-INF/templates/legalActSideALinkedDocuments.xhtml

 ui:param name=linkTypeCodeParam
 value=#{LinkTypeHolder.LINK_KEIČIANTIS_PAKEITIMAS_TYPE_CODE}/

 ui:param name=linkedDocumentsParam
 value=#{legalActController.keičiantisPakeitimasDocuments}/

 /ui:decorate



 legalActSideALinkedDocuments.xhtml:



 ui:composition …

 p:tab disabled=#{legalActController.linkedDocumentCount lt 0}

rendered=#{legalActController.linkedDocumentCount lt 0 or
 !empty linkedDocumentsParam}

 ...

 /p:tab

 /ui:composition



 That is, included (decorated actually) part might not be rendered at all.



 Only ui:composition and ui:decorate are used, no c:if (c namespace is not
 used at all), no ui:include, no ui:fragment. I think this is some corner
 case (bug actually).

 What should I look for (print for debugging) to help find the reason?



 ERROR 2014-11-30 16:52:12,343 # REQUEST ANALYSIS #: method: POST,
 requestURL:
 https://www.e-tar.lt/portal/legalAct.html?documentId=cdba6b00e56911e39ea8c7e1dfdc4b5c,
 JSF-PHASE: RESTORE_VIEW, AJAX: true, sessionId:
 C77CE1B76CD9A3435E444B6E243C1096.asHost1

 java.lang.IllegalStateException: Error restoring component:
 mainForm:accordionRight

at
 org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:832)
 ~[myfaces-impl-2.2.6.jar:2.2.6]

at
 org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:847)
 ~[myfaces-impl-2.2.6.jar:2.2.6]

at
 org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:847)
 ~[myfaces-impl-2.2.6.jar:2.2.6]

at
 org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:847)
 ~[myfaces-impl-2.2.6.jar:2.2.6]

at
 org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:847)
 ~[myfaces-impl-2.2.6.jar:2.2.6]

at
 org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:847)
 ~[myfaces-impl-2.2.6.jar:2.2.6]

at
 org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreStateFromMap(DefaultFaceletsStateManagementStrategy.java:847)
 ~[myfaces-impl-2.2.6.jar:2.2.6]

at
 org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.restoreView(DefaultFaceletsStateManagementStrategy.java:412)
 ~[myfaces-impl-2.2.6.jar:2.2.6]

at
 org.apache.myfaces.application.StateManagerImpl.restoreView(StateManagerImpl.java:133)
 ~[myfaces-impl-2.2.6.jar:2.2.6]

at
 org.apache.myfaces.shared.view.ViewDeclarationLanguageBase.restoreView(ViewDeclarationLanguageBase.java:104)
 ~[myfaces-impl-2.2.6.jar:2.2.6]

at
 org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.restoreView(FaceletViewDeclarationLanguage.java:2140)
 ~[myfaces-impl-2.2.6.jar:2.2.6]

at
 org.apache.myfaces.application.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:336)
 ~[myfaces-impl-2.2.6.jar:2.2.6]

at
 org.ocpsoft.rewrite.faces.RewriteViewHandler.restoreView(RewriteViewHandler.java:102)
 ~[rewrite-integration-faces-2.0.12.Final.jar:2.0.12.Final]

at
 javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper..java:82)
 ~[myfaces-api-2.2.6.jar:2.2.6]

at
 org.omnifaces.viewhandler.RestorableViewHandler.restoreView(RestorableViewHandler.java:66)
 ~[omnifaces-1.8.1.jar:1.8.1-20140603]

at
 javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper..java:82)
 ~[myfaces-api-2.2.6.jar:2.2.6]

at
 org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:170)
 ~[myfaces-impl-2.2.6.jar:2.2.6]

at
 org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:196

Re: Unexpected behaviour of duplicate id check algorithm

[Leonardo Uribe]

Hi

The only change that could cause like that between 2.1.x and 2.2.x is:

https://issues.apache.org/jira/browse/MYFACES-3811
Fix c:forEach behavior once for all

The previous algorithm (in 2.1.x) caused problems when you try
combinations of c:forEach and ui:include and other tags, so in that sense
the new algorithm is more stable. The new algorithm is activated when
c:forEach iterates over a Serializable collection, so one way to use the
old algorithm from 2.1.x is use a non Serializable collection.

The stack trace shows that you are doing something very unusual in
you page. The id shouln'd be that long:

j_id_r_v_e_m_2_4_1_1_14_9_3_1c_1_2_0_1_1_6_1_1_2_0_
1_2_2_1_2_0_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_
0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_
17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26 

It should be something that cause the id to be generated in that way,
maybe a hidden exception or something inside the iterated
components. I see that do the iteration by c:forEach should be
surrounded by a try{...} finally{...} block to avoid that situation.

I suggest you to check with a debugger how c:forEach is being
called. I have created this issue:

https://issues.apache.org/jira/browse/MYFACES-3944
- Calls to fcc.startComponentUniqueIdSection(...) and
fcc.endComponentUniqueIdSection(...) should be surrounded in a try
finally block

To deal with this, but that small fix will not solve the real cause
of the problem you have.

regards,

Leonardo Uribe

2014-11-24 4:15 GMT-05:00 Alexey Shakov alexey.sha...@menta.de:
 Hi,

 I have upgraded Myfaces version from 2.1.6 to 2.2.5 in my project and
 getting strange exception now, stating, that smth. wrong with ids on the
 page. Exception differs, depending on javax.faces.PARTIAL_STATE_SAVING
 parameter value.

 With javax.faces.PARTIAL_STATE_SAVING set to false:

 java.lang.IllegalStateException: Client-id :
 j_id_r_v_e_m_2_4_1_1_14_9_3_1c_1_2_0_1_1_6_1_1_2_0_1_2_2_1_2_0_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_1_1_1_6_1_1_2_0_0_1_0_2_1_1_6_2_1_1_2_4_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_48_0_49_0_50_0_51_0_52_0_53_0_54_0_55_0_56_0_57_0_58_0_59_0_60_0_61_0_62_0_63_0_64_0_65_0_66_0_67_0_68_0_69_0_70_0_71_0_72_0_73_0_74_0_75_0_76_0_77_0_78_0_79_0_80_0_81_0_82_0_83_0_84_0_85_0_86_0_87_0_88_0_89_0_90_0_91_0_92_0_93_0_94_0_95_0_96_0_97_0_98_0_99_0_100_0_101_0_102_0_103_0_104_0_105_0_106_0_107_0_108_0_109_0_110_0_111_0_112_0_113_0_114_0_115_0_116_0_117_0_118_0_119_0_120_0_121_0_122_0_123_0_124_0_125_0_126_0_127_0_128_0_129_0_130_0_131_0_132_0_133_0_134_0_135_0_136_0_137_0_138_0_139_0_140_0_141_0_142_0_143_0_144_0_145_0_146_0_147_0_148_0_149_0_150_0_151_0_152_0_153_0_154_0_155_0_156_0_157_0_158_0_159_0_160_0_161_0_162_0_163_0_164_0_165_0_166_0_167_0_168_0_169_0_170_0_171_0_172_0_173_0_174_0_175_0_176_0_177_0_178_0_179_0_180_0_181_0_182_0_183_0_184_0_185_0_186_0_187_0_188_0_189_0_2_1_1_6_1_1_2_0_1_1_6_2_1_1_2_0_4_1_1
 is duplicated in the faces tree. Component :
 j_id_r_v_e_m_2_4_1_1_14_9_3_1c_1_2_0_1_1_6_1_1_2_0_1_2_2_1_2_0_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_1_1_1_6_1_1_2_0_0_1_0_2_1_1_6_2_1_1_2_4_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_48_0_49_0_50_0_51_0_52_0_53_0_54_0_55_0_56_0_57_0_58_0_59_0_60_0_61_0_62_0_63_0_64_0_65_0_66_0_67_0_68_0_69_0_70_0_71_0_72_0_73_0_74_0_75_0_76_0_77_0_78_0_79_0_80_0_81_0_82_0_83_0_84_0_85_0_86_0_87_0_88_0_89_0_90_0_91_0_92_0_93_0_94_0_95_0_96_0_97_0_98_0_99_0_100_0_101_0_102_0_103_0_104_0_105_0_106_0_107_0_108_0_109_0_110_0_111_0_112_0_113_0_114_0_115_0_116_0_117_0_118_0_119_0_120_0_121_0_122_0_123_0_124_0_125_0_126_0_127_0_128_0_129_0_130_0_131_0_132_0_133_0_134_0_135_0_136_0_137_0_138_0_139_0_140_0_141_0_142_0_143_0_144_0_145_0_146_0_147_0_148_0_149_0_150_0_151_0_152_0_153_0_154_0_155_0_156_0_157_0_158_0_159_0_160_0_161_0_162_0_163_0_164_0_165_0_166_0_167_0_168_0_169_0_170_0_171_0_172_0_173_0_174_0_175_0_176_0_177_0_178_0_179_0_180_0_181_0_182_0_183_0_184_0_185_0_186_0_187_0_188_0_189_0_2_1_1_6_1_1_2_0_1_1_6_2_1_1_2_0_4_1_1,
 path: {Component-Path : [Class:
 org.apache.myfaces.extensions.validator.core.factory.ExtValViewRoot,ViewId:
 /pages/query/query_main.xhtml][Class:
 javax.faces.component.html.HtmlBody,Id: j_id_j][Class

Re: Unexpected behaviour of duplicate id check algorithm

[Leonardo Uribe]

Hi

I think I found the problem. In UserTagHandler there is a missing
call to fcc.endComponentUniqueIdSection(); . That means all
custom facelet tags will have the problem, but it will only be
found when you use nested combinations of custom facelet
tags and c:forEach tags. I'll fix it under MYFACES-3944

regards,

Leonardo Uribe

2014-11-24 14:41 GMT-05:00 Leonardo Uribe lu4...@gmail.com:
 Hi

 The only change that could cause like that between 2.1.x and 2.2.x is:

 https://issues.apache.org/jira/browse/MYFACES-3811
 Fix c:forEach behavior once for all

 The previous algorithm (in 2.1.x) caused problems when you try
 combinations of c:forEach and ui:include and other tags, so in that sense
 the new algorithm is more stable. The new algorithm is activated when
 c:forEach iterates over a Serializable collection, so one way to use the
 old algorithm from 2.1.x is use a non Serializable collection.

 The stack trace shows that you are doing something very unusual in
 you page. The id shouln'd be that long:

 j_id_r_v_e_m_2_4_1_1_14_9_3_1c_1_2_0_1_1_6_1_1_2_0_
 1_2_2_1_2_0_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_
 0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_
 17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26 

 It should be something that cause the id to be generated in that way,
 maybe a hidden exception or something inside the iterated
 components. I see that do the iteration by c:forEach should be
 surrounded by a try{...} finally{...} block to avoid that situation.

 I suggest you to check with a debugger how c:forEach is being
 called. I have created this issue:

 https://issues.apache.org/jira/browse/MYFACES-3944
 - Calls to fcc.startComponentUniqueIdSection(...) and
 fcc.endComponentUniqueIdSection(...) should be surrounded in a try
 finally block

 To deal with this, but that small fix will not solve the real cause
 of the problem you have.

 regards,

 Leonardo Uribe

 2014-11-24 4:15 GMT-05:00 Alexey Shakov alexey.sha...@menta.de:
 Hi,

 I have upgraded Myfaces version from 2.1.6 to 2.2.5 in my project and
 getting strange exception now, stating, that smth. wrong with ids on the
 page. Exception differs, depending on javax.faces.PARTIAL_STATE_SAVING
 parameter value.

 With javax.faces.PARTIAL_STATE_SAVING set to false:

 java.lang.IllegalStateException: Client-id :
 j_id_r_v_e_m_2_4_1_1_14_9_3_1c_1_2_0_1_1_6_1_1_2_0_1_2_2_1_2_0_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_1_1_1_6_1_1_2_0_0_1_0_2_1_1_6_2_1_1_2_4_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_48_0_49_0_50_0_51_0_52_0_53_0_54_0_55_0_56_0_57_0_58_0_59_0_60_0_61_0_62_0_63_0_64_0_65_0_66_0_67_0_68_0_69_0_70_0_71_0_72_0_73_0_74_0_75_0_76_0_77_0_78_0_79_0_80_0_81_0_82_0_83_0_84_0_85_0_86_0_87_0_88_0_89_0_90_0_91_0_92_0_93_0_94_0_95_0_96_0_97_0_98_0_99_0_100_0_101_0_102_0_103_0_104_0_105_0_106_0_107_0_108_0_109_0_110_0_111_0_112_0_113_0_114_0_115_0_116_0_117_0_118_0_119_0_120_0_121_0_122_0_123_0_124_0_125_0_126_0_127_0_128_0_129_0_130_0_131_0_132_0_133_0_134_0_135_0_136_0_137_0_138_0_139_0_140_0_141_0_142_0_143_0_144_0_145_0_146_0_147_0_148_0_149_0_150_0_151_0_152_0_153_0_154_0_155_0_156_0_157_0_158_0_159_0_160_0_161_0_162_0_163_0_164_0_165_0_166_0_167_0_168_0_169_0_170_0_171_0_172_0_173_0_174_0_175_0_176_0_177_0_178_0_179_0_180_0_181_0_182_0_183_0_184_0_185_0_186_0_187_0_188_0_189_0_2_1_1_6_1_1_2_0_1_1_6_2_1_1_2_0_4_1_1
 is duplicated in the faces tree. Component :
 j_id_r_v_e_m_2_4_1_1_14_9_3_1c_1_2_0_1_1_6_1_1_2_0_1_2_2_1_2_0_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_1_1_1_6_1_1_2_0_0_1_0_2_1_1_6_2_1_1_2_4_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_48_0_49_0_50_0_51_0_52_0_53_0_54_0_55_0_56_0_57_0_58_0_59_0_60_0_61_0_62_0_63_0_64_0_65_0_66_0_67_0_68_0_69_0_70_0_71_0_72_0_73_0_74_0_75_0_76_0_77_0_78_0_79_0_80_0_81_0_82_0_83_0_84_0_85_0_86_0_87_0_88_0_89_0_90_0_91_0_92_0_93_0_94_0_95_0_96_0_97_0_98_0_99_0_100_0_101_0_102_0_103_0_104_0_105_0_106_0_107_0_108_0_109_0_110_0_111_0_112_0_113_0_114_0_115_0_116_0_117_0_118_0_119_0_120_0_121_0_122_0_123_0_124_0_125_0_126_0_127_0_128_0

Re: Unexpected behaviour of duplicate id check algorithm

[Leonardo Uribe]

Hi

In 2.1.x the logic in UserTagHandler was a bit different, so the bug
is only in 2.2.x branch. I suppose it will solve the problem. I have
already committed the code on trunk.

regards,

Leonardo Uribe

2014-11-24 15:09 GMT-05:00 Leonardo Uribe lu4...@gmail.com:
 Hi

 I think I found the problem. In UserTagHandler there is a missing
 call to fcc.endComponentUniqueIdSection(); . That means all
 custom facelet tags will have the problem, but it will only be
 found when you use nested combinations of custom facelet
 tags and c:forEach tags. I'll fix it under MYFACES-3944

 regards,

 Leonardo Uribe

 2014-11-24 14:41 GMT-05:00 Leonardo Uribe lu4...@gmail.com:
 Hi

 The only change that could cause like that between 2.1.x and 2.2.x is:

 https://issues.apache.org/jira/browse/MYFACES-3811
 Fix c:forEach behavior once for all

 The previous algorithm (in 2.1.x) caused problems when you try
 combinations of c:forEach and ui:include and other tags, so in that sense
 the new algorithm is more stable. The new algorithm is activated when
 c:forEach iterates over a Serializable collection, so one way to use the
 old algorithm from 2.1.x is use a non Serializable collection.

 The stack trace shows that you are doing something very unusual in
 you page. The id shouln'd be that long:

 j_id_r_v_e_m_2_4_1_1_14_9_3_1c_1_2_0_1_1_6_1_1_2_0_
 1_2_2_1_2_0_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_
 0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_
 17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26 

 It should be something that cause the id to be generated in that way,
 maybe a hidden exception or something inside the iterated
 components. I see that do the iteration by c:forEach should be
 surrounded by a try{...} finally{...} block to avoid that situation.

 I suggest you to check with a debugger how c:forEach is being
 called. I have created this issue:

 https://issues.apache.org/jira/browse/MYFACES-3944
 - Calls to fcc.startComponentUniqueIdSection(...) and
 fcc.endComponentUniqueIdSection(...) should be surrounded in a try
 finally block

 To deal with this, but that small fix will not solve the real cause
 of the problem you have.

 regards,

 Leonardo Uribe

 2014-11-24 4:15 GMT-05:00 Alexey Shakov alexey.sha...@menta.de:
 Hi,

 I have upgraded Myfaces version from 2.1.6 to 2.2.5 in my project and
 getting strange exception now, stating, that smth. wrong with ids on the
 page. Exception differs, depending on javax.faces.PARTIAL_STATE_SAVING
 parameter value.

 With javax.faces.PARTIAL_STATE_SAVING set to false:

 java.lang.IllegalStateException: Client-id :
 j_id_r_v_e_m_2_4_1_1_14_9_3_1c_1_2_0_1_1_6_1_1_2_0_1_2_2_1_2_0_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_1_1_1_6_1_1_2_0_0_1_0_2_1_1_6_2_1_1_2_4_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_48_0_49_0_50_0_51_0_52_0_53_0_54_0_55_0_56_0_57_0_58_0_59_0_60_0_61_0_62_0_63_0_64_0_65_0_66_0_67_0_68_0_69_0_70_0_71_0_72_0_73_0_74_0_75_0_76_0_77_0_78_0_79_0_80_0_81_0_82_0_83_0_84_0_85_0_86_0_87_0_88_0_89_0_90_0_91_0_92_0_93_0_94_0_95_0_96_0_97_0_98_0_99_0_100_0_101_0_102_0_103_0_104_0_105_0_106_0_107_0_108_0_109_0_110_0_111_0_112_0_113_0_114_0_115_0_116_0_117_0_118_0_119_0_120_0_121_0_122_0_123_0_124_0_125_0_126_0_127_0_128_0_129_0_130_0_131_0_132_0_133_0_134_0_135_0_136_0_137_0_138_0_139_0_140_0_141_0_142_0_143_0_144_0_145_0_146_0_147_0_148_0_149_0_150_0_151_0_152_0_153_0_154_0_155_0_156_0_157_0_158_0_159_0_160_0_161_0_162_0_163_0_164_0_165_0_166_0_167_0_168_0_169_0_170_0_171_0_172_0_173_0_174_0_175_0_176_0_177_0_178_0_179_0_180_0_181_0_182_0_183_0_184_0_185_0_186_0_187_0_188_0_189_0_2_1_1_6_1_1_2_0_1_1_6_2_1_1_2_0_4_1_1
 is duplicated in the faces tree. Component :
 j_id_r_v_e_m_2_4_1_1_14_9_3_1c_1_2_0_1_1_6_1_1_2_0_1_2_2_1_2_0_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_1_1_1_6_1_1_2_0_0_1_0_2_1_1_6_2_1_1_2_4_4_2_1_2_1_1_0_0_1_0_2_0_3_0_4_0_5_0_6_0_7_0_8_0_9_0_10_0_11_0_12_0_13_0_14_0_15_0_16_0_17_0_18_0_19_0_20_0_21_0_22_0_23_0_24_0_25_0_26_0_27_0_28_0_29_0_30_0_31_0_32_0_33_0_34_0_35_0_36_0_37_0_38_0_39_0_40_0_41_0_42_0_43_0_44_0_45_0_46_0_47_0_48_0_49_0_50_0_51_0_52_0_53_0_54_0_55_0_56_0_57_0_58_0_59_0_60_0_61_0_62_0_63_0_64_0_65_0_66_0_67_0_68_0_69_0_70_0_71_0_72_0_73_0_74_0_75_0_76_0_77_0_78_0_79_0_80_0_81_0_82_0_83_

[ANNOUNCE] MyFaces Core v2.2.6 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces
Core 2.2.6.

MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified
by JSR-344.

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

MyFaces Core 2.2.6 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under
Group ID org.apache.myfaces.core.

Release Notes - MyFaces Core - Version 2.2.6

Bug

[MYFACES-3920] - HtmlPanelGroup implements ClientBehaviorHolder,
but does not render it's behaviors
[MYFACES-3923] - MyFaces uses Servlet 3.0 only method
cookie.setHttpOnly(true)
[MYFACES-3927] - Myfaces 2.2.4 not compatible with Google App Engine
[MYFACES-3928] - MyFaces doesn't resolve in OSGi environment when
Servlet API 3.1 is present
[MYFACES-3930] - java.lang.IllegalArgumentException: null at
HtmlRenderKitImpl.createResponseWriter
[MYFACES-3931] - RelocatableResourceHandler tag + inner f:facet =
NullPointerException
[MYFACES-3934] - f:view transient=true does not work on when
client side state saving is enabled and PSS is set to false
[MYFACES-3935] - h:inputTextarea with null value throws NullPointerException
[MYFACES-3936] - Flash object requires cleanup strategy when
client window feature is used

Improvement

[MYFACES-3937] - Set default for
org.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION to 4
[MYFACES-3938] - Faces Flow requires cleanup strategy

regards,

Leonardo Uribe

Re: ViewScoped bean created multiple times?

[Leonardo Uribe]

Hi

In my opinion, you should use @PostConstruct annotation over init method.

But the code has an entry like this:

@ManagedProperty(value=#{priceController})
private PriceController priceController;

Since this is inside a view scope bean, PriceController instance is saved
with
the view scope bean. It is a pitfall of JSF managed beans, solved in CDI
beans.

My suggestions is don't use @ManagedProperty inside the view scope bean
and instead use facesContext.getApplication().evaluateExpressionGet(...)
to get your beans, so you can always have the right instance without include
it into the state. The best strategy in my opinion is use request scope
beans
for encode behavior and view scope beans as data holders.

regards

Leonardo Uribe


2014-11-07 19:02 GMT-05:00 Thomas Andraschko andraschko.tho...@gmail.com:

 Constructor is called multiple times by design - thats how object
 serialization works.
 Serislization is enabled by default in myfaces to support
 clustering/failover.

 No clue about viewaction - i cant use jsf 2.2.

 Am Freitag, 7. November 2014 schrieb Bjørn T Johansen :

  2.2, like this.:
 
  faces-config xmlns=http://xmlns.jcp.org/xml/ns/javaee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://xmlns.jcp.org/xml/ns/javaee
  http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd;
  version=2.2
 
 
  No, javax.faces.PARTIAL_STATE_SAVING is set to true...
 
 
  BTJ
 
  On Fri, 7 Nov 2014 16:21:29 -0500
  Kito Mann kito.m...@virtua.com javascript:; wrote:
 
   OK. What version do you have in your faces-config.xml file? Also, do
 you
   have javax.faces.PARTIAL_STATE_SAVING set to false in web.xml?
  
   ___
  
   Kito D. Mann | @kito99 | Author, JSF in Action
   Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
  consulting
   http://www.JSFCentral.com | @jsfcentral
   +1 203-998-0403
  
   * Listen to the Enterprise Java Newscast: *http://
   http://blogs.jsfcentral.com/JSFNewscast/enterprisejavanews.com
   http://ww.enterprisejavanews.com*
   * JSFCentral Interviews Podcast:
   http://www.jsfcentral.com/resources/jsfcentralpodcasts/
   * Sign up for the JSFCentral Newsletter:
  http://oi.vresp.com/?fid=ac048d0e17
  
   On Fri, Nov 7, 2014 at 4:09 PM, Bjørn T Johansen b...@havleik.no
  javascript:; wrote:
  
No bindings...  And using Myfaces 2.2.5
   
BTJ
   
On Fri, 7 Nov 2014 15:57:00 -0500
Kito Mann kito.m...@virtua.com javascript:; wrote:
   
 Hello Bjorn,

 Do you have component bindings in your page (i.e h:myComponent
 binding=#{myBean.comp}/)? That causes the exact behavior you're
 describing in versions of JSF prior to 2.2. What version of MyFaces
  are
you
 using?

 ___

 Kito D. Mann | @kito99 | Author, JSF in Action
 Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
consulting
 http://www.JSFCentral.com | @jsfcentral
 +1 203-998-0403

 * Listen to the Enterprise Java Newscast: *http://
 http://blogs.jsfcentral.com/JSFNewscast/enterprisejavanews.com
 http://ww.enterprisejavanews.com*
 * JSFCentral Interviews Podcast:
 http://www.jsfcentral.com/resources/jsfcentralpodcasts/
 * Sign up for the JSFCentral Newsletter:
http://oi.vresp.com/?fid=ac048d0e17

 On Fri, Nov 7, 2014 at 3:42 PM, Bjørn T Johansen b...@havleik.no
  javascript:; wrote:

  I trying to create a webapplication using request and/or
 viewscope
instead
  of sessionscope, which I have always used... (Neved needed to
  concern
  myself with memory usage in the apps I have implemented.. :) )
  But I now have a problem using @ViewScoped..
  When I access index.xhtml which uses a managed bean in viewscope,
  the
  constructor is called multiple times. And the same with an init
method, that
  should be called only once. I am using..:
 
  f:metadata
  f:viewAction action=#{calendarController.initPrices} /
  /f:metadata
 
  h:head..
 
  to call the init method, but I have also tried using f:event
prerenderView
  and also @PostConstruct but I am not able to make the bean call
 the
init
  method only once...
 
  What am I missing?
 
 
  Regards,
 
  BTJ
  --
 
 
   
 
 ---
  Bjørn T Johansen
 
  b...@havleik.no javascript:;
 
 
   
 
 ---
  Someone wrote:
  I understand that if you play a Windows CD backwards you hear
  strange
  Satanic messages
  To which someone replied:
  It's even worse than that; play it forwards and it installs
  Windows
 
 
   
 
 ---
 
   
 
 

Re: Understanding page lifecycle on return from a faces flow

[Leonardo Uribe]

Hi

I think the problem happens because the navigation is executed on invoke
application case, but by default f:viewAction is set to be executed on
invoke application phase too. Probably f:viewAction is executed before the
navigation.

Faces Flow allows to set initializer and finalizer methods, so the best way
could be do the check in a finalizer method. Or if you want, you can use
f:event type=preRenderView listener=#{...}/, to execute a method
after invoke application phase, but before render.

regards,

Leonardo Uribe

2014-10-21 10:51 GMT-05:00 Alexander Wise sa...@clickshare.com:

 Greetings,
   I am trying to use a viewAction as a mechanism to enforce pre-conditions
 on pages, and am using faces flows to present any interaction required to
 enforce the preconditions. For example, imagine a “one click” ordering
 scheme, where clicking on a link takes you to the confirmation page for the
 order, but before the order can proceed, we need to make sure the customer
 is logged in (presenting a login/signup flow if they aren’t), and that they
 have a current credit card on file (presenting an update billing
 information flow if they aren’t)...

 I am entering the flow with a viewAction:

 f:viewAction action=#{authenticator.enter} onPostback=true /

 Authenticator.enter checks the pre-condition on the page, and navigates to
 the login flow, if the user is not logged in. But, at the end of the flow,
 I want enter() to be invoked again in case their are other preconditions
 that need to be enforced. A phase listener shows all the same phases are
 being executed, but the viewAction is not getting triggered again, so
 clearly, I don’t understand the page lifecycle sufficiently…

 Can anybody explain why the viewAction doesn’t get triggered again, and
 what I can do to change that?
 /s

Re: Myfaces Core - OSGi Bundle expand version range

[Leonardo Uribe]

Hi

The base code of MyFaces is in apache svn repo:

2.2.x
http://svn.apache.org/repos/asf/myfaces/core/trunk/

2.1.x
http://svn.apache.org/repos/asf/myfaces/core/branches/2.1.x/

2.0.x
http://svn.apache.org/repos/asf/myfaces/core/branches/2.0.x/

The fix you need should be done in bundle/pom.xml. It is quite simple, so I
have changed the issue to be solved for the next release.

regards,

Leonardo Uribe

2014-10-14 8:16 GMT-05:00 Achim Nierbeck bcanh...@googlemail.com:

 Hi,

 as working on different OSGi technologies I just came across the fact that
 the MyFaces Core bundle is not
 compatible in working with Servlet API 3.1, see also [1]
 I wanted to help on this so what's the best way of patching this. Looking
 at the github 2.1.x branch, the pom seems wrong to me (saying it's a
 2.2.0-SNAPSHOT) [2].

 So what's the best approach to actually file a quick patch for this?


 regards, Achim

 [1] - https://issues.apache.org/jira/browse/MYFACES-3928
 [2] - https://github.com/apache/myfaces/blob/2.1.x/pom.xml

 --

 Apache Member
 Apache Karaf http://karaf.apache.org/ Committer  PMC
 OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer 
 Project Lead
 blog http://notizblog.nierbeck.de/
 Co-Author of Apache Karaf Cookbook http://bit.ly/1ps9rkS

 Software Architect / Project Manager / Scrum Master

[ANNOUNCE] MyFaces Core v2.0.22 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces
Core 2.0.22.

MyFaces Core is a JavaServer(tm) Faces 2.0 implementation as specified
by JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100%
compliant with the JSR-314 specification.

MyFaces Core 2.0.22 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under
Group ID org.apache.myfaces.core.

Release Notes - MyFaces Core - Version 2.0.22

Bug

[MYFACES-3848] - FunctionMapper not found when using a function
inside value of f:setPropertyActionListener
[MYFACES-3875] - Unhandled attribute for for custom converter
[MYFACES-3883] - c:forEach with PSS enabled fails when add multiple rows
[MYFACES-3887] - UIDebug is alwas rendered=true (no
ValueExpression evaluation)
[MYFACES-3890] - Component added using vdl.createComponent(...) is
removed when javax.faces.FACELETS_REFRESH_PERIOD is not -1
[MYFACES-3902] - jsf.js: error handling output improvement
[MYFACES-3907] - NullPointerException in ManagedBeanBuilder after
server restart
[MYFACES-3913] - NPE in SwitchAjaxExceptionHandlerWrapperImpl
[MYFACES-3914] - HtmlScriptRenderer marks stylesheet as rendered
[MYFACES-3919] - javax.faces.SEPARATOR_CHAR Applied Incorrectly to
commandLink Hidden Field
[MYFACES-3921] - NullPointerException at SerializedViewCollection

Improvement

[MYFACES-3895] - Missed space character in ViewExpiredException getMessage()
[MYFACES-3906] - jsf.js: evaled javascript errors are not handled
the same way as other errors
[MYFACES-3918] - DefaultFaceletsStateManagementStrategy: keep list
of removed client IDs stable over time


regards,

Leonardo Uribe

[ANNOUNCE] MyFaces Core v2.1.16 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces
Core 2.1.16.

MyFaces Core is a JavaServer(tm) Faces 2.1 implementation as specified
by JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100%
compliant with the JSR-314 specification.

MyFaces Core 2.1.16 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under
Group ID org.apache.myfaces.core.

Release Notes - MyFaces Core - Version 2.1.16

Bug

[MYFACES-3841] - h:inputTextArea removes leading newline
[MYFACES-3848] - FunctionMapper not found when using a function
inside value of f:setPropertyActionListener
[MYFACES-3875] - Unhandled attribute for for custom converter
[MYFACES-3883] - c:forEach with PSS enabled fails when add multiple rows
[MYFACES-3887] - UIDebug is alwas rendered=true (no
ValueExpression evaluation)
[MYFACES-3888] - Resource from classpath locked on windows after
change in eclipse
[MYFACES-3890] - Component added using vdl.createComponent(...) is
removed when javax.faces.FACELETS_REFRESH_PERIOD is not -1
[MYFACES-3902] - jsf.js: error handling output improvement
[MYFACES-3907] - NullPointerException in ManagedBeanBuilder after
server restart
[MYFACES-3913] - NPE in SwitchAjaxExceptionHandlerWrapperImpl
[MYFACES-3914] - HtmlScriptRenderer marks stylesheet as rendered
[MYFACES-3919] - javax.faces.SEPARATOR_CHAR Applied Incorrectly to
commandLink Hidden Field
[MYFACES-3921] - NullPointerException at SerializedViewCollection

Improvement

[MYFACES-3895] - Missed space character in ViewExpiredException getMessage()
[MYFACES-3906] - jsf.js: evaled javascript errors are not handled
the same way as other errors
[MYFACES-3918] - DefaultFaceletsStateManagementStrategy: keep list
of removed client IDs stable over time

regards,

Leonardo Uribe

[ANNOUNCE] MyFaces Core v2.2.5 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces
Core 2.2.5.

MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified
by JSR-344.

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

MyFaces Core 2.2.5 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under
Group ID org.apache.myfaces.core.

Release Notes - MyFaces Core - Version 2.2.5

Bug

[MYFACES-3891] - Don't write flash-scoped variables in
ErrorPageWriter when FLASH_SCOPE_DISABLED=true
[MYFACES-3907] - NullPointerException in ManagedBeanBuilder after
server restart
[MYFACES-3912] - Exception when loading FlowScopeBeanHolder
[MYFACES-3913] - NPE in SwitchAjaxExceptionHandlerWrapperImpl
[MYFACES-3914] - HtmlScriptRenderer marks stylesheet as rendered
[MYFACES-3919] - javax.faces.SEPARATOR_CHAR Applied Incorrectly to
commandLink Hidden Field
[MYFACES-3920] - HtmlPanelGroup implements ClientBehaviorHolder,
but does not render it's behaviors
[MYFACES-3924] - Memory leak in ViewScopeBeanHolder

Improvement

[MYFACES-3895] - Missed space character in ViewExpiredException getMessage()
[MYFACES-3906] - jsf.js: evaled javascript errors are not handled
the same way as other errors
[MYFACES-3918] - DefaultFaceletsStateManagementStrategy: keep list
of removed client IDs stable over time

Wish

[MYFACES-3789] - Change default refresh period for facelets from 2
to 0 sec (=always refresh)
[MYFACES-3917] - Remove compile scope dependency - geronimo jcdi
spec 1.0 from myfaces-api maven build

regards,

Leonardo Uribe

Re: NPE in DefaultFaceletFactory._createViewMetadataFacelet from MyFaces 2.2.4 and Karaf 3.0.1

[Leonardo Uribe]

Hi

The line that throw the exception has this code:

String alias = / + _removeFirst(url.getFile(), getBaseUrl().getFile());

the base url is (/), so probably it is resolved as null. This reference
is taken through ResourceResolver, so a custom implementation could fix the
issue.

regards,

Leonardo Uribe


2014-09-06 4:44 GMT-05:00 Paul Spencer pau...@apache.org:

 The log entries below are from MyFaces 2.1.15 and 2.2.4, so is this a
 regression bug?

 ***
 * MyFaces 2.1.15
 ***
 2014-09-06 05:16:40,601 | TRACE | qtp195585050-76  |
 FaceletViewDeclarationLanguage   | 640 - org.apache.myfaces.core.impl -
 2.1.15 | Initializing
 2014-09-06 05:16:40,657 | DEBUG | qtp195585050-76  |
 FaceletViewDeclarationLanguage   | 640 - org.apache.myfaces.core.impl -
 2.1.15 | Successfully loaded library:
 bundle://632.0:1/META-INF/primefaces-p.taglib.xml
 2014-09-06 05:16:40,660 | DEBUG | qtp195585050-76  |
 FaceletViewDeclarationLanguage   | 640 - org.apache.myfaces.core.impl -
 2.1.15 | Successfully loaded library:
 bundle://632.0:1/META-INF/primefaces-pm.taglib.xml
 2014-09-06 05:16:40,663 | DEBUG | qtp195585050-76  | Resource
| 640 - org.apache.myfaces.core.impl - 2.1.15 | Resource-Url
 from external context: null
 2014-09-06 05:16:40,665 | DEBUG | qtp195585050-76  |
 DefaultFaceletFactory| 640 - org.apache.myfaces.core.impl -
 2.1.15 | Using ResourceResolver: DefaultResourceResolver
 2014-09-06 05:16:40,665 | DEBUG | qtp195585050-76  |
 DefaultFaceletFactory| 640 - org.apache.myfaces.core.impl -
 2.1.15 | Using Refresh Period: -1
 2014-09-06 05:16:40,666 | TRACE | qtp195585050-76  |
 FaceletViewDeclarationLanguage   | 640 - org.apache.myfaces.core.impl -
 2.1.15 | Initialization Successful
 2014-09-06 05:16:40,668 | DEBUG | qtp195585050-76  | Resource
| 640 - org.apache.myfaces.core.impl - 2.1.15 | Resource-Url
 from external context: bundle://636.3:0/helloWorld.xhtml
 2014-09-06 05:16:40,670 | DEBUG | qtp195585050-76  | Resource
| 640 - org.apache.myfaces.core.impl - 2.1.15 | Resource-Url
 from external context: bundle://636.3:0/helloWorld.xhtml
 2014-09-06 05:16:40,672 | DEBUG | qtp195585050-76  | Resource
| 640 - org.apache.myfaces.core.impl - 2.1.15 | Resource-Url
 from external context: bundle://636.3:0/helloWorld.xhtml
 2014-09-06 05:16:40,672 | DEBUG | qtp195585050-76  |
 DefaultFaceletFactory| 640 - org.apache.myfaces.core.impl -
 2.1.15 | Creating Facelet used to create View Metadata for:
 bundle://636.3:0/helloWorld.xhtml
 2014-09-06 05:16:40,672 | DEBUG | qtp195585050-76  | Compiler
| 640 - org.apache.myfaces.core.impl - 2.1.15 | Initializing
 2014-09-06 05:16:40,680 | DEBUG | qtp195585050-76  | Compiler
| 640 - org.apache.myfaces.core.impl - 2.1.15 | Initialization
 Successful
 2014-09-06 05:16:40,688 | DEBUG | qtp195585050-76  | CompilationManager
| 640 - org.apache.myfaces.core.impl - 2.1.15 | Namespace Pushed
 : http://www.w3.org/1999/xhtml
 2014-09-06 05:16:40,688 | DEBUG | qtp195585050-76  | CompilationManager
  | 640 - org.apache.myfaces.core.impl - 2.1.15 | Starting Unit:
 org.apache.myfaces.view.facelets.compiler.NamespaceUnit@4b9284dc and
 adding it to parent:
 org.apache.myfaces.view.facelets.compiler.CompilationUnit@50ae47
 2014-09-06 05:16:40,688 | DEBUG | qtp195585050-76  | CompilationManager
| 640 - org.apache.myfaces.core.impl - 2.1.15 | Namespace Pushed
 f: http://java.sun.com/jsf/core
 2014-09-06 05:16:40,688 | DEBUG | qtp195585050-76  | CompilationManager
  | 640 - org.apache.myfaces.core.impl - 2.1.15 | Namespace
 Pushed h: http://java.sun.com/jsf/html
 2014-09-06 05:16:40,688 | DEBUG | qtp195585050-76  | CompilationManager
  | 640 - org.apache.myfaces.core.impl - 2.1.15 | Namespace
 Pushed ui: http://java.sun.com/jsf/facelets
 2014-09-06 05:16:40,688 | DEBUG | qtp195585050-76  | CompilationManager
  | 640 - org.apache.myfaces.core.impl - 2.1.15 | Namespace
 Pushed p: http://primefaces.org/ui
 2014-09-06 05:16:40,690 | DEBUG | qtp195585050-76  | CompilationManager
  | 640 - org.apache.myfaces.core.impl - 2.1.15 | Tag Pushed:
 /viewMetadata/helloWorld.xhtml at line 12 and column 17 f:view
 2014-09-06 05:16:40,690 | DEBUG | qtp195585050-76  | CompilationManager
| 640 - org.apache.myfaces.core.impl - 2.1.15 | Starting Unit:
 /viewMetadata/helloWorld.xhtml at line 12 and column 17 f:view and adding
 it to parent:
 org.apache.myfaces.view.facelets.compiler.NamespaceUnit@4b9284dc
 2014-09-06 05:16:40,690 | DEBUG | qtp195585050-76  | CompilationManager
| 640 - org.apache.myfaces.core.impl - 2.1.15 | Finished Unit:
 /viewMetadata/helloWorld.xhtml at line 12 and column 17 f:view
 2014-09-06 05:16:40,690 | DEBUG | qtp195585050-76  | CompilationManager
| 640 - org.apache.myfaces.core.impl - 2.1.15 | Finished Unit:
 org.apache.myfaces.view.facelets.compiler.NamespaceUnit

Re: MyFaces 2.2.0 ViewScoped AmbiguousResolutionException

[Leonardo Uribe]

Hi

I have tested the latest snapshot from trunk and it is working with tomee
1.7.0. I don't see any exception from this side.

regards,

Leonardo Uribe


2014-09-03 17:23 GMT-05:00 José Luis Cetina maxtorz...@gmail.com:

 Hi, i was trying to use MyFaces 2.2.4 with TomEE 1.7.0 JAX-RS, i want to
 use myfaces 2.2.4 because i want to use the @javax.faces.view.ViewScoped (i
 use the omnifaces viewscoped) and the f:viewAction.

 But again im getting javax.enterprise.inject.AmbiguousResolutionException:
 Ambiguous resolution exception that i reported a few months ago, apparently
 myfaces 2.2.4 is not working with ears in tomee 1.7.0.

 I already reported to tomee mailing list but @Romain sayed

 think so but more a MF issue this time I think

 @Leonardo




 2014-01-15 17:14 GMT-06:00 Howard W. Smith, Jr. smithh032...@gmail.com:

  if you are not able to use MyFaces 2.2 @ViewScoped, you may need to keep
  OmniFaces CDI @ViewScoped until someone helps you with your issue.
 
  Some months ago, I tested MyFaces 2.2 with OmniFaces CDI @ViewScoped; all
  of my @ViewScoped beans were still OmniFaces CDI @ViewScoped, and I
  experienced no issues. My app is not packaged as an EAR.
 
  today, i am using MyFaces 2.2 @ViewScoped beans even though I still have
  OmniFAces 1.6.3 JAR/dependency (not using OmniFaces CDI @ViewScoped).
 
  For the first day, running MyFaces 2.2, I am quite pleased. No issues to
  report, no exceptions in tomee/tomcat log files.
 
 
 
  On Wed, Jan 15, 2014 at 5:57 PM, José Luis Cetina maxtorz...@gmail.com
  wrote:
 
   I removed CODI and my app is package as ear. maybe i need to try tomee
   1.6.1-snapshot
  
  
   2014/1/15 Howard W. Smith, Jr. smithh032...@gmail.com
  
On Wed, Jan 15, 2014 at 4:40 PM, José Luis Cetina 
  maxtorz...@gmail.com
wrote:
   
 I removed my faces 2.1.13 jars (api and imp) from tomee lib and add
myfaces
 api and impl 2.2.0

   
that's exactly what I did and I don't get the error.
   
Jose, are you still using MyFaces CODI (1.5 or 1.6.x) and EAR, too?
   
  
  
  
   --
   ---
   *SCJA. José Luis Cetina*
   ---
  
 



 --
 ---
 *José Luis Cetina*
 ---

Re: SERIALIZE_STATE_IN_SESSION - What does it do?

[Leonardo Uribe]

Hi

Check if your view scope managed beans implements Serializable interface.
When SERIALIZE_STATE_IN_SESSION, it forces serialization of all view scope
beans, and if you have not marked them as Serializable, the values will get
lost. In a cluster, it is possible to find configurations where a session
is serialized and deserialized, so SERIALIZE_STATE_IN_SESSION help with
that scenario, to avoid exceptions later when the session is deserialized.

regards,

Leonardo Uribe


2014-09-04 14:51 GMT-05:00 kim.cal...@oneamerica.com:

 We have a custom address tag that seems to behave differently based on
 whether SERIIALIZE_STATE_IN_SESSION is set to true or false.
 When it is set to true, the values entered by the user on the page never
 make it to the managed bean.   When it is set to false, the values
 entered do make it to the managed bean.   Any idea why changing the value
 of this parameter would impact the property being updated
 in the managed bean or not?   Our applications are running in a clustered
 environment, so we are thinking that SERIALIZE_STATE_IN_SESSION
 should be set to true so things will failover correctly.   Is that
 correct?

 Thanks




 This e-mail message is intended only for the use of the individual or
 entity to
 which the transmission is addressed. Any interception may be a violation of
 law. If you are not the intended recipient, any dissemination,
 distribution or
 copying of this e-mail is strictly prohibited. If you are not the intended
 recipient, please contact the sender by reply e-mail and destroy all
 copies of
 the document.

Re: MyFaces 2.2.0 ViewScoped AmbiguousResolutionException

[Leonardo Uribe]

As you already know, MyFaces provide some extensions and those extensions
register some CDI beans. But the way how the dependencies are loaded are
controlled by Tomee and by the CDI implementation, in this case OWB. I have
tried in the past to avoid the CDI beans in the integration point, but it
is not possible, you need one in order to hold the beans in the scope, and
you cannot access JSF from CDI (it works the opposite, access CDI from JSF).

regards,

Leonardo Uribe


2014-09-04 15:25 GMT-05:00 Romain Manni-Bucau rmannibu...@gmail.com:

 the issue is wars of an ear inherit from lib beans so mf shouldn't
 use it (can be done adding a bean with a generated name by webapp -
 and get the name from the servlet context for instance)

 on tomee side we can skip mf cdi beans in ear lib part if it can help


 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau


 2014-09-04 22:23 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
  @Leonardo: with ears?
 
 
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
  2014-09-04 22:12 GMT+02:00 Leonardo Uribe lu4...@gmail.com:
  Hi
 
  I have tested the latest snapshot from trunk and it is working with
 tomee
  1.7.0. I don't see any exception from this side.
 
  regards,
 
  Leonardo Uribe
 
 
  2014-09-03 17:23 GMT-05:00 José Luis Cetina maxtorz...@gmail.com:
 
  Hi, i was trying to use MyFaces 2.2.4 with TomEE 1.7.0 JAX-RS, i want
 to
  use myfaces 2.2.4 because i want to use the
 @javax.faces.view.ViewScoped (i
  use the omnifaces viewscoped) and the f:viewAction.
 
  But again im getting
 javax.enterprise.inject.AmbiguousResolutionException:
  Ambiguous resolution exception that i reported a few months ago,
 apparently
  myfaces 2.2.4 is not working with ears in tomee 1.7.0.
 
  I already reported to tomee mailing list but @Romain sayed
 
  think so but more a MF issue this time I think
 
  @Leonardo
 
 
 
 
  2014-01-15 17:14 GMT-06:00 Howard W. Smith, Jr. 
 smithh032...@gmail.com:
 
   if you are not able to use MyFaces 2.2 @ViewScoped, you may need to
 keep
   OmniFaces CDI @ViewScoped until someone helps you with your issue.
  
   Some months ago, I tested MyFaces 2.2 with OmniFaces CDI
 @ViewScoped; all
   of my @ViewScoped beans were still OmniFaces CDI @ViewScoped, and I
   experienced no issues. My app is not packaged as an EAR.
  
   today, i am using MyFaces 2.2 @ViewScoped beans even though I still
 have
   OmniFAces 1.6.3 JAR/dependency (not using OmniFaces CDI @ViewScoped).
  
   For the first day, running MyFaces 2.2, I am quite pleased. No
 issues to
   report, no exceptions in tomee/tomcat log files.
  
  
  
   On Wed, Jan 15, 2014 at 5:57 PM, José Luis Cetina 
 maxtorz...@gmail.com
   wrote:
  
I removed CODI and my app is package as ear. maybe i need to try
 tomee
1.6.1-snapshot
   
   
2014/1/15 Howard W. Smith, Jr. smithh032...@gmail.com
   
 On Wed, Jan 15, 2014 at 4:40 PM, José Luis Cetina 
   maxtorz...@gmail.com
 wrote:

  I removed my faces 2.1.13 jars (api and imp) from tomee lib
 and add
 myfaces
  api and impl 2.2.0
 

 that's exactly what I did and I don't get the error.

 Jose, are you still using MyFaces CODI (1.5 or 1.6.x) and EAR,
 too?

   
   
   
--
---
*SCJA. José Luis Cetina*
---
   
  
 
 
 
  --
  ---
  *José Luis Cetina*
  ---
 

Re: MyFaces 2.2.0 ViewScoped AmbiguousResolutionException

[Leonardo Uribe]

2014-09-04 16:04 GMT-05:00 Romain Manni-Bucau rmannibu...@gmail.com:

 but you can share in both something (common thing is the classloader)
 to match the bean (or name) you need.


I don't understand. MyFaces just provide the extension points. When and how
the extensions are called are up to CDI and maybe Tomee. I suppose the
AmbiguousResolutionException is caused because MyFaces is loaded twice by
Tomee (when it is using ear). Split that code in a separate jar will not
help.




 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau


 2014-09-04 22:38 GMT+02:00 Leonardo Uribe lu4...@gmail.com:
  As you already know, MyFaces provide some extensions and those extensions
  register some CDI beans. But the way how the dependencies are loaded are
  controlled by Tomee and by the CDI implementation, in this case OWB. I
 have
  tried in the past to avoid the CDI beans in the integration point, but it
  is not possible, you need one in order to hold the beans in the scope,
 and
  you cannot access JSF from CDI (it works the opposite, access CDI from
 JSF).
 
  regards,
 
  Leonardo Uribe
 
 
  2014-09-04 15:25 GMT-05:00 Romain Manni-Bucau rmannibu...@gmail.com:
 
  the issue is wars of an ear inherit from lib beans so mf shouldn't
  use it (can be done adding a bean with a generated name by webapp -
  and get the name from the servlet context for instance)
 
  on tomee side we can skip mf cdi beans in ear lib part if it can help
 
 
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
  2014-09-04 22:23 GMT+02:00 Romain Manni-Bucau rmannibu...@gmail.com:
   @Leonardo: with ears?
  
  
   Romain Manni-Bucau
   Twitter: @rmannibucau
   Blog: http://rmannibucau.wordpress.com/
   LinkedIn: http://fr.linkedin.com/in/rmannibucau
   Github: https://github.com/rmannibucau
  
  
   2014-09-04 22:12 GMT+02:00 Leonardo Uribe lu4...@gmail.com:
   Hi
  
   I have tested the latest snapshot from trunk and it is working with
  tomee
   1.7.0. I don't see any exception from this side.
  
   regards,
  
   Leonardo Uribe
  
  
   2014-09-03 17:23 GMT-05:00 José Luis Cetina maxtorz...@gmail.com:
  
   Hi, i was trying to use MyFaces 2.2.4 with TomEE 1.7.0 JAX-RS, i
 want
  to
   use myfaces 2.2.4 because i want to use the
  @javax.faces.view.ViewScoped (i
   use the omnifaces viewscoped) and the f:viewAction.
  
   But again im getting
  javax.enterprise.inject.AmbiguousResolutionException:
   Ambiguous resolution exception that i reported a few months ago,
  apparently
   myfaces 2.2.4 is not working with ears in tomee 1.7.0.
  
   I already reported to tomee mailing list but @Romain sayed
  
   think so but more a MF issue this time I think
  
   @Leonardo
  
  
  
  
   2014-01-15 17:14 GMT-06:00 Howard W. Smith, Jr. 
  smithh032...@gmail.com:
  
if you are not able to use MyFaces 2.2 @ViewScoped, you may need
 to
  keep
OmniFaces CDI @ViewScoped until someone helps you with your issue.
   
Some months ago, I tested MyFaces 2.2 with OmniFaces CDI
  @ViewScoped; all
of my @ViewScoped beans were still OmniFaces CDI @ViewScoped, and
 I
experienced no issues. My app is not packaged as an EAR.
   
today, i am using MyFaces 2.2 @ViewScoped beans even though I
 still
  have
OmniFAces 1.6.3 JAR/dependency (not using OmniFaces CDI
 @ViewScoped).
   
For the first day, running MyFaces 2.2, I am quite pleased. No
  issues to
report, no exceptions in tomee/tomcat log files.
   
   
   
On Wed, Jan 15, 2014 at 5:57 PM, José Luis Cetina 
  maxtorz...@gmail.com
wrote:
   
 I removed CODI and my app is package as ear. maybe i need to try
  tomee
 1.6.1-snapshot


 2014/1/15 Howard W. Smith, Jr. smithh032...@gmail.com

  On Wed, Jan 15, 2014 at 4:40 PM, José Luis Cetina 
maxtorz...@gmail.com
  wrote:
 
   I removed my faces 2.1.13 jars (api and imp) from tomee lib
  and add
  myfaces
   api and impl 2.2.0
  
 
  that's exactly what I did and I don't get the error.
 
  Jose, are you still using MyFaces CODI (1.5 or 1.6.x) and EAR,
  too?
 



 --

 ---
 *SCJA. José Luis Cetina*

 ---

   
  
  
  
   --
   ---
   *José Luis Cetina*
   ---
  
 

Re: SERIALIZE_STATE_IN_SESSION - What does it do?

[Leonardo Uribe]

Hi

2014-09-04 16:23 GMT-05:00 kim.cal...@oneamerica.com:

 Leonardo,

 Thanks for the response.  We don't have any view scoped managed beans. The
 bean is session scoped.
 It does implement Serializable. We recently migrated from MyFaces 1,1,4 to
 MyFaces 2.1.13.  This worked fine before, but isn't working
 now, if SERIALIZE_STATE_IN_SESSION is set to true.  We are still using
 JSPs, not Facelets.  I've stepped through the code several times and
 haven't
 discovered the issue yet.


Many things has happened since 1.1. JSP was deprecated in JSF 2.0 and the
suggested way is migrate JSP views into Facelets. Some component libraries
for JSF 2.0 deprecate JSP too. My suggestion is you could try first move
your application to MyFaces 1.2.12 (JSF 1.2) (change from JSF 1.1 EL to
Unified EL) and then convert your JSP views into Facelets and try 2.1.13.

regards,

Leonardo Uribe





 Kim Calvin
 Sr Systems Consultant - Web Solutions
 OneAmerica
 P.O. Box 368
 Indianapolis, IN 46206
 Phone: (317) 285-2401
 Fax:  (317) 285-7696
 kim.cal...@oneamerica.com

 OneAmerica companies:
 AUL | State Life | OneAmerica Securities |
 McCready and Keene | PML | AUL RMS



 From:   Leonardo Uribe lu4...@gmail.com
 To: MyFaces Discussion users@myfaces.apache.org,
 Date:   09/04/2014 04:19 PM
 Subject:Re: SERIALIZE_STATE_IN_SESSION - What does it do?



 Hi

 Check if your view scope managed beans implements Serializable interface.
 When SERIALIZE_STATE_IN_SESSION, it forces serialization of all view scope
 beans, and if you have not marked them as Serializable, the values will
 get
 lost. In a cluster, it is possible to find configurations where a session
 is serialized and deserialized, so SERIALIZE_STATE_IN_SESSION help with
 that scenario, to avoid exceptions later when the session is deserialized.

 regards,

 Leonardo Uribe


 2014-09-04 14:51 GMT-05:00 kim.cal...@oneamerica.com:

  We have a custom address tag that seems to behave differently based on
  whether SERIIALIZE_STATE_IN_SESSION is set to true or false.
  When it is set to true, the values entered by the user on the page never
  make it to the managed bean.   When it is set to false, the values
  entered do make it to the managed bean.   Any idea why changing the
 value
  of this parameter would impact the property being updated
  in the managed bean or not?   Our applications are running in a
 clustered
  environment, so we are thinking that SERIALIZE_STATE_IN_SESSION
  should be set to true so things will failover correctly.   Is that
  correct?
 
  Thanks
 
 
 
 
  This e-mail message is intended only for the use of the individual or
  entity to
  which the transmission is addressed. Any interception may be a violation
 of
  law. If you are not the intended recipient, any dissemination,
  distribution or
  copying of this e-mail is strictly prohibited. If you are not the
 intended
  recipient, please contact the sender by reply e-mail and destroy all
  copies of
  the document.


 __
 This email has been scanned by the Symantec Email Security.cloud service.
 For more information please visit http://www.symanteccloud.com
 __


 This e-mail message is intended only for the use of the individual or
 entity to
 which the transmission is addressed. Any interception may be a violation of
 law. If you are not the intended recipient, any dissemination,
 distribution or
 copying of this e-mail is strictly prohibited. If you are not the intended
 recipient, please contact the sender by reply e-mail and destroy all
 copies of
 the document.

Re: features.xml for MyFaces v2.2.x?

[Leonardo Uribe]

Hi

I think it doesn't exists, at least in the svn, but it is not hard to
create one.

regards,

Leonardo Uribe


2014-09-03 9:29 GMT-05:00 Paul Spencer pau...@apache.org:

 I am looking for a features.xml to easily install the MyFaces bundle and
 its dependent bundles into Karaf.  I looked in the MyFaces website, but
 only found the bundle.  Does such a file exist? If so, where?

 Paul Spencer

Re: Performance issue with component bindings and Ajax requests

[Leonardo Uribe]

Hi

I checked the algorithm and I have also fixed the problem (committed
in 2.0.x, 2.1.x and 2.2.x). See:

https://issues.apache.org/jira/browse/MYFACES-3918

I think the solution is ok, but an extra test could be also helpful.

regards,

Leonardo

2014-08-20 2:45 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr:
 On 20/08/2014 09:41, Marc Heinz wrote:

 Thanks for the quick answer!

 We tried disabling PSS but this actually broke several other things, so we
 would prefer not to touch it right now.

 Setting the flag org.apache.myfaces.REMOVING_COMPONENTS_BUILD however
 seems to do the trick... (we though about using it before but we were
 unsure about the possible implications).

 I've created an issue as suggested:
 https://issues.apache.org/jira/browse/MYFACES-3918

 I will report any possible regression we find there, and I will test again
 when a fix becomes available.

 I am also interesting by this issue and ready to test a fix in the days to
 come.

 Ludovic
 |
 | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
 |

Re: Issue with javax.faces.SEPARATOR_CHAR and commandLink

[Leonardo Uribe]

Hi

2014-08-20 6:36 GMT-05:00 William Lucy wtl...@us.ibm.com:


 Hello all,

 We've come across an issue while trying to modify the
 javax.faces.SEPARATOR_CHAR - changing it to a non-colon character seems to
 break h:commandLink actions.  For example, with the separator character set
 to a hyphen -, the following navigation does not work (the output link
 just triggers a refresh):

 f:view
 h:form
 h:commandLink id=link action=toLink.html
 h:outputText value=Link /
 /h:commandLink
 /h:form
 /f:view

 This can be observed in MyFaces 2.0.21, 2.1.15, and 2.2.4.  A workaround is
 to enable the context parameter
 org.apache.myfaces.RENDER_FORM_SUBMIT_SCRIPT_INLINE, however that parameter
 has been removed in the 2.2 branch.  (It's also not a particularly
 desirable workaround.)

Yes, that's the reason why we remove it. It was legacy stuff from 1.1/1.2 and
with 2.2 it is the right time to do a cleanup in the codebase.

  The issue here seems to stem from the oamSubmit.js
 script; in that file there is a call

 myfaces.oam.setHiddenInput(formName, formName + ':' + '_idcl', linkId);

 which explicitly passes uses a colon separator character.  In
 HtmlRendendererUtils.getHiddenCommandLinkFieldname, however, we have

 return formInfo.getFormName() + UINamingContainer.getSeparatorChar
 (FacesContext.getCurrentInstance())+ HIDDEN_COMMANDLINK_FIELD_NAME;

 which will cause the wrong hidden field name to be searched, and the broken
 actions seen here.

 Is this a bug, or just an accepted limitation of javax.faces.SEPARATOR_CHAR
 use?  Thanks for any feedback!


It is a bug. We should not use UINamingContainer.getSeparatorChar(...) to
render that hidden field and enforce ':' instead. The reason is the intention
of use javax.faces.SEPARATOR_CHAR is to avoid the collision with css
when you use the ':', but in this case the intention is to create a hidden
field, with no real underlying component, so it is better to let ':' on the js
file. Please create an issue in MyFaces issue tracker and I'll fix it on all
affected branches.

https://issues.apache.org/jira/browse/MYFACES

regards,

Leonardo Uribe

 Bill Lucy
 IBM RTP WebSphere
 wtl...@us.ibm.com

Re: Performance issue with component bindings and Ajax requests

[Leonardo Uribe]

Hi

The problem is the call to formRoot.getChildren().clear() activates
the listener for
PreRemoveFromViewEvent and that one register the removed components. Since
you are generating over and over components, after many requests that list
becomes big.

I can imagine two solutions:

1. Disable PSS on the affected views, using
javax.faces.FULL_STATE_SAVING_VIEW_IDS param

2. Try to use this code on formRoot.getChildren().clear();

facesContext.getAttributes.put(org.apache.myfaces.REMOVING_COMPONENTS_BUILD,
Boolean.TRUE);
formRoot.getChildren().clear();
facesContext.getAttributes.remove(org.apache.myfaces.REMOVING_COMPONENTS_BUILD);

That will avoid register the ids on the list, without side effects
(that I can imagine right now,
not 100% sure).

Anyway, It is possible to find a solution changing the code in
DefaultFaceletsStateManagementStrategy, so the list keeps stable over time,
Please create an issue on MyFaces issue tracker:

https://issues.apache.org/jira/browse/MYFACES

regards,

Leonardo Uribe

2014-08-19 8:12 GMT-05:00 Marc Heinz mhz4...@gmail.com:
 Hello everybody,

 We are currently encountering some performances issues with myfaces, and we
 would really appreciate some help on the subject.

 We are generating forms to be filled by the user dynamically (through
 component binding) from a set of externally managed rules. Here is a short
 overview:

 In our facelet:
 h:panelGroup id=formRoot binding=#{FormBean.formRoot}/

 Our backing bean:

 @RequestScoped
 public class FormBean {
  private boolean rebuildDone = false;
  private UIPanel formRoot;
  public UIPanel getFormRoot() {
   if (!rebuildDone) {
rebuildForm();
   }
   return formRoot;
  }
  public void setFormRoot(UIPanel formRoot) {
// Ignore.
  }
  // Public method to rebuild the current form content in reaction to
 updates fired from Ajax managed components.
  public void rebuildForm() {
   if (formRoot == null) {
 formRoot = new UIPanel();
 // The whole component tree is marked as transient.
 formRoot.setTransient(true);
 formRoot.setId(formRoot);
   }

   // Clear the existing tree.
   formRoot.getChildren().clear();

   // Start building the new component tree with formRoot as parent.
   [...]
  }
 }

 We use Ajax extensively: all updates events are processed with
 AjaxBehaviorsListeners (wired on onchange client events).

 When a change is processed (during the INVOKE_APPLICATION phase), the value
 is validated and the GUI is refreshed by calling the rebuildForm()
 method. The existing component tree will then be *cleared* by calling
 getChildren().clear() on the binding root component. It will be then
 rebuilt entirely (even though only a small subset of components are usually
 affected). This is clearly inefficient, but this is some legacy code that
 we don't want to disturb unless strictly required.

 What we observed (with MyFaces 2.1.12 and the 2.1.16 r1618150 in trunk): on
 all forms (but especially on forms with all lot of components) every Ajax
 request takes more time to complete than the previous one as long as we
 stay on the same view. On a form with ~70 fields, the turnaround time
 (measured with the Net panel of Firebug) goes from ~250ms (first request)
 to more than 1 second after ~15 update.

 After some profiling done with VisualVM, we pinpointed the location of the
 latency to:
 org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.handleDynamicAddedRemovedComponents(),
 accountable for  70% of the processing time. On further inspection, it
 appears that a data structure, the list of removed client IDs
 (clientIdsRemoved), is growing endlessly across each request.

 We are not too sure where the problem is right now... Should we build the
 component tree only once during the RESTORE_VIEW phase and then update it?
 (this seems hardly doable) Are we simply doing something in the wrong
 phase? Should I raise an issue on this?

 Any feedback would be most appreciated,

 Thanks,
 Marc

Re: dep error?

[Leonardo Uribe]

Hi

Instead use provided, these dependencies are optional:

!-- CDI 1.0 --
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-jcdi_1.0_spec/artifactId
version1.0/version
scopecompile/scope
optionaltrue/optional
/dependency

!-- Injection --
dependency
groupIdorg.apache.geronimo.specs/groupId
artifactIdgeronimo-atinject_1.0_spec/artifactId
version1.0/version
scopecompile/scope
optionaltrue/optional
/dependency

It is better to let it like that, because it is valid to use JSF 2.2
artifacts without CDI.

regards,

Leonardo Uribe

2014-08-04 16:00 GMT-05:00 Romain Manni-Bucau rmannibu...@gmail.com:
 Hi guys

 just to mention 2.2.4 has:

  40 [INFO] +- org.apache.myfaces.core:myfaces-api:jar:2.2.4:compile
  41 [INFO] |  +-
 org.apache.geronimo.specs:geronimo-jcdi_1.0_spec:jar:1.0:compile
  42 [INFO] |  \-
 org.apache.geronimo.specs:geronimo-atinject_1.0_spec:jar:1.0:compile

 Wouldn't it be better to set geronimo deps as provided?


 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau

Re: null Long values displayed as 0

[Leonardo Uribe]

Hi

All files from org.apache.el comes from the EL library, so it is out
of MyFaces scope. I think you cannot override the EL coercion rules,
unless you change the underlying EL library.

regards,

Leonardo

2014-07-16 12:20 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr:
 On 16/07/2014 19:15, titou10 titou10 wrote:

 Maybe you could try to add property
 org.apache.el.parser.COERCE_TO_ZERO=false to your JVM
 Denis/MTL

 No, COERCE_TO_ZERO is useful in the opposite way, when submitting the value.
 BTW, I already use it.

 Thx anyway.


 Ludovic
 |
 | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
 |

Re: Getting NPE when flowscope value evaluates to null.

[Leonardo Uribe]

Hi

I tried to set the null value with MyFaces 2.2.4 and it works as expected.

But trying with Mojarra 2.2.7 I get this:

javax.faces.component.UpdateModelException: java.lang.NullPointerException
at javax.faces.component.UIInput.updateModel(UIInput.java:866)
at javax.faces.component.UIInput.processUpdates(UIInput.java:749)
at javax.faces.component.UIForm.processUpdates(UIForm.java:281)

Caused by: java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1124)
at javax.el.MapELResolver.setValue(MapELResolver.java:265)
at 
com.sun.faces.el.DemuxCompositeELResolver._setValue(DemuxCompositeELResolver.java:255)
at 
com.sun.faces.el.DemuxCompositeELResolver.setValue(DemuxCompositeELResolver.java:281)
at com.sun.el.parser.AstValue.setValue(AstValue.java:201)
at com.sun.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:291)
at 
org.apache.webbeans.el22.WrappedValueExpression.setValue(WrappedValueExpression.java:95)
at 
com.sun.faces.facelets.el.TagValueExpression.setValue(TagValueExpression.java:131)
at javax.faces.component.UIInput.updateModel(UIInput.java:832)
... 34 more

Take a look your classpath, probably something is not right.

regards,

Leonardo

2014-07-03 23:08 GMT-05:00 Paul Spencer pau...@apache.org:
 MyFaces 2.2.3   2.2.4
 jetty-maven-plugin:8.1.15.v20140411

 Getting NPE when Flow Scope parameter evaluates to null.

 If no value is entered for firstName before “continue” on  
 campaigns/campaigns.xhtml is clicked, the NPE below thrown. Otherwise the 
 page2.xhtml is displayed as expected.

 ***
 * campaigns/campaigns.xhtml
 ***
 h:outputLabel for=firstName value=First Name /
 h:inputText id=firstName value=#{flowScope.firstName} 
 maxlength=10 /
 h:commandButton value=“Continue” action=“page2” /

 ***
 * campaigns/page2.xhtml
 ***
 h:commandButton value=“Exit action=campaigns-return /
 h:outputLabel for=firstName value=First Name /
 h:inputText id=“firstName value=#{flowScope.firstName} 
 maxlength=10 /

 ***
 * Error displayed when page2.xhtml is returned and firstName is null
 ***
 java.lang.NullPointerException

 viewId=/campaigns/campaigns.xhtml
 location=/Users/paul/Documents/workspace-4.3.2/VenderRollsImporterMockUp/src/main/webapp/campaigns/campaigns.xhtml
 phaseId=UPDATE_MODEL_VALUES(4)

 Caused by:
 java.lang.NullPointerException - java.lang.NullPointerException
 at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1124)
 HtmlInputText class=class javax.faces.component.html.HtmlInputText” 
 clientId=j_id_s:firstName disabled=false id=firstName 
 immediate=false inView=true localValueSet=true maxlength=10 
 readonly=false rendered=true required=false size=-2147483648 
 transient=false valid=false value=#{flowScope.firstName} 
 location=/campaigns/campaigns.xhtml at line 76 and column 82/ - State 
 size:246 bytes

 ***
 * Scopes Value
 ***
 Request Parameters
 Name  Value
 j_id_s:firstName
 j_id_s:j_id_x Continue
 j_id_s_SUBMIT 1
 jfwid -lbh0f813a


 Is this normal?

 Paul Spencer

[ANNOUNCE] MyFaces Core v2.2.4 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces
Core 2.2.4.

MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified
by JSR-344.

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

MyFaces Core 2.2.4 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under
Group ID org.apache.myfaces.core.

Release Notes - MyFaces Core - Version 2.2.4

Bug

[MYFACES-3841] - h:inputTextArea removes leading newline
[MYFACES-3848] - FunctionMapper not found when using a function
inside value of f:setPropertyActionListener
[MYFACES-3879] - Passthrough attributes for f:selectItem and
f:selectItems should be rendered by associated components
[MYFACES-3886] - SerializedViewCollection does not update it's
_keys list when _serializedViews contains key
[MYFACES-3887] - UIDebug is alwas rendered=true (no
ValueExpression evaluation)
[MYFACES-3888] - Resource from classpath locked on windows after
change in eclipse
[MYFACES-3890] - Component added using vdl.createComponent(...) is
removed when javax.faces.FACELETS_REFRESH_PERIOD is not -1
[MYFACES-3893] - NullPointerException in
ErrorPageWriter._writeAttributes [Line 1304]
[MYFACES-3902] - jsf.js: error handling output improvement

Improvement

[MYFACES-3639] - The flash scope cookie is not HttpOnly

New Feature

[MYFACES-3880] - Allow view state to be rendered in the beginning
of the form

regards,

Leonardo Uribe

Re: Content of ui:define variable not appearing in ui:include include fragment.

[Leonardo Uribe]

Hi

Use ui:decorate instead ui:include in the parts you need an ui:define
to be taken into account when the templates are resolved.

regards,

Leonardo Uribe

2014-07-01 9:29 GMT-05:00 Paul Spencer p...@intekon.com:
 Using MyFaces 2.2.3

 The intent is for the contents of the ui:define variable page_title to 
 appear both in the browser title bar and in the page’s content header area 
 while using a common template across many pages.  The content header area is 
 displayed in the body of the page and is there to give each page a 
 consistent look.

 In the example below, “My Page1 Title” appears as the title of the page1.jsp, 
 but not in the header content of the page.

 Why does the ui:define variable page_title evaluate to blank/null in 
 includes pages?

 Is there a better way to accomplish the intended behavior?


 ***
 * Page1.xhtml
 ***
 ?xml version=1.0 encoding=UTF-8 ?
 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN 
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
 html xmlns=http://www.w3.org/1999/xhtml;
 xmlns:f=http://java.sun.com/jsf/core;
 xmlns:h=http://java.sun.com/jsf/html;
 xmlns:ui=http://java.sun.com/jsf/facelets;
 h:body
 ui:composition template=/template/commonLayout.xhtml
 ui:define name=“page_title”My Page1 Title/ui:define
 ui:define name=“content
 f:view transient=“true”
   h1Page 1/h1
 /f:view
 /ui:define

 /ui:composition
 /h:body
 /html



 ***
 * commonLayout.xhtml
 ***
 ?xml version=1.0 encoding=UTF-8?
 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
 html xmlns=http://www.w3.org/1999/xhtml;
 xmlns:h=http://java.sun.com/jsf/html;
 xmlns:ui=http://java.sun.com/jsf/facelets;

 h:head
 meta http-equiv=Content-Type content=text/html; charset=UTF-8 /
 h:outputStylesheet library=css name=default.css /
 h:outputStylesheet library=css name=cssLayout.css /
 titleui:insert name=page_title //title
 /h:head

 h:body
 ui:debug /
 div id=page
 div id=top
 ui:insert name=header
 ui:include 
 src=/template/commonHeader.xhtml/
 /ui:insert
 /div
 div
 div id=left
 ui:insert name=menu
 ui:include 
 src=/template/commonMenuLeft.xhtml /
 /ui:insert
 /div

 div id=content
 ui:insert name=content
 ui:include 
 src=/template/commonContent.xhtml/
 /ui:insert
 /div
 ui:debug/ui:debug
 /div
 div id=bottom
 ui:insert name=footer
 ui:include 
 src=/template/commonFooter.xhtml /
 /ui:insert
 /div

 /div
 /h:body
 /html

 ***
 * commonHeader.xhtml
 ***
 ?xml version=1.0 encoding=UTF-8?
 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
 html xmlns=http://www.w3.org/1999/xhtml;
 xmlns:ui=http://java.sun.com/jsf/facelets;
 body
 ui:component
 h1 style=text-align: center; color: black; 
 background-color: white;
 ui:insert name=page_title /
 /h1
 /ui:component
 /body
 /html


 Paul Spencer

Re: caption facet not document in h:datatable.

[Leonardo Uribe]

Hi

It looks like UIData has getHeader()/getFooter(), but there is not
getCaption(), so there is no @JSFFacet. Yes, you can create an issue
as with priority trivial in:

https://issues.apache.org/jira/browse/MYFACES

regards,

Leonardo

2014-06-30 8:49 GMT-05:00 Paul Spencer pau...@apache.org:
 The caption facet is not document for the tag h:datatable.
   http://myfaces.apache.org/core22/myfaces-impl/tagdoc/h_dataTable.html

 Should I create an issue for this?

 Paul Spencer

[ANNOUNCE] MyFaces Test v1.0.7 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces
Test 1.0.7.

The Myfaces Test Framework provides mock object libraries, plus base
classes for creating your own JUnit TestCases for JSF.

For more information please see: http://myfaces.apache.org/test

MyFaces Core is available in the central Maven repository under Group
ID org.apache.myfaces.test.

Release Notes - MyFaces Test - Version 1.0.7

Improvement

[MYFACESTEST-70] - customizable ClassLoader

regards,

Leonardo Uribe

Re: NPE when view pooling / CACHE_EL_EXPRESSIONS == alwaysRecompile

[Leonardo Uribe]

Hi

I have checked the problem in deep and I was not able to reproduce the
problem. The reason is view pooling algorithm saves UIViewRoot state
fully (markInitialState is set to false, and the state is used later
to clone the views), and that also includes the binding table for
tags, so this table should be always saved and restored correctly.
Really it is not a problem if you set EL cache mode to strict, because
if you are using view pool in that view, enable or disable EL cache
will have minimal effect.

It should be some additional not seen element that is making it fail,
or in other words, it should be a combination between different
things, but it is impossible to understand it without an example.

regards,

Leonardo

2014-06-12 3:38 GMT-05:00 Leonardo Uribe lu4...@gmail.com:
 Hi

 An example to reproduce it could help in this case.

 Leonardo.

 On Jun 10, 2014 11:21 PM, l.pe...@senat.fr l.pe...@senat.fr wrote:

 (republished here following the advice of Gerhard Petracek on
 us...@deltaspike.apache.org)

 Dear all,

 I have the following NPE when view pooling is activated and
 CACHE_EL_EXPRESSIONS is set to alwaysRecompile :

 java.lang.NullPointerException at
 org.apache.myfaces.view.facelets.el.FaceletStateValueExpression.getValue(FaceletStateValueExpression.java:107)
 at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:68) at
 org.apache.el.parser.AstValue.getValue(AstValue.java:161) at
 org.apache.el.parser.AstEmpty.getValue(AstEmpty.java:47) at
 org.apache.el.parser.AstNot.getValue(AstNot.java:44) at
 org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:185) at
 org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression.getValue(ContextAwareTagValueExpression.java:96)
 at javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:377)
 at
 javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1211)
 at
 javax.faces.component.UIComponentBase._isPhaseExecutable(UIComponentBase.java:2440)
 at
 javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1386)
 at
 javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401)
 at
 javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401)
 at
 javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401)
 at
 javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401)
 at javax.faces.component.UIForm.processDecodes(UIForm.java:154) at
 javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401)
 at
 javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401)
 at
 javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401)
 at
 javax.faces.component.UIViewRoot._processDecodesDefault(UIViewRoot.java:1687)
 at javax.faces.component.UIViewRoot.access$500(UIViewRoot.java:77) at
 javax.faces.component.UIViewRoot$ApplyRequestValuesPhaseProcessor.process(UIViewRoot.java:1778)
 at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1653) at
 javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:869) at
 org.apache.myfaces.lifecycle.ApplyRequestValuesExecutor.execute(ApplyRequestValuesExecutor.java:42)
 at
 org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:196)
 at
 org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:143)
 at
 org.apache.deltaspike.jsf.impl.listener.request.DeltaSpikeLifecycleWrapper.execute(DeltaSpikeLifecycleWrapper.java:89)
 at javax.faces.lifecycle.LifecycleWrapper.execute(LifecycleWrapper.java:46)
 at javax.faces.webapp.FacesServlet.service(FacesServlet.java:198) at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at
 fr.senat.faces.filters.HibernateNoCacheFilter.doFilter(HibernateNoCacheFilter.java:123)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at
 fr.senat.faces.filters.HibernateSessionConversationFilter.doFilter(HibernateSessionConversationFilter.java:128)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at
 fr.senat.faces.filters.HibernateUserFromPrincipalFilter.doFilter(HibernateUserFromPrincipalFilter.java:43)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
 at
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at
 fr.senat.faces.filters.SessionCreationTrackingFilter.doFilter(SessionCreationTrackingFilter.java:48)
 at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243

Re: fileUpload native and with primefaces5 and with tomer

[Leonardo Uribe]

Hi

It was fixed in 2.2.2, please use 2.2.3 instead. See:

https://issues.apache.org/jira/browse/MYFACES-3865

regards,

Leonardo

2014-06-17 7:51 GMT-05:00 maurojava mauro2java2...@gmail.com:
 I have tried to use  primefaces5  fileUpload with configuratoins of native
  use of Part (no with commons ) into myfaces 2.2 .
 But not success.
 You know if the FacesServlet is annotated with @Multipart or i have
 configure with multipart into web.xml ?

 Please help me.
 I would als use myfaces2.2  into tomee 1.6 with substitution jars of myfaces
 api and myfaces ikplbtnto tomee/lib.

 Also into that case i have to confgure into web.xml  the faces servlet  with
 multpart config for use native Part with fileUplad of myfaces and for use
 fileUpload of primefaces5 with myfaces 2.2 and tomee ?



 --
 View this message in context: 
 http://myfaces.10567.n7.nabble.com/fileUpload-native-and-with-primefaces5-and-with-tomer-tp118244.html
 Sent from the MyFaces - Users mailing list archive at Nabble.com.

Re: NPE when view pooling / CACHE_EL_EXPRESSIONS == alwaysRecompile

[Leonardo Uribe]

Hi

An example to reproduce it could help in this case.

Leonardo.
On Jun 10, 2014 11:21 PM, l.pe...@senat.fr l.pe...@senat.fr wrote:

 (republished here following the advice of Gerhard Petracek on
 us...@deltaspike.apache.org)

 Dear all,

 I have the following NPE when view pooling is activated and
 CACHE_EL_EXPRESSIONS is set to alwaysRecompile :

 java.lang.NullPointerException at org.apache.myfaces.view.facelets.el.
 FaceletStateValueExpression.getValue(FaceletStateValueExpression.java:107)
 at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:68) at
 org.apache.el.parser.AstValue.getValue(AstValue.java:161) at
 org.apache.el.parser.AstEmpty.getValue(AstEmpty.java:47) at
 org.apache.el.parser.AstNot.getValue(AstNot.java:44) at org.apache.el.
 ValueExpressionImpl.getValue(ValueExpressionImpl.java:185) at
 org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression
 .getValue(ContextAwareTagValueExpression.java:96) at
 javax.faces.component._DeltaStateHelper.eval(_DeltaStateHelper.java:377)
 at javax.faces.component.UIComponentBase.isRendered(UIComponentBase.java:1211)
 at 
 javax.faces.component.UIComponentBase._isPhaseExecutable(UIComponentBase.java:2440)
 at 
 javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1386)
 at 
 javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401)
 at 
 javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401)
 at 
 javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401)
 at 
 javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401)
 at javax.faces.component.UIForm.processDecodes(UIForm.java:154) at
 javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401)
 at 
 javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401)
 at 
 javax.faces.component.UIComponentBase.processDecodes(UIComponentBase.java:1401)
 at 
 javax.faces.component.UIViewRoot._processDecodesDefault(UIViewRoot.java:1687)
 at javax.faces.component.UIViewRoot.access$500(UIViewRoot.java:77) at
 javax.faces.component.UIViewRoot$ApplyRequestValuesPhaseProcess
 or.process(UIViewRoot.java:1778) at javax.faces.component.
 UIViewRoot._process(UIViewRoot.java:1653) at javax.faces.component.
 UIViewRoot.processDecodes(UIViewRoot.java:869) at
 org.apache.myfaces.lifecycle.ApplyRequestValuesExecutor.execute(
 ApplyRequestValuesExecutor.java:42) at org.apache.myfaces.lifecycle.
 LifecycleImpl.executePhase(LifecycleImpl.java:196) at
 org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:143)
 at org.apache.deltaspike.jsf.impl.listener.request.
 DeltaSpikeLifecycleWrapper.execute(DeltaSpikeLifecycleWrapper.java:89) at
 javax.faces.lifecycle.LifecycleWrapper.execute(LifecycleWrapper.java:46)
 at javax.faces.webapp.FacesServlet.service(FacesServlet.java:198) at
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
 ApplicationFilterChain.java:305) at org.apache.catalina.core.
 ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at
 fr.senat.faces.filters.HibernateNoCacheFilter.doFilter(
 HibernateNoCacheFilter.java:123) at org.apache.catalina.core.
 ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(
 ApplicationFilterChain.java:210) at fr.senat.faces.filters.
 HibernateSessionConversationFilter.doFilter(HibernateSessionConversationFilter.java:128)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
 ApplicationFilterChain.java:243) at org.apache.catalina.core.
 ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at
 fr.senat.faces.filters.HibernateUserFromPrincipalFilter.doFilter(
 HibernateUserFromPrincipalFilter.java:43) at org.apache.catalina.core.
 ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(
 ApplicationFilterChain.java:210) at fr.senat.faces.filters.
 SessionCreationTrackingFilter.doFilter(SessionCreationTrackingFilter.java:48)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
 ApplicationFilterChain.java:243) at org.apache.catalina.core.
 ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
 at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
 at 
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:581)
 at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
 at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
 at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:947)
 at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
 at 

RE: Declaring a node that is not type 'view' as the start node.

[Leonardo Uribe]

Hi

It looks like if register bean was in the flow scope associated with the
flow to evaluate. The lookup will fail, because when the start node outcome
is calculated, you have not entered the flow yet. The algorithm works in 2
steps: calculate the final outcome and then perform the transitions. I
don't see any problem, because it is expected to fail in that scenario.

Leonardo
On Jun 10, 2014 1:01 PM, Mark m...@piggybankrupt.co.uk wrote:

 Hi,

 Can anyone confirm if this is a problem with the myfaces implementation?

 Regards,

 Mark.


 -Original Message-
 From: Mark [mailto:m...@piggybankrupt.co.uk]
 Sent: 19 May 2014 22:22
 To: users@myfaces.apache.org
 Subject: Declaring a node that is not type 'view' as the start node.

 Declaring a node that is not type 'view' as the start node.



 Upon using flows within myfaces I can successfully enter and move within
 the
 flow provided the start node is a 'view' type.

 However, upon using a 'method-call' type or a 'switch' type I receive the
 errors below. My intention is to use a method-type node as a start-node to

 determine the first page in the flow, which is returned as an outcome. I
 found https://java.net/jira/browse/JAVASERVERFACES-3110, which  presents
 the
 same problem in jsf.





 ##using method-call##

 java.lang.NullPointerException



 viewId=/index.xhtml


 location=C:\Users\Mark\Documents\Dev\login\ui\target\login-1.0-SNAPSHOT\inde
 x.xhtml

 phaseId=INVOKE_APPLICATION(5)



 Caused by:

 java.lang.NullPointerException

 at

 javax.faces.application.NavigationCaseWrapper.isRedirect(NavigationCaseWrapp
 er.java:111)

 HtmlCommandButton action=registration actionExpression=registration
 class=class javax.faces.component.html.HtmlCommandButton
 clientId=j_id_f:j_id_n disabled=false id=j_id_n immediate=false
 inView=true readonly=false rendered=true transient=false
 type=submit value=submit location=/index.xhtml at line 26 and column
 71/ - State size:0 bytes



 ##using switch##

 WebBeans context with scope type annotation @FlowScoped does not exist
 within current thread



 viewId=/index.xhtml


 location=C:\Users\Mark\Documents\Dev\login\ui\target\login-1.0-SNAPSHOT\inde
 x.xhtml

 phaseId=INVOKE_APPLICATION(5)



 Caused by:

 javax.enterprise.context.ContextNotActiveException - WebBeans context with
 scope type annotation @FlowScoped does not exist within current thread

 at

 org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.jav
 a:299)HtmlCommandButton action=registration
 actionExpression=registration class=class
 javax.faces.component.html.HtmlCommandButton clientId=j_id_f:j_id_n
 disabled=false id=j_id_n immediate=false inView=true
 readonly=false rendered=true transient=false type=submit
 value=submit location=/index.xhtml at line 26 and column 71/ - State
 size:0 bytes



 ##setup -flow.xml##

 faces-config version=2.2 xmlns=http://xmlns.jcp.org/xml/ns/javaee;

   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;

   xsi:schemaLocation=http://xmlns.jcp.org/xml/ns/javaee
 http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd;



 flow-definition id=registration



 start-nodestartIt/start-node

 !--switch id=startIt

 case

 if#{register.startPage()==register}/if

 from-outcomeregister/from-outcome

 /case

 case/case

 default-outcomewelcomePage/default-outcome

 /switch--



 method-call

 method id=startIt#{register.startPage()}/method

default-outcomeregister/default-outcome

 /method-call





 view id=register

 vdl-document/registration/welcome.xhtml/vdl-document

 /view



 view id=welcomePage

 vdl-document/registration/registration1.xhtml/vdl-document

 /view



 flow-return id=return-index

 from-outcome/index.xhtml/from-outcome

 /flow-return

 /flow-definition

 /faces-config



 ##environment##

 Tommee+ 1.6

 myfaces-api-2.2.2  myfaces-impl-2.2.2 replacing the tomee shipped 2.1.3



 Any ideas?



 Regards,





 Mark Davis



 This email and any associated file contains confidential information and is
 intended solely for the person(s) named. If you are not the intended
 recipient, please do not read, print, store, disclose, re-distribute or act
 upon any information contained. Instead, please return to the sender and
 delete the message and / or files from your PC.

Re: Tag component instantiation and EL strict or alwaysRecompile modes

[Leonardo Uribe]

Hi Ludovic

Good to know that. In my understanding, that code is the best option so
far, and a lot of effort has been done to make it work. It was really hard
to get it done. It has some good junit tests in place. Anyway we need to
convince to the EG that myfaces behavior is the way to go. I think there is
an issue already created on the spec, but I can't remember which number is.

Regards

Leonardo
On Jun 10, 2014 10:55 AM, l.pe...@senat.fr l.pe...@senat.fr wrote:

 On 05/06/2014 07:27, Leonardo Uribe wrote:

 Hi

 Use the standard vdl.createComponent(...) included since JSF 2.2. It has
 the necessary code to do the trick properly. Please note in Myfaces this
 method has been extend to support facelet tags too. It should work with
 the
 view pool.

 Thank you Leonardo.

 I updated my code to use this method and it perfectly works. I could
 remove those naughty introspections, and that is always a long term bless.

 Best regards,

 Ludovic
 |
 | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
 |

Re: Submit form after disabling an input element via javascript?

[Leonardo Uribe]

Hi

This is something complicated. If you disable a link on the server, you
don't want a javascript that enable it on the client side, submit it and
then found that something that you don't expect has happended on the
server, right?. Who manage disable attribute? The client or the server?
If an action is performed on the server, the server manage the attribute,
so an Ajax request is mandatory to enable the input. Otherwise it could be
a security hole. The thing to remember here is never trust on the client.
No matter how intelligent we want the client to be, in cases like this one
the state on the server is the king, and that will not change (because we
can't!).

Regards,

Leonardo
On Jun 10, 2014 10:06 PM, Karl Kildén karl.kil...@gmail.com wrote:

 Howard, thanks for the links and interest.

 In my case I already rewrote all my pages but I still think that error
 message is wrong.

 This is our use case:

 [X] Use Defaults for everything

 Once the user unclicks that checkbox 5 inputs are editable otherwise they
 get default. Since they get default I obviously just want JSF to leave me
 alone and you know behave like they are disabled ;)

 That way String fileName =newFile.txt; will not be changed and everything
 is smooth.

 What I see others complain about is that they have updated the value and
 then disabled yet still want it posted. This is a fundamental
 misunderstanding of how disabled works and differs from my scenario.

 In my case there was no reason to do it with javascript though and I did
 not like the solution in place so I fixed it by using f:ajax and
 disabled=#{condition} but had it been a central part of my system I would
 have been more hesitant to use the server side for such a simple operation.



 On 10 June 2014 21:51, Howard W. Smith, Jr. smithh032...@gmail.com
 wrote:

  Leonardo, what are your thoughts on this thread? thanks.
 
 
 
  On Wed, Jun 4, 2014 at 11:43 AM, Karl Kildén karl.kil...@gmail.com
  wrote:
 
   Howard,
  
   To do that one would need a purpose. I fail to see the benefit other
 than
   bending the knee to a JSF limitation.
  
  
  
  
   On 4 June 2014 16:48, Howard W. Smith, Jr. smithh032...@gmail.com
  wrote:
  
Karl, if Javascript was written to enable field, why is there not
Javascript to disable before submit?
On Jun 4, 2014 8:33 AM, Karl Kildén karl.kil...@gmail.com wrote:
   
 Hi,

 my app recently upgraded from JSF 1.2 had a broken page with this
 in
   the
 log:

 WARNING: There should always be a submitted value for an input if
 it
  is
 rendered, its form is submitted, and it was not originally rendered
 disabled or read-only.  You cannot submit a form after disab
 ling an input element via javascript.  Consider setting read-only
 to
   true
 instead or resetting the disabled value back to false prior to form
 submission. Component : {Component-Path : [Class: javax.fa
 ces.component.UIViewRoot,ViewId: /pages/main.xhtml][Class:
 javax.faces.component.html.HtmlBody,Id: j_id_10][Class:
 javax.faces.component.html.HtmlForm,Id: f][Class:
 javax.faces.component.html.HtmlPane
 lGroup,Id: body][Class:
 javax.faces.component.html.HtmlPanelGroup,Id:
 contentBody][Class: javax.faces.component.html.HtmlPanelGrid,Id:
 j_id_2b_p][Class: javax.faces.component.html.HtmlInputText,Id: im
 portName] Location: /WEB-INF/facelets/admin/profileUploadForm.xhtml
  at
line
 88 and column 73}


 I don't understand this limitation. Is there some global flag I
 could
   use
 to make sure not included inputs are seen as unchanged or
 something?

 cheers

   
  
 

Re: Tag component instantiation and EL strict or alwaysRecompile modes

[Leonardo Uribe]

Hi

Use the standard vdl.createComponent(...) included since JSF 2.2. It has
the necessary code to do the trick properly. Please note in Myfaces this
method has been extend to support facelet tags too. It should work with the
view pool.

regards

Leonardo Uribe
On Jun 4, 2014 12:37 PM, l.pe...@senat.fr l.pe...@senat.fr wrote:

 Dear all,

 I am doing something dirty in my code. I dynamically instantiate and add
 tag components to my component tree, according to some information that I
 have at runtime.

 My instantiation method looks like :

 public static UIComponent instantiateTagComponent(Location loc,
 String namespace, String localPrefix, String componentName,
 TagComponentParam params[]) {
 final String ERROR_MESSAGE = Erreur lors de l'instanciation d'un
 tag component;
 FacesContext ctx = FacesContext.getCurrentInstance();
 AbstractFaceletContext fctx = (AbstractFaceletContext)
 ctx.getAttributes().get(FaceletContext.FACELET_CONTEXT_KEY);
 fctx.pushPageContext(new PageContextImpl());

 FaceletViewDeclarationLanguage vdl = new
 FaceletViewDeclarationLanguage(ctx);

 UIPanel panel = (UIPanel) ctx.getApplication().createComponent(
 UIPanel.COMPONENT_TYPE );

 try {
 Method createCompiler = FaceletViewDeclarationLanguage
 .class.getDeclaredMethod(createCompiler,FacesContext.class);
 Method createFaceletFactory = FaceletViewDeclarationLanguage
 .class.getDeclaredMethod(createFaceletFactory,
 FacesContext.class,org.apache.myfaces.view.facelets.
 compiler.Compiler.class);
 createCompiler.setAccessible(true);
 createFaceletFactory.setAccessible(true);
 org.apache.myfaces.view.facelets.compiler.Compiler compiler =
 (org.apache.myfaces.view.facelets.compiler.Compiler)
 createCompiler.invoke(vdl, ctx);
 FaceletFactory ff = (FaceletFactory)
 createFaceletFactory.invoke(vdl, ctx, compiler);
 TagLibrary tl = compiler.createTagLibrary();
 TagConfig tc = new JSFUtilsTagUnit(tl, namespace, localPrefix,
 componentName,params,loc);
 TagHandler th = tl.createTagHandler(namespace, componentName,
 tc);
 Field declaredField = FaceletCompositionContext.
 class.getDeclaredField(FACELET_COMPOSITION_CONTEXT_KEY);
 declaredField.setAccessible(true);
 FaceletCompositionContextImpl faceletCompositionContextImpl =
 new FaceletCompositionContextImpl(ff,ctx);
 Class? dfcClass = Class.forName(org.apache.
 myfaces.view.facelets.impl.DefaultFaceletContext);
 Field fMCTX = dfcClass.getDeclaredField(_mctx);
 fMCTX.setAccessible(true);
 fMCTX.set(fctx, faceletCompositionContextImpl);
 FacesContext.getCurrentInstance().getAttributes().put((String)
 declaredField.get(null),faceletCompositionContextImpl);
 FaceletCompositionContext mctx = (FaceletCompositionContext)
 FaceletCompositionContext.getCurrentInstance(fctx);
 mctx.startComponentUniqueIdSection();
 th.apply( fctx, panel );
 } catch (IOException ex) {
 log.error(ERROR_MESSAGE, ex);
 } catch (InvocationTargetException ex) {
 log.error(ERROR_MESSAGE, ex);
 } catch (NoSuchMethodException ex) {
 log.error(ERROR_MESSAGE, ex);
 } catch (NoSuchFieldException ex) {
 log.error(ERROR_MESSAGE, ex);
 } catch (SecurityException ex) {
 log.error(ERROR_MESSAGE, ex);
 } catch (ClassNotFoundException ex) {
 log.error(ERROR_MESSAGE, ex);
 } catch (IllegalArgumentException ex) {
 log.error(ERROR_MESSAGE, ex);
 } catch (IllegalAccessException ex) {
 log.error(ERROR_MESSAGE, ex);
 }
 finally {
 fctx.popPageContext();
 }
 return panel;
 }

 This is dirty, but this perfectly works for quite some time now, at least
 until I stick to

 context-param
 param-nameorg.apache.myfaces.CACHE_EL_EXPRESSIONS/param-name
 param-valuestrict/param-value
 /context-param


 if I change it to alwaysRecompile, the state is not properly restored
 and I end with and NPE like :

 04/06/2014 12:29:41 ERROR [http-bio-8443-exec-56] - Exception occur!
 java.lang.NullPointerException
 at org.apache.myfaces.view.facelets.el.FaceletStateValueExpression.
 getValue(FaceletStateValueExpression.java:107)
 at org.apache.el.parser.AstIdentifier.getValue(AstIdentifier.java:68)
 at org.apache.el.ValueExpressionImpl.getValue(
 ValueExpressionImpl.java:185)
 at org.apache.myfaces.view.facelets.el.ContextAwareTagValueExpression
 .getValue(ContextAwareTagValueExpression.java:96)
 at javax.faces.component._DeltaStateHelper.eval(_
 DeltaStateHelper.java:360)
 at javax.faces.component.UIParameter.getValue(UIParameter.java:85)
 at org.apache.myfaces.shared.renderkit.html.HtmlLinkRendererBase.
 addChildParametersToHref

Re: Submit problem

[Leonardo Uribe]

Hi

You should check if the html output is correct. Probably it could be a
conflict between Tobago and the default JSF renderers, after all
RenderKitWrapper was added in JSF 2.0. Even if you set
renderKitId=”HTML_BASIC”, probably Tobago renderkit is still on top.

regards,

Leonardo Uribe


2014-05-08 10:42 GMT+02:00 Anton Sysoev bogatyr-h...@yandex.ru:

   Hi. I have a project based on Tobago 2.0 alpha 3 + Tomcat 7.0.34 +
 MyFaces Core 2.1.14 and it works fine. Now I need one page based on core
 jsf components only. I try to add a page like below in the project

 f:view xmlns=http://www.w3.org/1999/xhtml;http://www.w3.org/1999/xhtml


 xmlns:h=http://java.sun.com/jsf/html;http://java.sun.com/jsf/html
xmlns:f=http://java.sun.com/jsf/core;
renderKitId=”HTML_BASIC”

 html
 h[image: Дразнюсь]ody
 h:form
 h:inputText value=”#{mybean.number}”/
 h:commandButton value=”submit” action=”#{mybean.store}”/
 h:form
 /h[image: Дразнюсь]ody
 html
 /f:view

 Page is rendered but values are not submitted. Is this a bug or I’m doing
 something wrong? Thanks.

[ANNOUNCE] MyFaces Core v2.2.3 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces
Core 2.2.3.

MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified
by JSR-344.

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

MyFaces Core 2.2.3 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under
Group ID org.apache.myfaces.core.

Release Notes - MyFaces Core - Version 2.2.3

Bug

[MYFACES-3874] - Component property class is not writable
[MYFACES-3875] - Unhandled attribute for for custom converter
[MYFACES-3876] - Clarify requeriments and behavior of HTML
friendly markup feature
[MYFACES-3877] - Add @ListenerFor(systemEventClass =
PostRestoreStateEvent.class) causes StackOverflowException on MyFaces
2.2
[MYFACES-3878] - Update existing wrappers against new features in
JSF 2.2 (ViewHandlerWrapper, ...)
[MYFACES-3879] - Passthrough attributes for f:selectItem and
f:selectItems should be rendered by associated components
[MYFACES-3882] - Page with template and stylesheet not rendered correctly
[MYFACES-3883] - c:forEach with PSS enabled fails when add multiple rows

Task

[MYFACES-3884] - Add missing
impl/src/test/resources/org/apache/myfaces/view/facelets/**/testComposite/*.xhtml
licenses
[MYFACES-3885] - Add missing licenses to trivial js and xml files
and exclude spi files in pom to clean up rat output

regards,

Leonardo Uribe

Re: Start MyFaces on demand?

[Leonardo Uribe]

Hi

Don't worry about resource consumption. It is not a necessary. The code
only loads the necessary classes and its memory footprint is minimal.
Instead, you can reduce the size of some caches, usually affected by web
config parameters. The effect will be minimal in any case.

Leonardo
On Apr 17, 2014 9:09 PM, Felipe Jaekel fkjae...@gmail.com wrote:

 I'm working in a JAX-RS project, it has a configuration page in JSP that I
 would like to change to JSF.

 As this page is rarely used, basically only when the project is first
 deployed, I'd like to be able to start MyFaces only when this paged is
 accessed to avoid unnecessary server resources consumption.

 I tried to remove the the load-on-startup parameter from the FacesServlet,
 but I keep seeing MyFaces output on the server startup.

 Is it possible to do or I don't have to worry about resources consumption
 in this case?

 Thanks

Re: ViewExpiredException, but session hasn't timed out

[Leonardo Uribe]

Hi

I see, now I get it. By default MyFaces always renders the view state
field at the form end. To solve your problem, you need to render it at
the beginning of the form.

JSF spec javadoc for h:form says this:

... Call ViewHandler.writeState() before the the close of the form
element. Render all the necessary hidden fields for all commandLink
instances in the page just before the close of the form element.
...

What happen if we call it at the beginning of the form? there is a
buffer that takes the response to inject the view state token before
the end of the request, so you'll get an small increase of memory
usage if you are using client side state saving, but besides that
nothing else. This is an improvement/new feature, not a bug, so please
create an issue in MyFaces issue tracker as improvement.

regards,

Leonardo



2014-04-10 14:05 GMT+02:00 Felipe Jaekel fkjae...@gmail.com:
 It's necessary to have a slow internet connection to reproduce this, so I
 can't test locally. While the page is loading the user hits a command
 button. As the page is still loading, I guess the view state is not created
 yet, so viewHandler.restoreView(facesContext, viewId) returns null.

 Thanks for the suggestion. I'll give it try, but according to the component
 documentation, using it for this case feels more like a workaround than a
 solution, so I'd like to see if there are more options.


 2014-04-09 14:48 GMT-03:00 Howard W. Smith, Jr. smithh032...@gmail.com:

 Wow, you're using Shiro.

 Would be nice to have a list of steps how you duplicate this in your app,
 definitely and always.

 I definitely suggest you use OmniFaces restore view component to avoid this
 exception.
  On Apr 9, 2014 1:41 PM, Felipe Jaekel fkjae...@gmail.com wrote:

  I'm getting view expired exceptions if the user tries to perform an
 action
  in a page that isn't fully loaded.
 
  javax.faces.application.ViewExpiredException: /page/plano/plano.jsfNo
  saved view state could be found for the view identifier:
  /page/plano/plano.jsf
  at
 
 org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:181)
 
 
  Looking at RestoreViewExceutor source code we have this:
 
 
  if (facesContext.getResponseComplete())
  {
  // If the view handler cannot restore the view
  and the response
  // is complete, it can be an error or some
  logic in restoreView.
  return true;
  }
  else
  {
  // If the return from
  ViewHandler.restoreView() is null, throw a ViewExpiredException with
  an
  // appropriate error message.
  throw new ViewExpiredException(No saved view
  state could be found for the view identifier:  + viewId, viewId);
  }
  }
 
 
  Page hasn't fully loaded yet, so facesContext.getResponseComplete() is
  returning false, but isn't there a way to avoid this? Page gets unusable
  after the VEE is thrown.
 
 
  Thanks in advance,
 
  Phillip
 
 
  Full stackTrace:
 
  javax.faces.application.ViewExpiredException: /page/plano/plano.jsfNo
  saved view state could be found for the view identifier:
  /page/plano/plano.jsf
  at
 
 org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:181)
  at
 
 org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:196)
  at
 
 org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:143)
  at javax.faces.webapp.FacesServlet.service(FacesServlet.java:198)
  at
 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
  at
 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
  at
 
 org.primefaces.webapp.filter.FileUploadFilter.doFilter(FileUploadFilter.java:98)
  at
 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
  at
 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
  at
  org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
  at
 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
  at
 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
  at
 
 org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
  at
 
 org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
  at
 
 org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
  at
 
 org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
  at
 
 

Re: DefaultContextAwareELException serialization problem

[Leonardo Uribe]

Hi

An exception shouldn't be serializable. I can't find any line of code in MyFaces
that serialize and exception, so I suppose you are doing it manually somehow.

regards,

Leonardo

2014-04-04 15:43 GMT+02:00 Felipe Jaekel fkjae...@gmail.com:
 I'm eventually seeing this in my Tomcat 7 logs: *IOException while loading
 persisted sessions: java.io.WriteAbortedException: writing aborted;
 java.io.NotSerializableException:
 org.apache.myfaces.view.facelets.el.DefaultContextAwareELException.*

 I'm using MyFaces 2.2.2. Shouldn't DefaultContextAwareELException be
 serializable?

 Thanks

 *Full stackTrace:*
 Abr 04, 2014 10:35:50 AM org.apache.catalina.session.StandardManager doLoad
 Grave: IOException while loading persisted sessions:
 java.io.WriteAbortedException: writing aborted;
 java.io.NotSerializableException:
 org.apache.myfaces.view.facelets.el.DefaultContextAwareELException
 java.io.WriteAbortedException: writing aborted;
 java.io.NotSerializableException:
 org.apache.myfaces.view.facelets.el.DefaultContextAwareELException
  at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1354)
 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
  at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
  at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1990)
  at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1915)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
  at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
  at
 org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1595)
 at
 org.apache.catalina.session.StandardSession.readObjectData(StandardSession.java:1060)
  at
 org.apache.catalina.session.StandardManager.doLoad(StandardManager.java:282)
 at
 org.apache.catalina.session.StandardManager.load(StandardManager.java:202)
  at
 org.apache.catalina.session.StandardManager.startInternal(StandardManager.java:489)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
  at
 org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5476)
 at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
  at
 org.apache.catalina.core.StandardContext.reload(StandardContext.java:3988)
 at
 org.apache.catalina.loader.WebappLoader.backgroundProcess(WebappLoader.java:425)
  at
 org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1345)
 at
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530)
  at
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
 at
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
  at
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519)
 at java.lang.Thread.run(Thread.java:744)
 Caused by: java.io.NotSerializableException:
 org.apache.myfaces.view.facelets.el.DefaultContextAwareELException
 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1183)
  at
 java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1547)
 at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1508)
  at
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1431)
 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1177)
  at
 java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1547)
 at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1508)
  at
 java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1431)
 at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1177)
  at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
 at
 org.apache.catalina.session.StandardSession.writeObject(StandardSession.java:1671)
  at
 org.apache.catalina.session.StandardSession.writeObjectData(StandardSession.java:1077)
 at
 org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:430)
  at
 org.apache.catalina.session.StandardManager.unload(StandardManager.java:351)
 at
 org.apache.catalina.session.StandardManager.stopInternal(StandardManager.java:516)
  at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
 at
 org.apache.catalina.core.StandardContext.stopInternal(StandardContext.java:5655)
  at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:232)
 at
 org.apache.catalina.core.StandardContext.reload(StandardContext.java:3981)
  ... 7 more

 Abr 04, 2014 10:35:50 AM org.apache.catalina.session.StandardManager
 startInternal
 Grave: Exception loading sessions from persistent storage

[ANNOUNCE] MyFaces Core v2.2.2 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces
Core 2.2.2.

MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified
by JSR-344.

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

MyFaces Core 2.2.2 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under
Group ID org.apache.myfaces.core.

Release Notes - MyFaces Core - Version 2.2.2

Bug

[MYFACES-3865] - enctype=multipart/form-data not working
[MYFACES-3866] - Unexpected result when using
http://xmlns.jcp.org/jsf; namespace
[MYFACES-3867] -
SectionUniqueIdCounter.startUniqueIdSection(String base) does not
generate prefix correctly
[MYFACES-3869] - Ids used by c:if, c:forEach and other facelet
tags requires to be unique per facelet
[MYFACES-3870] - Attribute jsf:element elementName=... is not
working as expected

regards,

Leonardo Uribe

Re: 2.2 stability

[Leonardo Uribe]

Hi

@Karl  I think your problem should be something different. I closed
MYFACES-3869, since we have positive confirmation that the fix done
works, but we need to analyze your problem and check if there is an
error in MyFaces or not.

We need more information than just the stack trace. MyFaces default
error page gives the component tree using ErrorWriter and indicate
which component has the duplicate id. There are some tricks involving
programmatic component manipulation that can trigger a duplicate id
exception, but not because they are correct and myfaces has a bug but
because they are just invalid. In JSF 2.2, with vdl.createComponent it
is possible to create programmatically added components using facelets
in the right way. It is useful to use ui:debug tag to see the
component tree and describe the steps involved in the exception, to
help us to understand what could possible happen and how to fix it.

regards,

Leonardo Uribe

2014-03-13 7:19 GMT-05:00 Howard W. Smith, Jr. smithh032...@gmail.com:
 On Thu, Mar 13, 2014 at 7:34 AM, Karl Kildén karl.kil...@gmail.com wrote:

 Tried 2.2.2-20140313.024403-5

 Duplicate id problems are still present. I have tried for a while now to
 create a simple sample but I am unsuccessful so far.


 +1 thanks Karl for the report.

Re: 2.2 stability

[Leonardo Uribe]

Hi

2014-03-10 14:13 GMT-05:00 Howard W. Smith, Jr. smithh032...@gmail.com:
 response inline,

 On Mon, Mar 10, 2014 at 2:43 PM, Karl Kildén karl.kil...@gmail.com wrote:

 Hi Howard,

 If someone proposed a fix for me I must have missed it, so no my issues are
 still not resolved unfortunately. I don't think it's possible to write it
 in another fashion.


 Leonardo's response, asking you to try MyFaces 2.2.1, which was released
 within the last 12 to 24 hours. :)


Yes. If there is a bug in 2.2.1 and there is evidence, I'll do my best
for fix it.



 Problem #1: enctype=multipart/form-data not working. Not sure if anyone
 tried the demo app I linked in the jira but for now I can't investigate it
 any further on my own.


 i don't think Leonardo's response was targeting this issue.
 maybe/hopefully, Leonardo will respond at his earliest convenience.
 earlier, did you say that this issue is resolved via Mojarra 2.2.x (and
 some other container... glassfish, jboss, ...) ???


I have read JSF 2.2 spec fully and there is no special part related to multipart
encoding. I don't see how it can work, maybe it is something not documented.
I'll review the issue and check an example against latest Mojarra.



 Problem #2 I also have a problem with duplicated id's but it would take
 some time to reproduce it in a demo app so I'm hesitant to bring it up.
 Basically a lot of ajax, dynamic includes, c:forEach, ui:repeat, some
 bindings :-)


 did you try MyFaces 2.2.1 release to see if the duplicated IDs issue is
 fixed in your app/project?

 is it best to assume that c:forEach is supposed to work with/via AJAX PPR?
 just because Mojarra 'works', should we assume that Mojarra's
 implementation is correct?


Let's go to clarify this.

First of all, c:forEach has been a broken tag for year. Most people has found
many bugs, most of them related to its particular behavior. Since facelets was
donated to both Mojarra and MyFaces, both share the same code and has
the same problems. Mojarra has not done anything to fix the problems, so they
still have the old code, but in MyFaces 2.2.x branch we have tried to fix it
once for all.

The problem is sometimes in some situations the old code (in Mojarra) works,
but in others it just doesn't, it fails in the form of duplicate id
exceptions or the
state get lost, but for the user point of view sometimes it looks like things
are working but it is not, it is rotten from the inside.

So, the old code is not an option, because it is the worst possible option.
The new solution is the way to go, because it solves the problem from root.

So, Mojarra implementation is not correct, but just by luck it works in some
situations. The solution in MyFaces 2.2.1 is the best we have so far, works in
most cases and if there is a bug (I'm working on MYFACES-3867, which claims
a problem in a very specific complex case) we'll fix it.

I know all this has been annoying and painful, that's the reason why
we did it in
2.2.x only, but if we can fix it, it will be great because the
component tree will
use always PSS in those dynamic parts and that means lower state size, lower
session size and better overall performance.

 MyFaces and TomEE committers know that there MyFaces may be a bit more
 'strict' than Mojarra (I can agree with that as well, as per my experience
 when i migrated from Mojarra 2.1.x to MyFaces 2.1.x), and I think MyFaces
 (and TomEE) committers question the fact that Mojarra is really meeting
 requirements of the spec, or there is a different set of TCKs that Mojarra
 is running against. I hope 'they' will confirm, clarify, or correct what
 I'm stating here. :)

In few words, the vision of MyFaces is comply with the spec. But that does
not mean that MyFaces will be bug-compatible with Mojarra. I think the code
is very good from spec point of view, and each issue found that it has
been solved in a different way has been widely discussed. What's happening
here is the TCK does not cover a lot of edge cases, and since MyFaces is
widely used and many people gives a lot of good quality feedback, it has
been possible to fix a lot of issues that Mojarra has not seen yet, or has not
been fixed in the right way.

One way to see the quality of the code is take a look at the amount of
issues solved in each version. In 2.0.10 we solved 72 issues but in 2.0.21 we
solved just 2. In 2.2.1 we solved only 12.

regards,

Leonardo Uribe

Re: 2.2 stability

[Leonardo Uribe]

Hi Karl

2014-03-10 15:15 GMT-05:00 Karl Kildén karl.kil...@gmail.com:
 Hi Leo,

 Upgraded to  2.2.1 today (or was it yesterday?) and had problems. Removed
 org.apache.myfaces.STRICT_JSF_2_FACELETS_COMPATIBILITY and many problems
 went away. Much later discovered more problems but it's just me and my
 silly app until I have proof :-)

 I totally agree that c:forEach was more broken before! Thanks a lot for
 fixing it.


I have found the problem related to MYFACES-3867, so I have already
fixed the code in trunk. I think this bug deserves a quick-fix release.

 I would be very interested in some more input / clarifications about my
 other problem actually. Are you saying that forms may not
 use  enctype=multipart/form-data? How are you supposed to
 fileUpload? Perhaps you must have a fileUpload component present if the
 form has  enctype=multipart/form-data? Sounds like a weird limitation. My
 functional requirement is of course a form with a fileupload component, it
 is not working though and it's because the form will not post. I ended up
 removing all markup until I had a single button in a form and it still did
 not work, that's when I created a jira. But at one point that form did have
 a fileupload too with no difference in the result.



The example provided by Michael Kurz in:

https://github.com/jsflive/jsf22-examples/blob/master/jsf22-input-file/src/main/webapp/upload.xhtml

h:form id=form enctype=multipart/form-data
h:messages/
h:panelGrid columns=2
h:outputText value=File:/
h:inputFile id=file value=#{uploadPage.uploadedFile}
validator=#{uploadPage.validateFile}/
/h:panelGrid

h:commandButton value=Upload File action=#{uploadPage.uploadFile}/
h:commandButton value=Upload File (Ajax)
action=#{uploadPage.uploadFile}
f:ajax execute=file render=@all/
/h:commandButton

h:panelGrid id=content columns=1
h:outputText value=Content:/
h:inputTextarea readonly=true value=#{uploadPage.fileContent}
rows=10 cols=100/
/h:panelGrid
/h:form

Look the enctype=multipart/form-data is there, but the code also
needs the h:inputFile. I don't see how it can work with just the button.

h:form id=mainForm enctype=multipart/form-data
h:commandButton value=Press me action=# {bean.test}/br/
/h:form

I can see the example in the rar file:

h:form id=mainForm enctype=multipart/form-data
h:panelGrid columns=2
h:outputLabel for=name value=Please enter your name/
h:inputText id=name value=#{helloWorld.name}
required=true/
/h:panelGrid
h:commandButton value=Press me action=#{helloWorld.send}/br/
h:messages showDetail=true showSummary=false/
/h:form

but the same, it requires the h:inputFile so the file is uploaded. Servlet
3.0 implementation handles the request, and JSF uses the spec, so
if the servlet spec works JSF should work.

regards,

Leonardo Uribe





 On 10 March 2014 21:01, Leonardo Uribe lu4...@gmail.com wrote:

 2014-03-10 14:56 GMT-05:00 Karl Kildén karl.kil...@gmail.com:
  Ah the new release, yes I tried it asap it did not fix my issue.
 

 Which one? #1 or #2 ?

  Regarding the duplicated id issue that I think could be related to
  c:forEach, No idea what the problem is but it works fine with mojarra and
  just as fine with myfaces 2.1.x. The construct in that app is special so
 it
  is up to me to reproduce it and I don't have time until next week. And
 yes,
  c:forEach works with ajax but it's important that the items are unchanged
  during postback.
 

 Ok. If we have an example we will be able to fix it more quickly. For now
 I'll take a look at MYFACES-3867

  I am considering mojarra because enctype=multipart/form-data is not
  working for me with any myfaces 2 version. It's common knowledge that
  Mojarra is skimping on some validation here and there.
 
 
  On 10 March 2014 20:13, Howard W. Smith, Jr. smithh032...@gmail.com
 wrote:
 
  response inline,
 
  On Mon, Mar 10, 2014 at 2:43 PM, Karl Kildén karl.kil...@gmail.com
  wrote:
 
   Hi Howard,
  
   If someone proposed a fix for me I must have missed it, so no my
 issues
  are
   still not resolved unfortunately. I don't think it's possible to
 write it
   in another fashion.
  
 
  Leonardo's response, asking you to try MyFaces 2.2.1, which was released
  within the last 12 to 24 hours. :)
 
 
  
   Problem #1: enctype=multipart/form-data not working. Not sure if
 anyone
   tried the demo app I linked in the jira but for now I can't
 investigate
  it
   any further on my own.
  
 
  i don't think Leonardo's response was targeting this issue.
  maybe/hopefully, Leonardo will respond at his earliest convenience.
  earlier, did you say that this issue is resolved via Mojarra 2.2.x (and
  some other container... glassfish, jboss, ...) ???
 
 
  
   Problem #2 I also have a problem

Re: 2.2 stability

[Leonardo Uribe]

Hi

@MYFACES-3865 It was fixed in 2.2.1, and the artifacts will be released
in no time. The fix for c:forEach was really complex and painful, but it
was finally done and the result is the best option we will have. Finally
we have a proper solution that will work in complex cases and will
allow all facelets dinamic tags to work well together.

The hack done for:

org.apache.myfaces.STRICT_JSF_2_FACELETS_COMPATIBILITY

Is meant for people that requires the old (and buggy) logic from facelets
1.1.x, so it is expected to do not work in some cases.

My personal perception is 2.2.1 will be very stable, it is obvious to have
some small bugs, but in this release we created a lot of junit tests, so
the probability of find bugs has become small. Anyway, we will be eager
to check and fix all new issues as soon as possible.

regards,

Leonardo Uribe

2014-03-09 18:26 GMT-05:00 Howard W. Smith, Jr. smithh032...@gmail.com:
 On Sun, Mar 9, 2014 at 5:20 PM, Ludovic Pénet l.pe...@senat.fr wrote:

 I found 2.2 to be very stable, almost a drop in replacement for 2.1.


 +1

 I was using MyFaces 2.1.13 prior using MyFaces 2.2.0 (final), and MyFaces
 2.2.0 seems just as stable as 2.1.13 is/was. I'm very pleased/satisfied
 with myFaces 2.2.0, and i have had 'no' issues at all. :)

[ANNOUNCE] MyFaces Core v2.0.21 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces
Core 2.0.21.

MyFaces Core is a JavaServer(tm) Faces 2.0 implementation as specified
by JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100%
compliant with the JSR-314 specification.

MyFaces Core 2.0.21 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under
Group ID org.apache.myfaces.core.

Release Notes - MyFaces Core - Version 2.0.21

Bug

[MYFACES-3847] - HtmlStylesheetRenderer doesn't ignore additional
link parameters when checking for the resource
[MYFACES-3857] - Unbalanced pushComponentToEL/popComponentFromEL
in processUpdates

regards,

Leonardo Uribe

[ANNOUNCE] MyFaces Core v2.1.15 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces
Core 2.1.15.

MyFaces Core is a JavaServer(tm) Faces 2.1 implementation as specified
by JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100%
compliant with the JSR-314 specification.

MyFaces Core 2.1.15 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under
Group ID org.apache.myfaces.core.

Release Notes - MyFaces Core - Version 2.1.15

Bug

[MYFACES-3847] - HtmlStylesheetRenderer doesn't ignore additional
link parameters when checking for the resource
[MYFACES-3850] - html EL expression inside markup enables escape
on static text in facelets jspx mode
[MYFACES-3854] - oam-compress-spaces remove carriage return / line
feed in CDATA sections
[MYFACES-3857] - Unbalanced pushComponentToEL/popComponentFromEL
in processUpdates


regards,

Leonardo Uribe

[ANNOUNCE] MyFaces Core v2.2.1 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces
Core 2.2.1.

MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified
by JSR-344.

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

MyFaces Core 2.2.1 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under
Group ID org.apache.myfaces.core.

Release Notes - MyFaces Core - Version 2.2.1

Bug

[MYFACES-3845] - Invalid modification of
facesConfig.getFacesFlowDefinitions() collection when implicit flow
definition is derived
[MYFACES-3847] - HtmlStylesheetRenderer doesn't ignore additional
link parameters when checking for the resource
[MYFACES-3850] - html EL expression inside markup enables escape
on static text in facelets jspx mode
[MYFACES-3853] - ui:include not working inside c:forEach
[MYFACES-3854] - oam-compress-spaces remove carriage return / line
feed in CDATA sections
[MYFACES-3857] - Unbalanced pushComponentToEL/popComponentFromEL
in processUpdates
[MYFACES-3858] - Faces Flow startNode is not defined by default
for xml non empty files ending with -flow.xml
[MYFACES-3859] - Allow use the flowId as a nodeId inside the same flow
[MYFACES-3860] - UIViewRoot.restoreViewScopeState(...) is not
being called from DefaultFaceletsStateManagementStrategy
[MYFACES-3861] - impl-test module using unpack plugin does not
allow generate site

Improvement

[MYFACES-3846] - Implement temporal resourcehandler cache for JSF
2.2 contracts
[MYFACES-3862] - Set mock InitialContextFactory for junit testing
with myfaces impl test


regards,

Leonardo Uribe

Re: 2.2.0 and multipart

[Leonardo Uribe]

Hi

I can confirm a simple example using MyFaces 2.2.0 works. See:

http://jsflive.wordpress.com/2013/04/23/jsf22-file-upload/

I think the problem is caused by some kind of incompatibility from
primefaces p:fileUpload. h:inputFile relies on servlet 3.0 spec, but
p:fileUpload could still use the filter approach, so you need to put a
filter on top of faces servlet to handle the multipart request.

Theoretically, nothing has changed, or at least at first view I cannot
see a problem in MyFaces besides the issues we have already fixed, so
2.2.0 should not have any problem.

It could be great if you can provide an example webapp showing the
problem, so we can take a look with the debugger and see if there is a
problem from primefaces or from myfaces. For now the evidence I have
suggest MyFaces is ok.

regards,

Leonardo Uribe

2014-02-25 10:36 GMT-05:00 Leonardo K. Shikida shik...@gmail.com:
 Thanks
 Em 25/02/2014 12:20, Howard W. Smith, Jr. smithh032...@gmail.com
 escreveu:

 On Tue, Feb 25, 2014 at 3:20 AM, Werner Punz werner.p...@gmail.com
 wrote:

  Am 22.02.14 02:58, schrieb Leonardo K. Shikida:
 
   Hi
 
  Just noticed this thread about tomee, myfacs 2.2.0 and multipart request
 
  stackoverflow.com/questions/21948228/how-to-get-jsf-file-
  upload-to-work-on-tomee-1-6
 
  does anyone know if between 2.1.13 and 2.2.0, multipart request has got
  any
  new bug? could not find anything in JIRA
 
  the guy who posted the stackoverflow question tested with
 
  h:commandButton while I've reproduced the problem just switching
  myfaces jars from vanilla tomee 1.6.0 from 2.1.13 to 2.2.0 and using
  p:fileUpload
 
  []
 
  Leo
 
   Hi this could be a new bug, we introduced a fileupload handling with
 JSF
  2.2 (the h:inputFile tag) maybe the normal multipart request handling was
  broken by the extensions done in this area the best bet is to file a
  bugreport in the myfaces bugtracker https://issues.apache.org/
  jira/browse/MYFACES
 
  Werner
 
 
  +1 thanks Leonardo for informing the user list about this issue. I am
 using MyFaces 2.2 (and/via TomEE 1.6.1 snapshot) with my JSF web
 application, and I confirmed this bug/issue too in my app. PrimeFaces 4.x
 (simple) fileUpload is no longer working. :(

 maybe, it can/should be confirmed if MyFaces 2.2 (basic/simple) fileUpload
 works as designed/expected. i have not tested that though/yet.

[ANNOUNCE] release of myfaces master pom v 15

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of myfaces
master pom v 15.

This pom is used internally by define default configuration and
community information shared by all myfaces projects and used when
site deployment and reports are executed.

You can find it in the maven repo unde the group org.apache.myfaces.myfaces.

http://repo2.maven.org/maven2/org/apache/myfaces/myfaces/15/myfaces-15.pom

regards,

Leonardo Uribe

Re: Composite components in myfaces 2.2.

[Leonardo Uribe]

Hi

I think the problem is mix ui:composition with cc:interface or
cc:implementation. The compiler check these tags and do some special
steps. Just use other different tag like this.

html xmlns=http://www.w3.org/1999/xhtml;
xmlns:h=http://java.sun.com/jsf/html;  

regards,

Leonardo Uribe

2014-02-24 15:01 GMT-05:00 Michael Kurz michi.k...@gmx.at:
 Maybe you are missing a faces-config.xml in the jar inside META-INF. JSF
 won't scan the jar otherwise. See my post at JSFlive [1] for details.

 Best regards
 Michi

 [1]: http://jsflive.wordpress.com/2011/03/24/custom-component-library/


 Am 24.02.2014 13:26, schrieb Johannes Murth:

 The output of DOCTYPE was related to another issue:

 The XHTML that is embedded with ui:include had this as root element.
 ui:composition as root element solved the problem.
 - Side question: is this an official change from 2.1 to 2.2?

 But there is still the issue that the composite component from the JAR is
 not found:

 The using page looks like this:

  
xmlns:xma=http://openxma.codehaus.org/xmajsf;

 ...
  xma:navbar .. brand=Test /
  ..
 /...

 The component is  in somelib.jar/META-INF/resources/xmajsf/navbar.xhtml
 and
 looks like this

 Beside there is a xmajsf.taglib.xml in the root of the same JAR:
 ui:composition xmlns=http://www.w3.org/1999/xhtml;
 xmlns:cc=http://java.sun.com/jsf/composite;
  xmlns:ui=http://java.sun.com/jsf/facelets;
 cc:interface componentType=Navbar
 cc:attribute name=brand required=true/
 /cc:interface
 cc:implementation
 ...
 /cc:implementation
 /ui:composition

 Beside there is this content in META-INF\xmajsf.taglib.xml inside the same
 JAR:

 facelet-taglib version=2.0 xmlns=http://java.sun.com/xml/ns/javaee;
   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
 xsi:schemaLocation=
 http://java.sun.com/xml/ns/javaee
 http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd;
   namespacehttp://openxma.codehaus.org/xmajsf/namespace
   composite-library-namexmajsf/composite-library-name
 /facelet-taglib

 What am I doing wrong?



 2014-02-14 17:52 GMT+01:00 Michael Kurz michi.k...@gmx.at:

 Hi,

 would be interesting how your composite component looks like (the basic
 structure) and how it is embedded in the page.

 Best regards
 Michi

 Am 13.02.2014 13:10, schrieb Johannes Murth:

   Hi! I just upgraded from 2.1 to 2.2 and have rendering problem because
 xml

 doctype and html tag are rendered right before composite component.
 These
 break the layout and should just be swallowed.

 Thanks for any advice!

Re: @FlowScoped, @Named and @ManagedBean

[Leonardo Uribe]

Hi

I forgot to say what's wrong in the xml file is define the start node.
I have created and fixed this issue on:

https://issues.apache.org/jira/browse/MYFACES-3858

regards,

Leonardo Uribe


2014-02-13 13:12 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr:
 On 13/02/2014 19:01, Leonardo Uribe wrote:

 Hi

 Thanks for the example. It helps to clarify the problem. The
 definition of the flow has a problem:

  @Produces
  @FlowDefinition
  public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder)
 {
  String flowId = flux;
  flowBuilder.id(, flowId);
  flowBuilder.viewNode(flowId,
  / + flowId + / + flowId + .xhtml).
  markAsStartNode();
 /*flowBuilder.returnNode(returnFromFlux).
  fromOutcome(#{flowScopedBean.return});*/

  return flowBuilder.getFlow();
  }

 In this part:

 flowBuilder.viewNode(flowId,
  / + flowId + / + flowId + .xhtml).
  markAsStartNode();

 you are using the flow id as a viewNodeId. That confuses the
 navigation algorithm because the spec says that an outcome can be a
 flowId, and in that sense a flowId is a global identifier that cannot
 be reused. The fix is just set another id:

  flowBuilder.viewNode(start,
  / + flowId + / + flowId + .xhtml).
  markAsStartNode();

 The example only requires some small changes in FlowScopedBean and that's
 it.

 ok for this one, I will try it tomorrow. And can you tell me what was wrong
 with XML file (or the empty XML file) ?

 Thank you,


 Ludovic
 |
 | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
 |

Re: @FlowScoped, @Named and @ManagedBean

[Leonardo Uribe]

Hi

I also did some changes in the navigation to deal with the case when
the nodeId has the same name as the flow in:

https://issues.apache.org/jira/browse/MYFACES-3859

Please note in a normal case click to enter into a flow twice (enter
into a flow, navigate and try to enter into the same flow again) cause
get out of the flow and enter into the flow again, which is expected.
But in this case, the resulting flow will not have that behavior and
instead the navigation goes to the node identified as start node
without exit from the flow.

regards,

Leonardo Uribe

2014-02-19 20:05 GMT-05:00 Leonardo Uribe lu4...@gmail.com:
 Hi

 I forgot to say what's wrong in the xml file is define the start node.
 I have created and fixed this issue on:

 https://issues.apache.org/jira/browse/MYFACES-3858

 regards,

 Leonardo Uribe


 2014-02-13 13:12 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr:
 On 13/02/2014 19:01, Leonardo Uribe wrote:

 Hi

 Thanks for the example. It helps to clarify the problem. The
 definition of the flow has a problem:

  @Produces
  @FlowDefinition
  public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder)
 {
  String flowId = flux;
  flowBuilder.id(, flowId);
  flowBuilder.viewNode(flowId,
  / + flowId + / + flowId + .xhtml).
  markAsStartNode();
 /*flowBuilder.returnNode(returnFromFlux).
  fromOutcome(#{flowScopedBean.return});*/

  return flowBuilder.getFlow();
  }

 In this part:

 flowBuilder.viewNode(flowId,
  / + flowId + / + flowId + .xhtml).
  markAsStartNode();

 you are using the flow id as a viewNodeId. That confuses the
 navigation algorithm because the spec says that an outcome can be a
 flowId, and in that sense a flowId is a global identifier that cannot
 be reused. The fix is just set another id:

  flowBuilder.viewNode(start,
  / + flowId + / + flowId + .xhtml).
  markAsStartNode();

 The example only requires some small changes in FlowScopedBean and that's
 it.

 ok for this one, I will try it tomorrow. And can you tell me what was wrong
 with XML file (or the empty XML file) ?

 Thank you,


 Ludovic
 |
 | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
 |

Re: Error with c:if inside next c:forEach MyFaces 2.2.0

[Leonardo Uribe]

Hi

It looks like a page processed by facelets, not by JSP.

Between 2.2.0-beta and 2.2.0 we did a change in c:forEach tag. The
improvement is ok, but according to the stack trace I can see a
problemn with the id generation. I recently fixed this issue:

https://issues.apache.org/jira/browse/MYFACES-3853

It looks like something related. If the id generation is correct,
c:forEach and c:if receive different ids. The old algorithm in
c:forEach did not have an associated id.

Could you please try with the latest snapshot available here?

https://repository.apache.org/content/repositories/snapshots/org/apache/myfaces/core/

regards,

Leonardo Uribe

2014-02-18 21:20 GMT-05:00 Najy Nicolas najy.nico...@gmail.com:
 Hi,


 I have a c:if tag inside 3 nested for loops in a JSP file.
 I get an error  only when I add the c:if to the JSP...

 I only got the error when I upgraded to MyFaces 2.2.0. The same JSP
 worked fine when I used MyFaces 2.2.0-beta


 c:forEach var=table items=#{myBean.tables}
 c:forEach var=row items=#{table.rows}
 c:forEach var=cell items=#{row.cells}
 c:if  test=#{cell.visible}
 #{cell.comeValue}
 /c:if
 c:forEach/
 c:forEach/
 c:forEach/

 WARNING: JSF error handler:
 java.lang.ClassCastException: java.lang.Boolean cannot be cast to
 org.apache.myfaces.view.facelets.tag.jstl.core.IterationState
 at
 org.apache.myfaces.view.facelets.tag.jstl.core.ForEachHandler.apply(ForEachHandler.java:210)
 at
 javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46)
 at
 org.apache.myfaces.view.facelets.tag.jstl.core.ForEachHandler.applyFirstTime(ForEachHandler.java:382)
 at
 org.apache.myfaces.view.facelets.tag.jstl.core.ForEachHandler.apply(ForEachHandler.java:229)
 at
 javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46)
 at
 org.apache.myfaces.view.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:161)
 at
 org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:59)
 at
 org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:48)
 at
 org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:514)
 at
 org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:568)
 at
 org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:546)
 at
 org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:240)
 at
 org.apache.myfaces.view.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:226)
 at
 org.apache.myfaces.view.facelets.tag.jstl.core.ForEachHandler.applyFirstTime(ForEachHandler.java:382)
 at
 org.apache.myfaces.view.facelets.tag.jstl.core.ForEachHandler.apply(ForEachHandler.java:229)
 at
 org.apache.myfaces.view.facelets.tag.jstl.core.IfHandler.apply(IfHandler.java:126)
 at
 javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46)
 at
 org.apache.myfaces.view.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:161)
 at
 org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:59)
 at
 org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:48)
 at
 org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:514)
 at
 org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:568)
 at
 org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:546)
 at
 org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:240)
 at
 org.apache.myfaces.view.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:226)
 at
 org.apache.myfaces.view.facelets.tag.jstl.core.IfHandler.apply(IfHandler.java:126)
 at
 javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46)
 at
 org.apache.myfaces.view.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:161)
 at
 org.apache.myfaces.view.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:59)
 at
 org.apache.myfaces.view.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:48)
 at
 org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:514)
 at
 org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:568)
 at
 org.apache.myfaces.view.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:546)
 at
 org.apache.myfaces.view.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:240)
 at
 org.apache.myfaces.view.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:226)
 at
 org.apache.myfaces.view.facelets.tag.jstl.core.IfHandler.apply(IfHandler.java:126)
 at
 javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:46)
 at
 javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:55

[ANNOUNCE] MyFaces Test v1.0.6 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces
Test 1.0.6.

The Myfaces Test Framework provides mock object libraries, plus base
classes for creating your own JUnit TestCases for JSF.

For more information please see: http://myfaces.apache.org/test

MyFaces Core is available in the central Maven repository under Group
ID org.apache.myfaces.test.

Release Notes - MyFaces Test - Version 1.0.6

Bug

[MYFACESTEST-64] - MockMethodExpression should throw MethodNotFoundException

Improvement

[MYFACESTEST-67] - Allow use servlet listeners inside mocks
[MYFACESTEST-68] - Set Location header on redirect for mock

New Feature

[MYFACESTEST-65] - Implement HttpServletRequest.isUserInRole(String)
[MYFACESTEST-66] - pre-configured containers

regards,

Leonardo Uribe

Re: @FlowScoped, @Named and @ManagedBean

[Leonardo Uribe]

Hi

Thanks for the example. It helps to clarify the problem. The
definition of the flow has a problem:

@Produces
@FlowDefinition
public Flow defineFlow(@FlowBuilderParameter FlowBuilder flowBuilder) {
String flowId = flux;
flowBuilder.id(, flowId);
flowBuilder.viewNode(flowId,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();
/*flowBuilder.returnNode(returnFromFlux).
fromOutcome(#{flowScopedBean.return});*/

return flowBuilder.getFlow();
}

In this part:

flowBuilder.viewNode(flowId,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();

you are using the flow id as a viewNodeId. That confuses the
navigation algorithm because the spec says that an outcome can be a
flowId, and in that sense a flowId is a global identifier that cannot
be reused. The fix is just set another id:

flowBuilder.viewNode(start,
/ + flowId + / + flowId + .xhtml).
markAsStartNode();

The example only requires some small changes in FlowScopedBean and that's it.

regards,

Leonardo Uribe

2014-02-13 6:03 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr:
 On 13/02/2014 01:44, Leonardo Uribe wrote:
 [...]


 This is an edge case. Theorically it should work. Could you please provide
 the
 stack trace, so I can investigate it further?.


 Please find attached a mini maven project reproducing the «bug» (or maybe a
 PBKAC there :-) ).

 If you just build and debug it, you will be in the situation I just
 described.

 If you disable the Flux description bean (I just comment the @Produces  and
 @FlowDefinition annotations to do that) and rename

 src/main/webapp/flux/flux-flow-empty.xml
 or
 src/main/webapp/flux/flux-flow-simple.xml

 to
 src/main/webapp/flux/flux-flow.xml

 you will be able to test the other situations I described.

 Thanks again !


 Ludovic


 |
 | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
 |

Re: @FlowScoped, @Named and @ManagedBean

[Leonardo Uribe]

...@gmail.com wrote:
   
 Can't you just switch to DS?


 2014-02-11 18:46 GMT+01:00 Leonardo Uribe lu4...@gmail.com
  javascript:;
 :

  Hi
 
  CDI implementations does not require to provide anything to JSF
 in
  order to make @FlowScoped to work. The code has been tested
 against
  OWB and Weld and it works in both cases.
 
  But the flow stuff relies on the new ClientWindow API, and that
  could
  cause a conflict with CODI, because CODI provides a solution for
  this
  part too. In fact, the solution introduced in the standard comes
  from
  CODI.
 
  In your particular case, the best option is provide a custom
  ClientWindowFactory / ClientWindow that implements
  ClientWindow.getId() method and grab the value generated by CODI.
  Theorically there is no need of the custom PhaseListener, because
  the
  attachWindow step is done in CODI. I haven't tried it but I
  suppose
  a custom ClientWindow will work.
 
  regards,
 
  Leonardo Uribe
 
  2014-02-11 11:56 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr:
   On 11/02/2014 14:51, l.pe...@senat.fr wrote:
  
   On 11/02/2014 10:28, l.pe...@senat.fr wrote:
  
   On 11/02/2014 03:30, Leonardo Uribe wrote:
  
  
   [...]
  
   @FlowScoped annotation is for CDI only, so it will not work
  for
JSF
   managed beans. In your case, I believe the bean is
  instantiated
but
 it
   is not stored in any context, so once is created is
 discarded,
 giving
   the impression that the bean is working but it is not.
  
  



 --
 ___

 Kito D. Mann | @kito99 | Author, JSF in Action
 Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
 http://www.JSFCentral.com | @jsfcentral
 +1 203-998-0403

 * Listen to the Enterprise Java Newscast: *http://w
 http://blogs.jsfcentral.com/JSFNewscast/ww.enterprisejavanews.com
 http://ww.enterprisejavanews.com*
 * JSFCentral Interviews Podcast:
 http://www.jsfcentral.com/resources/jsfcentralpodcasts/
 * Sign up for the JSFCentral Newsletter: http://oi.vresp.com/?fid=ac048d0e17

Re: How to survive viewscoped beans/viewmap after session destroy (using client side saving)?

[Leonardo Uribe]

Hi

In JSF 2.2 it was decided to store view scope beans always in session
(take a look at the description of @ViewScoped annotation in the
javadoc). But you can just call facesContext.getViewRoot() and use the
attribute map. Just remember the values there must be Serializable or
implement StateHolder.

In my understanding, this was done in this way to support @PreDestroy
annotation when the session is expired.

regards,

Leonardo Uribe



2014-02-12 23:28 GMT-05:00 user 01 user...@gmail.com:
 I'm using Myfaces 2.2 with Client-side state saving. I see that the
 ViewScoped beans  data stored in viewmap is lost after the user session is
 destroyed.
 I came to know, not sure if it is correct, that this is the expected
 behavior but then what's the way to avoid view expired exceptions after
 session destroy?

 My problem is that I destroy the user session pretty quickly after some
 inactivity period(like after 20 minutes) but I want the viewscope data to
 survive even after that(when using client saving) so that when the user
 comes back after session destroy, he doesn't need to do a page refresh. I
 dont know why  how this is so implemented but It is very normal that the
 user may be busy reading some section of website or be away for 20 minutes,
  as he comes back  interacts with opened pages, how would I make that
 work without the state ?
 I think this is a common requirement for any public websites.

 I think the internally used jsf viewstate is not lost, if I use client side
 state saving(as my pages still work), but then why are those viewscoped
 beans scoped that were also serialized to page along with the viewstate.

 If this the designed behavior, Is there any way I could make the view
 scoped data survive session expiration ?

Re: @FlowScoped, @Named and @ManagedBean

[Leonardo Uribe]

Hi

CDI implementations does not require to provide anything to JSF in
order to make @FlowScoped to work. The code has been tested against
OWB and Weld and it works in both cases.

But the flow stuff relies on the new ClientWindow API, and that could
cause a conflict with CODI, because CODI provides a solution for this
part too. In fact, the solution introduced in the standard comes from
CODI.

In your particular case, the best option is provide a custom
ClientWindowFactory / ClientWindow that implements
ClientWindow.getId() method and grab the value generated by CODI.
Theorically there is no need of the custom PhaseListener, because the
attachWindow step is done in CODI. I haven't tried it but I suppose
a custom ClientWindow will work.

regards,

Leonardo Uribe

2014-02-11 11:56 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr:
 On 11/02/2014 14:51, l.pe...@senat.fr wrote:

 On 11/02/2014 10:28, l.pe...@senat.fr wrote:

 On 11/02/2014 03:30, Leonardo Uribe wrote:


 [...]

 @FlowScoped annotation is for CDI only, so it will not work for JSF
 managed beans. In your case, I believe the bean is instantiated but it
 is not stored in any context, so once is created is discarded, giving
 the impression that the bean is working but it is not.

 In MyFaces it is possible to create a custom flow scope annotation for
 other containers that works just like @FlowScoped, implementing
 org.apache.myfaces.spi.FacesFlowProvider SPI interface. You are
 already in CDI, so you don't need to bother about that.

 I have seen @Named annotation working with Spring, so it is not
 something specific for CDI, but @FlowScoped depends of CDI API.

 I am using CODI 1.0.5 (I heavily use its @ViewAccessScoped annotation)
 with OpenWebBeans 1.2.1.

 So, I thought  was ok on the CDI side...

 ...but after reading your mail, it seems to me that this CDI
 implementation was provided before JSF 2.2 release, and so that it must not
 include proper @FacesFlow support.

 Should I switch to another implementation, like DeltaSpike ?

 I must have misunderstood your mail from Sep 26 2013 (
 http://myfaces.10567.n7.nabble.com/JSF-2-2-status-amp-snapshot-usage-td115852.html
 ) inviting us to try Faces Flows in MyFaces 2.2.

 After some debugging, I found that :
 * beans are discovered and processed ok by
 org.apache.myfaces.flow.cdi.FlowScopeCDIExtension
 * -flow.xml is detected and processed with no errors ;
 * if I use an empty -flow.xml file, an exception is raised line 716 of
 org.apache.myfaces.config.DefaultFacesConfigurationProvider (on
 facesConfig.getFacesFlowDefinitions().add(flow); )
 * if I add a breakpoint in
 org.apache.myfaces.flow.FlowHandlerImpl#clientWindowTransition, I can see :
 ** my flow registered in _flowMapById (with flow1 key)
 ** my flow registered in _flowMapByDocumentId (with an empty key)
 ** that _facesFlowProvider is null


 ok, I think I got it. And, as I feared, it seems to be CODI related.

 In JSF2.2, a call to

 //JSF 2.2: attach window
 _lifecycle.attachWindow(facesContext);

 has been added line 193 of javax.faces.webapp.FacesServlet

 When you use CODI, _lifecycle is an instance of

 org.apache.myfaces.extensions.cdi.jsf2.impl.listener.phase.CodiLifecycleWrapper

 This wrapper has been designed for JSF 2.0 and 2.1. So, it does not wrap the
 call to attachWindow. And Lifecycle#attachWindow, which does nothing, is
 called.

 Later, when JSf tries to find my @FlowScoped bean, it fails in

 org.apache.myfaces.flow.FlowHandlerImpl#getCurrentFlow , because client
 windos is null

 (line 165 and following) :
 ClientWindow clientWindow =
 context.getExternalContext().getClientWindow();
 if (clientWindow == null)
 {
 return null;
 }

 So, I guess that I have to write a custom PhaseListener to solve this little
 glitch.

 If you have a better solution, I will gladly take it.


 Best regards,

 Ludovic
 |
 | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
 |

Re: @FlowScoped, @Named and @ManagedBean

[Leonardo Uribe]

Hi

2014-02-10 11:56 GMT-05:00 l.pe...@senat.fr l.pe...@senat.fr:
 Dear all,

 I am starting to really use JSF 2.2. I am trying to use Faces Flows. I am
 starting with a very simple flow, whose name is flow1.

 So, under src/main/webapp, I have a flow1 directory containing

 flow1-flow.xml
 flow1.xhtml
 flow1b.xhtml

 flow1-flow.xml contains :

 ?xml version=1.0 encoding=UTF-8?
 faces-config
 xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
 xmlns='http://xmlns.jcp.org/xml/ns/javaee'
 xsi:schemaLocation='http://xmlns.jcp.org/xml/ns/javaee
 http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd'
 version='2.2' 
 flow-definition id=flow1
 flow-return id=returnFromFlow1
 from-outcome/accueil/from-outcome
 /flow-return
 /flow-definition
 /faces-config


 With such a simple config, using conventions would be a better choice than
 configuration, but I plan to add more things to it... :-)

 I use a @FlowScoped bean declared this way :

 @Named
 @FlowScoped(flow1)
 public class MinintFileContext implements Serializable {

 
 }

 and it does not work. I have the following exception :

 javax.servlet.ServletException: javax.servlet.ServletException:
 javax.el.ELException: javax.enterprise.context.ContextNotActiveException:
 WebBeans context with scope type annotation @FlowScoped does not exist
 within current thread


 To make it work, I have to use @ManagedBean instead of @Named.

 My first question is : I do not understand why... In my (obviously wrong)
 understanding, @Named was a super-set of CDI-managed beans, including
 @ManagedBean-s.



@FlowScoped annotation is for CDI only, so it will not work for JSF
managed beans. In your case, I believe the bean is instantiated but it
is not stored in any context, so once is created is discarded, giving
the impression that the bean is working but it is not.

In MyFaces it is possible to create a custom flow scope annotation for
other containers that works just like @FlowScoped, implementing
org.apache.myfaces.spi.FacesFlowProvider SPI interface. You are
already in CDI, so you don't need to bother about that.

I have seen @Named annotation working with Spring, so it is not
something specific for CDI, but @FlowScoped depends of CDI API.

 Another question...

 I am using PrimeFaces p:menubar . I noticed that I can not use /flow1 as
 the outcome of a menuitem

 Ex : p:menuitem value=Blah blah blah outcome=/flow1 /

 I have to use

 p:menuitem value=Blah blah blah outcome=/flow1/flow1 /

 Why ? This might be a PF-specific question.


Try in this way:

p:menuitem value=Blah blah blah outcome=flow1 /

If you put /flow1 as outcome, the navigation algorithm will
interpret this as a normal navigation to a page (/flow1.xhtml), so the
flow scope will not be activated and the bean will not be instantiated
correctly. It should work without any changes in primefaces, because
the outcome should be calculated using
ConfigurableNavigationHandler.getNavigationCase(...).


 Finally, I am failing to use the flow-return configuration.

 I tried

 p:commandButton value=Terminer action=returnFromFlow1/

 and

 h:commandButton value=Terminer action=returnFromFlow1/

 But it just does not work.

 So, I tried to change the config to

 flow-return id=returnFromFlow1
 from-outcome#{minintFileContext.returnValue}/from-outcome
 /flow-return

 and added a

 public String getReturnValue() {
 return /accueil;
 }

 method to he MinintFileContext bean, but it does not work better.

 Any idea ?


Try it again, maybe the reason is that it seems you are inside the
flow but it is not. You can check if you are in the flow using
facesContext.getApplication().getFlowHandler().isActive(...).

regards,

Leonardo Uribe

 Thanks in advance



 I have the following JSF-related or generic dependencies (I mean that I
 remove in-house dependencies from the following tree) :
 [INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @
 faces-dependencies ---
 [INFO] fr.senat:faces-dependencies:jar:4.0.0-SNAPSHOT
 [INFO] +- commons-lang:commons-lang:jar:2.6:compile
 [INFO] +- org.apache.commons:commons-lang3:jar:3.1:compile
 [INFO] +- org.apache.tomcat:tomcat-catalina:jar:7.0.47:provided
 [INFO] |  +- org.apache.tomcat:tomcat-servlet-api:jar:7.0.47:provided
 [INFO] |  +- org.apache.tomcat:tomcat-juli:jar:7.0.47:provided
 [INFO] |  +- org.apache.tomcat:tomcat-annotations-api:jar:7.0.47:provided
 [INFO] |  +- org.apache.tomcat:tomcat-api:jar:7.0.47:provided
 [INFO] |  \- org.apache.tomcat:tomcat-util:jar:7.0.47:provided
 [INFO] +- org.apache.myfaces.core:myfaces-api:jar:2.2.0:compile
 [INFO] +- org.apache.myfaces.core:myfaces-impl:jar:2.2.0:compile
 [INFO] |  +- commons-collections:commons-collections:jar:3.2:compile
 [INFO] |  +- commons-codec:commons-codec:jar:1.3:compile
 [INFO] |  +- commons-beanutils:commons-beanutils:jar:1.8.3:compile
 [INFO] |  |  \- commons-logging:commons

Re: StackOverflowError with MyFaces 2.2.0

[Leonardo Uribe]

Hi

The stack trace suggest there is a problem in the classpath. There
should be a copy of javax.faces api somewhere that is making a
conflict.

regards,

Leonardo Uribe

2014/1/22 Howard W. Smith, Jr. smithh032...@gmail.com:
 On Wed, Jan 22, 2014 at 1:50 PM, Mike Calmus m...@calmus.org wrote:

 I tried updating an existing application to MyFaces 2.2.0 (from 2.1.11) by
 simply replacing the library.


 Interesting. I'm sure that I could have migrated my app from MyFaces 2.1.11
 to myFaces 2.2.0, but I'm using TomEE, which has a nice home for MyFaces
 2.1.x (and MyFaces 2.2.x).

 Library = api and impl JAR

 or

 library = bundle JAR ?



 When I try to deploy the app, I get a StackOverflowError (below).


 Might be good for you to copy/paste your (entire) server log (on startup of
 server/app) to pastebin website or provide that in your next reply.

Re: JSF 2.2 Exit Flow

[Leonardo Uribe]

Hi

You can do what you want creating a custom ViewHandler and overriding
createView(...) method  like this:

@Override
public UIViewRoot createView(FacesContext context, String viewId)
{
UIViewRoot root = super.createView(context, viewId);
if (root != null)
{
FlowHandler flowHandler =
context.getApplication().getFlowHandler();
if (flowHandler.isActive(context, ,  flow1) 
!viewId.startsWith(/flow1/))
{
Flow flow = flowHandler.getFlow(context, , flow1);
flowHandler.transition(context, flow, null, null, viewId);
}
}
return root;
}

The code just check when the flow is active and if the view belongs to the
flow. If the navigation goes out of the flow it send a trasition ending the
flow.

Really this topic is being discussed under the EG, see:

https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1253

Let's see what happen.

regards,

Leonardo Uribe



2014/1/18 Gerhard Petracek gerhard.petra...@gmail.com

 hi geoffrey,

 just fyi (in addition to the answer from michael):
 that's one of the major use-cases we had for codi/deltaspike
 (grouped-)conversations.
 you can use a listener (or an observer for PreViewConfigNavigateEvent +
 custom view-config meta-data) which
 just calls (WindowContext#closeConversations in case of codi or
 GroupedConversationManager#closeConversations in case of deltaspike).

 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/1/18 Michael Kurz michi.k...@gmx.at

  Hi,
 
  as far as I know, this is currently not possible. JSF won't let you
  navigate to something that is not defined as a node in the current flow.
 I
  quickly talked to Ed Burns about this some time ago and he more or less
  confirmed that this is the case.
 
  Regards
  Michael
 
  Am 17.01.2014 02:10, schrieb Geoffrey Longo:
 
   I have an application that consists of a dropdown menu bar with many
 menu
  items.  Each menu item will initiate a new faces flow.  This is working
  correctly, however, once I am inside a flow, I would like any click on a
  menu item to exit the current flow, and then start a new one.  There are
  dozens of menu items in the application, so I was wondering if there is
 any
  way to have the current flow automatically exit when a menu item is
 clicked
  without having to define a flow-return for each menu item?
 
  Thanks,
  Geoff
 
 

Re: MyFaces 2.2.0 ViewScoped AmbiguousResolutionException

[Leonardo Uribe]

Hi

It looks like something not directly related to MyFaces, it is like if
the classpath is scanned twice, or like the bean is subscribed twice.
I suppose it is a bug in OWB or in TomEE. Maybe you should report it
in:

https://issues.apache.org/jira/browse/TOMEE

regards,

Leonardo Uribe

2014/1/15 José Luis Cetina maxtorz...@gmail.com:
 Hi. I use TomEE 1.6.0 Final release with myfaces 2.1.13 and jdk 1.7 with
 this i was using the org.omnifaces.cdi.ViewScoped annotation with any
 problem, with the new release of myfaces 2.2.0 i decide to change from
 org.omnifaces.cdi.ViewScoped to javax.faces.view.ViewScoped then im gettin
 this AmbiguousResolutionException.


 This error only happend in Linux environment, if i run the same project in
 Windows this error never appears.


 I removed my faces 2.1.13 jars (api and imp) from tomee lib and add myfaces
 api and impl 2.2.0


 What could be wrong?

 Log:

 javax.enterprise.inject.AmbiguousResolutionException: Ambiguous resolution
 found beans:
 ViewScopeBeanHolder, Name:null, WebBeans Type:MANAGED, API
 Types:[java.io.Serializable,java.lang.Object,org.apache.myfaces.cdi.view.ViewScopeBeanHolder],
 Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
 from 
 jar:file:/home/broncos/apache/tomee/apache-tomee-jaxrs-1.6.0/lib/myfaces-impl-2.2.0.jar!/org/apache/myfaces/cdi/view/ViewScopeBeanHolder.class
 ViewScopeBeanHolder, Name:null, WebBeans Type:MANAGED, API
 Types:[java.io.Serializable,java.lang.Object,org.apache.myfaces.cdi.view.ViewScopeBeanHolder],
 Qualifiers:[javax.enterprise.inject.Any,javax.enterprise.inject.Default]
 from 
 jar:file:/home/broncos/apache/tomee/apache-tomee-jaxrs-1.6.0/lib/myfaces-impl-2.2.0.jar!/org/apache/myfaces/cdi/view/ViewScopeBeanHolder.class
 
 org.apache.webbeans.util.InjectionExceptionUtil.throwAmbiguousResolutionExceptionForBeans(InjectionExceptionUtil.java:104)
 
 org.apache.webbeans.util.InjectionExceptionUtil.throwAmbiguousResolutionException(InjectionExceptionUtil.java:94)
 
 org.apache.webbeans.util.InjectionExceptionUtil.throwAmbiguousResolutionException(InjectionExceptionUtil.java:71)
 
 org.apache.webbeans.container.InjectionResolver.resolve(InjectionResolver.java:699)
 
 org.apache.webbeans.container.BeanManagerImpl.resolve(BeanManagerImpl.java:925)
 
 org.apache.webbeans.container.InjectableBeanManager.resolve(InjectableBeanManager.java:201)
 
 org.apache.myfaces.cdi.util.BeanProvider.getContextualReference(BeanProvider.java:413)
 
 org.apache.myfaces.cdi.util.BeanProvider.getContextualReference(BeanProvider.java:144)
 
 org.apache.myfaces.cdi.impl.CDIManagedBeanHandlerImpl.getViewScopeBeanHolder(CDIManagedBeanHandlerImpl.java:64)
 
 org.apache.myfaces.cdi.impl.CDIManagedBeanHandlerImpl.generateViewScopeId(CDIManagedBeanHandlerImpl.java:92)
 
 org.apache.myfaces.view.ViewScopeProxyMap.getWrapped(ViewScopeProxyMap.java:76)
 
 org.apache.myfaces.view.ViewScopeProxyMap.size(ViewScopeProxyMap.java:89)
 javax.faces.component.UIViewRoot.saveState(UIViewRoot.java:1498)
 
 org.apache.myfaces.renderkit.ErrorPageWriter._writeComponent(ErrorPageWriter.java:846)
 
 org.apache.myfaces.renderkit.ErrorPageWriter.debugHtml(ErrorPageWriter.java:351)
 
 org.apache.myfaces.renderkit.ErrorPageWriter.handle(ErrorPageWriter.java:470)
 
 org.apache.myfaces.context.MyFacesExceptionHandlerWrapperImpl.handle(MyFacesExceptionHandlerWrapperImpl.java:301)
 
 javax.faces.context.ExceptionHandlerWrapper.handle(ExceptionHandlerWrapper.java:61)
 
 org.omnifaces.exceptionhandler.FullAjaxExceptionHandler.handle(FullAjaxExceptionHandler.java:162)
 
 org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:287)
 javax.faces.webapp.FacesServlet.service(FacesServlet.java:198)

Re: [ANNOUNCE] MyFaces Core v2.2.0 Release

[Leonardo Uribe]

Hi Howard

2014/1/13 Howard W. Smith, Jr. smithh032...@gmail.com:
 Leonardo,

 Some questions for you:

 1. How has MyFaces 2.2 (beta) release been performing and/or accepted by
 MyFaces user community?


We have received some good feedback that has helped a lot to get the new
release.

 2. Any big corporation/names start using MyFaces 2.2 (beta) release yet?


If things goes like it was in 2.0, it still will take a couple of
releases so more
people start using fully the new artifacts, but since we are 2.2 I hope the
adoption will be faster.

 3. Does MyFaces 2.2 perform better than MyFaces 2.1.x (latest release)?


Yes, there are some improvements in session size / state management that
will help. From speed perspective, with the same flags enabled both perform
more or less the same.

 4. Do you think you will create 2 or 3 blog posts about MyFaces 2.2
 performance against Mojarra, Wicket, and Spring...like you did for MyFaces
 2.1.7?


Probably, but more as an update to keep track what has happened.

regards,

Leonardo Uribe

 Thanks,
 Howard


 On Mon, Jan 13, 2014 at 11:29 PM, Leonardo Uribe lu4...@apache.org wrote:

 The Apache MyFaces team is pleased to announce the release of MyFaces
 Core 2.2.0.

Re: [core] What's new in MyFaces 2.2

[Leonardo Uribe]

Hi

2014/1/13 Howard W. Smith, Jr. smithh032...@gmail.com:
 Wow, interesting that you sent this email as I was writing my email, asking
 a few questions bout MyFaces 2.2.

 Your other posts about MyFaces 2.1.14 (and 2.0.20) inspired/motivated me to
 think about MyFaces 2.2. I am considering migrating my app from MyFaces
 2.1.x to 2.2. I think I tested/ran my app already with MyFaces 2.2, and
 since the last time that I tested/used myFaces 2.2, I have no
 issues/defects to report. Just have not pushed MyFaces 2.2 to my production
 environment yet.


The changes included in JSF 2.2 does not make any conflict with 2.0 / 2.1 code.
The migration step from 2.1 to 2.2 is very simple, just replace the
jars and that's
it. There are some differences like for example the view scope beans are now
stored in session and if CDI is enabled, view scope is managed by CDI.

Additionally, there wasn't any change that affect the behavior significantly in
JSF 2.2, so the code looks very stable. It were also included a lot of
junit tests
for the new features to ensure everything works as expected, which reduces
in the long term the occurrence of bugs and provides a better code quality.

 I wanted to wait and hear a bit more from the community about it, but (LOL)
 that's the thing, there are not many questions at all on MyFaces user list.
 Evidently, it just works! :)



 On Mon, Jan 13, 2014 at 11:42 PM, Leonardo Uribe lu4...@apache.org wrote:

 Hi

 For the people who want to know quickly what's new in MyFaces 2.2, I
 have written a summary of the new features here:

 http://lu4242.blogspot.com/2014/01/whats-new-in-myfaces-22.html

 regards,

 Leonardo Uribe

[ANNOUNCE] MyFaces Core v2.0.20 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces
Core 2.0.20.MyFaces Core is a JavaServer(tm) Faces 2.0 implementation
as specified by JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and
is 100% compliant with the JSR-314 specification. MyFaces Core 2.0.20
is available in both binary and source distributions.*
http://myfaces.apache.org/download.htmlMyFaces Core is also available
in the central Maven repository under Group ID
org.apache.myfaces.core.Bug[MYFACES-3835] - ViewState gets
truncated on chrome with richfaces fileupload component
[MYFACES-3836] - f:ajax disabled=false in commandButton with onclick
prevents form submission[MYFACES-3837] - ui:debug renders an amp;
but it should be  because the markup is inside a CDATA sectionTask
[MYFACES-3827] - Replace .xsd with the ones from geronimo or written
from scratchregards,Leonardo Uribe

[ANNOUNCE] MyFaces Core v2.1.14 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces
Core 2.1.14.

MyFaces Core is a JavaServer(tm) Faces 2.1 implementation as specified
by JSR-314. MyFaces Core has passed Sun's JSR-314 TCK and is 100%
compliant with the JSR-314 specification.

MyFaces Core 2.1.14 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under
Group ID org.apache.myfaces.core.

Bug

[MYFACES-3829] - alwaysRecompile logged as wrong value for
org.apache.myfaces.CACHE_EL_EXPRESSIONS on startup
[MYFACES-3831] - CacheELFaceletCacheImpl is not storing the
compiled template (only when alwaysRecompile is enabled)
[MYFACES-3835] - ViewState gets truncated on chrome with richfaces
fileupload component
[MYFACES-3836] - f:ajax disabled=false in commandButton with
onclick prevents form submission
[MYFACES-3837] - ui:debug renders an amp; but it should be 
because the markup is inside a CDATA section

Task

[MYFACES-3827] - Replace .xsd with the ones from geronimo or
written from scratch

regards,

Leonardo Uribe

[ANNOUNCE] MyFaces Core v2.2.0 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces
Core 2.2.0.

MyFaces Core is a JavaServer(tm) Faces 2.2 implementation as specified
by JSR-344.

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

MyFaces Core 2.2.0 is available in both binary and source distributions.

* http://myfaces.apache.org/download.html

MyFaces Core is also available in the central Maven repository under
Group ID org.apache.myfaces.core.

Bug

[MYFACES-3820] - UIInput.setSubmittedValue() cause recursive call
when calling getSubmittedValue() on Debug
[MYFACES-3821] - Implement UIData.setDataModel(...)
[MYFACES-3824] - @FlowScope with no defining documentId set cannot
found active flow with explicit documentId
[MYFACES-3829] - alwaysRecompile logged as wrong value for
org.apache.myfaces.CACHE_EL_EXPRESSIONS on startup
[MYFACES-3830] - Component created using @FacesComponent with
createTag=true and @ResourceDependency makes initialization fail
[MYFACES-3831] - CacheELFaceletCacheImpl is not storing the
compiled template (only when alwaysRecompile is enabled)
[MYFACES-3832] - disableClientWindow is not fully implemented
[MYFACES-3834] - Restore
org.apache.myfaces.config.impl.digester.elements.FacesConfig to avoid
tomee integration to fail
[MYFACES-3835] - ViewState gets truncated on chrome with richfaces
fileupload component
[MYFACES-3836] - f:ajax disabled=false in commandButton with
onclick prevents form submission
[MYFACES-3837] - ui:debug renders an amp; but it should be 
because the markup is inside a CDATA section
[MYFACES-3838] - LegacyUserTagHandler should implement
ComponentContainerHandler
[MYFACES-3839] - Relative implicit link not found when it
reference parent nodes.

Improvement

[MYFACES-3804] - Use the same key in server side state saving for
ajax requests
[MYFACES-3806] - Destroy ViewScope beans when view is discarded
from view state.
[MYFACES-3815] - Lazy instantiation of Renderer classes
[MYFACES-3819] - Allow override resource components using a tag handler
[MYFACES-3823] - [perf] use a preinitialized table of unique ids
for UIViewRoot.createUniqueId(...)
[MYFACES-3825] - [perf] Cache EL expressions using an indirection
for ui:param and user tag attributes
[MYFACES-3828] - [perf] Do not store the namespace into state for
dynamic components

New Feature

[MYFACES-3664] - JSF View Pooling (going beyond JSF Stateless Mode)

Task

[MYFACES-3647] - remove JspStateManagerImpl and other unused stuff
in this area
[MYFACES-3715] - Remove unnecessary parameters or features from
earlier versions in MyFaces 2.2
[MYFACES-3809] - Add http://java.sun.com/jstl/core as a valid
namespace for c jstl library in facelets
[MYFACES-3810] - Add compatibility mode for facelets 1.1.x behavior
[MYFACES-3811] - Fix c:forEach behavior once for all
[MYFACES-3812] - Cleanup Facelets Initialization Code and decouple
facelets taglibrary config parsing
[MYFACES-3813] - Cleanup
org.apache.myfaces.config.impl.digester.elements package
[MYFACES-3814] - Allow ServiceProviderFinder to be initialized at startup
[MYFACES-3818] - Unify behavior of composite component renderer
[MYFACES-3822] - General cleanup and remove unused web config params
[MYFACES-3826] - Add junit test case for MyFaces and CDI
[MYFACES-3827] - Replace .xsd with the ones from geronimo or
written from scratch

regards,

Leonardo Uribe

[core] What's new in MyFaces 2.2

[Leonardo Uribe]

Hi

For the people who want to know quickly what's new in MyFaces 2.2, I
have written a summary of the new features here:

http://lu4242.blogspot.com/2014/01/whats-new-in-myfaces-22.html

regards,

Leonardo Uribe

Re: [TomEE/MyFaces 2.1.13] SocketTimeoutException thrown by ResourceHandlerImpl handleResourceRequest

[Leonardo Uribe]

Hi Howard

I think it should work with:

org.apache.myfaces.application.ResourceHandlerImpl.level = OFF

regards,

Leonardo

2014/1/7 Howard W. Smith, Jr. smithh032...@gmail.com:
 Leonardo,

 On Tue, Nov 12, 2013 at 10:45 PM, Leonardo Uribe lu4...@gmail.com wrote:

 The exception
 was added in the log on:

 https://issues.apache.org/jira/browse/MYFACES-3736

 I have checked it and there is no evidence of an error from MyFaces side.

 Maybe we can do something to hide the exception, printing it only if
 Level.FINE is set.


 In the meanwhile, what is the best way to prevent this exception from
 appearing in my (tomee+) log file? can i disable it via logging.properties
 via the following?

 org.apache.myfaces.application.ResourceHandlerImpl.level = WARNING

Re: [Tomahawk] New Release

[Leonardo Uribe]

Hi

With the introduction on JSF 2.2, over the last year all efforts of MyFaces
committers has been put on get a release of 2.2.0 branch, which is
relatively close, but it has taken a lot of effort to get it done.

The hope is after 2.2.0 the community will focus on other MyFaces projects,
including MyFaces Tomahawk. Since this is an open source project, the
evolution of the project depends on the contributions and interests of the
members of the comunity, so any contribution on this regard is most welcome.

regards,

Leonardo Uribe


2013/12/18 andreas.schm...@hella.com andreas.schm...@hella.com

 Hello,

 I'm using myFaces in combination with tomahawk for a while. I wonder if
 there are any plans to release a new version of tomahawk. The latest
 release
 is - I think - over one year old and even this release does not contain any
 interessting new components that did not exist in the version for myfaces
 1.2/1.2.

 Best regards
 Andreas




 --
 View this message in context:
 http://myfaces.10567.n7.nabble.com/Tomahawk-New-Release-tp116784.html
 Sent from the MyFaces - Users mailing list archive at Nabble.com.

Re: [TomEE/MyFaces 2.1.13] SocketTimeoutException thrown by ResourceHandlerImpl handleResourceRequest

[Leonardo Uribe]

Hi

Thanks to provide the link of the discussion in tomcat list. The exception
was added in the log on:

https://issues.apache.org/jira/browse/MYFACES-3736

I have checked it and there is no evidence of an error from MyFaces side.

Maybe we can do something to hide the exception, printing it only if
Level.FINE is set.

regards,

Leonardo Uribe



2013/11/11 Howard W. Smith, Jr. smithh032...@gmail.com

 FYI,

 On Sun, Nov 10, 2013 at 8:29 AM, Howard W. Smith, Jr. 
 smithh032...@gmail.com wrote:

  more on this topic...


 Discussed on the tomcat list:

 Avoiding/Handling SocketTimeoutException(s) when web application serving
 resources to mobile clients[1]


 [1]

 http://tomcat.10.x6.nabble.com/Avoiding-Handling-SocketTimeoutException-s-when-web-application-serving-resources-to-mobile-clients-td5007700.html

Re: Performance params

[Leonardo Uribe]

Hi Kito

2013/10/31 Kito Mann kito.m...@virtua.com

 Hello everyone,

 I have a couple of questions about performance parameters:

 · org.apache.myfaces.SUPPORT_JSP_AND_FACES_EL

 How significant is the performance improvement for a Facelet page if this
 is turned off?


This param avoids execute JSF 1.0 EL code, and disable jsp vdl, so EL
expressions runs faster. The effect in performance is small but noticeable.


 · org.apache.myfaces.VIEW_UNIQUE_IDS_CACHE_ENABLED

 If I understand this correctly, this is only useful after a specific user
 has already reached the maximum number of views stored in the session, or
 am I missing something?


This flag enables ids storage at facelet handler level. The effect is it
increase
the size of the compiled facelet in memory (because all generated ids for
the compiled facelet are stored in that level) but it gives a significant
performance
improvement in both memory and speed. In 2.1.x/2.0.x it is disabled by
default,
but in 2.2.x the idea is enable it by default, because there are no side
effects,
and the current code has been well tested.

regards,

Leonardo Uribe

___

 Kito D. Mann | @kito99 | Author, JSF in Action
 Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
 http://www.JSFCentral.com | @jsfcentral
 +1 203-998-0403

 * Listen to the Enterprise Java Newscast:
 *http://whttp://blogs.jsfcentral.com/JSFNewscast/
 ww.enterprisejavanews.com*
 * JSFCentral Interviews Podcast:
 http://www.jsfcentral.com/resources/jsfcentralpodcasts/
 * Sign up for the JSFCentral Newsletter:
 http://oi.vresp.com/?fid=ac048d0e17

[ANNOUNCE] MyFaces Test v1.0.5 Release

[Leonardo Uribe]

The Apache MyFaces team is pleased to announce the release of MyFaces Test
1.0.5.

The Myfaces Test Framework provides mock object libraries, plus base
classes for creating your own JUnit TestCases for JSF.

For more information please see: http://myfaces.apache.org/test

MyFaces Core is available in the central Maven repository under Group ID
org.apache.myfaces.test.

Release Notes - MyFaces Test - Version 1.0.5

Task

[MYFACESTEST-63] - Add JSF 2.2 branch for MyFaces Test

regards,

Leonardo Uribe