HtmlCheckboxRendererBase with XHTML output bug?

[Martin Koci]

Hi,
I'm using current codebase with ADF Faces (open source donation) and 
with jspx (XHTML output).


There is problem with HtmlCheckboxRendererBase, line 257, code is:

writer.writeText("", null); // close input

It renderes incorrect XHTML:  is not closed with />

It can be solved with changing

writer.writeText("", null); // close input

to

writer.endElement(HTML.INPUT_ELEM);

which is more correct, I think.

Is this a bug ?

Thanks,

Martin



--
Mgr. Martin Kočí
-
AURA, s.r.o.
Úvoz 499/56; 602 00 Brno
ISO 9001 certifikovaná společnost
tel./fax: +420 5 43 24 51 11
e-mail:  [EMAIL PROTECTED]
internet: http://www.aura.cz
http://www.j2ee.cz
- 

Is implementation of org.apache.myfaces.shared.renderkit.html.HtmlMessagesRendererBase$MessagesIterator correct?

[Martin Koci]

Hello,

I'm writing custom messages renderer and found strange (for me) behavior 
of MessagesIterator:


JSF spec: globalOnly: Flag indicating whether only messages not 
associated with any specific component should be rendered. If not set, 
ALL messages will be rendered. Default value is “false”



public MessagesIterator(FacesContext facesContext, boolean globalOnly)
{
_facesContext = facesContext;
if (globalOnly)
{
// JSF spec: The getMessages(String) method returns an Iterator over 
queued Messages

// those associated with no client identifier if the parameter is null
// OK - if globalOnly is true we have only messages not attached to 
component

_globalMessagesIterator = facesContext.getMessages(null);

_clientIdsWithMessagesIterator = NullIterator.instance();
}
else // globalOnly = false
{
// ??? NO global messages? JSF spec: If not set, ALL messages will be 
rendered!
_globalMessagesIterator = 
org.apache.myfaces.shared.util.NullIterator.instance();


// ??? - we obtain only ids with messages but NO global messages 
iterator. But spec says: if globalOnly false (or not set) ALL messages 
will be rendered.

_clientIdsWithMessagesIterator = facesContext.getClientIdsWithMessages();
}
_componentMessagesIterator = null;
_clientId = null;
}

Thanks for info,

Martin

--
Mgr. Martin Kočí
-
AURA, s.r.o.
Úvoz 499/56; 602 00 Brno
ISO 9001 certifikovaná společnost
tel./fax: +420 5 43 24 51 11
e-mail:  [EMAIL PROTECTED]
internet: http://www.aura.cz
http://www.j2ee.cz
- 

[Trinidad] MessageFactory.BindingFacesMessage resolves parameters only once

[Martin Koci]

Hi,

I probably found a problem  with BindingFacesMessage class. If calling
getMessage() it resolves value binding only once and then cache it. I
think values should be resolved every time as normal ValueBinding or
ValueExpressing does - calling getValue(context) creates a new value
every time; but BindingFacesMessage returns still same value (which can
be pretty old and unactual). 

How did I find the problem:

- in my converter I added logger - its logging converter message in
place where it occurs

- calling message.getSummary() resolves label of component to null,
because loadBundle is not loaded in process validation phase

- in message renderer: it call message.getSummary() too but it return
message with cached, null label. But there - in render response  phase -
label is null no more, because bundles loaded with f:loadBundle already
exist!


I fixed it locally with:
private void _resolveBindings()
{
  //if (_resolvedParameters == null)
  //{
_resolvedParameters = _getProcessedBindings(null, _parameters);
  //}
}

What do you think?


Regards, 

Martin Koci

Re: [Trinidad] MessageFactory.BindingFacesMessage resolves parameters only once

[Martin Koci]

https://issues.apache.org/jira/browse/TRINIDAD-28


Adam Winer píše v Pá 18. 05. 2007 v 10:55 -0700:
> Yeah, looks like a good fix.  I doubt the optimization of caching
> here is buying us much of anything.
> 
> -- Adam
> 
> 
> On 5/17/07, Martin Koci < [EMAIL PROTECTED]> wrote:
> Hi,
> 
> I probably found a problem  with BindingFacesMessage class. If
> calling 
> getMessage() it resolves value binding only once and then
> cache it. I
> think values should be resolved every time as normal
> ValueBinding or
> ValueExpressing does - calling getValue(context) creates a new
> value
> every time; but BindingFacesMessage returns still same value
> (which can
> be pretty old and unactual).
> 
> How did I find the problem:
> 
> - in my converter I added logger - its logging converter
> message in
> place where it occurs 
> 
> - calling message.getSummary() resolves label of component to
> null,
> because loadBundle is not loaded in process validation phase
> 
> - in message renderer: it call message.getSummary() too but it
> return
> message with cached, null label. But there - in render
> response  phase - 
> label is null no more, because bundles loaded with
> f:loadBundle already
> exist!
> 
> 
> I fixed it locally with:
> private void _resolveBindings()
> {
>   //if (_resolvedParameters == null)
>   //{ 
> _resolvedParameters = _getProcessedBindings(null,
> _parameters);
>   //}
> }
> 
> What do you think?
> 
> 
> Regards,
> 
> Martin Koci
> 
> 
> 
> 
> 
> 
> 
> 

[Trinidad] Auto-scroll feature with trinidad

[Martin Koci]

Hi all,

we discussed that topic already: http://www.mail-archive.com/[EMAIL 
PROTECTED]/msg01039.html


New thoughts about that? Trinidad is out of incubator - we can find one
solution for myfaces-impl & tomahawk & trinidad now.


Regards, 

Martin 

[Trinidad] upload file and UTF-8

[Martin Koci]

Hello,


there is a problem with utf-8 encoding and UploadRequestWrapper in
method setCharacterEncoding. We are using UTF-8 to support Czech
language (and others),  but it doesnt work with file upload - it decodes
request as in iso latin 1.

(Following example can be unreadable in some email clients: test string
"čeština ěěššččřřžžýýááííéé" becomes "eatina aa YY~~���").


I dont know why but sometimes is encoding "utf-8" and sometimes "UTF-8".

 Then 'if' code :

// If the encoding is already right, we can bail
if (encoding.equals(_encoding))
  return;

will not pass and UploadRequestWrapper will decode request as iso latin1
request.


I fixed it locally with:

// If the encoding is already right, we can bail
if (encoding.equalsIngnoreCase(_encoding))
  return;


but Id don't know where the problem really is.


What do you think?


Regards,


Martin Kočí

[core] ClassLoaderResourceLoader.getLibraryVersion(String) performace

[Martin Koci]

Hi,

during  profiling YourKitProfiler always marks
org.apache.myfaces.resource.ClassLoaderResourceLoader.getLibraryVersion(String) 
as hotspot - that method always takes 30--50% CPU time per one 
request/response. Is it a known problem? I will provide more information later.

Regards,

Martin Kočí

Re: [core] ClassLoaderResourceLoader.getLibraryVersion(String) performace

[Martin Koci]

I can confirm that problem was really in getLibraryVersion() - after few
hours of profiling (with simulation of 10 concurrent users) profiler
shows that JarEntry.nextElement() in was called over 300 000 000 times
(!) and getLibraryVersion() was total winner in cumulative time category
within org.apache packages.

Now with current trunk problem is gone and database queries are again my
prime time hogs ;-) 

Thanks,

Martin Kočí

Matthias Wessendorf píše v Pá 05. 02. 2010 v 18:20 +0100:
> Ah, ok :)
> 
> I am interested in what Martin comes up, regarding details.
> Hopefully it is only "getLibraryVersion(...)" ;-)
> 
> -Matthias
> 
> On Fri, Feb 5, 2010 at 6:09 PM, Leonardo Uribe  wrote:
> > Hi
> >
> > The code that serve resources on myfaces core comes from trinidad. There was
> > also other parts that comes from there too.
> >
> > Leonardo Uribe
> >
> > 2010/2/5 Matthias Wessendorf 
> >>
> >> -hi,
> >>
> >> has one checked what Trinidad is offering for that ?
> >> I mean the code is pretty old (and therefore stable).
> >> Also at Oracle there is quite some PREF testing done...
> >>
> >> -Matthias
> >>
> >> On Fri, Feb 5, 2010 at 5:38 PM, Leonardo Uribe  wrote:
> >> > Hi
> >> >
> >> > Created MYFACES-2538 Remove resourceVersion and libraryVersion from
> >> > resource
> >> > identifiers.
> >> >
> >> > regards,
> >> >
> >> > Leonardo Uribe
> >> >
> >> > 2010/2/5 Leonardo Uribe 
> >> >>
> >> >> Hi
> >> >>
> >> >> Yes, that one is a big problem. There is no way to "traverse" a jar
> >> >> file
> >> >> without iterating over all entries to get the library version and
> >> >> resource
> >> >> version. That means the current algorithm do that all times a resource
> >> >> is
> >> >> rendered. This is really bad.
> >> >>
> >> >> I remember someone commented that on jsr-314-open at jcp.org mailing
> >> >> list,
> >> >> and checking the latest ri code (2.0.2-b10), library and resource
> >> >> version
> >> >> feature was removed. It seems a decision was taken there.
> >> >>
> >> >> Checking more, the topic describing this is:
> >> >>
> >> >> [jsr-314-open] Need guidance: invalid assumptions in design of resource
> >> >> versioning feature
> >> >>
> >> >> We should change our algorithm too to prevent this performance problem.
> >> >>
> >> >> regards,
> >> >>
> >> >> Leonardo Uribe
> >> >>
> >> >> 2010/2/5 Martin Koci 
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> during  profiling YourKitProfiler always marks
> >> >>>
> >> >>>
> >> >>> org.apache.myfaces.resource.ClassLoaderResourceLoader.getLibraryVersion(String)
> >> >>> as hotspot - that method always takes 30--50% CPU time per one
> >> >>> request/response. Is it a known problem? I will provide more
> >> >>> information
> >> >>> later.
> >> >>>
> >> >>> Regards,
> >> >>>
> >> >>> Martin Kočí
> >> >>>
> >> >>>
> >> >>>
> >> >>>
> >> >>
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Matthias Wessendorf
> >>
> >> blog: http://matthiaswessendorf.wordpress.com/
> >> sessions: http://www.slideshare.net/mwessendorf
> >> twitter: http://twitter.com/mwessendorf
> >
> >
> 
> 
> 

[core] Status of state saving implementation in current trunk

[Martin Koci]

Hello,

what is the current status of state saving implementation in myfaces
core trunk? Is it a "work in progress" or should it work? 
For example I noticed that server state saving with facelets is
completely broken (FaceletViewDeclarationLanguage calls
stateMgr.saveView only for client state saving) - should I write jira
issue or somebody is working on it?

Regards,

Martin Kočí

Re: [core] Status of state saving implementation in current trunk

[Martin Koci]

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

Leonardo Uribe píše v Po 08. 02. 2010 v 21:35 -0500:
> Hi
> 
> It should work. If something does not, just create an issue and I'll
> take a look at it. I think in this case there are some differences
> between client side and server side state saving but both should work.
> 
> regards,
> 
> Leonardo Uribe
> 
> 2010/2/8 Martin Koci 
> Hello,
> 
> what is the current status of state saving implementation in
> myfaces
> core trunk? Is it a "work in progress" or should it work?
> For example I noticed that server state saving with facelets
> is
> completely broken (FaceletViewDeclarationLanguage calls
> stateMgr.saveView only for client state saving) - should I
> write jira
> issue or somebody is working on it?
> 
> Regards,
> 
> Martin Kočí
> 
> 

[core] Code formatter setting for myfaces core (for Eclipse)

[Martin Koci]

Hi,

can you please point me to a description how to set code formatting
which conforms check style rules? Or better - is there a public settings
for eclipse formatter (it is a file named org.eclipse.jdt.core.prefs
from .settings directory)?

Thanks,

Martin Kočí 

Re: [core] Code formatter setting for myfaces core (for Eclipse)

[Martin Koci]

Thanks,

that's very useful. Question regarding logging: WIKI page says that
commons-logging is used. Is it still valid statement? 

Jakob Korherr píše v Út 09. 02. 2010 v 14:36 +0100:
> Hi Martin,
> 
> see http://wiki.apache.org/myfaces/MyFaces_Developer_Notes for
> details.
> 
> Regards,
> Jakob
> 
> 2010/2/9 Martin Koci 
> Hi,
> 
> can you please point me to a description how to set code
> formatting
> which conforms check style rules? Or better - is there a
> public settings
> for eclipse formatter (it is a file named
> org.eclipse.jdt.core.prefs
> from .settings directory)?
> 
> Thanks,
> 
> Martin Kočí
> 
> 

[core] converterId/validatorId and binding

[Martin Koci]

Hi,


there is probably a unclarity regarding cooperation of
converterId/validatorId and binding attributes from f:converter and
f:validator facelets tags.
https://javaserverfaces.dev.java.net/nonav/docs/2.0/pdldocs/facelets/f/converter.html
 says that converterId is not required, same for validatorId. 

I didn't find what should happen if user does not specify converterId
and binding leads to null object. Simple test page


  


confirms that this is mystery for mojarra developers too - it throws
javax.faces.view.facelets.TagException: /test.xhtml @10,54 
Default behavior invoked of requiring a converter-id passed in the
constructor, must override ConvertHandler(ConverterConfig)


Specification does not speak about facelets tag directly but 9.4.5
 (for JSP) contains this text:

"The createConverter() method must:

If binding is non-null, call binding.getValue() to obtain a reference to
the Converter instance. If there is no exception thrown, and
binding.getValue() returned a non-null object that implements
javax.faces.convert.Converter, register it by calling setConverter(). If
there was an exception thrown, rethrow the exception as a JspException.
Use the converterId attribute if the converter instance could not be
created from the binding attribute. If the converterId attribute is set,
call the createConverter() method of the Application instance for this
application, passing converter id specified by their converterId
attribute. If the binding attribute was also set, store the converter
instance by calling binding.setValue(). Register the converter instance
by calling setConverter(). If there was an exception thrown, rethrow the
exception as a JspException."

Please notice the sentence "If the converterId attribute is set". I
suggest to follow this behavior in ConvertDelegateHandler and log a
warning or add a FacesMessage in develelopment mode if user uses
f:converter tag without converterId and with null binding (same for
f:validator).

Regards,

Martin Kočí

Related issue: https://issues.apache.org/jira/browse/MYFACES-2536

Re: [VOTE] release for myfaces core 2.0.1

[Martin Koci]

Hi,

can you  guys take a look at
https://issues.apache.org/jira/browse/MYFACES-2753 before release
2.0.1? 

Thanks,

Martin Kočí

