[jira] [Commented] (MYFACES-3311) Can't resolve converter for cc attributes
[
https://issues.apache.org/jira/browse/MYFACES-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13109240#comment-13109240
]
Martin Marinschek commented on MYFACES-3311:
Hi Michi,
I'll say what I know about this topic:
- we can not use java.lang.Long (or any specific type) as the type for a value
expression, as the EL will try to coerce null to 0 then (that's a very strange
part of the Unified EL spec)
- however, we can of course get the value and see what the type is. Of course,
this will not work when the value is null.
- Best would probably be to go over some means independent of the EL to
determine the type, but I don't know if the API enables us to do this
I wonder if the third suggestion is used when you are outside of a composite
comp, but not used when you are inside?
best regards,
Martin
Can't resolve converter for cc attributes
-
Key: MYFACES-3311
URL: https://issues.apache.org/jira/browse/MYFACES-3311
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.1.3
Reporter: Michael Kurz
Attachments: MYFACES-3311-testapp.zip
I have some serious problems with composite component attributes. I have a
composite component with the attribute value. This attribute
(#{cc.attrs.value}) is mapped to the value attribute of an internal
h:inputText. When I pass a VE to the composite component, the value is not
converted in the h:inputText.
The problem is caused in _SharedRendererUtils.findUIOutputConverter(). In
this method the converter is resolved based on the type returned by a call to
getType() on the VE. Unfortunately, for the VE in the composite component
(#{cc.attrs.value}) this resolves to java.lang.Object (and not to
java.lang.Long in my case).
I quickly tried to replace the call to VE.getType() with a call to
getValue().getClass(). This works, but I guess this introduces additional
constraints I'm currently not aware of. Any ideas? Wasn't something like this
already discussed in the past?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3199) Handling AbortProcessingException is unconsistent
[
https://issues.apache.org/jira/browse/MYFACES-3199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13058538#comment-13058538
]
Martin Marinschek commented on MYFACES-3199:
Hi Martin,
I totally agree with your point about listener isolation, however I see things
a little differently (highlighting with _ added):
1) execute one listener in try catch block and catch (Exception e)
2) if
2a) exception is instance of APE _or any of the causes of the exception are an
APE, don't_ publish ExceptionQueuedEvent and terminate processing for current
event _(is this as such in the spec that an APE has to be queued?)_
2b) for any other exception publish ExceptionQueuedEvent and continue broadcast
processing
3) handle queued exception in exception handler
3a) default exception handler : ignore AbortProcessingException
3b) custom exception handler: can handle all unexpected exception (for example
remove them from queue)
4) all unhandled exception are rethrow and error page is displayed
Handling AbortProcessingException is unconsistent
-
Key: MYFACES-3199
URL: https://issues.apache.org/jira/browse/MYFACES-3199
Project: MyFaces Core
Issue Type: Sub-task
Components: General
Environment: myface core trunk
Reporter: Martin Kočí
UIViewRoot:
try {
source.broadcast(event);
}
catch (AbortProcessingException e)
{
ExceptionQueuedEventContext exceptionContext
= new ExceptionQueuedEventContext(context, e, source,
context.getCurrentPhaseId());
context.getApplication().publishEvent(context,
ExceptionQueuedEvent.class, exceptionContext);
// Abortion
return false;
}
Problem 1:
h:inputText valueChangeListener=#{bean.processValueChange}
MethodExpressionValueChangeListener wraps all exceptions to
AbortProcessingException and therefore exception is queued
Problem 2:
h:inputText
f:valueChangeListener binding=#{bean} /
/h:inputText
ValueChangeListenerHandler does not wrap exception to
AbortProcessingException and therefore exception is not queued in this block
(but it is queued from phase executor but without component info)
Problem 3: JSF spec 2.1 :
Clarification made: throwing an AbortProcessingException tells an
implementation that no further broadcast of the
current event occurs. Does not affect future events.
But I think that code in UIViewRoot makes opposite: // Abortion return
false;
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MYFACES-3012) Allow f:param for h:inputText f:ajax
[ https://issues.apache.org/jira/browse/MYFACES-3012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12983626#action_12983626 ] Martin Marinschek commented on MYFACES-3012: I would like this feature, but it is not foreseen by the spec so far. best regards, Martin Allow f:param for h:inputText f:ajax Key: MYFACES-3012 URL: https://issues.apache.org/jira/browse/MYFACES-3012 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.4-SNAPSHOT Environment: myfaces trunk, shared svn. rev 1051469 Reporter: Martin Kočí Priority: Minor Attachments: MYFACES-3012.patch I don't know what spec says but following should work: h:inputText f:param name=paramName value=paramValue / f:ajax / /h:inputText expected result is paramName = paramValue pair in request. For h:command it works already. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2968) ApplicationImpl.createMethodBinding should create expression with signature: void method(params)
[ https://issues.apache.org/jira/browse/MYFACES-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12933765#action_12933765 ] Martin Marinschek commented on MYFACES-2968: Hi guys, just my additional 2 cents: the EL implementations behave differently with return values. E.g.: JUEL won't find an action method which has a void return value - the reference EL implementation will find it! best regards, Martin ApplicationImpl.createMethodBinding should create expression with signature: void method(params) Key: MYFACES-2968 URL: https://issues.apache.org/jira/browse/MYFACES-2968 Project: MyFaces Core Issue Type: Bug Reporter: Martin Kočí Attachments: MYFACES-2968.patch This is probably not specified but mojarra does it: Application.createMethodBinding creates method expression with void return type. That makes sence because original purpose of MethodBinding is a reference to faces listeners and they are without return values mostly. o.a.m.ApplicationImpl creates value expression to method with Object return type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2895) Messages component cannot be updated by ajax without wrapping it
[
https://issues.apache.org/jira/browse/MYFACES-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12903799#action_12903799
]
Martin Marinschek commented on MYFACES-2895:
Spec bug or not, we should try to fix it in the implementation.
best regards,
Martin
Messages component cannot be updated by ajax without wrapping it
Key: MYFACES-2895
URL: https://issues.apache.org/jira/browse/MYFACES-2895
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.2-SNAPSHOT
Reporter: Nick Belaevski
When there are no faces messages generated, h:messages component does not
render no HTML tags, so it cannot be updated by ajax.
To reproduce:
h:messages id=messages /
h:commandButton value=Invoke listener by
type action=#{bean.generateMessage}
f:ajax render=messages /
/h:commandButton
No messages will appear. As a workaround messages component can be wrapped
into h:panelGroup that's id will be specified in 'render':
h:panelGroup id=messages
h:messages /
/h:panelGroup
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2861) Remove commons-discovery dependency
[ https://issues.apache.org/jira/browse/MYFACES-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896778#action_12896778 ] Martin Marinschek commented on MYFACES-2861: Hi Leonardo, are you aware that you can exclude transitive dependencies in Maven? see here: http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html best regards, Martin Remove commons-discovery dependency --- Key: MYFACES-2861 URL: https://issues.apache.org/jira/browse/MYFACES-2861 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.1 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.2-SNAPSHOT Commons-discovery has a dependency to commons-logging. That cause a transitive dependency to myfaces-impl. To prevent this dependency, we need to move that code into our codebase and refactor it so it uses jul instead. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2744) UIData.getClientId() should not append rowIndex, instead use UIData.getContainerClientId()
[
https://issues.apache.org/jira/browse/MYFACES-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12888559#action_12888559
]
Martin Marinschek commented on MYFACES-2744:
I don´t want this to be reverted. This is an issue - and even if we slightly
deviate from the spec language (which is wrong in this case), the fix is
entirely correct and it will not cause compatibility issues with Mojarra.
best regards,
Martin
UIData.getClientId() should not append rowIndex, instead use
UIData.getContainerClientId()
--
Key: MYFACES-2744
URL: https://issues.apache.org/jira/browse/MYFACES-2744
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0
Reporter: Leonardo Uribe
Assignee: Jakob Korherr
Fix For: 2.0.1-SNAPSHOT
from: [jsr-314-open] Ajax inside a DataTable
Cagatay Civici
I've faced with an issue in our app I'd like to share when trying to update
the datatable itself from a command element located inside a column. Case is
to select a row, execute logic and update the datatable. Basic code:
h:dataTable id=cars var=car value=#{tableBean.carsSmall}
h:column
f:facet name=header
Model
/f:facet
h:outputText value=#{car.model} /
/h:column
h:column
f:facet name=header
Action
/f:facet
h:commandButton value=Some Action
actionListener=#{tableBean.handleRowAction(car)}
f:ajax render=cars /
/h:commandButton
/h:column
/h:dataTable
As datatable has a rowIndex = 0 during rendering of commandButton f:ajax
defines the component id to render as cars:{rowIndex} where I should expect
cars only. This is due to UIData.getClientId implementation as UIData
adds rowIndex for unique row ids. This causes an issue with a nested f:ajax
case.
Martin Marinschek
We should never include the row-index in the client-id of the table
itself. For this, we need to revise the client-id generation
algorithm.
Without actually having tried it, I think that it is easy to do so, as
we have a UIComponentBase.getContainerClientId() to create the
client-id of the children - when this method is called, we append the
row-index, if getClientId() itself is called, we don´t.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2753) Trivial multi-level templating does not work if ui:include is used
[ https://issues.apache.org/jira/browse/MYFACES-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12888162#action_12888162 ] Martin Marinschek commented on MYFACES-2753: I´d like to link this to: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1684 I don´t have the time to look into this more right now, but maybe you guys can start off a good discussion with Max and Andy - nobody seems to be absolutely clear about this API, so it is worthwhile spending some time on this. If you get a good understanding, why don't you document it so that everybody will be able to get it... best regards, Martin Trivial multi-level templating does not work if ui:include is used -- Key: MYFACES-2753 URL: https://issues.apache.org/jira/browse/MYFACES-2753 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.2-SNAPSHOT Environment: myfaces core trunk (2.0.2-SNAPSHOT), tomcat 6.0.26 Reporter: Martin Kočí Assignee: Jakob Korherr Attachments: MYFACES-2753-tests.patch, MYFACES-2753.patch, MYFACES-2753.tar.gz Following example does not produce any output: OuterClient.xhtml ui:decorate template=/templates/OuterTemplate.xhtml xmlns:ui=http://java.sun.com/jsf/facelets; ui:define name=content ui:include src=InnerClient.xhtml / /ui:define /ui:decorate OuterTemplate.xhtml: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN http://www.w3.org/TR/html4/loose.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:f=http://java.sun.com/jsf/core; xmlns:h=http://java.sun.com/jsf/html; f:view h:head titletitle/title /h:head h:body ui:insert name=content / /h:body /f:view /html InnerClient.xhtml: ui:composition template=/templates/InnerTemplate.xhtml xmlns=http://www.w3.org/1999/xhtml; xmlns:ui=http://java.sun.com/jsf/facelets; ui:define name=content Do you see me? /ui:define /ui:composition InnerTemplate.xhtml: f:subview xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:f=http://java.sun.com/jsf/core; ui:insert name=content / /f:subview But if OutterClient.xhtml looks like: ui:decorate template=/templates/OuterTemplate.xhtml xmlns:ui=http://java.sun.com/jsf/facelets; ui:define name=content ui:composition template=/templates/InnerTemplate.xhtml ui:define name=content Do you see me? /ui:define /ui:composition /ui:define /ui:decorate it outputs Do you see me? which is expected result in both cases. I think first case should work too - or am I missing something? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2780) MyFaces performance improvements for production
[ https://issues.apache.org/jira/browse/MYFACES-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12888165#action_12888165 ] Martin Marinschek commented on MYFACES-2780: Hi Mike, thanks for the parameter! Do you (anyways) have an idea of how much the lazy loading influences the request processing of the first request? How much are the typical memory savings for a large component library? Just so that our users have something to chew on ;) best regards, Martin MyFaces performance improvements for production Key: MYFACES-2780 URL: https://issues.apache.org/jira/browse/MYFACES-2780 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 2.0.0 Reporter: Michael Concini Assignee: Michael Concini Priority: Minor Fix For: 2.0.1 Several fixes to enhance startup memory footprint and runtime performance taking advantage of ProjectStage. -lazy loading of validators, converters, behaviors,components - can have a substantial impact on startup footprint in applications with multiple or very large widget libraries. Turn off some updating of resources for ProjectStage=Production by default (can always override using javax.faces.FACELETS_REFRESH_PERIOD) -change default facelets refresh interval to -1 when projectStage is production. This by itself gains a 60% improvement in throughput. -disable reloading of web.xml and faces-config after the first load. -store a map to cache Class to listenerFor and resourceDependency annotations when in production. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2792) Redirect with include-view-params in faces-config.xml
[
https://issues.apache.org/jira/browse/MYFACES-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12886700#action_12886700
]
Martin Marinschek commented on MYFACES-2792:
;) s*** happens!
all the best,
Martin
Redirect with include-view-params in faces-config.xml
-
Key: MYFACES-2792
URL: https://issues.apache.org/jira/browse/MYFACES-2792
Project: MyFaces Core
Issue Type: Bug
Reporter: Gurkan Erdogdu
Assignee: Jakob Korherr
Fix For: 2.0.1-SNAPSHOT
I have a bean
@ManagedBean(name=blog)
@SessionScoped
public class Blog {
private String content;
private static AtomicInteger id = new AtomicInteger(0);
private String idm;
public String addBlog(){
this.idm = Integer.toString(id.incrementAndGet());
return view?faces-redirect=trueamp;includeViewParams=true;
}
}
This is result view
h:body
f:view
f:metadata
f:viewParam name=id
value=#{blog.idm}/f:viewParam
/f:metadata
/f:view
h:outputText value=#{blog.content}/h:outputText
/h:body
This works! Changed to following and adding faces-config.xml
public String addBlog(){
this.idm = Integer.toString(id.incrementAndGet());
return ok;
}
navigation-rule
navigation-case
from-action#{blog.addBlog}/from-action
from-outcomeok/from-outcome
to-view-id/view.xhtml/to-view-id
redirect include-view-params=true/
/navigation-case
/navigation-rule
Not working!
What can be the problem? (I think doing some wrong actions!)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2780) MyFaces performance improvements for production
[ https://issues.apache.org/jira/browse/MYFACES-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12885915#action_12885915 ] Martin Marinschek commented on MYFACES-2780: Well, I am ok with lazy loading if it does not change the request times, also not the ones for the first request. How much loading do you defer - is it changing the time needed for processing a request? In any case, I guess this should be configurable. best regards, Martin MyFaces performance improvements for production Key: MYFACES-2780 URL: https://issues.apache.org/jira/browse/MYFACES-2780 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 2.0.0 Reporter: Michael Concini Assignee: Michael Concini Priority: Minor Fix For: 2.0.1 Several fixes to enhance startup memory footprint and runtime performance taking advantage of ProjectStage. -lazy loading of validators, converters, behaviors,components - can have a substantial impact on startup footprint in applications with multiple or very large widget libraries. Turn off some updating of resources for ProjectStage=Production by default (can always override using javax.faces.FACELETS_REFRESH_PERIOD) -change default facelets refresh interval to -1 when projectStage is production. This by itself gains a 60% improvement in throughput. -disable reloading of web.xml and faces-config after the first load. -store a map to cache Class to listenerFor and resourceDependency annotations when in production. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2780) MyFaces performance improvements for production
[ https://issues.apache.org/jira/browse/MYFACES-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12885474#action_12885474 ] Martin Marinschek commented on MYFACES-2780: Hi guys, how is lazy loading good for production performance? In production, I would expect everything to be initialized on startup - so that request times are as low as possible (and certainly not the first request is taking longer than all other requests). Startup is not so much an issue in production! That's why everyone precompiles JSPs in production. best regards, Martin MyFaces performance improvements for production Key: MYFACES-2780 URL: https://issues.apache.org/jira/browse/MYFACES-2780 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 2.0.0 Reporter: Michael Concini Assignee: Michael Concini Priority: Minor Fix For: 2.0.1 Several fixes to enhance startup memory footprint and runtime performance taking advantage of ProjectStage. -lazy loading of validators, converters, behaviors,components - can have a substantial impact on startup footprint in applications with multiple or very large widget libraries. Turn off some updating of resources for ProjectStage=Production by default (can always override using javax.faces.FACELETS_REFRESH_PERIOD) -change default facelets refresh interval to -1 when projectStage is production. This by itself gains a 60% improvement in throughput. -disable reloading of web.xml and faces-config after the first load. -store a map to cache Class to listenerFor and resourceDependency annotations when in production. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2730) FacesContext not available on application startup
[ https://issues.apache.org/jira/browse/MYFACES-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12882072#action_12882072 ] Martin Marinschek commented on MYFACES-2730: Hi Leonardo, but this would effectively mean we cannot wrap the faces-context for the startup, instead it is only going to be our instance? best regards, Martin FacesContext not available on application startup - Key: MYFACES-2730 URL: https://issues.apache.org/jira/browse/MYFACES-2730 Project: MyFaces Core Issue Type: Bug Components: JSR-127, JSR-252, JSR-314 Affects Versions: 1.1.8, 1.2.9, 2.0.0 Reporter: Nick Belaevski Assignee: Leonardo Uribe Fix For: 2.0.2-SNAPSHOT Attachments: MYFACES-2730-1.patch, MYFACES-2730-2.patch, MYFACES-2730-3.patch, MYFACES-2730-4.patch, MYFACES-2730-revert.patch If custom ResourceHandler calls FacesContext.getCurrentInstance() in constructor to read init parameters, null value is returned. This affects latest MyFaces 2.0.0-SNAPSHOT. Mojarra 2.0 provides InitFacesContext in this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2730) FacesContext not available on application startup
[ https://issues.apache.org/jira/browse/MYFACES-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12882106#action_12882106 ] Martin Marinschek commented on MYFACES-2730: Hi guys, if Mojarra follows the same pattern (not allows to decorate the FacesContext in the startup process), then I agree to the proposed solution. best regards, Martin FacesContext not available on application startup - Key: MYFACES-2730 URL: https://issues.apache.org/jira/browse/MYFACES-2730 Project: MyFaces Core Issue Type: Bug Components: JSR-127, JSR-252, JSR-314 Affects Versions: 1.1.8, 1.2.9, 2.0.0 Reporter: Nick Belaevski Assignee: Leonardo Uribe Fix For: 2.0.2-SNAPSHOT Attachments: MYFACES-2730-1.patch, MYFACES-2730-2.patch, MYFACES-2730-3.patch, MYFACES-2730-4.patch, MYFACES-2730-revert.patch If custom ResourceHandler calls FacesContext.getCurrentInstance() in constructor to read init parameters, null value is returned. This affects latest MyFaces 2.0.0-SNAPSHOT. Mojarra 2.0 provides InitFacesContext in this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2730) FacesContext not available on application startup
[ https://issues.apache.org/jira/browse/MYFACES-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12881629#action_12881629 ] Martin Marinschek commented on MYFACES-2730: Hi guys, if there is backwards compatibility issues - e.g. an existing version of Orchestra which runs on MyFaces 1.2 does not run on MyFaces 2.0 due to throwing an exception, or any libraries which don't deploy but would be deploying if we don't throw exceptions, I change my position. I also think that resolving EL expressions should also be possible on startup (just not in request and session scoped beans). However, I thought the FacesContext was not available on startup so far, so why do existing libraries rely on this behaviour? If this is necessary - I am in favor to log an error instead. best regards, Martin FacesContext not available on application startup - Key: MYFACES-2730 URL: https://issues.apache.org/jira/browse/MYFACES-2730 Project: MyFaces Core Issue Type: Bug Components: JSR-127, JSR-252, JSR-314 Affects Versions: 1.1.8, 1.2.9, 2.0.0 Reporter: Nick Belaevski Assignee: Leonardo Uribe Fix For: 2.0.2-SNAPSHOT Attachments: MYFACES-2730-1.patch, MYFACES-2730-2.patch, MYFACES-2730-3.patch, MYFACES-2730-revert.patch If custom ResourceHandler calls FacesContext.getCurrentInstance() in constructor to read init parameters, null value is returned. This affects latest MyFaces 2.0.0-SNAPSHOT. Mojarra 2.0 provides InitFacesContext in this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2758) DebugPhaseListener tries to get value from unrendered component where value is unavailable
[
https://issues.apache.org/jira/browse/MYFACES-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12881697#action_12881697
]
Martin Marinschek commented on MYFACES-2758:
Hi Jakob,
we need to make sure for each and every value resolution in the debug phase
listener that we catch all exceptions and just ignore them - we don't care
about performance here, we just want to make sure that we don't mess up a page
with the debug information.
best regards,
Martin
DebugPhaseListener tries to get value from unrendered component where value
is unavailable
--
Key: MYFACES-2758
URL: https://issues.apache.org/jira/browse/MYFACES-2758
Project: MyFaces Core
Issue Type: Bug
Components: Extension Feature
Affects Versions: 2.0.2-SNAPSHOT
Environment: myfaces core trunk
Reporter: Martin Kočí
Assignee: Jakob Korherr
Fix For: 2.0.2-SNAPSHOT
When in Develepment stage DebugPhaseListener collects useful information
about component tree. But there is a problem with construction like this
(example is from a real application based on ADF API) :
h:dataTable
value=#{queryModel.currentDescriptor.conjunctionCriterion.criterionList}
var=node
h:column
h:selectOneMenu rendered=#{node.attributeCriterion and
node.removable} value=#{node.operator}
f:selectItems value=#{node.operators} /
/h:selectOneMenu
/h:column
/h:dataTable
please note that selectOneMenu is rendered only if node is AttributeCriterion
because only AttributeCriterion class has property operator. But
DebugPhaseListener tries to get value for every row in DataTable even it is
not rendered - it leads in this case to exception:
javax.el.PropertyNotFoundException: The class
'com.companyConjunctionCriterion' does not have the property 'operator'
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2730) FacesContext not available on application startup
[ https://issues.apache.org/jira/browse/MYFACES-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12881218#action_12881218 ] Martin Marinschek commented on MYFACES-2730: Hi Leo, Jakob, I want exceptions on methods which make no sense - much clearer to the user. Deleting files in svn is totally ok as well. Implementing this in 1.2 and 1.1 does not help. best regards, Martin FacesContext not available on application startup - Key: MYFACES-2730 URL: https://issues.apache.org/jira/browse/MYFACES-2730 Project: MyFaces Core Issue Type: Bug Components: JSR-127, JSR-252, JSR-314 Affects Versions: 1.1.8, 1.2.9, 2.0.0 Reporter: Nick Belaevski Assignee: Leonardo Uribe Fix For: 2.0.2-SNAPSHOT Attachments: MYFACES-2730-1.patch, MYFACES-2730-2.patch, MYFACES-2730-revert.patch If custom ResourceHandler calls FacesContext.getCurrentInstance() in constructor to read init parameters, null value is returned. This affects latest MyFaces 2.0.0-SNAPSHOT. Mojarra 2.0 provides InitFacesContext in this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (MYFACES-2730) FacesContext not available on application startup
[ https://issues.apache.org/jira/browse/MYFACES-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12881218#action_12881218 ] Martin Marinschek edited comment on MYFACES-2730 at 6/22/10 10:53 AM: -- Hi Leo, Jakob, I want exceptions on methods which make no sense - much clearer to the user. Deleting files in svn is totally ok as well - you can always restore them at any point of time. Implementing this in 1.2 and 1.1 does not help, it would be wasting your precious time. best regards, Martin was (Author: mmarinschek): Hi Leo, Jakob, I want exceptions on methods which make no sense - much clearer to the user. Deleting files in svn is totally ok as well. Implementing this in 1.2 and 1.1 does not help. best regards, Martin FacesContext not available on application startup - Key: MYFACES-2730 URL: https://issues.apache.org/jira/browse/MYFACES-2730 Project: MyFaces Core Issue Type: Bug Components: JSR-127, JSR-252, JSR-314 Affects Versions: 1.1.8, 1.2.9, 2.0.0 Reporter: Nick Belaevski Assignee: Leonardo Uribe Fix For: 2.0.2-SNAPSHOT Attachments: MYFACES-2730-1.patch, MYFACES-2730-2.patch, MYFACES-2730-revert.patch If custom ResourceHandler calls FacesContext.getCurrentInstance() in constructor to read init parameters, null value is returned. This affects latest MyFaces 2.0.0-SNAPSHOT. Mojarra 2.0 provides InitFacesContext in this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2739) Pass through String values in EnumConverter.getAsString()
[
https://issues.apache.org/jira/browse/MYFACES-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12873926#action_12873926
]
Martin Marinschek commented on MYFACES-2739:
Hi Gentlemen,
I don't think it is a good idea to wait for 2.1. As slow as things currently
run inside the big companies involved, we should rather have a
context-parameter strict-compatibility mode and we should try to fix such
issues (which are really issues hindering people using JSF properly) if this is
not set to true.
best regards,
Martin
Pass through String values in EnumConverter.getAsString()
-
Key: MYFACES-2739
URL: https://issues.apache.org/jira/browse/MYFACES-2739
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-314
Affects Versions: 2.0.0
Reporter: Jakob Korherr
Assignee: Jakob Korherr
Attachments: MYFACES-2739.patch
From the related spec issue (#817 -
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=817):
In every standard by-type converter in the JSF spec, except for the
EnumConverter, the following code is present in getAsString():
if (value instanceof String)
{
return (String) value;
}
Thus allowing String values to be used directly as the String representation
of
the type. This allows e.g. the following scenario for an Integer property in
the
managed bean to work, although 1234 beeing a String and not an Integer:
h:selectOneRadio value=#{myBean.inputInt}
f:selectItem itemValue=1234 /
/h:selectOneRadio
However the spec javadoc of the EnumConverter does not include this scenario
and
thus EnumConverter.getAsString() throws a ConverterException when providing a
String value. This means that the following scenario won't work, although it
should on my opinion (note that this currently does work with Mojarra because
of
an implementation issue - see [1] for details):
h:selectOneRadio value=#{myBean.inputEnum}
f:selectItem itemValue=EnumConstant1 /
/h:selectOneRadio
EnumConstant1 beeing a valid constant in the enum type referenced by
#{myBean.inputEnum}. The only way to make this work right now is to use a
ValueExpression that resolves to the needed enum constant, so something like
this:
h:selectOneRadio value=#{myBean.inputEnum}
f:selectItem itemValue=#{myBean.propertyThatResolvesToEnumConstant1} /
/h:selectOneRadio
This is not very straight forward IMHO, thus I think
EnumConverter.getAsString()
should pass through String-values just as every other standard by-type
converter
does.
See also the discussion on the MyFaces user mailing list about this [2].
[1] https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1694
[2] http://www.mail-archive.com/us...@myfaces.apache.org/msg55742.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2737) Cache FacesContext on UIComponentBase instances
[
https://issues.apache.org/jira/browse/MYFACES-2737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12872080#action_12872080
]
Martin Marinschek commented on MYFACES-2737:
Hi Leonardo,
I _definitely_ like this approach - no spec changes necessary. Way cool!
It was that simple, and I just didn't see it ;). Neither did any of the cs-JSF
team and EG members involved - just great.
best regards,
Martin
Cache FacesContext on UIComponentBase instances
---
Key: MYFACES-2737
URL: https://issues.apache.org/jira/browse/MYFACES-2737
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-314
Affects Versions: 2.0.0
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Attachments: MYFACES-2737-1.patch
Right now, the implementation of UIComponentBase.getFacesContext() is this:
@Override
protected FacesContext getFacesContext()
{
return FacesContext.getCurrentInstance();
}
I think it is possible to create a variable like this:
private transient FacesContext _facesContext;
and change the current implementation to:
void setCachedFacesContext(FacesContext facesContext)
{
_facesContext = facesContext;
}
@Override
protected FacesContext getFacesContext()
{
if (_facesContext == null)
{
return FacesContext.getCurrentInstance();
}
else
{
return _facesContext;
}
}
Then we do this on methods like processXXX, encodeXXX (not on encodeAll),
visitTree and invokeOnComponent:
@Override
public void processDecodes(FacesContext context)
{
try
{
setCachedFacesContext(context);
/*.. do what is required */
}
finally
{
popComponentFromEL(context);
setCachedFacesContext(null);
}
In few words, set and release temporally the variable while those operations
are executed. This change will reduce the amount of calls to
FacesContext.getCurrentInstance() without side effects, because we are
caching only on safe places and enclosing everything in a try finally block.
If no objections I'll commit this code soon.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2730) FacesContext not available on application startup
[ https://issues.apache.org/jira/browse/MYFACES-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12870594#action_12870594 ] Martin Marinschek commented on MYFACES-2730: That should - by the way - be part of the Spec. If language to this extent is not included, we should file an issue. best regards, Martin FacesContext not available on application startup - Key: MYFACES-2730 URL: https://issues.apache.org/jira/browse/MYFACES-2730 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0 Reporter: Nick Belaevski If custom ResourceHandler calls FacesContext.getCurrentInstance() in constructor to read init parameters, null value is returned. This affects latest MyFaces 2.0.0-SNAPSHOT. Mojarra 2.0 provides InitFacesContext in this case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1504) Update autoscroll feature to JSF 2
[ https://issues.apache.org/jira/browse/TOMAHAWK-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12868070#action_12868070 ] Martin Marinschek commented on TOMAHAWK-1504: - Hi Leonardo, ok, well - with my comment I meant if it wouldn´t be practical to (instead of having one tag per component) have one component per page which enables this behaviour for all command components? Just like we do it in the view-handler of MyFaces? Does that sound reasonable? best regards, Martin Update autoscroll feature to JSF 2 -- Key: TOMAHAWK-1504 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1504 Project: MyFaces Tomahawk Issue Type: Improvement Components: JSF2 Affects Versions: 1.1.9 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 1.1.10-SNAPSHOT Attachments: TOMAHAWK-1504-1.patch In jsf 1.1. and 1.2, autoscroll behavior had the following problems: - It is myfaces specific feature, because requires add some code on renderers. In ri it will not work - It only works for h:commandXXX and t:commandXXX components, so if you use trinidad (override h:commandXXX renderers) it will not work. - Since it requires render some javascript at the end of body tag, it requires use DefaultAddResource or t:documentBody With jsf 2.0 we have the chance to get rid all this problems and make this feature work with other libraries. First a short review about this feature. To make it work, it requires the following points: - Render an input type=hidden name=autoScroll / that will contain the position on the page (x,y) - Render a function called getScrolling() ant the end of the page that calculate the value and optionally render the command that scroll. - Render the script on each link to call getScrolling() function and assign its value to the hidden field (using oamSetHiddenInput). The idea include add the following code: - Create a new client behavior tag called t:autoscroll that adds the script required on each command component. - Create a new component that just render the hidden field. It will be added as a component resource. - Create a new component that render autoScroll script. It will be added as a component resource. - Add some code on ResourceViewHandler, to add the two previous components to the component tree as transient each time the view is rendered, but only if org.apache.myfaces.AUTO_SCROLL web param is true or t:autoscroll is used on the current page. Now, the proposal will work in following scenarios like this: - org.apache.myfaces.AUTO_SCROLL is enabled, myfaces core is used, so all h:commandXXX and t:commandXXX works like in jsf 1.1 and jsf 1.2. - org.apache.myfaces.AUTO_SCROLL is disabled and myfaces core is used, hidden field and script will be added only if t:autoscroll is used. By default, h:commandXXX and t:commandXXX will not have autoscroll script, so t:autoscroll is required to add this script. - RI (Mojarra) is used, hidden field and script will be added only if t:autoscroll is used. By default, h:commandXXX and t:commandXXX will not have autoscroll script, so t:autoscroll is required to add this script. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2616) Fix UIData state saving model (spec issue 153)
[
https://issues.apache.org/jira/browse/MYFACES-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12867478#action_12867478
]
Martin Marinschek commented on MYFACES-2616:
Hi Leonardo,
while I see that your approach would be good, I see one problem with this - and
that is performance due to the additional tree visit (and the EG has already
said that it is not happy about adding more tree-visits).
Can we find a solution so that your requirements are fulfilled, and no
additional tree-visit is necessary?
best regards,
Martin
Fix UIData state saving model (spec issue 153)
--
Key: MYFACES-2616
URL: https://issues.apache.org/jira/browse/MYFACES-2616
Project: MyFaces Core
Issue Type: Task
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Attachments: fixUIDataPSS-6.patch, fixUIDataPSS-7.patch
In short, this topic is an attempt to add full state to components inside
UIData. I'll do a brief resume, so people can understand this one easily.
UIData uses the same component instances to render multiple rows. Suppose
this example:
h:dataTable id=cities var=city value=#{country.cities}
h:column
h:outputText value=#{city} /
/h:column
/h:dataTable
In the component tree it is created this hierarchy:
HtmlDatatable
UIColumn
HtmlOutputText
If we have 10 cities, the same component is used over and over to render all
10 cities. The reason to do that in this way is keep state as small as
possible.
Now let's suppose something like this:
h:dataTable id=cities var=city value=#{country.cities}
h:column
h:inputText value=#{city} /
/h:column
/h:dataTable
It was changed the output component for an input one. If this table is in a
form and the values are submitted, the same component is used to apply
request values, validate and apply them to the model (update process). To
make this possible, UIData class has some code to preserve this values
between phases (using EditableValueHolder interface), so when each phase is
processed, all rows are traversed and you get the expected behavior.
Now suppose something more complex: We have a code that use invokeOnComponent
to change the style of my inputText. In theory, only one row should change.
But in fact, all rows are rendered with the same color. Why? because we use
the same component to render all rows, and we don't preserve the children
component state between rows.
There is a lot of issues, questions, and side effects related to this issue,
but just to put some of them here:
TOMAHAWK-1062 InputTextArea doesn't work properly inside facet DetailStamp
TOMAHAWK-96 Data table Scroller not working the dataTable which was actually
contained in other DataTable
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=153
Problems with UIData state saving
Also, it is well know that one reason why people uses c:forEach in facelets,
is because this one create full components per each row. It is very easy to
find articles on internet.
Now, with jsf 2.0 we have partial state saving, so we have a chance to fix
this one once and for all. I tried fix this one per months (maybe years!),
but talking with Martin Marinschek on JSFDays, some ideas came out and
finally it was found a possibility to fix this one using the existing api and
with little changes on the spec.
The proposal is this:
1. Do not call UIComponent.markInitialState() on ComponentTagHandlerDelegate,
as ComponentHandler javadoc says, instead call it after PostAddToViewEvent
are published on vdl.buildView(). We need to call it from root to nodes, so
the parent component is marked first. I know the place where this call comes
is from trinidad tag handler, but this call needs to be fixed in a more
predictable way.
2. Use an attribute on facesContext to identify when the VDL is marking the
initial state (in myfaces there is already an attribute called
org.apache.myfaces.MARK_INITIAL_STATE). This is necessary to indicate
UIData instances that it is time to save the full state of all component
children,
3. Allow UIData to hold a map where the key are client ids and the value are
the deltas of all components per row. This map should be saved and restored.
4. Change UIData.setRowIndex() to restore and save the component state.
I'll attach a patch on this issue with the algorithm proposed (because it is
based on myfaces codebase). It was tested and it works. But note it is
necessary to fix the javadoc for UIData.markInitialState(), ComponentHandler
and maybe vdl.buildView(), so the intention is propose this change for jsf
2.0 rev A. Note this works only with PSS enabled because without it
[jira] Commented: (TRINIDAD-1809) CPU impact for repeated calls to isRenderer on UIXComponentBase
[ https://issues.apache.org/jira/browse/TRINIDAD-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12867479#action_12867479 ] Martin Marinschek commented on TRINIDAD-1809: - Hi Stefan, yes, you are right - it would be safe to do this. In cs-JSF we do exactly this - we also cache the rendered attribute from the begin of processDecodes until the end of invoke application. However: if you cache this in a transient attributes, you need to treat stuff in data-tables differently. Transient attributes are not saved/restored per row while a data-table is processed, a long standing issue we have with the spec. best regards, Martin CPU impact for repeated calls to isRenderer on UIXComponentBase --- Key: TRINIDAD-1809 URL: https://issues.apache.org/jira/browse/TRINIDAD-1809 Project: MyFaces Trinidad Issue Type: Bug Components: Components Reporter: Stevan Malesevic While using Trinidad framework we noticed that even with very complex app having complex bus logic we still spend some 2-3% of time doing checks on isRenderer() on UIXComponentBase. In general the problem is that number of these are EL expression on some EL expressions are not very cheap to evaluate. Now, the fact that there are number of duplicate checks makes the cost higher. The big chunk of calls comes from 3 areas 1. encodeBegin, encodeChild and encodeEnd all do the check 2. __encodeRecursive does a check and then invokes methods from 1. 3. CoreRenderer.encodeChild also does a check and then calls group 1. Generally it should be possible to mark renderer as local property at the begging of comp rendering and use it . This should save a 1/3 of cpu cycles -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1504) Update autoscroll feature to JSF 2
[ https://issues.apache.org/jira/browse/TOMAHAWK-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12867481#action_12867481 ] Martin Marinschek commented on TOMAHAWK-1504: - Hi Leonardo, cool stuff - like your suggestion. Question: t:autoScroll is a client-behaviour, and a normal tag, right? So I will just have to add it once to a page if I use Mojarra, right? nice! best regards, Martin Update autoscroll feature to JSF 2 -- Key: TOMAHAWK-1504 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1504 Project: MyFaces Tomahawk Issue Type: Improvement Components: JSF2 Affects Versions: 1.1.9 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Attachments: TOMAHAWK-1504-1.patch In jsf 1.1. and 1.2, autoscroll behavior had the following problems: - It is myfaces specific feature, because requires add some code on renderers. In ri it will not work - It only works for h:commandXXX and t:commandXXX components, so if you use trinidad (override h:commandXXX renderers) it will not work. - Since it requires render some javascript at the end of body tag, it requires use DefaultAddResource or t:documentBody With jsf 2.0 we have the chance to get rid all this problems and make this feature work with other libraries. First a short review about this feature. To make it work, it requires the following points: - Render an input type=hidden name=autoScroll / that will contain the position on the page (x,y) - Render a function called getScrolling() ant the end of the page that calculate the value and optionally render the command that scroll. - Render the script on each link to call getScrolling() function and assign its value to the hidden field (using oamSetHiddenInput). The idea include add the following code: - Create a new client behavior tag called t:autoscroll that adds the script required on each command component. - Create a new component that just render the hidden field. It will be added as a component resource. - Create a new component that render autoScroll script. It will be added as a component resource. - Add some code on ResourceViewHandler, to add the two previous components to the component tree as transient each time the view is rendered, but only if org.apache.myfaces.AUTO_SCROLL web param is true or t:autoscroll is used on the current page. Now, the proposal will work in following scenarios like this: - org.apache.myfaces.AUTO_SCROLL is enabled, myfaces core is used, so all h:commandXXX and t:commandXXX works like in jsf 1.1 and jsf 1.2. - org.apache.myfaces.AUTO_SCROLL is disabled and myfaces core is used, hidden field and script will be added only if t:autoscroll is used. By default, h:commandXXX and t:commandXXX will not have autoscroll script, so t:autoscroll is required to add this script. - RI (Mojarra) is used, hidden field and script will be added only if t:autoscroll is used. By default, h:commandXXX and t:commandXXX will not have autoscroll script, so t:autoscroll is required to add this script. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1425) Support to java.sql.Date using inputCalendar tag.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12866342#action_12866342 ] Martin Marinschek commented on TOMAHAWK-1425: - Hi Leonardo, I have always thought that JSF should add a business-converter for such issues. So we should have a way to convert between the model type that we need for the renderer, and the model-type that the backing-beans use. You could register such a converter on the input-component like the normal converter, businessConverter= We could also cover stuff like the joda-date with this. Eventually, we could even add a central registry for this in MyFaces where you can register business-converters centrally and hence let the renderer automatically retrieve such a a converter for the backing-bean datatype and the datatype it needs. best regards, Martin Support to java.sql.Date using inputCalendar tag. - Key: TOMAHAWK-1425 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1425 Project: MyFaces Tomahawk Issue Type: New Feature Components: Calendar Affects Versions: 1.1.8 Reporter: Paulo Henrique Couto de Lima Assignee: Leonardo Uribe Priority: Minor Fix For: 1.1.10-SNAPSHOT Attachments: HtmlCalendarRenderer.java.patch Original Estimate: 1h Remaining Estimate: 1h Trying to use a java.sql.Date value for inputCalendar results in IllegalArgumentException, thrown by the deprecated method getHour of java.sql.Date. java.util.Date does not throw any exceptions when getHour is invoked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2667) var values cause problems with ui:debug when creating the debug component tree
[
https://issues.apache.org/jira/browse/MYFACES-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12862527#action_12862527
]
Martin Marinschek commented on MYFACES-2667:
Hi Jakob,
yes, the location in the XHTML. Actually, from our discussion on the EG, we
have stated that this location should be part of the information each component
has (it comes from the tag field of a TagHandler in Facelets I think). I hope
this has made it into the spec, if not, you will need to file a spec issue ;)
Emitting this information would be very valuable on the debug page.
best regards,
Martin
var values cause problems with ui:debug when creating the debug component tree
--
Key: MYFACES-2667
URL: https://issues.apache.org/jira/browse/MYFACES-2667
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.1-SNAPSHOT
Reporter: Jakob Korherr
Assignee: Jakob Korherr
Fix For: 2.0.1-SNAPSHOT
When using ui:debug / on a page, it creates a String version of the current
component tree to show it in the debug output window (opens by hitting ctrl +
shift + D in the browser).
While creating this component tree, ui:debug wants to display every property
of every component in the tree using the class' PropertyDescriptors. However
there are some problems with this solution related to components that publish
values in the RequestMap while the real tree is processed (rendered) like
e.g. ui:repeat or h:dataTable (mostly those with a var attribute). Every
child component of such a component, which refers to this value, will cause
EL operations with invalid parameters (null or empty String) when its getters
are called. See the related thread on the mailing list to this problem:
http://www.mail-archive.com/us...@myfaces.apache.org/msg55485.html
In addition, properties with values of Collection, Map or Iterator are not
included in the debug output, only those with real values (like true,
false, 1234) are included. Also I don't think that it makes much sence to
include all real values in the debug component tree, because what should we
display for components that render their children a couple of times like
h:dataTable? ...and depend on values of their parent which are published
somewhere else?
To visualize the problem a bit more, see the following facelet page:
ui:repeat var=master value=#{myBean.masterList}
h:dataTable var=detail value=#{myBean.getDetailList(master)}
h:column
h:outputText value=#{detail} /
/h:column
/h:dataTable
/ui:repeat
The debug output for this one looks something like this:
UIRepeat id=j_id2114509110_7e08d943 inView=true offset=0
rendered=true size=-1 step=1 transient=false var=master
HtmlDataTable border=-2147483648 first=0
id=j_id2114509110_7e08d9b9 inView=true rendered=true rowIndex=-1
rows=0 transient=false var=detail
UIColumn id=j_id2114509110_7e08d99f inView=true
rendered=true transient=false
HtmlOutputText escape=true id=j_id2114509110_7e08d9f5
inView=true rendered=true transient=false/
/UIColumn
/HtmlDataTable
/UIRepeat
I personally think that it would be much better not to evaluate the
ValueExpressions, but to include the properties with the expression String in
the component tree, like you see here:
UIRepeat id=j_id2114509110_7e08d943 inView=true offset=0
rendered=true size=-1 step=1 transient=false
value=#{myBean.masterList} var=master
HtmlDataTable border=-2147483648 first=0
id=j_id2114509110_7e08d9b9 inView=true rendered=true rowIndex=-1
rows=0 transient=false value=#{myBean.getDetailList(master)}
var=detail
UIColumn id=j_id2114509110_7e08d99f inView=true
rendered=true transient=false
HtmlOutputText escape=true id=j_id2114509110_7e08d9f5
inView=true rendered=true transient=false value=#{detail}/
/UIColumn
/HtmlDataTable
/UIRepeat
This will solve the problem the user has experienced and will also create a
much better debug output.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2667) var values cause problems with ui:debug when creating the debug component tree
[
https://issues.apache.org/jira/browse/MYFACES-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12861782#action_12861782
]
Martin Marinschek commented on MYFACES-2667:
Hi Jakob,
sure, that is a good idea!
A feature which I would have wanted for a long time already would be the
ability to concentrate on one component (like click on it on the debug page)
and then being able to see how that component values changed over the
lifecycle. That would help me a lot with debugging in cs-JSF. The location of
the component (coming from the Facelet Tag Handler) is hopefully already
included in the information shown?
best regards,
Martin
var values cause problems with ui:debug when creating the debug component tree
--
Key: MYFACES-2667
URL: https://issues.apache.org/jira/browse/MYFACES-2667
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.1-SNAPSHOT
Reporter: Jakob Korherr
Assignee: Jakob Korherr
Fix For: 2.0.1-SNAPSHOT
When using ui:debug / on a page, it creates a String version of the current
component tree to show it in the debug output window (opens by hitting ctrl +
shift + D in the browser).
While creating this component tree, ui:debug wants to display every property
of every component in the tree using the class' PropertyDescriptors. However
there are some problems with this solution related to components that publish
values in the RequestMap while the real tree is processed (rendered) like
e.g. ui:repeat or h:dataTable (mostly those with a var attribute). Every
child component of such a component, which refers to this value, will cause
EL operations with invalid parameters (null or empty String) when its getters
are called. See the related thread on the mailing list to this problem:
http://www.mail-archive.com/us...@myfaces.apache.org/msg55485.html
In addition, properties with values of Collection, Map or Iterator are not
included in the debug output, only those with real values (like true,
false, 1234) are included. Also I don't think that it makes much sence to
include all real values in the debug component tree, because what should we
display for components that render their children a couple of times like
h:dataTable? ...and depend on values of their parent which are published
somewhere else?
To visualize the problem a bit more, see the following facelet page:
ui:repeat var=master value=#{myBean.masterList}
h:dataTable var=detail value=#{myBean.getDetailList(master)}
h:column
h:outputText value=#{detail} /
/h:column
/h:dataTable
/ui:repeat
The debug output for this one looks something like this:
UIRepeat id=j_id2114509110_7e08d943 inView=true offset=0
rendered=true size=-1 step=1 transient=false var=master
HtmlDataTable border=-2147483648 first=0
id=j_id2114509110_7e08d9b9 inView=true rendered=true rowIndex=-1
rows=0 transient=false var=detail
UIColumn id=j_id2114509110_7e08d99f inView=true
rendered=true transient=false
HtmlOutputText escape=true id=j_id2114509110_7e08d9f5
inView=true rendered=true transient=false/
/UIColumn
/HtmlDataTable
/UIRepeat
I personally think that it would be much better not to evaluate the
ValueExpressions, but to include the properties with the expression String in
the component tree, like you see here:
UIRepeat id=j_id2114509110_7e08d943 inView=true offset=0
rendered=true size=-1 step=1 transient=false
value=#{myBean.masterList} var=master
HtmlDataTable border=-2147483648 first=0
id=j_id2114509110_7e08d9b9 inView=true rendered=true rowIndex=-1
rows=0 transient=false value=#{myBean.getDetailList(master)}
var=detail
UIColumn id=j_id2114509110_7e08d99f inView=true
rendered=true transient=false
HtmlOutputText escape=true id=j_id2114509110_7e08d9f5
inView=true rendered=true transient=false value=#{detail}/
/UIColumn
/HtmlDataTable
/UIRepeat
This will solve the problem the user has experienced and will also create a
much better debug output.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1600) Trinidad2 - Dialog navigation clears View Scope
[ https://issues.apache.org/jira/browse/TRINIDAD-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12862058#action_12862058 ] Martin Marinschek commented on TRINIDAD-1600: - Hi Martin, Max, in cs-JSF, independent of your discussion, we followed the original approach suggested by Max with our dialog handling - I am not entirely sure that the view-map should be cleared when setViewRoot is set. I believe that this is somewhat too much of hidden behaviour for this method. Should we take this up with the EG? best regards, Martin Trinidad2 - Dialog navigation clears View Scope --- Key: TRINIDAD-1600 URL: https://issues.apache.org/jira/browse/TRINIDAD-1600 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 2.0.0-alpha Environment: Trinidad 2.0 branch, JSF RI 2.0.0RC2 Reporter: Martin Koci Assignee: Max Starets Fix For: 2.0.0.3-core Attachments: patch.txt, patch2.txt, patch3.diff JSF 2.0 introduces new scope View Scope implemented with a Map UIViewRoot.viewMap. Spec also says that call FacesConfig.setViewRoot() clears that Map. Problem: Trinidad NavigationHandler uses method handleNavigation for detection if a dialog navigation will be performed - however that method creates new UIViewRoot and sets it to FacesContext - clears view scope. If user places managed bean into view scope and starts a dialog: navigation on that view, bean is removed and new instance of the bean is created after dialog return. Solution: use new JSF 2.0 ConfigurableNavigationHandler API -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2674) ClassNotFoundException when using org.apache.myfaces.annotation.SCAN_PACKAGES parameter with not existing package
[ https://issues.apache.org/jira/browse/MYFACES-2674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12860803#action_12860803 ] Martin Marinschek commented on MYFACES-2674: Hi Matthias, well, the logging/exception should certainly be more strict in development than in production mode (you don´t want an application to fail when you deploy it while it runs during development). The question is if it is desired to have unknown directories here? Shouldn´t the user know that something is amiss? best regards, Martin ClassNotFoundException when using org.apache.myfaces.annotation.SCAN_PACKAGES parameter with not existing package --- Key: MYFACES-2674 URL: https://issues.apache.org/jira/browse/MYFACES-2674 Project: MyFaces Core Issue Type: Bug Reporter: Matthias Weßendorf in web.xml have the following ctx param: context-param param-nameorg.apache.myfaces.annotation.SCAN_PACKAGES/param-name param-valuenet.wessendorf/param-value /context-param but if this package does not exist, you'll notice this: Caused by: java.lang.ClassNotFoundException: No resource for net/wessendorf at org.apache.myfaces.config.annotation._PackageInfo.getClasses(_PackageInfo.java:102) at org.apache.myfaces.config.annotation.AnnotationConfigurator.packageClasses(AnnotationConfigurator.java:332) at org.apache.myfaces.config.annotation.AnnotationConfigurator.configure(AnnotationConfigurator.java:186) ... 17 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2672) Don't create more wrappers for _behaviorsMap than necessary
[ https://issues.apache.org/jira/browse/MYFACES-2672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12860804#action_12860804 ] Martin Marinschek commented on MYFACES-2672: Hi Leonardo, clearly you will need to reset the cached instance when a behaviour is added - but apart from this, the caching is certainly good. best regards, Martin Don't create more wrappers for _behaviorsMap than necessary --- Key: MYFACES-2672 URL: https://issues.apache.org/jira/browse/MYFACES-2672 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.1-SNAPSHOT Actually we have a code on UIComponentBase.wrapBehaviorsMap() that each time it is called it returns a Collections.unmodifiableMap(_behaviorsMap). I think we can use a transient variable here to hold the resulting instance, and each time it is called return it. Collections.unmodifiableMap is just a wrapper of the real one, so we can cache it safely here. UIComponentBase.getClientBehaviors could be called many times for the same component when it is rendered. I think it is worth to do it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2667) var values cause problems with ui:debug when creating the debug component tree
[
https://issues.apache.org/jira/browse/MYFACES-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12860815#action_12860815
]
Martin Marinschek commented on MYFACES-2667:
Hi Jakob,
now that we have the tree-visiting in place, we can do both:
- first write out the component-tree master, with only expressions in place
- second we write out the tree how it is really evaluated by the components,
with the real component values
the more debugging information, the better!
best regards,
Martin
var values cause problems with ui:debug when creating the debug component tree
--
Key: MYFACES-2667
URL: https://issues.apache.org/jira/browse/MYFACES-2667
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.1-SNAPSHOT
Reporter: Jakob Korherr
Assignee: Jakob Korherr
Fix For: 2.0.1-SNAPSHOT
When using ui:debug / on a page, it creates a String version of the current
component tree to show it in the debug output window (opens by hitting ctrl +
shift + D in the browser).
While creating this component tree, ui:debug wants to display every property
of every component in the tree using the class' PropertyDescriptors. However
there are some problems with this solution related to components that publish
values in the RequestMap while the real tree is processed (rendered) like
e.g. ui:repeat or h:dataTable (mostly those with a var attribute). Every
child component of such a component, which refers to this value, will cause
EL operations with invalid parameters (null or empty String) when its getters
are called. See the related thread on the mailing list to this problem:
http://www.mail-archive.com/us...@myfaces.apache.org/msg55485.html
In addition, properties with values of Collection, Map or Iterator are not
included in the debug output, only those with real values (like true,
false, 1234) are included. Also I don't think that it makes much sence to
include all real values in the debug component tree, because what should we
display for components that render their children a couple of times like
h:dataTable? ...and depend on values of their parent which are published
somewhere else?
To visualize the problem a bit more, see the following facelet page:
ui:repeat var=master value=#{myBean.masterList}
h:dataTable var=detail value=#{myBean.getDetailList(master)}
h:column
h:outputText value=#{detail} /
/h:column
/h:dataTable
/ui:repeat
The debug output for this one looks something like this:
UIRepeat id=j_id2114509110_7e08d943 inView=true offset=0
rendered=true size=-1 step=1 transient=false var=master
HtmlDataTable border=-2147483648 first=0
id=j_id2114509110_7e08d9b9 inView=true rendered=true rowIndex=-1
rows=0 transient=false var=detail
UIColumn id=j_id2114509110_7e08d99f inView=true
rendered=true transient=false
HtmlOutputText escape=true id=j_id2114509110_7e08d9f5
inView=true rendered=true transient=false/
/UIColumn
/HtmlDataTable
/UIRepeat
I personally think that it would be much better not to evaluate the
ValueExpressions, but to include the properties with the expression String in
the component tree, like you see here:
UIRepeat id=j_id2114509110_7e08d943 inView=true offset=0
rendered=true size=-1 step=1 transient=false
value=#{myBean.masterList} var=master
HtmlDataTable border=-2147483648 first=0
id=j_id2114509110_7e08d9b9 inView=true rendered=true rowIndex=-1
rows=0 transient=false value=#{myBean.getDetailList(master)}
var=detail
UIColumn id=j_id2114509110_7e08d99f inView=true
rendered=true transient=false
HtmlOutputText escape=true id=j_id2114509110_7e08d9f5
inView=true rendered=true transient=false value=#{detail}/
/UIColumn
/HtmlDataTable
/UIRepeat
This will solve the problem the user has experienced and will also create a
much better debug output.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2621) BeanValidation does not work with Unified EL 2.2
[ https://issues.apache.org/jira/browse/MYFACES-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12850902#action_12850902 ] Martin Marinschek commented on MYFACES-2621: Sounds like a totally sure case for removing synchronized ;) best regards, Martin BeanValidation does not work with Unified EL 2.2 Key: MYFACES-2621 URL: https://issues.apache.org/jira/browse/MYFACES-2621 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Environment: bean validation 1.0.0.GA, unified el 2.2 Reporter: Jakob Korherr Assignee: Jakob Korherr When using the new Unified EL 2.2, BeanValidation does not work, because _BeanValidatorUELUtils.getUELValueReferenceWrapper() always returns null. See also the related thread on the mailing list: http://www.mail-archive.com/us...@myfaces.apache.org/msg55250.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1747) zip page state to reduce live memory
[ https://issues.apache.org/jira/browse/TRINIDAD-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851176#action_12851176 ] Martin Marinschek commented on TRINIDAD-1747: - A few questions to this (sorry, I am a bit late): - 100Megs of page state - for one user? This is incredibly high! I guess you are talking about multiple users? - why do you have a page-state independent of the implementation´s page state? I don´t understand this. best regards, Martin zip page state to reduce live memory Key: TRINIDAD-1747 URL: https://issues.apache.org/jira/browse/TRINIDAD-1747 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Gabrielle Crawford Attachments: 1.2.12.1_compressviewstate.patch, 1.2.12.2_compressviewstate.patch, trunk_compressviewstate.patch PageState Objects tend to pin a lot of live memory. These objects are heavy in live memory and can use a couple of MB per object. This is very big overhead and becomes much bigger issue in clustering when session replication happens. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2634) MyFaces 2.0 performance improvements
MyFaces 2.0 performance improvements Key: MYFACES-2634 URL: https://issues.apache.org/jira/browse/MYFACES-2634 Project: MyFaces Core Issue Type: New Feature Components: JSR-314 Reporter: Martin Marinschek Assignee: Martin Marinschek JSF 2.0 introduced a partial state saving option: state of the page will not completely, but only partially state-saved. This partial state saving reduces the page-state memory to around 20% of the value under the JSF 1.2 full state saving option, as preliminary measurements show - this is a relevant reduction. However, I believe we can reduce this number even more, if we carefully take a look on what really needs to be saved and how. This project would need to provide: 1) a setup to measure the numbers and provide comparisons 2) measurements of the current state 3) several steps which lead to a reduction of the state Further research topics could be: - partial state-saving in tables - currently, this is not implemented at all - if no c:if, c:forEach, or ui:include is present on the page, we could get rid of the second application of the template before rendering automatically. best regards, Martin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1747) zip page state to reduce live memory
[ https://issues.apache.org/jira/browse/TRINIDAD-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12851191#action_12851191 ] Martin Marinschek commented on TRINIDAD-1747: - That sounds reasonable. Question: do you anyways save the state, or only cache? what do you do if the user spawns a new window for the same view? best regards, Martin zip page state to reduce live memory Key: TRINIDAD-1747 URL: https://issues.apache.org/jira/browse/TRINIDAD-1747 Project: MyFaces Trinidad Issue Type: Improvement Reporter: Gabrielle Crawford Attachments: 1.2.12.1_compressviewstate.patch, 1.2.12.2_compressviewstate.patch, trunk_compressviewstate.patch PageState Objects tend to pin a lot of live memory. These objects are heavy in live memory and can use a couple of MB per object. This is very big overhead and becomes much bigger issue in clustering when session replication happens. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2624) Automatically add h:messages if ProjectStage is Development
[ https://issues.apache.org/jira/browse/MYFACES-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12850080#action_12850080 ] Martin Marinschek commented on MYFACES-2624: Hi Jakob, can you please open a spec issue (against the missing documentation)? thanks a lot, regards, Martin Automatically add h:messages if ProjectStage is Development --- Key: MYFACES-2624 URL: https://issues.apache.org/jira/browse/MYFACES-2624 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Jakob Korherr Assignee: Jakob Korherr If ProjectStage is Development and there is no h:messages component on the current view we should automatically add h:messages to the component tree, because many users often forget about adding this useful (debug) component and wonder why their actions are never called. This is also an official JSF 2.0 spec requirement, however I couldn't find it in the spec-pdf or in the javadoc, but in the spec issue tracker [1] and on several blogs like Ryan Lubke's Blog [2]. Furthermore Mojarra also does it. [1] https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=314 [2] http://blogs.sun.com/rlubke/entry/jsf_2_0_new_feature2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2618) Don't warn if there is no submitted value in the current request for every EditableValueHolder
[ https://issues.apache.org/jira/browse/MYFACES-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12848656#action_12848656 ] Martin Marinschek commented on MYFACES-2618: Hi Jakob, I am not sure, I think I might object ;) Why that warning is invented is easily explained: users often forget that the rendered attribute needs to be bound to a bean in scope session or conversation. And if they forget this, the rendered attribute might have toggled (to true), and suddenly we try to decode something for which no submitted value is there. To give the user at least some information that there is a problem, we log that warning. Now, for the AJAX case: if nothing is submitted, why would you run the decoding for this field? That sounds a bit strange to me. You might decide to execute only some of the fields, but then you would also submit these fields - a split between submitting some and decoding some others is nothing which I would see as being useful. In short: I need more information to decide that I would object, but I think I will. best regards, Martin Don't warn if there is no submitted value in the current request for every EditableValueHolder -- Key: MYFACES-2618 URL: https://issues.apache.org/jira/browse/MYFACES-2618 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Jakob Korherr Assignee: Jakob Korherr Priority: Minor Attachments: MYFACES-2618.patch Take a look at HtmlRendererUtils.decodeUIInput(): There we do a check for paramMap.containsKey(clientId) and if this returns false (meaning that there is no submitted value for the given component in the request parameter map) we add a warning message to the log. I think we should get rid of this warning, because as a reason of AJAX it is on my opinion normal to not submit all values of a form in every request. Furthermore it has no impact on the lifecycle, because if the submitted value is null it just isn't processed any further. See also the related thread on the mailing list: http://www.mail-archive.com/us...@myfaces.apache.org/msg55238.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2615) Conversion errors should add a FacesMessage instead of throwing a FacesException
[ https://issues.apache.org/jira/browse/MYFACES-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12848666#action_12848666 ] Martin Marinschek commented on MYFACES-2615: I totally agree with your reasoning. Very well done - you have a very analytical mind, Jakob ;) ! best regards, Martin Conversion errors should add a FacesMessage instead of throwing a FacesException Key: MYFACES-2615 URL: https://issues.apache.org/jira/browse/MYFACES-2615 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Jakob Korherr Assignee: Jakob Korherr Attachments: MYFACES-2615.patch While working on MYFACES-2614 I ran into the problem that, if a conversion fails, the error page is displayed with the related ConverterException. This should not happen, instead a FacesMessage describing the conversion error should be added to the FacesContext. See section 2.2.3 Process Validations (or also section 2.2.2. Apply Request Values for components with immediate set to true) of the JSF 2.0 spec: Conversions and Validations that failed will have caused messages to be enqueued via calls to addMessage() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2615) Conversion errors should add a FacesMessage instead of throwing a FacesException
[ https://issues.apache.org/jira/browse/MYFACES-2615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12848667#action_12848667 ] Martin Marinschek commented on MYFACES-2615: Hi Jakob, a P.S.: can you please request a specification fix on this? Just open an issue in the spec issue tracker. thanks! best regards, Martin Conversion errors should add a FacesMessage instead of throwing a FacesException Key: MYFACES-2615 URL: https://issues.apache.org/jira/browse/MYFACES-2615 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Jakob Korherr Assignee: Jakob Korherr Attachments: MYFACES-2615.patch While working on MYFACES-2614 I ran into the problem that, if a conversion fails, the error page is displayed with the related ConverterException. This should not happen, instead a FacesMessage describing the conversion error should be added to the FacesContext. See section 2.2.3 Process Validations (or also section 2.2.2. Apply Request Values for components with immediate set to true) of the JSF 2.0 spec: Conversions and Validations that failed will have caused messages to be enqueued via calls to addMessage() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2607) Ugly NPE in CompositeFunctionMapper.resolveFunction() if second FunctionMapper is null
[ https://issues.apache.org/jira/browse/MYFACES-2607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12846353#action_12846353 ] Martin Marinschek commented on MYFACES-2607: Hi jakob, sure, sure - my comment was purely theoretical, if the second part of your statement would have been true. In any case, I think I like the NoopFunctionMapper a bit more than passing null - it sounds like a good thing to do to tell people: there is nothing, but this is good as it is. best regards, Martin Ugly NPE in CompositeFunctionMapper.resolveFunction() if second FunctionMapper is null -- Key: MYFACES-2607 URL: https://issues.apache.org/jira/browse/MYFACES-2607 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Jakob Korherr Assignee: Jakob Korherr Priority: Minor Fix For: 2.0.0-beta-3 The class CompositeFunctionMapper gets two FunctionMappers in the constructor which it uses to resolve EL functions in its method resolveFunction(). Currently the first FunctionMapper is always NamespaceHandler and the second one is the one from the ELContext, which is null at all times. I think this is also a problem, but at first I want to get rid of this ugly NPE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2607) Ugly NPE in CompositeFunctionMapper.resolveFunction() if second FunctionMapper is null
[ https://issues.apache.org/jira/browse/MYFACES-2607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845957#action_12845957 ] Martin Marinschek commented on MYFACES-2607: Hi Jakob, in general, it is not really a good idea to try to get rid of null pointer exceptions, if (as you say in the second part of the comment) a null value is not expected at this location. The general rule is: the earlier an exception happens, the better for finding out why it occurs! best regards, Martin Ugly NPE in CompositeFunctionMapper.resolveFunction() if second FunctionMapper is null -- Key: MYFACES-2607 URL: https://issues.apache.org/jira/browse/MYFACES-2607 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-beta-3 Reporter: Jakob Korherr Assignee: Jakob Korherr Priority: Minor Fix For: 2.0.0-beta-3 The class CompositeFunctionMapper gets two FunctionMappers in the constructor which it uses to resolve EL functions in its method resolveFunction(). Currently the first FunctionMapper is always NamespaceHandler and the second one is the one from the ELContext, which is null at all times. I think this is also a problem, but at first I want to get rid of this ugly NPE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2594) Facelets state saving doesn't handle well programmatic component manipulation
[
https://issues.apache.org/jira/browse/MYFACES-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12843489#action_12843489
]
Martin Marinschek commented on MYFACES-2594:
Hi guys,
the viewpoint of the EG is that all dynamic changes to the component tree need
to be tracked by the state-saving algorithm, if partial state saving is enabled.
So if partial state saving is enabled, you need to hook into the add/remove
methods of the component and track the occurring changes.
If partial state saving is not enabled, everything should just work as it used
the work as the driving force for the state is then the full state-tree, which
was completely saved in the JSF1.2 case anyways.
best regards,
Martin
Facelets state saving doesn't handle well programmatic component manipulation
-
Key: MYFACES-2594
URL: https://issues.apache.org/jira/browse/MYFACES-2594
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.0-beta-3
Environment: myfaces trunk
Reporter: Martin Koci
Priority: Minor
Simple tests (code pasted below) outputs following results:
1) JSP: switchs colums at every click with no problem
2) Facelets with javax.faces.PARTIAL_STATE_SAVING=false - no visual switch
3) Facelets with javax.faces.PARTIAL_STATE_SAVING=true switchs colums at
every click with no problem
Common code from test.jspx and test.xhtml
... jsp: or facelets stuff here ...
h:form id=form
h:commandButton value=Switch columns
f:actionListener binding=#{testBean} /
/h:commandButton
h:dataTable id=table
h:column
f:facet name=header
h:outputText value=firstName /
/f:facet
/h:column
h:column
f:facet name=header
h:outputText value=surname /
/f:facet
/h:column
/h:dataTable
/h:form
@ManagedBean
@RequestScoped
public class TestBean implements ActionListener {
public void processAction(ActionEvent event) throws
AbortProcessingException {
FacesContext context = FacesContext.getCurrentInstance();
UIComponent table =
context.getViewRoot().findComponent(form:table);
UIComponent column1 = table.getChildren().get(0);
UIComponent column2 = table.getChildren().get(1);
table.getChildren().clear();
table.getChildren().add(column2);
table.getChildren().add(column1);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2290) Add OSGi bundle information and bundle classloader / activator
[ https://issues.apache.org/jira/browse/MYFACES-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12770849#action_12770849 ] Martin Marinschek commented on MYFACES-2290: Hi Leonardo, Felix, I just checked with Mojarra: they ARE an OSGI Bundle, and they don't have any bundle-activators or other stuff. Only meta-data. Nothing special in Mojarra for OSGI. Felix, why did you feel the need to create these classes? regards, Martin Add OSGi bundle information and bundle classloader / activator -- Key: MYFACES-2290 URL: https://issues.apache.org/jira/browse/MYFACES-2290 Project: MyFaces Core Issue Type: New Feature Components: General Affects Versions: 1.2.8-SNAPSHOT Environment: OSGi (Equinox, Apache Felix, ...) Reporter: Felix Röthenbacher Assignee: Leonardo Uribe Priority: Critical Attachments: myfaces-core.diff.txt, myfaces-shared.diff.txt The provided patch will add OSGi information to bundle manifest. A bundle activator class makes the MyFaces framework aware that it is running in a bundle environment. A bundle classloader is used to load classes and resources from the bundle classpath. The patch doesn't require any new runtime dependencies and doesn't affect class loading in a non-OSGi environment. Though, small modifications to classloading were needed. This was mainly replacing Thread.currentThread.getContextClassLoader() with ClassUtils methods. To run MyFaces in an OSGi environment both bundles (myfaces-api and myfaces-impl) have to be started in the OSGi container. Additionally, the myfaces-impl bundle has to be made available to myfaces-api. Use a fragment bundle with myfaces-api as Fragment-Host and myfaces-impl as Required-Bundle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-15) Orchestra in Portal Environment
[ https://issues.apache.org/jira/browse/ORCHESTRA-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12766477#action_12766477 ] Martin Marinschek commented on ORCHESTRA-15: Hi Leonardo, contrary to your comment on ORCHESTRA-17, I think for JSF 2.0 support we have to give up on the reflection based way of wrapping external-context anyways. So I think we should really go down the route of switching, depending on the active JSF version, between the different wrappers, or work with an extension library. See ORCHESTRA-45 (https://issues.apache.org/jira/browse/ORCHESTRA-45) for my Orchestra JSF 2.0 patch which shows this. regards, Martin Orchestra in Portal Environment --- Key: ORCHESTRA-15 URL: https://issues.apache.org/jira/browse/ORCHESTRA-15 Project: MyFaces Orchestra Issue Type: Bug Affects Versions: 1.0 Environment: myfaces1.1.5, liferay portal4.3.3, orchestra-core1.0, tomcat 5.5 Reporter: Rashmi Assignee: Mario Ivankovits Priority: Blocker Fix For: 1.1 Attachments: ORCHESTRA-Portlet-2.patch, orchestraPortlet.zip, stacktrace.txt In the portlet environment ConversationManager is not getting initialized. The FrameworkAdapter.getCurrentInstance() is as well NULL. The part of the exception is as follows: Caused by: java.lang.NullPointerException at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:90) at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:76) at org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchestraScope.getBean(AbstractSpringOrchestraScope.java:125) at org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchestraScope.get(AbstractSpringOrchestraScope.java:117) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:285) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160) at org.springframework.aop.target.SimpleBeanTargetSource.getTarget(SimpleBeanTargetSource.java:33) at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.getTarget(Cglib2AopProxy.java:661) at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:611) at de.seat.mitarbeiterinfo.view.mitarbeiterlist$$EnhancerByCGLIB$$4f90561b.getMitarbeiterListModel(generated) ... 125 more The filter is not working as expected in Portlet environment but works perfetly well in norman Servlet container. Can myfaces-portlet-bridge be used in someway to configure the filter to run in portlet environment? Thanks and Regards, Rashmi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-40) A transaction token component inspired by the struts transaction processor
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12763940#action_12763940 ] Martin Marinschek commented on ORCHESTRA-40: Hi Mario, I think we all agree, having a decent handling for this thing is a long missing feature here in JSF land. yes, it really is. I also agree that it is much more a virulent problem when you use a conversation framework as it is much likely that you run into problems with the database else. well, I believe it is also a problem with normal session scope, but no one should be using the session scope anyways The question is if we need it strongly integrated into Orchestra. I've looked at the patch, and beside that something gets stored into the conversationContext I can not see anything which can not be solved using normal JSF phase listeners. And for storing into the conversationContext we can create a scope which does this (instead of accessing it directly). You also gain the ability to decide on which level the tokens are kept. If you do not use Orchestra you simply can the manager bean into the session then. Ok, sure, this might as well work without orchestra - but you definitely need a window/tab concept. And isn't that something orchestra also tries to solve? I'd say this component qualifies for its own project, e.g. within our ext (sorry, lost the name) project. On the other hand, I understand that - compared to seam and webflow - people await such functionality from Orchestra too. If we add this to Orchestra, I'd like to see it in a separated module, e.g. orchestra-jsfext. Would this be feasible? Why jsfext? Does the solution have anything to do with JSF per se? The default implementation of the listener might have a JSF implication, but apart from that, no. Again, I think the whole thing is bound to windows and tabs, and therefore needs to reside in Orchestra or on top of Orchestra as a module of Orchestra - where exactly is not so much of an issue to me. As for the technical aspect of this patch, I have some notes: 1) Does this solution work with ajax, or will an ajax request trigger a DOUBLE_SUBMIT_OR_RELOAD_TYPE notification? I think ajax detection needs to be added, at least to detect JSF 2.0 alike ajax requests. Hmm, I am not sure. Shouldn't we just make sure that the parameter gets updated like in the normal request case? 2) I see you store the token in the request parameter. Probably - in the context of ajax - storing it as attribute on the UIViewRoot might be better. If you have to deal with ajax requests you are able to update this value then with the new token. ok, yes - then this would be somewhat automatic. I am also constantly thinking about moving the conversationContext paramter into the UIViewRoot - but this is another story. sounds good to me. 3) We should also add a default TransactionTokenListener which behaves in a way we think an application should react on these events.People than can use it to jump start the system. Probably something like MyTransactionTokenListener with a faces message added so the user will get some feedback. yes, and that might be JSF specific - jump to the rendering phase, and add a faces-message. Exactly. 4) I'd like to have a way to ignore some requests. E.g. if you issue an jsf action which will just stream a PDF to the user (without page change), the browser stay on the page, but the token has been used then. The current token needs to be added to the list of used tokens at the end of the request then. Probably an API like TransactionTokenManager.getInstance().ignoreRequest() suppress this addittion then for the current request. The token can then be used again. Also trinidad has at least two components which open a window and just report the value back to the main window. Probably we also need a way to ignore requests based on an URL pattern to deal with that? Yes, there needs to be a way to cover this usecase. Isn't the target attribute the determining factor? regards, Martin A transaction token component inspired by the struts transaction processor -- Key: ORCHESTRA-40 URL: https://issues.apache.org/jira/browse/ORCHESTRA-40 Project: MyFaces Orchestra Issue Type: New Feature Components: Conversation Affects Versions: 1.3.1 Reporter: Bernd Bohmann Assignee: Simon Kitching Attachments: ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch A transactionToken Component for orchestra inspired by the struts transaction processor. The
[jira] Created: (ORCHESTRA-45) Support for JSF 2.0
Support for JSF 2.0 --- Key: ORCHESTRA-45 URL: https://issues.apache.org/jira/browse/ORCHESTRA-45 Project: MyFaces Orchestra Issue Type: Improvement Components: FrameworkAdapter Affects Versions: 1.3.1 Reporter: Martin Marinschek Orchestra should support JSF 2.0. The supplied patch changes the decorators in Orchestra to allow this, however, the patch is not backwards compatible with the 1.2/1.1 version (and contrary to supporting both 1.1 and 1.2 in one version, this is not possible with 2.0 anymore, as the interfaces have new methods which in turn have parameters/return types which are only available in JSF 2.0). The question will be how we will be able to continue. I see two options: a) a branch, and two independent releases b) adding a common JSF 1.2 compatibility library, which would allow to a certain extent to mimick basic JSF 2.0 infrastructure (it would not try to reimplement features from 2.0, however) I will also post this question to the MyFaces mailing-list, and we will see how to proceed from here. regards, Martin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ORCHESTRA-41) NullPointerException in method findConversationContextId
[ https://issues.apache.org/jira/browse/ORCHESTRA-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Marinschek resolved ORCHESTRA-41. Resolution: Cannot Reproduce Assignee: Martin Marinschek NullPointerException in method findConversationContextId Key: ORCHESTRA-41 URL: https://issues.apache.org/jira/browse/ORCHESTRA-41 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation, FrameworkAdapter Affects Versions: 1.3.1 Environment: Windows XP SP2, Tomcat 6.0.20 Reporter: Bozhidar Bozhanov Assignee: Martin Marinschek Original Estimate: 0.08h Remaining Estimate: 0.08h After some time, (probably when a thread times-out) the following appears: Exception in thread org.apache.myfaces.orchestra.conversation.ConversationWiperThread java.lang.NullPointerException at org.apache.myfaces.orchestra.conversation.ConversationManager.findConversationContextId(ConversationManager.java:140) at org.apache.myfaces.orchestra.conversation.ConversationManager.removeAndInvalidateConversationContext(ConversationManager.java:343) at org.apache.myfaces.orchestra.conversation.ConversationManager.checkTimeouts(ConversationManager.java:626) at org.apache.myfaces.orchestra.conversation.ConversationWiperThread._run(ConversationWiperThread.java:113) at org.apache.myfaces.orchestra.conversation.ConversationWiperThread.run(ConversationWiperThread.java:90) It doesn't bring any trouble to the front-end, but still, it is an exception :) The problem, I think is that the ThreadLocal variable (after the thread has timed-out) return null, so no conversationContext anymore. A little anti-NPE check in the findConversaionContextId would get rid of the exception. I'm not sure whether this happens in 1.3.1, I checked the source code in the repository and there was no NPE check, so I presume the issue is still there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-40) A transaction token component inspired by the struts transaction processor
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12763785#action_12763785 ] Martin Marinschek commented on ORCHESTRA-40: Ok, so there was a lot of action here, but not really a lot of discussion. Let's discuss about the base first: Bernd's (and by the way also Manfred's and mine) point of view is that a JSF application should have a way to be informed of back-button clicks, forward-button clicks, refreshes, double-submits, etc. As I see it, an interface implemented by the application should provide a hook which needs to be called in such cases. Now for me this is highly conversation-context (=tab or window) related: a back-button is always clicked within a tab or window. If you want to indicate to the user that the back-button has been pressed you will need to store a list of tokens (one per request) and again, I think that should be stored per conversation-context (not in the session). If it is not for this, Orchestra should provide ways to handle these problems cause a solution is desperately needed in the JSF space. AFAIK, only Spring Webflow provides something out of the box, and with Spring Webflow you are moving pretty far off the JSF standard, both from a configuration perspective and a usage perspective (however, I am not saying that Spring Webflow is bad - it is indeed a very good framework - just not very close to JSF if you take a deeper look at it). regards, Martin A transaction token component inspired by the struts transaction processor -- Key: ORCHESTRA-40 URL: https://issues.apache.org/jira/browse/ORCHESTRA-40 Project: MyFaces Orchestra Issue Type: New Feature Components: Conversation Affects Versions: 1.3.1 Reporter: Bernd Bohmann Assignee: Simon Kitching Attachments: ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch A transactionToken Component for orchestra inspired by the struts transaction processor. The transaction token is to be used for enforcing a single request for a particular transaction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2156) Performance improvement in HtmlRenderKitImpl
[ https://issues.apache.org/jira/browse/MYFACES-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12714120#action_12714120 ] Martin Marinschek commented on MYFACES-2156: Hi Leonardo, are you sure a flat3map will not cause any problems with multiple threads accessing the configuration? regards, Martin Performance improvement in HtmlRenderKitImpl Key: MYFACES-2156 URL: https://issues.apache.org/jira/browse/MYFACES-2156 Project: MyFaces Core Issue Type: Improvement Affects Versions: 1.1.6 Reporter: Philipp Schoepf Assignee: Leonardo Uribe Priority: Minor Fix For: 1.2.7-SNAPSHOT Attachments: MYFACES-2156.patch we did some profiling in our project and found out that HtmlRenderKitImpl creates some amount of transient object garbage when getRenderer is called: Self 8005 0,00 7,92 0 2894448 J:org/apache/myfaces/renderkit/html/HtmlRenderKitImpl.getRenderer(Ljava/lang/String;Ljava/lang/String;)Ljavax/faces/render/Renderer; Child 24015 0,00 4,69 0 1714064 J:java/lang/StringBuffer.append(Ljava/lang/String;)Ljava/lang/StringBuffer; The above values were recorded with just 2 request to a page with many components - 2.8MB of transient objects were created by 8005 calls to getRenderer. I assume that this is due to the keying currenlty implemented which always creates a concatinated string. I guess using a MapString, MapString, Renderer doubleMap could improve the performance here since string creation for keying would not be nessary. Might also touch 1.2 and 2.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-64) Allow t:htmlTag to support an attributes string.
[ https://issues.apache.org/jira/browse/TOMAHAWK-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611487#action_12611487 ] Martin Marinschek commented on TOMAHAWK-64: --- Hi Christian, but why did you change the component to render its children? For rendering attributes, you would not have had to do this. regards, Martin Allow t:htmlTag to support an attributes string. Key: TOMAHAWK-64 URL: https://issues.apache.org/jira/browse/TOMAHAWK-64 Project: MyFaces Tomahawk Issue Type: Bug Components: Html Tag Reporter: Michael Rimov Assignee: Leonardo Uribe Priority: Minor Fix For: 1.1.7-SNAPSHOT Attachments: htmltag_param_feature.patch I would really like to see t:htmlTag to allow html attributes to be passed into the html tag. A concrete example: td colspan=2 Hello World /td Would Ideally (to me) be converted to: t:htmlTag value=td attributes=colspan='2' h:outputText value=Hello World/ /t:htmlTag Thanks! :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-64) Allow t:htmlTag to support an attributes string.
[ https://issues.apache.org/jira/browse/TOMAHAWK-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12611515#action_12611515 ] Martin Marinschek commented on TOMAHAWK-64: --- Sure, it was a dumb question from my side - you are absolutely right. I don't see how we can solve this and still provide backward-compatibility, and in JSF 1.2, this tag is not relevant anymore, so we should probably not apply this patch at all. regards, Martin Allow t:htmlTag to support an attributes string. Key: TOMAHAWK-64 URL: https://issues.apache.org/jira/browse/TOMAHAWK-64 Project: MyFaces Tomahawk Issue Type: Bug Components: Html Tag Reporter: Michael Rimov Assignee: Leonardo Uribe Priority: Minor Fix For: 1.1.7-SNAPSHOT Attachments: htmltag_param_feature.patch I would really like to see t:htmlTag to allow html attributes to be passed into the html tag. A concrete example: td colspan=2 Hello World /td Would Ideally (to me) be converted to: t:htmlTag value=td attributes=colspan='2' h:outputText value=Hello World/ /t:htmlTag Thanks! :) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-21) URLs are always encoded
[ https://issues.apache.org/jira/browse/ORCHESTRA-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587031#action_12587031 ] Martin Marinschek commented on ORCHESTRA-21: what about relative urls in the browser - they usually start with a / - will those be considered? regards, Martin URLs are always encoded --- Key: ORCHESTRA-21 URL: https://issues.apache.org/jira/browse/ORCHESTRA-21 Project: MyFaces Orchestra Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Mario Ivankovits Fix For: 2.0 In Trinidad some components creates the javascript calls like String url = javascript:TrShuttleProxy._moveItems(...; and than, we internally encode the url. Like facesContext.getExternalContext().encodeActionURL(url); so... with Orchestra, you now get something like: javascript:TrShuttleProxy._movetems();?conversationContext=3 which causes a JS syntax error. Fix would be to ignore anything that has a javascript: prefix. Orchestra should only append the conversationContext if the protocol is http or https. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-21) URLs are always encoded
[ https://issues.apache.org/jira/browse/ORCHESTRA-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587032#action_12587032 ] Martin Marinschek commented on ORCHESTRA-21: To say something more: I would go the same way the portlet bridge is going, and just exclude javascript: / ftp: protocols. regards, Martin URLs are always encoded --- Key: ORCHESTRA-21 URL: https://issues.apache.org/jira/browse/ORCHESTRA-21 Project: MyFaces Orchestra Issue Type: Bug Reporter: Matthias Weßendorf Assignee: Mario Ivankovits Fix For: 2.0 In Trinidad some components creates the javascript calls like String url = javascript:TrShuttleProxy._moveItems(...; and than, we internally encode the url. Like facesContext.getExternalContext().encodeActionURL(url); so... with Orchestra, you now get something like: javascript:TrShuttleProxy._movetems();?conversationContext=3 which causes a JS syntax error. Fix would be to ignore anything that has a javascript: prefix. Orchestra should only append the conversationContext if the protocol is http or https. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1850) component attributes problem with server side state saving with serialize in state = false
[ https://issues.apache.org/jira/browse/MYFACES-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585735#action_12585735 ] Martin Marinschek commented on MYFACES-1850: This is very dangerous; it's good you fix it. Simon's comment is still true, however. Generally, for references to JSF objects, this will not be a problem, cause they will implement the StateHolder-interface. Couldn't we serialize everything which is a reference-type and not a JSF-internal class, instead of serializing the full tree? Would this perform well? Could this be done in a central place? regards, Marti n component attributes problem with server side state saving with serialize in state = false Key: MYFACES-1850 URL: https://issues.apache.org/jira/browse/MYFACES-1850 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.5, 1.2.2 Reporter: Mario Ivankovits Assignee: Mario Ivankovits Priority: Critical When using server side state saving with serialize state in view=false all the saved states for the same view contains a shared reference to the component attribute map. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOBAGO-466) Extend AttributeHandler for handling methodexpression in a facelet composition
[
https://issues.apache.org/jira/browse/TOBAGO-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12578556#action_12578556
]
Martin Marinschek commented on TOBAGO-466:
--
Hi Bernd,
finally I got time to look at this solution ;)
What I like:
it is really simple
What I don't like:
- you have to explicitly define the signature in the attribute-handler - what
with more generic methods? I'd rather configure this somewhere in the
composite...
regards,
Martin
Extend AttributeHandler for handling methodexpression in a facelet composition
--
Key: TOBAGO-466
URL: https://issues.apache.org/jira/browse/TOBAGO-466
Project: MyFaces Tobago
Issue Type: Improvement
Components: Facelets
Reporter: Bernd Bohmann
Assignee: Bernd Bohmann
Fix For: 1.0.12
In a facelets composition a method expression as an argument did not work.
ui:composition...
tc:label .../
tc:in /
tc:button action=${action} actionListener=${actionListener} /
/ui:composition
instead you can use the attribute tag
tc:button
tc:attribute name=action value=${action} /
/tc:button
the attribute tag evaluate the value expression and create if required a
method expression from the value of the expression.
If the value is not a value expression the attribute tag create the method
expression directly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (ORCHESTRA-17) RequestParameterFacesContextFactory only works with HttpServletResponse
RequestParameterFacesContextFactory only works with HttpServletResponse
---
Key: ORCHESTRA-17
URL: https://issues.apache.org/jira/browse/ORCHESTRA-17
Project: MyFaces Orchestra
Issue Type: Bug
Components: RequestParameterProvider
Affects Versions: 1.0, 1.1
Environment: Liferay Portlet Container
Reporter: Martin Marinschek
Assignee: Martin Marinschek
The following snippet wrongly casts to HttpServletResponse, therefore
portlet-environments will not work:
if (response instanceof HttpServletResponse)
{
HttpServletRequest httpServletRequest = (HttpServletRequest)
request;
// Wrap this request only if something else (eg a
RequestParameterServletFilter) has not already wrapped it.
if
(!Boolean.TRUE.equals(httpServletRequest.getAttribute(RequestParameterServletFilter.REQUEST_PARAM_FILTER_CALLED)))
{
I will commit a solution very soon.
regards,
Martin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ORCHESTRA-17) RequestParameterFacesContextFactory only works with HttpServletResponse
[
https://issues.apache.org/jira/browse/ORCHESTRA-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Marinschek resolved ORCHESTRA-17.
Resolution: Fixed
Patch committed. The patch relies on decorating the external-context instead of
the servlet-response.
regards,
Martin
RequestParameterFacesContextFactory only works with HttpServletResponse
---
Key: ORCHESTRA-17
URL: https://issues.apache.org/jira/browse/ORCHESTRA-17
Project: MyFaces Orchestra
Issue Type: Bug
Components: RequestParameterProvider
Affects Versions: 1.0, 1.1
Environment: Liferay Portlet Container
Reporter: Martin Marinschek
Assignee: Martin Marinschek
The following snippet wrongly casts to HttpServletResponse, therefore
portlet-environments will not work:
if (response instanceof HttpServletResponse)
{
HttpServletRequest httpServletRequest = (HttpServletRequest)
request;
// Wrap this request only if something else (eg a
RequestParameterServletFilter) has not already wrapped it.
if
(!Boolean.TRUE.equals(httpServletRequest.getAttribute(RequestParameterServletFilter.REQUEST_PARAM_FILTER_CALLED)))
{
I will commit a solution very soon.
regards,
Martin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-17) RequestParameterFacesContextFactory only works with HttpServletResponse
[
https://issues.apache.org/jira/browse/ORCHESTRA-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577488#action_12577488
]
Martin Marinschek commented on ORCHESTRA-17:
Hi Mario,
ok, I see - I didn't think plain JSPs where served out by the FacesServlet - we
are only wrapping the FacesContext here, right, so how did this ever work with
plain JSPs?
If I understand your class comments correctly, the filter should be used for
plain JSPs?
regards,
Martin
RequestParameterFacesContextFactory only works with HttpServletResponse
---
Key: ORCHESTRA-17
URL: https://issues.apache.org/jira/browse/ORCHESTRA-17
Project: MyFaces Orchestra
Issue Type: Bug
Components: RequestParameterProvider
Affects Versions: 1.0, 1.1
Environment: Liferay Portlet Container
Reporter: Martin Marinschek
Assignee: Martin Marinschek
The following snippet wrongly casts to HttpServletResponse, therefore
portlet-environments will not work:
if (response instanceof HttpServletResponse)
{
HttpServletRequest httpServletRequest = (HttpServletRequest)
request;
// Wrap this request only if something else (eg a
RequestParameterServletFilter) has not already wrapped it.
if
(!Boolean.TRUE.equals(httpServletRequest.getAttribute(RequestParameterServletFilter.REQUEST_PARAM_FILTER_CALLED)))
{
I will commit a solution very soon.
regards,
Martin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-922) JSF-1.2: JspTilesViewHandlerImpl
[ https://issues.apache.org/jira/browse/TOMAHAWK-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577621#action_12577621 ] Martin Marinschek commented on TOMAHAWK-922: I don't get these comments. There is two versions of the JspTilesViewHandler, one for Tiles (old) and one for Tiles 2. The old handler won't work with the RI (the new one should). There is a tiles-example checked in to the MyFaces sources which show this is working. What refactoring on this should be done? regards, Martin JSF-1.2: JspTilesViewHandlerImpl Key: TOMAHAWK-922 URL: https://issues.apache.org/jira/browse/TOMAHAWK-922 Project: MyFaces Tomahawk Issue Type: Bug Components: Tiles Affects Versions: 1.1.5-SNAPSHOT Environment: MyFaces Tomahawk SVN HEAD + JSF-1.2_03 (Reference implementation) + JDK-1.5.0_11 + Tomcat-6.0.10 Reporter: Jesper Pedersen The JspTilesViewHandlerImpl doesn't work under JSF-1.2 (RI) as it doesn't deliver any output. Steps: 1) Get myfaces-example-tiles-1.1.5-SNAPSHOT.war 2) Replace MyFaces-Core with JSF-1.2 (RI) in WEB-INF/lib 3) Deploy on Tomcat-6.0.10 4) Go to http://localhost:8080/myfaces-example-tiles-1.1.5-SNAPSHOT/ Generated HTML: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN head meta http-equiv=Content-Type content=text/html;CHARSET=iso-8859-1 / titleMyfaces - Tiles/title link rel=stylesheet type=text/css href=css/tiles.css / /head /html Basically I'm unable to use Tomahawk under JSF-1.2 currently, so any pointers on how to fix this issue or to provide more information would be great. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-922) JSF-1.2: JspTilesViewHandlerImpl
[ https://issues.apache.org/jira/browse/TOMAHAWK-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577622#action_12577622 ] Martin Marinschek commented on TOMAHAWK-922: Hold on - it won't work with the RI, as the MyFaces-config from the implementation seems still to be used, nobody has ever fixed this long outstanding issue, which doesn't bug us to hard, cause most of us are using Facelets and not the RI, so patches are welcome. regards, Martin JSF-1.2: JspTilesViewHandlerImpl Key: TOMAHAWK-922 URL: https://issues.apache.org/jira/browse/TOMAHAWK-922 Project: MyFaces Tomahawk Issue Type: Bug Components: Tiles Affects Versions: 1.1.5-SNAPSHOT Environment: MyFaces Tomahawk SVN HEAD + JSF-1.2_03 (Reference implementation) + JDK-1.5.0_11 + Tomcat-6.0.10 Reporter: Jesper Pedersen The JspTilesViewHandlerImpl doesn't work under JSF-1.2 (RI) as it doesn't deliver any output. Steps: 1) Get myfaces-example-tiles-1.1.5-SNAPSHOT.war 2) Replace MyFaces-Core with JSF-1.2 (RI) in WEB-INF/lib 3) Deploy on Tomcat-6.0.10 4) Go to http://localhost:8080/myfaces-example-tiles-1.1.5-SNAPSHOT/ Generated HTML: !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN head meta http-equiv=Content-Type content=text/html;CHARSET=iso-8859-1 / titleMyfaces - Tiles/title link rel=stylesheet type=text/css href=css/tiles.css / /head /html Basically I'm unable to use Tomahawk under JSF-1.2 currently, so any pointers on how to fix this issue or to provide more information would be great. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-434) MyFaces's Portlet enhancement
[ https://issues.apache.org/jira/browse/MYFACES-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577655#action_12577655 ] Martin Marinschek commented on MYFACES-434: --- Hi Shinsuke, others, excuse my long silence - it was mostly due to the fact that I found it hard to fully understand what happened in your bridge, Shinsuke - the code is not very easy comprehensible, especially the javascript-rendering-part. I should have discussed more with you guys, but here I am with a different solution which replaces the DefaultAddResource-implementation of MyFaces with one that does not do buffering. Additionally, the extensions-filter is not necessary anymore in a servlet-world - instead, a FacesContextFactory-wrapper and a phase-listener take over. In the portlet-world, the extensions-filter should still be configured in the main web.xml of the portal, it will then serve out resources (use the filter-mapping from before). With this, a few things won't work in the portlet world, but most things will do. However, there is still two issues with my proposed solution: - I can only get it to work with JSF 1.1 _or_ JSF 1.2, but not in both. This is as I need to wrap the FacesContext, and I cannot use the interface of the JSF 1.2 FacesContext in the Tomahawk-1.1 version. However, in a 1.2 environment, the method getELContext() will be called on the FacesContext; and this method is only available in the 1.2 interface. This really means there should have been a FacesContextWrapper fro the beginning in the javax.api.*-classes, then this wouldn't be a problem at all. Does anyone have a suggestion? - I haven't so far taken care of file-upload - should be easy, however. The question is where the init-parameters should come frome now that the filter can safely be removed. Should we maybe read the init-parameters from the filter still, so that the users can keep their configuration? regards, Martin MyFaces's Portlet enhancement - Key: MYFACES-434 URL: https://issues.apache.org/jira/browse/MYFACES-434 Project: MyFaces Core Issue Type: Improvement Components: Portlet_Support Affects Versions: 1.1.0 Environment: LInux, J2SE 1.4.2 Reporter: Shinsuke SUGAYA Assignee: Martin Marinschek Attachments: PortletEnableTomahawk.patch, Tomahawk_FileUpload_IBMPortal.zip MyFacesGenericPortlet does not fully support the feature of tomahawk component, such as inputHtml and fileUpload. So, I request the following feature to run it on portlet: - support tags in head (ex. inputHtml component) - support upload (fileUpload component) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ORCHESTRA-15) Orchestra in Portal Environment
[ https://issues.apache.org/jira/browse/ORCHESTRA-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Marinschek resolved ORCHESTRA-15. Resolution: Fixed Fix Version/s: 1.1 Assignee: Mario Ivankovits Testing has resulted in the information that the bug is resolved. Thanks Mario for your bug-fix, everything is working smoothly in the portlet environment now! If using the MyFacesGenericPortlet, however, there is a class-cast exception - this is entirely the fault of the MyFacesGenericPortlet, however - it wrongly casts the FacesContext to ServletFacesContextImpl. The portlet should instead provide a FacesContextFactory as well. regards, Martin Orchestra in Portal Environment --- Key: ORCHESTRA-15 URL: https://issues.apache.org/jira/browse/ORCHESTRA-15 Project: MyFaces Orchestra Issue Type: Bug Affects Versions: 1.0 Environment: myfaces1.1.5, liferay portal4.3.3, orchestra-core1.0, tomcat 5.5 Reporter: Rashmi Assignee: Mario Ivankovits Priority: Blocker Fix For: 1.1 Attachments: orchestraPortlet.zip, stacktrace.txt In the portlet environment ConversationManager is not getting initialized. The FrameworkAdapter.getCurrentInstance() is as well NULL. The part of the exception is as follows: Caused by: java.lang.NullPointerException at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:90) at org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:76) at org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchestraScope.getBean(AbstractSpringOrchestraScope.java:125) at org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchestraScope.get(AbstractSpringOrchestraScope.java:117) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:285) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:160) at org.springframework.aop.target.SimpleBeanTargetSource.getTarget(SimpleBeanTargetSource.java:33) at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.getTarget(Cglib2AopProxy.java:661) at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:611) at de.seat.mitarbeiterinfo.view.mitarbeiterlist$$EnhancerByCGLIB$$4f90561b.getMitarbeiterListModel(generated) ... 125 more The filter is not working as expected in Portlet environment but works perfetly well in norman Servlet container. Can myfaces-portlet-bridge be used in someway to configure the filter to run in portlet environment? Thanks and Regards, Rashmi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (PORTLETBRIDGE-23) Add ability to redirect during render + execute phase listener when not calling lifecycle.execute
[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569905#action_12569905
]
Martin Marinschek commented on PORTLETBRIDGE-23:
Hi Mike,
I just reviewed your change, and it looks good - except:
+ // using the cached view. Still call the preRestoreView phase listeners
+ // as some extensions depend on this being called per request.
+ PhaseListener[] listeners = lifecycle.getPhaseListeners();
+ PhaseEvent event = new PhaseEvent(context, PhaseId.RESTORE_VIEW,
lifecycle);
+ for (PhaseListener listener:listeners)
+ {
+listener.beforePhase(event);
+ }
the line listener.beforePhase() should only be called if the
listener.getPhaseId() returns ANY_PHASE or RESTORE_VIEW - it is our
responsibility to check this before calling this method.
regards,
Martin
Add ability to redirect during render + execute phase listener when not
calling lifecycle.execute
-
Key: PORTLETBRIDGE-23
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-23
Project: MyFaces Portlet Bridge
Issue Type: New Feature
Components: Impl
Affects Versions: 1.0.0-SNAPSHOT
Reporter: Michael Freedman
Fix For: 1.0.0-SNAPSHOT
Attachments: jira_23.patch
Add ability to redirect during a render (local navigation)
Call (before) phase listener in render when not calling lifecycle.execute()
Misc changes to sync with updated version of the spec.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1190) Exception in t:columns
[ https://issues.apache.org/jira/browse/TOMAHAWK-1190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12566564#action_12566564 ] Martin Marinschek commented on TOMAHAWK-1190: - They should be Boolean - the code causing the exception (in the renderer?) is wrong. regards, Martin Exception in t:columns -- Key: TOMAHAWK-1190 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1190 Project: MyFaces Tomahawk Issue Type: Bug Reporter: Martin Haimberger Assignee: Martin Haimberger Attachments: HtmlColumns-patch_issue_1190.patch Hi, the setter for the attributes sortable, defaultSorted, groupBy are Boolean instead of boolean, which causes a exception if using this attributes. Regards, Martin Haimberger -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1192) ClassCastException in inputHtml
[ https://issues.apache.org/jira/browse/TOMAHAWK-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Marinschek resolved TOMAHAWK-1192. - Resolution: Fixed Fix Version/s: 1.1.7-SNAPSHOT Assignee: Martin Marinschek ClassCastException in inputHtml --- Key: TOMAHAWK-1192 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1192 Project: MyFaces Tomahawk Issue Type: Bug Components: Html Editor Affects Versions: 1.1.6 Environment: myfaces 1.2.2, tomahawk 1.1.6, facelets 1.1.13. Reporter: Ken McArthur Assignee: Martin Marinschek Fix For: 1.1.7-SNAPSHOT Get the following exception in the rendering facelets phases: Caused by: java.lang.ClassCastException: java.lang.Class at org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:35) at org.apache.myfaces.custom.inputHtml.InputHtmlRenderer.setThisPageAlreadyRenderedAnInputHtml(InputHtmlRenderer.java:107) at org.apache.myfaces.custom.inputHtml.InputHtmlRenderer.encodeEnd(InputHtmlRenderer.java:93) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:556) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1192) ClassCastException in inputHtml
[ https://issues.apache.org/jira/browse/TOMAHAWK-1192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12566889#action_12566889 ] Martin Marinschek commented on TOMAHAWK-1192: - Please test on next snapshot. regards, Martin ClassCastException in inputHtml --- Key: TOMAHAWK-1192 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1192 Project: MyFaces Tomahawk Issue Type: Bug Components: Html Editor Affects Versions: 1.1.6 Environment: myfaces 1.2.2, tomahawk 1.1.6, facelets 1.1.13. Reporter: Ken McArthur Assignee: Martin Marinschek Fix For: 1.1.7-SNAPSHOT Get the following exception in the rendering facelets phases: Caused by: java.lang.ClassCastException: java.lang.Class at org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:35) at org.apache.myfaces.custom.inputHtml.InputHtmlRenderer.setThisPageAlreadyRenderedAnInputHtml(InputHtmlRenderer.java:107) at org.apache.myfaces.custom.inputHtml.InputHtmlRenderer.encodeEnd(InputHtmlRenderer.java:93) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:556) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1187) submitOnEvent callback can not bind to bean method
[
https://issues.apache.org/jira/browse/TOMAHAWK-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Marinschek resolved TOMAHAWK-1187.
-
Resolution: Fixed
Fix Version/s: 1.1.7-SNAPSHOT
Assignee: Martin Marinschek
Bug is fixed - but the rendered-property should already have worked for this
component. For your suggestion: please open a separate improvement request for
this.
regards,
Martin
submitOnEvent callback can not bind to bean method
--
Key: TOMAHAWK-1187
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1187
Project: MyFaces Tomahawk
Issue Type: Bug
Components: submitOnEvent
Reporter: Dave
Assignee: Martin Marinschek
Fix For: 1.1.7-SNAPSHOT
callback=#{bean.submit? \func1\ : \ func2\}
The bean method is not called, and the callback is always func2.
Suggest onsubmit that takes javascript code (return true or false)
true -- submit (click the link/button)
false -- do not submit
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Deleted: (MYFACES-1813) inputHtml
[ https://issues.apache.org/jira/browse/MYFACES-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Marinschek deleted MYFACES-1813: --- inputHtml - Key: MYFACES-1813 URL: https://issues.apache.org/jira/browse/MYFACES-1813 Project: MyFaces Core Issue Type: Bug Environment: myfaces 1.2.2, tomahawk 1.1.6, facelets 1.1.13. Reporter: Ken McArthur Get the following exception in the rendering facelets phases: Caused by: java.lang.ClassCastException: java.lang.Class at org.apache.myfaces.util.AbstractAttributeMap.put(AbstractAttributeMap.java:35) at org.apache.myfaces.custom.inputHtml.InputHtmlRenderer.setThisPageAlreadyRenderedAnInputHtml(InputHtmlRenderer.java:107) at org.apache.myfaces.custom.inputHtml.InputHtmlRenderer.encodeEnd(InputHtmlRenderer.java:93) at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:556) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1812) All faces-config.xml get loaded twice from jars in WEB-INF/lib
[ https://issues.apache.org/jira/browse/MYFACES-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12564217#action_12564217 ] Martin Marinschek commented on MYFACES-1812: I need to add: I'm not sure about this - and haven't tested the behaviour. I have never seen this happening in any of my web-applications - and I wonder what the difference in environment you have. The reason why I rewrote the code still is that we also need to sort the faces-config.xml-files by name of the jar they are contained in - we didn't do this so far, but it is in the spec, so I could kill this ommission with the same commit. regards, Martin All faces-config.xml get loaded twice from jars in WEB-INF/lib -- Key: MYFACES-1812 URL: https://issues.apache.org/jira/browse/MYFACES-1812 Project: MyFaces Core Issue Type: Bug Reporter: Val Blant ClassUtils.getResources(FACES_CONFIG_RESOURCE, this) will return an iterator over all META-INF/faces-config.xml resources that were found. The search is carried out by starting at WebAppClassLoader and making an Enumeration of all resources with the given name that WebAppClassLoader and all its parents see. The jars placed into WEB-INF/lib will be seen by the WebAppClassLoader AND AppClassLoader, thus resulting in the same jars (the ones that have META-INF/faces-config.xml) being placed on the list twice. This is fine, but things break when FacesConfigurator.feedClassloaderConfigurations() does not check for duplicate URLs and just blindly registers everything from these jars twice. One of the effects of this bug is that all phase listeners get registered and therefore executed twice. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1812) All faces-config.xml get loaded twice from jars in WEB-INF/lib
[ https://issues.apache.org/jira/browse/MYFACES-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Marinschek resolved MYFACES-1812. Resolution: Fixed Fix Version/s: 1.2.3-SNAPSHOT P.S.: can you please test the new snapshot tomorrow and tell us the results? regards, Martin All faces-config.xml get loaded twice from jars in WEB-INF/lib -- Key: MYFACES-1812 URL: https://issues.apache.org/jira/browse/MYFACES-1812 Project: MyFaces Core Issue Type: Bug Reporter: Val Blant Assignee: Martin Marinschek Fix For: 1.2.3-SNAPSHOT ClassUtils.getResources(FACES_CONFIG_RESOURCE, this) will return an iterator over all META-INF/faces-config.xml resources that were found. The search is carried out by starting at WebAppClassLoader and making an Enumeration of all resources with the given name that WebAppClassLoader and all its parents see. The jars placed into WEB-INF/lib will be seen by the WebAppClassLoader AND AppClassLoader, thus resulting in the same jars (the ones that have META-INF/faces-config.xml) being placed on the list twice. This is fine, but things break when FacesConfigurator.feedClassloaderConfigurations() does not check for duplicate URLs and just blindly registers everything from these jars twice. One of the effects of this bug is that all phase listeners get registered and therefore executed twice. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOBAGO-516) Unable to deploy Tobago sample application to JSF RI 1.2_05 RC3
[
https://issues.apache.org/jira/browse/TOBAGO-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561257#action_12561257
]
Martin Marinschek commented on TOBAGO-516:
--
I would suspect it is - what Ryan is referring to is you should use
from-outcome/, and not from-action/ in this case.
from-action should only be used with a method-binding relating to the action
that is being executed!
regards,
Martin
Unable to deploy Tobago sample application to JSF RI 1.2_05 RC3
---
Key: TOBAGO-516
URL: https://issues.apache.org/jira/browse/TOBAGO-516
Project: MyFaces Tobago
Issue Type: Bug
Components: Demo
Affects Versions: 1.0.11
Environment: Ubuntu Feisty Fawn
JDK 1.6.0_03
JSF-RI 1.2_05 RC3
Reporter: Ryan Lubke
When attempting to deploy the latest Tobago snapshot demo, I see the
following error upon deployment:
[#|2007-10-15T11:24:42.109-0700|SEVERE|sun-appserver9.1|javax.enterprise.system.container.web|_ThreadID=16;_ThreadName=Timer-5;_RequestID=d4c3328a-551f-42df-a738-9d82f6217276;|WebModule[/tobago]PWC1275:
Exception sending context initialized event to listener instance of class
com.sun.faces.config.ConfigureListener
com.sun.faces.config.ConfigurationException: CONFIGURATION FAILED! Unable to
parse document 'jndi:/server/tobago/WEB-INF/faces-config.xml':
cvc-pattern-valid: Value '404' is not facet-valid with respect to pattern
'#\{.*\}' for type 'faces-config-el-expressionType'.
Looking at the faces-config.xml in question, the following navigation rule is
specified:
navigation-rule
from-view-id/best-practice/error.jsp/from-view-id
navigation-case
from-action404/from-action
to-view-id/best-practice/not-existing-page.jsp/to-view-id
/navigation-case
navigation-case
from-actionsyntax/from-action
to-view-id/best-practice/error-in-syntax.jsp/to-view-id
/navigation-case
/navigation-rule
The description of from-action:
The from-action element contains an action reference expression
that must have been executed (by the default ActionListener for handling
application level events) in order to select this navigation rule.
That having been said, this will probably work fine on JSF-RI 1.2_04 P02.
1.2_05 change the config parsing to use schemas for all validation.
1.2_05 includes a private 1.1 version of the schema. Any 1.x based
faces-config
files will be converted to refer to the private schema internally and then
validated
using a cached schema instance. This was done as it is very difficult to
provide
both schema and dtd validation without relying on implementation specific
properties.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-906) optimize getClientId - use per thread shared StringBuilder
[ https://issues.apache.org/jira/browse/TRINIDAD-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561256#action_12561256 ] Martin Marinschek commented on TRINIDAD-906: Hi Gabrielle, I'm just wondering - would it be better to store the String-Builder as a request-Attribute? As you get passed a FacesContext into getClientId() anyways, you might save some CPU-cycles which are necessary to retrieve the the thread-local variable? regards, Martin optimize getClientId - use per thread shared StringBuilder -- Key: TRINIDAD-906 URL: https://issues.apache.org/jira/browse/TRINIDAD-906 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.5-core Reporter: Gabrielle Crawford Priority: Minor Fix For: 1.0.6-core, 1.2.6-core In getClientId/getContainerClientId we create a new stringBuilder. However when creating a client id we only use one stringBuilder at a time, so have a single instance of a StringBuilder saved on thread local. Have a utility to get this instance, and any time a user gets the instance, set the length of the stringBuilder to 0. This will completely break if a user tries to call it for 2 stringbuilders, so doc this well. Preliminary testing by a performance person here at Oracle found the saving is ~300KB out of 5850KB for the request. This is about 5% total request memory. As expected profile shows that most of the memory saving comes from not creating huge number of string builders -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-906) optimize getClientId - use per thread shared StringBuilder
[ https://issues.apache.org/jira/browse/TRINIDAD-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561265#action_12561265 ] Martin Marinschek commented on TRINIDAD-906: Ok, I've read a little more - ThreadLocal doesn't need a synchronized access anymore, but obviously getting the current thread still needs some performance. Well, your performance guys will be able to tell you ;) regards, Martin optimize getClientId - use per thread shared StringBuilder -- Key: TRINIDAD-906 URL: https://issues.apache.org/jira/browse/TRINIDAD-906 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.5-core Reporter: Gabrielle Crawford Priority: Minor Fix For: 1.0.6-core, 1.2.6-core In getClientId/getContainerClientId we create a new stringBuilder. However when creating a client id we only use one stringBuilder at a time, so have a single instance of a StringBuilder saved on thread local. Have a utility to get this instance, and any time a user gets the instance, set the length of the stringBuilder to 0. This will completely break if a user tries to call it for 2 stringbuilders, so doc this well. Preliminary testing by a performance person here at Oracle found the saving is ~300KB out of 5850KB for the request. This is about 5% total request memory. As expected profile shows that most of the memory saving comes from not creating huge number of string builders -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-906) optimize getClientId - use per thread shared StringBuilder
[ https://issues.apache.org/jira/browse/TRINIDAD-906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561491#action_12561491 ] Martin Marinschek commented on TRINIDAD-906: Up to JDK1.4 getting the current thread seemed to be expensive - I didn't find any numbers for 1.4, 1.5 or 1.6, just the general statement that in 1.4, this is better. Thanks for the clarification, Scott! regards, Martin optimize getClientId - use per thread shared StringBuilder -- Key: TRINIDAD-906 URL: https://issues.apache.org/jira/browse/TRINIDAD-906 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.5-core Reporter: Gabrielle Crawford Assignee: Gabrielle Crawford Priority: Minor Fix For: 1.0.6-core, 1.2.6-core In getClientId/getContainerClientId we create a new stringBuilder. However when creating a client id we only use one stringBuilder at a time, so have a single instance of a StringBuilder saved on thread local. Have a utility to get this instance, and any time a user gets the instance, set the length of the stringBuilder to 0. This will completely break if a user tries to call it for 2 stringbuilders, so doc this well. Preliminary testing by a performance person here at Oracle found the saving is ~300KB out of 5850KB for the request. This is about 5% total request memory. As expected profile shows that most of the memory saving comes from not creating huge number of string builders -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1805) form stopped working after ajax request
[ https://issues.apache.org/jira/browse/MYFACES-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561146#action_12561146 ] Martin Marinschek commented on MYFACES-1805: Is this related to https://issues.apache.org/jira/browse/MYFACES-1804 ? regards, Martin form stopped working after ajax request --- Key: MYFACES-1805 URL: https://issues.apache.org/jira/browse/MYFACES-1805 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.5, 1.2.0 Reporter: Mario Ivankovits Fix For: 1.1.6-SNAPSHOT, 1.2.2-SNAPSHOT In a little bit complicated form using multiple PPR areas the datascroller attached to a datatable stopped working with InternetExplorer after the first ajax request. MyFaces always sent the current page again. It turned out that the code in oamSetHiddenInput is not fully compatible with InternetExplorer. The problem is that even after adding the element to the form using javascript the check for it (typeof form.elements[name]=='undefined') still returns undefined. After setting the id of the created element (beside of it's name) fixed this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-892) PanelTabbed immediate does not work
[ https://issues.apache.org/jira/browse/TRINIDAD-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12557934#action_12557934 ] Martin Marinschek commented on TRINIDAD-892: I'd say Tomas is right - immediate's only use is to pass on conversion, validation, update model and execute invoke application directly after decode. regards, Martin PanelTabbed immediate does not work --- Key: TRINIDAD-892 URL: https://issues.apache.org/jira/browse/TRINIDAD-892 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.0.4-core Reporter: Tomas Havelka Fix For: 1.0.5-core Immediate attribute in ShowDetailItem component embedded in PanelTabbed does not work at all. It always calls validation and tab page cannot be changed when the active one contains not valid data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-1115) Adding Tiles2 support to tomahawk
[ https://issues.apache.org/jira/browse/TOMAHAWK-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Marinschek updated TOMAHAWK-1115: Resolution: Duplicate Fix Version/s: 1.1.7-SNAPSHOT Assignee: Martin Marinschek Status: Resolved (was: Patch Available) Duplicate of TOMAHAWK-1160. Actually, TOMAHAWK-1160 is the duplicate. Forgive my ignorance - my only excuse is that my solution is cleaner, and also works in a portlet environment. regards, Martin Adding Tiles2 support to tomahawk - Key: TOMAHAWK-1115 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1115 Project: MyFaces Tomahawk Issue Type: Improvement Components: Tiles Reporter: Stephen More Assignee: Martin Marinschek Priority: Minor Fix For: 1.1.7-SNAPSHOT Attachments: Bundle.properties, JspTiles2ViewHandlerImpl.java, TilesViewHandler.java It looks like branch 1.x of struts is supported. ( http://myfaces.apache.org/tomahawk/tiles.html ) Can code be added to support tiles 2 ( http://tiles.apache.org/ ) ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1782) France Locale and NumberConverter doesn't work well with currency strings
[
https://issues.apache.org/jira/browse/MYFACES-1782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547999
]
Martin Marinschek commented on MYFACES-1782:
So you're saying the default grouping separator for the fr_FR locale is \u00a?
regards,
Martin
France Locale and NumberConverter doesn't work well with currency strings
-
Key: MYFACES-1782
URL: https://issues.apache.org/jira/browse/MYFACES-1782
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0
Reporter: Matthias Weßendorf
Assignee: Matthias Weßendorf
Attachments: MYFACES-1782.patch
This test-case shows, that there is a failure inside the standard
NumberConverter (MyFaces):
protected void setUp() throws Exception
{
super.setUp();
mock = new NumberConverter();
mock.setLocale(Locale.FRANCE);
FacesContext.getCurrentInstance().getViewRoot().setLocale(Locale.GERMANY);
}
public void testFranceLocale()
{
UIInput input = new UIInput();
mock.setType(currency);
Number number = (Number)
mock.getAsObject(FacesContext.getCurrentInstance(), input, 12 345,68
€);
assertNotNull(number);
}
the grouping_sep should be a nb-space...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1160) MyFaces Tiles integration has not been working with Tiles 2 - now it does
MyFaces Tiles integration has not been working with Tiles 2 - now it does - Key: TOMAHAWK-1160 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1160 Project: MyFaces Tomahawk Issue Type: New Feature Components: Tiles Affects Versions: 1.1.6 Reporter: Martin Marinschek Assignee: Martin Marinschek Fix For: 1.1.7-SNAPSHOT Upgrade of MyFaces Tiles integration to Tiles 2 - use new JspTilesTwoViewHandlerImpl class with Tiles 2 and the new configuration / jsp-tag syntax of tiles 2 for this to work. The integration is shown in the MyFaces Tomahawk Tiles example. regards, Martin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1160) MyFaces Tiles integration has not been working with Tiles 2 - now it does
[ https://issues.apache.org/jira/browse/TOMAHAWK-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Marinschek resolved TOMAHAWK-1160. - Resolution: Fixed MyFaces Tiles integration has not been working with Tiles 2 - now it does - Key: TOMAHAWK-1160 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1160 Project: MyFaces Tomahawk Issue Type: New Feature Components: Tiles Affects Versions: 1.1.6 Reporter: Martin Marinschek Assignee: Martin Marinschek Fix For: 1.1.7-SNAPSHOT Upgrade of MyFaces Tiles integration to Tiles 2 - use new JspTilesTwoViewHandlerImpl class with Tiles 2 and the new configuration / jsp-tag syntax of tiles 2 for this to work. The integration is shown in the MyFaces Tomahawk Tiles example. regards, Martin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-63) having two or more x:inputFileUpload in the same form results in the h:commandButton's action never being executed.
[
https://issues.apache.org/jira/browse/TOMAHAWK-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Marinschek resolved TOMAHAWK-63.
---
Resolution: Fixed
Fix Version/s: 1.1.7-SNAPSHOT
Thanks to Alexander Jesse for checking this.
regards,
Martin
having two or more x:inputFileUpload in the same form results in the
h:commandButton's action never being executed.
---
Key: TOMAHAWK-63
URL: https://issues.apache.org/jira/browse/TOMAHAWK-63
Project: MyFaces Tomahawk
Issue Type: Bug
Components: File Upload
Environment: Windows, Tomcat 5.5 and Sun RI 1.1.01
Reporter: Neal Katz
Assignee: Manfred Geiler
Fix For: 1.1.7-SNAPSHOT
having two or more x:inputFileUpload in the same form results in the
h:commandButton's action never being executed.
example,
h:panelGrid columns=3 styleClass=page-header
h:outputText value=Select Primary Image /
x:inputFileUpload id=fileupload1
accept=image/*
value=#{editProductPageBean.upFile}
storage=file
styleClass=fileUploadInput
required=true /
h:commandButton value=Upload
action=#{editProductPageBean.uploadPrimary} /
h:outputText value=Select Thumb Image /
x:inputFileUpload id=fileupload2
accept=image/*
value=#{editProductPageBean.upFile}
storage=file
styleClass=fileUploadInput
required=true /
h:commandButton value=Upload
action=#{editProductPageBean.uploadThumb} /
/h:panelGrid
remove the second x:inputFileUpload and everything works fine
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-6) MyFaces FileUpload Issues
[ https://issues.apache.org/jira/browse/TOMAHAWK-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Marinschek resolved TOMAHAWK-6. -- Resolution: Fixed Fix Version/s: 1.1.7-SNAPSHOT Assignee: Martin Marinschek Both issues fixed in latest head. Thanks to Alexander Jesse for helping me to fix and test this. regards, Martin MyFaces FileUpload Issues - Key: TOMAHAWK-6 URL: https://issues.apache.org/jira/browse/TOMAHAWK-6 Project: MyFaces Tomahawk Issue Type: Bug Components: File Upload Reporter: David F Assignee: Martin Marinschek Fix For: 1.1.7-SNAPSHOT Their are two issues: The first issues is MyFaces defines an UploadFile Interface that you access in your backing bean. The UploadedFile interface doesn't define a method for deleting the temporary files that Commons File Upload creates on disk. These files will be deleted only when the FileItem instances are garbage collected. The DefaultFileItem class of Commons File Upload has a finalize() method that deletes the temporary file managed by the object that is removed from memory. If the application is uploading large files, we want to delete them right after they are processed, without waiting for garbage collection. To be able to do that, we would have to add a getFileItem() method (in UploadedFileDefaultFileImpl) that should return the FileItem instance, which has a delete() method. In addition, we would also have to add this to the UploadFile interface as well. The second issue is Their are two filter parameters in Myfaces file upload component: uploadThresholdSize and uploadMaxFileSize(both are required by the Commons File Upload component) The uploadThresholdSize tells Common File uploads to keep files in memory that are less than this size, and uploadMaxFileSize says to ignore files that take less than this size.If you try to upload a file that is too large, the current version of MyFaces ignores all form data, as if the user submitted an empty form. If we want to signal the failed upload to the user, we would have to change the source code of the MultipartRequestWrapper class of MyFaces and add a FacesContext.getCurrentInstance().addMessage() to warn the user. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1761) Handling PostConstruct annotations - wrong order
[ https://issues.apache.org/jira/browse/MYFACES-1761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541298 ] Martin Marinschek commented on MYFACES-1761: @Paul: I think we should do the same as the RI does (especially, as what the RI does is a lot more inline with what a user would expect). We need to be compliant not only to the spec wording, but also to the meaning, and the meaning is interpreted by what the RI does (we can certainly behave different if compatiblity is not at stake and if we do things better for the user, but not worse). So this is indeed a bug! regards, Martin Handling PostConstruct annotations - wrong order Key: MYFACES-1761 URL: https://issues.apache.org/jira/browse/MYFACES-1761 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Reporter: Bernhard Huemer Fix For: 1.2.1-SNAPSHOT Attachments: MyFaces-1761.patch, postconstruct-demo.zip The specification states that managed bean methods annotated with @PostConstruct have to be called after the object is initialized and after dependency injection is performed. However, MyFaces calls those methods after the bean instance is created but before dependency injection is performed (for example, see http://www.nabble.com/myfaces-1.2.0-postConstruct-tf4760326.html ). In order to resolve this bug the LifecycleProvider interface has to be changed. Currently there's only one method responsible for creating/initializing a new bean: newInstance(). This design choice implicates that there's no possibility to seperate the steps creating the bean and postconstructing the bean. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1729) label attribute does not resolve EL expresion (JSR 252 Issue 6 related)
[
https://issues.apache.org/jira/browse/MYFACES-1729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537911
]
Martin Marinschek commented on MYFACES-1729:
Ok, I like your last solution best as well, but I wonder if there are any
compatibility problems here.
May I ask you to look at the RI as well? Why is it working there? I think they
will have a different trick, can we check if the two tricks together will
remain compatible?
regards,
Martin
label attribute does not resolve EL expresion (JSR 252 Issue 6 related)
---
Key: MYFACES-1729
URL: https://issues.apache.org/jira/browse/MYFACES-1729
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.1-SNAPSHOT
Environment: Tomcat 6, Windows XP
Reporter: Leonardo Uribe
Attachments: patchFinalSolution.patch
When validation is applied to the following page:
%@ page session=false contentType=text/html;charset=utf-8%
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h%
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%
html
f:view
[EMAIL PROTECTED] file=inc/head.inc%
body
f:loadBundle
basename=org.apache.myfaces.examples.resource.example_messages
var=example_messages/
h1Myfaces Examples JSF 1.2 Additions/h1
h:messages id=messageList styleClass=error/
h:form id=form1
h:panelGrid columns=4
h:outputLabel for=form1:number1
value=#{example_messages['sample1_number']} 1 : /
h:outputText
value=#{validationController.number1ValidationLabel} /
h:inputText label=#{example_messages['sample1_number']}
id=number1 value=#{calcForm.number1} maxlength=10
size=25 required=true
f:validateLongRange minimum=1 maximum=10 /
/h:inputText
h:message id=number1Error for=form1:number1
styleClass=error /
/h:panelGrid
h:panelGrid columns=4
h:outputLabel for=form1:number2
value=#{example_messages['sample1_form']} 2 : /
h:outputText
value=#{validationController.number2ValidationLabel} /
h:inputText label=#{example_messages['sample1_form']}
id=number2 value=#{calcForm.number2} maxlength=10
size=25 required=true
f:validateLongRange minimum=20 maximum=50 /
/h:inputText
h:message id=number2Error for=form1:number2
styleClass=error /
/h:panelGrid
h:panelGrid columns=2
h:outputLabel for=form1:result
value=#{example_messages['sample1_result']} : /
h:outputText id=result value=#{calcForm.result} /
/h:panelGrid
h:panelGrid columns=4
h:commandButton id=addButton
value=#{example_messages['sample1_add']} action=none
f:actionListener
type=org.apache.myfaces.examples.example1.CalcActionListener/f:actionListener
/h:commandButton
h:commandButton id=subtractButton
value=#{example_messages['sample1_sub']} action=none
f:actionListener
type=org.apache.myfaces.examples.example1.CalcActionListener/f:actionListener
/h:commandButton
h:commandLink id=href1 action=none
h:outputText
value=#{example_messages['sample1_add_link']} /
f:actionListener
type=org.apache.myfaces.examples.example1.CalcActionListener/f:actionListener
/h:commandLink
h:commandLink id=href2 action=none
h:outputText
value=#{example_messages['sample1_sub_link']} /
f:actionListener
type=org.apache.myfaces.examples.example1.CalcActionListener/f:actionListener
/h:commandLink
/h:panelGrid
/h:form
/body
/f:view
/html
If you use the attribute label on inputText like this:
h:inputText label=#{example_messages['sample1_number']}
id=number1 value=#{calcForm.number1} maxlength=10
size=25 required=true
f:validateLongRange minimum=1 maximum=10 /
/h:inputText
and a validation error happens, the EL expression inside label attribute
returns null. On a message box this looks like:
null: Validation Error: Specified attribute is not between the expected
values of 20 and 50.
On JSF RI 1.2 this works
[jira] Updated: (MYFACES-1739) JSR-252 Issue #13: needs converter-for-class converter registration for BigDecimal and BigInteger
[
https://issues.apache.org/jira/browse/MYFACES-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Marinschek updated MYFACES-1739:
---
Resolution: Fixed
Assignee: Martin Marinschek
Status: Resolved (was: Patch Available)
Thanks to Leonardo Uribe for supplying this patch.
regards,
Martin
JSR-252 Issue #13: needs converter-for-class converter registration for
BigDecimal and BigInteger
--
Key: MYFACES-1739
URL: https://issues.apache.org/jira/browse/MYFACES-1739
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Environment: Tomcat 6.0.14, Myfaces 1.2.1-SNAPSHOT
Reporter: Leonardo Uribe
Assignee: Martin Marinschek
Fix For: 1.2.1-SNAPSHOT
Attachments: patchBigIntegerBigDecimal.patch
When you have this code:
%@ page session=false contentType=text/html;charset=utf-8%
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h%
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%
html
f:view
[EMAIL PROTECTED] file=inc/head.inc%
body
f:loadBundle
basename=org.apache.myfaces.examples.resource.example_messages
var=example_messages /
h1Myfaces Examples JSF 1.2 Additions/h1
h:messages/h:messages
h:form id=form
h:panelGrid id=grid columns=3
h:outputLabel value=BigInt
for=bigint/h:outputLabel
h:inputText id=bigint
value=#{convertBigBean.bigint}
f:converter
converterId=javax.faces.BigInteger /
/h:inputText
h:message for=bigint/h:message
h:outputLabel value=BigDecimal
for=bigdecimal/h:outputLabel
h:inputText id=bigdecimal
value=#{convertBigBean.bigdecimal}
f:converter
converterId=javax.faces.BigDecimal /
/h:inputText
h:message for=bigdecimal/h:message
/h:panelGrid
h:commandButton id=button1 value=press me action=update
/
/h:form
/body
/f:view
/html
And the backing bean looks like follows:
package org.apache.myfaces.convertbig;
import java.math.BigDecimal;
import java.math.BigInteger;
public class ConvertBigBean {
private BigInteger bigint;
private BigDecimal bigdecimal;
public BigInteger getBigint() {
return bigint;
}
public void setBigint(BigInteger bigint) {
this.bigint = bigint;
}
public BigDecimal getBigdecimal() {
return bigdecimal;
}
public void setBigdecimal(BigDecimal bigdecimal) {
this.bigdecimal = bigdecimal;
}
}
The code works but if you remove the lines:
f:converter converterId=javax.faces.BigInteger /
and
f:converter converterId=javax.faces.BigDecimal /
works in JSF RI 1.2 but not on Myfaces 1.2.
This issue is related with MYFACES-1260 JSR-252 Issue #13: Specified by
type converter registration for BigDecimal and BigInteger, but this is closed
so I open a new issue. The solution is simple, just add the following:
converter
converter-for-classjava.math.BigDecimal/converter-for-class
converter-classjavax.faces.convert.BigDecimalConverter/converter-class
/converter
and
converter
converter-for-classjava.math.BigInteger/converter-for-class
converter-classjavax.faces.convert.BigIntegerConverter/converter-class
/converter
to the files BigInteger.xml and BigDecimal.xml of myfaces-build project on
1.2 branch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1749) Performance Improvements
[ https://issues.apache.org/jira/browse/MYFACES-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Marinschek updated MYFACES-1749: --- Resolution: Fixed Assignee: Martin Marinschek Status: Resolved (was: Patch Available) Thanks to Michael Kurz for this important patch. regards, Martin Performance Improvements Key: MYFACES-1749 URL: https://issues.apache.org/jira/browse/MYFACES-1749 Project: MyFaces Core Issue Type: Improvement Affects Versions: 1.2.1-SNAPSHOT Reporter: Michael Kurz Assignee: Martin Marinschek Fix For: 1.2.1-SNAPSHOT Attachments: myfaces1749-patch.zip Last week I did some JMeter testing, profiling and code checking on MyFaces to try increase the overall performance. Here are my suggestions for improvement: *) _ComponentAttributesMap I introduced a cache for maps with component attributes. This cache avoids rebuilding the map for every instance of the same component class. It is implemented using a WeakHashMap to allow the GC to remove entries that are not referenced in any instance. *) UIComponentBase Made a few changes in isIdValid as it is called quite often. The new id is now checked against the old id and if it is the same it is assumed as valid (avoids checking chars). Additionally I use isLetterOrDigit() and access string chars directly insted of fetching an array first. *) ImplicitObjectResolver I replaced List with Map to avoid iteration over lists. *) HtmlResponseWriterImpl Use new method of HTMLEncoder for char[] *) HTMLEncoder Improved performance of encode mthod and added a new one that takes a char[] und directly writes to a writer. *) UnicodeEncoder Replaced StringBuffer with StringBuilder. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1746) Properties not set in UIComponentTag.createComponent()
[
https://issues.apache.org/jira/browse/MYFACES-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Marinschek updated MYFACES-1746:
---
Resolution: Fixed
Assignee: Mario Ivankovits
Status: Resolved (was: Patch Available)
Hi Michael,
thanks for this patch - as I took such a long time, Mario beat me to it and
committed a patch himself.
regards,
Martin
Properties not set in UIComponentTag.createComponent()
--
Key: MYFACES-1746
URL: https://issues.apache.org/jira/browse/MYFACES-1746
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.1-SNAPSHOT
Reporter: Michael Kurz
Assignee: Mario Ivankovits
Fix For: 1.2.1-SNAPSHOT
Attachments: myfaces-api-1746.patch
I ran into a problem with MyFaces 1.2.1-SNAPSHOT and Tomahawk 1.1.6. The
problem was that for t:commandButton id=cancel value=Cancel
action=#{aBean.cancel} / no value was rendered and that the action was not
working. With 1.2.0 it worked.
After some debugging I found out that setProperties() is not called in
UICompnentTag.createComponent(). In 1.2.0 setProperties was called in
UIComponentClassicTagBase.findComponent().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1684) myface 1.2 cant handle enum type
[
https://issues.apache.org/jira/browse/MYFACES-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Marinschek updated MYFACES-1684:
---
Resolution: Fixed
Assignee: Martin Marinschek (was: Matthias Weßendorf)
Status: Resolved (was: Patch Available)
thanks to Achim Hügen and Michael Kurz for providing patches. Special thanks
for providing tests as well. I love patches like this!
regards,
Martin
myface 1.2 cant handle enum type
Key: MYFACES-1684
URL: https://issues.apache.org/jira/browse/MYFACES-1684
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 1.2.1-SNAPSHOT
Environment: xp
Reporter: Dan Tran
Assignee: Martin Marinschek
Fix For: 1.2.1-SNAPSHOT
Attachments: myfaces-api-1684.patch, myfaces-impl-1684.patch,
myfaces1684-patch-new.zip
I switch my jsf 1.2 from ri to myfaces 1.2.0 and run in this issue
java.lang.IllegalArgumentException: Value is no String
(class=com.iplocks.model.domain.target.DatabaseType, value=DB27) and
component databaseSearchForm:j_id25with path: {Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId: /database/search.xhtml][Class:
javax.faces.component.html.HtmlForm,Id: databaseSearchForm][Class:
javax.faces.component.html.HtmlPanelGrid,Id: j_id22][Class:
javax.faces.component.html.HtmlPanelGrid,Id: j_id23][Class:
javax.faces.component.html.HtmlSelectOneMenu,Id: j_id25]} does not have a
Converter
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getConvertedStringValue(RendererUtils.java:560)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1741) JSR-252 Issue 21 - Provided an additional binding attribute for the core Converter, Listener and Validator tags has wrong behaviour
[
https://issues.apache.org/jira/browse/MYFACES-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537907
]
Martin Marinschek commented on MYFACES-1741:
As soon as you have a patch ready (with documentation), I'll take a look at it.
I haven't looked to deep into the spec with regards to this binding attribute
on converters/validators so far.
regards,
Martin
JSR-252 Issue 21 - Provided an additional binding attribute for the core
Converter, Listener and Validator tags has wrong behaviour
-
Key: MYFACES-1741
URL: https://issues.apache.org/jira/browse/MYFACES-1741
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.0
Environment: Tomcat 6.0.14, Myfaces 1.2.1-SNAPSHOT (Oct 7 2007)
Reporter: Leonardo Uribe
Fix For: 1.2.1-SNAPSHOT
There is a problem with the behaviour of binding attribute from
actionListeners, validators and converters.
I have this test. The objective is explore how binding attribute is doing
things comparing jsf ri 1.2 and
myfaces 1.2.1-SNAPSHOT, trying to detect bugs on myfaces :)
bindingCLV.jsp
%@ page session=false contentType=text/html;charset=utf-8%
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h%
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%
html
f:view beforePhase=#{bindingCLVBean.beforePhase}
afterPhase=#{bindingCLVBean.afterPhase}
[EMAIL PROTECTED] file=inc/head.inc%
body
f:loadBundle
basename=org.apache.myfaces.examples.resource.example_messages
var=example_messages /
h1Myfaces Examples JSF 1.2 Additions/h1
h:messages/h:messages
h:form id=form
h:panelGrid id=grid columns=3
h:outputLabel value=BigInt
for=bigint/h:outputLabel
h:inputText id=bigint
binding=#{bindingCLVBean.input1} value=#{bindingCLVBean.bigint}
f:converter
converterId=javax.faces.BigInteger
binding=#{bindingCLVBean.converterBigint}/
f:validator
validatorId=org.apache.myfaces.bindingCLV.DummyValidator
binding=#{bindingCLVBean.validatorBigint}/
/h:inputText
h:message for=bigint/h:message
h:outputLabel value=BigDecimal
for=bigdecimal/h:outputLabel
h:inputText id=bigdecimal
binding=#{bindingCLVBean.input2} value=#{bindingCLVBean.bigdecimal}
f:converter
converterId=javax.faces.BigDecimal
binding=#{bindingCLVBean.converterBigdecimal}/
f:validator
validatorId=org.apache.myfaces.bindingCLV.DummyValidator
binding=#{bindingCLVBean.validatorBigdecimal}/
/h:inputText
h:message for=bigdecimal/h:message
/h:panelGrid
h:commandButton id=button1 value=press me
action=#{bindingCLVBean.update}
f:actionListener
type=org.apache.myfaces.bindingCLV.DummyActionListener
binding=#{bindingCLVBean.listener} /
/h:commandButton
/h:form
/body
/f:view
/html
Bean:
package org.apache.myfaces.bindingCLV;
import java.math.BigDecimal;
import java.math.BigInteger;
import javax.faces.application.FacesMessage;
import javax.faces.component.html.HtmlInputText;
import javax.faces.context.FacesContext;
import javax.faces.convert.Converter;
import javax.faces.event.ActionListener;
import javax.faces.event.PhaseEvent;
import javax.faces.validator.Validator;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public class BindingCLVBean {
private BigInteger bigint;
private BigDecimal bigdecimal;
private Converter converterBigint;
private Converter converterBigdecimal;
private Validator validatorBigint;
private Validator validatorBigdecimal;
private HtmlInputText input1;
private HtmlInputText input2;
private ActionListener listener;
Log log = LogFactory.getLog(BindingCLVBean.class);
public void beforePhase(PhaseEvent phaseEvent){
FacesContext facesContext = FacesContext.getCurrentInstance();
facesContext.addMessage(null, new FacesMessage(This is the
message for phase before +phaseEvent.getPhaseId().toString()));
facesContext.addMessage(null, new
FacesMessage(Component:+this.getInput1()));
[jira] Commented: (TOMAHAWK-1031) links from sortable table are not working (with TRINIDAD)
[
https://issues.apache.org/jira/browse/TOMAHAWK-1031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537916
]
Martin Marinschek commented on TOMAHAWK-1031:
-
Hi Leonardo,
I'm still not sure about this. Maybe you could try to explain to me why it
doesn't work with Trinidad (a bit more into detail than right now, with exactly
what happens where in the lifecycle), and then we can find a solution together?
regards,
Martin
links from sortable table are not working (with TRINIDAD)
-
Key: TOMAHAWK-1031
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1031
Project: MyFaces Tomahawk
Issue Type: Bug
Environment: windows xp, jboss 4.2.0.GA
Reporter: Leonardo Uribe
Attachments: patch2.patch, patch9sortColumnAscending1.patch
When you mix trinidad and tomahawk CommandSortHeader component it not works.
I believe that I have found the reason. Take a look at this code
(please note only the part where _sortColumn and _sortAscending is set to
null):
/**
* Specify what column the data should be sorted on.
* p/
* Note that calling this method iimmediately/i stores the value
* via any value-binding with name sortColumn. This is done because
* this method is called by the HtmlCommandSortHeader component when
* the user has clicked on a column's sort header. In this case, the
* the model getter method mapped for name value needs to read this
* value in able to return the data in the desired order - but the
* HtmlCommandSortHeader component is usually immediate in order to
* avoid validating the enclosing form. Yes, this is rather hacky -
* but it works.
*/
public void setSortColumn(String sortColumn)
{
_sortColumn = sortColumn;
// update model is necessary here, because processUpdates is never
called
// reason: HtmlCommandSortHeader.isImmediate() == true
ValueBinding vb = getValueBinding(sortColumn);
if (vb != null)
{
vb.setValue(getFacesContext(), _sortColumn);
_sortColumn = null;
}
setSortColumnIndex(columnNameToIndex(sortColumn));
}
public String getSortColumn()
{
if (_sortColumn != null) return _sortColumn;
ValueBinding vb = getValueBinding(sortColumn);
return vb != null ? (String) vb.getValue(getFacesContext()) : null;
}
public void setSortAscending(boolean sortAscending)
{
_sortAscending = Boolean.valueOf(sortAscending);
// update model is necessary here, because processUpdates is never
called
// reason: HtmlCommandSortHeader.isImmediate() == true
ValueBinding vb = getValueBinding(sortAscending);
if (vb != null)
{
vb.setValue(getFacesContext(), _sortAscending);
_sortAscending = null;
}
}
public boolean isSortAscending()
{
if (_sortAscending != null)
return _sortAscending.booleanValue();
ValueBinding vb = getValueBinding(sortAscending);
Boolean v = vb != null ? (Boolean) vb.getValue(getFacesContext()) :
null;
return v != null ? v.booleanValue() : DEFAULT_SORTASCENDING;
}
If you set _sortColumn and _sortAscending variables to null, when this method
is executed:
public Object saveState(FacesContext context)
{
/*...*/
values[5] = _sortColumn;
values[6] = _sortAscending;
/*...*/
}
the variables are saved as null!! (but the ValueBinding no)
If you remove this lines:
_sortColumn = null;
and
_sortAscending = null;
I probe it and it works well ( I think that this error is related to
TOMAHAWK-457)
Trinidad use its own StateManager impl. So I believe that this is the reason
of TOMAHAWK-457 (RI has a different StateManagerImpl).
But I'm not sure if this should be done or something like this:
_sortColumn =
getValueBinding(sortColumn).getValue(getFacesContext());
What do you think in order to create a properly patch
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1742) Improved ViewState handling
[ https://issues.apache.org/jira/browse/MYFACES-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Marinschek updated MYFACES-1742: --- Resolution: Fixed Assignee: Martin Marinschek Status: Resolved (was: Patch Available) Thanks to Michael Kurz for providing this patch. regards, Martin Improved ViewState handling --- Key: MYFACES-1742 URL: https://issues.apache.org/jira/browse/MYFACES-1742 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 1.2.0, 1.2.1-SNAPSHOT Reporter: Michael Kurz Assignee: Martin Marinschek Priority: Minor Fix For: 1.2.1-SNAPSHOT Attachments: viewstate-patch-1.2.1.zip I improved the performance of the view state writing in MyFaces 1.2.1 quite a bit with the following 2 changes: 1) The algorithm for replacing the form state marker in JspViewHandlerImpl is much faster now (improved indexOf, buffered writing, StringBuilder) 2) The view state can now be rendered with javascript. If this feature is enabled (via context parameter org.apache.myfaces.VIEWSTATE_JAVASCRIPT) the view state hidden inputs in the forms are rendered with empty value attributes. The actual viewstate is then filled in on the client with a rendered javascript function that simply iterates over all forms. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1664) JSR-301 Implementation
[ https://issues.apache.org/jira/browse/MYFACES-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Marinschek updated MYFACES-1664: --- Resolution: Fixed Assignee: Martin Marinschek Status: Resolved (was: Patch Available) Initial commit completed. regards, Martin JSR-301 Implementation -- Key: MYFACES-1664 URL: https://issues.apache.org/jira/browse/MYFACES-1664 Project: MyFaces Core Issue Type: New Feature Components: Portlet_Support Affects Versions: 1.2.0-SNAPSHOT Environment: JSR-168, JSF 1.2 Reporter: Scott O'Bryan Assignee: Martin Marinschek Attachments: jsf-portlet-bridge.zip, jsf-portlet-bridge.zip.md5, jsf-portlet-bridge.zip.sha1 MyFaces 1.2 does not currently have a JSR-301 subproject. Work should begin on JSR-301 as bridge support for the MyFaces 1.2 branch. Trinidad is currently dependant on this project for bridge support and other Renderkits may wish to use this standards based bridge as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1748) facesContext.getExternalContext().encodeActionURL must not be called for URLs from the ViewHandler
[ https://issues.apache.org/jira/browse/MYFACES-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Marinschek resolved MYFACES-1748. Resolution: Invalid Assignee: Scott O'Bryan facesContext.getExternalContext().encodeActionURL must not be called for URLs from the ViewHandler -- Key: MYFACES-1748 URL: https://issues.apache.org/jira/browse/MYFACES-1748 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.5 Environment: Portlet environment using a WSRP portlet implemented with MyFaces Reporter: Dirk Schaube Assignee: Scott O'Bryan In org.apache.myfaces.shared_impl.renderkit.html.HtmlFormRendererBase.encodeBegin (and maybe other classes rendering action URLs) you find the following code segment: String actionURL = getActionUrl(facesContext, htmlForm); ... writer.writeURIAttribute(HTML.ACTION_ATTR, facesContext.getExternalContext().encodeActionURL(actionURL), null); and the method getActionUrl in HtmlRenderer says: return viewHandler.getActionURL(facesContext, viewId); So what's wrong with it? The Method viewHandler.getActionURL returns a URL that is suitable for rendering (see the JavaDoc). This URL may not be a normal URL as in my case with a wsrp portlet rendered on the producer server where the URL look like this: wsrp_rewrite?wsrp-urlType=blockingActionwsrp-mode=wsrp%3Aview... If you call encodeActionURL with such a URL the method javax.portlet.PortletResponse.encodeURL(url) is called. This method checks for either an absolute URL or full path URI. As both is not the case here, I get a IllegalArgumentException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1748) facesContext.getExternalContext().encodeActionURL must not be called for URLs from the ViewHandler
[ https://issues.apache.org/jira/browse/MYFACES-1748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537224 ] Martin Marinschek commented on MYFACES-1748: Can I clarify a little more? MyFaces is correct here, your bridge implementation is wrong. You should file an issue with the creators of the bridge. regards, Martin facesContext.getExternalContext().encodeActionURL must not be called for URLs from the ViewHandler -- Key: MYFACES-1748 URL: https://issues.apache.org/jira/browse/MYFACES-1748 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.1.5 Environment: Portlet environment using a WSRP portlet implemented with MyFaces Reporter: Dirk Schaube In org.apache.myfaces.shared_impl.renderkit.html.HtmlFormRendererBase.encodeBegin (and maybe other classes rendering action URLs) you find the following code segment: String actionURL = getActionUrl(facesContext, htmlForm); ... writer.writeURIAttribute(HTML.ACTION_ATTR, facesContext.getExternalContext().encodeActionURL(actionURL), null); and the method getActionUrl in HtmlRenderer says: return viewHandler.getActionURL(facesContext, viewId); So what's wrong with it? The Method viewHandler.getActionURL returns a URL that is suitable for rendering (see the JavaDoc). This URL may not be a normal URL as in my case with a wsrp portlet rendered on the producer server where the URL look like this: wsrp_rewrite?wsrp-urlType=blockingActionwsrp-mode=wsrp%3Aview... If you call encodeActionURL with such a URL the method javax.portlet.PortletResponse.encodeURL(url) is called. This method checks for either an absolute URL or full path URI. As both is not the case here, I get a IllegalArgumentException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-1751) encodeChildren in Renderer-base-class is wrongly implemented
encodeChildren in Renderer-base-class is wrongly implemented Key: MYFACES-1751 URL: https://issues.apache.org/jira/browse/MYFACES-1751 Project: MyFaces Core Issue Type: Bug Components: JSR-127, JSR-252 Affects Versions: 1.2.0, 1.1.5, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.1.0 Reporter: Martin Marinschek Assignee: Martin Marinschek Priority: Critical Fix For: 1.1.6-SNAPSHOT, 1.2.1-SNAPSHOT encodeChildren is wrongly implemented - calls encodeChildren if getRendersChildren() returns true. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-1751) encodeChildren in Renderer-base-class is wrongly implemented
[ https://issues.apache.org/jira/browse/MYFACES-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Marinschek resolved MYFACES-1751. Resolution: Fixed encodeChildren in Renderer-base-class is wrongly implemented Key: MYFACES-1751 URL: https://issues.apache.org/jira/browse/MYFACES-1751 Project: MyFaces Core Issue Type: Bug Components: JSR-127, JSR-252 Affects Versions: 1.1.0, 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.2.0 Reporter: Martin Marinschek Assignee: Martin Marinschek Priority: Critical Fix For: 1.1.6-SNAPSHOT, 1.2.1-SNAPSHOT encodeChildren is wrongly implemented - calls encodeChildren if getRendersChildren() returns true. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1733) [Seam] Server-side state saving not working correctly
[ https://issues.apache.org/jira/browse/MYFACES-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Marinschek updated MYFACES-1733: --- Resolution: Fixed Fix Version/s: 1.2.1-SNAPSHOT 1.1.6-SNAPSHOT Assignee: Martin Marinschek Status: Resolved (was: Patch Available) Thanks to Michael Kurz for fixing this (please checkout the 1.2 head, if my change there works properly as well). regards, Martin [Seam] Server-side state saving not working correctly - Key: MYFACES-1733 URL: https://issues.apache.org/jira/browse/MYFACES-1733 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.6-SNAPSHOT Reporter: Stephen Friedrich Assignee: Martin Marinschek Priority: Critical Fix For: 1.1.6-SNAPSHOT, 1.2.1-SNAPSHOT Attachments: jira1733-patch.zip Sometimes when using server-side state-saving some state is fixed and won't ever update. I don't know how exactly this is caused, but it occurs a lot when using JBoss Seam. It is consensus in the Seam community not to ever use myfaces with server-side state saving or even better not to use myfaces, but the RI instead. Here is how to reproduce reliably with one of the Seam example applications: - download and unzip tomcat 5.5. - download and unzip JBoss Seam 1.2.1. - edit seam-install-folder/build.properties and specify the path to tomcat - edit seam-install-folder/examples/seampay/resources/WEB-INF/web.xml and change state saving method to server. - run ant deploy.tomcat from seam-install-folder/examples/seampay/ - open http://localhost:8080/jboss-seam-pay - try to click on different accounts. = Only the first selection ever will make it. All others are ignored. Change back to client side state saving and everything works ok. I tried to look into this, but I am way over my head here with the internals of JSF and MyFaces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1733) [Seam] Server-side state saving not working correctly
[ https://issues.apache.org/jira/browse/MYFACES-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534371 ] Martin Marinschek commented on MYFACES-1733: Well, in any case, the wording of the spec, taken exactly as it is written, leads to this behaviour here - even though the intent is very clear, and the fix is of course correct. Thanks to Michael Kurz for sorting this out. regards, Martin [Seam] Server-side state saving not working correctly - Key: MYFACES-1733 URL: https://issues.apache.org/jira/browse/MYFACES-1733 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.6-SNAPSHOT Reporter: Stephen Friedrich Priority: Critical Attachments: jira1733-patch.zip Sometimes when using server-side state-saving some state is fixed and won't ever update. I don't know how exactly this is caused, but it occurs a lot when using JBoss Seam. It is consensus in the Seam community not to ever use myfaces with server-side state saving or even better not to use myfaces, but the RI instead. Here is how to reproduce reliably with one of the Seam example applications: - download and unzip tomcat 5.5. - download and unzip JBoss Seam 1.2.1. - edit seam-install-folder/build.properties and specify the path to tomcat - edit seam-install-folder/examples/seampay/resources/WEB-INF/web.xml and change state saving method to server. - run ant deploy.tomcat from seam-install-folder/examples/seampay/ - open http://localhost:8080/jboss-seam-pay - try to click on different accounts. = Only the first selection ever will make it. All others are ignored. Change back to client side state saving and everything works ok. I tried to look into this, but I am way over my head here with the internals of JSF and MyFaces. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-1712) FacesListeners get added to components twice causing event to be raised twice.
[
https://issues.apache.org/jira/browse/MYFACES-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Marinschek updated MYFACES-1712:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
Thanks to Thomas Fischer for this fix - and special thanks for reading the spec
very carefully.
We need contributors like you!
regards,
Martin
FacesListeners get added to components twice causing event to be raised twice.
--
Key: MYFACES-1712
URL: https://issues.apache.org/jira/browse/MYFACES-1712
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.2.0
Environment: Windows XP, Tomcat 6.0, jdk6, MyFaces 1.2.0, Tomahawk
1.1.5
Reporter: Andrew Redman
Assignee: Martin Marinschek
Fix For: 1.2.1-SNAPSHOT
Attachments: myfaces-1712-patch.txt
On components that have an actionListener set or valueChangeListener, these
listeners are added to the component instance twice. At runtime this causes
the method to be called with the event twice. For example I have the
following component
h:selectOneMenu id=Applications onchange=submit()
valueChangeListener=#{EditPage.processApplicationChange}
my processApplicationChange method is invoke twice.
I have tracked this down the UIComponentELTag and UIComponentClassicTagBase
classes. The UIComponentClassicTagBase calls createComponent in the
findComponent method and then calls setProperties. However the
createComponent method that is implemented in UIComponentELTag also calls
setProperties. The setProperties routine is what adds any listeners to a
collection. Therefore they get added twice. By removing the setProperties in
UIComponentELTag createComponent and leaving it up to the findComponent
method fixes the issue. I'm not sure however if this will have other
implications although as yet I have found no issues.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
