RE: [orchestra] latest code in core project is not JDK 1.4 compatible
Hi! Even if you advertised at the beginning, I too think that JDK 1.4 compatibility is no longer a must. Merging core15 might then be the logical step. Are you going to volunteer? ;-) Ciao, Mario Von: Leonardo Uribe [mailto:lu4...@gmail.com] Gesendet: Mittwoch, 14. Oktober 2009 01:21 An: MyFaces Development Betreff: [orchestra] latest code in core project is not JDK 1.4 compatible Hi Checking some stuff in orchestra, I have seen that some code in core project is not JDK 1.4 compatible. The question is given JDK 1.4 has reached its end of service life, shouldn't we move forward and make orchestra JDK 1.5 and upper compatible? That means also merge core15 code with core. Note that if this is not true, we have to change/revert some code already committed to make it JDK 1.4 compatible (for example, do not make the call to ThreadLocal.remove() on FrameworkAdapter). regards Leonardo Uribe
Re: [orchestra] latest code in core project is not JDK 1.4 compatible
2009/10/14 Mario Ivankovits ma...@ops.co.at Hi! Even if you advertised at the beginning, I too think that JDK 1.4 compatibility is no longer a must. Merging core15 might then be the logical step. Are you going to volunteer? ;-) Hi Mario Yes, sure!. I'll do it, no problem. regards Leonardo Uribe Ciao, Mario *Von:* Leonardo Uribe [mailto:lu4...@gmail.com] *Gesendet:* Mittwoch, 14. Oktober 2009 01:21 *An:* MyFaces Development *Betreff:* [orchestra] latest code in core project is not JDK 1.4 compatible Hi Checking some stuff in orchestra, I have seen that some code in core project is not JDK 1.4 compatible. The question is given JDK 1.4 has reached its end of service life, shouldn't we move forward and make orchestra JDK 1.5 and upper compatible? That means also merge core15 code with core. Note that if this is not true, we have to change/revert some code already committed to make it JDK 1.4 compatible (for example, do not make the call to ThreadLocal.remove() on FrameworkAdapter). regards Leonardo Uribe
[jira] Created: (MYFACES-2380) DefaultRestoreViewSupport.calculateViewId does not calculate viewId properly on portlet case
DefaultRestoreViewSupport.calculateViewId does not calculate viewId properly on portlet case Key: MYFACES-2380 URL: https://issues.apache.org/jira/browse/MYFACES-2380 Project: MyFaces Core Issue Type: Bug Components: Portlet_Support Affects Versions: 1.2.7 Environment: liferay 5.2.3, myfaces portlet bridge 1.0.0-beta-2, myfaces core 1.2.7 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Testing the helloworld portlet archetype on liferay for many, many hours, I have seen a problem with the way it is resolved the view id In this configuration, the current algorithm resolves the view id using javax.servlet.include.path_info and javax.servlet.include.servlet_path But in portlet case, this values should not be taken into account. Instead, we have to check if this is a portlet request or not (it seems javax.portlet.faces.PORTLET_LIFECYCLE_PHASE is used to check if is a portlet request or not) and call: org.apache.myfaces.portlet.faces.context.PortletExternalContextImpl.getRequestPathInfo() or getRequestContextPath() when necessary. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1585) Update the support for the Opera browser.
[ https://issues.apache.org/jira/browse/TRINIDAD-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Yvanovich updated TRINIDAD-1585: - Status: Patch Available (was: Open) Update the support for the Opera browser. - Key: TRINIDAD-1585 URL: https://issues.apache.org/jira/browse/TRINIDAD-1585 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.2.12-core Environment: Opera browser Reporter: Mark Yvanovich Priority: Minor Attachments: trinidad1585_1_2_12_2.patch, trinidad1585trunk.patch Original Estimate: 24h Remaining Estimate: 24h Currently, the _populateOperaAgentImpl() method just sets the actual agent to gecko and sets the version number to the Opera version. This method needs to be updated so that Opera has its own agent type. This is needed to allow the Opera browser to be fully supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1585) Update the support for the Opera browser.
[ https://issues.apache.org/jira/browse/TRINIDAD-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Yvanovich updated TRINIDAD-1585: - Status: Open (was: Patch Available) Update the support for the Opera browser. - Key: TRINIDAD-1585 URL: https://issues.apache.org/jira/browse/TRINIDAD-1585 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.2.12-core Environment: Opera browser Reporter: Mark Yvanovich Priority: Minor Attachments: trinidad1585_1_2_12_2.patch, trinidad1585trunk.patch Original Estimate: 24h Remaining Estimate: 24h Currently, the _populateOperaAgentImpl() method just sets the actual agent to gecko and sets the version number to the Opera version. This method needs to be updated so that Opera has its own agent type. This is needed to allow the Opera browser to be fully supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1585) Update the support for the Opera browser.
[ https://issues.apache.org/jira/browse/TRINIDAD-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf resolved TRINIDAD-1585. -- Resolution: Fixed Fix Version/s: 1.2.13-core Assignee: Matthias Weßendorf Update the support for the Opera browser. - Key: TRINIDAD-1585 URL: https://issues.apache.org/jira/browse/TRINIDAD-1585 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.2.12-core Environment: Opera browser Reporter: Mark Yvanovich Assignee: Matthias Weßendorf Priority: Minor Fix For: 1.2.13-core Attachments: trinidad1585_1_2_12_2.patch, trinidad1585trunk.patch Original Estimate: 24h Remaining Estimate: 24h Currently, the _populateOperaAgentImpl() method just sets the actual agent to gecko and sets the version number to the Opera version. This method needs to be updated so that Opera has its own agent type. This is needed to allow the Opera browser to be fully supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: VOTE: jsf 2.0: should cyclic references in managed-bean custom scopes be detected?
Aggregation: +7 (+8 including myself) for the idea with the ProjectStage.
Because it really is not that much of work, I will include the cyclic
reference detection in my patch for MYFACES-2375.
Thank you all for your contribution and a special thanks to Michael Concini
for the idea with the project stage!
Regards,
Jakob
2009/10/13 Jan-Kees van Andel jankeesvanan...@gmail.com
+1, but it might be a lot of work. Maybe we should first get a
spec-compliant release out and plan this one for a second release.
/JK
2009/10/13 Gerhard Petracek gerhard.petra...@gmail.com:
+1 for the project stage idea
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2009/10/13 Werner Punz werner.p...@gmail.com
+1 as well for the project stage idea, the dev stage is definitely
the one which should track this but for production we need optimal
performance.
Werner
Kito Mann schrieb:
+1
On Tue, Oct 13, 2009 at 10:52 AM, Bruno Aranda brunoara...@gmail.com
mailto:brunoara...@gmail.com wrote:
+1 with the project stage sounds good to me!
2009/10/13 Simon Lessard simon.lessar...@gmail.com
mailto:simon.lessar...@gmail.com
+1 for the project stage idea.
On Tue, Oct 13, 2009 at 10:28 AM, Michael Concini
mconc...@gmail.com mailto:mconc...@gmail.com wrote:
What about using project stage to determine which behavior
to follow? If we're in production stage we don't check for
best performance, but in development/test stages we perform
the check.
Alternatively, could we at least make it configurable
through an org.apache.myfaces param in web.xml so apps that
have been fully tested can disable the check?
Thanks,
Mike
Jakob Korherr wrote:
Hi everbody.
While working on MYFACES-2375, I got stuck at the
following scenario:
Managed bean m1 has a custom scope #{m2.scope} and
managed bean m2 has a custom scope #{m1.scope}.
In this scenario you will get a StackOverflowException
when trying to create one of the two managed beans.
RI really ends in a StackOverflowException, should
MyFaces end in such a Exception too or detect the cyclic
reference and throw an ELException?
Mike Kienenberger told me the following: We have a
precedent set on making MyFaces proactive on detecting
error conditions in the configuration.
The only problem is, that checking the cyclic references
would not happen once at MyFaces startup, but every time
a managed bean will be created, which means it slows
down the application.
What is your opinion on this question?
Vote +1, if you think MyFaces should detect cyclic
references in the managed bean scope.
[jira] Commented: (MYFACES-2216) MyFaces suppresses runtime exceptions thrown in ActionListeners
[
https://issues.apache.org/jira/browse/MYFACES-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12765766#action_12765766
]
Kaeri Johnson commented on MYFACES-2216:
This issue is causing is great pains in production- is there a workaround or
fix being implemented?
MyFaces suppresses runtime exceptions thrown in ActionListeners
---
Key: MYFACES-2216
URL: https://issues.apache.org/jira/browse/MYFACES-2216
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.6, 1.2.7-SNAPSHOT
Environment: Tomcat 6.0.18, JRE 1.6.11
Reporter: Dirk Möbius
Have a look at the following stack trace when a custom ActionListener throws
an unhandled exception:
com.myproject.validation.ValidationException
at com.myproject.controller.MyController.validate(MyController.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.el.parser.AstValue.invoke(AstValue.java:172)
at
org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
at
org.apache.jasper.el.JspMethodExpression.invoke(JspMethodExpression.java:68)
at
javax.faces.event.MethodExpressionActionListener.processAction(MethodExpressionActionListener.java:49)
at javax.faces.event.ActionEvent.processListener(ActionEvent.java:51)
at
javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:554)
at javax.faces.component.UICommand.broadcast(UICommand.java:124)
at
javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:369)
at javax.faces.component.UIViewRoot.process(UIViewRoot.java:264)
at
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:153)
at
org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
at
org.apache.myfaces.custom.ppr.PPRLifecycleWrapper.execute(PPRLifecycleWrapper.java:68)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:151)
In MethodExpressionActionListener.processAction(ActionEvent), any exception
is wrapped into an AbortProcessingException:
public void processAction(ActionEvent actionEvent) throws
AbortProcessingException {
try {
Object[] params = new Object[]{actionEvent};
methodExpression.invoke(elContext(), params);
} catch (Exception e) {
throw new AbortProcessingException(e);
}
}
Deeper down in the stack trace, any AbortProcessingException is silently
ignored in method UIViewRoot.__broadcastForPhase(PhaseId phaseId) :
private void _broadcastForPhase(PhaseId phaseId) {
...
try
{
source.broadcast(event);
}
catch (AbortProcessingException e)
{
// abort event processing
// Page 3-30 of JSF 1.1 spec: Throw an
// AbortProcessingException, to tell the JSF
implementation
// that no further broadcast of this event, or any further
// events, should take place.
abort = true;
break;
}
...
}
Mojarra logs the exception at least (twice, in fact). But IMHO unhandled
exceptions should make it to the top-level to be handled by custom error
handlers or phase listeners. The spec is not explicit about unhandled
exceptions in ActionListeners. Sec 3.4.7 (Event broadcasting) simply states:
During event broadcasting, a listener processing an event may:
* Examine or modify the state of any component in the component tree.
* Add or remove components from the component tree.
* Add messages to be returned to the user, by calling addMessage on the
FacesContext instance for the current request.
* Queue one or more additional events, from the same source component or a
different one,
for processing during the current lifecycle phase.
* Throw an AbortProcessingException, to tell the JSF implementation that no
further broadcast of this event, or any further events, should take place.
* Call renderResponse() on the FacesContext instance for the current
request.[...]
* Call responseComplete() on the FacesContext instance for the current
Re: VOTE: jsf 2.0: should cyclic references in managed-bean custom scopes be detected?
Hi *, Thank you all for your contribution and a special thanks to Michael Concini for the idea with the project stage! indeed a very good idea. Ed will love to see that his ProjectStage is getting some more usage ;). regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