Werner Punz píše v Út 06. 07. 2010 v 18:07 +0200:
> Jepp there were a handful of showstoppers, most have been fixed (but not 
> all)
> I am glad 2.0.1 did not make it out of the door, this gave us additional 
> time to fix the bugs which have crawled up lately.
> 
> 
> Werner
> 
> 
> Am 06.07.10 00:48, schrieb Leonardo Uribe:
> > Hi
> >
> > Yes, the vote has been stopped. In the last weeks we have found some
> > issues, so it is necessary to fix them before propose another release.
> >
> > regards,
> >
> > Leonardo Uribe
> >
> > 2010/7/5 Matthias Wessendorf mailto:mat...@apache.org>>
> >
> > Hi,
> >
> > I was out for a bit, and was wondering if this vote has now been
> > officially stopped ?
> >
> > Thanks!
> > Matthias
> >
> > On Wed, Jun 16, 2010 at 12:00 PM, Leonardo Uribe  > > wrote:
> >  > Hi
> >  >
> >  > That's cool! Thanks!. After release myfaces master pom v 8 I'll
> > propose a
> >  > release of 2.0.1 again.
> >  >
> >  > regards,
> >  >
> >  > Leonardo
> >  >
> >  > 2010/6/16 Michael Concini  > >
> >  >>
> >  >> Leonardo,
> >  >> I just committed the proper fix for MYFACES-2754 now so as far
> > as 2754 and
> >  >> 2755 we should be good to go.
> >  >>
> >  >> -Mike
> >  >> On 6/16/2010 1:52 PM, Leonardo Uribe wrote:
> >  >>
> >  >> Hi Bernd
> >  >>
> >  >> Ok, thanks. Unfortunately I have to restart all release steps,
> > because
> >  >> there was changes applied on trunk that should be applied, but
> > I'm not have
> >  >> a separate patch to apply it (MYFACES-2755, MYFACES-2754 is in
> > progress,
> >  >> TOMAHAWK).
> >  >>
> >  >> We still have an unresolved problem with myfaces master pom v7
> > (checkstyle
> >  >> version is snapshot). Since myfaces core 2.0.x depends on this
> > pom and we
> >  >> don't have response from Matthias fix this issue, At this point
> > I have to
> >  >> release myfaces master pom first.
> >  >>
> >  >> regards,
> >  >>
> >  >> Leonardo Uribe
> >  >>
> >  >> 2010/6/16 Bernd Bohmann  > >
> >  >>>
> >  >>> Hi Leonardo,
> >  >>>
> >  >>> thanks a lot. Now it is ok for me.
> >  >>> I added some missing licenses on the 2.0.1 branch.
> >  >>>
> >  >>> Regards
> >  >>>
> >  >>> Bernd
> >  >>>
> >  >>>
> >  >>>
> >  >>> On Tue, Jun 15, 2010 at 11:14 PM, Leonardo Uribe
> > mailto:lu4...@gmail.com>>
> >  >>> wrote:
> >  >>> > Hi Bernd
> >  >>> >
> >  >>> > I added in api:
> >  >>> >
> >  >>> > META-INF/licenses/dojo-LICENSE.TXT
> >  >>> > META-INF/licenses/j4fry-LICENSE.TXT
> >  >>> > META-INF/licenses/facelets-LICENSE.TXT
> >  >>> >
> >  >>> > in impl
> >  >>> >
> >  >>> > META-INF/licenses/glassfish-LICENSE.TXT
> >  >>> > META-INF/licenses/facelets-LICENSE.TXT
> >  >>> >
> >  >>> > because the schemas with CDDL license are on impl jar.
> >  >>> >
> >  >>> > The update to NOTICE.txt message was committed too. Anyway to
> > prevent
> >  >>> > misunderstandings, I'll wait your response about it.
> >  >>> >
> >  >>> > regards,
> >  >>> >
> >  >>> > Leonardo Uribe
> >  >>> >
> >  >>> > 2010/6/15 Bernd Bohmann  > >
> >  >>> >>
> >  >>> >> Hello Leonardo,
> >  >>> >>
> >  >>> >> looks ok for me.
> >  >>> >>
> >  >>> >> Can you also add in api
> >  >>> >>
> >  >>> >> META-INF/licenses/dojo-LICENSE.TXT
> >  >>> >> META-INF/licenses/j4fry-LICENSE.TXT
> >  >>> >> META-INF/licenses/glassfish-LICENSE.TXT
> >  >>> >> META-INF/licenses/facelets-LICENSE.TXT
> >  >>> >>
> >  >>> >> and in impl
> >  >>> >>
> >  >>> >> META-INF/licenses/facelets-LICENSE.TXT
> >  >>> >>
> >  >>> >> an example would be
> >  >>> >>
> >  >>> >>
> >  >>> >>
> > 
> > http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/core/src/main/resources/META-INF/licenses/
> >  >>> >>
> >  >>> >> I have no time to perform the required changes unit tomorrow
> >  >>> >> afternoon.
> >  >>> >>
> >  >>> >> Regards
> >  >>> >>
> >  >>> >> Bernd
> >  >>> >>
> >  >>> >> On Tue, Jun 15, 2010 at 8:11 PM, Leonardo Uribe
> > mailto:lu4...@gmail.com>>
> >  >>> >> wrote:
> >  >>> >> > Hi
> >  >>> >> >
> >  >>> >> > I think the NOTICE.txt file on impl module could be like this:
> >  >>> >> >
> >  >>> >> > This product includes software developed by:
> >  >>> >> > The Apache Software Foundation (http://www.apache.org/).
> >  >>> >> >
> >  >>> >> >
> >  >>> >> 

ValidatorHandler and "wire all attributes set to the Validator instance"

[Martin Koci]

Hi,

javadoc for javax.faces.view.facelets.ValidatorHandler contains this
sentence:

"Will wire all attributes set to the Validator instance
created/fetched". Based on that one our developer tried this:



Expected result was to put a value into validator via setter
setProperty(). But "all attributes set" means binding, for,
disabled, ... only the specified ones, right?

Thanks,


Martin Kočí 

Myfaces vs. mojarra restore view performance

[Martin Koci]

Hi,

our profiling results show that myfaces are significantly slower in
restore view phase:

com.sun.faces LifeCycle .. restoreView : 80 ms

o.a.m.RestoreViewExecutor : 750ms! 

This result is perfectly reproducible in our case. I profile it on a
application real application  - I cannot post test case here. 

Configuration: myfaces or mojarra from trunk, partial state saving, a
view with more than 200 UIInput components.


Is it a known problem? I will provide more detailed profiling results
later.

Regards,

Martin Kočí

Re: Myfaces vs. mojarra restore view performance

[Martin Koci]

Hi,

quick results: yourkitprofiler marks as hot spot
UiViewRoot.addComponentResource (3381 invocation count) - that method
itself creates 5 710 511 invocations of AbstractIterator.next() 

Reason probably is that I have  custom renderer for UInput with
@ResourceDependencies(...many @ResourceDependecy here).

All invocations comes from
org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply 
recursively during restore view - VDL.buildView. 

Solution: @ResourceDependencies is static structure and cannot change
during lifecycle - call addComponentResource for particular type of
component (renderer, validator, ...) only once per one lifecycle ?


Thanks,

Martin Kočí

Jan-Kees van Andel píše v Po 02. 08. 2010 v 19:18 +0200:
> Hey,
> 
> 
> I'm very interested in the details behind those 750ms. Can you post
> the hotspots? Like: number of invocations, ms. self time and ms. total
> time.
> 
> 
> Thanks.
> 
> 
> Regards,
> Jan-Kees
> 
> 
> 2010/8/2 Martin Koci 
> Hi,
> 
> our profiling results show that myfaces are significantly
> slower in
> restore view phase:
> 
> com.sun.faces LifeCycle .. restoreView : 80 ms
> 
> o.a.m.RestoreViewExecutor : 750ms!
> 
> This result is perfectly reproducible in our case. I profile
> it on a
> application real application  - I cannot post test case here.
> 
> Configuration: myfaces or mojarra from trunk, partial state
> saving, a
> view with more than 200 UIInput components.
> 
> 
> Is it a known problem? I will provide more detailed profiling
> results
> later.
> 
> Regards,
> 
> Martin Kočí
> 
> 
> 
> 
> 
> 
> 

Re: Myfaces vs. mojarra restore view performance

[Martin Koci]

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

Martin Koci píše v Po 02. 08. 2010 v 22:20 +0200:
> Hi,
> 
> quick results: yourkitprofiler marks as hot spot
> UiViewRoot.addComponentResource (3381 invocation count) - that method
> itself creates 5 710 511 invocations of AbstractIterator.next() 
> 
> Reason probably is that I have  custom renderer for UInput with
> @ResourceDependencies(...many @ResourceDependecy here).
> 
> All invocations comes from
> org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply 
> recursively during restore view - VDL.buildView. 
> 
> Solution: @ResourceDependencies is static structure and cannot change
> during lifecycle - call addComponentResource for particular type of
> component (renderer, validator, ...) only once per one lifecycle ?
> 
> 
> Thanks,
> 
> Martin Kočí
> 
> Jan-Kees van Andel píše v Po 02. 08. 2010 v 19:18 +0200:
> > Hey,
> > 
> > 
> > I'm very interested in the details behind those 750ms. Can you post
> > the hotspots? Like: number of invocations, ms. self time and ms. total
> > time.
> > 
> > 
> > Thanks.
> > 
> > 
> > Regards,
> > Jan-Kees
> > 
> > 
> > 2010/8/2 Martin Koci 
> > Hi,
> > 
> > our profiling results show that myfaces are significantly
> > slower in
> > restore view phase:
> > 
> > com.sun.faces LifeCycle .. restoreView : 80 ms
> > 
> > o.a.m.RestoreViewExecutor : 750ms!
> > 
> > This result is perfectly reproducible in our case. I profile
> > it on a
> > application real application  - I cannot post test case here.
> > 
> > Configuration: myfaces or mojarra from trunk, partial state
> > saving, a
> > view with more than 200 UIInput components.
> > 
> > 
> > Is it a known problem? I will provide more detailed profiling
> > results
> > later.
> > 
> > Regards,
> > 
> > Martin Kočí
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 
> 

Re: Myfaces vs. mojarra restore view performance

[Martin Koci]

Hi,

today's results:

myfaces from trunk + patchs from MYFACES-2854 : ~80 ms in
RestoreViewExecutor.exectute

mojarra: ~70 ms in RestoreViewPhase.execute


major gain comes from solution which I suggest in MYFACES-2854: process
resource dependecies only for type, not for each instance of that type.
Can this solution have disadvantages? 


Now the slowest part of restore view phase is creation of composite
components during buildView() -
CompositeComponentResourceTagHandler.createComponent(FaceletContext)
leads to invovations of Tomcat's
WebappClassLoader.findResourceInternal(String, String). Probably
composite components should be cached in production stage?


Regards,

Martin Kočí

Martin Koci píše v Po 02. 08. 2010 v 22:20 +0200:
> Hi,
> 
> quick results: yourkitprofiler marks as hot spot
> UiViewRoot.addComponentResource (3381 invocation count) - that method
> itself creates 5 710 511 invocations of AbstractIterator.next() 
> 
> Reason probably is that I have  custom renderer for UInput with
> @ResourceDependencies(...many @ResourceDependecy here).
> 
> All invocations comes from
> org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply 
> recursively during restore view - VDL.buildView. 
> 
> Solution: @ResourceDependencies is static structure and cannot change
> during lifecycle - call addComponentResource for particular type of
> component (renderer, validator, ...) only once per one lifecycle ?
> 
> 
> Thanks,
> 
> Martin Kočí
> 
> Jan-Kees van Andel píše v Po 02. 08. 2010 v 19:18 +0200:
> > Hey,
> > 
> > 
> > I'm very interested in the details behind those 750ms. Can you post
> > the hotspots? Like: number of invocations, ms. self time and ms. total
> > time.
> > 
> > 
> > Thanks.
> > 
> > 
> > Regards,
> > Jan-Kees
> > 
> > 
> > 2010/8/2 Martin Koci 
> > Hi,
> > 
> > our profiling results show that myfaces are significantly
> > slower in
> > restore view phase:
> > 
> > com.sun.faces LifeCycle .. restoreView : 80 ms
> > 
> > o.a.m.RestoreViewExecutor : 750ms!
> > 
> > This result is perfectly reproducible in our case. I profile
> > it on a
> > application real application  - I cannot post test case here.
> > 
> > Configuration: myfaces or mojarra from trunk, partial state
> > saving, a
> > view with more than 200 UIInput components.
> > 
> > 
> > Is it a known problem? I will provide more detailed profiling
> > results
> > later.
> > 
> > Regards,
> > 
> > Martin Kočí
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> 
> 

Re: Myfaces vs. mojarra restore view performance

[Martin Koci]

Leonardo Uribe píše v St 04. 08. 2010 v 14:26 -0500:
> Hi
> 
> 2010/8/4 Martin Koci 
> Hi,
> 
> today's results:
> 
> myfaces from trunk + patchs from MYFACES-2854 : ~80 ms in
> RestoreViewExecutor.exectute
> 
> mojarra: ~70 ms in RestoreViewPhase.execute
> 
> 
> major gain comes from solution which I suggest in
> MYFACES-2854: process
> resource dependecies only for type, not for each instance of
> that type.
> Can this solution have disadvantages?
> 
> 
> 
> Could you try with the patch proposed (MYFACES-2854-1.patch) ?
Yes, I profile myfaces with that patch. That speeds it up to ~300 ms.
But there are still thousands invocations of addComponentResource - see
next comment

> 
> I think the solution proposed is not taking into consideration that in
> a single request, 
> multiple views could be built (for example when there is a redirect on
> PreRenderViewEvent).

ah, yes that's true. So cache it per view then? Consider following
scenario: a view with more then 800 UIInput components of same type (we
have one such view, don't ask me why). That component declares
dependency on 5 resources. This configuration creates 4000 invocation of
addComponentResource  but the result is insertion of 5 resources only!
Resources adding per type reduces it to 5 invocations; 4000 vs. 5 is big
difference. 

> 
> 
> Now the slowest part of restore view phase is creation of
> composite
> components during buildView() -
> CompositeComponentResourceTagHandler.createComponent(FaceletContext)
> leads to invovations of Tomcat's
> WebappClassLoader.findResourceInternal(String, String).
> Probably
> composite components should be cached in production stage?
> 
> 
> In theory, FaceletFactory cache them, isn't it?
> 

I din't look into code, this result comes from yourkitprofiler, but
probably caching is not working fine in this case, because count of
invocation of findResourceInternal is same as count of composite
components in tested view. I'll investigate it later.


> regards,
> 
> Leonardo Uribe
>  
> 
> Regards,
> 
> Martin Kočí
> 
> Martin Koci píše v Po 02. 08. 2010 v 22:20 +0200:
> 
> > Hi,
> >
> > quick results: yourkitprofiler marks as hot spot
> > UiViewRoot.addComponentResource (3381 invocation count) -
> that method
> > itself creates 5 710 511 invocations of
> AbstractIterator.next()
> >
> > Reason probably is that I have  custom renderer for UInput
> with
> > @ResourceDependencies(...many @ResourceDependecy here).
> >
> > All invocations comes from
> >
> 
> org.apache.myfaces.view.facelets.tag.jsf.ComponentTagHandlerDelegate.apply 
> recursively during restore view - VDL.buildView.
> >
> > Solution: @ResourceDependencies is static structure and
> cannot change
> > during lifecycle - call addComponentResource for particular
> type of
> > component (renderer, validator, ...) only once per one
> lifecycle ?
> >
> >
> > Thanks,
> >
> > Martin Kočí
> >
> > Jan-Kees van Andel píše v Po 02. 08. 2010 v 19:18 +0200:
> > > Hey,
> > >
> > >
>     > > I'm very interested in the details behind those 750ms. Can
> you post
> > > the hotspots? Like: number of invocations, ms. self time
> and ms. total
> > > time.
> > >
> > >
> > > Thanks.
> > >
> > >
> > > Regards,
> > > Jan-Kees
> > >
> > >
> > > 2010/8/2 Martin Koci 
> > > Hi,
> > >
> > > our profiling results show that myfaces are
> significantly
> > > slower in
> > > restore view phase:
> > >
> > > com.sun.faces LifeCycle .. restoreView : 80 ms
> > >
> > > o.a.m.RestoreViewExecutor : 750ms!
> > >
> > > This result is perfectly reproducible in our case.
> I profile
> > > it on a
> > > application real application  - I cannot post test
> case here.
> > >
> > > Configuration: myfaces or mojarra from trunk,
> partial state
> > > saving, a
> > > view with more than 200 UIInput components.
> > >
> > >
> > > Is it a known problem? I will provide more
> detailed profiling
> > > results
> > > later.
> > >
> > > Regards,
> > >
> > > Martin Kočí
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> 
> 
> 
> 

Re: Myfaces vs. mojarra restore view performance

[Martin Koci]

Hi,

success!

myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70 ms in restore view
phase. It was *750 ms* before.

Thanks,

Martin Kočí

Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500:
> Hi
> 
> I implemented a proposal for this one on MYFACES-2854-2.patch using
> the suggestion
> proposed (do not apply ResourceDependency if it was already
> processed). I hope that 
> patch solve the problem.
> 
> regards,
> 
> Leonardo
> 

Re: Myfaces vs. mojarra restore view performance

[Martin Koci]

Hi,


is it possible to cache inspected classes in RequestViewContext? I did
something like that:

if (isProduction && !
requestViewContext.isAlreadyInspected(inspectedClass)) {

_handleListenerForAnnotations(context, inspected,
inspectedClass, component, isProduction);

_handleResourceDependencyAnnotations(context,
inspectedClass, component, isProduction);

requestViewContext.setAsProcessed(inspectedClass);
}

in _handleAnnotations and it reduces restore view time to 30-40 ms.


regards,

Martin Kočí

Leonardo Uribe píše v Čt 05. 08. 2010 v 15:56 -0500:
> Hi
> 
> Ok, good to know that. I closed MYFACES-2854. Maybe on MYFACES-2862 we
> can use FacesContext.isProjectStage(ProjectStage).
> 
> regards,
> 
> Leonardo
> 
> 2010/8/5 Martin Koci 
> Hi,
> 
> success!
> 
> myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70 ms in
> restore view
> phase. It was *750 ms* before.
> 
> Thanks,
> 
> Martin Kočí
> 
> Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500:
> 
> > Hi
> >
> > I implemented a proposal for this one on
> MYFACES-2854-2.patch using
> > the suggestion
> > proposed (do not apply ResourceDependency if it was already
> > processed). I hope that
> > patch solve the problem.
> >
> > regards,
> >
> > Leonardo
> >
> 
> 
> 
> 

Synchronizer token (double submit problem) status

[Martin Koci]

Hi,

what's the current status of implementation of synchronizer token in
myfaces core? There is a specification issue  planned for 2.1 [1]. 

Furthermore, if user wants to block HTML/DOM entirely what can he/she
use? I know trinidad solution only and it has special javascript method
pprInstallBlockingHandlers [2] which automaticaly blocks all DOM
elements during AJAX request/response and if user uses tr:commandButton
blocking="true" then it blocks DOM during normal sumbit too. I would be
nice have something similiar in core (as myfaces extension).

Thanks,

Martin Kočí



[1]
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=559
[2]
https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad-impl/src/main/javascript/META-INF/adf/jsLibs/Core.js

[Trinidad] SimpleSelectOneRenderer.getSubmittedValue bug?

[Martin Koci]

Hello,

why has SimpleSelectOneRenderer such implementation of
getSubmittedValue:


Object submittedValue = super.getSubmittedValue(context,
component,
clientId);
if (submittedValue == null)
   submittedValue = "";

return submittedValue;



The suspicious part is : submittedValue = ""  - it leads to
processUpdates on CoreSelectOneChoice, because not-null submitted value
means "component is in request"

See UIXEditableValue.validate(FacesContext):

// Submitted value == null means "the component was not submitted
// at all";  validation should not continue
Object submittedValue = getSubmittedValue();
if (submittedValue == null)
  return;

It this a bug?


Regards,

Martin Kočí

[Trinidad] Selecting a row in tr:table with mouse click (rowSelection="singleClick")

[Martin Koci]

Hello,

currently tr:table supports selection of one row with attribute
rowSelection="simple". 

For better user experience we want to select a row with clicking on
table row. 

To achieve this I did four minor changes in trinidad code base:

1) support "singleClick" in decoding phase
2) render a hidden field for storing index of clicked row
3) render a onclick for each TR in HTML output
4) add a JS function to Core.js


ad 1) in TableRenderer.decodeSelection(FacesContext, UIComponent):

// added singleClick condition, TableSelectOneRenderer will be used
// for decoding
if ("single".equals(selection) || "singleClick".equals(selection))
_selectOne.decode(context, treeTable);



ad 2) TableRenderer.encodeAll(FacesContext, RenderingContext,
UIComponent, FacesBean):

// If rowSelection is singleClick we render a hidden field
// for storing TR rowIndex
 if
("singleClick".equals(component.getAttributes().get(CoreTable.ROW_SELECTION_KEY.getName(
  {
  // Id is the same as rowSelection="single" uses 
  String id = tContext.getTableId() + ":selected";
  rw.startElement("input", null);
  rw.writeAttribute("type", "hidden", null);
  rw.writeAttribute("id", id, null);
  rw.writeAttribute("name", id, null);
  rw.endElement("input");
}


ad 3) DesktopTableRenderer._renderTableRows(FacesContext,
RenderingContext, TableRenderingContext, UIComponent)

// for rowSelection="singleClick" render a onclick on each TR element
if("singleClick".equals(component.getAttributes().get(CoreTable.ROW_SELECTION_KEY.getName(
 {
final String hiddenFieldId=  tContext.getTableId() + ":selected";
writer.writeAttribute("onclick", "onListClick(this,'" + hiddenFieldId
+"')", null);
}

ad 4) and finally in Core.js
function onListClick(rowEl, hiddenId) {
   var jumpValue = rowEl.rowIndex;
   var hiddenField =  document.getElementById(hiddenId);

   hiddenField.value = jumpValue;
   return true;
}


TBD:
-- indicating selected row with a nice CSS style
-- support autoSubmit to deliver SelectionEvent immediately


Any ideas, preferences?

Regards,


Martin Kočí

Re: evaluating JSR-303 @Size(max=) for input fields?

[Martin Koci]

Hi,

I tried it for my renderkit but unfortunately there is no (or I didn't
find) solution for scenario, where 

value="#{bean.otherBean.constrainedProperty}" and otherBean is null. In
such case you can only obtain constrains from declared type, not from
the real one. 

But for simpler cases where value EL leads to property on non-null bean
it works fine and reduces  duplicity of "max length" information. JPA
2.0 uses @Size for DB constraints too.

Regards,

Martin Kočí

Mark Struberg píše v Út 24. 08. 2010 v 20:41 +:
> Hi!
> 
> Not sure if this is covered in the spec, but wouldn't if be useful to parse 
> for 
> the JSR-303 Size annotation [1] and use this value for the maxlength 
> attribute 
> of h:inputText fields if nothing is manually specified in the xhtml?
> 
> LieGrue,
> strub
> 
> 
> [1]http://download.oracle.com/javaee/6/api/javax/validation/constraints/Size.html
> 
> 
>   
> 

EL method invocation performance

[Martin Koci]

Hi,

this problem is not in myfaces but affects performance especially in
render response phase: 

EL 2.2 introduces method invocation but if you try use it like
rendered="#{bean.getRendered(param)}" there is an unpleasant surprise:
both implementations of BeanELResolver (Glassfish, Tomcat) use this
construction during method invocation:

ExpressionFactory exprFactory = ExpressionFactory.newInstance();

That newInstance() always involves FactoryFinder mechanism, callstack
then looks like :

org.apache.catalina.loader.WebappClassLoader.findResourceInternal
 org.apache.catalina.loader.WebappClassLoader.findResource
 org.apache.catalina.loader.WebappClassLoader.getResourceAsStream
   javax.el.FactoryFinder.find(String, String, Properties)
javax.el.ExpressionFactory.newInstance(Properties)
 javax.el.ExpressionFactory.newInstance()
  javax.el.BeanELResolver.invokeMethod(Method, Object, Object[])


Always tries to locale factory implementation, that
means /META-INF/services reading! This is not problem in myfaces, but
users don't distinguish between JSF and EL well.

Any ideas? 

Regards,

Martin Kočí

https://uel.dev.java.net/svn/uel/trunk/api/src/main/java/javax/el/BeanELResolver.java
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/el/BeanELResolver.java

Re: EL method invocation performance

[Martin Koci]

Great! I thought that tomcat and geronimo EL implementation are from
same source; But just now I'm looking in geronimo code and
expressionFactory instance is cached - I'll definitely try it, thanks!


Ivan píše v St 25. 08. 2010 v 22:54 +0800:
> How about trying the el api published by Geronimo ? it caches the
> ExpressionFactory to avoid the search action by default.
> 
> 2010/8/25 Martin Koci 
> Hi,
> 
> this problem is not in myfaces but affects performance
> especially in
> render response phase:
> 
> EL 2.2 introduces method invocation but if you try use it like
> rendered="#{bean.getRendered(param)}" there is an unpleasant
> surprise:
> both implementations of BeanELResolver (Glassfish, Tomcat) use
> this
> construction during method invocation:
> 
> ExpressionFactory exprFactory =
> ExpressionFactory.newInstance();
> 
> That newInstance() always involves FactoryFinder mechanism,
> callstack
> then looks like :
> 
> org.apache.catalina.loader.WebappClassLoader.findResourceInternal
>  org.apache.catalina.loader.WebappClassLoader.findResource
>  org.apache.catalina.loader.WebappClassLoader.getResourceAsStream
>   javax.el.FactoryFinder.find(String, String, Properties)
>javax.el.ExpressionFactory.newInstance(Properties)
> javax.el.ExpressionFactory.newInstance()
>  javax.el.BeanELResolver.invokeMethod(Method, Object,
> Object[])
> 
> 
> Always tries to locale factory implementation, that
> means /META-INF/services reading! This is not problem in
> myfaces, but
> users don't distinguish between JSF and EL well.
> 
> Any ideas?
> 
> Regards,
> 
> Martin Kočí
> 
> 
> https://uel.dev.java.net/svn/uel/trunk/api/src/main/java/javax/el/BeanELResolver.java
> 
> http://svn.apache.org/viewvc/tomcat/trunk/java/javax/el/BeanELResolver.java
> 
> 
> 
> 
> 
> 
> -- 
> Ivan

Re: EL method invocation performance

[Martin Koci]

Now I'm sure that it is an implementation problem: it was very
suspicious that both Tomcat and Glassfish implementations have it - but
Geronimo does not have this problem.

Andy Schwartz píše v St 25. 08. 2010 v 11:38 -0400:
> On Wed, Aug 25, 2010 at 11:10 AM, Jakob Korherr  
> wrote:
> 
> > If it is an implementation problem and can be circumvent in any way, I would
> > contact the Glassfish and Tomcat developers about this ;)
> 
> +1.  I pinged Kin-man as a heads up on this...
> 
> Andy
> 

Re: EL method invocation performance

[Martin Koci]

Hi,

I'll try it but not today :) Optimization is my priority task for next
few months and certainly I'll compare all four (or more?) EL
implementations.

Mark Struberg píše v St 25. 08. 2010 v 17:52 +:
> Martin, could you please give juel a quick try? Would be interested if if 
> also 
> suffers from this problem.
> 
> You can find a slightly tweaked (bugfixed) version of it on my github page
> 
> http://github.com/struberg/juel
> 
> The original is on juel.sourceforge.net
> 
> LieGrue,
> strub
> 
> 
> >
> >From: Jakob Korherr 
> >To: MyFaces Development 
> >Sent: Wed, August 25, 2010 5:10:09 PM
> >Subject: Re: EL method invocation performance
> >
> >Hi,
> >
> >Does this really have to happen at every method invocation or is this an 
> >implementation problem?
> >
> >If it is an implementation problem and can be circumvent in any way, I would 
> >contact the Glassfish and Tomcat developers about this ;)
> >
> >Regards,
> >Jakob
> >
> >
> >2010/8/25 Ivan 
> >
> >How about trying the el api published by Geronimo ? it caches the 
> >ExpressionFactory to avoid the search action by default.
> >>
> >>
> >>2010/8/25 Martin Koci 
> >>
> >>
> >>Hi,
> >>>
> >>>this problem is not in myfaces but affects performance especially in
> >>>render response phase:
> >>>
> >>>EL 2.2 introduces method invocation but if you try use it like
> >>>rendered="#{bean.getRendered(param)}" there is an unpleasant surprise:
> >>>both implementations of BeanELResolver (Glassfish, Tomcat) use this
> >>>construction during method invocation:
> >>>
> >>>ExpressionFactory exprFactory = ExpressionFactory.newInstance();
> >>>
> >>>That newInstance() always involves FactoryFinder mechanism, callstack
> >>>then looks like :
> >>>
> >>>org.apache.catalina.loader.WebappClassLoader.findResourceInternal
> >>> org.apache.catalina.loader.WebappClassLoader.findResource
> >>> org.apache.catalina.loader.WebappClassLoader.getResourceAsStream
> >>>  javax.el.FactoryFinder.find(String, String, Properties)
> >>>   javax.el.ExpressionFactory.newInstance(Properties)
> >>>javax.el.ExpressionFactory.newInstance()
> >>> javax.el.BeanELResolver.invokeMethod(Method, Object, Object[])
> >>>
> >>>
> >>>Always tries to locale factory implementation, that
> >>>means /META-INF/services reading! This is not problem in myfaces, but
> >>>users don't distinguish between JSF and EL well.
> >>>
> >>>Any ideas?
> >>>
> >>>Regards,
> >>>
> >>>Martin Kočí
> >>>
> >>>https://uel.dev.java.net/svn/uel/trunk/api/src/main/java/javax/el/BeanELResolver.java
> >>>
> >>>
> >>>http://svn.apache.org/viewvc/tomcat/trunk/java/javax/el/BeanELResolver.java
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>-- 
> >>Ivan
> >>
> >
> >
> >-- 
> >Jakob Korherr
> >
> >blog: http://www.jakobk.com
> >twitter: http://twitter.com/jakobkorherr
> >work: http://www.irian.at
> >
> 
> 
>   
> 

_SelectItemsUtil._ValueConverter

[Martin Koci]

Hi,


what is the purpose of _SelectItemsUtil._ValueConverter in
UISelectMany.validateValue(FacesContext, Object) ?

Two weird things:

1) it wraps value into new String[] { value }
2) it calls UISelectMany.this.getConvertedValue and it leads to
Rendered.getConvertedValue call

I don't see sence in  call of UISelectMany.this.getConvertedValue
because this already done: we are in method validateValue here and
conversion with Renderer.getConvertedValue is done already. This causes
calls to Renderer.getConvertedValue during process validation which is
unintented I think.


Regards,

Martin Kočí

Re: _SelectItemsUtil._ValueConverter

[Martin Koci]

Hi,


I understand that requirement but isn't it EL coercion task ? :

https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=152

and from UISelectMany.validateValue JavaDoc:

" ...Before comparing each option, coerce the option value type to the
type of this component's value following the Expression Language
coercion rules ..."


Regards,

Martin Kočí

Jakob Korherr píše v Pá 27. 08. 2010 v 15:31 +0200:
> Hi Martin,
> 
> The purpose of this conversion is that the value of the SelectItems
> may be a String, but the real (already converted) value of the
> UISelectMany may be something else, e.g. Float. Imagine the following
> scenario:
> 
> 
> 
> 
> 
> 
> 
> The itemValues of all SelectItems are Strings, but the UISelectMany
> points to a property which is of type Float[]. Now because of the fact
> that all Strings can be converted into Floats, this scenario must
> work.
> 
> If you now take a look at _SelectItemsUtil.matchValue(), you can see
> that not the component's value, but the value of the SelectItem is
> converted via the _ValueConverter:
> 
> SelectItem item = selectItemsIter.next();
> Object itemValue = item.getValue();
> if(converter != null && itemValue instanceof String)
> {
> itemValue = converter.getConvertedValue(context,
> (String)itemValue);
> }
> 
> and then matched against the real value (again which is e.g. Float):
> 
> if (value==itemValue || value.equals(itemValue))
> {
> return true;
> }
> 
> Furthermore the converter has to be invoked with the wrapped String in
> a String[], because UISelectMany.getConvertedValue() needs a
> submittedValue of type String[].
> 
> Is this clear for you or should I explain it in more detail?
> 
> Regards,
> Jakob
> 
> 2010/8/27 Martin Koci 
> Hi,
> 
> 
> what is the purpose of _SelectItemsUtil._ValueConverter in
> UISelectMany.validateValue(FacesContext, Object) ?
> 
> Two weird things:
> 
> 1) it wraps value into new String[] { value }
> 2) it calls UISelectMany.this.getConvertedValue and it leads
> to
> Rendered.getConvertedValue call
> 
> I don't see sence in  call of
> UISelectMany.this.getConvertedValue
> because this already done: we are in method validateValue here
> and
> conversion with Renderer.getConvertedValue is done already.
> This causes
> calls to Renderer.getConvertedValue during process validation
> which is
> unintented I think.
> 
> 
> Regards,
> 
> Martin Kočí
> 
> 
> 
> 
> 
> -- 
> Jakob Korherr
> 
> blog: http://www.jakobk.com
> twitter: http://twitter.com/jakobkorherr
> work: http://www.irian.at

Re: [COMMUNITY] MyFaces += Martin Kočí

[Martin Koci]

Hi,

it's an honour for me, thanks for inviting me to this great community.

Just for curiosity I found this:
https://issues.apache.org/jira/browse/MYFACES-1171 - reported by me more
than four years ago - time runs so fast! That reminds me: I started with
JSF 0.4 EA - do you remember h:command_button tag with underscore :) ?
Over time I participated in development of more than five large systems
with JSF based GUI and experiences I'll share with you here.


Thanks,

Martin Kočí

