Re: Tomahawk Partial rerender datatable column
Do you want to update a complete column or a single cell in the same row?
Which versions (MyFaces, Richfaces) do you use?
Richfaces doesn't like the forceId attribute in many cases. Try to
remove it from the datatable.
And the region around the outputtext with textVehiclename does not make
any sense.
Michael
Am 26.10.2012 04:23, schrieb daniel ccss:
Anybody
On Thu, Oct 25, 2012 at 8:54 AM, daniel ccss danielcc...@gmail.com wrote:
Hi, hope you can help me, Is there a way of update only one column of the
datatable using a4j, not updating all the datatable.
Im Using myfaces (Tomahawk)
This is what I have, a h:selectBooleanCheckbox that when is clicked the
onchange event is fire and rerender an h:outputText
t:dataTable id=data forceId=true
binding=#{VehicleBean.dataTableVehicle}
var=vehicleTable
value=#{VehicleBean.vehicleList} preserveDataModel=false rows=10
t:column
a4j:region
h:selectBooleanCheckbox .
a4j:support event=onchange reRender=*
textVehicleName*/
/h:selectBooleanCheckbox
/a4j:region
/t:column
t:column
a4j:region
t:outputText id=*textVehicleName*
value=#{vehicleTable.name}/
/a4j:region
/t:column
/t:dataTable
That code doesn´t work, If I put the outputText outside the datatable or
if i refresh al the datatable it works, but I don´t want to update all the
datatable, I want a partial rerender of only one column, hope you can help
me thanks!!!
Re: ViewExpiredException with valid session
Do you have multiple forms on your page?
Am 09.08.2012 14:11, schrieb Jarosław Szczepankiewicz:
Hi,
I have a big (for me) problem with primefaces / myfaces.
Server: tomcat 7, myfaces: 2.1.2, jdk 7, primefaces 3.3.1
I have simple managed bean with @ViewScope. I have an edit form. I access the
form with GET parameter:
/be/cms/article.faces?id=3
which is used to load the Article from DB. Form shows ok and is in session (i
observer session id and it does not change). Then I click submit button. I get:
-
[java] DEBUG [SessionTimeoutPhaseListener.java] beforePhase: RESTORE_VIEW(1)
[java] DEBUG [SessionTimeoutPhaseListener.java] NO session timeout
detected...
[java] DEBUG [SessionTimeoutPhaseListener.java] afterPhase:
RESTORE_VIEW(1)
javax.faces.application.ViewExpiredException: /be/cms/article.facesNo saved
view state could be found for the view identifier: /be/cms/article.faces
[java]at
org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:128)
~[myfaces-impl-2.1.2.jar:2.1.2]
[java]at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:171)
[myfaces-impl-2.1.2.jar:2.1.2]
[java]at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
[myfaces-impl-2.1.2.jar:2.1.2]
[java]at
javax.faces.webapp.FacesServlet.service(FacesServlet.java:189)
[myfaces-api-2.1.2.jar:2.1.2]
[java]at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
[catalina.jar:7.0.26]
[java]at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
[catalina.jar:7.0.26]
[java]at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
[catalina.jar:7.0.26]
[java]at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
[catalina.jar:7.0.26]
[java]at
org.apache.tomee.catalina.OpenEJBValve.invoke(OpenEJBValve.java:44)
[tomee-catalina-4.0.0-beta-2.jar:4.0.0-beta-2]
[java]at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
[catalina.jar:7.0.26]
[java]at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
[catalina.jar:7.0.26]
[java]at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
[catalina.jar:7.0.26]
[java]at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
[catalina.jar:7.0.26]
[java]at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
[catalina.jar:7.0.26]
[java]at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
[catalina.jar:7.0.26]
[java]at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
[tomcat-coyote.jar:7.0.26]
[java]at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
[tomcat-coyote.jar:7.0.26]
[java]at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:309)
[tomcat-coyote.jar:7.0.26]
[java]at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
Source) [na:1.7.0_03]
[java]at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source) [na:1.7.0_03]
[java]at java.lang.Thread.run(Unknown Source) [na:1.7.0_03]
---
SessionTimeoutPhaseListener is my class that implements PhaseListener, strange
thing is that phase listener shows that the exception is probably after
RESTORE_VIEW :(.
The session is not timed out. I have org.apache.myfaces.VALIDATE = true.
ID of the session does not change. I have observed the PostConstruct entrance
but no PreDestroy on my bean so probably my bean still lives and is ready to be
bound to the view, but can not force the view to be restored.
I have used the following options:
1. facelets.BUILD_BEFORE_RESTORE = TRUE, does not matter
2. javax.faces.STATE_SAVING_METHOD = client or server, does not matter
3. changing AJAX to FALSE and using direct access does not matter
The post does
I have lost almost all my hairs. I will appreciate any help advice. , thanks
in advance
Sources:
article.xhtml
--
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:p=http://primefaces.org/ui;
f:metadata
f:viewParam name=id value=#{articleEditBean.entryId}
required=true
requiredMessage=No entry specified.
f:validateLongRange minimum=1 /
/f:viewParam
f:event type=preRenderView listener=#{articleEditBean.loadEntry} /
/f:metadata
h:head
titleArtykul edycja/title
/h:head
Re: ViewExpiredException
As far as I know there is still no better fix or workaround. The portlet case is supported out of the box and the other 90% of the real world projects need this workaorund. Michael Am 08.05.2012 12:11, schrieb Paul Rivera: Hi Guys, I just had a similar problem as with the one posted in this issue: https://issues.apache.org/jira/browse/MYFACES-3159 Its about 1 year later since then. I was wondering if there is a better fix/workaround for this aside from inserting the js snippet in the link? Best Regards, Paul Rivera
Re: PPS ?
Thanks Werner for your quick repsonses. Good to know, that it's not compatible with a4j/richfaces. a4j contains some useful adons ( e.g. oncomplete for custom javascript calls after ajax calls, better queues, selfrendered outputpanels etcetc). It's too much effort at the moment to replace all ajax commands with standard components. Michael Am 03.04.2012 09:08, schrieb Werner Punz: Ok that is the explanation. Ajax4JSF introduces its own ajax lifecycle, it bypasses the standard JSF Javascripts introduced with JSF 2.0. The question is more along the lines, do you still need a4j or is the standard Ajax stuff enough. The blog entries I wrote about pps and the no_portlet_env only adheres to what MyFaces 2.x brings out of the box, I cannot speak about extension frameworks there which run their own ajax lifecycle. Werner Am 02.04.12 16:18, schrieb Michael Heinen: Hi Werner, I tested various combinations with execute set to either @this or to @region. The usage of myfaces.config.pps=true does not result is less submitted fields (checked with Fiddler2). I use a4j:commandButtons (without children) for the submits. myfaces.config.pps is set in the document head on initial page load, right after myfaces.config.no_portlet_env=true. Michael
Re: use collections with selectManyCheckboxes and JSF 2.1?
Issue created: https://issues.apache.org/jira/browse/MYFACES-3522 Am 03.04.2012 09:09, schrieb Werner Punz: Ok this seems like a bug to me, can you file a bugreport on https://issues.apache.org/jira/browse/MYFACES So that it will be fixed until the next release. Leonardo our core maintainer is pretty quick in fixing bugs. Werner Am 02.04.12 15:45, schrieb Michael Heinen: I use a List of SelectItems for the inner f:selectItems tag. The value attribute of selectManyCheckbox points to an ArrayList with Strings, representing the selected values. The checkboxes are initially correctly checked, but after ajax submission my model (MapSting,Object) contains StringArrays instead of ArrayLists. Indeed this worked well since JSF 1.0, but it does not work with 2.1 anymore in my case. BTW: I use Tomcat 6.0.35 (and selectManyCheckboxes work well with myfaces 1.2.10 and richfaces 3.3.3) Michael Am 02.04.2012 15:30, schrieb Werner Punz: Am 02.04.12 11:56, schrieb Michael Heinen: What's going wrong here? How can I use Collections with selectManyCheckboxes and JSF 2.1? Hi I usually pass a list of SelectItem Objects that has been working since JSF 1.0. Werner
use collections with selectManyCheckboxes and JSF 2.1?
Hi all,
I have another weird problem during the migration from JSF 1.2 to 2.1.
In my model I use ArrayLists for the value of selectManyCheckboxes.
If a form is now posted StringArrays are received instead of ArrayLists!
After a lot of debugging I stumbled over two new attributes:
collectionType and valueType.
I set collectionType to java.util.ArrayList and valueType to
java.lang.String.
To my surprise this did not help.
Tag usage:
t:aliasBean
t:dataList
t:selectManyCheckbox id=cboxCPsel
rendered=#{cpLink.typeSelectManyCheckBox ||
cpLink.typeTree}
disabled=#{aliasCodingPanelReadonly ||
cpLink.readOnly}
value=#{MyProxyController.myDocument.attributes[cpLink.name]}
var=sItem
collectionType=java.util.ArrayList
valueType=java.lang.String
f:selectItems value=#{MyProxyController.categories[cpLink.name]}/
/t:selectManyCheckbox
Further debugging:
org.apache.myfaces.shared_tomahawk.renderkit._SharedRendererUtils.getConvertedUISelectManyValue
line 133:
Class? modelType = expression .getType(facesContext.getELContext());
modelType is now java.lang.Object!
What's going wrong here?
How can I use Collections with selectManyCheckboxes and JSF 2.1?
libs:
tomahawk20-1.1.11.jar
myfaces 2.1.6
richfaces 4.2 Final
Regards,
Michael
Re: use collections with selectManyCheckboxes and JSF 2.1?
I use a List of SelectItems for the inner f:selectItems tag. The value attribute of selectManyCheckbox points to an ArrayList with Strings, representing the selected values. The checkboxes are initially correctly checked, but after ajax submission my model (MapSting,Object) contains StringArrays instead of ArrayLists. Indeed this worked well since JSF 1.0, but it does not work with 2.1 anymore in my case. BTW: I use Tomcat 6.0.35 (and selectManyCheckboxes work well with myfaces 1.2.10 and richfaces 3.3.3) Michael Am 02.04.2012 15:30, schrieb Werner Punz: Am 02.04.12 11:56, schrieb Michael Heinen: What's going wrong here? How can I use Collections with selectManyCheckboxes and JSF 2.1? Hi I usually pass a list of SelectItem Objects that has been working since JSF 1.0. Werner
Re: PPS ?
Hi Werner, I tested various combinations with execute set to either @this or to @region. The usage of myfaces.config.pps=true does not result is less submitted fields (checked with Fiddler2). I use a4j:commandButtons (without children) for the submits. myfaces.config.pps is set in the document head on initial page load, right after myfaces.config.no_portlet_env=true. Michael Am 02.04.2012 15:09, schrieb Werner Punz: Ok I also did a function check, for me the pps param works. What is your ajax request, (jsf.ajax.request) call do you have the execute on a parent element which needs its childs executed or on single childs. Werner Am 02.04.12 14:59, schrieb Werner Punz: Ok I did a quick check, pps should be enabled, however if you for instance have an execute=form then all the form values will be encoded I have to do a deep investigation whether the param is broken or not. Werner Am 02.04.12 14:52, schrieb Werner Punz: Am 30.03.12 15:52, schrieb Michael Heinen: Hi again, I read an article about PPS at http://werpublogs.blogspot.de/2011/07/apache-myfaces-jsfjs-queue-control.html If I understand this correctly then the data passed to the server should be reduced in ajax calls. Correct, only the controls with are in the execute part should be submitted as values. I added myfaces.config.pps = true on clientside as a script during initial page load. With Fiddler2 I cannot see any difference in the requests. The data sent to the server with ajax (via Richfaces) seems to be identical. Google does to help regarding the parameter. My project runs with MyFaces 2.1.6. The parameter is relatively beta, I will check if the functionality is broken tomorrow quickly and will drop a note regarding it. lG Werner
Re: no parallel ajax requests anymore with JSF 2.1?
Hi Milo, are you really 100% sure that this is possible with JSF 2.1 and Richfaces 4.2? Did you verify that the requests are in parallel via logging or breakpoins? I tried a few combinations of the richfaces queues which were not working in parallel. Afaik the richfaces queues are on top of the JSF queue. Nick Baleavski from Richfaces said this also (07/2011): https://community.jboss.org/message/614023#614023 JSF 2 does not allow parallel AJAX requests, they are all being queued and then sent in the serial order. Another comment from Richfaces discussions, looking for concurrent requests: https://community.jboss.org/message/648601#648601 For me this seems to be a major regression in JSF! It does support jax now but no Ajax! Could anybody explain this to me? It worked well with JSF 1.2. Now I have to start new threads manually in a web container, which I really don't like. And the migration to another JSF version is again not estimable at all. vG Michael Am 29.03.2012 15:45, schrieb Milo van der Zee: Hello Michael, in RichFaces you could add multiple queues and they won't wait for eachother. MAG, Milo van der Zee On Thu, 2012-03-29 at 15:30 +0200, Michael Heinen wrote: Hi all, I'm still converting my application (mayfaces, tomahawk and richfaces) from JSF 1.2 to 2.1. Now I noticed that parallel ajax requests are not working at all! E.g. a long running request which calculates something and parallel poll requests to fetch status or partial results until the first request is finished. I stumbled over Werner's Blog (at http://werpublogs.blogspot.de/2011/07/apache-myfaces-jsfjs-queue-control.html) which contains following statement: The official spec enforces following behavior: if you submit an Ajax post it is either sent directly if no other submit is running or enqueued until the running ajax submit has terminated and then the submit is issued. Question: Are there any workarounds to allow parallel requests? Or do I have to start new threads manually in my backing beans, which I really do not like? Is there something like a migration guide available? I read many documents and ppts about JSF 2 but never read anything about this new queing so far. Michael
PPS ?
Hi again, I read an article about PPS at http://werpublogs.blogspot.de/2011/07/apache-myfaces-jsfjs-queue-control.html If I understand this correctly then the data passed to the server should be reduced in ajax calls. I added myfaces.config.pps = true on clientside as a script during initial page load. With Fiddler2 I cannot see any difference in the requests. The data sent to the server with ajax (via Richfaces) seems to be identical. Google does to help regarding the parameter. My project runs with MyFaces 2.1.6. Does anybody use it and what is the effect? BTW: What does PPS stand for? Partial ...? Thanks, Michael
no parallel ajax requests anymore with JSF 2.1?
Hi all, I'm still converting my application (mayfaces, tomahawk and richfaces) from JSF 1.2 to 2.1. Now I noticed that parallel ajax requests are not working at all! E.g. a long running request which calculates something and parallel poll requests to fetch status or partial results until the first request is finished. I stumbled over Werner's Blog (at http://werpublogs.blogspot.de/2011/07/apache-myfaces-jsfjs-queue-control.html) which contains following statement: The official spec enforces following behavior: if you submit an Ajax post it is either sent directly if no other submit is running or enqueued until the running ajax submit has terminated and then the submit is issued. Question: Are there any workarounds to allow parallel requests? Or do I have to start new threads manually in my backing beans, which I really do not like? Is there something like a migration guide available? I read many documents and ppts about JSF 2 but never read anything about this new queing so far. Michael
Re: Clear Input Components after validation or conversion error with JSF 2.1
result = null;
for (Iterator i = base.getFacetsAndChildren(); i.hasNext();) {
UIComponent kid = (UIComponent) i.next();
// Special handling for UIForm because of the attribute
prependId
if (!(kid instanceof NamingContainer) || (kid instanceof
UIForm !((UIForm) kid).isPrependId() !id.equals(kid.getId( {
if (checkId id.equals(kid.getId())) {
result = kid;
break;
}
result = findComponent(kid, id, true);
if (result != null) {
break;
}
} else if (id.equals(kid.getId())) {
result = kid;
break;
}
}
return (result);
}
private void recursiveReset(UIComponent comp) {
if (comp instanceof EditableValueHolder) {
((EditableValueHolder) comp).resetValue();
}
for (IteratorUIComponent i = comp.getFacetsAndChildren();
i.hasNext();) {
recursiveReset(i.next());
}
}
@Override
public void beforePhase(PhaseEvent pe) {
}
@Override
public PhaseId getPhaseId() {
return PhaseId.RESTORE_VIEW;
}
}
Am 26.03.2012 17:22, schrieb Martin Koci:
Hi,
normal JSF behaviour (as you already know) is preserving and
resdisplaying the invalid input to allow re-type it later, for example:
'12-14-21 can be understood as date': a user can fix it with
minimal effort only by removing two additional zeros.
The classic solution for your problem is [1] tr:resetActionListener or
[2] pe:resetEditableValues. Do those two solve your task or is it other
problem?
a) How do I get the JSF 1.2 behavior with 2.1? Is resetValue() the
wrong method?
This is the right method.
b) Ideally I would reset only the executed components instead of all
input fields of the form. How can I determine them?
With richfaces 3.3.3 I checked for request keys representing the
submitted region or the ajaxSingle key. is there anything similar for
ajax commands and JSF 2.1?
for example pe:resetEditableValues has attribute 'for' or the standard
key javax.faces.partial.execute says it.
c) Shouldn't there be out of the box support for this szenario?
Yes, in JSF 2.2 will be such thing as pe:resetEditableValues in core (in
prefix f:)
[1]
http://myfaces.apache.org/trinidad/trinidad-api/tagdoc/tr_resetActionListener.html
[2]
http://fractalsoft.net/primeext-showcase-mojarra/views/resetEditableValues.jsf
Michael Heinen píše v Po 26. 03. 2012 v 15:22 +0200:
So I would like to clear the component values AFTER rendering and
BEFORE
state saving.
Is this possible at all?
Or do I have any better alternatives with JSF 2.1?
Thanks,
Michael
Am 26.03.2012 13:49, schrieb Michael Heinen:
Hi all,
I refer to the problem described at:
https://cwiki.apache.org/confluence/display/MYFACES/Clear+Input+Components#
Workflow:
1) Form is submitted
2) Validation or conversion fails
3) Another command is clicked that loads new or fresh data into the
same area
Problem:
The data of request (1) is shown instead of (3) because the submitted
or local values of the components are not cleared after
validation/conversion error.
Solution for JSF 1.2
I patched com.sun.facelets.FaceletViewHandler and cleared the UIInput
components via resetValue() before the new state was saved.
As a result new (fresh) data was shown correctly and the submitted
value was also shown directly after the validation/conversion error.
With JSF 2.1 this does not work the same way.
- I patched
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView
- Before accessing the state manager I iterate over the
clientIdsWithMessages, determine the correspoding form and call
resetValue for all inputComponents.
- As a result new (fresh) data is shown correctly after step (3)
- But the submitted value is NOT shown directly after the
validation/conversion error (step 2). Instead the original value is
shown.
(e.g. User clears required value and submits form, message 'Field
must not be empty' is shown and field contains the original value
instead of being empty)
Questions:
a) How do I get the JSF 1.2 behavior with 2.1? Is resetValue() the
wrong method?
b) Ideally I would reset only the executed components instead of all
input fields of the form. How can I determine them?
With richfaces 3.3.3 I checked for request keys representing the
submitted region or the ajaxSingle key. is there anything similar for
ajax commands and JSF 2.1?
c) Shouldn't there be out of the box support for this szenario?
Used versions:
MyFaces 2.1.6 with partial state saving activated
Tomahawk2 1.1.11
Richfaces 4.2.0 Final
Regards,
Michael
Re: Clear Input Components after validation or conversion error with JSF 2.1
Afaik these global ActionListeners are not called for behaviors (f:ajax
or a4j:ajax attached to a component) so it would not work for all kind
of ajax requests. Is this correct?
In my case it does also not help to run only over the parent form of the
command which submitted the request because I have multiple forms on my
pages. A command could render areas inside other forms and those
EditableValueHolders would not be reset with this approach in subsequent
requests.
I can run over the submitted form only during the request that results
in a valdiation/conversion error but in this case the INVOKE_APPLICATION
phase is not invoked. That's the dilemma.
So I'll change my ResetInputPhaseListener from after RESTORE_VIEW to
before INVOKE_APPLICATION for better state handling.
Thanks,
Michael
Am 28.03.2012 16:42, schrieb Martin Koci:
Michael Heinen píše v St 28. 03. 2012 v 16:22 +0200:
Hi,
thanks to Martin and Christan for your answers.
Trinidad and primefaces are not used in my project so far.
I had a quick look and it seems that the tr:resetActionListener as well
as the primefaces extension must be attached to all commands and I have
nearly 600. So I am looking for a more generic way.
Interesting requirement.
Try custom ActionListenerImpl. The default implementation is [1]. This
code implements the action feature at h:commandButton/link. You can
provide own implementation, find parent UIForm and clear all
EditableValueHolder in this UIForm. This is generally faster as
interating over whole UIViewRoot. Also submittedValues are part of
application state and manipulation of those value is responsibility of
invoke-application phase.
Register your implementation in faces-config.xml as:
application
action-listenermy.reset.action.Listener/action-listener
/application
[1]
https://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/main/java/org/apache/myfaces/application/ActionListenerImpl.java
Christias solution did not work in detail in combination with richfaces
4.2.Final.
The renderIds are not full qualified client ids and therefore component
lookups fail.
Moreover I would not reset self-rendered outputpanels with this approach.
But I have a workaorund now.
I use also a PhaseListener that runs afterRestoreView phase over the
complete view tree(!) and resets all EditableValueOlders.
At first I thought this would cost too much performance to run over the
complete view and to do it on every request.
But to my surprise it takes only one millisecond on my dev machine.
However I would prefer to reset only submitted components and only in
case of a validation/conversion error after rendering the invalid values
and before state saving. From my pov this should be done always
internally in JSF.
Or does it make any sense to keep the local/submitted values after a
conversion/validation error occured and after the response is rendered?
Thanks again,
Michael
Am 26.03.2012 17:35, schrieb Christian Beikov:
Hey,
the following PhaseListener implementation will do the trick, at least
this is what I would expect that should be done by jsf in general.
public class ResetInputPhaseListener implements PhaseListener {
private static final Logger log =
LoggerFactory.getLogger(ResetInputPhaseListener.class);
@Override
public void afterPhase(PhaseEvent pe) {
if
(pe.getFacesContext().getPartialViewContext().isAjaxRequest()) {
CollectionString renderIds =
pe.getFacesContext().getPartialViewContext().getRenderIds();
UIViewRoot view = pe.getFacesContext().getViewRoot();
for (String renderId : renderIds) {
UIComponent comp = findComponent(view, renderId);
if (comp != null) {
recursiveReset(comp);
} else {
log.warn(Could not find component with id ' +
renderId + ' in view ' + view.getViewId() + ');
}
}
}
}
/**
* Originally taken from Mojarra implementation of UIComponentBase
with the
* addition of special checking when the NamingContainer is of the
type UIForm.
*/
private UIComponent findComponent(UIComponent comp, String expr) {
if (expr == null) {
throw new NullPointerException();
}
FacesContext ctx = FacesContext.getCurrentInstance();
final char sepChar = UINamingContainer.getSeparatorChar(ctx);
final String SEPARATOR_STRING = String.valueOf(sepChar);
if (expr.length() == 0) {
// if an empty value is provided, fail fast.
throw new IllegalArgumentException(\\);
}
// Identify the base component from which we will perform our
search
UIComponent base = comp;
if (expr.charAt(0) == sepChar) {
// Absolute searches start at the root of the tree
while (base.getParent() != null) {
base = base.getParent
Clear Input Components after validation or conversion error with JSF 2.1
Hi all, I refer to the problem described at: https://cwiki.apache.org/confluence/display/MYFACES/Clear+Input+Components# Workflow: 1) Form is submitted 2) Validation or conversion fails 3) Another command is clicked that loads new or fresh data into the same area Problem: The data of request (1) is shown instead of (3) because the submitted or local values of the components are not cleared after validation/conversion error. Solution for JSF 1.2 I patched com.sun.facelets.FaceletViewHandler and cleared the UIInput components via resetValue() before the new state was saved. As a result new (fresh) data was shown correctly and the submitted value was also shown directly after the validation/conversion error. With JSF 2.1 this does not work the same way. - I patched org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView - Before accessing the state manager I iterate over the clientIdsWithMessages, determine the correspoding form and call resetValue for all inputComponents. - As a result new (fresh) data is shown correctly after step (3) - But the submitted value is NOT shown directly after the validation/conversion error (step 2). Instead the original value is shown. (e.g. User clears required value and submits form, message 'Field must not be empty' is shown and field contains the original value instead of being empty) Questions: a) How do I get the JSF 1.2 behavior with 2.1? Is resetValue() the wrong method? b) Ideally I would reset only the executed components instead of all input fields of the form. How can I determine them? With richfaces 3.3.3 I checked for request keys representing the submitted region or the ajaxSingle key. is there anything similar for ajax commands and JSF 2.1? c) Shouldn't there be out of the box support for this szenario? Used versions: MyFaces 2.1.6 with partial state saving activated Tomahawk2 1.1.11 Richfaces 4.2.0 Final Regards, Michael
Re: Help : tasks supported by RichFaces
Did you try the richfaces forum? https://community.jboss.org/en/richfaces?view=discussions Am 26.03.2012 12:13, schrieb ayouB __: Hello, Does RichFaces4 supports : 1) Mobile components as it's the case for PrimeFaces. 2) Charts components (graphs) 3) Reporting components (PDF, Excel, Word, ...). Thank you all.
Re: Clear Input Components after validation or conversion error with JSF 2.1
So I would like to clear the component values AFTER rendering and BEFORE state saving. Is this possible at all? Or do I have any better alternatives with JSF 2.1? Thanks, Michael Am 26.03.2012 13:49, schrieb Michael Heinen: Hi all, I refer to the problem described at: https://cwiki.apache.org/confluence/display/MYFACES/Clear+Input+Components# Workflow: 1) Form is submitted 2) Validation or conversion fails 3) Another command is clicked that loads new or fresh data into the same area Problem: The data of request (1) is shown instead of (3) because the submitted or local values of the components are not cleared after validation/conversion error. Solution for JSF 1.2 I patched com.sun.facelets.FaceletViewHandler and cleared the UIInput components via resetValue() before the new state was saved. As a result new (fresh) data was shown correctly and the submitted value was also shown directly after the validation/conversion error. With JSF 2.1 this does not work the same way. - I patched org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView - Before accessing the state manager I iterate over the clientIdsWithMessages, determine the correspoding form and call resetValue for all inputComponents. - As a result new (fresh) data is shown correctly after step (3) - But the submitted value is NOT shown directly after the validation/conversion error (step 2). Instead the original value is shown. (e.g. User clears required value and submits form, message 'Field must not be empty' is shown and field contains the original value instead of being empty) Questions: a) How do I get the JSF 1.2 behavior with 2.1? Is resetValue() the wrong method? b) Ideally I would reset only the executed components instead of all input fields of the form. How can I determine them? With richfaces 3.3.3 I checked for request keys representing the submitted region or the ajaxSingle key. is there anything similar for ajax commands and JSF 2.1? c) Shouldn't there be out of the box support for this szenario? Used versions: MyFaces 2.1.6 with partial state saving activated Tomahawk2 1.1.11 Richfaces 4.2.0 Final Regards, Michael
Re: onsumit not exeucted for ajax requests - alternative?
Thanks Werner for the suggestion. I created meanwhile a JIRA issue for this: https://issues.apache.org/jira/browse/MYFACES-3460 A global js listener is unfortunately not what I need. In my case it depends on the form, whether a js should be executed during submission or not. Some requests can run in parallel (e.g. autocompletion, pulls) while others are blocking. Do you know why the simple onsubmit of a form is not executed for ajax requests? Michael Am 06.02.2012 14:02, schrieb Werner Punz: Hi if you need to execute commands before any arbitrary ajax call then you can add your own global ajax request listener via jsf.ajax.addOnEvent(callback) The callback is called three times per request, same as if you would set it directly within the request, but on a global scale. http://docs.oracle.com/cd/E17802_01/j2ee/javaee/javaserverfaces/2.0/docs/js-api/symbols/jsf.ajax.html Unfortunately a deregistration is not possible within the jsf api within myfaces there is a way but that would break the compatibility of the code with Mojarra. Werner Am 02.02.12 11:05, schrieb Michael Heinen: Hi, I am currently migrating an application to JSF 2.1 I have a lot of ajax commands (richfaces) and some new f:ajax tags. My forms contain some js functions which should be called during onsubmit but unfortunately onsubmit is not called for ajax requests. How can I specify some JS functions that should be executed before any ajax call? I do not want to add them to a few hundred commands manually and would like to define the calls on a few spots as possible. Thanks, Michael
Re: onsumit not exeucted for ajax requests - alternative?
Werner, thanks for the explanation and pointing me to the Blog!
I'll have a look any play around with this.
Maybe RichFaces Queues are also an alternative for me because most of my
ajax commands are from Richfaces.
Thanks,
Michael
Am 06.02.2012 14:47, schrieb Werner Punz:
You can use the global listeners however, set yourself a marker
class or
an attribute in your form element which should trigger the listener
and if you get an ajax request you can check for this marker whether
you
should intercept with your code or not.
Just forgot to mention in your case to prevent double submits,
throwing an error to cancel the request is perfectly valid.
For limited time double submit prevention this might be handy as well
http://www.irian.at/de/blog/-/blogs/apache-myfaces-queue-control
Werner
Am 06.02.12 14:42, schrieb Werner Punz:
The onsubmit is a simple callback coming from the dom tree, it is not
executed during ajax because there is no form submit performed.
Have in mind on some browsers you dont even get the event with special
dom configurations (aka, simple form posts not by submit buttons etc...)
or the event cannot be blocked, so do not entirely rely on this event,
it is flakey.
For the ajax case:
You can use the global listeners however, set yourself a marker class or
an attribute in your form element which should trigger the listener
and if you get an ajax request you can check for this marker whether you
should intercept with your code or not.
Here is a short pseudo code example:
function submitHandler(data) {
if(data.status == begin) {
var src = data.source;
var form = getParentForm(src);
if(hasClass(form, myMarker)) {
intercept();
}
}
}
You cannot cancel the request that way, but at least you have a
callback. Practically by throwing an error in your code the request then
will be cancelled and an error handler will be called.
That might be a dirty way to cancel the request upfront.
Am 06.02.12 14:12, schrieb Michael Heinen:
Thanks Werner for the suggestion.
I created meanwhile a JIRA issue for this:
https://issues.apache.org/jira/browse/MYFACES-3460
A global js listener is unfortunately not what I need.
In my case it depends on the form, whether a js should be executed
during submission or not.
Some requests can run in parallel (e.g. autocompletion, pulls) while
others are blocking.
Do you know why the simple onsubmit of a form is not executed for ajax
requests?
Michael
Am 06.02.2012 14:02, schrieb Werner Punz:
Hi if you need to execute commands before any arbitrary ajax call
then you can add your own global ajax request listener via
jsf.ajax.addOnEvent(callback)
The callback is called three times per request, same as if you would
set it directly within the request, but on a global scale.
http://docs.oracle.com/cd/E17802_01/j2ee/javaee/javaserverfaces/2.0/docs/js-api/symbols/jsf.ajax.html
Unfortunately a deregistration is not possible within the jsf api
within myfaces there is a way but that would break the compatibility
of the code with Mojarra.
Werner
Am 02.02.12 11:05, schrieb Michael Heinen:
Hi,
I am currently migrating an application to JSF 2.1
I have a lot of ajax commands (richfaces) and some new f:ajax tags.
My forms contain some js functions which should be called during
onsubmit but unfortunately onsubmit is not called for ajax requests.
How can I specify some JS functions that should be executed before
any
ajax call?
I do not want to add them to a few hundred commands manually and
would
like to define the calls on a few spots as possible.
Thanks,
Michael
Re: onsumit not exeucted for ajax requests - alternative?
Hi,
onsubmit of the form is executed for the standard Command Button but not
for an Ajax Button.
I tried with myFaces 2.1.5, 2.0.11 and with mojarra 2.1.6 and 2.0.8.
Here is a very simple sample:
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
ui:composition
h:form id=myform onsubmit=alert('submitted')
h:outputText id=oldCounter value=oldCounter:
#{MyController.counter}/br/
h:outputText id=newCounter value=newCounter:
#{MyController.counter}/br/
h:commandButton value=AjaxButton
actionListener=#{MyController.increase}
f:ajax render=newCounter execute=@this/
/h:commandButtonbr/
h:commandButton value=Button actionListener=#{MyController.increase}/
/h:form
/ui:composition
/html
@ManagedBean(name = MyController)
@SessionScoped
public class MyController{
private int counter = 1;
public int getCounter() {
return counter;
}
public void increase(ActionEvent ae) {
counter++;
}
}
Is it a bug and should I add it to JIRA?
Is there any workaround to execute the js of the outer form for ajax
commands?
It was working well with JSF 1.2 and richfaces 3.3.3, but now I'm stuck
Michael
Am 02.02.2012 12:09, schrieb Milo van der Zee:
Hello Michael,
you are completely right. I have the onbegin defined on every action
initiating component but that is precisely what you don't want. That
would result in very much changes...
a4j:status id=status startText= stopText=
onstart=showAjaxActive(); onstop=hideAjaxActive();
onerror=handleError(event);/
This does handle every ajax call but then it has nothing to do with form
submissions.
I'm actually surprised that onsubmit does not work. Isn't it just a bug?
MAG,
Milo
On Thu, 2012-02-02 at 11:35 +0100, Michael Heinen wrote:
Hi Milo,
what's onbegin ? Where do i define that?
This attribute is not specifed for h:form.
See http://myfaces.apache.org/core21/myfaces-impl/tagdoc/h_form.html
Michael
Am 02.02.2012 11:21, schrieb Milo van der Zee:
Hello Michael,
might be that 'onbegin' does what you want?
MAG,
Milo van der Zee
On Thu, 2012-02-02 at 11:05 +0100, Michael Heinen wrote:
Hi,
I am currently migrating an application to JSF 2.1
I have a lot of ajax commands (richfaces) and some new f:ajax tags.
My forms contain some js functions which should be called during
onsubmit but unfortunately onsubmit is not called for ajax requests.
How can I specify some JS functions that should be executed before any
ajax call?
I do not want to add them to a few hundred commands manually and would
like to define the calls on a few spots as possible.
Thanks,
Michael
onsumit not exeucted for ajax requests - alternative?
Hi, I am currently migrating an application to JSF 2.1 I have a lot of ajax commands (richfaces) and some new f:ajax tags. My forms contain some js functions which should be called during onsubmit but unfortunately onsubmit is not called for ajax requests. How can I specify some JS functions that should be executed before any ajax call? I do not want to add them to a few hundred commands manually and would like to define the calls on a few spots as possible. Thanks, Michael
Re: onsumit not exeucted for ajax requests - alternative?
Hi Milo, what's onbegin ? Where do i define that? This attribute is not specifed for h:form. See http://myfaces.apache.org/core21/myfaces-impl/tagdoc/h_form.html Michael Am 02.02.2012 11:21, schrieb Milo van der Zee: Hello Michael, might be that 'onbegin' does what you want? MAG, Milo van der Zee On Thu, 2012-02-02 at 11:05 +0100, Michael Heinen wrote: Hi, I am currently migrating an application to JSF 2.1 I have a lot of ajax commands (richfaces) and some new f:ajax tags. My forms contain some js functions which should be called during onsubmit but unfortunately onsubmit is not called for ajax requests. How can I specify some JS functions that should be executed before any ajax call? I do not want to add them to a few hundred commands manually and would like to define the calls on a few spots as possible. Thanks, Michael
Re: NoSuchMethodError org.apache.myfaces.component.html.ext.AbstractHtmlDataTable.isPreserveRowComponentState
It was caused by a local Patch I did not see immediately
Am 19.12.2011 17:12, schrieb Michael Heinen:
Hi,
I am still migrating a myFaces/richfaces app from JSF 1.2 to 2.1
Tomahawk is updated from 12-1.1.10 to 20-1.1.11.
App runs under Tomcat 6.0.32
On pages with a t:datatable I am getting following stack:
Caused by: java.lang.NoSuchMethodError:
org.apache.myfaces.component.html.ext.AbstractHtmlDataTable.isPreserveRowComponentState()Z
at
org.apache.myfaces.component.html.ext.AbstractHtmlDataTable.markInitialState(AbstractHtmlDataTable.java:1198)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage._markInitialState(FaceletViewDeclarationLanguage.java:581)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage._markInitialState(FaceletViewDeclarationLanguage.java:591)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage._markInitialState(FaceletViewDeclarationLanguage.java:591)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage._markInitialState(FaceletViewDeclarationLanguage.java:591)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage._markInitialState(FaceletViewDeclarationLanguage.java:591)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage._markInitialState(FaceletViewDeclarationLanguage.java:591)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage._markInitialState(FaceletViewDeclarationLanguage.java:591)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage._markInitialState(FaceletViewDeclarationLanguage.java:591)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage._markInitialStateOnView(FaceletViewDeclarationLanguage.java:558)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.buildView(FaceletViewDeclarationLanguage.java:513)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:77)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
... 29 more
sample xhtml snippet:
t:dataTable id=collist
var=row
value=#{MyController.myDataModel}
rowIndexVar=index
newspaperColumns=1
styleClass=prefTable
t:column
t:div styleClass=prevTableTdDiv
t:checkbox for=:preferencesForm:columns index=#{index}/
/t:div
/t:column
/t:dataTable
Any idea?
Michael
NoSuchMethodError org.apache.myfaces.component.html.ext.AbstractHtmlDataTable.isPreserveRowComponentState
Hi,
I am still migrating a myFaces/richfaces app from JSF 1.2 to 2.1
Tomahawk is updated from 12-1.1.10 to 20-1.1.11.
App runs under Tomcat 6.0.32
On pages with a t:datatable I am getting following stack:
Caused by: java.lang.NoSuchMethodError:
org.apache.myfaces.component.html.ext.AbstractHtmlDataTable.isPreserveRowComponentState()Z
at
org.apache.myfaces.component.html.ext.AbstractHtmlDataTable.markInitialState(AbstractHtmlDataTable.java:1198)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage._markInitialState(FaceletViewDeclarationLanguage.java:581)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage._markInitialState(FaceletViewDeclarationLanguage.java:591)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage._markInitialState(FaceletViewDeclarationLanguage.java:591)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage._markInitialState(FaceletViewDeclarationLanguage.java:591)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage._markInitialState(FaceletViewDeclarationLanguage.java:591)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage._markInitialState(FaceletViewDeclarationLanguage.java:591)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage._markInitialState(FaceletViewDeclarationLanguage.java:591)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage._markInitialState(FaceletViewDeclarationLanguage.java:591)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage._markInitialStateOnView(FaceletViewDeclarationLanguage.java:558)
at
org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.buildView(FaceletViewDeclarationLanguage.java:513)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:77)
at
org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
... 29 more
sample xhtml snippet:
t:dataTable id=collist
var=row
value=#{MyController.myDataModel}
rowIndexVar=index
newspaperColumns=1
styleClass=prefTable
t:column
t:div styleClass=prevTableTdDiv
t:checkbox for=:preferencesForm:columns index=#{index}/
/t:div
/t:column
/t:dataTable
Any idea?
Michael
{Tomahawk sandbox] CompareToValidator and JSF 2.1 ?
I am right now migrating myFaces/richfaces app fronm JSF 1.2 to 2.1 and try to resolve all compile errors first (started with 230). Tomahawk must be also updated from 12-1.1.10 to 20-1.1.11. I extended the tomahawk sandbox component CompareToValidator but this is not existing anymore. What's the replacement in 2.1 or where should I look at? Is it ValidateBean or are there any official non-sandbox components available now? BTW: Is there a migration guide for JSF, myfaces or tomahawk available? Cheers, Michael
Re: My Faces Tunning
A few thoughts: - Set the NUMBER_OF_VIEWS_IN SESSION to 1 if your app does not support the browser back button! - try to reduce the number of components (e.g. conditionally controls can be excluded at compile time via c:if or via dynamic includes instead of visibleOnUserRole or rendered checks). - facelets instead of jsps - plain html tags where possible - short component ids Michael Am 17.10.2011 22:16, schrieb Boyd, David (Corporate): All, I am doing some investigation into how to shrink the amount of session memory our JSF application is consuming on a per user basis. We are using MyFaces 1.1.7 and Tomahawk 1.1.5 running on IBM Websphere 7.0 patch 19. (Not able to upgrade either of these items at this time) IBM's guideline is that the session size should be less then 5k - average around 2.5k in order not to impact performance of the server and session replication. We are currently using Memory to Memory but looking at moving to database as suggested by IBM. Our site was running at about 35M per user. We changed the number of view states from 100 to 10 and that dropped it down to around 4M. We have several backing beans which are currently session scope and are looking at changing them to request scope. I also found the following: http://www.econsulting.nl/images/pdf/Tuning%20JSF%20Applications-%20J-Sp ring%202008.pdf which seems to have a lot of information concerning how JSF handles certain content on the pages. This is still under investigation to make sure what is stated make sense. I have also read somewhere that regardless if the managed backing bean is session or request scope is that the view state will still have the bean and its content. So the view state size will not change. Looking for clarification on this one. The questions is are others facing the same issue in which JSF applications tend to consume a lot of memory for a given users session? What are some of the best practices to reduce this size if any or is this just the way when using JSF? Issues with session replication on IBM WebSphere when running a JSF application? What we see as a result of this is that in the event a user hops to another server, the session data is not present due to how large the data is and how long it takes to replicate. User experience issues. We had seen an issue in which it appeared that changes to the object in the session was not being updated correctly and have done some session management tuning in which we customize the settings so that all session attributes are written out. Looking at the .jar file it does appear that myFaces is making the call correctly when the contents of the object in the session changes. So WebSphere session listener should be picking up that change.
id of submitted command accessible in PhaseListener?
Hi, Can I determine in a PhaseListener which action/actionListener should be called or which commandButton was executed? Especially after skipping some phases due to validation or conversion errors? Michael
Re: JSF application very slow with HTTPS
Richard, I don't understand your response. What dou you mean with primefaces? Did you see similar behaviour with it and ssl? Michael Am 12.04.2011 18:13, schrieb Richard Yee: Aloysius, Read the issue. It is with PRIMEFACES. -Richard On Tue, Apr 12, 2011 at 9:07 AM, Michael Heinenmhn4...@googlemail.comwrote: Thanks Bernd for pointing to this. I tried to profile the single request with yourKit. I found some method calls that look strange to me. Note the millis are much larger due to additional profiling costs): The whole request took now around 100 seconds with tracing. - org.apache.catalina.connector.Request.isSSLAttribute(String) is called 205.000 times but it took only 671 ms (own time 499ms) - some methods like com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates() or - com.sun.net.ssl.internal.ssl.SSLSessionImpl.hashCode() are called 95.000 times (own time 2300ms) - getPeerCertificates is also called from RequestCacade.getAttributeNames as in the mentioned bug report. - org.apache.catalina.util.Enumerator.init(Iterator, boolean) has 10 seconds own time! - around 95000 javax.net.ssl.SSLPeerUnverifiedExceptions are thrown. I tested this locally with a certificate created via java keytool. Next I'll test with a real certificate Michael Am 12.04.2011 09:53, schrieb Bernd Bohmann: Hello, maybe it is a richfaces issue see: https://issues.apache.org/jira/browse/MYFACES-2823 Regards Bernd On Mon, Apr 11, 2011 at 6:42 PM, Mike Kienenbergermkien...@gmail.com wrote: Yes, I know that this method has drawbacks, but it's still a good alternative in this case as he knows what methods are involved, and he has access to the source code so he can change it at the htmlTableRenderer.encodeInnerHtml. Data method. Not everyone wants to try to set up and learn YourKit, nor evaluate it or buy it or any of the other serious profilers. If you've already got a profiler installed and are familiar with it, go with that. :) This is a quick-and-dirty solution that's often worked for me. I've got the eclipse profiler installed, and I've had YourKit installed before, but this is often the simplest path for me. You can have the results back from this in the time it takes to 1) download the h2database jar and drop it into your project, 2) change the code, 3) recompile the app, 4) run it. On Mon, Apr 11, 2011 at 12:31 PM, Mark Strubergstrub...@yahoo.de wrote: yea, but most of the time you a) don't exactly know what you r looking for b) don't like to change your code c) will get the the lifecycle wrappers back as 'most expensive' methods... LieGrue, strub --- On Mon, 4/11/11, Mike Kienenbergermkien...@gmail.com wrote: From: Mike Kienenbergermkien...@gmail.com Subject: Re: JSF application very slow with HTTPS To: MyFaces Discussionusers@myfaces.apache.org Cc: Mark Strubergstrub...@yahoo.de Date: Monday, April 11, 2011, 4:27 PM Or you can go with something a lot simpler and start with the free profiler provided in the H2Database jar. import org.h2.util; ... Profiler profiler = new Profiler(); profiler.startCollecting(); // application code System.out.println(profiler.getTop(3)); http://www.h2database.com/html/performance.html#application_profiling For my own use, I've pulled out the three relevant classes and removed the unnecessary methods if you don't want to grab the entire package, although that's really trivial to do as well. It's about 350 lines of code total. On Mon, Apr 11, 2011 at 12:12 PM, Mark Strubergstrub...@yahoo.de wrote: Ah sorry, have overread that: The time is spent in htmlTableRenderer.encodeInnerHtml I'd start the application with YourKit profiler and do some profiling. You can get a free yourkit test license (14 days I think) for evaluation. LieGrue, strub --- On Mon, 4/11/11, Michael Heinenmhn4...@googlemail.com wrote: From: Michael Heinenmhn4...@googlemail.com Subject: Re: JSF application very slow with HTTPS To: MyFaces Discussionusers@myfaces.apache.org Date: Monday, April 11, 2011, 3:45 PM Fat? Well there is a lot of EL in this table, nearly in all cells, e.g. for column widths, values, styles etc. The EL is always hitting backing beans, some with additional map access. But the real problem is the poor HTTPS performance compared to HTTP. It should not be caused by the app and also not by JSF or Tomcat of course. There should be a little overhead for additional handshaking, but not for the rendering! Could this be caused by a buffering whereever? Mark (or anybody else), did you compare your app with http and https? Just wondering whether this is a problem only in my app. Regards, Michael Am 11.04.2011 17:27, schrieb Mark Struberg: Btw another question: 1s local response time? How fat is this page? We have a really big page in production with 1400 lines in a dataTable - and it renders in 450 ms... How many back-and-forth requests do you see if you open firebug? Do you have some EL involved which
Re: JSF application very slow with HTTPS
The issue is solved. It was a bug in Tomcat, created in version 6.0.28 and fixed in 6.0.30! See https://issues.apache.org/bugzilla/show_bug.cgi?id=49613 Michael Am 12.04.2011 18:13, schrieb Richard Yee: Aloysius, Read the issue. It is with PRIMEFACES. -Richard On Tue, Apr 12, 2011 at 9:07 AM, Michael Heinenmhn4...@googlemail.comwrote: Thanks Bernd for pointing to this. I tried to profile the single request with yourKit. I found some method calls that look strange to me. Note the millis are much larger due to additional profiling costs): The whole request took now around 100 seconds with tracing. - org.apache.catalina.connector.Request.isSSLAttribute(String) is called 205.000 times but it took only 671 ms (own time 499ms) - some methods like com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates() or - com.sun.net.ssl.internal.ssl.SSLSessionImpl.hashCode() are called 95.000 times (own time 2300ms) - getPeerCertificates is also called from RequestCacade.getAttributeNames as in the mentioned bug report. - org.apache.catalina.util.Enumerator.init(Iterator, boolean) has 10 seconds own time! - around 95000 javax.net.ssl.SSLPeerUnverifiedExceptions are thrown. I tested this locally with a certificate created via java keytool. Next I'll test with a real certificate Michael Am 12.04.2011 09:53, schrieb Bernd Bohmann: Hello, maybe it is a richfaces issue see: https://issues.apache.org/jira/browse/MYFACES-2823 Regards Bernd On Mon, Apr 11, 2011 at 6:42 PM, Mike Kienenbergermkien...@gmail.com wrote: Yes, I know that this method has drawbacks, but it's still a good alternative in this case as he knows what methods are involved, and he has access to the source code so he can change it at the htmlTableRenderer.encodeInnerHtml. Data method. Not everyone wants to try to set up and learn YourKit, nor evaluate it or buy it or any of the other serious profilers. If you've already got a profiler installed and are familiar with it, go with that. :) This is a quick-and-dirty solution that's often worked for me. I've got the eclipse profiler installed, and I've had YourKit installed before, but this is often the simplest path for me. You can have the results back from this in the time it takes to 1) download the h2database jar and drop it into your project, 2) change the code, 3) recompile the app, 4) run it. On Mon, Apr 11, 2011 at 12:31 PM, Mark Strubergstrub...@yahoo.de wrote: yea, but most of the time you a) don't exactly know what you r looking for b) don't like to change your code c) will get the the lifecycle wrappers back as 'most expensive' methods... LieGrue, strub --- On Mon, 4/11/11, Mike Kienenbergermkien...@gmail.com wrote: From: Mike Kienenbergermkien...@gmail.com Subject: Re: JSF application very slow with HTTPS To: MyFaces Discussionusers@myfaces.apache.org Cc: Mark Strubergstrub...@yahoo.de Date: Monday, April 11, 2011, 4:27 PM Or you can go with something a lot simpler and start with the free profiler provided in the H2Database jar. import org.h2.util; ... Profiler profiler = new Profiler(); profiler.startCollecting(); // application code System.out.println(profiler.getTop(3)); http://www.h2database.com/html/performance.html#application_profiling For my own use, I've pulled out the three relevant classes and removed the unnecessary methods if you don't want to grab the entire package, although that's really trivial to do as well. It's about 350 lines of code total. On Mon, Apr 11, 2011 at 12:12 PM, Mark Strubergstrub...@yahoo.de wrote: Ah sorry, have overread that: The time is spent in htmlTableRenderer.encodeInnerHtml I'd start the application with YourKit profiler and do some profiling. You can get a free yourkit test license (14 days I think) for evaluation. LieGrue, strub --- On Mon, 4/11/11, Michael Heinenmhn4...@googlemail.com wrote: From: Michael Heinenmhn4...@googlemail.com Subject: Re: JSF application very slow with HTTPS To: MyFaces Discussionusers@myfaces.apache.org Date: Monday, April 11, 2011, 3:45 PM Fat? Well there is a lot of EL in this table, nearly in all cells, e.g. for column widths, values, styles etc. The EL is always hitting backing beans, some with additional map access. But the real problem is the poor HTTPS performance compared to HTTP. It should not be caused by the app and also not by JSF or Tomcat of course. There should be a little overhead for additional handshaking, but not for the rendering! Could this be caused by a buffering whereever? Mark (or anybody else), did you compare your app with http and https? Just wondering whether this is a problem only in my app. Regards, Michael Am 11.04.2011 17:27, schrieb Mark Struberg: Btw another question: 1s local response time? How fat is this page? We have a really big page in production with 1400 lines in a dataTable - and it renders in 450 ms... How many back-and-forth requests do you see if you open firebug? Do you
Re: JSF application very slow with HTTPS
Thanks Bernd for pointing to this. I tried to profile the single request with yourKit. I found some method calls that look strange to me. Note the millis are much larger due to additional profiling costs): The whole request took now around 100 seconds with tracing. - org.apache.catalina.connector.Request.isSSLAttribute(String) is called 205.000 times but it took only 671 ms (own time 499ms) - some methods like com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates() or - com.sun.net.ssl.internal.ssl.SSLSessionImpl.hashCode() are called 95.000 times (own time 2300ms) - getPeerCertificates is also called from RequestCacade.getAttributeNames as in the mentioned bug report. - org.apache.catalina.util.Enumerator.init(Iterator, boolean) has 10 seconds own time! - around 95000 javax.net.ssl.SSLPeerUnverifiedExceptions are thrown. I tested this locally with a certificate created via java keytool. Next I'll test with a real certificate Michael Am 12.04.2011 09:53, schrieb Bernd Bohmann: Hello, maybe it is a richfaces issue see: https://issues.apache.org/jira/browse/MYFACES-2823 Regards Bernd On Mon, Apr 11, 2011 at 6:42 PM, Mike Kienenbergermkien...@gmail.com wrote: Yes, I know that this method has drawbacks, but it's still a good alternative in this case as he knows what methods are involved, and he has access to the source code so he can change it at the htmlTableRenderer.encodeInnerHtml. Data method. Not everyone wants to try to set up and learn YourKit, nor evaluate it or buy it or any of the other serious profilers. If you've already got a profiler installed and are familiar with it, go with that. :) This is a quick-and-dirty solution that's often worked for me. I've got the eclipse profiler installed, and I've had YourKit installed before, but this is often the simplest path for me. You can have the results back from this in the time it takes to 1) download the h2database jar and drop it into your project, 2) change the code, 3) recompile the app, 4) run it. On Mon, Apr 11, 2011 at 12:31 PM, Mark Strubergstrub...@yahoo.de wrote: yea, but most of the time you a) don't exactly know what you r looking for b) don't like to change your code c) will get the the lifecycle wrappers back as 'most expensive' methods... LieGrue, strub --- On Mon, 4/11/11, Mike Kienenbergermkien...@gmail.com wrote: From: Mike Kienenbergermkien...@gmail.com Subject: Re: JSF application very slow with HTTPS To: MyFaces Discussionusers@myfaces.apache.org Cc: Mark Strubergstrub...@yahoo.de Date: Monday, April 11, 2011, 4:27 PM Or you can go with something a lot simpler and start with the free profiler provided in the H2Database jar. import org.h2.util; ... Profiler profiler = new Profiler(); profiler.startCollecting(); // application code System.out.println(profiler.getTop(3)); http://www.h2database.com/html/performance.html#application_profiling For my own use, I've pulled out the three relevant classes and removed the unnecessary methods if you don't want to grab the entire package, although that's really trivial to do as well. It's about 350 lines of code total. On Mon, Apr 11, 2011 at 12:12 PM, Mark Strubergstrub...@yahoo.de wrote: Ah sorry, have overread that: The time is spent in htmlTableRenderer.encodeInnerHtml I'd start the application with YourKit profiler and do some profiling. You can get a free yourkit test license (14 days I think) for evaluation. LieGrue, strub --- On Mon, 4/11/11, Michael Heinenmhn4...@googlemail.com wrote: From: Michael Heinenmhn4...@googlemail.com Subject: Re: JSF application very slow with HTTPS To: MyFaces Discussionusers@myfaces.apache.org Date: Monday, April 11, 2011, 3:45 PM Fat? Well there is a lot of EL in this table, nearly in all cells, e.g. for column widths, values, styles etc. The EL is always hitting backing beans, some with additional map access. But the real problem is the poor HTTPS performance compared to HTTP. It should not be caused by the app and also not by JSF or Tomcat of course. There should be a little overhead for additional handshaking, but not for the rendering! Could this be caused by a buffering whereever? Mark (or anybody else), did you compare your app with http and https? Just wondering whether this is a problem only in my app. Regards, Michael Am 11.04.2011 17:27, schrieb Mark Struberg: Btw another question: 1s local response time? How fat is this page? We have a really big page in production with 1400 lines in a dataTable - and it renders in 450 ms... How many back-and-forth requests do you see if you open firebug? Do you have some EL involved which isn't hitting the backing bean but directly goes into the database? Something in this direction... LieGrue, strub --- On Mon, 4/11/11, Mike Kienenbergermkien...@gmail.com wrote: From: Mike Kienenbergermkien...@gmail.com Subject: Re: JSF application very slow with HTTPS To: MyFaces Discussionusers@myfaces.apache.org Cc:
JSF application very slow with HTTPS
Hi, My JSF application is very slow via HTTPS. Some parts are 15 times slower compared to HTTP I measured the response times of the xhtml requests with Fiddler (locally and over network) Result for a very large page (512 KB) with a big datatable without ajax usage: -- local access with HTTP: 1 sec -- local access with HTTPS: 15-16 sec Other pages are factor 2-4 slower, with or without ajax. The time is spent in htmlTableRenderer.encodeInnerHtml. Data is of course available, there is no additional backend access. The simple download of xhtml files or other files is NOT (noticeable) slower. Other non JSF applications running on the same servers are also not slower with HTTPS. Before I start profiling: - Does anybody have an idea where I should look at? - Are there any known JSF or webApp settings that influence https performance? Environment: Facelets myFaces 1.2.9 tomahawk12_1.1.10 richfaces 3.3.3 tomcat 6.0.29 jdk 1.6.0_23 Regards, Michael
Re: JSF application very slow with HTTPS
Yes, compression is enabled, at least on the real systems. It was turned off in this local test. However, turning on compression results in 43KB instead of 512 KB and the response time is locally a little bit slower (17.5 sec). So the problem with HTTPS is independent of the compression. I just tried to measure the times with jetty without success. Which jetty version do I have to use for myfaces 1.2? I tried several ones (7.3.x, 7.2.x, 7.1.X) but I get always EL errors with nested expressions which I do not get with Tomcat 6.0.X. I never used Jetty so far, can I put Tomcat's EL impl into jetty? Michael Am 11.04.2011 15:28, schrieb Adrian Mitev: Have you turned on the page compression of your app server? 2011/4/11 Walter Mourãowalter.mou...@gmail.com As far as I know, the JSF does not know anything about https... it is handled by the servlet container (Tomcat, Jetty...). Walter Mourão http://waltermourao.com.br http://arcadian.com.br http://oriens.com.br On Mon, Apr 11, 2011 at 8:49 AM, Michael Heinenmhn4...@googlemail.com wrote: Hi, My JSF application is very slow via HTTPS. Some parts are 15 times slower compared to HTTP I measured the response times of the xhtml requests with Fiddler (locally and over network) Result for a very large page (512 KB) with a big datatable without ajax usage: -- local access with HTTP: 1 sec -- local access with HTTPS: 15-16 sec Other pages are factor 2-4 slower, with or without ajax. The time is spent in htmlTableRenderer.encodeInnerHtml. Data is of course available, there is no additional backend access. The simple download of xhtml files or other files is NOT (noticeable) slower. Other non JSF applications running on the same servers are also not slower with HTTPS. Before I start profiling: - Does anybody have an idea where I should look at? - Are there any known JSF or webApp settings that influence https performance? Environment: Facelets myFaces 1.2.9 tomahawk12_1.1.10 richfaces 3.3.3 tomcat 6.0.29 jdk 1.6.0_23 Regards, Michael
TagAttributeException after migration to jetty
This is a follow-up discussion for JSF application very slow with
HTTPS in order to no hijack my own thread.
I want to compare the performance of my app with tomcat and jetty.
Environment:
Facelets
myFaces 1.2.9
tomahawk12_1.1.10
richfaces 3.3.3
The app runs fine with all Tomcat 6 versions.
Unfortunately I cannot access it with various jetty versions (7.3.x,
7.2.x, 7.1.X, 6.1.22) because nested EL expressions are not working.
Stack from 6.1.22 (edited):
com.sun.facelets.tag.TagAttributeException: /pages/foo.xhtml @43,114
title=#{MyController.myButtonEnabled?msgs['key1']:MyController.myButton2Enabled?msgs['key3']:msgs['key4']}
Error Parsing:
#{MyController.myButtonEnabled?msgs['key1']:MyController.myButton2Enabled?msgs['key3']:msgs['key4']}
at
com.sun.facelets.tag.TagAttribute.getValueExpression(TagAttribute.java:259)
at
com.sun.facelets.tag.jsf.ComponentRule$ValueExpressionMetadata.applyMetadata(ComponentRule.java:69)
at
com.sun.facelets.tag.MetadataImpl.applyMetadata(MetadataImpl.java:36)
at
com.sun.facelets.tag.MetaTagHandler.setAttributes(MetaTagHandler.java:76)
at
com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:165)
at
com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
at
com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:360)
at
com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:190)
at
com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
at
com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:360)
at
com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:190)
at
com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:360)
at
com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:190)
at
com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
at
com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:360)
at
com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:190)
at
com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
at
com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:360)
at
com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:190)
at
com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
at
com.sun.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:124)
at
com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49)
at
com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:39)
at
com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:248)
at
com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:294)
at
com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:273)
at
com.sun.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:140)
at com.sun.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:66)
at
com.sun.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:64)
at
com.sun.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:136)
at
com.sun.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:337)
at
com.sun.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:307)
at com.sun.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:68)
at
com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
at
com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:360)
at
com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:190)
at
com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
at
com.sun.facelets.tag.jsf.ComponentHandler.applyNextHandler(ComponentHandler.java:360)
at
com.sun.facelets.tag.jsf.ComponentHandler.apply(ComponentHandler.java:190)
at
com.sun.facelets.tag.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:47)
at
com.sun.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:124)
at
com.sun.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:49)
at
com.sun.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:39)
at
com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:248)
at
com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:294)
at
com.sun.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:273)
at
com.sun.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:140)
at
com.sun.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:116)
at
Re: JSF application very slow with HTTPS
Fat? Well there is a lot of EL in this table, nearly in all cells, e.g. for column widths, values, styles etc. The EL is always hitting backing beans, some with additional map access. But the real problem is the poor HTTPS performance compared to HTTP. It should not be caused by the app and also not by JSF or Tomcat of course. There should be a little overhead for additional handshaking, but not for the rendering! Could this be caused by a buffering whereever? Mark (or anybody else), did you compare your app with http and https? Just wondering whether this is a problem only in my app. Regards, Michael Am 11.04.2011 17:27, schrieb Mark Struberg: Btw another question: 1s local response time? How fat is this page? We have a really big page in production with 1400 lines in a dataTable - and it renders in 450 ms... How many back-and-forth requests do you see if you open firebug? Do you have some EL involved which isn't hitting the backing bean but directly goes into the database? Something in this direction... LieGrue, strub --- On Mon, 4/11/11, Mike Kienenbergermkien...@gmail.com wrote: From: Mike Kienenbergermkien...@gmail.com Subject: Re: JSF application very slow with HTTPS To: MyFaces Discussionusers@myfaces.apache.org Cc: Michael Heinenmhn4...@googlemail.com Date: Monday, April 11, 2011, 2:20 PM I also use jetty-6.1.22. My environment is almost identical to yours, give or take a minor version number. On Mon, Apr 11, 2011 at 7:49 AM, Michael Heinenmhn4...@googlemail.com wrote: Hi, My JSF application is very slow via HTTPS. Some parts are 15 times slower compared to HTTP I measured the response times of the xhtml requests with Fiddler (locally and over network) Result for a very large page (512 KB) with a big datatable without ajax usage: -- local access with HTTP: 1 sec -- local access with HTTPS: 15-16 sec Other pages are factor 2-4 slower, with or without ajax. The time is spent in htmlTableRenderer.encodeInnerHtml. Data is of course available, there is no additional backend access. The simple download of xhtml files or other files is NOT (noticeable) slower. Other non JSF applications running on the same servers are also not slower with HTTPS. Before I start profiling: - Does anybody have an idea where I should look at? - Are there any known JSF or webApp settings that influence https performance? Environment: Facelets myFaces 1.2.9 tomahawk12_1.1.10 richfaces 3.3.3 tomcat 6.0.29 jdk 1.6.0_23 Regards, Michael
Re: JSF application very slow with HTTPS
Yep, that's what I'll do after getting the app running on jetty. What a pain, I thought this would have been done in a few minutes Am 11.04.2011 18:12, schrieb Mark Struberg: Ah sorry, have overread that: The time is spent in htmlTableRenderer.encodeInnerHtml I'd start the application with YourKit profiler and do some profiling. You can get a free yourkit test license (14 days I think) for evaluation. LieGrue, strub --- On Mon, 4/11/11, Michael Heinenmhn4...@googlemail.com wrote: From: Michael Heinenmhn4...@googlemail.com Subject: Re: JSF application very slow with HTTPS To: MyFaces Discussionusers@myfaces.apache.org Date: Monday, April 11, 2011, 3:45 PM Fat? Well there is a lot of EL in this table, nearly in all cells, e.g. for column widths, values, styles etc. The EL is always hitting backing beans, some with additional map access. But the real problem is the poor HTTPS performance compared to HTTP. It should not be caused by the app and also not by JSF or Tomcat of course. There should be a little overhead for additional handshaking, but not for the rendering! Could this be caused by a buffering whereever? Mark (or anybody else), did you compare your app with http and https? Just wondering whether this is a problem only in my app. Regards, Michael Am 11.04.2011 17:27, schrieb Mark Struberg: Btw another question: 1s local response time? How fat is this page? We have a really big page in production with 1400 lines in a dataTable - and it renders in 450 ms... How many back-and-forth requests do you see if you open firebug? Do you have some EL involved which isn't hitting the backing bean but directly goes into the database? Something in this direction... LieGrue, strub --- On Mon, 4/11/11, Mike Kienenbergermkien...@gmail.com wrote: From: Mike Kienenbergermkien...@gmail.com Subject: Re: JSF application very slow with HTTPS To: MyFaces Discussionusers@myfaces.apache.org Cc: Michael Heinenmhn4...@googlemail.com Date: Monday, April 11, 2011, 2:20 PM I also use jetty-6.1.22. My environment is almost identical to yours, give or take a minor version number. On Mon, Apr 11, 2011 at 7:49 AM, Michael Heinenmhn4...@googlemail.com wrote: Hi, My JSF application is very slow via HTTPS. Some parts are 15 times slower compared to HTTP I measured the response times of the xhtml requests with Fiddler (locally and over network) Result for a very large page (512 KB) with a big datatable without ajax usage: -- local access with HTTP: 1 sec -- local access with HTTPS: 15-16 sec Other pages are factor 2-4 slower, with or without ajax. The time is spent in htmlTableRenderer.encodeInnerHtml. Data is of course available, there is no additional backend access. The simple download of xhtml files or other files is NOT (noticeable) slower. Other non JSF applications running on the same servers are also not slower with HTTPS. Before I start profiling: - Does anybody have an idea where I should look at? - Are there any known JSF or webApp settings that influence https performance? Environment: Facelets myFaces 1.2.9 tomahawk12_1.1.10 richfaces 3.3.3 tomcat 6.0.29 jdk 1.6.0_23 Regards, Michael
Re: myfaces-tree2 component
Hi Pritam,
I migrated a few weeks ago to the richfaces tree which has ajax support
on board.
Maybe it's an alternative for you.
Regards,
Michael
Am 01.03.2011 09:20, schrieb Jakob Korherr:
Hi Pritam,
I had a similar problem in one of my projects and we solved it by
making the tree AJAX aware - which means that we only loaded the first
section of the tree with the site and then loaded other sections on
demand if a user clicked the related +.
However, if that is not possible for you, you have 2 other options: 1)
use a different tree component from another library (not tomahawk) or
2) write your own tree component.
I hope this helps!
Regards,
Jakob
2011/3/1, Gaikwad, Pritam (Pritam)pgaik...@avaya.com:
Hi,
We are using tomahawk's tree2 component in our application. We have more
than 12000 nodes in the navigation tree which is the most important
component of our application.
The problem is- with 12000 nodes tree renderer generates large amount of
html (~ 20MB) which is repetitive and the browser takes almost 40-45
minutes to render the tree. So, do we have any way to avoid this
problem?
Mentioned below html is only a small part of what's being sent from the
server.
table cellpadding=0 cellspacing=0 border=0trtd width=19
height=100% nowrap=nowrap
background=/CS-OAM/faces/myFacesExtensionResource/org.apache.myfaces.re
nderkit.html.util.MyFacesResourceLoader/12986260/tree2.HtmlTreeRenderer/
images/line-trunk.gifimg
src=/CS-OAM/faces/myFacesExtensionResource/org.apache.myfaces.renderkit
.html.util.MyFacesResourceLoader/12986260/tree2.HtmlTreeRenderer/images/
line-trunk.gif alt= width=19 height=18 border=0 //tdtd
width=19 nowrap=nowrap height=100% valign=topa href=#
onclick=setID(this.id);;return
oamSubmitForm('navigation:_idJsp1','navigation:_idJsp1:enterprise:enterp
rise-tree:enterprisetree:0:0:0:t2g',null,[['enterprisetree:org.apache.my
faces.tree.NAV_COMMAND','0:0:0']]);
id=navigation:_idJsp1:enterprise:enterprise-tree:enterprisetree:0:0:0:t
2gimg
id=navigation:_idJsp1:enterprise:enterprise-tree:enterprisetree:0:0:0:t
2
src=/CS-OAM/faces/myFacesExtensionResource/org.apache.myfaces.renderkit
.html.util.MyFacesResourceLoader/12986260/tree2.HtmlTreeRenderer/images/
nav-minus-line-last.gif alt=Collapse border=0 height=18
width=19 title=Collapse //a/tdtd nowrap=nowrapspan
style=white-space:nowrap;img
src=/CS-OAM/images/dtree/folderopen.gif alt=Folder Open border=0
/a href=# onclick=setID(this.id);return
oamSubmitForm('navigation:_idJsp1','navigation:_idJsp1:enterprise:enterp
rise-tree:enterprisetree:0:0:0:_idJsp35');
id=navigation:_idJsp1:enterprise:enterprise-tree:enterprisetree:0:0:0:_
idJsp35 class=documentDefault Admin
Site/a/span/td/tr/table
table cellpadding=0 cellspacing=0 border=0trtd width=19
height=100% nowrap=nowrap
background=/CS-OAM/faces/myFacesExtensionResource/org.apache.myfaces.re
nderkit.html.util.MyFacesResourceLoader/12986260/tree2.HtmlTreeRenderer/
images/line-trunk.gifimg
src=/CS-OAM/faces/myFacesExtensionResource/org.apache.myfaces.renderkit
.html.util.MyFacesResourceLoader/12986260/tree2.HtmlTreeRenderer/images/
line-trunk.gif alt= width=19 height=18 border=0 //tdtd
width=19 height=100% nowrap=nowrap
background=/CS-OAM/faces/myFacesExtensionResource/org.apache.myfaces.re
nderkit.html.util.MyFacesResourceLoader/12986260/tree2.HtmlTreeRenderer/
images/spacer.gifimg
src=/CS-OAM/faces/myFacesExtensionResource/org.apache.myfaces.renderkit
.html.util.MyFacesResourceLoader/12986260/tree2.HtmlTreeRenderer/images/
spacer.gif alt= width=19 height=18 border=0 //tdtd
width=19 nowrap=nowrap height=100% valign=top
background=/CS-OAM/faces/myFacesExtensionResource/org.apache.myfaces.re
nderkit.html.util.MyFacesResourceLoader/12986260/tree2.HtmlTreeRenderer/
images/line-trunk.gifimg id=t2
src=/CS-OAM/faces/myFacesExtensionResource/org.apache.myfaces.renderkit
.html.util.MyFacesResourceLoader/12986260/tree2.HtmlTreeRenderer/images/
line-middle.gif alt= border=0 height=18 width=19 //tdtd
nowrap=nowrapspan style=white-space:nowrap;a href=#
onclick=setID(this.id);return
oamSubmitForm('navigation:_idJsp1','navigation:_idJsp1:enterprise:enterp
rise-tree:enterprisetree:0:0:0:0:_idJsp38');
id=navigation:_idJsp1:enterprise:enterprise-tree:enterprisetree:0:0:0:0
:_idJsp38 class=documentmhprfadmin/a/span/td/tr/table
table cellpadding=0 cellspacing=0 border=0trtd width=19
height=100% nowrap=nowrap
background=/CS-OAM/faces/myFacesExtensionResource/org.apache.myfaces.re
nderkit.html.util.MyFacesResourceLoader/12986260/tree2.HtmlTreeRenderer/
images/line-trunk.gifimg
src=/CS-OAM/faces/myFacesExtensionResource/org.apache.myfaces.renderkit
.html.util.MyFacesResourceLoader/12986260/tree2.HtmlTreeRenderer/images/
line-trunk.gif alt= width=19 height=18 border=0 //tdtd
width=19 height=100% nowrap=nowrap
background=/CS-OAM/faces/myFacesExtensionResource/org.apache.myfaces.re
nderkit.html.util.MyFacesResourceLoader/12986260/tree2.HtmlTreeRenderer/
images/spacer.gifimg
global validation of all input fields in order to remove forbidden chars?
Hi, My app does not work correctly if a user enters an ISO control character (e.g. 'START OF HEADING' (U+0001) or ALT+01) in an input field. I get a xml parsing error on client side if the illegal char is inside an attribute (here the value attribute of an input field). This happens with richfaces in combination with the neko parser. There seems to be only one solution: Do not allow these special chars during input! Question: What is the best approach for validating all input fields in a generic way? Note that the illegal chars must be removed from the value attribute of the input field otherwise the rerendering of the errornous input field fails again. Thanks, Michael
Re: ui:param value accessible in backing bean?
Hi Jakob,
I migrated my app from jsp/tiles to xhtml/facelets successfully in the
last 2-3 days.
But your hint is unfortunately not working for me.
namespace in xhtml file for core tags is:
xmlns:c=http://java.sun.com/jsp/jstl/core;
Is this the right one or do I have to use
xmlns:c=http://java.sun.com/jstl/core; (without jsp)?
jstl-1.2.jar is in the lib folder of my webApp.
c:out does not print anything and the set value is also not accessible
via EL in the getter of my bean.
My current code:
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:c=http://java.sun.com/jsp/jstl/core;
ui:composition template=templates/main.xhtml
ui:param name=activeTab value=wb/
c:set var=foo2 value=bla2 scope=request/
c:set target=#{requestScope} property=foo value=fooValue /
ui:define name=navigation
ui:include src=/facelets/parts/navigation.xhtml/ui:include
/ui:define
I try to access foo and foo2 in navigation.xhtml and in a getter called
from navigation.xhtml.
Any Idea what's going wrong here ?
Greetz,
Michael
Am 20.07.2010 23:20, schrieb Jakob Korherr:
Hi Michael,
You can usec:set from the JSTL to put the value into the request scope.
Then you can access it in the facelet and also later in the action method.
Namespace: xmlns:c=http://java.sun.com/jsp/jstl/core;
c:set target=#{requestScope} property=foo value=fooValue /
Regards,
Jakob
2010/7/20 Leonardo Uribelu4...@gmail.com
Hi
I checked in deep some days ago ui:param, and it only define the expression
when the view is build, but its context is not preserved on other phases.
FaceletContext extends from ELContext and override its VariableMapper and
FunctionMapper. So in practice, ui:param just add a variable on the
variable
mapper. but after ui:composition and ui:include ends its processing the
variable is just discarded, because the whole VariableMapper wrapper
created
by this two tags is removed too.
regards,
Leonardo Uribe
2010/7/20 Michael Heinenmhn4...@googlemail.com
Is it possible to access the value of a facelets ui:param tag in phase
render response in a backing bean?
I tried to resolve #{activeTab} in MyController.getOnlick() without
success.
Sample:
1) Template
ui:composition template=templates/main.xhtml
ui:param name=activeTab value=blabla/
ui:define name=navigation
ui:include src=/facelets/navigation.xhtml/ui:include
/ui:define
2) navigation.xhtml
...
t:commandLink onclick=#{MyController.onlick}
...
I use myFaces 1.2.9 and facelets 1.1.15.
Thanks,
Michael
Re: ui:param value accessible in backing bean?
Many thanks Jakob, your tag is working well.
Michael
Am 21.07.2010 13:06, schrieb Jakob Korherr:
Hi Michael,
I just created a Facelets 1.1.x custom tags project and adapted the
SetHandler from MyFaces core 2.0 for Facelets 1.1.x.
You can find the source at
http://jakobk-extensions.googlecode.com/svn/trunk/jsf/facelets1/facelets1-custom-tags/
Just check it out and use mvn clean install to get the JAR. If you include
this JAR in your webapp, you can use the custom set tag like this:
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:jk=http://facelets.jakobk.at/customtags;
jk:set target=#{requestScope} property=foo value=fooValue /
I hope you can use this solution.
Regards,
Jakob
2010/7/21 Jakob Korherrjakob.korh...@gmail.com
Hi Michael,
I migrated my app from jsp/tiles to xhtml/facelets successfully in the
last 2-3 days.
That's great :)
Hm, yes. Unfortunately I digged deeper into it and found out thatc:set
is equal toui:param on facelets-1.x, thus the suggested code only works
for JSF 2.0. I am sorry, but this means that you will have to find some
other tag which accomplishes this or you will have to write your own one
(which should not be too hard, because you can take the code from MyFaces
core 2.0 SetHandler --
org.apache.myfaces.view.facelets.tag.jstl.core.SetHandler and just register
it in your facelets taglib).
I hope this helps!
Regards,
Jakob
2010/7/21 Michael Heinenmhn4...@googlemail.com
Hi Jakob,
I migrated my app from jsp/tiles to xhtml/facelets successfully in the
last 2-3 days.
But your hint is unfortunately not working for me.
namespace in xhtml file for core tags is: xmlns:c=
http://java.sun.com/jsp/jstl/core;
Is this the right one or do I have to use xmlns:c=
http://java.sun.com/jstl/core; (without jsp)?
jstl-1.2.jar is in the lib folder of my webApp.
c:out does not print anything and the set value is also not accessible
via EL in the getter of my bean.
My current code:
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:c=http://java.sun.com/jsp/jstl/core;
ui:composition template=templates/main.xhtml
ui:param name=activeTab value=wb/
c:set var=foo2 value=bla2 scope=request/
c:set target=#{requestScope} property=foo value=fooValue /
ui:define name=navigation
ui:include src=/facelets/parts/navigation.xhtml/ui:include
/ui:define
I try to access foo and foo2 in navigation.xhtml and in a getter called
from navigation.xhtml.
Any Idea what's going wrong here ?
Greetz,
Michael
Am 20.07.2010 23:20, schrieb Jakob Korherr:
Hi Michael,
You can usec:set from the JSTL to put the value into the request
scope.
Then you can access it in the facelet and also later in the action
method.
Namespace: xmlns:c=http://java.sun.com/jsp/jstl/core;
c:set target=#{requestScope} property=foo value=fooValue /
Regards,
Jakob
2010/7/20 Leonardo Uribelu4...@gmail.com
Hi
I checked in deep some days ago ui:param, and it only define the
expression
when the view is build, but its context is not preserved on other
phases.
FaceletContext extends from ELContext and override its VariableMapper
and
FunctionMapper. So in practice, ui:param just add a variable on the
variable
mapper. but after ui:composition and ui:include ends its processing the
variable is just discarded, because the whole VariableMapper wrapper
created
by this two tags is removed too.
regards,
Leonardo Uribe
2010/7/20 Michael Heinenmhn4...@googlemail.com
Is it possible to access the value of a facelets ui:param tag in phase
render response in a backing bean?
I tried to resolve #{activeTab} in MyController.getOnlick() without
success.
Sample:
1) Template
ui:composition template=templates/main.xhtml
ui:param name=activeTab value=blabla/
ui:define name=navigation
ui:include src=/facelets/navigation.xhtml/ui:include
/ui:define
2) navigation.xhtml
...
t:commandLink onclick=#{MyController.onlick}
...
I use myFaces 1.2.9 and facelets 1.1.15.
Thanks,
Michael
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
ui:param value accessible in backing bean?
Is it possible to access the value of a facelets ui:param tag in phase
render response in a backing bean?
I tried to resolve #{activeTab} in MyController.getOnlick() without success.
Sample:
1) Template
ui:composition template=templates/main.xhtml
ui:param name=activeTab value=blabla/
ui:define name=navigation
ui:include src=/facelets/navigation.xhtml/ui:include
/ui:define
2) navigation.xhtml
...
t:commandLink onclick=#{MyController.onlick}
...
I use myFaces 1.2.9 and facelets 1.1.15.
Thanks,
Michael
Re: Myfaces Upgrade Issues 1.1.5 to 1.2.9
Do you use the right version of tomahawk, tomahawk12-1.1.9 ? Which tiles version are you using? Tiles 2.0.7 works fine with tomahawk 12_1.1.9. Newer versions are not supported by tomahawk. Make sure to read the tiles migration guide if you update from an older struts-tiles version. See this web page and the other migration pages at the bottom. http://tiles.apache.org/2.0/framework/migration/tags.html Michael Am 05.07.2010 10:13, schrieb شہباز علئ : Hi Recently I have updated my application to myfaces 1.2.9 from myfaces 1.1.5 to get use of JSF 1.2 for this, I have updated: myfaces to 1.2.9 tomahawk to 1.1.9 jstl to jstl 1.2 richfaces to 3.2.0 I already being using Tomcat 6 as j2ee container which i dont need to changed. But I am getting the following exception whenever I hit any tiles configured page: I have configured org.apache.myfaces.tomahawk.application.jsp.JspTilesTwoViewHandlerImpl too. But I cannot understand the issue. Please help ! java.lang.NullPointerException at org.apache.tiles.servlet.context.ServletTilesRequestContext.forward(ServletTilesRequestContext.java:198) at org.apache.tiles.servlet.context.ServletTilesRequestContext.dispatch(ServletTilesRequestContext.java:185) at org.apache.myfaces.tomahawk.application.jsp.JspTilesTwoViewHandlerImpl.buildView(JspTilesTwoViewHandlerImpl.java:450) at org.apache.myfaces.tomahawk.application.jsp.JspTilesTwoViewHandlerImpl.buildTilesViewLikeContainer(JspTilesTwoViewHandlerImpl.java:354) at org.apache.myfaces.tomahawk.application.jsp.JspTilesTwoViewHandlerImpl.renderTilesView(JspTilesTwoViewHandlerImpl.java:154) at org.apache.myfaces.tomahawk.application.jsp.JspTilesTwoViewHandlerImpl.renderView(JspTilesTwoViewHandlerImpl.java:135) at com.avanza.unison.config.LocaleResolverViewHandler.renderView(LocaleResolverViewHandler.java:76) at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108) at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:189) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:187) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:341) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:147) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:276) at org.ajax4jsf.Filter.doFilter(Filter.java:175) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.avanza.unison.config.ApplicationRequestFilter.activityLoggingAspect(ApplicationRequestFilter.java:346) at com.avanza.unison.config.ApplicationRequestFilter.sessionDataAspect(ApplicationRequestFilter.java:322) at com.avanza.unison.config.ApplicationRequestFilter.transactionAspect(ApplicationRequestFilter.java:277) at com.avanza.unison.config.ApplicationRequestFilter.validURLForUser(ApplicationRequestFilter.java:249) at com.avanza.unison.config.ApplicationRequestFilter.authenticationAspect(ApplicationRequestFilter.java:222) at com.avanza.unison.config.ApplicationRequestFilter.licenseAuthentication(ApplicationRequestFilter.java:136) at com.avanza.unison.config.ApplicationRequestFilter.doFilter(ApplicationRequestFilter.java:118) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.avanza.unison.config.DataReloadFilter.doFilter(DataReloadFilter.java:42) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.avanza.unison.config.ApplicationRequestFilter.activityLoggingAspect(ApplicationRequestFilter.java:346) at com.avanza.unison.config.ApplicationRequestFilter.sessionDataAspect(ApplicationRequestFilter.java:322) at com.avanza.unison.config.ApplicationRequestFilter.transactionAspect(ApplicationRequestFilter.java:277) at com.avanza.unison.config.ApplicationRequestFilter.validURLForUser(ApplicationRequestFilter.java:249) at com.avanza.unison.config.ApplicationRequestFilter.authenticationAspect(ApplicationRequestFilter.java:222) at com.avanza.unison.config.ApplicationRequestFilter.licenseAuthentication(ApplicationRequestFilter.java:136) at
Re: Myfaces Upgrade Issues 1.1.5 to 1.2.9
You should remove the struts.jar completely because tiles is now a separate project with it's own jars. But your exception looks like another problem. You should try to debug it find out why path is null in your case. Michael Am 05.07.2010 12:17, schrieb شہباز علئ : I tried after replacing tiles with 2.0.7, and getting the following exception, i found one more thing when I looked into the lib folder that we are using tiles with struts1.1, Do I need to upgrade its version as well. Please suggest. javax.faces.FacesException: org.apache.tiles.TilesException: No request dispatcher returned for path 'null' at org.apache.myfaces.tomahawk.application.jsp.JspTilesTwoViewHandlerImpl.renderTilesView(JspTilesTwoViewHandlerImpl.java:159) at org.apache.myfaces.tomahawk.application.jsp.JspTilesTwoViewHandlerImpl.renderView(JspTilesTwoViewHandlerImpl.java:135) at com.avanza.unison.config.LocaleResolverViewHandler.renderView(LocaleResolverViewHandler.java:76) at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108) at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:189) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:187) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:341) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:147) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:276) at org.ajax4jsf.Filter.doFilter(Filter.java:175) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.avanza.unison.config.ApplicationRequestFilter.activityLoggingAspect(ApplicationRequestFilter.java:346) at com.avanza.unison.config.ApplicationRequestFilter.sessionDataAspect(ApplicationRequestFilter.java:322) at com.avanza.unison.config.ApplicationRequestFilter.transactionAspect(ApplicationRequestFilter.java:277) at com.avanza.unison.config.ApplicationRequestFilter.validURLForUser(ApplicationRequestFilter.java:249) at com.avanza.unison.config.ApplicationRequestFilter.authenticationAspect(ApplicationRequestFilter.java:222) at com.avanza.unison.config.ApplicationRequestFilter.licenseAuthentication(ApplicationRequestFilter.java:136) at com.avanza.unison.config.ApplicationRequestFilter.doFilter(ApplicationRequestFilter.java:118) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.avanza.unison.config.DataReloadFilter.doFilter(DataReloadFilter.java:42) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.avanza.unison.config.ApplicationRequestFilter.activityLoggingAspect(ApplicationRequestFilter.java:346) at com.avanza.unison.config.ApplicationRequestFilter.sessionDataAspect(ApplicationRequestFilter.java:322) at com.avanza.unison.config.ApplicationRequestFilter.transactionAspect(ApplicationRequestFilter.java:277) at com.avanza.unison.config.ApplicationRequestFilter.validURLForUser(ApplicationRequestFilter.java:249) at com.avanza.unison.config.ApplicationRequestFilter.authenticationAspect(ApplicationRequestFilter.java:222) at com.avanza.unison.config.ApplicationRequestFilter.licenseAuthentication(ApplicationRequestFilter.java:136) at com.avanza.unison.config.ApplicationRequestFilter.doFilter(ApplicationRequestFilter.java:118) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at
Re: Using tiles with tomahawk12 1.1.9
Which tiles version are you using? Tiles 2.0.7 works fine with tomohawl 12_1.1.9. Newer versions are not supported by tomahawk. Make sure to read the tiles migration guide if you update from an older struts-tiles version. See this web page and the other migration pages at the bottom. http://tiles.apache.org/2.0/framework/migration/tags.html Michael Am 26.04.2010 15:50, schrieb Geetika Srivastava: Hi, I am trying to use tiles (struts version) with tomahawk12 1.1.9 jar. However it seems that the definition factory is not getting initialized as I am getting the error. javax.faces.FacesException: javax.servlet.jsp.JspException: Can't get definitions factory from context. I am using the same configuration as done in the example for tomahawk 1.1.9 . Is there any difference in configuration for tomahawk12. Regards, Geetika Srivastava Tata Consultancy Services Mailto: geetika.srivast...@tcs.com Website: http://www.tcs.com Experience certainty. IT Services Business Solutions Outsourcing =-=-= Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
ConcurrentModificationException in RequestMap.getAttributeNames
Hi, I found followoing exception a few times in my tomcat log after running a JMeter stresstest some hours with a few hundred users. Any ideas about a ConcurrentModificationException during RequestMap.getAttributeNames() ? [2010-04-07 09:00:59,653] http-8080-6 [ERROR] [6799FA3FDEBB49F294E54657DB099957] servlets.FacesServletWrapper service: Caught exception in the FacesServletWrapper: javax.servlet.ServletException: java.util.ConcurrentModificationException at javax.faces.webapp._ErrorPageWriter.throwException(_ErrorPageWriter.java:549) at javax.faces.webapp.FacesServlet.handleLifecycleException(FacesServlet.java:293) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:187) at com.foo.client.web.servlets.FacesServletWrapper.service(FacesServletWrapper.java:124) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:206) at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290) at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388) at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:384) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.foo.client.web.filters.LoginFilter.doFilter(LoginFilter.java:183) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.foo.client.web.filters.EncodingFilter.doFilter(EncodingFilter.java:49) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at com.foo.client.web.filters.TimerFilter.doFilter(TimerFilter.java:71) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:465) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489) at java.lang.Thread.run(Thread.java:619) Caused by: javax.faces.FacesException: java.util.ConcurrentModificationException at javax.faces.component.UIComponent.invokeOnComponent(UIComponent.java:166) at javax.faces.component.UIComponentBase.invokeOnComponent(UIComponentBase.java:293) at javax.faces.component.UIComponent.invokeOnComponent(UIComponent.java:172) at javax.faces.component.UIComponentBase.invokeOnComponent(UIComponentBase.java:293) at javax.faces.component.UIComponent.invokeOnComponent(UIComponent.java:172) at javax.faces.component.UIComponentBase.invokeOnComponent(UIComponentBase.java:293) at javax.faces.component.UIComponent.invokeOnComponent(UIComponent.java:172) at javax.faces.component.UIComponentBase.invokeOnComponent(UIComponentBase.java:293) at javax.faces.component.UIComponent.invokeOnComponent(UIComponent.java:172) at javax.faces.component.UIComponentBase.invokeOnComponent(UIComponentBase.java:293) at org.ajax4jsf.component.AjaxViewRoot.processPhase(AjaxViewRoot.java:226) at org.ajax4jsf.component.AjaxViewRoot.processValidators(AjaxViewRoot.java:463) at org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103) at
Re: ConcurrentModificationException in RequestMap.getAttributeNames
Thanks Jakob for the analysis.
But what is another thread?
Do you know whether myFaces (or richfaces) starts another thread?
I don't think that any other thrid party libs are involved here.
Any instant ideas for this?
It's not a real problem so far because it occurred during a load test only.
Michael
Am 09.04.2010 11:57, schrieb Jakob Korherr:
Hi Michael,
I just took a look at this problem and it seems to be one of tomcat. I also
checked out the tomcat 6.0.24 branch to find the code that causes the
exception.
The main problem is that the request map is altered during it is processed
with an Iterator in org.apache.catalina.util.Enumerator --
java.util.ConcurrentModificationException.
Here is some code from tomcat that shows this conclusion:
org.apache.catalina.connector.Request.getAttributeNames looks like this:
public Enumeration getAttributeNames() {
// cut for clarity
return new Enumerator(attributes.keySet(), true);
}
So this code wants to create a new Enumerator with the keySet of the request
attributes. It also tells the Enumerator to clone the keySet before
generating the Iterator internally. The code that does the cloning can be
found in org.apache.catalina.util.Enumerator:
public Enumerator(Iterator iterator, boolean clone) {
super();
if (!clone) {
this.iterator = iterator;
} else {
List list = new ArrayList();
while (iterator.hasNext()) {
list.add(iterator.next()); // line 101: this is the place
where the ConcurrentModificationException happens
}
this.iterator = list.iterator();
}
}
So the constructor goes through the given Iterator (from the keySet of the
request map) and creates an ArrayList out of it. The problem is now that if
another thread alters the request map during this creation, you will get the
ConcurrentModificationException. Of course, this is very rare and
furthermore I guess the cloning was added to minimize the chance of a
ConcurrentModificationException, but it still can happen.
If you really want to eleminate this problem, thread synchronizing has to be
introduced here.
Regards,
Jakob
2010/4/9 Michael Heinenmhn4...@googlemail.com
Hi,
I found followoing exception a few times in my tomcat log after running a
JMeter stresstest some hours with a few hundred users.
Any ideas about a ConcurrentModificationException during
RequestMap.getAttributeNames() ?
[2010-04-07 09:00:59,653] http-8080-6 [ERROR]
[6799FA3FDEBB49F294E54657DB099957] servlets.FacesServletWrapper service:
Caught exception in the FacesServletWrapper:
javax.servlet.ServletException: java.util.ConcurrentModificationException
at
javax.faces.webapp._ErrorPageWriter.throwException(_ErrorPageWriter.java:549)
at
javax.faces.webapp.FacesServlet.handleLifecycleException(FacesServlet.java:293)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:187)
at
com.foo.client.web.servlets.FacesServletWrapper.service(FacesServletWrapper.java:124)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:206)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:290)
at
org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:388)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:515)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:384)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.foo.client.web.filters.LoginFilter.doFilter(LoginFilter.java:183)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
com.foo.client.web.filters.EncodingFilter.doFilter(EncodingFilter.java:49)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at com.foo.client.web.filters.TimerFilter.doFilter(TimerFilter.java:71)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
Re: [tomahawk] replaceIdWithLabel not working in t:messages after update to JSF 1.2
Hi Mike,
it was caused by a patch that I created locally. I fixed this and now it
works again as before with JSF 1.1
But there are still open issues in combination with datatables or datalists:
https://issues.apache.org/jira/browse/TOMAHAWK-452
Michael
Am 02.04.2010 19:43, schrieb Mike Kienenberger:
Michael, I'm having the same problem you had before using
myfaces-api-1.2.8.jar
tomahawk-1.1.9.jar
Were you saying it was caused by a patch you made, or by an incorrect
patch MyFaces incorrectly applied?
This page code:
---
t:messages
globalOnly=true
showDetail=true /
t:messages
globalOnly=false
showDetail=true /
h:outputLabel
for=accountPaymentAmountInput
value=Amount /
h:inputText
id=accountPaymentAmountInput
binding=#{page.accountPaymentAmountInput}
required=true
value=#{page.accountPaymentAmount}
/h:inputText
---
results in
masterForm:enterPaymentForm:Amount: Validation Error: Value is required.
On Tue, Dec 22, 2009 at 12:49 PM, Michael Heinen
michael.hei...@recommind.com wrote:
I found the issue during the creation of a small test project.
It was caused by a not correctly migrated patch for the UIInput.class.
Michael
-Original Message-
From: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] On Behalf Of
Jakob Korherr
Sent: Dienstag, 22. Dezember 2009 17:05
To: MyFaces Discussion
Subject: Re: [tomahawk] replaceIdWithLabel not working in t:messages after
update to JSF 1.2
Hi Michael,
I'm sorry, but I can not reproduce your problem. On my machine it is User:
Validierungsfehler: Eingabe erforderlich..
Can you please provide more information about your jsp.
Regards,
Jakob
2009/12/22 Michael Heinenmichael.hei...@recommind.com
Hi,
I have another migration issue:
Error messages are rendered with the component ids instead of the label
after update from myfaces 1.1.6 to 1.2.8 and tomahawk to 12_1.1.9
jsp:
h:outputLabel for=name value=User/
h:panelGroup
h:inputText id=name value=#{MyController.name} required=true
Class
org.apache.myfaces.renderkit.html.ext.HtmlMessagesRenderer.getSummary(...)
contains following line (86):
msgSummary =
msgSummary.replaceAll(HtmlMessageRenderer.findInputId(facesContext,
msgClientId),inputLabel);
Content:
msgSummary= name: Validierungsfehler: Eingabe erforderlich.
HtmlMessageRenderer.findInputId(facesContext, msgClientId) returns
loginForm:name
inptutLabel= User
So the problem is that findInputId returns the full qualified clientid
instead of the id.
This worked with the old 1.1 jars.
Any ideas?
Michael
RE: dramatic performance decrease after update to JSF 1.2
I have some news regarding the performance problem. The major performance decrease was caused by a Tomcat Bug. See https://issues.apache.org/bugzilla/show_bug.cgi?id=48600 Setting metadata-complete=true in web.xml improved the 1.2 speed significantly! There seems to be still another problem in Tocmat: Average results of 500 calls of a simple page (jsp) with 1000 h:output tags: JSF 1.1 Tomcat: 26ms JSF 1.1 Jetty: 35ms JSF 1.2 Tomcat: 72ms JSF 1.2 Jetty: 41ms Is anybody here aware of other Tomcat bugs or settings that could explain the above numbers? I'll also ask on the tomcat list. Michael -Original Message- From: Michael Heinen [mailto:michael.hei...@recommind.com] Sent: Freitag, 29. Januar 2010 09:36 To: MyFaces Discussion Subject: RE: dramatic performance decrease after update to JSF 1.2 I am really astonished that nobody else out in the world faced or addressed this problem so far. JSF 1.2 seems to be much slower than JSF 1.1 (with jsps, don't know about facelets). It can be reproduced easily with a simple JSF app without tiles, richfaces and all this stuff. Just create a simple page with a few hundred output tags without any EL: e.g. h:outputText value=1 style=z-index:4711;/. It is nearly two times slower and the time is lost during phase render response. Same effect occurs with Mojarra, which seems to be faster than Myfaces (at least for this simple case). This effect is of course worse in case of heavy load on the app. A version upgrade should not result in such a performance loss, we are not talking about a few percent. Does anybody have an explanation for this? Is it caused by separating tree creation from rendering? Is the component tree now walked completely two times, for creation and rendering? Michael -Original Message- From: Michael Heinen [mailto:michael.hei...@recommind.com] Sent: Freitag, 15. Januar 2010 11:07 To: MyFaces Discussion Subject: dramatic performance decrease after update to JSF 1.2 Hi, I have updated my application to JSF 1.2 during the last weeks. Now I did some performance tests and the result has been alarming! Performance declined by factor 2-4 depending on hardware and actions!!! Measurements: I used two different contexts on same Tomcat means identical tomcat config and JDK. I started only one of the contexts for each tests run. Backend is also the same. JMeter was used to fire requests but the difference can be seen by manual clicks immediately. Obvious results: Time is lost in phase render response. Sample numbers for a single request on a slow notebook in phase render response (with debug logging): JSF1.1: 1594ms JSF1.1: 4766ms (The numbers are much better without debug logging of course but the factor is still the same) Environment: Tomcat 6.0.20 JDK 1.6.0.18 Updated Libs: myFaces: 1.1.5 to 1.2.8 tomahawk: 1.1.7 to 12-1.1.9 richfaces: 3.1.5 to 3.3.3Beta1 tiles: 1(struts) to 2.0.5 jstl: 1.1.0 to 1.2 commons-digester: 1.7 to 1.8 oro-2.0.8 to jakarta-oro.jar Settings: identical in 1.1 and 1.2: javax.faces.STATE_SAVING_METHOD=server org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION = 1 org.apache.myfaces.SERIALIZE_STATE_IN_SESSION = false org.apache.myfaces.COMPRESS_STATE_IN_SESSION=false 1.2 new: org.apache.myfaces.SECRET added org.apache.myfaces.USE_ENCRYPTION = false org.apache.myfaces.CACHE_OLD_VIEWS_IN_SESSION_MODE=off (I patched this in 1.1 and removed the old references) Questions before I start profiling and probably sink time: 1) Is this typical or expected? 2) Is any new configuration flag added to 1.2 which could have high impact on performance? 3) Any other hints where to look at? Michael
RE: dramatic performance decrease after update to JSF 1.2
I am really astonished that nobody else out in the world faced or addressed this problem so far. JSF 1.2 seems to be much slower than JSF 1.1 (with jsps, don't know about facelets). It can be reproduced easily with a simple JSF app without tiles, richfaces and all this stuff. Just create a simple page with a few hundred output tags without any EL: e.g. h:outputText value=1 style=z-index:4711;/. It is nearly two times slower and the time is lost during phase render response. Same effect occurs with Mojarra, which seems to be faster than Myfaces (at least for this simple case). This effect is of course worse in case of heavy load on the app. A version upgrade should not result in such a performance loss, we are not talking about a few percent. Does anybody have an explanation for this? Is it caused by separating tree creation from rendering? Is the component tree now walked completely two times, for creation and rendering? Michael -Original Message- From: Michael Heinen [mailto:michael.hei...@recommind.com] Sent: Freitag, 15. Januar 2010 11:07 To: MyFaces Discussion Subject: dramatic performance decrease after update to JSF 1.2 Hi, I have updated my application to JSF 1.2 during the last weeks. Now I did some performance tests and the result has been alarming! Performance declined by factor 2-4 depending on hardware and actions!!! Measurements: I used two different contexts on same Tomcat means identical tomcat config and JDK. I started only one of the contexts for each tests run. Backend is also the same. JMeter was used to fire requests but the difference can be seen by manual clicks immediately. Obvious results: Time is lost in phase render response. Sample numbers for a single request on a slow notebook in phase render response (with debug logging): JSF1.1: 1594ms JSF1.1: 4766ms (The numbers are much better without debug logging of course but the factor is still the same) Environment: Tomcat 6.0.20 JDK 1.6.0.18 Updated Libs: myFaces: 1.1.5 to 1.2.8 tomahawk: 1.1.7 to 12-1.1.9 richfaces: 3.1.5 to 3.3.3Beta1 tiles: 1(struts) to 2.0.5 jstl: 1.1.0 to 1.2 commons-digester: 1.7 to 1.8 oro-2.0.8 to jakarta-oro.jar Settings: identical in 1.1 and 1.2: javax.faces.STATE_SAVING_METHOD=server org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION = 1 org.apache.myfaces.SERIALIZE_STATE_IN_SESSION = false org.apache.myfaces.COMPRESS_STATE_IN_SESSION=false 1.2 new: org.apache.myfaces.SECRET added org.apache.myfaces.USE_ENCRYPTION = false org.apache.myfaces.CACHE_OLD_VIEWS_IN_SESSION_MODE=off (I patched this in 1.1 and removed the old references) Questions before I start profiling and probably sink time: 1) Is this typical or expected? 2) Is any new configuration flag added to 1.2 which could have high impact on performance? 3) Any other hints where to look at? Michael
dramatic performance decrease after update to JSF 1.2
Hi, I have updated my application to JSF 1.2 during the last weeks. Now I did some performance tests and the result has been alarming! Performance declined by factor 2-4 depending on hardware and actions!!! Measurements: I used two different contexts on same Tomcat means identical tomcat config and JDK. I started only one of the contexts for each tests run. Backend is also the same. JMeter was used to fire requests but the difference can be seen by manual clicks immediately. Obvious results: Time is lost in phase render response. Sample numbers for a single request on a slow notebook in phase render response (with debug logging): JSF1.1: 1594ms JSF1.1: 4766ms (The numbers are much better without debug logging of course but the factor is still the same) Environment: Tomcat 6.0.20 JDK 1.6.0.18 Updated Libs: myFaces: 1.1.5 to 1.2.8 tomahawk: 1.1.7 to 12-1.1.9 richfaces: 3.1.5 to 3.3.3Beta1 tiles: 1(struts) to 2.0.5 jstl: 1.1.0 to 1.2 commons-digester: 1.7 to 1.8 oro-2.0.8 to jakarta-oro.jar Settings: identical in 1.1 and 1.2: javax.faces.STATE_SAVING_METHOD=server org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION = 1 org.apache.myfaces.SERIALIZE_STATE_IN_SESSION = false org.apache.myfaces.COMPRESS_STATE_IN_SESSION=false 1.2 new: org.apache.myfaces.SECRET added org.apache.myfaces.USE_ENCRYPTION = false org.apache.myfaces.CACHE_OLD_VIEWS_IN_SESSION_MODE=off (I patched this in 1.1 and removed the old references) Questions before I start profiling and probably sink time: 1) Is this typical or expected? 2) Is any new configuration flag added to 1.2 which could have high impact on performance? 3) Any other hints where to look at? Michael
access MethodExpression from actionListener
Hi,
I use a global action-listener defined in faces-config via the action-listener
tag to log called actions/actionsListeners.
With JSF 1.1 I used following code:
private void storeCalledAction(ActionEvent actionEvent){
ActionSource actionSource = (ActionSource) actionEvent.getComponent();
//1. check for action listener
MethodBinding methodBinding = actionSource.getActionListener();
if (methodBinding == null){
//2. check for action
methodBinding = actionSource.getAction();
}
if (methodBinding != null){
action = methodBinding.getExpressionString();
...
MethodBinding is deprecated in JSF1.2 and also null for actionListeners.
Therefore I changed ActionSource to ActionSource2 and MethodBinding to
MethodExpression.
private void storeCalledAction(final ActionEvent actionEvent){
ActionSource2 actionSource = (ActionSource2) actionEvent.getComponent();
MethodExpression methodExpression = actionSource.getActionExpression();
if (methodExpression==null){
ActionListener[] actionListeners = actionSource.getActionListeners();
if (actionListeners!=null actionListeners.length0){
ActionListener lastActionListener =
actionListeners[actionListeners.length-1];
// And now???
}
}
How can I access the methodExpression of the (now nested) ActionListeners?
They are of type javax.faces.event.MethodExpressionActionListener but there is
no getter available.
Do I have to patch MethodExpressionActionListener locally and add a getter or
is there an official alternative?
Michael
javascript problem with commandlink and onclick after update to JSF 1.2
Hi,
I have another problem after my update from myfaces 1.1.5 to 1.2.8.
I cannot use this anymore in onclick attributes of commandLinks due to
changed rendering of commandLinks. Instead of the link the outer form is
accessed via this.
sample:
h:form id=tabform ...
t:commandLink id=tabTemplates forceId=true
onclick=alert(this.id);
action=#{...}
output with 1.1.5: tabTemplates
output with 1.2.8: tabform
rendered html onclick attributes:
myfaces 1.2.8: onclick=var cf = function(){alert(this.id);var oamSF =
function(){return oamSubmitForm('tabform','tabTemplates');};return
(cf()==false)? false : oamSF();
myfaces 1.1.5: onclick=alert(this.id);
One workaround is something like this:
onclick=var me1=getObj('tabTemplates'); alert(m1);
This change is unfortunately really expensive and error-prone for me because I
used this construct more than hundred times and often it is generated
dynamically :-(
Is there any other workaround or trick to access the clicked link in the
onclick attribute via javascript inside a function definition?
How is the id of the commandLink placed into oamSubmitForm as parameter?
Michael
RE: javascript problem with commandlink and onclick after update to JSF 1.2
Hi Jakob,
I feared this.
I used this often in dynamic expressions returned from managed beans to do
some client side stuff e.g.
getOnclick(){
doit(this);
}
From my point of view it would be great if myfaces would replace »this« with
»document.getElementById('clienId')« automatically.
This would be a great improvement!
+1 from my side.
Michael
-Original Message-
From: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] On Behalf Of
Jakob Korherr
Sent: Montag, 4. Januar 2010 16:05
To: MyFaces Discussion
Subject: Re: javascript problem with commandlink and onclick after update to
JSF 1.2
Hi Michael,
Unfortunately I don't think it is possible to refer to the clicked link
inside the function definition. The only way I know is to use
document.getElementById('...').
»How is the id of the commandLink placed into oamSubmitForm as parameter?«
The renderer of the command link generates this javascript and so it puts
the id there.
From my point of view it would be great if myfaces would replace »this« with
»document.getElementById('clienId')« automatically. However, I don't know if
this violates the jsf 1.2 spec.
Regards,
Jakob
2010/1/4 Michael Heinen michael.hei...@recommind.com
Hi,
I have another problem after my update from myfaces 1.1.5 to 1.2.8.
I cannot use this anymore in onclick attributes of commandLinks due to
changed rendering of commandLinks. Instead of the link the outer form is
accessed via this.
sample:
h:form id=tabform ...
t:commandLink id=tabTemplates forceId=true
onclick=alert(this.id);
action=#{...}
output with 1.1.5: tabTemplates
output with 1.2.8: tabform
rendered html onclick attributes:
myfaces 1.2.8: onclick=var cf = function(){alert(this.id);var oamSF =
function(){return oamSubmitForm('tabform','tabTemplates');};return
(cf()==false)? false : oamSF();
myfaces 1.1.5: onclick=alert(this.id);
One workaround is something like this:
onclick=var me1=getObj('tabTemplates'); alert(m1);
This change is unfortunately really expensive and error-prone for me
because I used this construct more than hundred times and often it is
generated dynamically :-(
Is there any other workaround or trick to access the clicked link in the
onclick attribute via javascript inside a function definition?
How is the id of the commandLink placed into oamSubmitForm as parameter?
Michael
RE: javascript problem with commandlink and onclick after update to JSF 1.2
Hi Jakob,
Thanks for the initiative.
BTW Richfaces does not render command links this new way.
They do it still in the old way. The user specific content of the onclick
attribute is not wrapped in a js function and this is still working.
Maybe they are not spec compliant, don't know whether there are differences for
ajax and non-ajax commandlinks.
Michael
-Original Message-
From: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] On Behalf Of
Jakob Korherr
Sent: Montag, 4. Januar 2010 16:46
To: MyFaces Discussion
Subject: Re: javascript problem with commandlink and onclick after update to
JSF 1.2
Hi Michael,
I'll write a mail to the dev list and ask for opinions. On my opinion we
surely can implement this in tomahawk, because the spec does not define the
behavior of the tomahawk components and it certainly is an improvement.
I'll keep you up to date!
Regards,
Jakob
2010/1/4 Michael Heinen michael.hei...@recommind.com
Hi Jakob,
I feared this.
I used this often in dynamic expressions returned from managed beans to
do some client side stuff e.g.
getOnclick(){
doit(this);
}
From my point of view it would be great if myfaces would replace »this«
with »document.getElementById('clienId')« automatically.
This would be a great improvement!
+1 from my side.
Michael
-Original Message-
From: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] On
Behalf Of Jakob Korherr
Sent: Montag, 4. Januar 2010 16:05
To: MyFaces Discussion
Subject: Re: javascript problem with commandlink and onclick after update
to JSF 1.2
Hi Michael,
Unfortunately I don't think it is possible to refer to the clicked link
inside the function definition. The only way I know is to use
document.getElementById('...').
»How is the id of the commandLink placed into oamSubmitForm as parameter?«
The renderer of the command link generates this javascript and so it puts
the id there.
From my point of view it would be great if myfaces would replace »this«
with
»document.getElementById('clienId')« automatically. However, I don't know
if
this violates the jsf 1.2 spec.
Regards,
Jakob
2010/1/4 Michael Heinen michael.hei...@recommind.com
Hi,
I have another problem after my update from myfaces 1.1.5 to 1.2.8.
I cannot use this anymore in onclick attributes of commandLinks due to
changed rendering of commandLinks. Instead of the link the outer form is
accessed via this.
sample:
h:form id=tabform ...
t:commandLink id=tabTemplates forceId=true
onclick=alert(this.id);
action=#{...}
output with 1.1.5: tabTemplates
output with 1.2.8: tabform
rendered html onclick attributes:
myfaces 1.2.8: onclick=var cf = function(){alert(this.id);var oamSF =
function(){return oamSubmitForm('tabform','tabTemplates');};return
(cf()==false)? false : oamSF();
myfaces 1.1.5: onclick=alert(this.id);
One workaround is something like this:
onclick=var me1=getObj('tabTemplates'); alert(m1);
This change is unfortunately really expensive and error-prone for me
because I used this construct more than hundred times and often it is
generated dynamically :-(
Is there any other workaround or trick to access the clicked link in the
onclick attribute via javascript inside a function definition?
How is the id of the commandLink placed into oamSubmitForm as parameter?
Michael
RE: t:inputDate value problem in tomahawk 1.1.9
Hi Damar,
It's caused by different timezones.
Pls see this page:
http://wiki.apache.org/myfaces/FAQ#Date
Michael
-Original Message-
From: Damar Thapa [mailto:thapa.da...@gmail.com]
Sent: Samstag, 2. Januar 2010 09:49
To: MyFaces Discussion
Subject: Re: t:inputDate value problem in tomahawk 1.1.9
On Sat, Jan 2, 2010 at 4:46 PM, Damar Thapa thapa.da...@gmail.com wrote:
Hi,
Happy New Year 2010 to all.
I just tested the following code:
t:inputDate id=bDate type=date value=#{user.bDate}
popupCalendar=true/
I am using Myfaces-1.2.8, facelets-1.1.15, and tomahawk-1.1.9. Everything
looks fine, but the value of the input date comes out to be a day earlier.
For example, if I choose 15 January 2010 in the calendar, it assigns 14
January 2010 to user.bDate. Same thing happens if I disable
popupCalendar, and type the date.
Is this the bug, incompatibility issue, or I am missing something.
Any pointers would be highly appreciated.
With regards,
Damar
--
With regards,
Damar
commandButtons with type=button rendered as type=submit
Happy new year!
A question regarding commandButtons.
I noticed that the attribute type=button is not working anymore.
type=button is rendered with myfaces 1.1.5.
type=submit is rendered with myfaces 1.2.8.
Is this expected behavior according to spec or is it a bug?
myfaces 1.2.8
org.apache.myfaces.shared_impl.renderkit.html.HtmlButtonRendererBase.encodeEnd()
Line 116:
String type = getType(uiComponent);
if (type == null || !isReset(uiComponent))
{
type = HTML.INPUT_TYPE_SUBMIT;
}
myfaces 1.1.5
String type = getType(uiComponent);
if (type == null) {
type = HTML.INPUT_TYPE_SUBMIT;
}
Type submit is set now if type is not Reset!
Same is true for
org.apache.myfaces.shared_tomahawk.renderkit.html.HtmlButtonRendererBase.encodeEnd()
Workarounds are obvious:
a) patch HtmlButtonRendererBase locally and remove isReset check
b) add 'return false;' to the onclick attributes of all these buttons
c) write html directly
Question:
Should I create a Jira issue for this or is this working correctly in myfaces
1.2.8 and was a bug in myfaces 1.1.5?
Michael
Servlets return 404 after update to 1.2
Hi, After my update from myfaces 1.1.6 to to 1.2.8 I got a strange error in my Non-Faces Servlets. All Servlets are working well until I access the Faces Context as described in the WIKI: http://wiki.apache.org/myfaces/AccessFacesContextFromServlet After this all responses are empty and status is 404. Responses are sent correctly I don't access the FacesContext in the Servlet. This was of course working with myFaces 1.1.6 The workaround is obvious: Do no access FC in Servlets. But I would like to know the cause for this strange behavior. I can't find anything in the logfiles and didn't find anything during debugging. Stack of my servlet call: MyServlet.service(HttpServletRequest, HttpServletResponse) line: 72 MyServlet(HttpServlet).service(ServletRequest, ServletResponse) line: 717 ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 290 ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 206 CacheFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 114 ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 235 ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 206 StandardWrapperValve.invoke(Request, Response) line: 233 StandardContextValve.invoke(Request, Response) line: 191 BasicAuthenticator(AuthenticatorBase).invoke(Request, Response) line: 433 StandardHostValve.invoke(Request, Response) line: 128 ErrorReportValve.invoke(Request, Response) line: 102 StandardEngineValve.invoke(Request, Response) line: 109 CoyoteAdapter.service(Request, Response) line: 286 Http11Processor.process(Socket) line: 845 Michael
RE: Servlets return 404 after update to 1.2
This works! Thanks again Michael -Original Message- From: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] On Behalf Of Jakob Korherr Sent: Dienstag, 22. Dezember 2009 10:01 To: MyFaces Discussion Subject: Re: Servlets return 404 after update to 1.2 Hi Michael, Your problem is the following line: // set a new viewRoot, otherwise context.getViewRoot returns null UIViewRoot view = facesContext.getApplication().getViewHandler().createView(facesContext, ); In this line the current view handler trys to build the view , which, of course, does not exist and so the view handler sends a 404 not found. To fix this problem just remove the code that sets the UIViewRoot in the FacesContext (if you don't need it) or replace it with: facesContext.setViewRoot(new UIViewRoot()); This should work for you! Regards, Jakob 2009/12/22 Michael Heinen michael.hei...@recommind.com Hi, After my update from myfaces 1.1.6 to to 1.2.8 I got a strange error in my Non-Faces Servlets. All Servlets are working well until I access the Faces Context as described in the WIKI: http://wiki.apache.org/myfaces/AccessFacesContextFromServlet After this all responses are empty and status is 404. Responses are sent correctly I don't access the FacesContext in the Servlet. This was of course working with myFaces 1.1.6 The workaround is obvious: Do no access FC in Servlets. But I would like to know the cause for this strange behavior. I can't find anything in the logfiles and didn't find anything during debugging. Stack of my servlet call: MyServlet.service(HttpServletRequest, HttpServletResponse) line: 72 MyServlet(HttpServlet).service(ServletRequest, ServletResponse) line: 717 ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 290 ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 206 CacheFilter.doFilter(ServletRequest, ServletResponse, FilterChain) line: 114 ApplicationFilterChain.internalDoFilter(ServletRequest, ServletResponse) line: 235 ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 206 StandardWrapperValve.invoke(Request, Response) line: 233 StandardContextValve.invoke(Request, Response) line: 191 BasicAuthenticator(AuthenticatorBase).invoke(Request, Response) line: 433 StandardHostValve.invoke(Request, Response) line: 128 ErrorReportValve.invoke(Request, Response) line: 102 StandardEngineValve.invoke(Request, Response) line: 109 CoyoteAdapter.service(Request, Response) line: 286 Http11Processor.process(Socket) line: 845 Michael
[tomahawk] replaceIdWithLabel not working in t:messages after update to JSF 1.2
Hi,
I have another migration issue:
Error messages are rendered with the component ids instead of the label after
update from myfaces 1.1.6 to 1.2.8 and tomahawk to 12_1.1.9
jsp:
h:outputLabel for=name value=User/
h:panelGroup
h:inputText id=name value=#{MyController.name} required=true
Class
org.apache.myfaces.renderkit.html.ext.HtmlMessagesRenderer.getSummary(...)
contains following line (86):
msgSummary =
msgSummary.replaceAll(HtmlMessageRenderer.findInputId(facesContext,
msgClientId),inputLabel);
Content:
msgSummary= name: Validierungsfehler: Eingabe erforderlich.
HtmlMessageRenderer.findInputId(facesContext, msgClientId) returns
loginForm:name
inptutLabel= User
So the problem is that findInputId returns the full qualified clientid instead
of the id.
This worked with the old 1.1 jars.
Any ideas?
Michael
RE: [tomahawk] replaceIdWithLabel not working in t:messages after update to JSF 1.2
I found the issue during the creation of a small test project.
It was caused by a not correctly migrated patch for the UIInput.class.
Michael
-Original Message-
From: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] On Behalf Of
Jakob Korherr
Sent: Dienstag, 22. Dezember 2009 17:05
To: MyFaces Discussion
Subject: Re: [tomahawk] replaceIdWithLabel not working in t:messages after
update to JSF 1.2
Hi Michael,
I'm sorry, but I can not reproduce your problem. On my machine it is User:
Validierungsfehler: Eingabe erforderlich..
Can you please provide more information about your jsp.
Regards,
Jakob
2009/12/22 Michael Heinen michael.hei...@recommind.com
Hi,
I have another migration issue:
Error messages are rendered with the component ids instead of the label
after update from myfaces 1.1.6 to 1.2.8 and tomahawk to 12_1.1.9
jsp:
h:outputLabel for=name value=User/
h:panelGroup
h:inputText id=name value=#{MyController.name} required=true
Class
org.apache.myfaces.renderkit.html.ext.HtmlMessagesRenderer.getSummary(...)
contains following line (86):
msgSummary =
msgSummary.replaceAll(HtmlMessageRenderer.findInputId(facesContext,
msgClientId),inputLabel);
Content:
msgSummary= name: Validierungsfehler: Eingabe erforderlich.
HtmlMessageRenderer.findInputId(facesContext, msgClientId) returns
loginForm:name
inptutLabel= User
So the problem is that findInputId returns the full qualified clientid
instead of the id.
This worked with the old 1.1 jars.
Any ideas?
Michael
conversion error in selectmanyCheckbox - IllegalArgumentException - Cannot convert java.util.ArrayList
Hi,
I have another migration problem and cannot solve it so far.
One of my selectManyCheckboxes is not working anymore. A Conversion error is
thrown after form submission:
SCHWERWIEGEND: Cannot convert [soccer, tennis] of type class
java.util.ArrayList to class
com.recommind.litigation.client.web.model.utils.ArrayListWithSeparator
java.lang.IllegalArgumentException: Cannot convert [soccer, tennis] of type
class java.util.ArrayList to class
com.recommind.litigation.client.web.model.utils.ArrayListWithSeparator
at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:375)
at org.apache.el.parser.AstValue.setValue(AstValue.java:141)
at
org.apache.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:249)
at
org.apache.jasper.el.JspValueExpression.setValue(JspValueExpression.java:85)
at
javax.faces.component._ValueExpressionToValueBinding.setValue(_ValueExpressionToValueBinding.java:124)
at javax.faces.component.UIInput.updateModel(UIInput.java:282)
at
javax.faces.component.UIInput.processUpdates(UIInput.java:219)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:746)
at
org.apache.myfaces.custom.datalist.AbstractHtmlDataList.process(AbstractHtmlDataList.java:171)
at
org.apache.myfaces.custom.datalist.AbstractHtmlDataList.processChildren(AbstractHtmlDataList.java:150)
at
org.apache.myfaces.custom.datalist.AbstractHtmlDataList.processUpdates(AbstractHtmlDataList.java:95)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:746)
at
org.apache.myfaces.custom.aliasbean.AliasBeansScope.processUpdates(AliasBeansScope.java:222)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:746)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:746)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:746)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:746)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:746)
at
org.ajax4jsf.component.UIAjaxRegion.processUpdates(UIAjaxRegion.java:138)
at
org.ajax4jsf.component.AjaxViewRoot$2.invokeContextCallback(AjaxViewRoot.java:424)
at
org.ajax4jsf.component.ContextCallbackWrapper.invokeContextCallback(ContextCallbackWrapper.java:44)
at
javax.faces.component.UIComponent.invokeOnComponent(UIComponent.java:163)
This worked well with JSF 1.1 of course.
JSP:
t:dataList id=cpTList
value=#{AController.links}
var=cpLink
layout=simple
h:selectManyCheckbox id=cboxCPsel
rendered=#{cpLink.typeSelectManyCheckBox }
layout=pageDirection
value=#{ProxyController.activeWController.previewDocument.attributes[cpLink.name]}
f:selectItems
value=#{ProxyController.activeWController.scoredCategories[cpLink.name]}/
/h:selectManyCheckbox
previewDocument contains a Map with attributes.
The value here is of type ArrayListWithSeparator which is a subclass of
ArrayList with an overwritten toString() method.
So I tried to add a converter:
converter
converter-id/converter-id
--converter-for-classcom.foo.ArrayListWithSeparator/converter-for-class--
converter-classcom.foo.converters.ArrayListWithSeparatorConverter/converter-class
/converter
This converter is created and called if I specify it via ID and the converter
attribute.
The converter is not called via converter-class definition which is strange at
first sight.
Method getAsObject is called but I get A ClassCastException now:
public String getAsString(FacesContext context, UIComponent component, Object
value) throws ConverterException
{
ArrayListWithSeparatorString list = (ArrayListWithSeparatorString)
value;
Problem: value is of type String and cannot be cast to a
ArrayListWithSeparator.
CallStack:
ArrayListWithSeparatorConverter.getAsString(FacesContext, UIComponent, Object)
line: 81
RendererUtils.getConvertedStringValue(FacesContext, UIComponent, Converter,
Object) line: 648
RendererUtils.internalSubmittedOrSelectedValuesAsSet(FacesContext, UIComponent,
Converter, UISelectMany, Object) line: 709
The converter is called of every list member in line 709:
for (Iterator i = lst.iterator(); i.hasNext();)
set.add(getConvertedStringValue(context, component, converter,
i.next()));
Dead end! It seems to me that a custom converter does not help here.
Now I changed the EL expression. It works with JSF 1.2 with following
expression without any converters:
value=#{ProxyController.activeWController.dummies}
activeWController:
public
RE: conversion error in selectmanyCheckbox - IllegalArgumentException - Cannot convert java.util.ArrayList
Thanks Jakob.
This is a clear statement and I will change my impl instead of debugging
frameworks.
The converter was just a desperate approach.
But this is another compability issue which I can’t really understand.
It is working with JSF 1.1, is not working with JSF 1.2 and will be working
again in JSF 2.
This makes updates cumbersome.
So long,
Michael
From: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] On Behalf Of
Jakob Korherr
Sent: Freitag, 18. Dezember 2009 13:27
To: MyFaces Discussion
Cc: Michael Heinen
Subject: Re: conversion error in selectmanyCheckbox - IllegalArgumentException
- Cannot convert java.util.ArrayList
Hi Michael,
The problem is that the h:selectManyCheckbox creates a new ArrayList (or
array depending on the type of the property) every time you submit it. You
cannot tell it to use another implementation of List in JSF 1.2. However, it
will be possible in JSF 2.0 (actually I implemented this functionality on
MyFaces).
You have to use ArrayListString on your bean property. However, you can
create a new ArrayListWithSeparator in your setter method and invoke addAll()
passing the ArrayList as an argument.
The converter approach is totally wrong, sorry.
Regards,
Jakob
2009/12/18 Michael Heinen
michael.hei...@recommind.commailto:michael.hei...@recommind.com
Hi,
I have another migration problem and cannot solve it so far.
One of my selectManyCheckboxes is not working anymore. A Conversion error is
thrown after form submission:
SCHWERWIEGEND: Cannot convert [soccer, tennis] of type class
java.util.ArrayList to class
com.recommind.litigation.client.web.model.utils.ArrayListWithSeparator
java.lang.IllegalArgumentException: Cannot convert [soccer, tennis] of type
class java.util.ArrayList to class
com.recommind.litigation.client.web.model.utils.ArrayListWithSeparator
at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:375)
at org.apache.el.parser.AstValue.setValue(AstValue.java:141)
at
org.apache.el.ValueExpressionImpl.setValue(ValueExpressionImpl.java:249)
at
org.apache.jasper.el.JspValueExpression.setValue(JspValueExpression.java:85)
at
javax.faces.component._ValueExpressionToValueBinding.setValue(_ValueExpressionToValueBinding.java:124)
at javax.faces.component.UIInput.updateModel(UIInput.java:282)
at javax.faces.component.UIInput.processUpdates(UIInput.java:219)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:746)
at
org.apache.myfaces.custom.datalist.AbstractHtmlDataList.process(AbstractHtmlDataList.java:171)
at
org.apache.myfaces.custom.datalist.AbstractHtmlDataList.processChildren(AbstractHtmlDataList.java:150)
at
org.apache.myfaces.custom.datalist.AbstractHtmlDataList.processUpdates(AbstractHtmlDataList.java:95)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:746)
at
org.apache.myfaces.custom.aliasbean.AliasBeansScope.processUpdates(AliasBeansScope.java:222)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:746)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:746)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:746)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:746)
at
javax.faces.component.UIComponentBase.processUpdates(UIComponentBase.java:746)
at
org.ajax4jsf.component.UIAjaxRegion.processUpdates(UIAjaxRegion.java:138)
at
org.ajax4jsf.component.AjaxViewRoot$2.invokeContextCallback(AjaxViewRoot.java:424)
at
org.ajax4jsf.component.ContextCallbackWrapper.invokeContextCallback(ContextCallbackWrapper.java:44)
at
javax.faces.component.UIComponent.invokeOnComponent(UIComponent.java:163)
This worked well with JSF 1.1 of course.
JSP:
t:dataList id=cpTList
value=#{AController.links}
var=cpLink
layout=simple
h:selectManyCheckbox id=cboxCPsel
rendered=#{cpLink.typeSelectManyCheckBox }
layout=pageDirection
value=#{ProxyController.activeWController.previewDocument.attributes[cpLink.name]}
f:selectItems
value=#{ProxyController.activeWController.scoredCategories[cpLink.name]}/
/h:selectManyCheckbox
previewDocument contains a Map with attributes.
The value here is of type ArrayListWithSeparator which is a subclass of
ArrayList with an overwritten toString() method.
So I tried to add a converter:
converter
converter-id/converter-id
--converter-for-classcom.foo.ArrayListWithSeparator/converter-for-class--
converter-classcom.foo.converters.ArrayListWithSeparatorConverter/converter-class
/converter
This converter
JspPropertyNotWritableException - Illegal Syntax for Set Operation after update to 1.2
Hi,
are conditional Expressions not allowed anymore in value attributes in JSF 1.2?
Stack:
Caused by: org.apache.jasper.el.JspPropertyNotWritableException:
/pages/search.jsp(13,2)
'#{sessionScope.visit.user.restrictedToSearchInBatches?FlatBatchForReviewerCacheBean:NullBean}'
Illegal Syntax for Set Operation
at
org.apache.jasper.el.JspValueExpression.setValue(JspValueExpression.java:88)
at
org.apache.myfaces.custom.savestate.UISaveState.restoreState(UISaveState.java:125)
at
javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:849)
... 48 more
Tag:
t:saveState id=flatBatchForReviewerCacheBean
value=#{user.allowedToDoIt?FlatBatchForReviewerCacheBean:NullBean}/
It is working if I use either FlatBatchForReviewerCacheBean or NullBean without
the condition.
Input tags are also not working with conditions in the value attribute:
Message:
org.apache.jasper.el.JspPropertyNotWritableException: /pages/search.jsp(154,14)
'#{searchEntry.type=='dateFrom'?search.attributes[searchEntry.name].begin:search.attributes[searchEntry.name].end}'
Illegal Syntax for Set Operation
JSP snippet
t:dataList id=taxList
value=#{MyController.fields}
var=searchEntry ...
t:inputText id=s_date
value=#{searchEntry.type=='dateFrom'?search.attributes[searchEntry.name].begin:search.attributes[searchEntry.name].end}
/t:inputText
Both tags worked well with myfaces 1.1.6 and tomahawk 1.1.7 but not with
myfaces 1.2.8 and tomahawk12_1.1.9
Is it a bug?
Do I have to change anything or is there a workaround?
Michael
RE: JspPropertyNotWritableException - Illegal Syntax for Set Operation after update to 1.2
I was afraid of something like this.
Moving this logic into managed beans is not so easy because they are not always
accessible, or?
For some simple expressions it can be done but what about expressions in nested
lists?
Sample
t:dataList id=outer var=search
t:dataList id=inner var=searchEntry
t:inputText
value=#{searchEntry.type=='dateFrom'?search.attributes[searchEntry.name].begin:search.attributes[searchEntry.name].end}/
Local iteration var searchEntry does not know search which is in an outer
container and vice versa.
And I cannot pass variables (I don’t use facelets).
Isn’t this a major functionality loss?
Can I use another impl. of the unified EL? If yes which one would you recommend?
Michael
From: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] On Behalf Of
Jakob Korherr
Sent: Donnerstag, 17. Dezember 2009 10:54
To: MyFaces Discussion
Cc: Michael Heinen
Subject: Re: JspPropertyNotWritableException - Illegal Syntax for Set Operation
after update to 1.2
Hi Michael,
Due to the change to the Unified EL from MyFaces 1.1 to 1.2 some EL related
things changed. The problem you're describing is one of those, I'm afraid.
Looking at the first item in the stacktrace you can see that the Exception does
not come from MyFaces, but from tomcat's implementation of the Unified EL:
org.apache.jasper.el.JspValueExpression.
You can workaround this by moving the logic to a managed bean property.
Regards,
Jakob Korherr
2009/12/17 Michael Heinen
michael.hei...@recommind.commailto:michael.hei...@recommind.com
Hi,
are conditional Expressions not allowed anymore in value attributes in JSF 1.2?
Stack:
Caused by: org.apache.jasper.el.JspPropertyNotWritableException:
/pages/search.jsp(13,2)
'#{sessionScope.visit.user.restrictedToSearchInBatches?FlatBatchForReviewerCacheBean:NullBean}'
Illegal Syntax for Set Operation
at
org.apache.jasper.el.JspValueExpression.setValue(JspValueExpression.java:88)
at
org.apache.myfaces.custom.savestate.UISaveState.restoreState(UISaveState.java:125)
at
javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:849)
... 48 more
Tag:
t:saveState id=flatBatchForReviewerCacheBean
value=#{user.allowedToDoIt?FlatBatchForReviewerCacheBean:NullBean}/
It is working if I use either FlatBatchForReviewerCacheBean or NullBean without
the condition.
Input tags are also not working with conditions in the value attribute:
Message:
org.apache.jasper.el.JspPropertyNotWritableException: /pages/search.jsp(154,14)
'#{searchEntry.type=='dateFrom'?search.attributes[searchEntry.name].begin:search.attributes[searchEntry.name].end}'
Illegal Syntax for Set Operation
JSP snippet
t:dataList id=taxList
value=#{MyController.fields}
var=searchEntry ...
t:inputText id=s_date
value=#{searchEntry.type=='dateFrom'?search.attributes[searchEntry.name].begin:search.attributes[searchEntry.name].end}
/t:inputText
Both tags worked well with myfaces 1.1.6 and tomahawk 1.1.7 but not with
myfaces 1.2.8 and tomahawk12_1.1.9
Is it a bug?
Do I have to change anything or is there a workaround?
Michael
RE: JspPropertyNotWritableException - Illegal Syntax for Set Operation after update to 1.2
I just tried the latest 6.0.20 without success.
Do you think it's Bug in tomcat's EL impl?
If so I'll try to talk with some tomcat guys but this will take some time I
fear.
Michael
-Original Message-
From: Michael Heinen [mailto:michael.hei...@recommind.com]
Sent: Donnerstag, 17. Dezember 2009 11:40
To: MyFaces Discussion
Subject: RE: JspPropertyNotWritableException - Illegal Syntax for Set Operation
after update to 1.2
I was afraid of something like this.
Moving this logic into managed beans is not so easy because they are not always
accessible, or?
For some simple expressions it can be done but what about expressions in nested
lists?
Sample
t:dataList id=outer var=search
t:dataList id=inner var=searchEntry
t:inputText
value=#{searchEntry.type=='dateFrom'?search.attributes[searchEntry.name].begin:search.attributes[searchEntry.name].end}/
Local iteration var searchEntry does not know search which is in an outer
container and vice versa.
And I cannot pass variables (I don’t use facelets).
Isn’t this a major functionality loss?
Can I use another impl. of the unified EL? If yes which one would you recommend?
Michael
From: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] On Behalf Of
Jakob Korherr
Sent: Donnerstag, 17. Dezember 2009 10:54
To: MyFaces Discussion
Cc: Michael Heinen
Subject: Re: JspPropertyNotWritableException - Illegal Syntax for Set Operation
after update to 1.2
Hi Michael,
Due to the change to the Unified EL from MyFaces 1.1 to 1.2 some EL related
things changed. The problem you're describing is one of those, I'm afraid.
Looking at the first item in the stacktrace you can see that the Exception does
not come from MyFaces, but from tomcat's implementation of the Unified EL:
org.apache.jasper.el.JspValueExpression.
You can workaround this by moving the logic to a managed bean property.
Regards,
Jakob Korherr
2009/12/17 Michael Heinen
michael.hei...@recommind.commailto:michael.hei...@recommind.com
Hi,
are conditional Expressions not allowed anymore in value attributes in JSF 1.2?
Stack:
Caused by: org.apache.jasper.el.JspPropertyNotWritableException:
/pages/search.jsp(13,2)
'#{sessionScope.visit.user.restrictedToSearchInBatches?FlatBatchForReviewerCacheBean:NullBean}'
Illegal Syntax for Set Operation
at
org.apache.jasper.el.JspValueExpression.setValue(JspValueExpression.java:88)
at
org.apache.myfaces.custom.savestate.UISaveState.restoreState(UISaveState.java:125)
at
javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:849)
... 48 more
Tag:
t:saveState id=flatBatchForReviewerCacheBean
value=#{user.allowedToDoIt?FlatBatchForReviewerCacheBean:NullBean}/
It is working if I use either FlatBatchForReviewerCacheBean or NullBean without
the condition.
Input tags are also not working with conditions in the value attribute:
Message:
org.apache.jasper.el.JspPropertyNotWritableException: /pages/search.jsp(154,14)
'#{searchEntry.type=='dateFrom'?search.attributes[searchEntry.name].begin:search.attributes[searchEntry.name].end}'
Illegal Syntax for Set Operation
JSP snippet
t:dataList id=taxList
value=#{MyController.fields}
var=searchEntry ...
t:inputText id=s_date
value=#{searchEntry.type=='dateFrom'?search.attributes[searchEntry.name].begin:search.attributes[searchEntry.name].end}
/t:inputText
Both tags worked well with myfaces 1.1.6 and tomahawk 1.1.7 but not with
myfaces 1.2.8 and tomahawk12_1.1.9
Is it a bug?
Do I have to change anything or is there a workaround?
Michael
RE: JspPropertyNotWritableException - Illegal Syntax for Set Operation after update to 1.2
Thanks for the samples Jakob.
I tried it this way but t:savestate does not work so far.
Sample jsp:
works: t:saveState id=foo value=#{foobean}/
works not: t:saveState id=aaa value=#{ELUtilController.mybean}/
public class ELUtilController {
private Object getManagedBean(String beanName){
FacesContext fc = FacesContext.getCurrentInstance();
return fc.getApplication().getVariableResolver().resolveVariable(fc,
beanName);
//the deprecated way
}
public Object getMybean(){
if (user.isRestricted()){
return getManagedBean(bean1);
}
return getManagedBean(bean2);
}
public void setMybean(Object o){
//what’s to do here???
}
}
“bean1” is currently instantiated again during submit which should not occur.
“foobean” is not instantiated a second time.
What should I do in the setter setMybean? The passed object is “bean1”.
Do I have to call anything in setMybean?
“bean1” is also instantiated only one time if I use it directly: t:saveState
id=bbb value=#{bean1}/
Michael
From: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] On Behalf Of
Jakob Korherr
Sent: Donnerstag, 17. Dezember 2009 12:35
To: MyFaces Discussion
Cc: Michael Heinen
Subject: Re: JspPropertyNotWritableException - Illegal Syntax for Set Operation
after update to 1.2
Hi Michael,
No problem ;)
I don't think it's a bug in the Unified EL impl of tomcat. It's rather a
specification bug or just not wanted by the spec. However, I don't know the
unified EL spec very well, so I don't know it exactly.
To your problem: you can resolve any EL expression in the managed bean method
using the ExpressionFactory, for example:
FacesContext facesContext = FacesContext.getCurrentInstance();
facesContext.getApplication().getExpressionFactory().createValueExpression(facesContext.getELContext(),
#{searchEntry.type=='dateForm'},
Boolean.class).getValue(facesContext.getELContext());
This is also true for those objects, which are generated by the t:dataList,
because the property in the managed bean is evaluated while the objects are in
the request scope. Just try it!
However, a better method would be to use the binding attribute of the
t:dataList, for example binding = #{bean.myDataTable}. Then you can access the
current row data inside the managed bean with myDataTable.getRowData() (the
type of myDataTable is org.apache.myfaces.component.html.ext.HtmlDataTable).
Hope this helps!
Regards,
Jakob
2009/12/17 Michael Heinen
michael.hei...@recommind.commailto:michael.hei...@recommind.com
I just tried the latest 6.0.20 without success.
Do you think it's Bug in tomcat's EL impl?
If so I'll try to talk with some tomcat guys but this will take some time I
fear.
Michael
-Original Message-
From: Michael Heinen
[mailto:michael.hei...@recommind.commailto:michael.hei...@recommind.com]
Sent: Donnerstag, 17. Dezember 2009 11:40
To: MyFaces Discussion
Subject: RE: JspPropertyNotWritableException - Illegal Syntax for Set Operation
after update to 1.2
I was afraid of something like this.
Moving this logic into managed beans is not so easy because they are not always
accessible, or?
For some simple expressions it can be done but what about expressions in nested
lists?
Sample
t:dataList id=outer var=search
t:dataList id=inner var=searchEntry
t:inputText
value=#{searchEntry.type=='dateFrom'?search.attributes[searchEntry.name].begin:search.attributes[searchEntry.name].end}/
Local iteration var searchEntry does not know search which is in an outer
container and vice versa.
And I cannot pass variables (I don’t use facelets).
Isn’t this a major functionality loss?
Can I use another impl. of the unified EL? If yes which one would you recommend?
Michael
From: sethfromaust...@gmail.commailto:sethfromaust...@gmail.com
[mailto:sethfromaust...@gmail.commailto:sethfromaust...@gmail.com] On Behalf
Of Jakob Korherr
Sent: Donnerstag, 17. Dezember 2009 10:54
To: MyFaces Discussion
Cc: Michael Heinen
Subject: Re: JspPropertyNotWritableException - Illegal Syntax for Set Operation
after update to 1.2
Hi Michael,
Due to the change to the Unified EL from MyFaces 1.1 to 1.2 some EL related
things changed. The problem you're describing is one of those, I'm afraid.
Looking at the first item in the stacktrace you can see that the Exception does
not come from MyFaces, but from tomcat's implementation of the Unified EL:
org.apache.jasper.el.JspValueExpression.
You can workaround this by moving the logic to a managed bean property.
Regards,
Jakob Korherr
2009/12/17 Michael Heinen
michael.hei...@recommind.commailto:michael.hei...@recommind.commailto:michael.hei...@recommind.commailto:michael.hei...@recommind.com
Hi,
are conditional Expressions not allowed anymore in value attributes in JSF 1.2?
Stack:
Caused by: org.apache.jasper.el.JspPropertyNotWritableException:
/pages/search.jsp(13,2)
'#{sessionScope.visit.user.restrictedToSearchInBatches?FlatBatchForReviewerCacheBean:NullBean}'
Illegal
RE: JspPropertyNotWritableException - Illegal Syntax for Set Operation after update to 1.2
Why are these EL conditions working in outputText tags but not in others like
t:saveSate, t:inputText, f:selectItems and so on after form submission?
It's the same EL impl, or?
I used these EL conditions really often and I'm currently not able to convert
them or move them into a managed bean.
This is another blocker for my migration.
Michael
-Original Message-
From: Michael Heinen [mailto:michael.hei...@recommind.com]
Sent: Donnerstag, 17. Dezember 2009 15:28
To: Jakob Korherr; MyFaces Discussion
Subject: RE: JspPropertyNotWritableException - Illegal Syntax for Set Operation
after update to 1.2
Thanks for the samples Jakob.
I tried it this way but t:savestate does not work so far.
Sample jsp:
works: t:saveState id=foo value=#{foobean}/
works not: t:saveState id=aaa value=#{ELUtilController.mybean}/
public class ELUtilController {
private Object getManagedBean(String beanName){
FacesContext fc = FacesContext.getCurrentInstance();
return fc.getApplication().getVariableResolver().resolveVariable(fc,
beanName);
//the deprecated way
}
public Object getMybean(){
if (user.isRestricted()){
return getManagedBean(bean1);
}
return getManagedBean(bean2);
}
public void setMybean(Object o){
//what’s to do here???
}
}
“bean1” is currently instantiated again during submit which should not occur.
“foobean” is not instantiated a second time.
What should I do in the setter setMybean? The passed object is “bean1”.
Do I have to call anything in setMybean?
“bean1” is also instantiated only one time if I use it directly: t:saveState
id=bbb value=#{bean1}/
Michael
From: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] On Behalf Of
Jakob Korherr
Sent: Donnerstag, 17. Dezember 2009 12:35
To: MyFaces Discussion
Cc: Michael Heinen
Subject: Re: JspPropertyNotWritableException - Illegal Syntax for Set Operation
after update to 1.2
Hi Michael,
No problem ;)
I don't think it's a bug in the Unified EL impl of tomcat. It's rather a
specification bug or just not wanted by the spec. However, I don't know the
unified EL spec very well, so I don't know it exactly.
To your problem: you can resolve any EL expression in the managed bean method
using the ExpressionFactory, for example:
FacesContext facesContext = FacesContext.getCurrentInstance();
facesContext.getApplication().getExpressionFactory().createValueExpression(facesContext.getELContext(),
#{searchEntry.type=='dateForm'},
Boolean.class).getValue(facesContext.getELContext());
This is also true for those objects, which are generated by the t:dataList,
because the property in the managed bean is evaluated while the objects are in
the request scope. Just try it!
However, a better method would be to use the binding attribute of the
t:dataList, for example binding = #{bean.myDataTable}. Then you can access the
current row data inside the managed bean with myDataTable.getRowData() (the
type of myDataTable is org.apache.myfaces.component.html.ext.HtmlDataTable).
Hope this helps!
Regards,
Jakob
2009/12/17 Michael Heinen
michael.hei...@recommind.commailto:michael.hei...@recommind.com
I just tried the latest 6.0.20 without success.
Do you think it's Bug in tomcat's EL impl?
If so I'll try to talk with some tomcat guys but this will take some time I
fear.
Michael
-Original Message-
From: Michael Heinen
[mailto:michael.hei...@recommind.commailto:michael.hei...@recommind.com]
Sent: Donnerstag, 17. Dezember 2009 11:40
To: MyFaces Discussion
Subject: RE: JspPropertyNotWritableException - Illegal Syntax for Set Operation
after update to 1.2
I was afraid of something like this.
Moving this logic into managed beans is not so easy because they are not always
accessible, or?
For some simple expressions it can be done but what about expressions in nested
lists?
Sample
t:dataList id=outer var=search
t:dataList id=inner var=searchEntry
t:inputText
value=#{searchEntry.type=='dateFrom'?search.attributes[searchEntry.name].begin:search.attributes[searchEntry.name].end}/
Local iteration var searchEntry does not know search which is in an outer
container and vice versa.
And I cannot pass variables (I don’t use facelets).
Isn’t this a major functionality loss?
Can I use another impl. of the unified EL? If yes which one would you recommend?
Michael
From: sethfromaust...@gmail.commailto:sethfromaust...@gmail.com
[mailto:sethfromaust...@gmail.commailto:sethfromaust...@gmail.com] On Behalf
Of Jakob Korherr
Sent: Donnerstag, 17. Dezember 2009 10:54
To: MyFaces Discussion
Cc: Michael Heinen
Subject: Re: JspPropertyNotWritableException - Illegal Syntax for Set Operation
after update to 1.2
Hi Michael,
Due to the change to the Unified EL from MyFaces 1.1 to 1.2 some EL related
things changed. The problem you're describing is one of those, I'm afraid.
Looking at the first item in the stacktrace you can see that the Exception does
not come from MyFaces, but from tomcat's
RE: JspPropertyNotWritableException - Illegal Syntax for Set Operation after update to 1.2
Incredible! Thanks Jakob for this sample code, this helped a lot and it works
of course ☺
Things like this make the JSF development too complicated from my point of view.
Developers have to spent too much time with the framework or to find
workarounds for such shortcomings.
Regardless of whether this is a lack in the spec or in the impl.
I spent currently more time with the frameworks (myfaces, tomahawk, richfaces,
tiles, etc etc) than with the application.
Of course it's a major jump and with a large application but these compability
issues are really bitter…
I'm curious about the next one ...
Michael
From: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] On Behalf Of
Jakob Korherr
Sent: Donnerstag, 17. Dezember 2009 16:11
To: MyFaces Discussion
Cc: Michael Heinen
Subject: Re: JspPropertyNotWritableException - Illegal Syntax for Set Operation
after update to 1.2
Hi Michael,
Please use
FacesContext facesContext = FacesContext.getCurrentInstance();
facesContext.getApplication().getExpressionFactory().createValueExpression(facesContext.getELContext(),
#{beanName}, Object.class).getValue(facesContext.getELContext());
to resolve the managed bean in private Object getManagedBean(String beanName).
In the setter you can do the following:
FacesContext facesContext = FacesContext.getCurrentInstance();
facesContext.getApplication().getExpressionFactory().createValueExpression(facesContext.getELContext(),
#{beanName}, Object.class).setValue(facesContext.getELContext(), o);
And to your question: Why are these EL conditions working in outputText tags
but not in others like
t:saveSate, t:inputText, f:selectItems and so on after form submission?
It's the same EL impl, or?
You can use ? : for ValueExpressions which are only used to GET a value (e.g.
h:outputText). If you use them in a ValueExpression which might also SET the
value of the property, you will get an Exception (e.g. h:inputText).
Regards,
Jakob
2009/12/17 Michael Heinen
michael.hei...@recommind.commailto:michael.hei...@recommind.com
Why are these EL conditions working in outputText tags but not in others like
t:saveSate, t:inputText, f:selectItems and so on after form submission?
It's the same EL impl, or?
I used these EL conditions really often and I'm currently not able to convert
them or move them into a managed bean.
This is another blocker for my migration.
Michael
-Original Message-
From: Michael Heinen
[mailto:michael.hei...@recommind.commailto:michael.hei...@recommind.com]
Sent: Donnerstag, 17. Dezember 2009 15:28
To: Jakob Korherr; MyFaces Discussion
Subject: RE: JspPropertyNotWritableException - Illegal Syntax for Set Operation
after update to 1.2
Thanks for the samples Jakob.
I tried it this way but t:savestate does not work so far.
Sample jsp:
works: t:saveState id=foo value=#{foobean}/
works not: t:saveState id=aaa value=#{ELUtilController.mybean}/
public class ELUtilController {
private Object getManagedBean(String beanName){
FacesContext fc = FacesContext.getCurrentInstance();
return fc.getApplication().getVariableResolver().resolveVariable(fc,
beanName);
//the deprecated way
}
public Object getMybean(){
if (user.isRestricted()){
return getManagedBean(bean1);
}
return getManagedBean(bean2);
}
public void setMybean(Object o){
//what’s to do here???
}
}
“bean1” is currently instantiated again during submit which should not occur.
“foobean” is not instantiated a second time.
What should I do in the setter setMybean? The passed object is “bean1”.
Do I have to call anything in setMybean?
“bean1” is also instantiated only one time if I use it directly: t:saveState
id=bbb value=#{bean1}/
Michael
From: sethfromaust...@gmail.commailto:sethfromaust...@gmail.com
[mailto:sethfromaust...@gmail.commailto:sethfromaust...@gmail.com] On Behalf
Of Jakob Korherr
Sent: Donnerstag, 17. Dezember 2009 12:35
To: MyFaces Discussion
Cc: Michael Heinen
Subject: Re: JspPropertyNotWritableException - Illegal Syntax for Set Operation
after update to 1.2
Hi Michael,
No problem ;)
I don't think it's a bug in the Unified EL impl of tomcat. It's rather a
specification bug or just not wanted by the spec. However, I don't know the
unified EL spec very well, so I don't know it exactly.
To your problem: you can resolve any EL expression in the managed bean method
using the ExpressionFactory, for example:
FacesContext facesContext = FacesContext.getCurrentInstance();
facesContext.getApplication().getExpressionFactory().createValueExpression(facesContext.getELContext(),
#{searchEntry.type=='dateForm'},
Boolean.class).getValue(facesContext.getELContext());
This is also true for those objects, which are generated by the t:dataList,
because the property in the managed bean is evaluated while the objects are in
the request scope. Just try it!
However, a better method would be to use the binding attribute of the
t:dataList, for example binding = #{bean.myDataTable}. Then you
RE: updateActionListener not working with tomahawk12_1.1.9?
Thanks Guys for the really fast and good support!
I use now f:setPropertyActionListener as a workaround.
and created TOMAHAWK-1475
I am curious when my migration is over.
Michael
-Original Message-
From: Leonardo Uribe [mailto:lu4...@gmail.com]
Sent: Dienstag, 15. Dezember 2009 22:35
To: MyFaces Discussion
Subject: Re: updateActionListener not working with tomahawk12_1.1.9?
Hi
I remember an issue not the same but related:
http://issues.apache.org/jira/browse/MYFACES-1819
In few words the problem is that in EL, expressions like
#{bean.map['somekey']} returns null when getType() is called. Note this
does not happens in jsf 1.1, but on jsf 1.2.
Checking the code of f:setPropertyActionListener, it just do a simple call
like this:
target.setValue(ectx, value.getValue(ectx));
But t:updateActionListener has an additional converter property, so it try
to use the converter before call setValue.
It is a bug on t:updateActionListener, so it could be good create an issue
on
http://issues.apache.org/jira/browse/TOMAHAWK
to solve it in a similar way as MYFACES-1819 does.
regards,
Leonardo Uribe
2009/12/15 Mike Kienenberger mkien...@gmail.com
I had a similar issue.
What I did was replace t:updateActionListener property= with the
standardized f:setPropertyActionListener target=.
f:setPropertyActionListener better supports edge cases under Facelets
as well.
Other than avoiding the one-time conversion cost of the page
templates, there's no benefit to continuing to use
t:updateActionListener. I used a regular expression in Eclipse to
make the change, so it was pretty painless.
On Tue, Dec 15, 2009 at 1:09 PM, Jakob Korherr jakob.korh...@gmail.com
wrote:
Hi,
The NullPointerException is raised in the following line:
if (!type.equals(String.class) ! type.equals(Object.class))
Thus type is null.
type is the result of calling getPropertyBinding().getType(facesContext),
which returns null in your case.
However, I don't know exactly why this returns null, but maybe this
clarification is the trigger for someone else, who knows it.
Regards,
Jakob Korherr
2009/12/15 Michael Heinen michael.hei...@recommind.com
Hi,
I am still working on my update from JSF 1.1 to 1.2.
Now Buttons using a t:updateActionListener are not working anymore due
to a
java.lang.NullPointerException
at
org.apache.myfaces.custom.updateactionlistener.UpdateActionListener.processAction(UpdateActionListener.java:137)
The buttons are working with the 1.1 compliant libs.
The buttons are working without t:updateActionListener.
Complete Stack:
javax.faces.FacesException: Exception while calling broadcast on
component
: {Component-Path : [Class: org.ajax4jsf.component.AjaxViewRoot,ViewId:
/batches.jsp][Class: org.apache.myfaces.custom.document.Document,Id:
j_id_jsp_1727476414_3][Class:
org.apache.myfaces.custom.document.DocumentBody,Id:
j_id_jsp_1727476414_7][Class: org.apache.myfaces.custom.div.Div,Id:
content][Class: org.apache.myfaces.custom.div.Div,Id: batches][Class:
javax.faces.component.html.HtmlForm,Id: batchesForm][Class:
org.apache.myfaces.custom.div.Div,Id: batchlist][Class:
org.apache.myfaces.custom.datalist.HtmlDataList,Id:
j_id_jsp_1874425695_8][Class: org.apache.myfaces.custom.div.Div,Id:
j_id_jsp_1874425695_9][Class: org.apache.myfaces.custom.div.Div,Id:
openBatchBox][Class:
org.apache.myfaces.component.html.ext.HtmlCommandButton,Id:
batchSelectCmd]}
at
javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:562)
at
javax.faces.component.UICommand.broadcast(UICommand.java:110)
at
javax.faces.component.UIData.broadcast(UIData.java:721)
at
org.ajax4jsf.component.AjaxViewRoot.processEvents(AjaxViewRoot.java:324)
at
org.ajax4jsf.component.AjaxViewRoot.broadcastEvents(AjaxViewRoot.java:299)
at
org.ajax4jsf.component.AjaxViewRoot.processPhase(AjaxViewRoot.java:256)
at
org.ajax4jsf.component.AjaxViewRoot.processDecodes(AjaxViewRoot.java:412)
at
org.apache.myfaces.lifecycle.ApplyRequestValuesExecutor.execute(ApplyRequestValuesExecutor.java:32)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
at
org.apache.myfaces.custom.ppr.PPRLifecycleWrapper.execute(PPRLifecycleWrapper.java:68)
at
javax.faces.webapp.FacesServlet.service(FacesServlet.java:178)
at
com.recommind.xxx..servlets.FacesServletWrapper.service(FacesServletWrapper.java:123)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290
updateActionListener in JSF 1.2 - exec before outer action possible?
Hi,
What's the recommended migration for tomahawk updateActionListener from JSF 1.1
to 1.2? I did not find any helpful hints so far.
In JSF 1.1 the updateActionListener was called before the Action/ActionListener
of the outer command.
In JSF 1.2 the order has changed apparently. The component actionListener is
invoked and then nested actionListeners.
f:setPropertyActionListener can be used but it is called after the outer
command.
And the outer command is called twice in my case.
Is f:actionListener an alternative for Actions (not ActionListeners)? I didn't
get this working.
JSF 1.1:
t:commandButton id=acmd1 actionListener=#{MyController.doIt}
t:updateActionListener property=#{MyController.stateId}
value=bean.value/
/tcommandButton
Flow:
MyController.setStateId()
MyController.doIt()
JSF 1.2
t:commandLink id=acmd1 action=#{MyController.doIt}
f:setPropertyActionListener target=#{MyController.stateId}
value=#{bean.value}/
/t:commandLink
Flow:
MyController.doIt()
MyController.setStateId()
MyController.doIt()
How did other people solve this?
Michael
RE: updateActionListener in JSF 1.2 - exec before outer action possible?
Damn copy paste error. I meant in JSF 1.1 of course:
t:commandButton id=acmd1 action=#{MyController.doIt}
-Original Message-
From: Michael Heinen [mailto:michael.hei...@recommind.com]
Sent: Mittwoch, 16. Dezember 2009 11:51
To: MyFaces Discussion
Subject: updateActionListener in JSF 1.2 - exec before outer action possible?
Hi,
What's the recommended migration for tomahawk updateActionListener from JSF 1.1
to 1.2? I did not find any helpful hints so far.
In JSF 1.1 the updateActionListener was called before the Action/ActionListener
of the outer command.
In JSF 1.2 the order has changed apparently. The component actionListener is
invoked and then nested actionListeners.
f:setPropertyActionListener can be used but it is called after the outer
command.
And the outer command is called twice in my case.
Is f:actionListener an alternative for Actions (not ActionListeners)? I didn't
get this working.
JSF 1.1:
t:commandButton id=acmd1 actionListener=#{MyController.doIt}
t:updateActionListener property=#{MyController.stateId}
value=bean.value/
/tcommandButton
Flow:
MyController.setStateId()
MyController.doIt()
JSF 1.2
t:commandLink id=acmd1 action=#{MyController.doIt}
f:setPropertyActionListener target=#{MyController.stateId}
value=#{bean.value}/
/t:commandLink
Flow:
MyController.doIt()
MyController.setStateId()
MyController.doIt()
How did other people solve this?
Michael
RE: updateActionListener in JSF 1.2 - exec before outer action possible?
Mike, you are right, it is working as expected.
The first call of doIt() in my sample was caused by lazy initialization from
faces-config.
I'm sorry for this wrong report and wasting time, I was confused due to so many
problems in the last days.
Got today a working beta from richfaces which enables ajax rerendering again.
This migration is killing me...
Michael
-Original Message-
From: Mike Kienenberger [mailto:mkien...@gmail.com]
Sent: Mittwoch, 16. Dezember 2009 15:54
To: MyFaces Discussion
Subject: Re: updateActionListener in JSF 1.2 - exec before outer action
possible?
Sorry, that last example should have been:
h:commandButton action=#{test.doItTest1}
actionListener=#{test.execute}
t:updateActionListener property=#{test.stringValue}
value=one/
t:updateActionListener property=#{test.stringValue}
value=two/
/h:commandButton
I cut and paste the wrong part of the page code.
On Wed, Dec 16, 2009 at 9:46 AM, Mike Kienenberger mkien...@gmail.com wrote:
I am using Myfaces Core 1.2.8, Facelets 1.1.14, and Myfaces Tomahawk 1.1.9.
I'm not seeing the problems you are having. Perhaps it is because of
facelets.
I wrote some simple tests, and here's what I got for the most complicated one:
h:commandButton action=#{test.doItTest1}
actionListener=#{test.execute}
f:setPropertyActionListener target=#{test.stringValue}
value=one/
f:setPropertyActionListener target=#{test.stringValue}
value=two/
/h:commandButton
TestBean: execute()
TestBean: setStringValue()=one
TestBean: setStringValue()=two
TestBean: doItTest1()
If you have something specific, I'll give that a try, but I started
with your original examples.
I mixed in some t:updateALs, and the only thing that didn't work was
multiple t:UALs. Another reason not to use it.
h:commandButton action=#{test.doItTest1}
f:setPropertyActionListener target=#{test.stringValue}
value=one/
f:setPropertyActionListener target=#{test.stringValue}
value=two/
/h:commandButton
TestBean: execute()
TestBean: setStringValue()=one
TestBean: doItTest1()
On Wed, Dec 16, 2009 at 5:51 AM, Michael Heinen
michael.hei...@recommind.com wrote:
Hi,
What's the recommended migration for tomahawk updateActionListener from JSF
1.1 to 1.2? I did not find any helpful hints so far.
In JSF 1.1 the updateActionListener was called before the
Action/ActionListener of the outer command.
In JSF 1.2 the order has changed apparently. The component actionListener is
invoked and then nested actionListeners.
f:setPropertyActionListener can be used but it is called after the outer
command.
And the outer command is called twice in my case.
Is f:actionListener an alternative for Actions (not ActionListeners)? I
didn't get this working.
JSF 1.1:
t:commandButton id=acmd1 actionListener=#{MyController.doIt}
t:updateActionListener property=#{MyController.stateId}
value=bean.value/
/tcommandButton
Flow:
MyController.setStateId()
MyController.doIt()
JSF 1.2
t:commandLink id=acmd1 action=#{MyController.doIt}
f:setPropertyActionListener target=#{MyController.stateId}
value=#{bean.value}/
/t:commandLink
Flow:
MyController.doIt()
MyController.setStateId()
MyController.doIt()
How did other people solve this?
Michael
updateActionListener not working with tomahawk12_1.1.9?
)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Sample jsp snippet:
t:dataList var=batch
value=#{MyController1.myList} ...
t:commandButton id=batchSelectCmd forceId=true
immediate=true
action=#{MyController12.search}
value=foo
disabled=#{empty
batch.attributes['reviewState'][0]}
...
t:updateActionListener property=#{requestScope['selectedBatch']}
value=#{batch.value}/
/t:commandButton
/t:dataList
Updated Libs:
myFaces from 1.1.6 to 1.2.8
tomahawk from 1.1.7 to tomahawk12-1.1.9
tomhahawk sandbox from 1.1.7 to 1.1.9
richfaces from 3.1.5 to 3.3.2 (api,impl and ui)
tiles from 1 to 2.0.5
Any ideas?
Michael
[cid:image001.gif@01CA7DB0.113FA420]
Michael Heinen
Senior Software Engineer
Recommind GmbH
Tel: +49 (0) 2226 1596620
Email: michael.hei...@recommind.commailto:michael.hei...@recommind.com
Recommind GmbH, Vertretungsberechtigter Geschäftsführer Hartwig Laute,
Registergericht Amtsgericht Bonn, Registernummer HRB 10646
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorised
copying, disclosure or distribution of the material in this e-mail is strictly
forbidden.
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten
haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail.
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht
gestattet.
duplicate component ids after mirgration to JSF 1.2
I have massive problems with duplicate component ids after updating: - myFaces from 1.1.6 to 1.2.8 - tomahawk from 1.1.7 to tomahawk12-1.1.9 - tomhahawk sandbox from 1.1.7 to 1.1.9 - richfaces from 3.1.5 to 3.3.2 (api,impl and ui) - tiles from 1 to 2.0.5 The curious thing is that unique ids are claimed to be a duplicate. If I rename such an id to another one with a random number then this id is claimed! Sample stack: java.lang.IllegalStateException: duplicate Id for a component searches at org.ajax4jsf.application.TreeStructureNode.apply(TreeStructureNode.java:68) at org.ajax4jsf.application.TreeStructureNode.apply(TreeStructureNode.java:92) at org.ajax4jsf.application.TreeStructureNode.apply(TreeStructureNode.java:92) at org.ajax4jsf.application.TreeStructureNode.apply(TreeStructureNode.java:92) at org.ajax4jsf.application.TreeStructureNode.apply(TreeStructureNode.java:92) at org.ajax4jsf.application.TreeStructureNode.apply(TreeStructureNode.java:92) at org.ajax4jsf.application.TreeStructureNode.apply(TreeStructureNode.java:92) at org.ajax4jsf.application.TreeStructureNode.apply(TreeStructureNode.java:92) at org.ajax4jsf.application.TreeStructureNode.apply(TreeStructureNode.java:92) at org.ajax4jsf.application.TreeStructureNode.apply(TreeStructureNode.java:92) at org.ajax4jsf.application.TreeStructureNode.apply(TreeStructureNode.java:92) at org.ajax4jsf.application.TreeStructureNode.apply(TreeStructureNode.java:92) at org.ajax4jsf.application.TreeStructureNode.apply(TreeStructureNode.java:92) at org.ajax4jsf.application.TreeStructureNode.apply(TreeStructureNode.java:92) at org.ajax4jsf.application.TreeStructureNode.apply(TreeStructureNode.java:92) at org.ajax4jsf.application.AjaxStateManager.getTreeStructureToSave(AjaxStateManager.java:187) at org.ajax4jsf.application.AjaxStateManager.buildViewState(AjaxStateManager.java:498) at org.ajax4jsf.application.AjaxStateManager.saveView(AjaxStateManager.java:462) at org.apache.myfaces.tomahawk.application.jsp.JspTilesTwoViewHandlerImpl.renderTilesView(JspTilesTwoViewHandlerImpl.java:211) Sample tag: t:div id=searches forceId=true I use this tag with forceId many times (with different ids of course) and on some pages I get the duplicate id exceptions! I don't use c-tags, scriptlets or other dirty tags and the ebove div is not inside collection tags like datatable or datalist. I cannot see any pattern in this kind of error. Are there any known issues regarding duplicate ids or the tree creation? Is this rather a myfaces, tomahawk or richfaces issue? Thanks, Michael
RE: pages not rendered anymore after update from 1.1.6 to 1.2.8
I started this thread so I keep you up to date with my improvements of the migration. Some pages are now working basically with Tiles 2.0.5. 1) Migrated to Tiles2 according this guide: http://tiles.apache.org/migration/index.html 2) Renamed my tiles-definitions file to tiles.xml! Other names defined in the web.xml are not working. Unfortunately I had another name which cost me quite some hours. 3) I had to add commons-discovery-0.4.jar to the libs Not every project can migrate to Facelets easily. This means also some migration and QA effort. My project is under heavy development and started 4 years ago with Tiles. Facelets was a beta 0.1 at this time and it was not obvious at that it would become a standard. Sooner or later I will migrate to Facelets but right now this is no alternative. Michael -Original Message- From: Leonardo Uribe [mailto:lu4...@gmail.com] Sent: Mittwoch, 9. Dezember 2009 04:31 To: MyFaces Discussion Subject: Re: pages not rendered anymore after update from 1.1.6 to 1.2.8 Hi The example available here: http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/examples/tiles/ works with jsf 1.2 and tomahawk12-1.1.x (to execute it try mvn clean -Djsf=12 -Dtomahawk=12 jetty:run) Note that use jsf 1.2 and tomahawk-1.1.x does not work, because some changes in ViewHandler where added. I ignore if richfaces introduce some side effects (and that's the reason why does not work) but maybe this is the case. regards, Leonardo Uribe 2009/12/8 Richard Yee richard.k@gmail.com I'd suggest using facelets instead of Tiles. Tiles was never designed to work with JSF. Facelets provides similar templating capability and was designed to improve on shortcomings of JSP and JSF. Facelets is also part of JSF 2.0 -Richard On Tue, Dec 8, 2009 at 8:24 AM, Michael Heinen michael.hei...@recommind.com wrote: Thanks Richard, I tried this finally with a simple page in this project. TILES is the culprit. My simple page is now rendered with tomahawk tags after I removed context param org.ajax4jsf.VIEW_HANDLERS=org.apache.myfaces.tomahawk.application.jsp.JspTilesViewHandlerImpl from web.xml. The content of f:view is NOT rendered at all as soon as I add the above context param for tiles again. Sample jsp: %@ taglib uri=http://java.sun.com/jsf/html; prefix=h% %@ taglib uri=http://java.sun.com/jsf/core; prefix=f% %@ taglib uri=http://myfaces.apache.org/tomahawk; prefix=t% htmlhead/headbody hello f:viewworldh:outputText value=20/t:outputText value=09///f:view /body/html Output: hello The f:view tag is not processed at all with Tiles. Does anybody know what to do with tiles and JSF 1.2 (myFaces 1.2.8, tomahawk12_1.1.9 and richfaces 3.3.2)? Debugging all the frameworks together is really time consuming Michael -Original Message- From: Richard Yee [mailto:richard.k@gmail.com] Sent: Dienstag, 8. Dezember 2009 16:09 To: MyFaces Discussion Subject: Re: pages not rendered anymore after update from 1.1.6 to 1.2.8 Have you tried just having a page with a JSF outputText tag to see if that works? (No tiles or Richfaces) I would start from there and then add other tags to narrow down where the problem is. -R
RE: update from 1.1.6 to 1.2.8 - IllegalStateException: No Factories configured for this Application
Thanks Jakob.
Now I see following WARN message:
[2009-12-08 09:31:50,287] main [ WARN] [] webapp.AbstractFacesInitializer
initFaces: No mappings of FacesServlet found. Abort initializing MyFaces.
I specified a Wrapper around the FacesServlet for better exception handling.
This worked well with myFaces 1.1.6
servlet
servlet-nameFaces Servlet/servlet-name
servlet-classfoo.servlets.FacesServletWrapper/servlet-class
servlet
servlet-mapping
servlet-nameFaces Servlet/servlet-name
url-pattern/faces/*/url-pattern
/servlet-mapping
public class FacesServletWrapper extends HttpServlet {
private FacesServlet delegate;
…
public void service(ServletRequest request, ServletResponse response) throws
ServletException, IOException {
try {
this.delegate.service(request, response);
}
catch (Throwable throwable) {
…
Isn’t this supported anymore?
How Do I use this pattern with JSF 1.2?
Michael
From: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] On Behalf Of
Jakob Korherr
Sent: Montag, 7. Dezember 2009 18:21
To: Michael Heinen
Cc: MyFaces Discussion
Subject: Re: update from 1.1.6 to 1.2.8 - IllegalStateException: No Factories
configured for this Application
Hi Michael,
Looking at the following lines, the StartupServletContextListener wants to tell
you something, but you are not listening:
log4j:WARN No appenders could be found for logger
(org.apache.myfaces.webapp.StartupServletContextListener).
log4j:WARN Please initialize the log4j system properly.
The factories for MyFaces are configured in the StartupServletContextListener,
so something must went wrong in its contextInitialized() method.
Please configure a logger for StartupServletContextListener and post the output
to the mailing list for more information about the problem!
Regards,
Jakob Korherr
2009/12/7 Michael Heinen
michael.hei...@recommind.commailto:michael.hei...@recommind.com
Hi,
I tried to update my webApp from MyFaces 1.1.6, Tomahawk 1.1.7 and RichFaces
3.1.5 to JSF 1.2 compliant version.
Now the app does not start anymore and I get following exception on startup:
INFO: Starting Servlet Engine: Apache Tomcat/6.0.18
07.12.2009 17:58:49 org.apache.catalina.core.StandardContext
addApplicationListener
INFO: The listener org.apache.myfaces.webapp.StartupServletContextListener is
already configured for this context. The duplicate definition has been ignored.
log4j:WARN No appenders could be found for logger
(org.apache.myfaces.webapp.StartupServletContextListener).
log4j:WARN Please initialize the log4j system properly.
07.12.2009 17:58:50 org.apache.catalina.core.ApplicationContext log
SCHWERWIEGEND: StandardWrapper.Throwable
java.lang.IllegalStateException: No Factories configured for this Application.
This happens if the faces-initialization does not work at all - make sure that
you properly include all configuration settings necessary for a basic faces
application and that all the necessary libs are included. Also check the
logging output of your web application and your container for any exceptions!
If you did that and find nothing, the mistake might be due to the fact that you
use some special web-containers which do not support registering
context-listeners via TLD files and a context listener is not setup in your
web.xml.
A typical config looks like this;
listener
listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class
/listener
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:106)
at javax.faces.webapp.FacesServlet.init(FacesServlet.java:132)
at
com.recommind.litigation.client.web.servlets.FacesServletWrapper.init(FacesServletWrapper.java:73)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1172)
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:992)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4058)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4371)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at
org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at
org.apache.catalina.core.StandardService.start(StandardService.java:516)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:578)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
RE: update from 1.1.6 to 1.2.8 - IllegalStateException: No Factories configured for this Application
Found the solution.
My Wrapper has to implement DelegatedFacesServlet.
-Original Message-
From: Michael Heinen [mailto:michael.hei...@recommind.com]
Sent: Dienstag, 8. Dezember 2009 09:45
To: MyFaces Discussion
Subject: RE: update from 1.1.6 to 1.2.8 - IllegalStateException: No Factories
configured for this Application
Thanks Jakob.
Now I see following WARN message:
[2009-12-08 09:31:50,287] main [ WARN] [] webapp.AbstractFacesInitializer
initFaces: No mappings of FacesServlet found. Abort initializing MyFaces.
I specified a Wrapper around the FacesServlet for better exception handling.
This worked well with myFaces 1.1.6
servlet
servlet-nameFaces Servlet/servlet-name
servlet-classfoo.servlets.FacesServletWrapper/servlet-class
servlet
servlet-mapping
servlet-nameFaces Servlet/servlet-name
url-pattern/faces/*/url-pattern
/servlet-mapping
public class FacesServletWrapper extends HttpServlet {
private FacesServlet delegate;
…
public void service(ServletRequest request, ServletResponse response) throws
ServletException, IOException {
try {
this.delegate.service(request, response);
}
catch (Throwable throwable) {
…
Isn’t this supported anymore?
How Do I use this pattern with JSF 1.2?
Michael
From: sethfromaust...@gmail.com [mailto:sethfromaust...@gmail.com] On Behalf Of
Jakob Korherr
Sent: Montag, 7. Dezember 2009 18:21
To: Michael Heinen
Cc: MyFaces Discussion
Subject: Re: update from 1.1.6 to 1.2.8 - IllegalStateException: No Factories
configured for this Application
Hi Michael,
Looking at the following lines, the StartupServletContextListener wants to tell
you something, but you are not listening:
log4j:WARN No appenders could be found for logger
(org.apache.myfaces.webapp.StartupServletContextListener).
log4j:WARN Please initialize the log4j system properly.
The factories for MyFaces are configured in the StartupServletContextListener,
so something must went wrong in its contextInitialized() method.
Please configure a logger for StartupServletContextListener and post the output
to the mailing list for more information about the problem!
Regards,
Jakob Korherr
2009/12/7 Michael Heinen
michael.hei...@recommind.commailto:michael.hei...@recommind.com
Hi,
I tried to update my webApp from MyFaces 1.1.6, Tomahawk 1.1.7 and RichFaces
3.1.5 to JSF 1.2 compliant version.
Now the app does not start anymore and I get following exception on startup:
INFO: Starting Servlet Engine: Apache Tomcat/6.0.18
07.12.2009 17:58:49 org.apache.catalina.core.StandardContext
addApplicationListener
INFO: The listener org.apache.myfaces.webapp.StartupServletContextListener is
already configured for this context. The duplicate definition has been ignored.
log4j:WARN No appenders could be found for logger
(org.apache.myfaces.webapp.StartupServletContextListener).
log4j:WARN Please initialize the log4j system properly.
07.12.2009 17:58:50 org.apache.catalina.core.ApplicationContext log
SCHWERWIEGEND: StandardWrapper.Throwable
java.lang.IllegalStateException: No Factories configured for this Application.
This happens if the faces-initialization does not work at all - make sure that
you properly include all configuration settings necessary for a basic faces
application and that all the necessary libs are included. Also check the
logging output of your web application and your container for any exceptions!
If you did that and find nothing, the mistake might be due to the fact that you
use some special web-containers which do not support registering
context-listeners via TLD files and a context listener is not setup in your
web.xml.
A typical config looks like this;
listener
listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class
/listener
at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:106)
at javax.faces.webapp.FacesServlet.init(FacesServlet.java:132)
at
com.recommind.litigation.client.web.servlets.FacesServletWrapper.init(FacesServletWrapper.java:73)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1172)
at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:992)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4058)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4371)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at
org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at
org.apache.catalina.core.StandardService.start(StandardService.java:516)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:710
pages not rendered anymore after update from 1.1.6 to 1.2.8
Hi, I tried to update my webApp from myfaces 1.1.6, tomahawk 1.1.7 and richfaces 3.1.5 to JSF 1.2 After some problems the webapp finally started but no page is rendered anymore. Instead of the pages I get only empty screens without any content at all! I am still using Tiles1 (from struts1.1jar) in combination with jsps and not Facelets. What I did: 1) Updated myFaces jars from 1.1.6 to 1.2.8 (api and impl) 2) updated tomahawk 1.1.7 to tomahawk12-1.1.9 3) removed tomhahawk sandbox 1.1.7 4) updated richfaces from 3.1.5 to 3.3.2 (api,impl and ui) 5) updated jstl-1.1.0.jar to jstl-1.2.jar and removed standard.jar 6) deleted work folder of the webApp 7) updated faces-config.xml: set version attribute of faces-config tag to version=1.2 8) updated web.xml: set version attribute of web-app tag version=2.5 I attached the initialization log and the request log with debugging output. Initialization looks good from my point of view. One suspicious line in the request.log: [2009-12-08 14:45:17,492] http-8080-1 [ WARN] [D57992BA5C47A836C0EBE03C0224EB3B] webapp.BaseFilter checkMyFacesExtensionsFilter: MyFaces Extensions Filter should be configured to execute *AFTER* RichFaces filter. Refer to SRV.6.2.4 section of Servlets specification on how to achieve that. The order of the filters in web.xml is not changed and Faces Extensions Filter IS AFTER richfaces filter filter-mapping filter-namerichfaces/filter-name servlet-nameFaces Servlet/servlet-name dispatcherREQUEST/dispatcher dispatcherFORWARD/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping filter-mapping filter-nameMyFacesExtensionsFilter/filter-name url-pattern*.faces/url-pattern /filter-mapping filter-mapping filter-nameMyFacesExtensionsFilter/filter-name url-pattern/faces/*/url-pattern /filter-mapping I don't know whether the problem is caused, by MyFaces, Richfaces, Tomhawk Tiles or whatever at the moment. Any idea where to look at? Michael
RE: pages not rendered anymore after update from 1.1.6 to 1.2.8
The order seems to be correct to me: filter display-nameRichFaces Filter/display-name filter-namerichfaces/filter-name filter-classorg.ajax4jsf.Filter/filter-class /filter ... filter filter-nameMyFacesExtensionsFilter/filter-name filter-classorg.apache.myfaces.webapp.filter.ExtensionsFilter/filter-class init-param param-namemaxFileSize/param-name param-value20m/param-value /init-param /filter ... filter-mapping filter-namerichfaces/filter-name servlet-nameFaces Servlet/servlet-name dispatcherREQUEST/dispatcher dispatcherFORWARD/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping ... filter-mapping filter-nameMyFacesExtensionsFilter/filter-name url-pattern*.faces/url-pattern /filter-mapping filter-mapping filter-nameMyFacesExtensionsFilter/filter-name url-pattern/faces/*/url-pattern /filter-mapping Michael -Original Message- From: Richard Yee [mailto:richard.k@gmail.com] Sent: Dienstag, 8. Dezember 2009 15:38 To: MyFaces Discussion Subject: Re: pages not rendered anymore after update from 1.1.6 to 1.2.8 WARN] [D57992BA5C47A836C0EBE03C0224EB3B] webapp.BaseFilter checkMyFacesExtensionsFilter: MyFaces Extensions Filter should be configured to execute *AFTER* RichFaces filter. Refer to SRV.6.2.4 section of Servlets specification on how to achieve that. Sent from my iPhone On Dec 8, 2009, at 6:22 AM, Michael Heinen michael.hei...@recommind.com wrote: The attachments didn't work. Here is the content: Initialization: [2009-12-08 14:44:01,308] main [ INFO] [] webapp.StartupServletContextListener dispatchInitializationEvent: Checking for plugins:org.apache.myfaces.FACES_INIT_PLUGINS ... [2009-12-08 14:44:01,730] main [DEBUG] [] webxml.WebXmlParser readWebApp: Ignored node '#text' of type 3 [2009-12-08 14:44:01,761] main [ INFO] [] config.MyfacesConfig getBooleanInitParameter: No context init parameter 'org.apache.myfaces.RENDER_CLEAR_JAVASCRIPT_FOR_BUTTON' found, using default value false [2009-12-08 14:44:01,761] main [ INFO] [] config.MyfacesConfig getBooleanInitParameter: No context init parameter 'org.apache.myfaces.SAVE_FORM_SUBMIT_LINK_IE' found, using default value false [2009-12-08 14:44:01,761] main [ INFO] [] config.MyfacesConfig getBooleanInitParameter: No context init parameter 'org.apache.myfaces.READONLY_AS_DISABLED_FOR_SELECTS' found, using default value true [2009-12-08 14:44:01,761] main [ INFO] [] config.MyfacesConfig getBooleanInitParameter: No context init parameter 'org.apache.myfaces.RENDER_VIEWSTATE_ID' found, using default value true [2009-12-08 14:44:01,761] main [ INFO] [] config.MyfacesConfig getBooleanInitParameter: No context init parameter 'org.apache.myfaces.STRICT_XHTML_LINKS' found, using default value true [2009-12-08 14:44:01,761] main [ INFO] [] config.MyfacesConfig getLongInitParameter: No context init parameter 'org.apache.myfaces.CONFIG_REFRESH_PERIOD' found, using default value 2 [2009-12-08 14:44:01,761] main [ INFO] [] config.MyfacesConfig getBooleanInitParameter: No context init parameter 'org.apache.myfaces.VIEWSTATE_JAVASCRIPT' found, using default value false [2009-12-08 14:44:01,761] main [ INFO] [] config.MyfacesConfig getStringInitParameter: No context init parameter 'org.apache.myfaces.RESOURCE_VIRTUAL_PATH' found, using default value /faces/myFacesExtensionResource [2009-12-08 14:44:01,761] main [ INFO] [] config.MyfacesConfig createAndInitializeMyFacesConfig: Starting up Tomahawk on the MyFaces-JSF-Implementation [2009-12-08 14:44:01,917] main [ INFO] [] config.FacesConfigurator feedStandardConfig: Reading standard config META-INF/standard-faces- config.xml [2009-12-08 14:44:02,152] main [ INFO] [] config.FacesConfigurator feedClassloaderConfigurations: Reading config : jar:file:/C:/ workspace/LitigationWebClient/WebRoot/WEB-INF/lib/richfaces- impl-3.3.2.SR1.jar!/META-INF/faces-config.xml [2009-12-08 14:44:02,152] main [ INFO] [] config.FacesConfigurator feedClassloaderConfigurations: Reading config : jar:file:/C:/ workspace/LitigationWebClient/WebRoot/WEB-INF/lib/richfaces- ui-3.3.2.SR1.jar!/META-INF/faces-config.xml [2009-12-08 14:44:02,183] main [ INFO] [] config.FacesConfigurator feedClassloaderConfigurations: Reading config : jar:file:/C:/ workspace/LitigationWebClient/WebRoot/WEB-INF/lib/ tomahawk12-1.1.9.jar!/META-INF/faces-config.xml [2009-12-08 14:44:02,199] main [ INFO] [] config.FacesConfigurator feedWebAppConfig: Reading config /WEB-INF/faces-config.xml [2009-12-08 14:44:02,261] main [ INFO] [] config.FacesConfigurator startLib: Starting up MyFaces-package : myfaces-api in version : 1.2.8 from path : file:/C:/workspace/LitigationWebClient/WebRoot/WEB- INF/lib/myfaces-api-1.2.8.jar [2009-12-08 14:44:02,261] main [ INFO] [] config.FacesConfigurator startLib: Starting up MyFaces-package : myfaces-impl in version : 1.2.8 from path : file:/C:/workspace
RE: pages not rendered anymore after update from 1.1.6 to 1.2.8
Thanks Richard, I tried this finally with a simple page in this project. TILES is the culprit. My simple page is now rendered with tomahawk tags after I removed context param org.ajax4jsf.VIEW_HANDLERS=org.apache.myfaces.tomahawk.application.jsp.JspTilesViewHandlerImpl from web.xml. The content of f:view is NOT rendered at all as soon as I add the above context param for tiles again. Sample jsp: %@ taglib uri=http://java.sun.com/jsf/html; prefix=h% %@ taglib uri=http://java.sun.com/jsf/core; prefix=f% %@ taglib uri=http://myfaces.apache.org/tomahawk; prefix=t% htmlhead/headbody hello f:viewworldh:outputText value=20/t:outputText value=09///f:view /body/html Output: hello The f:view tag is not processed at all with Tiles. Does anybody know what to do with tiles and JSF 1.2 (myFaces 1.2.8, tomahawk12_1.1.9 and richfaces 3.3.2)? Debugging all the frameworks together is really time consuming Michael -Original Message- From: Richard Yee [mailto:richard.k@gmail.com] Sent: Dienstag, 8. Dezember 2009 16:09 To: MyFaces Discussion Subject: Re: pages not rendered anymore after update from 1.1.6 to 1.2.8 Have you tried just having a page with a JSF outputText tag to see if that works? (No tiles or Richfaces) I would start from there and then add other tags to narrow down where the problem is. -R
RE: pages not rendered anymore after update from 1.1.6 to 1.2.8
Little progress: 1) I have to use org.apache.myfaces.tomahawk.application.jsp.JspTilesTwoViewHandlerImpl instead of org.apache.myfaces.tomahawk.application.jsp.JspTilesViewHandlerImpl 2) I have to use version 2.0.5! Tiles 1 is not working with JspTilesTwoViewHandlerImpl and newer versions are also not working according to http://issues.apache.org/jira/browse/TOMAHAWK-74 Now I get a 404 for all pages accessed via tiles. This update is really no joy ... Michael -Original Message- From: Michael Heinen [mailto:michael.hei...@recommind.com] Sent: Dienstag, 8. Dezember 2009 17:24 To: MyFaces Discussion Subject: RE: pages not rendered anymore after update from 1.1.6 to 1.2.8 Thanks Richard, I tried this finally with a simple page in this project. TILES is the culprit. My simple page is now rendered with tomahawk tags after I removed context param org.ajax4jsf.VIEW_HANDLERS=org.apache.myfaces.tomahawk.application.jsp.JspTilesViewHandlerImpl from web.xml. The content of f:view is NOT rendered at all as soon as I add the above context param for tiles again. Sample jsp: %@ taglib uri=http://java.sun.com/jsf/html; prefix=h% %@ taglib uri=http://java.sun.com/jsf/core; prefix=f% %@ taglib uri=http://myfaces.apache.org/tomahawk; prefix=t% htmlhead/headbody hello f:viewworldh:outputText value=20/t:outputText value=09///f:view /body/html Output: hello The f:view tag is not processed at all with Tiles. Does anybody know what to do with tiles and JSF 1.2 (myFaces 1.2.8, tomahawk12_1.1.9 and richfaces 3.3.2)? Debugging all the frameworks together is really time consuming Michael -Original Message- From: Richard Yee [mailto:richard.k@gmail.com] Sent: Dienstag, 8. Dezember 2009 16:09 To: MyFaces Discussion Subject: Re: pages not rendered anymore after update from 1.1.6 to 1.2.8 Have you tried just having a page with a JSF outputText tag to see if that works? (No tiles or Richfaces) I would start from there and then add other tags to narrow down where the problem is. -R
update from 1.1.6 to 1.2.8 - IllegalStateException: No Factories configured for this Application
Hi, I tried to update my webApp from MyFaces 1.1.6, Tomahawk 1.1.7 and RichFaces 3.1.5 to JSF 1.2 compliant version. Now the app does not start anymore and I get following exception on startup: INFO: Starting Servlet Engine: Apache Tomcat/6.0.18 07.12.2009 17:58:49 org.apache.catalina.core.StandardContext addApplicationListener INFO: The listener org.apache.myfaces.webapp.StartupServletContextListener is already configured for this context. The duplicate definition has been ignored. log4j:WARN No appenders could be found for logger (org.apache.myfaces.webapp.StartupServletContextListener). log4j:WARN Please initialize the log4j system properly. 07.12.2009 17:58:50 org.apache.catalina.core.ApplicationContext log SCHWERWIEGEND: StandardWrapper.Throwable java.lang.IllegalStateException: No Factories configured for this Application. This happens if the faces-initialization does not work at all - make sure that you properly include all configuration settings necessary for a basic faces application and that all the necessary libs are included. Also check the logging output of your web application and your container for any exceptions! If you did that and find nothing, the mistake might be due to the fact that you use some special web-containers which do not support registering context-listeners via TLD files and a context listener is not setup in your web.xml. A typical config looks like this; listener listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class /listener at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:106) at javax.faces.webapp.FacesServlet.init(FacesServlet.java:132) at com.recommind.litigation.client.web.servlets.FacesServletWrapper.init(FacesServletWrapper.java:73) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1172) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:992) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4058) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4371) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardHost.start(StandardHost.java:719) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:578) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) 07.12.2009 17:58:50 org.apache.catalina.core.StandardContext loadOnStartup SCHWERWIEGEND: Servlet /foo threw load() exception What I did: 1) Updated myFaces jars from 1.1.6 to 1.2.8 (api and impl) 2) updated tomahawk 1.1.7 to tomahawk12-1.1.9 3) removed tomahawk sandbox 1.1.7 4) updated richfaces from 3.1.5 to 3.3.2 (api, impl and ui) 5) updated jstl-1.1.0.jar to jstl-1.2.jar and removed standard.jar 6) deleted work folder of the webApp I did not change web.xml or faces-config. Tomcat version is 6.0.18. Any ideas where to look now? Michael
RE: how to detect if a request is a ajax submit or normal submit?
With jsf 1.1 you can do it this way:
/**
* Check whether this request is an AJAX Request
* @return true if it is an AJAX Request; false otherwise
*/
protected boolean isAjaxRequest()
{
ServletRequest request = (ServletRequest)
FacesContext.getCurrentInstance().getExternalContext().getRequest();
try
{
return null !=
request.getParameter(org.ajax4jsf.renderkit.AjaxContainerRenderer.AJAX_PARAMETER_NAME);
}
catch (Exception e)
{
// OCJ 10 - throw exception for static resources.
return false;
}
}
-Original Message-
From: news [mailto:n...@ger.gmane.org] On Behalf Of Werner Punz
Sent: Mittwoch, 26. August 2009 10:27
To: users@myfaces.apache.org
Subject: Re: how to detect if a request is a ajax submit or normal submit?
Werner Punz schrieb:
Dave schrieb:
We use jsf ri, tomahawk and ajax4jsf.
For a request, on server side how to detect whether the request is a
ajax submit or normal submit? Is there a HTTP header for this? Thanks
In pre jsf 2.0 this is framework dependend, usually a request param is sent
which marks the request as ajax request so that JSF can take over and do
things differently for ajax.
A unified marker for all this as well as some apis to check whether you
are in an ajax cycle or not will be present in JSF 2.0 for now you have
to check the framework documentation or the request itself which request
parameter for the respective framework marks the request as an ajax one.
(This is easy to do with the network monitor of firebug)
Forgot to say in your case the a4j parameter is the one you have to look
for. A4j does the heavy lifting for you.
Werner
RE: Expression Language question
Try #{useGun useRifle}
-Original Message-
From: mitroiasi [mailto:mitroi...@yahoo.com]
Sent: Freitag, 17. Juli 2009 16:22
To: users@myfaces.apache.org
Subject: Expression Language question
Hi,
I have a problem concerning the EL syntax. I want that a componennt to be
rendered when 2 boolean properties are true, but I cannot accomplish this.
The following code is:
h:panelGroup rendered=#{useGun == true useRifle == true}
--
View this message in context:
http://www.nabble.com/Expression-Language-question-tp24535406p24535406.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
RE: Message bundle problem
You can use a Lazy map as Wrapper to build the keys dynamically.
A Transformer will be called during map access and you can add your prefix to
your key.
This does also work inside tables, lists etc
Sample:
import java.io.Serializable;
import java.util.HashMap;
import java.util.Map;
import org.apache.commons.collections.Transformer;
import org.apache.commons.collections.map.LazyMap;
public class MessageKeyCreatorBean implements Serializable
{
private Map mLazyMap;
public MessageKeyCreatorBean(){}
public void setTransformer (Object input)
{
String inputString = (String) input;
Transformer keyTransformer = new KeyTransformer(inputString);
this.mLazyMap = LazyMap.decorate(new HashMap(), keyTransformer);
}
public Map getLazyKey()
{
return this.mLazyMap;
}
public Object get(Object key)
{
return this.mLazyMap.get(key);
}
private static class KeyTransformer implements Transformer, Serializable
{
private String mPrefix = null;
public KeyTransformer(String prefix )
{
this.mPrefix = prefix;
}
public Object transform(Object input)
{
return this.mPrefix+input.toString();
}
}
}
Config:
managed-bean
managed-bean-namemyPrefixBean/managed-bean-name
managed-bean-classMessageKeyCreatorBean/managed-bean-class
managed-bean-scopeapplication/managed-bean-scope
managed-property
property-nametransformer/property-name
valuelinked/value
/managed-property
/managed-bean
View:
myPrefixBean.lazyKey[bean.type]
Michael
From: matt.rossner-pr...@sanofi-aventis.com
[mailto:matt.rossner-pr...@sanofi-aventis.com]
Sent: Freitag, 6. März 2009 11:31
To: users@myfaces.apache.org
Subject: Message bundle problem
Hi,
I need to access a message bundle property like so:
t:outputText value=#{msg['linked.' + bean.type]} /
Although that syntax doesn't quite work. I've tried a few things. The closest I
got was using a t:aliasBean like
t:aliasBean alias=#{key} value=linked.#{bean.type} /
t:outputText value=#{msg[key]} /
This actually works, but problems arise when you stick that into a t:dataList.
Inside the datalist the t:aliasBean doesn't get reevaluated and instead the
property resolver will try and resolve #{msg[linked.#{bean.type}]} which
doesn't work.
I had a temporary fix which changed the value stored in the bean to include the
linked. part but that causes problems later with the application logic.
Thanks for any help
Matt
RE: Data table is taking long time to render
What about profiling or at least adding some log statements to see exactly where the time is spent? If it is in JSF rendering: I do not render any (ajax) command links in datatables or lists anymore. Instead of this I place one commandlink for each action before the table which is called via javascript. This can reduce the size of the generated html, render time and network traffic significantly. Just check the rendered html to see whether this is an option for you. Michael From: Shasi Mitra Yarram [mailto:shasimi...@yahoo.com] Sent: Donnerstag, 29. Januar 2009 08:49 To: MyFaces Discussion Subject: Re: Data table is taking long time to render Hi David- We use ibatis,it takes connections from pool only and we have simple select queries. It returns 5000 records out of which we filter(filtering part is taken care by business classes) and show atmost 60 records on the page.Each record is a commandLink. And i am using t:dataTable with preserveDataModel=true. Even if i remove this attribute i don see much difference. I can see that there's a siginificant decrease in the response time if i use struts. But as jsf is giving more components and also faster to develop we don want to lose the opportunity of using it in our application. But if the performance is not upto the mark, clients insist us to use Struts or Spring web mvc. Also we have very less time to decide on which framework to use :-( We even followed all the performance improvement measures given in myfaces wiki..Any suggestions to my problem? Concurrent users may be atmost 1000. --- On Thu, 29/1/09, David Griffiths david_griffi...@shaw.ca wrote: From: David Griffiths david_griffi...@shaw.ca Subject: Re: Data table is taking long time to render To: MyFaces Discussion users@myfaces.apache.org Date: Thursday, 29 January, 2009, 5:43 AM Actually, he just said a million users - nothing about concurrent. Is this wired up to a database? Is a database connection being opened for each user, or is it a connection pool? What does the query look like? How many rows on average are you asking the data table to render? I guess I am asking if you are 100% sure it's JSF, or if maybe it's got to do with some other aspect of the application. There are parts of an application when, for performance reasons, you have to leave the high-level tools (JSF, Hibernate, Spring) and code lower to the silicon. Every Hibernate application I've worked on has had SQL over a plain JDBC connection for performance reasons. David Richard Yee wrote: What kind of server and how many are you running on? How many CPUs and how much memory? How are you testing it? You might have to tune your database and # of database connections. A million concurrent users is pretty unrealistic. -R On Wed, Jan 28, 2009 at 12:02 PM, Shasi Mitra Yarram shasimi...@yahoo.com wrote: Hi all, we are designing an application which will have atleast 1 million users. As part of POC we have developed a module with JSF and Spring. Now when we run it with 30 -40 users the page with datatable is taking 5 secs to render. But if we increase the number of users say 100 its taking more than 30 seconds. As we have not yet started coding we need to decide whether to go with JSF or use struts..Any help is greatly appreciated..I heard and can see too that performance of JSF is pretty slow although the development time is fast.. Add more friends to your messenger and enjoy! Invite them now. Add more friends to your messenger and enjoy! Invite them now. http://in.rd.yahoo.com/tagline_messenger_6/*http:/messenger.yahoo.com/invite/
[tomahawk] single checkboxes are rendered inside label tags
I recently updated tomhawk 1.1.5 to 1.1.7 and noticed that single checkboxes are rendered inside an additional label tag. The html output is now: LABEL INPUT id=... type=checkbox /foo /LABEL Why is this additional label tag rendered in 1.1.7? Is there any benefit? It is in class org.apache.myfaces.renderkit.html.extHtmlCheckboxRenderer in method renderSingleCheckbox ... writer.startElement(HTML.LABEL_ELEM, uiSelectMany); renderCheckbox(...); writer.endElement(HTML.LABEL_ELEM); ... Michael
RE: [tomahawk] single checkboxes are rendered inside label tags
-Original Message- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Dienstag, 4. November 2008 13:06 To: MyFaces Discussion Subject: Re: [tomahawk] single checkboxes are rendered inside label tags Michael Heinen schrieb: I recently updated tomhawk 1.1.5 to 1.1.7 and noticed that single checkboxes are rendered inside an additional label tag. The html output is now: LABEL INPUT id=... type=checkbox /foo /LABEL Why is this additional label tag rendered in 1.1.7? Is there any benefit? I believe this is equivalent to: label for=id1foo/label input id=id1 type=checkbox but cleaner (a parent/child relation seems more appropriate here than the for approach). If I remember correctly, having the text for the checkbout output as a label (in either form) means that clicking on the label changes the checkbox state too. Writing the checkbox text (foo in this case) as just plain text does not have that effect. I don't know of any other reason. Is there a problem? Regards, Simon -- -- Emails in mixed posting style will be ignored -- (http://en.wikipedia.org/wiki/Posting_style) No there is no problem. Just a few javascript methods for DOM manipulation failed due to the new nesting. I just was curious about it because there wasn't any label tag rendered in 1.1.5 Thanks, Michael
RE: Date output depending on the userlocale?
Yes, you can simply specify the various date formats in resource bundles
and use the pattern in converters:
Sample:
h:outputText id=aDate value=#{MyBean.mydate}
x:convertDateTime pattern=#{msgs['dateFormat]}/
/h:outputText
messages.en
dateFormat = DD/MM/
messages.de
dateFormat = DD-MM-
Michael
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Donnerstag, 30. Oktober 2008 12:44
To: users@myfaces.apache.org
Subject: Date output depending on the userlocale?
Hi *,
is it possible to configure the date format which is used for the output
of Date-objects for every locale - for example in the locale resource
bundle or in the faces-config.xml?
Example:
Locale en_US DD/MM/
Locale de_DE DD-MM-
Locale en_EN DD-MM.
Thanks and best regards,
Felix Becker
RE: Handling View expired Exception?
You could use a Servlet Filter and check whether the session is still valid. If not create a new one and redirect to login page Michael From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 22. Oktober 2008 15:09 To: users@myfaces.apache.org Subject: Handling View expired Exception? Hi *, when my session on a jsf page times out, i'm getting a view expired exception after executing an action on the page. How can I redirect the user to the login page - with a new session - when this exception was thrown? Thank you and best regards, Felix Becker
RE: [ANNOUNCE] Release of Tomahawk 1.1.7
Good news! Could someone please update the compatibility matrix? Does the new tomahawk release still work with myFaces 1.1.5? Michael From: Leonardo Uribe [mailto:[EMAIL PROTECTED] Sent: Sonntag, 14. September 2008 05:31 To: MyFaces Development; MyFaces Discussion Subject: [ANNOUNCE] Release of Tomahawk 1.1.7 The Apache MyFaces team is pleased to announce the release of Apache MyFaces Tomahawk 1.1.7. MyFaces Tomahawk provides a series of JavaServer Faces components that go beyond the JSF specification. These components are compatible with the Sun JSF 1.1 Reference Implementation (RI) or any other JSF 1.1 compatible implementation. Of course the custom components can also be used with the Apache JSF implementation MyFaces Core 1.1.6. There are also artifacts (tomahawk12) with enhanced compatibility with JSF 1.2 MyFaces Tomahawk 1.1.7 is available in both binary and source distributions. * http://myfaces.apache.org/download.html MyFaces Tomahawk is also available in the central Maven repository under Group ID org.apache.myfaces.tomahawk. Release notes: Bug * [TOMAHAWK-6] - MyFaces FileUpload Issues * [TOMAHAWK-63] - having two or more x:inputFileUpload in the same form results in the h:commandButton's action never being executed. * [TOMAHAWK-64] - Allow t:htmlTag to support an attributes string. * [TOMAHAWK-79] - Add facelets support for all Tomahawk components * [TOMAHAWK-117] - dataScroller bug when using ADF - navigation icons not clickable * [TOMAHAWK-406] - t:collapsiblePanel does not allow valueChangeListener * [TOMAHAWK-477] - newspaperTable: newspaperColumns does not works with value bindings * [TOMAHAWK-520] - TabbedPane Component creates two tags with the same id * [TOMAHAWK-523] - rowStyleClass does not resolve to an EL of var * [TOMAHAWK-530] - imageLocation of inputCalendar does not work * [TOMAHAWK-542] - forceId does not work on dataTable * [TOMAHAWK-689] - Style attributes do not apply to popup * [TOMAHAWK-698] - PPRPanelGroup Post-Information is submitted twice when using PPR * [TOMAHAWK-717] - Tabbed Pane: dataModel inside tabs is not updated when switching between tabs and coming back * [TOMAHAWK-726] - popup calendar position wrong when in relative container * [TOMAHAWK-728] - newspaperColumns attribute ignores EL expression * [TOMAHAWK-735] - ForceId does not work in inputCalendar anymore * [TOMAHAWK-750] - Raized ClassCastException when Comparing 2 InputDate with validateCompareTo * [TOMAHAWK-777] - DataScroller breaks facets functionality when using trinidad default renderkit * [TOMAHAWK-784] - user specified onclick contents not rendered in panel tabs * [TOMAHAWK-802] - HtmlInputDate does not have methods to set onchange, onblur and other such attributes * [TOMAHAWK-872] - t:collapsiblePanel fails to toggle * [TOMAHAWK-888] - NPE when using AjaxAnywhere * [TOMAHAWK-907] - Incorrect behaviour of HtmlInputText with ajax * [TOMAHAWK-914] - t:dataTable style attributes don't work with Facelets * [TOMAHAWK-917] - t:columns example is wrong * [TOMAHAWK-942] - Renderer set in extended html component jsp tag handler rather than in component class * [TOMAHAWK-953] - Panel Stack example fails with Message: There is more than one JSF tag with id : treePanel for parent component with id : 'stack' * [TOMAHAWK-955] - Tomahawk CORE components + tags errors (missing attributes, missing EL-support, missing saving/restoring) * [TOMAHAWK-962] - disabled commandLink render id attribute twice * [TOMAHAWK-964] - Seconds are random when input via t:inputDate ... type=short_time * [TOMAHAWK-966] - PPR examples containing commandLinks produce javascript errors in clientSide validation * [TOMAHAWK-968] - Interaction with inputCalendar component causes proliferation of commandLinks if running under ICEFaces. * [TOMAHAWK-969] - Partial Refresh does not work if triggerButton comes after the last PPRPanelGroup * [TOMAHAWK-971] - Schedule throws a java.lang.IllegalStateException if more than one post back is made consecitively when using the jsf 1.1 ri * [TOMAHAWK-974] - pprPanelGroup does not work inside dataTable * [TOMAHAWK-975] - t:schedule HeaderDateFormat locale problems * [TOMAHAWK-979] - ExcelExport - correct name for the downloaded file * [TOMAHAWK-982] - SelectOneRow missing disabled and readonly attributes as described in TLD (patch provided) * [TOMAHAWK-986] - The SharedRenderer fails to get the Default Locale when a headerDateFormat is specified * [TOMAHAWK-990] - sandbox modalDialog component doesn't hide underlying comboboxes on IE when viewId specified * [TOMAHAWK-996] - /schedule.HtmlSchedule/javascript/domLib.js causes flicker for :hover css in IE 7 * [TOMAHAWK-1009] - DataScoller - FastForward has borderline issues * [TOMAHAWK-1016] - ParameterResourceProvider do not encode the value *
RE: statesaving - memory consumption
I extended the JspStateManagerImpl also for this reason (and for some simple multi window support). I removed the Map with the old views stored as weak references because they are not useful at all in my App. Benefit is that GC is more performant and that possible errors (View could not be restored) are exactly reproducible and do not depend on memory consumption. Michael -Original Message- From: Daniel Niklas [mailto:[EMAIL PROTECTED] Sent: Dienstag, 2. September 2008 14:33 To: users@myfaces.apache.org Subject: Re: statesaving - memory consumption Hi Simon, Simon Kitching wrote: The idea is that by setting NUMBER_OF_VIEWS_IN_SESSION, a webapp can guarantee to support a certain number of back-button clicks - at the JSF level at least. Or that when two windows are open on the same webapp, that the user can perform NUMBER_OF_VIEWS_IN_SESSION clicks in one window before the other window starts to misbehave. Ok, our application doesn't need something like that, because we have session beans... Simon Kitching wrote: The weak map stuff then tries to make life nice for the user; when there is memory to spare then it tries to keep as many old views as possible, so that even more than NUMBER_OF_VIEWS_IN_SESSION clicks will work. But when memory is low, only NUMBER_OF_VIEWS_IN_SESSION clicks are guaranteed to work. It might be a problem, that many of these objects are created and the memory increases very fast. That means much effort for garbage collection! And most people (?!) doesn't need this mechanism at all. Simon Kitching wrote: The original code used the default constructor for ReferenceMap, which uses strong refs to keys but weak refs to values. The key object here is not large; it is the value (which is the whole UIViewRoot) that is held weakly. However nothing *ever* clears the keys for this map. Yes, 1.1.5 uses the default constructor for ReferenceMap. But this was not the problem! Entries of ReferenceMap will be removed when the garbage collection runs (and there is no other hard reference to the value), even if the corresponding key is hardly referenced! No memory leak here. Simon Kitching wrote: I agree with your second posting, a weak references isn't a good choice here, soft references would be better, but no idea what was going wrong with 1.1.5. I'll check this. Thanks for your answers Daniel -- View this message in context: http://www.nabble.com/statesaving---memory-consumption-tp19256471p192693 23.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
RE: myfaces with richfaces
Yes JSF 1.1: richfaces 3.1.X, myfaces 1.1.X - Tomcat 5.5 JSF 1.2: richfaces 3.2.X, myfaces 1.2.X - Tomcat 6 -Original Message- From: Hardik Shah [mailto:[EMAIL PROTECTED] Sent: Donnerstag, 7. August 2008 11:20 To: users@myfaces.apache.org Subject: Re: myfaces with richfaces so i have to use richfaces 3.1.6 tomcat 5.5 bcoz it supports myface 1.1 ,is it right? -- View this message in context: http://www.nabble.com/myfaces-with-richfaces-tp18866542p18866826.html Sent from the MyFaces - Users mailing list archive at Nabble.com.
JavaDoc links broken
The Javadoc links on http://myfaces.apache.org/javadoc.html are broken http://myfaces.apache.org/api/apidocs/index.html and http://myfaces.apache.org/impl/apidocs/index.html cannot be found. Michael
unbdeploy WepApp - struts.jar locked
Hi all, I have a problem with undeploying my JSF WebApp which is (most likely) not MyFaces specific. My App runs under Tomcat 5.5.26 using Tiles for templating and therefore struts.jar is under webInf\lib. The file struts.jar is always locked after undeploying the WepApp via Tomcat manager app. All other jars can be deleted but this one not. I don't want to use the antiJARLocking attribute for the context. Any ideas ? Michael
RE: unbdeploy WepApp - struts.jar locked
After spending many hours with this I found a solution that I do not understand. I removed following doctype definition from tiles-defs.xml !DOCTYPE tiles-definitions PUBLIC -//Apache Software Foundation//DTD Tiles Configuration 1.1//EN http://jakarta.apache.org/struts/dtds/tiles-config_1_1.dtd; Why does this result in locking struts.jar ? I tried also to use a local dtd without success. Michael From: Michael Heinen [mailto:[EMAIL PROTECTED] Sent: Dienstag, 15. Juli 2008 14:20 To: MyFaces Discussion Subject: unbdeploy WepApp - struts.jar locked Hi all, I have a problem with undeploying my JSF WebApp which is (most likely) not MyFaces specific. My App runs under Tomcat 5.5.26 using Tiles for templating and therefore struts.jar is under webInf\lib. The file struts.jar is always locked after undeploying the WepApp via Tomcat manager app. All other jars can be deleted but this one not. I don't want to use the antiJARLocking attribute for the context. Any ideas ? Michael
RE: unbdeploy WepApp - struts.jar locked
Thanks Simon. I read s.th. similar also but this is still really strange to me ... I could understand this if a DTD is referenced *inside* struts.jar. But http://jakarta.apache.org/struts/dtds/tiles-config_1_1.dtd; is a public dtd somewhere outside. How can caching this file result in locking struts.jar? Or do you think that some struts/tiles code holds a reference to the DTD also? I removed also all dtds from struts.jar without success. Michael -Original Message- From: simon [mailto:[EMAIL PROTECTED] Sent: Dienstag, 15. Juli 2008 17:59 To: MyFaces Discussion Subject: RE: unbdeploy WepApp - struts.jar locked On Tue, 2008-07-15 at 09:37 -0600, Michael Heinen wrote: After spending many hours with this I found a solution that I do not understand. I removed following doctype definition from tiles-defs.xml !DOCTYPE tiles-definitions PUBLIC -//Apache Software Foundation//DTD Tiles Configuration 1.1//EN http://jakarta.apache.org/struts/dtds/tiles-config_1_1.dtd; Why does this result in locking struts.jar ? This does make sense. The usual cause of this locking problem is some stupid code inside the sun jdk. When URL.openAsStream (or some such method, I forget the exact details) is used to load a resource, then the sun jdk caches a reference to that resource in order to optimise future accesses to it. But that means that on Windows the file is open so cannot be removed. The fix really should be in the jdk, but it isn't going to happen. Instead, the workaround is for all libraries to go around explicitly disabling caching wherever this is used. And I would guess that *if* an xml file has a local dtd declared then something is loading that via the above method, in order to validate the dtd or to detect implicit attributes etc. I think there is an issue in the JIRA somewhere to fix the problem in myfaces code. But of course it needs to be fixed in every lib too. Or move to a decent operating system :-). Please note: above details are only from memory. Exact classes, methods, etc can be wrong. Regards, Simon
RE: access names of called actions and beans
Hi Rafa, how does this global ActionListener work? I defined one in the faces-config and it's processAction method is called. But the action/actionListener of my commands are not executed anymore! Michael -Original Message- From: Rafa Pérez [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 2. Juli 2008 08:29 To: MyFaces Discussion Subject: Re: access names of called actions and beans You can declare your own global ActionListener in faces-config.xml. Every time an action/actionListener is executed, this class will be called. On Tue, Jul 1, 2008 at 9:46 PM, Richard Yee [EMAIL PROTECTED] wrote: If you are using Spring, you can also easily do it with AOP. -Richard On Tue, Jul 1, 2008 at 12:23 PM, Stephen Friedrich [EMAIL PROTECTED] wrote: I think it's not really feasible with a servlet only, but an interceptor can easily do it. See the posts in this thread for a working example: http://seamframework.org/Community/SeamPerformanceProblemRewardingWorkaround There's a little bit more configuration to do when you are not using Seam, but not too complicated either way. Michael Heinen wrote: What's the best approach to output the name of the called action/actionListener and the name of the corresponding managed beans ? I want to use a ServletFilter to measure the times for http requests and print out these names. Is there anything generic available via FacesContext? I do not want to touch every managed bean. Or do I have to overwrite org.apache.myfaces.el.MethodBindingImpl in order to store the names in requestscope in the invoke method? Michael
RE: date conversion in tooltip ?
Thanks Volker.
That's exactly the way I did it also yesterday.
This is very often the last chance for some shortcomings in EL or JSF.
Michael
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Volker Weber
Sent: Dienstag, 1. Juli 2008 17:27
To: MyFaces Discussion
Subject: Re: date conversion in tooltip ?
Hi Michael,
2008/6/30 Michael Heinen [EMAIL PROTECTED]:
I have to format a date inside a tooltip (or title attribute).
Is there any way to apply a converter for a tooltip ?
afaik no.
Or is it possible to call a converter via EL ?
afaik no.
I fear that converters are always used with the value attribute of the outer
tag.
Any ideas ?
just one:
You can do many things using a managedBean implementing a java.util.Map.
class MyDateConverter extends AbstractMap {
private SimpleDateFormat format = new SimpleDateFormat(dd.MM. hh:mm);
public Object get(Object key) {
if (key instanceof Date) {
return format.format((Date)key);
}
return null;
}
public Set entrySet() {}
}
tip=The date is #{myDateConverter[userBean.date]}
Michael
Regards,
Volker
--
inexso - information exchange solutions GmbH
Bismarckstraße 13 | 26122 Oldenburg
Tel.: +49 441 4082 356 |
FAX: +49 441 4082 355 | www.inexso.de
access names of called actions and beans
What's the best approach to output the name of the called action/actionListener and the name of the corresponding managed beans ? I want to use a ServletFilter to measure the times for http requests and print out these names. Is there anything generic available via FacesContext? I do not want to touch every managed bean. Or do I have to overwrite org.apache.myfaces.el.MethodBindingImpl in order to store the names in requestscope in the invoke method? Michael
date conversion in tooltip ?
I have to format a date inside a tooltip (or title attribute). Is there any way to apply a converter for a tooltip ? Or is it possible to call a converter via EL ? I fear that converters are always used with the value attribute of the outer tag. Any ideas ? Michael
RE: Leak in saveState?
I had to remove the sequence id in my custom JspStateManager.
The app did not work anymore with parallel ajax requests after removing the map
with the old views (weakReferences)
Shouldn't this be officially supported in myFaces?
e.g. if back button is not supported (numberOfViewsInSession=1) then another
JspStateManager without sequence ids should be used.
From my point of view the Map containing the old views as weakReferences should
also be removed because it results in really unpredictable behavior under load
and it costs performance.
Michael
-Original Message-
From: Michael Heinen [mailto:[EMAIL PROTECTED]
Sent: Dienstag, 22. April 2008 11:11
To: MyFaces Discussion
Subject: RE: Leak in saveState?
Hi,
I removed also the map containing the old views as weak references.
It does not make any sense in my use case because my app does not support the
browser back button.
Moreover I think that this map with the weak references results in
unpredictable behavior under load.
I am facing now a new problem without this old views caused by the sequence id
in the SerializedViewKey.
If I define numberOfViewsInSession=1 and a page is submitted multiple times
with ajax then let's say request1 and reqest2 are submitted with sequenceId=1.
This sequenceId is increased during processing of request1 from 1 to 2.
The view of request2 can't be restored anymore because it is fired with
sequenceId1 but the session counter is at 2!
Therefore my question:
Can I remove the sequenceId from SerializedViewKey if I do not support browser
back button?
From my point of view the weakMap and the sequenceId should not be used in case
of numberOfViewsInSession=1
Michael
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Montag, 21. April 2008 16:37
To: MyFaces Discussion
Subject: Re: Leak in saveState?
wbirkhead schrieb:
Gerald Müllan-3 wrote:
I can see that in some cases it may help, perhaps you wanna share the
impl ?
I just removed the two lines with the weak references. So, only ugly
duplication of code. :)
Gerald, at the risk of sounding like a novice, can you point me to the lines
of code with the weak references that you mention above? This would be a
HUGE help.
JspStateManagerImpl has this method:
public synchronized void add(FacesContext context, Object state)
{
Object key = new SerializedViewKey(context);
_serializedViews.put(key, state);
while (_keys.remove(key));
_keys.add(key);
int views = getNumberOfViewsInSession(context);
while (_keys.size() views)
{
key = _keys.remove(0);
Object oldView = _serializedViews.remove(key);
if (oldView != null)
{
getOldSerializedViewsMap().put(key, oldView);
}
}
}
The second while loop is trimming the strong-referenced pool down to
the necessary size, and adding the removed entries into the weak pool.
So just commenting out the call to
getOldSerializedViewsMap().put(key, oldView);
should do the trick.
Regards,
Simon