Matthias Wessendorf píše v Út 07. 09. 2010 v 16:50 +0200:
> The Myfaces PMC is proud to announce a new addition to our community.
> 
> Please welcome Martin Kočí as the newest MyFaces committer!
> Ali is an active member of the myfaces community. He started on
> contributing to Trinidad and was a great resource recently on MyFaces core.
> 
> 
> @Martin: Please add yourself to the Master-POM at
> https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml
> 

submittedValue vs. Converter.getAsObject

[Martin Koci]

Hi,

maybe this is a stupid question but:

>From UIInput javadoc:

... decoded value of this component, usually but >>>not necessarily a
String<<<, must be stored - but not yet converted - using
setSubmittedValue() 


from UIInput.getConvertedValue:

... and the submitted value is a >>>String<<<, locate a Converter as
follows

Question: why is Converter tied  only to String? Whole specification
speaks about submitted value as of "raw representation of value from
client" but not necessarily String. And 3.3 Conversion Model: "This
section describes the facilities provided by JavaServer Faces to support
type conversion between server-side Java objects and their (typically
String-based) representation in presentation markup."
But Converter.getAsObject expects only String as this "raw
representation" and "typically String-based" formulation from spec now
means "always String-based".
It seems to me that Converter introduces unnecessary dependency on
String-based representation - even ResponseWriter.write* accepts
java.lang.Object as value 

What I try to do is JSF-based server view with custom NOT-string based
protocol where "raw representations from client" can be java object like
Integer or more complex. Creating of:

interface Converter2 {
Object getAsObject(FacesContext,UIComponent,Object)
Object getAsRepresentation(FacesContext,UIComponent,Object)
}

solves my problem but I must reprogram significant part of JSF api.

Does anybody know the backgroud of this? Yes, this is question for EG
but this mailing list more open ...

Related issue: https://issues.apache.org/jira/browse/MYFACES-2910 (only
part of the problem)

Regards,

Kocicak

Re: [COMMUNITY] MyFaces += Martin Kočí

[Martin Koci]

And I almost forgot to write: in order to not mix frequent name "Martin"
in this mailing list I'll use preferably email Martin.Kocicak.Koci at
gmail dot com and "Kocicak" as nickname.

P.S. Kocicak (Kočičák in Czech) is a untranslatable pun based on my last
name and also a popular character from one bedtime story :)

Martin Koci píše v Út 07. 09. 2010 v 21:33 +0200: 
> Hi,
> 
> it's an honour for me, thanks for inviting me to this great community.
> 
> Just for curiosity I found this:
> https://issues.apache.org/jira/browse/MYFACES-1171 - reported by me more
> than four years ago - time runs so fast! That reminds me: I started with
> JSF 0.4 EA - do you remember h:command_button tag with underscore :) ?
> Over time I participated in development of more than five large systems
> with JSF based GUI and experiences I'll share with you here.
> 
> 
> Thanks,
> 
> Martin Kočí
> 
> Matthias Wessendorf píše v Út 07. 09. 2010 v 16:50 +0200:
> > The Myfaces PMC is proud to announce a new addition to our community.
> > 
> > Please welcome Martin Kočí as the newest MyFaces committer!
> > Ali is an active member of the myfaces community. He started on
> > contributing to Trinidad and was a great resource recently on MyFaces core.
> > 
> > 
> > @Martin: Please add yourself to the Master-POM at
> > https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml
> > 
> 
> 
> 

Re: submittedValue vs. Converter.getAsObject

[Martin Koci]

Matthias Wessendorf píše v St 08. 09. 2010 v 11:22 +0200:
> Hello,
> 
> in Trinidad we don't cast to String:
> 
> http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/xhtml/EditableValueRenderer.java?view=annotate
> 
> (see line 133->135)
yes, trinidad handles this situation best - mojarra casts to String in
second case described in MYFACES-2910. 

> This is because of supporting the "oracle adf numbers", like:
> http://download.oracle.com/docs/cd/E12839_01/apirefs./e10655/index.html?oracle/jbo/domain/Number.html

I use similar solution but it requires unique String representation <->
Object relation. This can be easily done for Numbers and other
"primitive" types in Java but I must deal with types where unique String
represenation does not exists or requires a lot of effort. 
So on JSF level conversion String <-> Object is unable to solve this
problem - I simply need Object <-> Object conversion which is not
supported yet.

> 
> The fix is simple: call toString() instead of doing the cast.
> 
> However, I think your patch misses the case of tolerating NULL (new w/ jsf2)
> 
> -Matthias
> 
> On Tue, Sep 7, 2010 at 11:05 PM, Martin Koci
>  wrote:
> > Hi,
> >
> > maybe this is a stupid question but:
> >
> > >From UIInput javadoc:
> >
> > ... decoded value of this component, usually but >>>not necessarily a
> > String<<<, must be stored - but not yet converted - using
> > setSubmittedValue() 
> >
> >
> > from UIInput.getConvertedValue:
> >
> > ... and the submitted value is a >>>String<<<, locate a Converter as
> > follows
> >
> > Question: why is Converter tied  only to String? Whole specification
> > speaks about submitted value as of "raw representation of value from
> > client" but not necessarily String. And 3.3 Conversion Model: "This
> > section describes the facilities provided by JavaServer Faces to support
> > type conversion between server-side Java objects and their (typically
> > String-based) representation in presentation markup."
> > But Converter.getAsObject expects only String as this "raw
> > representation" and "typically String-based" formulation from spec now
> > means "always String-based".
> > It seems to me that Converter introduces unnecessary dependency on
> > String-based representation - even ResponseWriter.write* accepts
> > java.lang.Object as value 
> >
> > What I try to do is JSF-based server view with custom NOT-string based
> > protocol where "raw representations from client" can be java object like
> > Integer or more complex. Creating of:
> >
> > interface Converter2 {
> > Object getAsObject(FacesContext,UIComponent,Object)
> > Object getAsRepresentation(FacesContext,UIComponent,Object)
> > }
> >
> > solves my problem but I must reprogram significant part of JSF api.
> >
> > Does anybody know the backgroud of this? Yes, this is question for EG
> > but this mailing list more open ...
> >
> > Related issue: https://issues.apache.org/jira/browse/MYFACES-2910 (only
> > part of the problem)
> >
> > Regards,
> >
> > Kocicak
> >
> >
> >
> >
> >
> 
> 
> 

FlashImpl : oam.Flash.RENDERMAP.TOKEN and number of Cookies

[Martin Koci]

Hi,

I'm not familiar with Flash implementation and Cookies (about Cookies I
know only one thing: they exist) thus I ask first:

I have many views = .xhtml files in structure like:

001/001.xhtml
002/002.xhtml
..


firefox show that for each such view one cookie exists:

oam.Flash.RENDERMAP.TOKEN with path /project/faces/001/
oam.Flash.RENDERMAP.TOKEN with path /project/faces/002/


Is it ok? 

Problem is that in our big systems with hundreds views we simply get
maximum of cookies per server:
http://kb.mozillazine.org/Network.cookie.maxPerHost

Thanks,

Kočičák

Re: FlashImpl : oam.Flash.RENDERMAP.TOKEN and number of Cookies

[Martin Koci]

Probably we should use cookie.setPath("/"); and reuse one cookie for all
cases?

Martin Koci píše v Čt 09. 09. 2010 v 22:39 +0200:
> Hi,
> 
> I'm not familiar with Flash implementation and Cookies (about Cookies I
> know only one thing: they exist) thus I ask first:
> 
> I have many views = .xhtml files in structure like:
> 
> 001/001.xhtml
> 002/002.xhtml
> ..
> 
> 
> firefox show that for each such view one cookie exists:
> 
> oam.Flash.RENDERMAP.TOKEN with path /project/faces/001/
> oam.Flash.RENDERMAP.TOKEN with path /project/faces/002/
> 
> 
> Is it ok? 
> 
> Problem is that in our big systems with hundreds views we simply get
> maximum of cookies per server:
> http://kb.mozillazine.org/Network.cookie.maxPerHost
> 
> Thanks,
> 
> Kočičák
> 
> 

Re: _SelectItemsUtil._ValueConverter

[Martin Koci]

Hi,

please review https://issues.apache.org/jira/browse/MYFACES-2920

1) JavaDoc explicitly mentions EL coecion but not Converter: 
https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/component/UISelectOne.html#validateValue%28javax.faces.context.FacesContext,%20java.lang.Object%29

"Before comparing each option, coerce the option value type to the type
of this component's value following the Expression Language coercion
rules" -

but obviously if Converter was used for SelectItem.value -> String
should be used for String -> SelectItem.value

2) EL coercion problem: yes, that can happen: 



  


Selected value will be 0.0 in this case. This is probably not problem if
property is primitive float but with Object Float user expects null
(maybe). But is itemValue="" permitted at all?


3) Trinidad: Matthias, isn't this change related to this problem too? :
http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/xhtml/SimpleSelectOneRenderer.java?r1=672549&r2=694485&diff_format=h


Regards,

Kočičák


Martin Marinschek píše v Pá 27. 08. 2010 v 17:50 +0200:
> I didn't totally think through if it is usable in this case, but more
> general, if you can prevent it, do not use EL coercion. Why?
> 
> As specified, EL coercion will coerce null to 0 or an "". For the next
> version of the EL, this behaviour might be configurable.
> 
> best regards,
> 
> Martin
> 
> On 8/27/10, Jakob Korherr  wrote:
> > Hi,
> >
> > Hmm, could be. I guess this code was introduced in JSF 1.1 (no unified EL
> > and thus no EL coercion available) and never changed in later versions.
> >
> > If you can make the scenario work using EL coercion, please file an issue in
> > the JIRA. Thanks!
> >
> > Regards,
> > Jakob
> >
> > 2010/8/27 Martin Koci 
> >
> >> Hi,
> >>
> >>
> >> I understand that requirement but isn't it EL coercion task ? :
> >>
> >> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=152
> >>
> >> and from UISelectMany.validateValue JavaDoc:
> >>
> >> " ...Before comparing each option, coerce the option value type to the
> >> type of this component's value following the Expression Language
> >> coercion rules ..."
> >>
> >>
> >> Regards,
> >>
> >> Martin Kočí
> >>
> >> Jakob Korherr píše v Pá 27. 08. 2010 v 15:31 +0200:
> >> > Hi Martin,
> >> >
> >> > The purpose of this conversion is that the value of the SelectItems
> >> > may be a String, but the real (already converted) value of the
> >> > UISelectMany may be something else, e.g. Float. Imagine the following
> >> > scenario:
> >> >
> >> > 
> >> > 
> >> > 
> >> > 
> >> > 
> >> >
> >> > The itemValues of all SelectItems are Strings, but the UISelectMany
> >> > points to a property which is of type Float[]. Now because of the fact
> >> > that all Strings can be converted into Floats, this scenario must
> >> > work.
> >> >
> >> > If you now take a look at _SelectItemsUtil.matchValue(), you can see
> >> > that not the component's value, but the value of the SelectItem is
> >> > converted via the _ValueConverter:
> >> >
> >> > SelectItem item = selectItemsIter.next();
> >> > Object itemValue = item.getValue();
> >> > if(converter != null && itemValue instanceof String)
> >> > {
> >> > itemValue = converter.getConvertedValue(context,
> >> > (String)itemValue);
> >> > }
> >> >
> >> > and then matched against the real value (again which is e.g. Float):
> >> >
> >> > if (value==itemValue || value.equals(itemValue))
> >> > {
> >> > return true;
> >> > }
> >> >
> >> > Furthermore the converter has to be invoked with the wrapped String in
> >> > a String[], because UISelectMany.getConvertedValue() needs a
> >> > submittedValue of type String[].
> >> >
> >> > Is this clear for you or should I explain it in more detail?
> >> >
> >> > Regards,
> >> > Jakob
> >> >
> >> > 2010/8/27 Martin Koci 
> >> > Hi,
> >> >
> >> >
> >> > what is the purpose 

Re: Myfaces vs. mojarra restore view performance

[Martin Koci]

Hi,


please review https://issues.apache.org/jira/browse/MYFACES-2922 and
apply if possible.

Thanks,

Kočičák


Leonardo Uribe píše v Pá 06. 08. 2010 v 13:07 -0500:
> Hi
> 
> 2010/8/6 Martin Koci 
> Hi,
> 
> 
> is it possible to cache inspected classes in
> RequestViewContext? I did
> something like that:
> 
> if (isProduction && !
> requestViewContext.isAlreadyInspected(inspectedClass)) {
> 
>_handleListenerForAnnotations(context, inspected,
> inspectedClass, component, isProduction);
> 
>_handleResourceDependencyAnnotations(context,
> inspectedClass, component, isProduction);
> 
>requestViewContext.setAsProcessed(inspectedClass);
>}
> 
> in _handleAnnotations and it reduces restore view time to
> 30-40 ms.
> 
> 
> It is necessary to apply @ListenerFor annotations on every component
> that has registered
> it in the view. The reason why we can cache @ResourceDependency is
> this annotation
> cause a component resource to be added, and that one will be always
> the "same".
> 
>  regards,
> 
> Leonardo
>  
> 
> regards,
> 
> Martin Kočí
> 
> Leonardo Uribe píše v Čt 05. 08. 2010 v 15:56 -0500:
> 
> > Hi
> >
> > Ok, good to know that. I closed MYFACES-2854. Maybe on
> MYFACES-2862 we
> > can use FacesContext.isProjectStage(ProjectStage).
> >
> > regards,
> >
> > Leonardo
> >
> > 2010/8/5 Martin Koci 
> > Hi,
> >
> > success!
> >
> > myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70
> ms in
> > restore view
> > phase. It was *750 ms* before.
> >
> > Thanks,
> >
> > Martin Kočí
> >
> > Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500:
> >
> > > Hi
> > >
> > > I implemented a proposal for this one on
> > MYFACES-2854-2.patch using
> > > the suggestion
> > > proposed (do not apply ResourceDependency if it
> was already
> > > processed). I hope that
> > > patch solve the problem.
> > >
> > > regards,
> > >
> > > Leonardo
> > >
> >
> >
> >
> >
> 
> 
> 
> 

Re: _SelectItemsUtil._ValueConverter

[Martin Koci]

Hi,

it works with Enums because EL uses for "EnumValue" coercion
Enum.valueOf(EnumType.class, "EnumValue") - see Unified EL spec, section
1.17 Enums . I added a test for this explicitly. But
MockExpressionFactory currently does not implement this enum coercion in
coerceToType method - MYFACES-2920-v2.patch contains fix for that.


Regards, 

Kočičák


Jakob Korherr píše v Út 14. 09. 2010 v 16:57 +0200:
> Hi,
> 
> The patch looks good, but actually I did not test it myself. Have you
> also tried it with enum values?
> 
> Funny that the TCK does not fail here, because the spec explicitly
> tells us to use coercion.
> 
> If it works well with enums, +1 on committing this patch.
> 
> Regards,
> Jakob
> 
> 2010/9/14 Martin Koci :
> > Hi,
> >
> > please review https://issues.apache.org/jira/browse/MYFACES-2920
> >
> > 1) JavaDoc explicitly mentions EL coecion but not Converter:
> > https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/component/UISelectOne.html#validateValue%28javax.faces.context.FacesContext,%20java.lang.Object%29
> >
> > "Before comparing each option, coerce the option value type to the type
> > of this component's value following the Expression Language coercion
> > rules" -
> >
> > but obviously if Converter was used for SelectItem.value -> String
> > should be used for String -> SelectItem.value
> >
> > 2) EL coercion problem: yes, that can happen:
> >
> >
> > 
> >  
> >
> >
> > Selected value will be 0.0 in this case. This is probably not problem if
> > property is primitive float but with Object Float user expects null
> > (maybe). But is itemValue="" permitted at all?
> >
> >
> > 3) Trinidad: Matthias, isn't this change related to this problem too? :
> > http://svn.apache.org/viewvc/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/xhtml/SimpleSelectOneRenderer.java?r1=672549&r2=694485&diff_format=h
> >
> >
> > Regards,
> >
> > Kočičák
> >
> >
> > Martin Marinschek píše v Pá 27. 08. 2010 v 17:50 +0200:
> >> I didn't totally think through if it is usable in this case, but more
> >> general, if you can prevent it, do not use EL coercion. Why?
> >>
> >> As specified, EL coercion will coerce null to 0 or an "". For the next
> >> version of the EL, this behaviour might be configurable.
> >>
> >> best regards,
> >>
> >> Martin
> >>
> >> On 8/27/10, Jakob Korherr  wrote:
> >> > Hi,
> >> >
> >> > Hmm, could be. I guess this code was introduced in JSF 1.1 (no unified EL
> >> > and thus no EL coercion available) and never changed in later versions.
> >> >
> >> > If you can make the scenario work using EL coercion, please file an 
> >> > issue in
> >> > the JIRA. Thanks!
> >> >
> >> > Regards,
> >> > Jakob
> >> >
> >> > 2010/8/27 Martin Koci 
> >> >
> >> >> Hi,
> >> >>
> >> >>
> >> >> I understand that requirement but isn't it EL coercion task ? :
> >> >>
> >> >> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=152
> >> >>
> >> >> and from UISelectMany.validateValue JavaDoc:
> >> >>
> >> >> " ...Before comparing each option, coerce the option value type to the
> >> >> type of this component's value following the Expression Language
> >> >> coercion rules ..."
> >> >>
> >> >>
> >> >> Regards,
> >> >>
> >> >> Martin Kočí
> >> >>
> >> >> Jakob Korherr píše v Pá 27. 08. 2010 v 15:31 +0200:
> >> >> > Hi Martin,
> >> >> >
> >> >> > The purpose of this conversion is that the value of the SelectItems
> >> >> > may be a String, but the real (already converted) value of the
> >> >> > UISelectMany may be something else, e.g. Float. Imagine the following
> >> >> > scenario:
> >> >> >
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> >
> >> >> > The itemValues of all SelectItems are Strings, but the UISelectMany
>

Re: [VOTE] release for myfaces core 2.0.2

[Martin Koci]

+1


Regards,

Kočičák

Jakob Korherr píše v Út 21. 09. 2010 v 17:45 +0200:
> +1
> 
> Regards,
> Jakob
> 
> 2010/9/21 Mark Struberg :
> > +1
> >
> > built from source went fine + rat is ok + signature check is ok.
> >
> > LieGrue,
> > strub
> >
> > --- On Tue, 9/21/10, Gerhard  wrote:
> >
> > From: Gerhard 
> > Subject: Re: [VOTE] release for myfaces core 2.0.2
> > To: "MyFaces Development" 
> > Date: Tuesday, September 21, 2010, 12:34 PM
> >
> > +1
> > regards,gerhard
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> >
> >
> > Professional Support for Apache MyFaces
> >
> >
> >
> >
> > 2010/9/21 Michael Concini 
> >
> >
> > +1
> >
> > On Tue, Sep 21, 2010 at 7:59 AM, Werner Punz  wrote:
> >
> >
> >
> > +1
> >
> >
> >
> > Am 21.09.10 02:52, schrieb Leonardo Uribe:
> >
> >
> > +1
> >
> >
> >
> > 2010/9/20 Leonardo Uribe mailto:lu4...@gmail.com>>
> >
> >
> >
> >
> > Hi,
> >
> >
> >
> > I was running the needed tasks to get the 2.0.2 release of Apache
> >
> > MyFaces core out.
> >
> >
> >
> > The artifacts passed all TCK tests.
> >
> >
> >
> > Please note that this vote concerns all of the following parts:
> >
> >   1. Maven artifact group "org.apache.myfaces.shared" v4.0.3  [1]
> >
> >   2. Maven artifact group "org.apache.myfaces.core" v2.0.2  [1]
> >
> >
> >
> > The artifacts were deployed on nexus repo [1] and to my private
> >
> > Apache account [3] for binary and source packages.
> >
> >
> >
> > The release notes could be found at [4].
> >
> >
> >
> > Also the clirr test does not show binary incompatibilities with
> >
> > myfaces-api.
> >
> >
> >
> > Please take a look at the "2.0.2" artifacts and vote!
> >
> >
> >
> > Please note: This vote is "majority approval" with a minimum of three
> >
> > +1 votes (see [3]).
> >
> >
> >
> > 
> >
> > [ ] +1 for community members who have reviewed the bits
> >
> > [ ] +0
> >
> > [ ] -1 for fatal flaws that should cause these bits not to be released,
> >
> >   and why..
> >
> > 
> >
> >
> >
> > Thanks,
> >
> > Leonardo Uribe
> >
> >
> >
> > [1]
> >
> > 
> > https://repository.apache.org/content/repositories/orgapachemyfaces-001/org/apache/myfaces
> >
> > [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
> >
> > [3] http://people.apache.org/~lu4242/myfaces202binsrc
> >
> > 
> >
> > [4]
> >
> > 
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600&styleName=Html&version=12315348
> >
> >
> >
> >
> > 
> > 
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
> 
> 

Re: submittedValue vs. Converter.getAsObject

[Martin Koci]

Hi,

I've just read Leonardo's post at jsr-314-open about this problem.

FYI: I have finished prototype of JSF server side solution with
non-String communication. It's based on custom renderkit and
ResponseWriter implementation.

I found only one major problem: this one discussed in this mail thread.

Minor thing is string-based naming and meaning of ResponseWriter
methods, because "ResponseWriter is an abstract class describing an
adapter to an underlying output mechanism for *character*-based
output" (from javadoc), but fortunately all methods accept Object as
value. 


Regards, 

Kočičák

Leonardo Uribe píše v St 08. 09. 2010 v 10:34 -0500:
> Hi Martin
> 
> 2010/9/8 Martin Marinschek 
> Hi Leo,
> 
> > Yes, to solve the problem with t:inputCalendar and
> t:inputDate it was clear
> > an interface like that was necessary but it is tied to
> java.util.Date in
> > this case:
> 
> 
> We could open an issue to make this more generic - and have an
> infrastructure in the impl where we can register such
> converters. Then
> we could use them for such use-cases as we have, and also for
> Martin's
> use-cases.
> 
> 
> 
> 
> Ok, I'll check in deep what trinidad does and why and later I'll open
> an issue for this one on
> the jsf spec issue tracker.
> 
> best regards,
> 
> Leonardo
>  
> best regards,
> 
> Martin
> 
> --
> 
> http://www.irian.at
> 
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
> 
> Professional Support for Apache MyFaces
> 
> 

[core] performance: disabling "old" technologies

[Martin Koci]

Hi,

since JSF 2.0 JSP support and  are deprecated. Since 1.2
same for javax.faces.el. 


For performace reasons I suggest find a way how disable following:

1) Managed Bean support (o.a.m.SUPPORT_MANAGED_BEANS=false)

if this flag is false, myfaces will not install ManagedBeanResolver and
will skip managed beans processing during startup (or outputs a warning
if managed bean is found and this flag is false).


2) VariableResolver and PropertyResolver
(o.a.m.SUPPORT_JAVAX_FACES_EL=false)

myfaces will not install VariableResolverImpl and
VariableResolverToELResolver and PropertyResolver implementations


3) (o.a.m.SUPPORT_JSP=false)
if this flag is false myfaces will not install FacesCompositeELResolver
and will skip JSP initializer during startup. FacesCompositeELResolver
is related to VariableResolverImpl, maybe this can be one paramater.

Those are only suggestions. I did some initial profiling and when "old"
technogies are disabled myfaces gain significant performance boost,
especially in render response phase.

Another solution for ELResolvers only is use of comparator but this does
not allow skip certain parts of code.

WDYT?

Kočičák

Re: Myfaces vs. mojarra restore view performance

[Martin Koci]

Hi,

Leonardo, can you please review :
https://issues.apache.org/jira/browse/MYFACES-2922
https://issues.apache.org/jira/browse/MYFACES-2862

and apply them if they are suitable?


Thanks,

Kočičák

Martin Koci píše v Út 14. 09. 2010 v 23:05 +0200:
> Hi,
> 
> 
> please review https://issues.apache.org/jira/browse/MYFACES-2922 and
> apply if possible.
> 
> Thanks,
> 
> Kočičák
> 
> 
> Leonardo Uribe píše v Pá 06. 08. 2010 v 13:07 -0500:
> > Hi
> > 
> > 2010/8/6 Martin Koci 
> > Hi,
> > 
> > 
> > is it possible to cache inspected classes in
> > RequestViewContext? I did
> > something like that:
> > 
> > if (isProduction && !
> > requestViewContext.isAlreadyInspected(inspectedClass)) {
> > 
> >_handleListenerForAnnotations(context, inspected,
> > inspectedClass, component, isProduction);
> > 
> >_handleResourceDependencyAnnotations(context,
> > inspectedClass, component, isProduction);
> > 
> >requestViewContext.setAsProcessed(inspectedClass);
> >}
> > 
> > in _handleAnnotations and it reduces restore view time to
> > 30-40 ms.
> > 
> > 
> > It is necessary to apply @ListenerFor annotations on every component
> > that has registered
> > it in the view. The reason why we can cache @ResourceDependency is
> > this annotation
> > cause a component resource to be added, and that one will be always
> > the "same".
> > 
> >  regards,
> > 
> > Leonardo
> >  
> > 
> > regards,
> > 
> > Martin Kočí
> > 
> > Leonardo Uribe píše v Čt 05. 08. 2010 v 15:56 -0500:
> >     
> > > Hi
> > >
> > > Ok, good to know that. I closed MYFACES-2854. Maybe on
> > MYFACES-2862 we
> > > can use FacesContext.isProjectStage(ProjectStage).
> > >
> > > regards,
> > >
> > > Leonardo
> > >
> > > 2010/8/5 Martin Koci 
> > > Hi,
> > >
> > > success!
> > >
> > > myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70
> > ms in
> > > restore view
> > > phase. It was *750 ms* before.
> > >
> > > Thanks,
> > >
> > > Martin Kočí
> > >
> > > Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500:
> > >
> > > > Hi
> > > >
> > > > I implemented a proposal for this one on
> > > MYFACES-2854-2.patch using
> > > > the suggestion
> > > > proposed (do not apply ResourceDependency if it
> > was already
> > > > processed). I hope that
> > > > patch solve the problem.
> > > >
> > > > regards,
> > > >
> > > > Leonardo
> > > >
> > >
> > >
> > >
> > >
> > 
> > 
> > 
> > 
> 
> 

[core] FacesEL vs. UEL vs. UEL 2.2

[Martin Koci]

Hi, 


there is a disorder in Expression Lauguage names in myfaces core.
Currently myfaces (method
javax.faces.validator._ExternalSpecifications.isUnifiedELAvailable() for
example) output a log:

"MyFaces Unified EL support enabled"

But this is a little misleading: there should be "Unified EL 2.2 support
enabled" because it tests presence of EL 2.2. "Unified EL support
enabled" does not make sence at all because JSF use Unified EL as core
technology and that cannot be disabled.


There are three major versions of ELs:

1) javax.faces.el - old and depreceated

2) javax.el 2.0, 2.1 (from JSP 2.0, 2.1) 

3) javax.el 2.2 from JSP 2.2, part of Java EE 6, EL with method
invocations


Suggestions:
Rename isUnifiedELAvailable to isUnifiedEL22Available,
TagValueExpressionUEL to TagValueExpressionUEL22 and so on.
For EL 2.3 (not released yet) we can add similar methods/classes.

Change log to "MyFaces Unified EL 2.2 support enabled (method
invocations are available)". 

I'll add similiar log "MyFaces Faces EL (javax.faces.el) support
disabled"  as part of "disabling "old" technologies"

WDYT ?


Kočičák

Re: EL method invocation performance

[Martin Koci]

Hi, 

some news about EL method invocations:

1)  Geronimo EL API implementation has this problem too:
https://issues.apache.org/jira/browse/GERONIMO-5657

2) UEL bug is still open:
https://uel.dev.java.net/issues/show_bug.cgi?id=19

3) JUEL doesn't not work for my test cases, for example it doesn't find
some public methods so I cannot say if JUEL has this problem now.


My today's recommedation (which can change tommorow) is: if you want EL
method invocations without file asscess within
(without /META-INF/services reading):

A) apply GERONIMO-5657 patch to
http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-el_2.2_spec/ and 
build this EL-API

B) use impl part from uel.dev.java.net as EL-impl or tomcat's EL impl


Please note that uel.dev.java.net API suffers from classic leaking
classloader problem too - it uses Class instance as key in static Map :
see MYFACES-2942 for details. Maybe we should put a warning about these
two issues at http://wiki.apache.org/myfaces/HowToEnableEl22 ?


Regards,

Kocicak

Martin Koci píše v St 25. 08. 2010 v 20:52 +0200:
> Hi,
> 
> I'll try it but not today :) Optimization is my priority task for next
> few months and certainly I'll compare all four (or more?) EL
> implementations.
> 
> Mark Struberg píše v St 25. 08. 2010 v 17:52 +:
> > Martin, could you please give juel a quick try? Would be interested if if 
> > also 
> > suffers from this problem.
> > 
> > You can find a slightly tweaked (bugfixed) version of it on my github page
> > 
> > http://github.com/struberg/juel
> > 
> > The original is on juel.sourceforge.net
> > 
> > LieGrue,
> > strub
> > 
> > 
> > >
> > >From: Jakob Korherr 
> > >To: MyFaces Development 
> > >Sent: Wed, August 25, 2010 5:10:09 PM
> > >Subject: Re: EL method invocation performance
> > >
> > >Hi,
> > >
> > >Does this really have to happen at every method invocation or is this an 
> > >implementation problem?
> > >
> > >If it is an implementation problem and can be circumvent in any way, I 
> > >would 
> > >contact the Glassfish and Tomcat developers about this ;)
> > >
> > >Regards,
> > >Jakob
> > >
> > >
> > >2010/8/25 Ivan 
> > >
> > >How about trying the el api published by Geronimo ? it caches the 
> > >ExpressionFactory to avoid the search action by default.
> > >>
> > >>
> > >>2010/8/25 Martin Koci 
> > >>
> > >>
> > >>Hi,
> > >>>
> > >>>this problem is not in myfaces but affects performance especially in
> > >>>render response phase:
> > >>>
> > >>>EL 2.2 introduces method invocation but if you try use it like
> > >>>rendered="#{bean.getRendered(param)}" there is an unpleasant surprise:
> > >>>both implementations of BeanELResolver (Glassfish, Tomcat) use this
> > >>>construction during method invocation:
> > >>>
> > >>>ExpressionFactory exprFactory = ExpressionFactory.newInstance();
> > >>>
> > >>>That newInstance() always involves FactoryFinder mechanism, callstack
> > >>>then looks like :
> > >>>
> > >>>org.apache.catalina.loader.WebappClassLoader.findResourceInternal
> > >>> org.apache.catalina.loader.WebappClassLoader.findResource
> > >>> org.apache.catalina.loader.WebappClassLoader.getResourceAsStream
> > >>>  javax.el.FactoryFinder.find(String, String, Properties)
> > >>>   javax.el.ExpressionFactory.newInstance(Properties)
> > >>>javax.el.ExpressionFactory.newInstance()
> > >>> javax.el.BeanELResolver.invokeMethod(Method, Object, Object[])
> > >>>
> > >>>
> > >>>Always tries to locale factory implementation, that
> > >>>means /META-INF/services reading! This is not problem in myfaces, but
> > >>>users don't distinguish between JSF and EL well.
> > >>>
> > >>>Any ideas?
> > >>>
> > >>>Regards,
> > >>>
> > >>>Martin Kočí
> > >>>
> > >>>https://uel.dev.java.net/svn/uel/trunk/api/src/main/java/javax/el/BeanELResolver.java
> > >>>
> > >>>
> > >>>http://svn.apache.org/viewvc/tomcat/trunk/java/javax/el/BeanELResolver.java
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >>-- 
> > >>Ivan
> > >>
> > >
> > >
> > >-- 
> > >Jakob Korherr
> > >
> > >blog: http://www.jakobk.com
> > >twitter: http://twitter.com/jakobkorherr
> > >work: http://www.irian.at
> > >
> > 
> > 
> >   
> > 
> 
> 
> 

[core] performance: TagAttributeImpl and composite component EL detection

[Martin Koci]

Hi,


a issue to consider in
org.apache.myfaces.view.facelets.tag.TagAttributeImpl: 


Methods
TagAttributeImpl.getMethodExpression and
TagAttributeImpl.getValueExpression use
CompositeComponentELUtils.isCompositeComponentXYZ methods to detect if
current #{} contains cc expression. But consider following: if user
migrates from facelets 1.2 to 2.0, this new cc detection slows down
build view process. In one my test case VDL.buildView calls
CompositeComponentELUtils.isCompositeComponentXYZ approx 3000 times per
build view with no match. isCompositeComponentXYZ is not cheap method
because it uses Pattern.matches().

Are there possibilities to avoid this? For example is possible have some
kind of "isProcessingCompositeComponent" method and skip
Pattern.matches() if false? We are in VDL.buildView here and no
components are available yet, no use of methods like
UIComponent.isCompositeComponent(UIComponent) is possible.

Any ideas?

Regards,

Kočičák

Re: [core] performance: TagAttributeImpl and composite component EL detection

[Martin Koci]

hehe, I was writing something similar: "in production stage
TagAttributeImpl is only created once and then facelets cache mechanism
keep this instance alive as part of Facelet memory structure. Thus if
user did request to all Facelet instances (all *xhtml) in JSF
application, it creates forest of Facelet instances, Facelet instances
are trees, those trees have nodes (Tag instances) with leafs =
TagAttribute instances. It this is true and  if I remember well graph
theory long time ago at university, each TagAttribute instance is unique
and there exists only on path to it -> 
why is ValueExpression evaluated new on every request?"

In short (I must go home now ...) : ValueExpression can differ in
expected type and facelets context. But can those values be really
diffirent for same TagAttribute instance? If they are always same can ve
cache ValueExpression instance forever?

Leonardo Uribe píše v St 20. 10. 2010 v 15:45 -0500:
> Hi
> 
> I have an idea: why don't evaluate that condition on construction
> time?
> 
> In that case, EL will be scanned only once (when the Facelet or
> Abstract Syntax Tree (AST) is build) and
> not when the view is build, like is happening now.
> 
> I have created an issue 
> 
> https://issues.apache.org/jira/browse/MYFACES-2951
> 
> and committed the code in trunk.
> 
> Suggestions are welcome.
> 
> Leonardo Uribe
> 
> 2010/10/20 Jakob Korherr 
> Hi Kočičák,
> 
> There might be some ways to improve this, but we have to be
> very
> careful in making changes to that area, because the whole
> composite
> components + EL domain is not that easy.
> 
> Actually the CompositeComponentELUtils.isCompositeComponentXYZ
> methods
> were introduced by myself when fixing the #{cc} issues we
> encountered
> in some MyFaces 2 alpha versions. Unfortunately I currently
> don't
> really have time to think about improvements here, sorry. But
> I really
> think that there is some room for improvements!
> 
> Also I really like your idea of
> isProcessingCompositeComponent. This
> might be a good way, because if this is false we can skip the
> #{cc}
> check, because such expressions will certainly not occur
> outside of a
> composite component. If you have some spare time, a patch
> would be
> really great :) :) - otherwise please just open a JIRA issue
> for this
> one so that we don't loose sight of it. Thanks!
> 
> Regards,
> Jakob
> 
> 2010/10/20 Werner Punz :
> 
> > Just my 2c without looking into the code, but I assume speed
> improvements
> > already can be gained by replacing the pattern matches, if
> possible with a
> > direct ll comparison.
> > Regexps often are heavier than simple parsing or string
> operations.
> >
> > Another thing might be that we add some caching mechanism on
> this level
> > which caches per request if possible. But I have not looked
> into the code,
> > so I am making wild assumptions here.
> >
>     > I assume also that some speed still can be gained in this
> area by better
> > utilization of the improved tree walking api jsf2 provides.
> >
> >
> > Werner
> >
> >
> > Am 20.10.10 15:54, schrieb Martin Koci:
> >>
> >> Hi,
> >>
> >>
> >> a issue to consider in
> >> org.apache.myfaces.view.facelets.tag.TagAttributeImpl:
> >>
> >>
> >> Methods
> >> TagAttributeImpl.getMethodExpression and
> >> TagAttributeImpl.getValueExpression use
> >> CompositeComponentELUtils.isCompositeComponentXYZ methods
> to detect if
> >> current #{} contains cc expression. But consider following:
> if user
> >> migrates from facelets 1.2 to 2.0, this new cc detection
> slows down
> >> build view process. In one my test case VDL.buildView calls
> >> CompositeComponentELUtils.isCompositeComponentXYZ approx
> 3000 times per
> >> build view with no match. isCompositeComponentXYZ is not
> cheap method
> >> because it uses Pattern.matches().
> >&g

[core] performance: TagAttributeImpl part II: object allocations

[Martin Koci]

Hi,

another performance related problem in TagAttributeImpl: ValueExpression
instances.

Consider a facelets view with 3000 attributes. Then during buildView
method TagAttributeImpl.getValueExpression allocates:

1) one instance of ValueExpression via
ExpressionFactory.createValueExpression

2) one instance of ValueExpression as TagValueExpression

3) if TagAttribute is inside composite component then allocates another
instance of LocationValueExpression.


In this test case buildView creates at least 6 000 instances of
ValueExpression. This is not problem because instances are cheap and
allocation doesn't affect CPU consumption. Problem appears if more
threads do the same: for 100 threads/requests it is 600 000 instances;
consider it for 1000 concurrent requests. All those instances are very
short-lived and practically never leave HotSpot's Young Generation space
and triggers GC excessively; GC management it the main problem : after
one hour of running stress test is TagAttributeImpl.getValueExpression
#1  in "hot spot by object count" with millions of allocations.

At first sight allocations 2) and 3) serves only as a kind of
TagAttribute <-> ValueExpression mapping. Specially the second one holds
only one String which serves later for a nicer exception report.

It seems that some better kind of TagAttribute <-> ValueExpression <->
(String, Localtion) relation reprezentation without using wrapper
pattern can solve this problem. Any ideas how to do it?


Regards,


Kočičák

Re: [core] performance: TagAttributeImpl part II: object allocations

[Martin Koci]

Leonardo Uribe píše v Čt 21. 10. 2010 v 20:31 -0500:
> Hi
> 
> I investigate more if it is possible and unfortunately it is not as
> default. ValueExpressions 
> instances are immutable, but when
> ExpressionFactory.createValueExpression is called, 
> this method uses FunctionMapper and VariableMapper provided by
> FaceletContext.
> 
> The problem is there is no way to detect if a ValueExpression was
> constructed using 
> FunctionMapper or VariableMapper, and facelets uses them a lot.
> 
> But in most cases, FunctionMapper and VariableMapper passed by
> facelets does not change,
> that means, no new variables of functions are added while facelet is
> processing the same page
> over and over. So cache them with a optional parameter (default false)
> could work.

Yes, especially if view declaration doesn't use build time tags like
c:if, c:choose or some kind of direct manipulation of component
tree/ELContext -> then variable mapping should be same for each request.

EL specification directly says that: "Expressions are also designed to
be immutable so that only one instance needs to be created for any given
expression String / FunctionMapper. This allows a container to
pre-create expressions and not have to reparse them each time they are
evaluated" so the only problem here is really the variable mapping.

> 
> Yes, we should test that possible optimization well.
> 
> regards,
> 
> Leonardo Uribe
> 
> 2010/10/21 Jakob Korherr 
> Looks promising, but are they really considered immutable? If
> we do
> this change, we should test special scenarios with all
> available EL
> impls (GlassFish, Tomcat, Geronimo, JUEL) first, because the
> behavior
> might differ from impl to impl..
> 
> Regards,
> Jakob
> 
> 2010/10/22 Leonardo Uribe :
> 
> > Hi
> >
> > In theory it is possible to cache ValueExpression creation
> at
> > TagAttributeImpl level, because ValueExpression instances
> are
> > immutable classes (once initialized does not change its
> state)
> > and Serializable.
> >
> > Just add a simple variable there could do  the job. Just add
> a variable
> > and fill it when getValueExpression(FaceletContext, Class)
> or
> > getMethodExpression(FaceletContext, Class, Class[]) is being
> > called. If two different threads fill this value at the same
> time
> > it will no matter, because both are the same.
> >
> > It is a hack very similar to
> > CompositeComponentDefinitionTagHandler._cachedBeanInfo:
> >
> > /**
> >  * Cached instance used by this component. Note here we
> have a
> >  * "racy single-check".If this field is used, it is
> supposed
> >  * the object cached by this handler is immutable, and
> this is
> >  * granted if all properties not saved as
> ValueExpression are
> >  * "literal".
> >  **/
> >
> > What do you think guys?
> >
> > regards,
> >
> > Leonardo Uribe
> >
> > 2010/10/21 Jakob Korherr 
> >>
> >> Hi Martin,
> >>
> >> Yes, I totally agree. This is really a big performance
> problem.
> >>
> >> The main problem here is that we have no real control about
> the
> >> creation of the ValueExpressions, because the EL
> implementation
> >> provides them for us, thus the wrapper approach.
> >>
> >> The first wrapper, TagValueExpression, (which is actually
> used for
> >> every facelet attribute ValueExpression, right?) might not
> really be
> >> necessary, I guess. The class comes directly from the
> >> facelets-codebase, so we actually don't know why it was
> introduced. I
> >> haven't looked at it yet, but I don't think it has any
> further sence.
> >> Maybe we can get rid of this wrapper...
> >>
> >> The second wrapper is a must, otherwise composite component
> EL
> >> expressions (#{cc}) won't work as expected, because the
> resolution
> >> mec

Re: EL method invocation performance

[Martin Koci]

Hi,
> hi martin,
> 
> 
> it would be nice to get more details about the juel issues.

Christian fixed them promptly in JUEL's svn:

http://sourceforge.net/tracker/?func=detail&aid=3095122&group_id=165179&atid=834616

http://sourceforge.net/tracker/?func=detail&aid=3031783&group_id=165179&atid=834616


Back to original topic: JUEL caches the ExpressionFactory instance and
thus does not have discussed performance problem.


> 
> 
> regards,
> gerhard 
> 
> http://www.irian.at
> 
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
> 
> Professional Support for Apache MyFaces
> 
> 
> 
> 
> 2010/10/19 Martin Koci 
> Hi,
> 
> some news about EL method invocations:
> 
> 1)  Geronimo EL API implementation has this problem too:
> https://issues.apache.org/jira/browse/GERONIMO-5657
> 
> 2) UEL bug is still open: 
> https://uel.dev.java.net/issues/show_bug.cgi?id=19
> 
> 
> 3) JUEL doesn't not work for my test cases, for example it
> doesn't find
> some public methods so I cannot say if JUEL has this problem
> now.
> 
> 
> My today's recommedation (which can change tommorow) is: if
> you want EL
> method invocations without file asscess within
> (without /META-INF/services reading):
> 
> A) apply GERONIMO-5657 patch to
> 
> http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-el_2.2_spec/ 
> and build this EL-API
> 
> B) use impl part from uel.dev.java.net as EL-impl or tomcat's
> EL impl
> 
> 
> Please note that uel.dev.java.net API suffers from classic
> leaking
> classloader problem too - it uses Class instance as key in
> static Map :
> see MYFACES-2942 for details. Maybe we should put a warning
> about these
> two issues at http://wiki.apache.org/myfaces/HowToEnableEl22 ?
> 
> 
> Regards,
> 
> Kocicak
> 
> Martin Koci píše v St 25. 08. 2010 v 20:52 +0200: 
> 
> > Hi,
> >
> > I'll try it but not today :) Optimization is my priority
> task for next
> > few months and certainly I'll compare all four (or more?) EL
> > implementations.
> >
> > Mark Struberg píše v St 25. 08. 2010 v 17:52 +:
> > > Martin, could you please give juel a quick try? Would be
> interested if if also
> > > suffers from this problem.
> > >
> > > You can find a slightly tweaked (bugfixed) version of it
> on my github page
> > >
> > > http://github.com/struberg/juel
> > >
> > > The original is on juel.sourceforge.net
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > > >
> > > >From: Jakob Korherr 
> > > >To: MyFaces Development 
> > > >Sent: Wed, August 25, 2010 5:10:09 PM
> > > >Subject: Re: EL method invocation performance
> > > >
> > > >Hi,
> > > >
> > > >Does this really have to happen at every method
> invocation or is this an
> > > >implementation problem?
>     > > >
> > > >If it is an implementation problem and can be circumvent
> in any way, I would
> > > >contact the Glassfish and Tomcat developers about this ;)
> > > >
> > > >Regards,
> > > >Jakob
> > > >
> > > >
> > > >2010/8/25 Ivan 
> > > >
> > > >How about trying the el api published by Geronimo ? it
> caches the
> > > >ExpressionFactory to avoid the search action by default.
> > > >>
> > > >>
> > > >>2010/8/25 Martin Koci 
> > > >>
> > > >>
> > > >>Hi,
> > > >>>
> > > >>>this problem is not in myfaces but affects performance
> especially in
> > > 

[test] testNG and EL impl in myfaces-test

[Martin Koci]

Hi,


two questions:


1) 12 test cases in myfaces-api and myfaces-impl use @Test from
org.testng.annotations, 56 test cases use @org.junit.Test. What is the
primary test engine for myfaces? I'm trying to provide patch for
MYFACES-2882 and UIViewRootTest uses TestNG: how to use
org.apache.myfaces.test.base.junit4.AbstractJsfTestCase there?


2) myfaces-test has mock-implementation of expression language API. Is
it possible to use real EL implementation instead? Problem:
MockExpressionFactory.coerceToType has no Enum support yet; use of very
EL implementation makes tests closer to real usage of myfaces.



Regards,


Kočičák

[core] UISelectItem(s) questions

[Martin Koci]

Hi,

following things are specified by spec, but maybe someone will know
reasons:

1) why UISelectOne/Many classes don't have method like

List getSelectItems

currently each renderkit has own method with similar purpose but with
different quality and bugs :)

for example, myfaces have RendererUtils.getSelectItemList(UISelectMany,
FacesContext) which outputs warning if f:selectItems value= leads to
null, but RichFaces throw an uninformative exception in same situation.

For user's view it is inconsistent behaviour.



2) similar question: why UISelectItem/UISelectItems dont have
getSelectItem() resp. getSelectItems() method for creating selections
they represent?


3) why UISelectItem has method like getItemLabel(),
getItemDescription(), but UISelectItems not - it uses only attributes
map.


Regards,

Kočičák

[core] Improve error reporting and logging

[Martin Koci]

Hi,

the most wanted feature which our coders want is more consistent and
human-readable error reporting and logging. Here is a example:

If user specifies f:ajax without eventName for a component without
defaultEventName, myfaces throw a execption:

Now (myfaces 2.0.3):
eventName could not be defined for f:ajax tag with no wrap mode.



Improved (example only; from my copy of myfaces):

MF0345: Your ajax tag does not specify eventName and component
com.foo.Bazz does not provide the default one. Please use one from
available: [change, blur, focus ...]"; 

Tag location: XYZ.xhtml line 56 column 23, 

Component: id: componentId,  class: com.foo.BazzInput, component type:
org.renderkit.Input

ViewId: YYZ.xhml, located in file system
as: /tmp/deploy/weabpp/XYZ.xhtml

PhaseId: RENDER_RESPONSE

Details: ... a detailed description of this problem + suggestions,
example of code.

References:
#  Click for problem MF0345 in MYFACES knowledge database (hypertext
link)
# Contact your technology team : m...@to.me
# If you think this a bug report it: jira.project.org






What do you think about this idea?

(I'll describe our requirements and what I found so far in next emails)


Regards,

Kočičák

Re: [core] Improve error reporting and logging

[Martin Koci]

Hi, 

I will do it for Czech and Slovak: MYFACES-3014. Not very frequent
languages, though - but 10 491 492 (CZ) + approx 5 mil (SK) inhabitants
(samt Kindern und Rentnern) of Czech + Slovak Republic will appreciate
it :)  


Werner Punz píše v Út 11. 01. 2011 v 15:13 +0100:
> Btw. I did some work in this area for the client. We now have localized 
> ajax error messages, for now only english and german, anyone willing to 
> step in for other languages?
> 
> Werner
> 
> 
> Am 11.01.11 14:00, schrieb Martin Marinschek:
> > I am always for better error reporting!
> >
> > best regards,
> >
> > Martin
> >
> > On 1/10/11, Jakob Korherr  wrote:
> >> Hi Kocicak,
> >>
> >> 1
> >>
> >> Regards,
> >> Jakob
> >>
> >> 2011/1/10 Martin Koci:
> >>>
> >>> Hi,
> >>>
> >>> the most wanted feature which our coders want is more consistent and
> >>> human-readable error reporting and logging. Here is a example:
> >>>
> >>> If user specifies f:ajax without eventName for a component without
> >>> defaultEventName, myfaces throw a execption:
> >>>
> >>> Now (myfaces 2.0.3):
> >>> eventName could not be defined for f:ajax tag with no wrap mode.
> >>>
> >>>
> >>>
> >>> Improved (example only; from my copy of myfaces):
> >>>
> >>> MF0345: Your ajax tag does not specify eventName and component
> >>> com.foo.Bazz does not provide the default one. Please use one from
> >>> available: [change, blur, focus ...]";
> >>>
> >>> Tag location: XYZ.xhtml line 56 column 23,
> >>>
> >>> Component: id: componentId,  class: com.foo.BazzInput, component type:
> >>> org.renderkit.Input
> >>>
> >>> ViewId: YYZ.xhml, located in file system
> >>> as: /tmp/deploy/weabpp/XYZ.xhtml
> >>>
> >>> PhaseId: RENDER_RESPONSE
> >>>
> >>> Details: ... a detailed description of this problem + suggestions,
> >>> example of code.
> >>>
> >>> References:
> >>> #  Click for problem MF0345 in MYFACES knowledge database (hypertext
> >>> link)
> >>> # Contact your technology team : m...@to.me
> >>> # If you think this a bug report it: jira.project.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> What do you think about this idea?
> >>>
> >>> (I'll describe our requirements and what I found so far in next emails)
> >>>
> >>>
> >>> Regards,
> >>>
> >>> Kočičák
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Jakob Korherr
> >>
> >> blog: http://www.jakobk.com
> >> twitter: http://twitter.com/jakobkorherr
> >> work: http://www.irian.at
> >>
> >
> >
> 
> 
> 

Re: [core] Improve error reporting and logging

[Martin Koci]

Here are some requirements and additional description:

-- identify every error with unique code:

If error begins with unique prefix like MF or MYFACES, coder can at
first sight recognize framework which is the source of that
error/exception. For example Oracle DB throws ORA- or our company stuff
throws AR- prefixed codes.
Number after that prefix is unique identification of problem. Whole
construct can serve as key for query (for bugzilla, WIKi, ...) or as
simple abbreviation of the problem. Our programmers often say "999
happens" instead of "Unexpected failure of data happens" :)

-- text after error code:

Should not only describe what is wrong but also how to solve it.


-- details section:

This section can contain detailed description of problem. It can have
example of , hyperlink to javaDoc or VDL docs, or
a notice that IDEs mostly don't auto-complete this attribute.
In can look like overkill but those informations are required over and
over again. Especially if I hear the same question like "what is
eventName" and "give me an example" again  (grrr)
Of course all information can be found elsewhere but to ease
development, every framework should be self-explanatory
This section can by also collapsable as is the part for component tree
already.

-- localization:

all human-readable text should be localizable because coders always read
and think faster in their mother language.


-- references section:

links to bugzilla, mail etc. Should be configurable, for example I want
provide link from error page to our internal bugzilla, not to myfaces
JIRA. Similar case for email address.


-- information about location of problem:

If Facelets VDL is used it is obvious to provide tag, column and line.
But we cannot limit it for facelets only. For example we have one
project that uses pure Java API for View creation and very complex
logic. Then if UIComponent.setId() throws new
IllegalArgumentException("component identifier must not be a zero-length
String"), is very hard to find the cause, if debugging is not available.
Here we can provide information about parent and path to component,
phase id etc. 


Kočičák

Werner Punz píše v Út 11. 01. 2011 v 15:12 +0100:
> ++1
> 
> Werner
> 
> 
> Am 10.01.11 20:06, schrieb Martin Koci:
> >
> > Hi,
> >
> > the most wanted feature which our coders want is more consistent and
> > human-readable error reporting and logging. Here is a example:
> >
> > If user specifies f:ajax without eventName for a component without
> > defaultEventName, myfaces throw a execption:
> >
> > Now (myfaces 2.0.3):
> > eventName could not be defined for f:ajax tag with no wrap mode.
> >
> >
> >
> > Improved (example only; from my copy of myfaces):
> >
> > MF0345: Your ajax tag does not specify eventName and component
> > com.foo.Bazz does not provide the default one. Please use one from
> > available: [change, blur, focus ...]";
> >
> > Tag location: XYZ.xhtml line 56 column 23,
> >
> > Component: id: componentId,  class: com.foo.BazzInput, component type:
> > org.renderkit.Input
> >
> > ViewId: YYZ.xhml, located in file system
> > as: /tmp/deploy/weabpp/XYZ.xhtml
> >
> > PhaseId: RENDER_RESPONSE
> >
> > Details: ... a detailed description of this problem + suggestions,
> > example of code.
> >
> > References:
> > #  Click for problem MF0345 in MYFACES knowledge database (hypertext
> > link)
> > # Contact your technology team : m...@to.me
> > # If you think this a bug report it: jira.project.org
> >
> >
> >
> >
> >
> >
> > What do you think about this idea?
> >
> > (I'll describe our requirements and what I found so far in next emails)
> >
> >
> > Regards,
> >
> > Kočičák
> >
> >
> 
> 
> 

[core] ajax @this with non trivial component

[Martin Koci]

Hi,

if component is represented on client like:



   a Label 

  


what will be in HTTP reuqest? execute = "clientId_input" - but this is
only internal part of the component, not id of component on the server
so no component is executed.

What I need is :


  
 


ajax behaviour renderer renders '@this' as pass thru value. What I
really need is:

if ("@this".equals(executeItem)) {
executeItem = clientBehaviorContext.getComponent().getCliendId()
}

Similar for render attribute. 


Spec. says: "@this = The element that triggered the request". Thats very
unclear: specification uses 'element' word in two contexts: DOM element
and XHTML element.


Mojarra 2.0.3 renders '@this' as pass through too.


WDYT ?


Kočičák

Re: [core] ajax @this with non trivial component

[Martin Koci]

Hi Andy,

thank you for explanation.

Myfaces do only the first part: 

(1) "This value will (or, well, should) be passed in as thefirst
argument to jsf.ajax.request()" but the second

(2) "and used as the replacement for "@this" targets."
in not implemented yet:
https://issues.apache.org/jira/browse/MYFACES-3018


Also if that situation occurs problem is not easy to find:
https://issues.apache.org/jira/browse/MYFACES-3019

Regards,

Martin

Andy Schwartz píše v St 19. 01. 2011 v 08:56 -0500: 
> Hi Martin -
> 
> I was worried about this case as well when we were working on the
> Ajax/ClientBehavior APIs.  Many Trinidad/ADF Faces components use
> similar markup to what you describe.
> 
> To support this case, we added the ClientBehaviorContext.getSourceId() API:
> 
> http://download.oracle.com/javaee/6/api/javax/faces/component/behavior/ClientBehaviorContext.html#getSourceId()
> 
> This allows renderers that attach client behaviors to non-root DOM
> elements to explicitly specify the id that corresponds to the
> component.  This value will (or, well, should) be passed in as the
> first argument to jsf.ajax.request() and used as the replacement for
> "@this" targets.
> 
> Andy
> 

Re: [VOTE] release for myfaces core 2.0.4

[Martin Koci]

+1

Leonardo Uribe píše v St 09. 02. 2011 v 01:07 -0500:
> Hi,
> 
> I was running the needed tasks to get the 2.0.4 release of Apache
> MyFaces core out.
> 
> The artifacts passed all TCK tests.
> 
> Please note that this vote concerns all of the following parts:
>  1. Maven artifact group "org.apache.myfaces.shared" v4.0.5  [1]
>  2. Maven artifact group "org.apache.myfaces.core" v2.0.4  [1]
> 
> The artifacts were deployed on nexus repo [1] and to my private 
> Apache account [3] for binary and source packages.
> 
> The release notes could be found at [4].
> 
> Also the clirr test does not show binary incompatibilities with
> myfaces-api.
> 
> Please take a look at the "2.0.4" artifacts and vote!
> 
> Please note: This vote is "majority approval" with a minimum of three
> +1 votes (see [3]).
> 
> 
> [ ] +1 for community members who have reviewed the bits
> [ ] +0
> [ ] -1 for fatal flaws that should cause these bits not to be
> released,
>  and why..
> 
> 
> Thanks,
> Leonardo Uribe
> 
> [1]
> https://repository.apache.org/content/repositories/orgapachemyfaces-044/org/apache/myfaces/
> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
> [3] http://people.apache.org/~lu4242/myfaces204binsrc
> [4]
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600&version=12316153

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

[Martin Koci]

+1


Regards,
Martin Kočí

Gerhard Petracek píše v Po 28. 02. 2011 v 14:22 +0100:
> Hi,
> 
> 
> I was running the needed tasks to get the 4th release of Apache
> MyFaces Extensions CDI (aka MyFaces CODI) out.
> The artifacts are deployed to Nexus [1] (and [2]).
> 
> 
> The release contains the following modules:
>  - CODI Core
>  - CODI JSF Module (for 1.2 and 2.0 and 2.1)
>  - CODI JPA Module
>  - CODI BV Module
>  - CODI I18N-Message Module
>  - CODI Scripting Module
>  - CODI Trinidad Support Module
>  - CODI Distribution Modules
>  - CODI Examples
> 
> 
> Please take a look at the 0.9.3 artifacts and vote!
> 
> 
> Please note:
> This vote is "majority approval" with a minimum of three +1 votes (see
> [3]).
> 
> 
> 
> [ ] +1 for community members who have reviewed the bits
> [ ] +0
> [ ] -1 for fatal flaws that should cause these bits not to be
> released, and why..
> 
> 
> 
> Thanks,
> Gerhard
> 
> 
> [1]
> https://repository.apache.org/content/repositories/orgapachemyfaces-063
> [2]
> https://repository.apache.org/content/repositories/orgapachemyfaces-063/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/0.9.3/myfaces-extcdi-parent-0.9.3-source-release.zip
> [3] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: submittedValue vs. Converter.getAsObject

[Martin Koci]

Hi, 

is there any progress in this area? As I can see, there was no
"official" response to this problem at jsr-314-open. Should we create
request for JSF 2.2? Full thread:
http://www.mail-archive.com/dev@myfaces.apache.org/msg48796.html

I found another scenario where generic Object <-> Object conversion is
useful: rowKey concept. Many renderkits use rowKey (Object) as
replacement of indices (int) (DataModel.getRowKey instead of
DataModel.getRowIndex). But a elegant type responsible for Object  <->
rowKey (Object) is not available now. In my use cases, I need  two
different conversion chains:

1) for non-String based client: Object (a @Entity mostly) -> rowKey
(Object) and back. 

2) HTML client:  Object (@Entity) -> rowKey (Object) (serves as key in
trinidad CollectionModel for example) and then 
rowKey (Object) -> clientRowKey (String) for HTML.

In the second case, responsible types are:
A) javax.faces.convert.Converter : Object (@Entity) <-> clientRowKey
(String)
B) org.apache.myfaces.trinidad.render.ClientRowKeyManager: rowKey
(Object) <-> clientRowKey (String)
C) ... this is the missing Object <-> Object conversion type.

type A) - Converter can delegate it's resposibility to chain of C)s and
one B).


WDYT?

Kočičák



> Hi

> Ok, good to know that. Anyway, I think a full solution should something
> like the proposed solution. Let's see what happen, and if it is not included
> maybe we could include it on a project in myfaces (myfaces commons
> or tomahawk maybe).

> regards,

> Leonardo Uribe

Martin Koci píše v Čt 23. 09. 2010 v 21:40 +0200:
> Hi,
> 
> I've just read Leonardo's post at jsr-314-open about this problem.
> 
> FYI: I have finished prototype of JSF server side solution with
> non-String communication. It's based on custom renderkit and
> ResponseWriter implementation.
> 
> I found only one major problem: this one discussed in this mail thread.
> 
> Minor thing is string-based naming and meaning of ResponseWriter
> methods, because "ResponseWriter is an abstract class describing an
> adapter to an underlying output mechanism for *character*-based
> output" (from javadoc), but fortunately all methods accept Object as
> value. 
> 
> 
> Regards, 
> 
> Kočičák
> 
> Leonardo Uribe píše v St 08. 09. 2010 v 10:34 -0500:
> > Hi Martin
> > 
> > 2010/9/8 Martin Marinschek 
> > Hi Leo,
> > 
> > > Yes, to solve the problem with t:inputCalendar and
> > t:inputDate it was clear
> > > an interface like that was necessary but it is tied to
> > java.util.Date in
> > > this case:
> > 
> > 
> > We could open an issue to make this more generic - and have an
> > infrastructure in the impl where we can register such
> > converters. Then
> > we could use them for such use-cases as we have, and also for
> > Martin's
> > use-cases.
> > 
> > 
> > 
> > 
> > Ok, I'll check in deep what trinidad does and why and later I'll open
> > an issue for this one on
> > the jsf spec issue tracker.
> > 
> > best regards,
> > 
> > Leonardo
> >  
> > best regards,
> > 
> > Martin
> > 
> > --
> > 
> > http://www.irian.at
> > 
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> > 
> > Professional Support for Apache MyFaces
> > 
> > 
> 

[core] performance: ELResolvers filtering

[Martin Koci]

Hi,


after few months I have time to do some performance optimalization for
myfaces. 

This one is related to topic
http://www.mail-archive.com/dev@myfaces.apache.org/msg49177.html


Problem: 
how to disable ELResolver smartly? Adding a context-param for each is an
overkill.

But we have https://cwiki.apache.org/MYFACES/elresolver-ordering.html in
codebase already. I propose to add new feature "ELResolver filtering"
and new context-param:


  org.apache.myfaces.EL_RESOLVER_PREDICATE
  org.foo.bazz.ELResolverPredicate


Filter is simple instance of org.apache.commons.collections.Predicate.


For application where no ManagedBean(Resolver) is used or no Flash, user
can simply return false from Predicate.evaluate and ELResolver won't be
installed.

WDYT?

Regards,

Kočičák

Re: [core] performance: ELResolvers filtering

[Martin Koci]

Hi, 

see https://issues.apache.org/jira/browse/MYFACES-3075 for first version
of patch.


@Mark, 
CDI/OWB manage scopes on their own, they don't use
externalContext.getSessionMap(), applicationMap, .. is it true? If yes,
then should be possible to disable
org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver ? This
one is not in filtered list, because of code in:

org.apache.myfaces.el.unified.ResolverBuilderForFaces.build(CompositeELResolver)

// the ScopedAttributeResolver has to be the last one in every
// case, because it always sets propertyResolved to true (per the spec)
compositeElResolver.add(new ScopedAttributeResolver());


Regards,

Kočičák


Mark Struberg píše v St 16. 03. 2011 v 12:10 +:
> h hot ;)
> 
> fat +1 
> 
> Lets allow to switch off all that stuff which no one needs if running on a 
> modern stack with facelets and CDI.
> 
> LieGrue,
> strub
> 
> --- On Wed, 3/16/11, Martin Koci  wrote:
> 
> > From: Martin Koci 
> > Subject: [core] performance: ELResolvers filtering
> > To: dev@myfaces.apache.org
> > Date: Wednesday, March 16, 2011, 10:29 AM
> > Hi,
> > 
> > 
> > after few months I have time to do some performance
> > optimalization for
> > myfaces. 
> > 
> > This one is related to topic
> > http://www.mail-archive.com/dev@myfaces.apache.org/msg49177.html
> > 
> > 
> > Problem: 
> > how to disable ELResolver smartly? Adding a context-param
> > for each is an
> > overkill.
> > 
> > But we have https://cwiki.apache.org/MYFACES/elresolver-ordering.html
> > in
> > codebase already. I propose to add new feature "ELResolver
> > filtering"
> > and new context-param:
> > 
> > 
> >  
> > org.apache.myfaces.EL_RESOLVER_PREDICATE
> >  
> > org.foo.bazz.ELResolverPredicate
> > 
> > 
> > Filter is simple instance of
> > org.apache.commons.collections.Predicate.
> > 
> > 
> > For application where no ManagedBean(Resolver) is used or
> > no Flash, user
> > can simply return false from Predicate.evaluate and
> > ELResolver won't be
> > installed.
> > 
> > WDYT?
> > 
> > Regards,
> > 
> > Kočičák
> > 
> > 
> 
> 
>   
> 

Re: [core] performance: ELResolvers filtering

[Martin Koci]

This approach cannot filter two resolvers:
1. org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver
2. org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver


1) the first one is instance of CompositeELResolver and serves as
container for sorted/filtered list of others ELResolvers. Currently does
something for JSP, so I suggest to introduce:

o.a.m.SUPPORT_JSP = true|false

content-param as mentioned in original mail thread "performance:
disabling "old" technologies" and if this false, myfaces will not
install FacesCompositeELResolver, but plain javax.el.CompositeELResolver
as parent.


2) org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver is the
last one in chain and always calls setPropertyResolved(true); (JSF 2.1:
5.6.2.9 ScopedAttribute ELResolver) and pick up anything stored in the
request, viewScope,  session, or application scopes by name.

In strictly CDI-based application with no direct modification of servlet
scopes or view scope this resolver will never resolve a property.

What to do with this one I don't know. Possibly we can use ELResolver
transforming :) org.apache.commons.collections.Transformer and allow
replace one resolver with another, for example:

o.a.m.el.unified.resolver.ScopedAttributeResolver ->
MyNotResovingResolverWhichCallsSetPropertyResolvedTrue

el.ResourceBundleELResolver -> SpringMessageSourceResolver (we don't use
ResourceBundle)

el.BeanELResolver -> MemoryLeakFreeBeanELResolver

Of course this functionality can be achieved by filtering out the
unwanted resolver with predicate and adding own in faces-config (and
sort it to proper position in chain)


Regards,


Kočičák


Martin Koci píše v St 16. 03. 2011 v 11:29 +0100:
> Hi,
> 
> 
> after few months I have time to do some performance optimalization for
> myfaces. 
> 
> This one is related to topic
> http://www.mail-archive.com/dev@myfaces.apache.org/msg49177.html
> 
> 
> Problem: 
> how to disable ELResolver smartly? Adding a context-param for each is an
> overkill.
> 
> But we have https://cwiki.apache.org/MYFACES/elresolver-ordering.html in
> codebase already. I propose to add new feature "ELResolver filtering"
> and new context-param:
> 
> 
>   org.apache.myfaces.EL_RESOLVER_PREDICATE
>   org.foo.bazz.ELResolverPredicate
> 
> 
> Filter is simple instance of org.apache.commons.collections.Predicate.
> 
> 
> For application where no ManagedBean(Resolver) is used or no Flash, user
> can simply return false from Predicate.evaluate and ELResolver won't be
> installed.
> 
> WDYT?
> 
> Regards,
> 
> Kočičák
> 
> 

[core] performance: an optimal ELResolvers chain for POJO-based apps

[Martin Koci]

Hi, 

I'm optimizing render response on a large view (takes over 3 secs to
render) and below you can see results of unsorted and unfiltered
ELResolvers chain. The most important info is that  BeanELResolver
resolves property over 4x from 64000 invocations. The second place
belongs to ImplicitObjectResolver with over 2 resolved properties.
The reason why BeanElResolver is so successful is because majority of
expressions looks like
{requestScope.pojoObject.propertyOne.propertyTwo}. 


The obvious optimalization would be move the BeanELResolver to top. But
you cannot: EL spec 2.2 javax.el.BeanELResolver: "If the property is not
found or is not readable, a PropertyNotFoundException is thrown."  So
UEL spec. mandates that BeanELResolver must be last one which resolves
not-null base and a property on that base.

Do you know the reason for that? Do you have any ideas how to move
BeanELResolver to top and avoid thousands of "empty" geValue
invocations?

Thanks, 

Kočičák


Results:
ImplicitObjectResolver:
getValue invocations: 64452 getValue hits: 21018

org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver:
getValue invocations: 64336 getValue hits: 30

org.richfaces.skin.SkinPropertiesELResolver
getValue invocations: 64306 getValue hits: 0

org.richfaces.resource.ResourceParameterELResolver
getValue invocations: 64306 getValue hits: 0

org.jboss.weld.environment.servlet.jsf.WeldApplication
$LazyBeanManagerIntegrationELResolver
getValue invocations: 64306 getValue hits: 975

org.apache.myfaces.el.unified.resolver.ManagedBeanResolver
getValue invocations: 63331 getValue hits: 0

org.apache.myfaces.el.unified.resolver.ResourceResolver
getValue invocations: 63331 getValue hits: 64

javax.el.ResourceBundleELResolver
getValue invocations: 63267 getValue hits: 3

org.apache.myfaces.el.unified.resolver.ResourceBundleResolver
getValue invocations: 63264 getValue hits: 3

javax.el.MapELResolver:
getValue invocations: 63261 getValue hits: 1069

javax.el.ListELResolver:
getValue invocations: 62192 getValue hits: 0

javax.el.ArrayELResolver:
getValue invocations: 62192 getValue hits: 0

javax.el.BeanELResolver:
getValue invocations: 62192 getValue hits: 40563

org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver
getValue invocations: 21629 getValue hits: 582

Re: [core] performance: an optimal ELResolvers chain for POJO-based apps

[Martin Koci]

Hi Mark,

I don't understand your question fully. There are no JSF managed beans
involved: 

org.apache.myfaces.el.unified.resolver.ManagedBeanResolver
getValue invocations: 63331 getValue hits: 0

"getValue hits" is zero - it means that resolver doesn't not resolve
property with context.setPropertyResolved(true).

The view is composed from two lagre tables and those tables are origin
for variable in request scope : 


#{requestScope.pojoObject.property1.property2}

If you remove the "requestScope" implicit object from expression it
changes only the number for ImplicitObjectResolver, not for
BeanELResolver.

Regards,

Kočičák

Mark Struberg píše v Po 28. 03. 2011 v 19:57 +0100:
> your numbers imply that one uses JSF @ManagedBeans, isn't?
> 
> LieGrue,
> strub
> 
> --- On Mon, 3/28/11, Martin Koci  wrote:
> 
> > From: Martin Koci 
> > Subject: [core] performance: an optimal ELResolvers chain for POJO-based 
> > apps
> > To: dev@myfaces.apache.org
> > Date: Monday, March 28, 2011, 6:50 PM
> > Hi, 
> > 
> > I'm optimizing render response on a large view (takes over
> > 3 secs to
> > render) and below you can see results of unsorted and
> > unfiltered
> > ELResolvers chain. The most important info is that 
> > BeanELResolver
> > resolves property over 4x from 64000 invocations. The
> > second place
> > belongs to ImplicitObjectResolver with over 2 resolved
> > properties.
> > The reason why BeanElResolver is so successful is because
> > majority of
> > expressions looks like
> > {requestScope.pojoObject.propertyOne.propertyTwo}. 
> > 
> > 
> > The obvious optimalization would be move the BeanELResolver
> > to top. But
> > you cannot: EL spec 2.2 javax.el.BeanELResolver: "If the
> > property is not
> > found or is not readable, a PropertyNotFoundException is
> > thrown."  So
> > UEL spec. mandates that BeanELResolver must be last one
> > which resolves
> > not-null base and a property on that base.
> > 
> > Do you know the reason for that? Do you have any ideas how
> > to move
> > BeanELResolver to top and avoid thousands of "empty"
> > geValue
> > invocations?
> > 
> > Thanks, 
> > 
> > Kočičák
> > 
> > 
> > Results:
> > ImplicitObjectResolver:
> > getValue invocations: 64452 getValue hits: 21018
> > 
> > org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver:
> > getValue invocations: 64336 getValue hits: 30
> > 
> > org.richfaces.skin.SkinPropertiesELResolver
> > getValue invocations: 64306 getValue hits: 0
> > 
> > org.richfaces.resource.ResourceParameterELResolver
> > getValue invocations: 64306 getValue hits: 0
> > 
> > org.jboss.weld.environment.servlet.jsf.WeldApplication
> > $LazyBeanManagerIntegrationELResolver
> > getValue invocations: 64306 getValue hits: 975
> > 
> > org.apache.myfaces.el.unified.resolver.ManagedBeanResolver
> > getValue invocations: 63331 getValue hits: 0
> > 
> > org.apache.myfaces.el.unified.resolver.ResourceResolver
> > getValue invocations: 63331 getValue hits: 64
> > 
> > javax.el.ResourceBundleELResolver
> > getValue invocations: 63267 getValue hits: 3
> > 
> > org.apache.myfaces.el.unified.resolver.ResourceBundleResolver
> > getValue invocations: 63264 getValue hits: 3
> > 
> > javax.el.MapELResolver:
> > getValue invocations: 63261 getValue hits: 1069
> > 
> > javax.el.ListELResolver:
> > getValue invocations: 62192 getValue hits: 0
> > 
> > javax.el.ArrayELResolver:
> > getValue invocations: 62192 getValue hits: 0
> > 
> > javax.el.BeanELResolver:
> > getValue invocations: 62192 getValue hits: 40563
> > 
> > org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver
> > getValue invocations: 21629 getValue hits: 582
> > 
> > 
> 
> 
>   
> 

Re: [core] performance: an optimal ELResolvers chain for POJO-based apps

[Martin Koci]

Hi, 

the only solution which comes to my mind is update MYFACES-3075 to
support transforming (replacing one resover with another) and with some
sort of supplier support (when user wants provide own list of EL
reolvers). That will allow complete maninulation of el resolvers chain:
custom chain,sort,filter and transform.

Then we can provide a lenient BeanELResolver implementation with
behaviour: if base does not have the property returns null and allows
next resolver to take charge of getValue.

WDYT?

Kočičák

Martin Koci píše v Po 28. 03. 2011 v 20:50 +0200:
> Hi, 
> 
> I'm optimizing render response on a large view (takes over 3 secs to
> render) and below you can see results of unsorted and unfiltered
> ELResolvers chain. The most important info is that  BeanELResolver
> resolves property over 4x from 64000 invocations. The second place
> belongs to ImplicitObjectResolver with over 2 resolved properties.
> The reason why BeanElResolver is so successful is because majority of
> expressions looks like
> {requestScope.pojoObject.propertyOne.propertyTwo}. 
> 
> 
> The obvious optimalization would be move the BeanELResolver to top. But
> you cannot: EL spec 2.2 javax.el.BeanELResolver: "If the property is not
> found or is not readable, a PropertyNotFoundException is thrown."  So
> UEL spec. mandates that BeanELResolver must be last one which resolves
> not-null base and a property on that base.
> 
> Do you know the reason for that? Do you have any ideas how to move
> BeanELResolver to top and avoid thousands of "empty" geValue
> invocations?
> 
> Thanks, 
> 
> Kočičák
> 
> 
> Results:
> ImplicitObjectResolver:
> getValue invocations: 64452 getValue hits: 21018
> 
> org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver:
> getValue invocations: 64336 getValue hits: 30
> 
> org.richfaces.skin.SkinPropertiesELResolver
> getValue invocations: 64306 getValue hits: 0
> 
> org.richfaces.resource.ResourceParameterELResolver
> getValue invocations: 64306 getValue hits: 0
> 
> org.jboss.weld.environment.servlet.jsf.WeldApplication
> $LazyBeanManagerIntegrationELResolver
> getValue invocations: 64306 getValue hits: 975
> 
> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver
> getValue invocations: 63331 getValue hits: 0
> 
> org.apache.myfaces.el.unified.resolver.ResourceResolver
> getValue invocations: 63331 getValue hits: 64
> 
> javax.el.ResourceBundleELResolver
> getValue invocations: 63267 getValue hits: 3
> 
> org.apache.myfaces.el.unified.resolver.ResourceBundleResolver
> getValue invocations: 63264 getValue hits: 3
> 
> javax.el.MapELResolver:
> getValue invocations: 63261 getValue hits: 1069
> 
> javax.el.ListELResolver:
> getValue invocations: 62192 getValue hits: 0
> 
> javax.el.ArrayELResolver:
> getValue invocations: 62192 getValue hits: 0
> 
> javax.el.BeanELResolver:
> getValue invocations: 62192 getValue hits: 40563
> 
> org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver
> getValue invocations: 21629 getValue hits: 582
> 
> 

Re: [core] performance: ELResolvers filtering

[Martin Koci]

Hi,

suggested patch is here:
 https://issues.apache.org/jira/browse/MYFACES-3078

can you please review it and apply if is it proper?

Regards,

Kočičák

> Hi

> Add a param to disable JSP support looks like a good idea. With such >
param we could solve this issue raised recently:

> https://issues.apache.org/jira/browse/MYFACES-3104 MyFaces 2 with EL ?
> 2.2 in Websphere 7

> regards,

> Leonardo Uribe

2011/3/17 Martin Koci 

This approach cannot filter two resolvers:
1.
org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver
2.
org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver


1) the first one is instance of CompositeELResolver and serves
as
container for sorted/filtered list of others ELResolvers.
Currently does
something for JSP, so I suggest to introduce:

o.a.m.SUPPORT_JSP = true|false

content-param as mentioned in original mail thread "performance:
disabling "old" technologies" and if this false, myfaces will
not
install FacesCompositeELResolver, but plain
javax.el.CompositeELResolver
as parent.


2)
org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver
is the
last one in chain and always calls setPropertyResolved(true);
(JSF 2.1:
5.6.2.9 ScopedAttribute ELResolver) and pick up anything stored
in the
request, viewScope,  session, or application scopes by name.

In strictly CDI-based application with no direct modification of
servlet
scopes or view scope this resolver will never resolve a
property.

What to do with this one I don't know. Possibly we can use
ELResolver
transforming :) org.apache.commons.collections.Transformer and
allow
replace one resolver with another, for example:

o.a.m.el.unified.resolver.ScopedAttributeResolver ->
MyNotResovingResolverWhichCallsSetPropertyResolvedTrue

el.ResourceBundleELResolver -> SpringMessageSourceResolver (we
don't use
ResourceBundle)

el.BeanELResolver -> MemoryLeakFreeBeanELResolver

Of course this functionality can be achieved by filtering out
the
unwanted resolver with predicate and adding own in faces-config
(and
sort it to proper position in chain)


Regards,
    
    
Kočičák


Martin Koci píše v St 16. 03. 2011 v 11:29 +0100:

> Hi,
>
>
> after few months I have time to do some performance
optimalization for
> myfaces.
>
> This one is related to topic
>
http://www.mail-archive.com/dev@myfaces.apache.org/msg49177.html
>
>
> Problem:
> how to disable ELResolver smartly? Adding a context-param for
each is an
> overkill.
>
> But we have
https://cwiki.apache.org/MYFACES/elresolver-ordering.html in
> codebase already. I propose to add new feature "ELResolver
filtering"
> and new context-param:
>
> 
>
org.apache.myfaces.EL_RESOLVER_PREDICATE
>   org.foo.bazz.ELResolverPredicate
> 
>
> Filter is simple instance of
org.apache.commons.collections.Predicate.
>
>
> For application where no ManagedBean(Resolver) is used or no
Flash, user
> can simply return false from Predicate.evaluate and ELResolver
won't be
> installed.
>
> WDYT?
>
> Regards,
>
> Kočičák
>
>

Re: [VOTE] release for myfaces core 2.0.5

[Martin Koci]

+1

Regards,

Kočičák

Leonardo Uribe píše v Út 05. 04. 2011 v 01:02 -0500:
> +1
> 
> 2011/4/5 Leonardo Uribe 
> Hi,
> 
> I was running the needed tasks to get the 2.0.5 release of
> Apache
> MyFaces core out.
> 
> The artifacts passed all TCK tests.
> 
> Please note that this vote concerns all of the following
> parts:
>  1. Maven artifact group "org.apache.myfaces.shared" v4.0.6
> [1]
>  2. Maven artifact group "org.apache.myfaces.core" v2.0.5  [1]
> 
> The artifacts were deployed on nexus repo [1] and to my
> private 
> Apache account [3] for binary and source packages.
> 
> The release notes could be found at [4].
> 
> Also the clirr test does not show binary incompatibilities
> with myfaces-api.
> 
> Please take a look at the "2.0.5" artifacts and vote!
> 
> Please note: This vote is "majority approval" with a minimum
> of three
> +1 votes (see [3]).
> 
> 
> [ ] +1 for community members who have reviewed the bits
> [ ] +0
> [ ] -1 for fatal flaws that should cause these bits not to be
> released,
>  and why..
> 
> 
> Thanks,
> Leonardo Uribe
> 
> [1]
> 
> https://repository.apache.org/content/repositories/orgapachemyfaces-044/org/apache/myfaces/
> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
> [3] http://people.apache.org/~lu4242/myfaces205binsrc
> [4]
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600&version=12316346
> 

[core] performance: performance hints

[Martin Koci]

Hi,

is it possible to introduce performance hints in myfaces-core? Hints
similar to javax.faces.component.visit.VisitHint but related to
performance improvements. Example:

For dataTable like:

#{aExpression}

it's completely unnecessary to save per-row state. Currently there is no
elegant way how to do read-only table (state per-row is always
maintained). If user wants (fast) readOnly table, he/she must extend
UIData and re-implemenent setRowIndex method. But hint say
"org.apache.myfaces.core.UIData.saveRowState"=false can solve it
elegantly - if present (in component.getAttributes()) UIData skips
row-state-saving and restoring methods entirely.

Lifespan of those hints can be request (faceContext.attributes) or view
(component.attributes)

WDYT?

Regards,

Kočičák


See https://issues.apache.org/jira/browse/MYFACES-3111 too.

Re: [core] performance: performance hints

[Martin Koci]

Hi,

Leonardo Uribe píše v Po 25. 04. 2011 v 12:45 +0200:
> Hi
> 
> 2011/4/19 Martin Koci 
> Hi,
> 
> is it possible to introduce performance hints in myfaces-core?
> Hints
> similar to javax.faces.component.visit.VisitHint but related
> to
> performance improvements. Example:
> 
> For dataTable like:
>   
>#{aExpression}
> 
> it's completely unnecessary to save per-row state. Currently
> there is no
> elegant way how to do read-only table (state per-row is always
> maintained). If user wants (fast) readOnly table, he/she must
> extend
> UIData and re-implemenent setRowIndex method. But hint say
> "org.apache.myfaces.core.UIData.saveRowState"=false can solve
> it
> elegantly - if present (in component.getAttributes()) UIData
> skips
> row-state-saving and restoring methods entirely.
> 
> 
> Unfortunately, we can't do anything like that on default UIData
> implementation
> (it could breaks backwards behavior). I think we could include a
> property 
> on tomahawk t:dataTable called "readOnly", that just skip all that
> code
> related to save/restore for rows. That could be better, and it has
> sense to
> put in tomahawk, because after all that is the right location for
> extend
> default jsf components.

Yes, this is one point of view and I agree with that "custom behaviour
belongs into custom component". I did exactly the same for my component.

But there are other topics to consider:

0) simple presence of performance hints in core does not break the
compatibility : the *usage* of that hint can break the compatibility -
so as usual, user must know what that parameter means and what  it can
cause.

1) I think JSF implementation can break the specified functionality:
myfaces did it already with elResolvers sorting for example. But the
default must be always false for 100% compatibility with JSF
specification.

2) The hint technique is very common : another example from Java EE is
world JPA Query.setHint 

3) Hints are a simple way to realize something "this should be in core"
but because of slow specification release cycle, you must wait a year or
two to get it officially specified in public API.

4) Ease of usage: for example, if you have only one readonly table in
whole project, creation of custom component for that purpose is an
overkill: simple  is
much easier.

5) Internet is full of "JSF is slow". Although I know that is completely
untrue, "hinting the core" for more performance is a easy way which
allows users to express all they need without additional dependencies.


So, do you think we really can't put this feature in core? I mean the
"hints feature" generally, not readonly UIData - that was only an
example. 


Regards,

Kočičák

> 
> Anyway, I think it is possible to do some work on UIData to make it
> perform
> faster and better.
>  
> Lifespan of those hints can be request
> (faceContext.attributes) or view
> (component.attributes)
> 
> I don't think in this case it applies, but any configuration param for
> a view 
> should be on a tag like f:view or something similar.
> 
> regards,
> 
> Leonardo
> 
> 
> 
> WDYT?
> 
> Regards,
> 
> Kočičák
> 
> 
> See https://issues.apache.org/jira/browse/MYFACES-3111 too.
> 
> 

Re: [core] tasks for release myfaces core 2.0.6 and 2.1.0-rc

[Martin Koci]

Hi,

I see one big issue: https://issues.apache.org/jira/browse/MYFACES-3117
That may require a change in server state management, so I suggest solve
it before first 2.1 release

Another one is a big performance improvement:
https://issues.apache.org/jira/browse/MYFACES-3130 that needs
discussion.


Regards,

Kočičák

Leonardo Uribe píše v Pá 06. 05. 2011 v 11:48 -0500:
> Hi
> 
> It could be good to do a release of myfaces core 2.0.5 and 2.1.0-rc in
> 1 or 2 weeks.
> 
> The code for myfaces core 2.1.x (actually in trunk) is ready, all
> features specified by
> the spec were implemented. So to keep things moving and get some
> feedback, I think
> it could be good to do a release, so people can give a try.
> 
> After that, it could be good to do a release of tomahawk too (1.1.11).
> Most of the issues
> planned for this release were already solved, and the only thing left
> is do a cleanup for
> sandbox for jsf 2.0.
> 
> If you have some issues that needs to be included in these releases,
> it is a good
> time to say it.
> 
> best regards,
> 
> Leonardo Uribe
> 

[core] performance: use indices instead of iterator (MYFACES-3130)

[Martin Koci]

Hi,

in current codebase, myfaces use mostly enhanced loop for iterating over
chidren:

for (UIComponent child: getChildren())

that creates new instance of iterator. 

After change to plain old indices:

for (i = 0; i < childCount; i++)
  child = getChildren().get(i);

I achieved following results in my test case:

1) number of AbstractList$Itr from ~ 100 000 down to ~1500 instances per
one render/response

2) time for one render/response from ~1500ms down to ~900ms

please see https://issues.apache.org/jira/browse/MYFACES-3130 for more
details.

We know that getChildren() is type of ArrayList
(javax.faces.component._ComponentChildrenList) - in this situation is
index-based loop safe change.

But custom component can override implementation of getChildren() and
provide own implementation which can be slower: I know about Trinidad:
uses ArrayList  too, so no risk here
(org.apache.myfaces.trinidad.component.ChildArrayList)

I use RichFaces and PrimeFaces too and don't see custom implementation
of children in their codebase.

What do you think about this problem? The performance gain is pretty big
but also risky.


Regards,

Kočičák

Re: [core] performance: use indices instead of iterator (MYFACES-3130)

[Martin Koci]

Hi,

yes, every List support indexes, but it dependes on implementation if
that index-based access is fast or not. For example, ArrayList is fast,
because it uses array internally; and also flags that with interface
java.util.RandomAccess

But LinkedList for example just iterates the list until it reaches the
index you specified - there is the dangerous problem.



Mike Kienenberger píše v Út 10. 05. 2011 v 16:17 -0400:
> If getChildren() is always of type List, then it really doesn't matter
> if it's ArrayList or ChildArrayList or some other kind of list.   You
> can use indexes for any type of List.
> 
> On Tue, May 10, 2011 at 4:11 PM, Martin Koci
>  wrote:
> > Hi,
> >
> > in current codebase, myfaces use mostly enhanced loop for iterating over
> > chidren:
> >
> > for (UIComponent child: getChildren())
> >
> > that creates new instance of iterator.
> >
> > After change to plain old indices:
> >
> > for (i = 0; i < childCount; i++)
> >  child = getChildren().get(i);
> >
> > I achieved following results in my test case:
> >
> > 1) number of AbstractList$Itr from ~ 100 000 down to ~1500 instances per
> > one render/response
> >
> > 2) time for one render/response from ~1500ms down to ~900ms
> >
> > please see https://issues.apache.org/jira/browse/MYFACES-3130 for more
> > details.
> >
> > We know that getChildren() is type of ArrayList
> > (javax.faces.component._ComponentChildrenList) - in this situation is
> > index-based loop safe change.
> >
> > But custom component can override implementation of getChildren() and
> > provide own implementation which can be slower: I know about Trinidad:
> > uses ArrayList  too, so no risk here
> > (org.apache.myfaces.trinidad.component.ChildArrayList)
> >
> > I use RichFaces and PrimeFaces too and don't see custom implementation
> > of children in their codebase.
> >
> > What do you think about this problem? The performance gain is pretty big
> > but also risky.
> >
> >
> > Regards,
> >
> > Kočičák
> >
> >
> 

Re: [core] do not check for duplicate ids when saving view on production stage

[Martin Koci]

+1 for specific parameter (in one project I build view dynamically from
DB and want this ids check)

Gerhard Petracek píše v St 11. 05. 2011 v 07:52 +0200:
> hi,
> 
> 
> i would combine it -> +1 for a myfaces specific parameter which gets
> evaluated in case of project-stage production.
> 
> 
> regards,
> gerhard
> 
> http://www.irian.at
> 
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
> 
> Professional Support for Apache MyFaces
> 
> 
> 2011/5/11 Leonardo Uribe 
> Hi
> 
> Checking the state saving algorithm I have seen that every
> time
> StateManager.saveView is called, it checks for duplicate ids,
> scanning
> the whole component tree. The documentation of
> StateManager.saveView
> says this:
> 
> "...This method must also enforce the rule that, for
> components with
> non-null ids, all components that are descendants of the same
> nearest
> NamingContainer must have unique identifiers".
> 
> Yes, that's right, but a possible optimization could be do not
> do it
> if project stage is production, or maybe just add a param that
> disable
> that stuff.
> 
> Does that sounds good? Any objections?
> 
> regards,
> 
> Leonardo Uribe
> 
> 

[core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)

[Martin Koci]

Hi,


two questions :

1) can UIComponent.rendererType be ValueExpression? If yes, in which
situation is useful to use it?

2) should be rendereType saved during state saving? Each component has
setRendererType("com.foo.renderer") in constructor and/or VDL calls
setRendererType() after calling Application.createComponent()


Please see MYFACES-3136 for details

Thanks,


Kočičák

Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)

[Martin Koci]

Hi,

from spec:

.. "Because the components themselves store only a rendererType property
(a logical identifier of a particular Renderer)" ..


rendererType = " Identifier of the Renderer instance (from the set of
Renderer rendererType String instances supported by the RenderKit
associated with the component tree we are processing."

"The default value of the rendererType property must be set to" ...
(always String in spec)


JavaDoc: setRendererType - rendererType = Logical identifier of the type
of Renderer to use, or null for components that render themselves

It seems to me that rendererType is String-only, not ValueExpression.
Similar attributes are componentType and componentFamily -those are
String-only I think.

Internally in code I don't see
component.setValueExpression("rendererType", ve). 

 is not possible. 



About state saving and rendererType I found nothing.


Jakob Korherr píše v Pá 13. 05. 2011 v 16:11 +0200:
> Hi Martin,
> 
> Have you checked the JSF 2.1 and 2.0 specs yet?
> 
> Regards,
> Jakob
> 
> 2011/5/13 Martin Koci :
> > Hi,
> >
> >
> > two questions :
> >
> > 1) can UIComponent.rendererType be ValueExpression? If yes, in which
> > situation is useful to use it?
> >
> > 2) should be rendereType saved during state saving? Each component has
> > setRendererType("com.foo.renderer") in constructor and/or VDL calls
> > setRendererType() after calling Application.createComponent()
> >
> >
> > Please see MYFACES-3136 for details
> >
> > Thanks,
> >
> >
> > Kočičák
> >
> >
> >
> 
> 
> 

Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)

[Martin Koci]

Hi,

trinidad caches Renderer instance in UIXComponentBase so they at least
suppose that rendererType cannot change during one render/response and
no need for evaluate it in every getRendererType() call - see
MYFACES-3144.

Other libs I'll check.

Regards,

Kočičák

Jakob Korherr píše v Pá 13. 05. 2011 v 16:44 +0200:
> Hmm, ok.
> 
> I also can't think of a scenario where you would use something like
> this right now. But I'll think of it and do some research..
> 
> Martin, could you take a look at some of the prominent JSF component
> libs (like Primefaces, Trinidad, Tomahawk, Tobago, RichFaces,
> IceFaces) and search in their code for something like this? If you
> don't find anything there, then it should be pretty safe to remove the
> ValueExpression support from rendererType!
> 
> Regards,
> Jakob
> 
> 2011/5/13 Martin Koci :
> > Hi,
> >
> > from spec:
> >
> > .. "Because the components themselves store only a rendererType property
> > (a logical identifier of a particular Renderer)" ..
> >
> >
> > rendererType = " Identifier of the Renderer instance (from the set of
> > Renderer rendererType String instances supported by the RenderKit
> > associated with the component tree we are processing."
> >
> > "The default value of the rendererType property must be set to" ...
> > (always String in spec)
> >
> >
> > JavaDoc: setRendererType - rendererType = Logical identifier of the type
> > of Renderer to use, or null for components that render themselves
> >
> > It seems to me that rendererType is String-only, not ValueExpression.
> > Similar attributes are componentType and componentFamily -those are
> > String-only I think.
> >
> > Internally in code I don't see
> > component.setValueExpression("rendererType", ve).
> >
> >  is not possible.
> >
> >
> >
> > About state saving and rendererType I found nothing.
> >
> >
> > Jakob Korherr píše v Pá 13. 05. 2011 v 16:11 +0200:
> >> Hi Martin,
> >>
> >> Have you checked the JSF 2.1 and 2.0 specs yet?
> >>
> >> Regards,
> >> Jakob
> >>
> >> 2011/5/13 Martin Koci :
> >> > Hi,
> >> >
> >> >
> >> > two questions :
> >> >
> >> > 1) can UIComponent.rendererType be ValueExpression? If yes, in which
> >> > situation is useful to use it?
> >> >
> >> > 2) should be rendereType saved during state saving? Each component has
> >> > setRendererType("com.foo.renderer") in constructor and/or VDL calls
> >> > setRendererType() after calling Application.createComponent()
> >> >
> >> >
> >> > Please see MYFACES-3136 for details
> >> >
> >> > Thanks,
> >> >
> >> >
> >> > Kočičák
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> >
> 
> 
> 

Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)

[Martin Koci]

Leonardo Uribe píše v Pá 13. 05. 2011 v 14:59 -0500:
> Hi
> 
> +1 to both changes.

That means: replace StateHelper with attribute as MYFACES-3136 suggests,
right?

>  I agree with you about rendererType is always an
> String, there is not any mention on the spec saying rendererType could
> receive EL expressions. If someone wants to change a renderer, it uses
> a RenderKit wrapper or just define another RenderKitId to be used for
> the current application.
> 
> Please note this description of UIViewRoot.getRenderKitId :
> 
> "... Return the render kit identifier of the RenderKit associated with
> this view. Unless explicitly set, as in
> ViewHandler.createView(javax.faces.context.FacesContext,
> java.lang.String), the returned value will be null. ..."
> 
> and setRenderKitId:
> 
> "... Set the render kit identifier of the RenderKit associated with
> this view. This method may be called at any time between the end of
> Apply Request Values phase of the request processing lifecycle (i.e.
> when events are being broadcast) and the beginning of the Render
> Response phase. ..."
> 
> So any caching must preserve this behavior.

Thats very interesting, with this behaviour it is possible to change
renderkit in actionListener for example. But it also means that renderer
cannot be be cached UIComponentBase:

1) UIComponent.decode -> caches renderer
2) INVOKE_APPLICATION -> changes renderKit
3) UIComponent.encodeBegin -> uses old cached renderer

but caching is valid for all encode* method then. Any ideas how to
detect "this component will be rendered in this lifecycle" and cache
renderer even for getClientId? stateManagement calls getClientId
(checkIds) before component.encodeBegin. Can we use visitTree method for
that?

Kočičák

> 
> regards,
> 
> Leonardo
> 
> 2011/5/13 Martin Koci :
> > Hi,
> >
> > trinidad caches Renderer instance in UIXComponentBase so they at least
> > suppose that rendererType cannot change during one render/response and
> > no need for evaluate it in every getRendererType() call - see
> > MYFACES-3144.
> >
> > Other libs I'll check.
> >
> > Regards,
> >
> > Kočičák
> >
> > Jakob Korherr píše v Pá 13. 05. 2011 v 16:44 +0200:
> >> Hmm, ok.
> >>
> >> I also can't think of a scenario where you would use something like
> >> this right now. But I'll think of it and do some research..
> >>
> >> Martin, could you take a look at some of the prominent JSF component
> >> libs (like Primefaces, Trinidad, Tomahawk, Tobago, RichFaces,
> >> IceFaces) and search in their code for something like this? If you
> >> don't find anything there, then it should be pretty safe to remove the
> >> ValueExpression support from rendererType!
> >>
> >> Regards,
> >> Jakob
> >>
> >> 2011/5/13 Martin Koci :
> >> > Hi,
> >> >
> >> > from spec:
> >> >
> >> > .. "Because the components themselves store only a rendererType property
> >> > (a logical identifier of a particular Renderer)" ..
> >> >
> >> >
> >> > rendererType = " Identifier of the Renderer instance (from the set of
> >> > Renderer rendererType String instances supported by the RenderKit
> >> > associated with the component tree we are processing."
> >> >
> >> > "The default value of the rendererType property must be set to" ...
> >> > (always String in spec)
> >> >
> >> >
> >> > JavaDoc: setRendererType - rendererType = Logical identifier of the type
> >> > of Renderer to use, or null for components that render themselves
> >> >
> >> > It seems to me that rendererType is String-only, not ValueExpression.
> >> > Similar attributes are componentType and componentFamily -those are
> >> > String-only I think.
> >> >
> >> > Internally in code I don't see
> >> > component.setValueExpression("rendererType", ve).
> >> >
> >> >  is not possible.
> >> >
> >> >
> >> >
> >> > About state saving and rendererType I found nothing.
> >> >
> >> >
> >> > Jakob Korherr píše v Pá 13. 05. 2011 v 16:11 +0200:
> >> >> Hi Martin,
> >> >>
> >> >> Have you checked the JSF 2.1 and 2.0 specs yet?
> >> >>
> >> >> Regards,
> >> >> Jakob
> >> >>
> >> >> 2011/5/13 Martin Koci :
> >> >> > Hi,
> >> >> >
> >> >> >
> >> >> > two questions :
> >> >> >
> >> >> > 1) can UIComponent.rendererType be ValueExpression? If yes, in which
> >> >> > situation is useful to use it?
> >> >> >
> >> >> > 2) should be rendereType saved during state saving? Each component has
> >> >> > setRendererType("com.foo.renderer") in constructor and/or VDL calls
> >> >> > setRendererType() after calling Application.createComponent()
> >> >> >
> >> >> >
> >> >> > Please see MYFACES-3136 for details
> >> >> >
> >> >> > Thanks,
> >> >> >
> >> >> >
> >> >> > Kočičák
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >
> >
> >
> 

Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)

[Martin Koci]

One more question: UIComponent.getClientId() uses
Renderer.convertClientId

1) INVOKE_APPLICATION - action listener calls component.getClient() ->
component generates client id with renderer1 + as next step
actionListener changes renderKitId

2) RENDER_RESPOSE: renderer2 from new renderkit renders component with
clientId from renderer1!

Is that ok?
 
Leonardo Uribe píše v Pá 13. 05. 2011 v 15:45 -0500:
> Hi
> 
> 2011/5/13 Martin Koci :
> > Leonardo Uribe píše v Pá 13. 05. 2011 v 14:59 -0500:
> >> Hi
> >>
> >> +1 to both changes.
> >
> > That means: replace StateHelper with attribute as MYFACES-3136 suggests,
> > right?
> 
> That means change StateHelper.eval to StateHelper.get in
> UIComponentBase.getRendererType()
> 
> The point 3 it is not really necessary, because this property is part
> of the full state, not the delta, which is the one that consume space
> on server side state saving. I prefer keep using StateHelper but get
> instead eval.
> 
> >
> >>  I agree with you about rendererType is always an
> >> String, there is not any mention on the spec saying rendererType could
> >> receive EL expressions. If someone wants to change a renderer, it uses
> >> a RenderKit wrapper or just define another RenderKitId to be used for
> >> the current application.
> >>
> >> Please note this description of UIViewRoot.getRenderKitId :
> >>
> >> "... Return the render kit identifier of the RenderKit associated with
> >> this view. Unless explicitly set, as in
> >> ViewHandler.createView(javax.faces.context.FacesContext,
> >> java.lang.String), the returned value will be null. ..."
> >>
> >> and setRenderKitId:
> >>
> >> "... Set the render kit identifier of the RenderKit associated with
> >> this view. This method may be called at any time between the end of
> >> Apply Request Values phase of the request processing lifecycle (i.e.
> >> when events are being broadcast) and the beginning of the Render
> >> Response phase. ..."
> >>
> >> So any caching must preserve this behavior.
> >
> > Thats very interesting, with this behaviour it is possible to change
> > renderkit in actionListener for example. But it also means that renderer
> > cannot be be cached UIComponentBase:
> >
> > 1) UIComponent.decode -> caches renderer
> > 2) INVOKE_APPLICATION -> changes renderKit
> > 3) UIComponent.encodeBegin -> uses old cached renderer
> >
> > but caching is valid for all encode* method then. Any ideas how to
> > detect "this component will be rendered in this lifecycle" and cache
> > renderer even for getClientId? stateManagement calls getClientId
> > (checkIds) before component.encodeBegin. Can we use visitTree method for
> > that?
> 
> Cache as soon as you do the lookup, but clean it inside encodeAll
> call. Note some code is necessary here if encodeAll is called multiple
> times over the same instance (datatable or datalist case). Use a
> simple variable to do the trick.
> 
> Leonardo
> 

Re: [myfaces] ideas and things to do

[Martin Koci]

Gerhard Petracek píše v Út 17. 05. 2011 v 11:59 +0200:
> hi,
> 
> 
> imo we should prototype some jsf 2.2 features (at least in a branch).
> that would help the eg to specify some of the new features (like the
> window-id) easily and we can get the feedback of the whole community
> and we would have the basic implementation quite early.
> so we increase the chance that the new features won't have to be
> deprecated in the next version (see the target attribute of
> composite-components).

1 ! JSF need feedback from real usage before features are specified
(as final), not after. Only that way leads to framework with real
useability.

> since html5 is planned as a part of jsf 2.2, we should do the same
> here.
> 
> 
> @lightweight component framework
> that might fit to tomahawk.
> 
> 
> regards,
> gerhard
> 
> http://www.irian.at
> 
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
> 
> Professional Support for Apache MyFaces
> 
> 
> 2011/5/17 Mark Struberg 
> +1
> 
> Especially the advanced resource handler is a great goodie.
> Currently it is not easily possible to deliver those resources
> with a cache header. Of course there should be some additional
> work in the JSF EG, but I think Jakob pinged Ed already on
> this topic, right?
> 
> The HTML-5 components from Ali are really great stuff too, but
> might take some time to be widely supported. But anyway, being
> a step ahead is always a good thing!
> 
> 
> Also Tomahawk still contains a few features which might be
> interesting in JSF-2 (Marcus Büttner is using those)
> * file upload
> * table sorting
> * table autosuggest
> * isUserInRole (would be great in conjunction with CODI
> manages Voters?)
> There is still no really lightweight component framework for
> JSF-2.
> 
> We could of course possibly drop all the 'basic' components
> like t:inputText and stuff.
> 
> 
> LieGrue,
> strub
> 
> --- On Tue, 5/17/11, Leonardo Uribe  wrote:
> 
> > From: Leonardo Uribe 
> > Subject: [myfaces] ideas and things to do
> > To: "MyFaces Development" 
> > Date: Tuesday, May 17, 2011, 3:48 AM
> 
> > Hi
> >
> > Thinking about how can we do MyFaces even better, I think
> > we should
> > focus on these areas in the short term:
> >
> > 1. HTML 5 project: there is some code in this area, so it
> > is only
> > necessary a bit of effort to get it out.
> > 2. Enhanced Resource Handler: again we have some code.
> > 3. Agent detection support: again, there is some code
> > extracted from
> > trinidad long time ago, but now with JSF2 we can do some
> > cleanup/update over this project.
> >
> > Any suggestions?
> >
> > Leonardo Uribe
> >
> 
> 
> 

Re: [core] do not check for duplicate ids when saving view on production stage

[Martin Koci]

org.apache.myfaces.CHECK_ID_IN_PRODUCTION (default true) 

and when false:
1) skip duplicate id check 
2) skip id validity check (in UIComponent.setId)
3) ... (something we found later) ...


WDYT?


Jakob Korherr píše v So 14. 05. 2011 v 12:26 +0200:
> +1 for a MyFaces specific parameter.
> 
> Regards,
> Jakob
> 
> 2011/5/11 Martin Koci :
> > +1 for specific parameter (in one project I build view dynamically from
> > DB and want this ids check)
> >
> > Gerhard Petracek píše v St 11. 05. 2011 v 07:52 +0200:
> >> hi,
> >>
> >>
> >> i would combine it -> +1 for a myfaces specific parameter which gets
> >> evaluated in case of project-stage production.
> >>
> >>
> >> regards,
> >> gerhard
> >>
> >> http://www.irian.at
> >>
> >> Your JSF powerhouse -
> >> JSF Consulting, Development and
> >> Courses in English and German
> >>
> >> Professional Support for Apache MyFaces
> >>
> >>
> >> 2011/5/11 Leonardo Uribe 
> >> Hi
> >>
> >> Checking the state saving algorithm I have seen that every
> >> time
> >> StateManager.saveView is called, it checks for duplicate ids,
> >> scanning
> >> the whole component tree. The documentation of
> >> StateManager.saveView
> >> says this:
> >>
> >> "...This method must also enforce the rule that, for
> >> components with
> >> non-null ids, all components that are descendants of the same
> >> nearest
> >> NamingContainer must have unique identifiers".
> >>
> >> Yes, that's right, but a possible optimization could be do not
> >> do it
> >> if project stage is production, or maybe just add a param that
> >> disable
> >> that stuff.
> >>
> >> Does that sounds good? Any objections?
> >>
> >> regards,
> >>
> >> Leonardo Uribe
> >>
> >>
> >
> >
> >
> 
> 
> 

Re: [VOTE] release for myfaces core 2.1.0

[Martin Koci]

+1

Leonardo Uribe píše v Út 24. 05. 2011 v 13:29 -0500:
> +1
> 
> 2011/5/24 Leonardo Uribe :
> > Hi,
> >
> > I was running the needed tasks to get the 2.1.0 release of Apache
> > MyFaces core out.
> >
> > The artifacts passed all TCK tests.
> >
> > Please note that this vote concerns all of the following parts:
> >  1. Maven artifact group "org.apache.myfaces.shared" v4.1.0  [1]
> >  2. Maven artifact group "org.apache.myfaces.core" v2.1.0  [1]
> >
> > The artifacts were deployed on nexus repo [1] and to my private
> > Apache account [3] for binary and source packages.
> >
> > The release notes could be found at [4].
> >
> > Also the clirr test does not show binary incompatibilities with myfaces-api.
> >
> > Please take a look at the "2.1.0" artifacts and vote!
> >
> > Please note: This vote is "majority approval" with a minimum of three
> > +1 votes (see [3]).
> >
> > 
> > [ ] +1 for community members who have reviewed the bits
> > [ ] +0
> > [ ] -1 for fatal flaws that should cause these bits not to be released,
> >  and why..
> > 
> >
> > Thanks,
> > Leonardo Uribe
> >
> > [1] 
> > https://repository.apache.org/content/repositories/orgapachemyfaces-003/org/apache/myfaces/
> > [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
> > [3] http://people.apache.org/~lu4242/myfaces210binsrc
> > [4] 
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600&version=12315190
> >
> 

[core] implicit object 'component' in rendered expression (myfaces and spec bug)

[Martin Koci]

Hi,







please notice the expression:

rendered="#{component.id eq 'testId'}" 

that is clearly true.

But that does not work as expected: inputText is rendered, but never
updates model value.


Problem 1.

from specification, methods UIComponent.process* and encode*
1) If the rendered property of this {@link UIComponent}
false, skip further processing 
2) Call {@link #pushComponentToEL}

-> #{component} resolves in rendered="#{}" to parent!


Problem 2.

MyFaces implement that (pointless) requirement inconsistently: from
UIComponentBase.process*:

(!isRendered())
  return;
pushComponentToEL(context, this)

and from UIComponentBase.encodeBegin*
 pushComponentToEL(context, this);
 if (isRendered())


causes that example above renderes inputText, but never updates model.

Problem 3.

RendererUtils.renderChild(FacesContext, UIComponent): 
in this method it is unappropriate to use following code:

if (!child.isRendered()) {
return;
}
child.encodeBegin(facesContext);

because:
1) it does not take into account pushComponentToEL ( #{component}
resolves to parent)
2) behaviour is incosistent with UIComponent.encodeBegin : you'll get
"random" rendering - depends if parent of component renders it's
children or not! For this case I've created MYFACES-3126, but I'll
reopen it now, because simple remove of 'if (!child.isRendered())' does
not solve that problem and causes another problem if component
getRendersChildren = false;


What do yout think about this problem?


Regards,

Kočičák

Re: [core] implicit object 'component' in rendered expression (myfaces and spec bug)

[Martin Koci]

Hi, 

for spec I've created bug few days ago:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1002 

but I didn't realize how deep impact this bug have: I did a training
about JSF implicit objects in our company and now practically every
coder uses #{component.something} :)

For myfaces: 
https://issues.apache.org/jira/browse/MYFACES-3157


Leonardo Uribe píše v St 25. 05. 2011 v 12:36 -0500:
> Hi
> 
> I have seen that. The problem is in spec javadoc, the behavior for
> UIComponent.process*
> and encode* is clear about the ordering.
> 
> In theory, pushComponentToEL should be called before any call to
> isRendered, but after
> isTransient. Look on MyFaces UIComponentBase.processRestoreState. It has this
> 
> public void processRestoreState(FacesContext context, Object state)
> {
> if (context == null)
> {
> throw new NullPointerException("context");
> }
> 
> Object[] stateValues = (Object[]) state;
> 
> try
> {
> // Call
> UIComponent.pushComponentToEL(javax.faces.context.FacesContext,
> javax.faces.component.UIComponent)
> pushComponentToEL(context, this);
> 
> // Call the restoreState() method of this component.
> restoreState(context, stateValues[0]);
> 
> The spec javadoc says the opposite, restoreState should be called "before"
> pushComponentToEL but in practice that breaks 
> UIComponent.EventListenerWrapper.
> I reported the bug long time ago, but it wasn't fixed (I don't know why).
> 
> This case is similar. This should be fixed on the spec, but I don't
> see a reason why we shouldn't commit that into myfaces code, because
> after all, nobody relies on the buggy behavior.
> 
> I think we should open a new issue on the spec issue tracker:
> 
> http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC
> 
> but fix it on myfaces code.
> 
> regards,
> 
> Leonardo Uribe
> 
> 2011/5/25 Martin Koci :
> > Hi,
> >
> > 
> >
> > >rendered="#{component.id eq 'testId'}"   
> >value="#{bean.value}" />
> >
> > 
> >
> > please notice the expression:
> >
> > rendered="#{component.id eq 'testId'}"
> >
> > that is clearly true.
> >
> > But that does not work as expected: inputText is rendered, but never
> > updates model value.
> >
> >
> > Problem 1.
> >
> > from specification, methods UIComponent.process* and encode*
> > 1) If the rendered property of this {@link UIComponent}
> > false, skip further processing
> > 2) Call {@link #pushComponentToEL}
> >
> > -> #{component} resolves in rendered="#{}" to parent!
> >
> >
> > Problem 2.
> >
> > MyFaces implement that (pointless) requirement inconsistently: from
> > UIComponentBase.process*:
> >
> > (!isRendered())
> >  return;
> > pushComponentToEL(context, this)
> >
> > and from UIComponentBase.encodeBegin*
> >  pushComponentToEL(context, this);
> >  if (isRendered())
> >
> >
> > causes that example above renderes inputText, but never updates model.
> >
> > Problem 3.
> >
> > RendererUtils.renderChild(FacesContext, UIComponent):
> > in this method it is unappropriate to use following code:
> >
> > if (!child.isRendered()) {
> >return;
> >}
> > child.encodeBegin(facesContext);
> >
> > because:
> > 1) it does not take into account pushComponentToEL ( #{component}
> > resolves to parent)
> > 2) behaviour is incosistent with UIComponent.encodeBegin : you'll get
> > "random" rendering - depends if parent of component renders it's
> > children or not! For this case I've created MYFACES-3126, but I'll
> > reopen it now, because simple remove of 'if (!child.isRendered())' does
> > not solve that problem and causes another problem if component
> > getRendersChildren = false;
> >
> >
> > What do yout think about this problem?
> >
> >
> > Regards,
> >
> > Kočičák
> >
> >
> >
> 

Re: [core] implicit object 'component' in rendered expression (myfaces and spec bug)

[Martin Koci]

Hi,

there are such cases but not many of them: in myfaces code after quick
search I guess about 10 such cases. The "main" is in
UIComponentBase.encodeChildren and in RendererUtils.renderChild (well,
there was, but I removed it incorrectly as part of MYFACES-3126)


This affects all attributes of component, not only rendered. If renderer
encodes children, then must set up context if reads something from
child. Consider:

 

if tabbedPaneRenderer iterates over children directly and reads 'style'
property, then it must guarantee that 'component' resolves to
navigationItem otherwise it is incosistent with situation, where
navigationItem encodes itself.

This will affects complex structures like dataTable and panelGrid, I
think.

Regards,

Kočičák
 
Blake Sullivan píše v St 25. 05. 2011 v 12:42 -0700:
> I suspect that there are many cases where parent components are looking 
> at rendered on their children before deciding to traverse into these 
> children.  If EL-binding rendered to the component is supported, then 
> the parent is either going to need to stop performing this optimization, 
> or it is going to have to ensure that the context is setup and torn down 
> around each call to isRendered.
> 
> -- Blake Sullivan
> 
> On 5/25/11 11:27 AM, Martin Koci wrote:
> > Hi,
> >
> > for spec I've created bug few days ago:
> > http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1002
> >
> > but I didn't realize how deep impact this bug have: I did a training
> > about JSF implicit objects in our company and now practically every
> > coder uses #{component.something} :)
> >
> > For myfaces:
> > https://issues.apache.org/jira/browse/MYFACES-3157
> >
> >
> > Leonardo Uribe píše v St 25. 05. 2011 v 12:36 -0500:
> >> Hi
> >>
> >> I have seen that. The problem is in spec javadoc, the behavior for
> >> UIComponent.process*
> >> and encode* is clear about the ordering.
> >>
> >> In theory, pushComponentToEL should be called before any call to
> >> isRendered, but after
> >> isTransient. Look on MyFaces UIComponentBase.processRestoreState. It has 
> >> this
> >>
> >>  public void processRestoreState(FacesContext context, Object state)
> >>  {
> >>  if (context == null)
> >>  {
> >>  throw new NullPointerException("context");
> >>  }
> >>
> >>  Object[] stateValues = (Object[]) state;
> >>
> >>  try
> >>  {
> >>  // Call
> >> UIComponent.pushComponentToEL(javax.faces.context.FacesContext,
> >> javax.faces.component.UIComponent)
> >>  pushComponentToEL(context, this);
> >>
> >>  // Call the restoreState() method of this component.
> >>  restoreState(context, stateValues[0]);
> >>
> >> The spec javadoc says the opposite, restoreState should be called "before"
> >> pushComponentToEL but in practice that breaks 
> >> UIComponent.EventListenerWrapper.
> >> I reported the bug long time ago, but it wasn't fixed (I don't know why).
> >>
> >> This case is similar. This should be fixed on the spec, but I don't
> >> see a reason why we shouldn't commit that into myfaces code, because
> >> after all, nobody relies on the buggy behavior.
> >>
> >> I think we should open a new issue on the spec issue tracker:
> >>
> >> http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC
> >>
> >> but fix it on myfaces code.
> >>
> >> regards,
> >>
> >> Leonardo Uribe
> >>
> >> 2011/5/25 Martin Koci:
> >>> Hi,
> >>>
> >>> 
> >>> 
> >>>  >>> rendered="#{component.id eq 'testId'}"
> >>>   value="#{bean.value}" />
> >>> 
> >>> 
> >>>
> >>> please notice the expression:
> >>>
> >>> rendered="#{component.id eq 'testId'}"
> >>>
> >>> that is clearly true.
> >>>
> >>> But that does not work as expected: inputText is rendered, but never
> >>> updates model value.
> >>>
> >>>
> >>> Problem 1.
> >>>
> >>> from specification, methods UIComponent.process* and encode*
> >>> 1) If the rend

Re: [core] implicit object 'component' in rendered expression (myfaces and spec bug)

[Martin Koci]

Hi,

more info about this problem:

1) I did some testing of mojarra and they do the same in encodeBegin as
myfaces:
pushComponentToEL
if (!isRendered())

despite of the specification. 

2) Specification does not mention pushComponentToEL for encodeAll(),
only says "If this component returns true from isRendered(), take the
following action ... Render this component and all its children "


3) pushComponentToEL and double push:
component.pushComponentToEL(context, null);
component.pushComponentToEL(context, null);

Will be the same component pushed twice on stack?


Regards, 

Kočičák

Martin Koci píše v St 25. 05. 2011 v 22:12 +0200:
> Hi,
> 
> there are such cases but not many of them: in myfaces code after quick
> search I guess about 10 such cases. The "main" is in
> UIComponentBase.encodeChildren and in RendererUtils.renderChild (well,
> there was, but I removed it incorrectly as part of MYFACES-3126)
> 
> 
> This affects all attributes of component, not only rendered. If renderer
> encodes children, then must set up context if reads something from
> child. Consider:
> 
>  
> 
> if tabbedPaneRenderer iterates over children directly and reads 'style'
> property, then it must guarantee that 'component' resolves to
> navigationItem otherwise it is incosistent with situation, where
> navigationItem encodes itself.
> 
> This will affects complex structures like dataTable and panelGrid, I
> think.
> 
> Regards,
> 
> Kočičák
>  
> Blake Sullivan píše v St 25. 05. 2011 v 12:42 -0700:
> > I suspect that there are many cases where parent components are looking 
> > at rendered on their children before deciding to traverse into these 
> > children.  If EL-binding rendered to the component is supported, then 
> > the parent is either going to need to stop performing this optimization, 
> > or it is going to have to ensure that the context is setup and torn down 
> > around each call to isRendered.
> > 
> > -- Blake Sullivan
> > 
> > On 5/25/11 11:27 AM, Martin Koci wrote:
> > > Hi,
> > >
> > > for spec I've created bug few days ago:
> > > http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1002
> > >
> > > but I didn't realize how deep impact this bug have: I did a training
> > > about JSF implicit objects in our company and now practically every
> > > coder uses #{component.something} :)
> > >
> > > For myfaces:
> > > https://issues.apache.org/jira/browse/MYFACES-3157
> > >
> > >
> > > Leonardo Uribe píše v St 25. 05. 2011 v 12:36 -0500:
> > >> Hi
> > >>
> > >> I have seen that. The problem is in spec javadoc, the behavior for
> > >> UIComponent.process*
> > >> and encode* is clear about the ordering.
> > >>
> > >> In theory, pushComponentToEL should be called before any call to
> > >> isRendered, but after
> > >> isTransient. Look on MyFaces UIComponentBase.processRestoreState. It has 
> > >> this
> > >>
> > >>  public void processRestoreState(FacesContext context, Object state)
> > >>  {
> > >>  if (context == null)
> > >>  {
> > >>  throw new NullPointerException("context");
> > >>  }
> > >>
> > >>  Object[] stateValues = (Object[]) state;
> > >>
> > >>  try
> > >>  {
> > >>  // Call
> > >> UIComponent.pushComponentToEL(javax.faces.context.FacesContext,
> > >> javax.faces.component.UIComponent)
> > >>  pushComponentToEL(context, this);
> > >>
> > >>  // Call the restoreState() method of this component.
> > >>  restoreState(context, stateValues[0]);
> > >>
> > >> The spec javadoc says the opposite, restoreState should be called 
> > >> "before"
> > >> pushComponentToEL but in practice that breaks 
> > >> UIComponent.EventListenerWrapper.
> > >> I reported the bug long time ago, but it wasn't fixed (I don't know why).
> > >>
> > >> This case is similar. This should be fixed on the spec, but I don't
> > >> see a reason why we shouldn't commit that into myfaces code, because
> > >> after all, nobody relies on the buggy behavior.
> > >>
> > >> I think we should open a new issue on the spec issue tracker:
> > >>
> > >> http://java.net/

Re: Clear Input Values

[Martin Koci]

Hi,

javax.faces.component.EditableValueHolder.resetValue()  and/or listener
like
http://myfaces.apache.org/trinidad/trinidad-api/tagdoc/tr_resetActionListener.html
 does not solve it?

Kočičák

Mark Struberg píše v Po 30. 05. 2011 v 13:19 +0100:
> Sounds like a good idea. 
> 
> But shouldn't that be handled via the JSF EG?
> Such a behaviour would need to be written in the spec to be reliable, isn't?
> 
> LieGrue,
> strub
> 
> --- On Mon, 5/30/11, Cagatay Civici  wrote:
> 
> > From: Cagatay Civici 
> > Subject: Clear Input Values
> > To: "MyFaces Development" 
> > Date: Monday, May 30, 2011, 8:12 AM
> > Hi all,
> > 
> > I'd like to discuss something I've been thinking about
> > lately. How to clear forms easily when validation fails?
> > 
> > Consider this simple case;
> > 
> > 
> > 
> >
> > 
> > 
> >
> >  > required="true"/>
> >
> >  > required="true"/>
> > 
> >
> > 
> >
> >  > execute="@form"/>
> >
> > 
> > 
> >
> >  > actionListener="#{pprBean.reset}">
> >
> >  > execute="@this"/>
> >
> > 
> >
> > 
> >
> >  > />
> >
> > 
> > 
> > 
> > Bean;
> > 
> > private String firstname, surname;
> > 
> > public void reset() {
> > firstname = null;
> > surname = null;
> > }
> > 
> > So when you run this, if one of the field is empty and the
> > other is not, validations fails and message is displayed.
> > Problem happens when reset button is clicked to reset the
> > form values. At processValidations phase UIInput saves the
> > converted value at state
> > and since validation failed, update model is not executed
> > so local value is never cleared. Clicking reset, clears the
> > bean's values but inputText will not use the bound value and
> > use the one kept in state as well ending up a confusing
> > behavior. I've seen this in many forums.
> > 
> > I know wiki's like this;
> > 
> > http://wiki.apache.org/myfaces/ClearInputComponents
> > 
> > But I mean shouldn't this work as expected? Proposed
> > solutions seem way too hard just to clear form values.
> > (component binding and calling resetValue(), new view,
> > javascript etc.)
> > 
> > If at processValidations phase, local value is not stored
> > in state, I think that will make the code above work, but
> > I'm not sure if there will be any side effects. Does anyone
> > know why converted local value is kept at state by calling
> > setValue().
> > 
> > Cagatay
> 

[core] support implicit object 'component' in renderers where getRendersChildren is true

[Martin Koci]

Hi,

problem described in MYFACES-3157 applies for all cases where renderer
reads property from child component. I think that only correct way in
push child to EL before:

child.pushComponentToEL()
Object value = child.getValue();
String style = child.getStyle();
child.popComponentFromEL()

Is that ok? This affects about 8 renderers in myfaces-impl/shared

Kočičák 

Re: [core] TagAttributeImpl part II: object allocations (cache ELExpressions)

[Martin Koci]

Hi,

thanks for implementing it.  There are some thoughts (about EL
generally):

1) Many big views (where creation of expressions costs nonnegligible
time) use ui:param (or other tag for variable mapping) thus optimization
there is not possible. It depends on style of programming but I checked
about 30 "most important" views in our company and variablemapper always
contains a mapping so no cache is used there.

2) Cache of precompiled expression is resposibility of EL-impl
(container). JUEL does it and it is good performance improvement; about
other implementations I'm not sure.


3) summary of problem: for one attribute in xhtml, 
myfaces create :
* one instance of valueExpression with
EpressionFactory.createValueExpression
* one instance of TagValueExpression/TagValueExpressionUEL (wrapper)
* optionally one instance of LocationValueExpression (wrapper for
composite component)

* lifespan of those instances is request, so they immediatelly GCed. 
* performance of createValueExpression is unknown and depends on
implementaion of EL. 


4) summary of requirements:
* reduce number of objects created for one attribute expression (ideally
to zero)
* minimize dependency on methods with unknown performance (like
createValueExpression)
* preserve functionality of VariableMapping

The main problem for implementation of such requirements is that EL
spec. does not allow fine grained operations. 

For example we cannot provide own implementation is some factory method;

We can fill issue against EL spec and wait for years for fix (like null
-> 0 coercion problem waits for it's solution). 

Or we can cooperate with one EL-implementation to prototype some
improvements (like how to avoid decorator pattern for expressions).

Regards,

Kočičák

Leonardo Uribe píše v Po 30. 05. 2011 v 16:00 -0500:
> Hi
> 
> There is a patch proposed (after many months thinking about it),
> according to the discussion on:
> 
> http://markmail.org/message/kca64ojdvb6em367?q=%5Bcore%5D+performance:+TagAttributeImpl+part+II:+object+allocations
> 
> here:
> 
> https://issues.apache.org/jira/browse/MYFACES-3160
> 
> The idea is cache ValueExpressions when necessary to reduce
> unnecessary object allocations and increase speed, because EL parsing
> is also avoided when necessary.
> 
> I think it is a nice optimization. The idea is detect when the
> VariableMapper has a value and if so, do not cache any expression.
> Additionally, use a volatile variable to store expressions.
> 
> The patch adds a new web config param called
> org.apache.myfaces.CACHE_EL_EXPRESSIONS to enable/disable this
> feature.
> 
> @Martin Koci: since you was the one proposing this optimization, it
> could be good if you can check if it is worth or not (I'm 99% sure, so
> any help to reach 100% is welcome!) . If that so, I'll commit the
> proposed code.
> 
> regards,
> 
> Leonardo Uribe
> 

[core] performance: avoid wrapped EL Expressions

[Martin Koci]

Hi,

as discussed here:
http://markmail.org/message/kca64ojdvb6em367?q=[core]+performance:
+TagAttributeImpl+part+II:+object+allocations#query:[core]%20performance
%3A%20TagAttributeImpl%20part%20II%3A%20object%20allocations+page:1
+mid:kca64ojdvb6em367+state:results

and here:

http://markmail.org/search/?q=TagAttributeImpl+part+II%3A+object
+allocations+%28cache+ELExpressions%29#query:TagAttributeImpl%20part%
20II%3A%20object%20allocations%20%28cache%20ELExpressions%29%20from%3A%
22Leonardo%20Uribe%22+page:1+mid:pmurllp3w73q6c6s+state:results

we need to avoid unnecessary ValueExpression instances.

Here is one idea: because we cannot wait for JCP (or I don't want to),
prototype some improvements in sandbox, for example:

1)  we can create MyFacesExpressionFactory with methods
createTagValueExpression, createLocationValueExpression,
createResourceLocationValueExpression 

2) In myfaces-core-impl then create default implementation with same
code as TagAttributeImpl.getValueExpression(FaceletContext, Class) has
currently.

3) create new module myfaces-integration with additional implementations
of MyFacesExpressionFactory. For example JUELOWBMyFacesExpressionFactory
- create* methods of such implementation will create not wrapped
expression but  one instance of JUELCODIValueExpression.
JUELCODIValueExpression will use inheritance from JUEL internal API (and
some code from OWB). 

Of course it will need cooperation with JUEL/OWB developers (for example
because de.odysseus.el.TreeValueExpression from JUEL is final class). 
Solution with inheritance is proposal only, I didn't try it yet. User
must be sure that no other library wants to wrap ValueExpression.


WDYT?

Kočičák

[core] EL improvements - summary

[Martin Koci]

Hi, 

summary of ExpressionLanguage-related improvements (done or in progress)

1) ELResolvers sorting:
https://cwiki.apache.org/MYFACES/elresolver-ordering.htm

2) EL Resolvers filtering: MYFACES-3075


3) Disable JSP (and javax.faces.el) support: MYFACES-3078


4) cache ELExpressions: MYFACES-3160


disscussed: 

"an optimal ELResolvers chain for POJO-based apps"


Do you have any other ideas for improvements in this area?



Bwt. any volunteer for adapting
http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/  for
JSF/myfaces? Result can be very motivative 


Regards,


Kočičák

Re: [core] performance: avoid wrapped EL Expressions

[Martin Koci]

Hi,

the idea seems very good - but when is decided that expression does not
uses some variable resolved by VariableResolver?
TagAttributeImpl.getValue/MethodExpression methods are called in
VDL.buildView - how is  the check done? String parsing? Yes, I didn't
look in the patch, its friday :)

Another idea: during VLD.buildView handler calls
TagAttribute.getMethodExpression and populates UIComponent with it. But
with partial lifecycle you don't need them all: with execute="@this" and
render="something" others components are untouched during lifecycle. Can
we create and use some kind o  LazyValueExpression which parses and
initializes expression at first access? 

Regards,

Kočičák

Leonardo Uribe píše v Čt 02. 06. 2011 v 21:10 -0500:
> Hi
> 
> I have attached another patch to MYFACES-3160. This one has the
> ability to detect if the expression uses some variable resolved by
> facelets VariableMapper wrappers and if so, indicate the expression
> cannot be cached.
> 
> This solution will work better, because it only creates Value/Method
> expressions when it is necessary. This is a great optimization,
> because in practice most expressions are bound to managed beans, so in
> practice it will make pages render faster (because EL parsing is only
> done once and a lot of objects will not be created) and the memory
> usage will be lower (less instances means gc works less).
> 
> The only part this does not have any effect is when there is a
> ValueExpression directly on the markup. In this case, I think since
> org.apache.myfaces.view.facelets.compiler.UIInstructionHandler is
> final (that means it is inmutable), put a volatile variable for cache
> such cases will make it a mutable class, so it cannot take advantage
> of some compiler optimizations. Maybe we can create two classes, one
> to handle markup without EL and other with EL. Anyway, the most
> critical point is expressions on attributes (changes on facelets
> compiler has to be done very carefully).
> 
> JK> I would really like to see some prototyping work for JSF 2.2 in this
> JK> area directly in a MyFaces core branch!
> 
> The patch proposed on MYFACES-3160 is for MyFaces 2.0 and 2.1. After
> the latest patch I think we don't really need some work on a EL
> implementation (see explanations below).
> 
> MK>>
> MK>> we need to avoid unnecessary ValueExpression instances.
> 
> Yes, sure!. I know this optimization will be very useful, and it will
> do better use of available resource (memory and cpu).
> 
> MK>>
> MK>> Here is one idea: because we cannot wait for JCP (or I don't want to),
> MK>> prototype some improvements in sandbox, for example:
> MK>>
> MK>> 1)  we can create MyFacesExpressionFactory with methods
> MK>> createTagValueExpression, createLocationValueExpression,
> MK>> createResourceLocationValueExpression 
> MK>>
> 
> The problem here is the hacks required to make #{cc} and resource
> "this" are too myfaces specific, and are too coupled to myfaces impl.
> 
> MK>> 2) In myfaces-core-impl then create default implementation with same
> MK>> code as TagAttributeImpl.getValueExpression(FaceletContext, Class) has
> MK>> currently.
> MK>>
> 
> It could be good to have a factory pattern applied to that part.
> 
> MK>> 3) create new module myfaces-integration with additional implementations
> MK>> of MyFacesExpressionFactory. For example JUELOWBMyFacesExpressionFactory
> MK>> - create* methods of such implementation will create not wrapped
> MK>> expression but  one instance of JUELCODIValueExpression.
> MK>> JUELCODIValueExpression will use inheritance from JUEL internal API (and
> MK>> some code from OWB).
> MK>>
> MK>> Of course it will need cooperation with JUEL/OWB developers (for example
> MK>> because de.odysseus.el.TreeValueExpression from JUEL is final class).
> MK>> Solution with inheritance is proposal only, I didn't try it yet. User
> MK>> must be sure that no other library wants to wrap ValueExpression.
> MK>>
> 
> In my mind this only works as a "last resource". VariableMapper usage
> is only a concern inside facelets, because its usage is bound to the
> context the expression is created.
> 
> Anyway, I would like to know first if it is really necessary to create
> such factories. We need concrete use cases that support that. For now,
> I'll be happy with the solution proposed. It still requires a deep
> review (because the code affected is very critical) and some junit
> tests, so it will take some time before finish it.
> 
> regards,
> 
> Leonardo Uribe
> 

Re: [core] performance: avoid wrapped EL Expressions

[Martin Koci]

Hi,

Leonardo Uribe píše v Pá 03. 06. 2011 v 15:38 -0500:
> Hi
> 
> 2011/6/3 Martin Koci :
> > Hi,
> >
> > the idea seems very good - but when is decided that expression does not
> > uses some variable resolved by VariableResolver?
> 
> Inside VariableMapperWrapper.resolveVariable. If it returns a not null
> value, a variable has been resolved.
> 
> > TagAttributeImpl.getValue/MethodExpression methods are called in
> > VDL.buildView - how is  the check done? String parsing? Yes, I didn't
> > look in the patch, its friday :)
> 
> No parsing is necessary.

I didn't realize that ExpressionFactory.createValueExpression calls
VariableMapper.resolveVariable. But it have to, because (from JavaDoc) "
The object returned must access the same variable mappings regardless of
whether the mappings in the provided FunctionMapper and VariableMapper
instances change between calling
ExpressionFactory.createValueExpression() and any method on
ValueExpression"

I tried that patch and it is very effective: it reduces response time
significantly, in one test case even about ~350ms. +1 for this solution.

Regards,

Kočičák

> >
> > Another idea: during VLD.buildView handler calls
> > TagAttribute.getMethodExpression and populates UIComponent with it. But
> > with partial lifecycle you don't need them all: with execute="@this" and
> > render="something" others components are untouched during lifecycle. Can
> > we create and use some kind o  LazyValueExpression which parses and
> > initializes expression at first access?
> >
> 
> The problem here is the context. As soon as facelets has built the
> view, VariableMapper info is lost, so on such LazyValueExpression you
> need to store that information (how?). Other problem is
> FunctionMapper, because it is setup "per page" so as soon as the page
> is processed, that context is lost. I don't think it could work. I
> think the strategy proposed here is better, because all Value/Method
> expressions are on Facelets Abstract Syntax Tree (AST), so once
> created it lives as long as that Facelet lives (see
> javax.faces.FACELETS_REFRESH_PERIOD). So, ajax operations will not
> recreate EL expressions if is not necessary.
> 
> regards,
> 
> Leonardo
> 
> > Regards,
> >
> > Kočičák
> >
> > Leonardo Uribe píše v Čt 02. 06. 2011 v 21:10 -0500:
> >> Hi
> >>
> >> I have attached another patch to MYFACES-3160. This one has the
> >> ability to detect if the expression uses some variable resolved by
> >> facelets VariableMapper wrappers and if so, indicate the expression
> >> cannot be cached.
> >>
> >> This solution will work better, because it only creates Value/Method
> >> expressions when it is necessary. This is a great optimization,
> >> because in practice most expressions are bound to managed beans, so in
> >> practice it will make pages render faster (because EL parsing is only
> >> done once and a lot of objects will not be created) and the memory
> >> usage will be lower (less instances means gc works less).
> >>
> >> The only part this does not have any effect is when there is a
> >> ValueExpression directly on the markup. In this case, I think since
> >> org.apache.myfaces.view.facelets.compiler.UIInstructionHandler is
> >> final (that means it is inmutable), put a volatile variable for cache
> >> such cases will make it a mutable class, so it cannot take advantage
> >> of some compiler optimizations. Maybe we can create two classes, one
> >> to handle markup without EL and other with EL. Anyway, the most
> >> critical point is expressions on attributes (changes on facelets
> >> compiler has to be done very carefully).
> >>
> >> JK> I would really like to see some prototyping work for JSF 2.2 in this
> >> JK> area directly in a MyFaces core branch!
> >>
> >> The patch proposed on MYFACES-3160 is for MyFaces 2.0 and 2.1. After
> >> the latest patch I think we don't really need some work on a EL
> >> implementation (see explanations below).
> >>
> >> MK>>
> >> MK>> we need to avoid unnecessary ValueExpression instances.
> >>
> >> Yes, sure!. I know this optimization will be very useful, and it will
> >> do better use of available resource (memory and cpu).
> >>
> >> MK>>
> >> MK>> Here is one idea: because we cannot wait for JCP (or I don't want to),
> >> MK>> prototype some improvements in sandbox, for example:
> >> MK>&g

Re: [core] performance: avoid wrapped EL Expressions

[Martin Koci]

Hi,

what problem is it? I know about excessive "rendered" evaluation:
JAVASERVERFACES_SPEC_PUBLIC-941. "value" at EditableValueHolder can be
evaluated 2x during one request/response. 

If it is another problem, can you create a jira issue, please? 


Thanks,

Kočičák

Kito Mann píše v Pá 03. 06. 2011 v 17:58 -0400:
> Leonardo, would this reduce the number of calls to getters during
> request processing? 
> ---
> Kito D. Mann | twitter: kito99 | Author, JSF in Action
> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
> consulting
> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
> twitter: jsfcentral
> +1 203-404-4848 x3
> 
> * Listen to the latest headlines in the JSF and Java EE
> newscast: http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF
> +and+Java+EE+Newscast
> * See you at JAX and JSF Summit 2011 June 20-23rd in San
> Jose: http://jaxconf.com/
> 
> 
> On Thu, Jun 2, 2011 at 10:10 PM, Leonardo Uribe 
> wrote:
> Hi
> 
> I have attached another patch to MYFACES-3160. This one has
> the
> ability to detect if the expression uses some variable
> resolved by
> facelets VariableMapper wrappers and if so, indicate the
> expression
> cannot be cached.
> 
> This solution will work better, because it only creates
> Value/Method
> expressions when it is necessary. This is a great
> optimization,
> because in practice most expressions are bound to managed
> beans, so in
> practice it will make pages render faster (because EL parsing
> is only
> done once and a lot of objects will not be created) and the
> memory
> usage will be lower (less instances means gc works less).
> 
> The only part this does not have any effect is when there is a
> ValueExpression directly on the markup. In this case, I think
> since
> org.apache.myfaces.view.facelets.compiler.UIInstructionHandler
> is
> final (that means it is inmutable), put a volatile variable
> for cache
> such cases will make it a mutable class, so it cannot take
> advantage
> of some compiler optimizations. Maybe we can create two
> classes, one
> to handle markup without EL and other with EL. Anyway, the
> most
> critical point is expressions on attributes (changes on
> facelets
> compiler has to be done very carefully).
> 
> JK> I would really like to see some prototyping work for JSF
> 2.2 in this
> JK> area directly in a MyFaces core branch!
> 
> The patch proposed on MYFACES-3160 is for MyFaces 2.0 and 2.1.
> After
> the latest patch I think we don't really need some work on a
> EL
> implementation (see explanations below).
> 
> MK>>
> MK>> we need to avoid unnecessary ValueExpression instances.
> 
> Yes, sure!. I know this optimization will be very useful, and
> it will
> do better use of available resource (memory and cpu).
> 
> MK>>
> MK>> Here is one idea: because we cannot wait for JCP (or I
> don't want to),
> MK>> prototype some improvements in sandbox, for example:
> MK>>
> MK>> 1)  we can create MyFacesExpressionFactory with methods
> MK>> createTagValueExpression, createLocationValueExpression,
> MK>> createResourceLocationValueExpression 
> MK>>
> 
> The problem here is the hacks required to make #{cc} and
> resource
> "this" are too myfaces specific, and are too coupled to
> myfaces impl.
> 
> MK>> 2) In myfaces-core-impl then create default
> implementation with same
> MK>> code as
> TagAttributeImpl.getValueExpression(FaceletContext, Class) has
> MK>> currently.
> MK>>
> 
> It could be good to have a factory pattern applied to that
> part.
> 
> MK>> 3) create new module myfaces-integration with additional
> implementations
> MK>> of MyFacesExpressionFactory. For example
> JUELOWBMyFacesExpressionFactory
> MK>> - create* methods of such implementation will create not
> wrapped
> MK>> expression but  one instance of JUELCODIValueExpression.
> MK>> JUELCODIValueExpression will use inheritance from JUEL
> internal API (and
> MK>> some code from OWB).
> MK>>
> MK>> Of course it will need cooperation with JUEL/OWB
> developers (for example
> MK>> because de.odysseus.el.TreeValueExpression from JUEL is
> final class).
> MK>> Solution with inheritance is proposal only, I didn't try
> it yet. User
> MK>> must be sure that no other 

[core] best way for editable table

[Martin Koci]

Hi,


how to do editable table in JSF? Not with all rows/cell in editable
state,  only with those ones which user switch with icon to update
state.

Example:

   



 



Solution 1:
add ValueExpression to attribute determines state of component:



This solution has serious disadvantages:
-- you must add expression to each component
-- for required additional expression is needed:
required="#{rowData.required}" 
-- evaluation of VEs for each row is very slow


Solution 2:
use DataModelListener

Use o implementation of DataModelListener and when UIData scrolls to
row, set property of component directly:
uiComponent.setDisplayValueOnly(true|false)

Disadvantages:
-- dependency on DataModel as value for UIData
-- cannot be done from plain XHTML



What do you think about this problem? Do you know any elegant solution
for this?

Thanks,

Kočičák

Re: [core] best way for editable table

[Martin Koci]

Hi,

yes I use 1. for small tables, but consider table 200 x 200. 
Then you must have required, displayValueOnly, disabled etc for each
component - that means 200x200x3 evaluated expression during *one* JSF
phase.

Regards,


Kočičák

Werner Punz píše v Út 07. 06. 2011 v 22:05 +0200:
> opted

Re: [VOTE] release for myfaces core 2.1.1

[Martin Koci]

+1

Gerhard Petracek píše v St 08. 06. 2011 v 11:30 +0200:
> +1
> 
> regards,
> gerhard
> 
> 2011/6/8, Werner Punz :
> > +1
> >
> > Am 08.06.11 08:04, schrieb Leonardo Uribe:
> >> Hi,
> >>
> >> I was running the needed tasks to get the 2.1.1 release of Apache
> >> MyFaces core out.
> >>
> >> This is a quick bug-fix release for the following issues.
> >>
> >>   * [MYFACES-3161] - UIData.restoreDescendantComponentStates fails when
> >> empty datatable is used and a new row is created
> >>   * [MYFACES-3162] - AJAX Broken when State Caching Mechanics turned off
> >>   * [MYFACES-3165] - UIData.broadcast does not push composite component
> >> on EL stack
> >>
> >> The artifacts passed all TCK tests.
> >>
> >> Please note that this vote concerns all of the following parts:
> >>   1. Maven artifact group "org.apache.myfaces.core" v2.1.1  [1]
> >>
> >> The artifacts were deployed on nexus repo [1] and to my private
> >> Apache account [3] for binary and source packages.
> >>
> >> The release notes could be found at [4].
> >>
> >> Also the clirr test does not show binary incompatibilities with
> >> myfaces-api.
> >>
> >> Please take a look at the "2.1.1" artifacts and vote!
> >>
> >> Please note: This vote is "majority approval" with a minimum of three
> >> +1 votes (see [3]).
> >>
> >> 
> >> [ ] +1 for community members who have reviewed the bits
> >> [ ] +0
> >> [ ] -1 for fatal flaws that should cause these bits not to be released,
> >>   and why..
> >> 
> >>
> >> Thanks,
> >> Leonardo Uribe
> >>
> >> [1]
> >> https://repository.apache.org/content/repositories/orgapachemyfaces-055/org/apache/myfaces/
> >> [2] http://www.apache.org/foundation/voting.html#ReleaseVotes
> >> [3] http://people.apache.org/~lu4242/myfaces211binsrc
> >> [4]
> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600&version=12316463
> >>
> >
> >
> >
> 
> 

Re: Problem with Trinidad's uploads

[Martin Koci]

forward from us...@myfaces.apache.org:

Hi,

I tried you project and:

1) faces-config.xml is wrong, it needs  as root element,
not 

2) trinidad-config is wrong, it has  element - this one belongs
to web.xml and element  with children
does not exist: see
http://myfaces.apache.org/trinidad/devguide/fileUpload.html


Please notice that in console you can see a lots and warnings like:
8.6.2011 20:25:04
org.apache.myfaces.trinidadinternal.config.ConfigParser$Handler
endElement
WARNING: Element upload-max-memory is not understandable

After correction of 1 and 2):

3) I created /tmp/TrinidadUpload and increased
org.apache.myfaces.trinidad.UPLOAD_MAX_DISK_SPACE to 10

and it uploads 1GB file without problem.


Regards, 

Kočičák

jitechno píše v Čt 02. 06. 2011 v 03:14 -0700:
> Joachim, I put entire project (without jaf&trinidad's jars) 
> http://old.nabble.com/Re%3A-Problem-with-Trinidad%27s-uploads-p31748075.html
> on this thread.
>  If you have time to look, thanks a lot.
>  This is the same version, what I use to test.
> Oleg
>