[jira] Commented: (MYFACES-1794) MF Core causes resources not found(404) errors (recently also corrected in Sun RI for JSF 1.2)
[ https://issues.apache.org/jira/browse/MYFACES-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12784211#action_12784211 ] Tobias Eisenträger commented on MYFACES-1794: - I get the same problem with the calendar, but also in general when trying to use the dialog framework. I guess it is because i am using the .jspx ending with my facelets, so i cannot add context-param param-namejavax.faces.DEFAULT_SUFFIX/param-name param-value.jsp/param-value /context-param which helped for some. Could anyone try to fix this, please? Thanks MF Core causes resources not found(404) errors (recently also corrected in Sun RI for JSF 1.2) -- Key: MYFACES-1794 URL: https://issues.apache.org/jira/browse/MYFACES-1794 Project: MyFaces Core Issue Type: Bug Affects Versions: 1.2.0 Environment: JSF 1.2 (failures mostly happen with extensions like with Trinidad e.g.) Reporter: Wolf Benz Cf. the MF mailing list: topics like Dialog issue during ADF-Trinidad migration I came across it using tr:inputDate but in the list topic I mentioned above, so I first thought it was a Trinidad issue, but people more knowledgeable with the JSF spec(Adam Winer) pointed out it was a MF 1.2 core issue, and that the Sun RI had also sufferend from it, yet in the RI, this bug has recently been corrected. The error I got was when clicking the calendar icon and expecting a cal popup. Instead I got: description The requested resource (.../__ADFv__.jsp) is not available. As it potentially affects a lot of other components beyond this trinidad one, I marked it major as these components just don't work anymore. E.g. MF mailing list with topic RE: [Trinidad] HTTP 404 (file not found) while using DialogFramework points that out. --Wolf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Java EE 6 - Web Profile...
FYI: http://matthiaswessendorf.wordpress.com/2009/12/01/java-ee-6-the-web-profile/ I wonder what the Tomcat folks will do... Does one know if the plan to offer a bundle that meets the Web- Profile (Apache Tomcat 7 WP Edition) ? could contain: -MyFaces (of course) -OpenWebBean -OpenEJB etc... -M -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (MYFACES-2433) Variable name error in oamClearHiddenInput and oamSetHiddenInput: use formname instead of formName
Variable name error in oamClearHiddenInput and oamSetHiddenInput: use formname
instead of formName
--
Key: MYFACES-2433
URL: https://issues.apache.org/jira/browse/MYFACES-2433
Project: MyFaces Core
Issue Type: Bug
Components: JSR-252
Affects Versions: 1.2.8
Environment: MyFaces 1.2.8; Tomcat 6.0.18, Servlet 2.5, Java 1.6;
Firefox 3.3.5
Reporter: Lutz Ulruch
In MyFaces 1.2.8 in
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.prepareScript()
2 errors slipped into the script functions oamClearHiddenInput and
oamSetHiddenInput:
While trying to implement the workaround for document.forms[formname] not
finding any form after partial page rendering and replacement of HTML DOM
fragments including HTML forms (because of a bug (?) in Firefox) a test has
been added:
var form = document.forms[formname];
if ( typeof form == 'undefined')
{
form = document.getElementById(formName);
}
But in oamClearHiddenInput and oamSetHiddenInput the function parameter is
named 'formname' instead of 'formName' (only in oamSubmitForm is it named
'formName').
That's why
document.getElementById(formName)
does not work in both functions.
By the way: You probably fixed this due to the bug 2256 which I issued.
Except for those two copypaste erros it works and I want to thank you for the
fix.
Maybe one should not use
document.forms[formname]
and the test
if ( typeof form == 'undefined')
at all and just use
var form = document.getElementById(formname)
in order to keep the code simple.
But I do not know if you think this approach is to slow or maybe it does not
work in all browsers.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [MyFaces 2] Multiple children in facet
Hi, I'm pretty sure this was discussed on the EG list, so yeah it looks like a hole in the spec and Mojarra being right here. ~ Simon On Mon, Nov 30, 2009 at 6:28 PM, Michael Kurz michi.k...@gmx.at wrote: Hi, I have recently created a bunch of applications with Mojarra 2.0 that I'm currently trying to port to MyFaces 2.0. In Mojarra 2 it is possible to have more than one child in a facet (without enclosing them in a panel). So I thought this is part of the new spec. But when I noticed that this is not working in MyFaces 2.0 I checked the spec and found no such feature. Did I miss something, or is this a Mojarra-specific feature? regards Michael Kurz
Re: [MyFaces 2] Multiple children in facet
On Tue, Dec 1, 2009 at 4:02 PM, Simon Lessard simon.lessar...@gmail.com wrote: Hi, I'm pretty sure this was discussed on the EG list, so yeah it looks like a hole in the spec and Mojarra being right here. if there is (another) hole in the spec... please file a ticket for that. Otherwise issues like that will never be done in a unique manner ... -Matthias ~ Simon On Mon, Nov 30, 2009 at 6:28 PM, Michael Kurz michi.k...@gmx.at wrote: Hi, I have recently created a bunch of applications with Mojarra 2.0 that I'm currently trying to port to MyFaces 2.0. In Mojarra 2 it is possible to have more than one child in a facet (without enclosing them in a panel). So I thought this is part of the new spec. But when I noticed that this is not working in MyFaces 2.0 I checked the spec and found no such feature. Did I miss something, or is this a Mojarra-specific feature? regards Michael Kurz -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (MYFACES-2434) dummy request/response classes for system event listeners will break with Servlet 3.0
dummy request/response classes for system event listeners will break with Servlet 3.0 - Key: MYFACES-2434 URL: https://issues.apache.org/jira/browse/MYFACES-2434 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Michael Concini Assignee: Michael Concini Currently the _SystemEventServletRequest and _SystemEventServletResponse classes implement ServletRequest and ServletResponse directly. There are several new methods that must be implemented in the servlet 3.0 updates of those interfaces. This can be resolved by changing them to extend ServletRequestWrapper and ServletResponseWrapper instead of implementing directly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2434) dummy request/response classes for system event listeners will break with Servlet 3.0
[ https://issues.apache.org/jira/browse/MYFACES-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Concini resolved MYFACES-2434. -- Resolution: Fixed Fix Version/s: 2.0.0-alpha-2 dummy request/response classes for system event listeners will break with Servlet 3.0 - Key: MYFACES-2434 URL: https://issues.apache.org/jira/browse/MYFACES-2434 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Michael Concini Assignee: Michael Concini Fix For: 2.0.0-alpha-2 Currently the _SystemEventServletRequest and _SystemEventServletResponse classes implement ServletRequest and ServletResponse directly. There are several new methods that must be implemented in the servlet 3.0 updates of those interfaces. This can be resolved by changing them to extend ServletRequestWrapper and ServletResponseWrapper instead of implementing directly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [scripting extension] compile errors ?
eh...
myfaces_129_SNAPSHOT needs shared_308_SNAPSHOT
and scripting needs 129:SNAPSHOT
:-)
On Tue, Dec 1, 2009 at 7:57 PM, Matthias Wessendorf mat...@apache.org wrote:
Hello,
is it just me ? Or does the scripting module not compile for you as well ?
[INFO] Compilation failure
/home/matzew/work/source/javanight/extensions/core/core/src/main/java/org/apache/myfaces/scripting/servlet/CustomChainLoader.java:[26,42]
cannot find symbol
symbol : class ClassLoaderExtension
location: package org.apache.myfaces.shared_impl.util
/home/matzew/work/source/javanight/extensions/core/core/src/main/java/org/apache/myfaces/scripting/servlet/CustomChainLoader.java:[39,39]
cannot find symbol
symbol: class ClassLoaderExtension
public class CustomChainLoader extends ClassLoaderExtension {
/home/matzew/work/source/javanight/extensions/core/core/src/main/java/org/apache/myfaces/scripting/core/util/ClassUtils.java:[24,42]
cannot find symbol
symbol : class ClassLoaderExtension
location: package org.apache.myfaces.shared_impl.util
/home/matzew/work/source/javanight/extensions/core/core/src/main/java/org/apache/myfaces/scripting/core/util/ClassUtils.java:[166,48]
cannot find symbol
symbol : class ClassLoaderExtension
location: class org.apache.myfaces.scripting.core.util.ClassUtils
/home/matzew/work/source/javanight/extensions/core/core/src/main/java/org/apache/myfaces/scripting/servlet/StartupServletContextPluginChainLoader.java:[25,32]
cannot find symbol
symbol : class StartupListener
location: package org.apache.myfaces.webapp
/home/matzew/work/source/javanight/extensions/core/core/src/main/java/org/apache/myfaces/scripting/servlet/StartupServletContextPluginChainLoader.java:[35,63]
cannot find symbol
symbol: class StartupListener
public class StartupServletContextPluginChainLoader implements
StartupListener {
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
[core] 1.2.9-SNAPSHOT == updating shared ?
Hey, I wonder if one is against updating 1.2.9. to the latest greatest (SNAPSHOT) of shared? (= 3.0.8-SNAPSHOT) -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [scripting extension] compile errors ?
On Tue, Dec 1, 2009 at 8:22 PM, Matthias Wessendorf mat...@apache.org wrote:
eh...
myfaces_129_SNAPSHOT needs shared_308_SNAPSHOT
see here:
http://markmail.org/message/qpkfmfjv2t5aa62a
and scripting needs 129:SNAPSHOT
and here:
http://svn.apache.org/viewvc?view=revisionrevision=885883
:-)
On Tue, Dec 1, 2009 at 7:57 PM, Matthias Wessendorf mat...@apache.org wrote:
Hello,
is it just me ? Or does the scripting module not compile for you as well ?
[INFO] Compilation failure
/home/matzew/work/source/javanight/extensions/core/core/src/main/java/org/apache/myfaces/scripting/servlet/CustomChainLoader.java:[26,42]
cannot find symbol
symbol : class ClassLoaderExtension
location: package org.apache.myfaces.shared_impl.util
/home/matzew/work/source/javanight/extensions/core/core/src/main/java/org/apache/myfaces/scripting/servlet/CustomChainLoader.java:[39,39]
cannot find symbol
symbol: class ClassLoaderExtension
public class CustomChainLoader extends ClassLoaderExtension {
/home/matzew/work/source/javanight/extensions/core/core/src/main/java/org/apache/myfaces/scripting/core/util/ClassUtils.java:[24,42]
cannot find symbol
symbol : class ClassLoaderExtension
location: package org.apache.myfaces.shared_impl.util
/home/matzew/work/source/javanight/extensions/core/core/src/main/java/org/apache/myfaces/scripting/core/util/ClassUtils.java:[166,48]
cannot find symbol
symbol : class ClassLoaderExtension
location: class org.apache.myfaces.scripting.core.util.ClassUtils
/home/matzew/work/source/javanight/extensions/core/core/src/main/java/org/apache/myfaces/scripting/servlet/StartupServletContextPluginChainLoader.java:[25,32]
cannot find symbol
symbol : class StartupListener
location: package org.apache.myfaces.webapp
/home/matzew/work/source/javanight/extensions/core/core/src/main/java/org/apache/myfaces/scripting/servlet/StartupServletContextPluginChainLoader.java:[35,63]
cannot find symbol
symbol: class StartupListener
public class StartupServletContextPluginChainLoader implements
StartupListener {
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2428) Id generation for facelets cause problems with htmlunit 2.4 or lower
[ https://issues.apache.org/jira/browse/MYFACES-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12784372#action_12784372 ] Michael Kurz commented on MYFACES-2428: --- My original problem is fixed now, but I still have some id issues from time to time. I'll report back if I know more. Id generation for facelets cause problems with htmlunit 2.4 or lower Key: MYFACES-2428 URL: https://issues.apache.org/jira/browse/MYFACES-2428 Project: MyFaces Core Issue Type: Task Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe The id generation strategy is critical to allow partial state saving works correctly, because all component state is saved on a map, and the clientId is the primary key for it. Actually, we just pass the facelet generated id for each tag as a seed for UniqueIdVendor.createUniqueId(FacesContext context, java.lang.String seed), This id cause an exception in htmlunit version 2.4 or lower (in 2.5 this was fixed). The objective of UniqueIdVendor interface is reduce the variation when ids are generated. The ideal case is that for any facelet page the generated ids assigned to components should remain the same no matter if the model changes by some reason. The problem starts when it is used c:forEach or c:if tags, because its behavior depends on the model state in a point of the time. The id generated by facelets is depends on the facelet alias page name, a counter id from CompilationManager. We need to do multiple tests for worst case scenarios, and try to define an strategy to reduce the variability of ids, providing proper seeds for it. Suggestions are welcome -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2434) dummy request/response classes for system event listeners will break with Servlet 3.0
[
https://issues.apache.org/jira/browse/MYFACES-2434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12784383#action_12784383
]
Michael Kurz commented on MYFACES-2434:
---
There is a bug in the new code. I get a NullPointerException on starting my app
because of this code in AbstractFacesInitializer:
private void dispatchInitDestroyEvent(Object servletContext, Class eventClass) {
ApplicationFactory appFac = (ApplicationFactory)
FactoryFinder.getFactory(FactoryFinder.APPLICATION_FACTORY);
FacesContext fc = null;
fc = FacesContext.getCurrentInstance();
ExternalContext ec = fc.getExternalContext();
if (fc == null) {
...
In my case fc is null!
dummy request/response classes for system event listeners will break with
Servlet 3.0
-
Key: MYFACES-2434
URL: https://issues.apache.org/jira/browse/MYFACES-2434
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-alpha
Reporter: Michael Concini
Assignee: Michael Concini
Fix For: 2.0.0-alpha-2
Currently the _SystemEventServletRequest and _SystemEventServletResponse
classes implement ServletRequest and ServletResponse directly. There are
several new methods that must be implemented in the servlet 3.0 updates of
those interfaces.
This can be resolved by changing them to extend ServletRequestWrapper and
ServletResponseWrapper instead of implementing directly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (EXTVAL-74) marker for empty- and null-value aware validation strategies
marker for empty- and null-value aware validation strategies Key: EXTVAL-74 URL: https://issues.apache.org/jira/browse/EXTVAL-74 Project: MyFaces Extensions Validator Issue Type: Improvement Components: Property Validation Affects Versions: 1.1.2, 1.1.1, 1.2.2, 1.2.1 Reporter: Gerhard Petracek Priority: Minor it should be possible to explicitly mark validation strategies which are aware of empty- and null-values markers: @EmptyValueAwareValidationStrategy @NullAwareValidationStrategy all other validation strategies don't have to manually check/ignore these values -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2436) BeanValidator stops on null value (@NotNull not checked)
BeanValidator stops on null value (@NotNull not checked) Key: MYFACES-2436 URL: https://issues.apache.org/jira/browse/MYFACES-2436 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Michael Kurz Attachments: MYFACES-2436.patch BeanValidator does not validate if value is null. As a result it is not possible to check @NotNull. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2436) BeanValidator stops on null value (@NotNull not checked)
[ https://issues.apache.org/jira/browse/MYFACES-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Kurz updated MYFACES-2436: -- Status: Patch Available (was: Open) BeanValidator stops on null value (@NotNull not checked) Key: MYFACES-2436 URL: https://issues.apache.org/jira/browse/MYFACES-2436 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Michael Kurz Attachments: MYFACES-2436.patch BeanValidator does not validate if value is null. As a result it is not possible to check @NotNull. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2428) Id generation for facelets cause problems with htmlunit 2.4 or lower
[ https://issues.apache.org/jira/browse/MYFACES-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12784459#action_12784459 ] Leonardo Uribe commented on MYFACES-2428: - After doing some tests on this issue, use components that implements UniqueIdVendors to define ids cause more problems. The problem is that is expected that some components on the tree are relocated. We can fix h:outputScript and h:outputStylesheet, but we can't do anything clean with composite:insertChildren or composite:insertFacet, because in that case we could have nested and mixed declaration of it and since we need the tree built before start to move, in that case we need to regenerate ids for all components that has a generated id. I check again the problem with htmlunit and it starts with the addition of '-' char inside generated ids. It seems more simple to prevent the DefaultFaceletContext.generateUniqueId insert this chars by a simple call to Math.abs. Use the generated id based from the alias name and tag position in a page seems to be the best solution in this case. Id generation for facelets cause problems with htmlunit 2.4 or lower Key: MYFACES-2428 URL: https://issues.apache.org/jira/browse/MYFACES-2428 Project: MyFaces Core Issue Type: Task Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe The id generation strategy is critical to allow partial state saving works correctly, because all component state is saved on a map, and the clientId is the primary key for it. Actually, we just pass the facelet generated id for each tag as a seed for UniqueIdVendor.createUniqueId(FacesContext context, java.lang.String seed), This id cause an exception in htmlunit version 2.4 or lower (in 2.5 this was fixed). The objective of UniqueIdVendor interface is reduce the variation when ids are generated. The ideal case is that for any facelet page the generated ids assigned to components should remain the same no matter if the model changes by some reason. The problem starts when it is used c:forEach or c:if tags, because its behavior depends on the model state in a point of the time. The id generated by facelets is depends on the facelet alias page name, a counter id from CompilationManager. We need to do multiple tests for worst case scenarios, and try to define an strategy to reduce the variability of ids, providing proper seeds for it. Suggestions are welcome -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2436) BeanValidator stops on null value (@NotNull not checked)
[ https://issues.apache.org/jira/browse/MYFACES-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-2436: Resolution: Fixed Fix Version/s: 2.0.0-alpha-2 Assignee: Leonardo Uribe Status: Resolved (was: Patch Available) Thanks to Michael Kurz for this patch BeanValidator stops on null value (@NotNull not checked) Key: MYFACES-2436 URL: https://issues.apache.org/jira/browse/MYFACES-2436 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Michael Kurz Assignee: Leonardo Uribe Fix For: 2.0.0-alpha-2 Attachments: MYFACES-2436.patch BeanValidator does not validate if value is null. As a result it is not possible to check @NotNull. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[tomahawk] start new module of tomahawk for jsf 2.0
Hi I think this is a good time to discuss and start a new module of tomahawk for jsf 2.0. We have now an alpha release of myfaces core 2.0, so we have myfaces-metadata.xml for chain the necessary metadata to compile tomahawk. Note that tomahawk depends on this metadata for build some config files, so to keep things simple it was preferred to do an alpha release of core before start this module. Below there is a list of ideas that will be taken into account. 1. All tomahawk components should implement the new partial state saving api. We could use the template used to compile myfaces for that. 2. Since we have a new ResourceHandler api, should we use it to server resources used by components? In theory yes, but still we need to use ExtensionsFilter to support fileupload. 3. How should we deal with the different javascript libraries used by tomahawk components? What naming convention use (to prevent collisions with other libs packing javascript libs on its jar)? maybe something like oam_dojo or tomahawk_[libraryname]. 4. t:aliasBean should use the new hack to deal with binding (see MYFACES-2364). 5. How to deal with facelets code? In theory, facelets dependency should be removed and all tag handlers should use javax.faces.view classes instead. 6. Since javascript api is now provided, it could be good to update some old javascript api used. Also, it could be good to use the new resource api to load resources. In few words, tomahawk must remain as close with the spec as possible. 7. Tomahawk sandbox could be a place to store new composite components added by developers. Suggestions are welcome. regards Leonardo Uribe
[orchestra] could we do a release of this artifacts?
Hi I would like to add a module for orchestra and jsf 2.0 and do a release of orchestra in the next days. Is any special step required to do it? or there is some issue that needs to be solved before release it? regards, Leonardo Uribe
[jira] Reopened: (TRINIDAD-1417) partialTriggers does not take String value
[ https://issues.apache.org/jira/browse/TRINIDAD-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Robinson reopened TRINIDAD-1417: --- Assignee: (was: Matthias Weßendorf) Re-opening but will change it from a bug to a wish item as I believe it would be very useful to convert String to String[] at the component level instead of the tag level so that EL that points to a string or a string with EL in it will also be split into an array. partialTriggers does not take String value -- Key: TRINIDAD-1417 URL: https://issues.apache.org/jira/browse/TRINIDAD-1417 Project: MyFaces Trinidad Issue Type: Bug Components: Components, Facelets Affects Versions: 1.2.10-core Environment: Facelets 1.1.14, Trinidad 1.2.10, MyFaces core 1.2.4, Glassfish v2 Reporter: Bart Kummel When using the partialTriggers attribute, it does not take a literal String (even if it only contains a single id). The only way to get partialTriggers to work is to use a EL expression that returns a String[]. When using a literal string, I get the following exception: java.lang.IllegalArgumentException: Cannot convert selectedReaction of type class java.lang.String to class [Ljava.lang.String; I see some relation with bug #TRINIDAD-60. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2423) h:dataTable renderer does not support colgroups facet
[ https://issues.apache.org/jira/browse/MYFACES-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr updated MYFACES-2423: --- Status: Patch Available (was: Open) h:dataTable renderer does not support colgroups facet - Key: MYFACES-2423 URL: https://issues.apache.org/jira/browse/MYFACES-2423 Project: MyFaces Core Issue Type: Task Components: JSR-314 Reporter: Leonardo Uribe Attachments: myfaces-2423.patch On the javadoc of h:dataTable, it says: Column Groups If the UIData component has a colgroups facet, render its contents. Consistent with the rules of facets in general, this facet must have only one child. In general, this will be a panel group component that will contain colgroup and col elements per the HTML Table specification. Use of column grouping can improve accessibility. This facet must be rendered before the table header and footer.. Since it is not marked with green or orange, we just skip it, but it is a new feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [core] 1.2.9-SNAPSHOT == updating shared ?
Hi I usually update shared to its next snapshot version when it is necessary to do some change in shared. In this way if shared has no changes between core release, we know in a simple way when generate this artifacts or not. There is a bug (MYFACES-2433) that affects shared and could be solved on the next release of core 1.2.x, so there is no problem if we update to the latest greatest one. regards Leonardo Uribe 2009/12/1 Matthias Wessendorf mat...@apache.org Hey, I wonder if one is against updating 1.2.9. to the latest greatest (SNAPSHOT) of shared? (= 3.0.8-SNAPSHOT) -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [MyFaces 2.0] how to handle _SystemEventServletRequest and _SystemEventServletResponse classes (attn:Werner)
2009/12/1 Matthias Wessendorf mwessend...@gmail.com Sent from my iPod. On 01.12.2009, at 22:48, Michael Concini mconc...@gmail.com wrote: I need some help with the best way to handle updating the dummy request/response objects that we use for system event listeners kicked off when there isn't a request context. Currently, we're implementing ServletRequest and ServletResponse directly. This is broken when using a servlet 3.0 runtime though since we're not implementing the new methods added by the servlet 3.0 spec. I tried already updating the classes to extend the request/response wrapper classes, but that turned out to be problematic since the constructor requires a request/response object to be passed. Since we don't have access to that as we're outside of a request I hit an NPE try to use FacesContext that wasn't there. I've come up with a couple of potential solutions on this and would like some input as to the best way to go. 1) We could also extend the wrapper classes, but add a no-arg constructor to the dummy classes that would just call super(null). This would be fine in most cases, but if an application tried to call any of the new ServletContext methods from Servlet 3.0 we'd get an NPE instead of a runtime exception (not ideal) 2) We can simply add the new methods from the Servlet 3.0 API to our dummy classes. I think as long as we don't include the @Override annotation it should build and run in either a 2.5 or 3.0 environment. I think I like that. We should test 2.5 env -Matthias I like number 2 too, because it keeps things simple. Leonardo Uribe 3) We could implement a dynamic proxy to handle the calls. Would be a little more complex to implement, but might be the most elegant solution. Not fully sure if there are performance implications here though. Personally, I'd lean towards (2), I'd like to here from Werner as well since he was the one that initially implemented this. Any additional feedback from others in the community is of course welcome. Thanks, Mike
Re: [MyFaces 2.0] how to handle _SystemEventServletRequest and _SystemEventServletResponse classes (attn:Werner)
I'd also prefer 2) Regards, Jakob Korherr 2009/12/2 Leonardo Uribe lu4...@gmail.com 2009/12/1 Matthias Wessendorf mwessend...@gmail.com Sent from my iPod. On 01.12.2009, at 22:48, Michael Concini mconc...@gmail.com wrote: I need some help with the best way to handle updating the dummy request/response objects that we use for system event listeners kicked off when there isn't a request context. Currently, we're implementing ServletRequest and ServletResponse directly. This is broken when using a servlet 3.0 runtime though since we're not implementing the new methods added by the servlet 3.0 spec. I tried already updating the classes to extend the request/response wrapper classes, but that turned out to be problematic since the constructor requires a request/response object to be passed. Since we don't have access to that as we're outside of a request I hit an NPE try to use FacesContext that wasn't there. I've come up with a couple of potential solutions on this and would like some input as to the best way to go. 1) We could also extend the wrapper classes, but add a no-arg constructor to the dummy classes that would just call super(null). This would be fine in most cases, but if an application tried to call any of the new ServletContext methods from Servlet 3.0 we'd get an NPE instead of a runtime exception (not ideal) 2) We can simply add the new methods from the Servlet 3.0 API to our dummy classes. I think as long as we don't include the @Override annotation it should build and run in either a 2.5 or 3.0 environment. I think I like that. We should test 2.5 env -Matthias I like number 2 too, because it keeps things simple. Leonardo Uribe 3) We could implement a dynamic proxy to handle the calls. Would be a little more complex to implement, but might be the most elegant solution. Not fully sure if there are performance implications here though. Personally, I'd lean towards (2), I'd like to here from Werner as well since he was the one that initially implemented this. Any additional feedback from others in the community is of course welcome. Thanks, Mike
Re: [MyFaces 2.0] how to handle _SystemEventServletRequest and _SystemEventServletResponse classes (attn:Werner)
I'm not sure number 2 would work, you should try it out. I know that when I tried to do this for Trinidad, it complained that I was not implementing the right version of the interfaces, even though the methods were there. If this is the case then perhaps you should use a Proxy Object. We did that in Trinidad to handle differences of several objects and the interface isn't applied until runtime. Your InvocationHandler can then call into the real methods as they are called if you wish, but it's the most foolproof way I found of implementing this. If #2 works for you, though, then I say go for it. If it doesn't, Proxy's aren't a bad alternative. Scott Jakob Korherr wrote: I'd also prefer 2) Regards, Jakob Korherr 2009/12/2 Leonardo Uribe lu4...@gmail.com 2009/12/1 Matthias Wessendorf mwessend...@gmail.com Sent from my iPod. On 01.12.2009, at 22:48, Michael Concini mconc...@gmail.com wrote: I need some help with the best way to handle updating the dummy request/response objects that we use for system event listeners kicked off when there isn't a request context. Currently, we're implementing ServletRequest and ServletResponse directly. This is broken when using a servlet 3.0 runtime though since we're not implementing the new methods added by the servlet 3.0 spec. I tried already updating the classes to extend the request/response wrapper classes, but that turned out to be problematic since the constructor requires a request/response object to be passed. Since we don't have access to that as we're outside of a request I hit an NPE try to use FacesContext that wasn't there. I've come up with a couple of potential solutions on this and would like some input as to the best way to go. 1) We could also extend the wrapper classes, but add a no-arg constructor to the dummy classes that would just call super(null). This would be fine in most cases, but if an application tried to call any of the new ServletContext methods from Servlet 3.0 we'd get an NPE instead of a runtime exception (not ideal) 2) We can simply add the new methods from the Servlet 3.0 API to our dummy classes. I think as long as we don't include the @Override annotation it should build and run in either a 2.5 or 3.0 environment. I think I like that. We should test 2.5 env -Matthias I like number 2 too, because it keeps things simple. Leonardo Uribe 3) We could implement a dynamic proxy to handle the calls. Would be a little more complex to implement, but might be the most elegant solution. Not fully sure if there are performance implications here though. Personally, I'd lean towards (2), I'd like to here from Werner as well since he was the one that initially implemented this. Any additional feedback from others in the community is of course welcome. Thanks, Mike
[Trinidad] remove application view cache in Trinidad 2?
Hi, I'm working on state saving issues in Trinidad 2 (for JSF 2). I'm just wondering if we really want to support application view cache going forward. The application view cache has some limitations that make me wonder how commonly it's used, see the doc under The Application View Cache http://myfaces.apache.org/trinidad/trinidad-1_2/devguide/configuration.html Maybe more importantly, I'm not sure, but I think the reason it exists is to avoid rerunning the tags? Is rerunning tags as much of an issue with facelets? If not, maybe we should just say to move to facelets in 2.0. Thanks, Gabrielle
[jira] Created: (TRINIDAD-1648) IllegalStateException in UIComponentBase when trying to add a resource (outputScript) to the body target...
IllegalStateException in UIComponentBase when trying to add a resource
(outputScript) to the body target...
---
Key: TRINIDAD-1648
URL: https://issues.apache.org/jira/browse/TRINIDAD-1648
Project: MyFaces Trinidad
Issue Type: New Feature
Components: Components
Affects Versions: 2.0.0-core
Environment: Running Trinidad 2.0.x; with Facelets; no Partial State
Saving and using JSF Ajax request rather than the Trinidad PPR mechanism
Reporter: Pavitra Subramaniam
1. I have a simple usecase where I have changed the Trinidad PPR code to use
the jsf.ajax. The client postback works ok and the command is processed on the
server properly.
2. During render response phase though, an h:outputScript tag present in the
page, gets re-targeted to be under the body tag and this causes an
IllegalStateException in the following method in UICOmponentBase.java.
3. It appears that the JSF RI, throws an ISE when the parent does not contain a
child either in its child list or the facets.
* pIf the specified {...@link UIComponent} has a non-null parent,
* remove it as a child or facet (as appropriate) of that parent.
* As a result, the codeparent/code property will always be
* codenull/code when this method returns./p
*
private static void eraseParent(UIComponent component)
4. To reproduce the problem , download the patch provided. This exception is
only apparent when testing with JSF Ajax.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1648) IllegalStateException in UIComponentBase when trying to add a resource (outputScript) to the body target...
[
https://issues.apache.org/jira/browse/TRINIDAD-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavitra Subramaniam updated TRINIDAD-1648:
--
Status: Patch Available (was: Open)
IllegalStateException in UIComponentBase when trying to add a resource
(outputScript) to the body target...
---
Key: TRINIDAD-1648
URL: https://issues.apache.org/jira/browse/TRINIDAD-1648
Project: MyFaces Trinidad
Issue Type: New Feature
Components: Components
Affects Versions: 2.0.0-core
Environment: Running Trinidad 2.0.x; with Facelets; no Partial State
Saving and using JSF Ajax request rather than the Trinidad PPR mechanism
Reporter: Pavitra Subramaniam
1. I have a simple usecase where I have changed the Trinidad PPR code to use
the jsf.ajax. The client postback works ok and the command is processed on
the server properly.
2. During render response phase though, an h:outputScript tag present in
the page, gets re-targeted to be under the body tag and this causes an
IllegalStateException in the following method in UICOmponentBase.java.
3. It appears that the JSF RI, throws an ISE when the parent does not contain
a child either in its child list or the facets.
* pIf the specified {...@link UIComponent} has a non-null parent,
* remove it as a child or facet (as appropriate) of that parent.
* As a result, the codeparent/code property will always be
* codenull/code when this method returns./p
*
private static void eraseParent(UIComponent component)
4. To reproduce the problem , download the patch provided. This exception is
only apparent when testing with JSF Ajax.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2437) columnClasses must not be rendered if colums columnClasses
columnClasses must not be rendered if colums columnClasses Key: MYFACES-2437 URL: https://issues.apache.org/jira/browse/MYFACES-2437 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Leonardo Uribe Assignee: Leonardo Uribe columnClasses must not be rendered if colums columnClasses -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2437) columnClasses must not be rendered if colums columnClasses
[ https://issues.apache.org/jira/browse/MYFACES-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2437. - Resolution: Fixed Fix Version/s: 2.0.0-alpha-2 columnClasses must not be rendered if colums columnClasses Key: MYFACES-2437 URL: https://issues.apache.org/jira/browse/MYFACES-2437 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.0-alpha-2 columnClasses must not be rendered if colums columnClasses -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2438) h:selectOneRadio can't render HTML.NBSP_ENTITY before start label text
h:selectOneRadio can't render HTML.NBSP_ENTITY before start label text -- Key: MYFACES-2438 URL: https://issues.apache.org/jira/browse/MYFACES-2438 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Leonardo Uribe Assignee: Leonardo Uribe One test that comes from tck does not allow to put a HTML.NBSP_ENTITY before start label text for a select one radio. It is known that do not render this stuff could cause a checkbox be rendered too close to the text (see TOMAHAWK-1395), but note here we are taking about a radio button. Anyway, we have to replace render this text with a space in order to pass a tck test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2438) h:selectOneRadio can't render HTML.NBSP_ENTITY before start label text
[ https://issues.apache.org/jira/browse/MYFACES-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2438. - Resolution: Fixed Fix Version/s: 2.0.0-alpha-2 h:selectOneRadio can't render HTML.NBSP_ENTITY before start label text -- Key: MYFACES-2438 URL: https://issues.apache.org/jira/browse/MYFACES-2438 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.0-alpha-2 One test that comes from tck does not allow to put a HTML.NBSP_ENTITY before start label text for a select one radio. It is known that do not render this stuff could cause a checkbox be rendered too close to the text (see TOMAHAWK-1395), but note here we are taking about a radio button. Anyway, we have to replace render this text with a space in order to pass a tck test. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [MyFaces 2.0] how to handle _SystemEventServletRequest and _SystemEventServletResponse classes (attn:Werner)
Hello,
regarding the 1st solution:
According to the JavaDocs the ServletRequestWrapper throws an
IllegalArgumentException if you pass null as delegate, so this won't
work (I'll come back to that later though). However, given that you're
worried about NullPointerExceptions in case someone calls methods that
have been introduced in the Servlet 3.0 version release, I assume that
MyFaces isn't really concerned about those methods anyway. Otherwise
you'd probably override those methods? If I'm mistaken, please correct
me as some suggestions later on rely on this assumption.
regarding the 2nd solution:
Just ignoring the @Override annotation won't work as the respective
interfaces introduce dependencies to artifacts that are only available
in a Servlet 3.0 environment (for example, there's the startAsync()
method that returns an AsyncContext). If a class loader were to load
your request / response dummy class, he would now also have to load the
class AsyncContext as it's a dependency of your class itself, which
apparently the class loader cannot do in a Servlet 2.5 environment.
Given that I'd say you'll have to create two different dummy
implementations, one that implements the Servlet 2.5 ServletRequest
interface and one that implements the Servlet 3.0 ServletRequest (i.e.
the only thing that changes is the set of methods you have to
implement). However, now another problem arises as you can't just use
two different versions of the same API in a single build, i.e. there's
no way to tell the compiler that one class just implements the methods
in the Servlet 2.5 version whereas another class has to implement the
methods of the Servlet 3.0 version. Both versions have to be compilable
using the same Servlet API version and as the Servlet 2.5 API is just a
subset of the Servlet 3.0 API, both versions have to be compilable using
the Servlet 3.0 version.
The big issue now is that we've got a contradiction now. If we want to
support a Servlet 3.0 environment, we'll have to use this version in our
build (again, Servlet 3.0 is if I'm not mistaken a superset of Servlet
2.5, that's the reason for that). However, the 2.5 version of the dummy
class cannot compile if one uses the 3.0 version for the actual build.
Maybe that sounds a little bit strange up until now, but hopefully now
it will get clearer: A 2.5 compatible implementation of the
ServletRequest interface must not implement the method startAsync as
it introduces an unsatisfiable dependency, but a 3.0 compatible build
environment requires any implementation to implement the method
startAsync (amongs others) as it is a part of the interface after all.
Hence I'm afraid but this solution just won't work either. Of course,
the third solution would probably work, but why bother about the
performance implications if there's another solution? :-)
I think the preferable solution is actually the first one. It's easy to
implement as we don't have to deal with the difference between the
Servlet 2.5 API and Servlet 3.0 API, but as I've already mentioned there
is the IllegalArgumentException issue that you just can't ignore either.
We just want to get rid of the null value somehow, so why not use a
dummy proxy instead? Note that there are no performance implications if
you override the wrapped methods anyway, i.e. in fact, the proxy won't
be called even once. It's sole purpose is to replace the null, that's
it. It could look like the following:
///
public class DummyServletRequest extends ServletRequestWrapper {
public DummyServletRequest() {
super(Proxy.newProxyInstance(
DummyServletRequest.class.getClassLoader(),
new Class[] { ServletRequest.class },
new InvocationHandler() {
public Object invoke(Object proxy, Method m, Object[] args) {
throw new UnsupportedOperationException(...);
}
}
);
}
// - Implement the interface ServletRequest now!
public Object getAttribute(String name) {
// ...
}
// ...
}
\\\
Hope that helps. :-)
regards,
Bernhard Huemer
On 12/01/2009 09:48PM GMT, Michael Concini wrote:
I need some help with the best way to handle updating the dummy
request/response objects that we use for system event listeners kicked
off when there isn't a request context. Currently, we're implementing
ServletRequest and ServletResponse directly. This is broken when using
a servlet 3.0 runtime though since we're not implementing the new
methods added by the servlet 3.0 spec.
I tried already updating the classes to extend the request/response
wrapper classes, but that turned out to be problematic since the
constructor requires a request/response object to be passed. Since we
don't have access to that as we're outside of a request I hit an NPE try
to use FacesContext that wasn't there.
I've come up with a couple of potential solutions on this and would like
some input as to the best way to go.
1) We could also extend the
Re: [Trinidad] remove application view cache in Trinidad 2?
Gabrielle, I think the main advantage of using application view cache is that state saving/view root caching is done once for a particular page within an application (that only applies to pages displayed in response to a GET request). Since we have seen some issues with the current implementation, I would vote for not supporting application view cache in Trinidad 2. Partial state saving should make its benefits much less tangible. If there is demand for this feature in the future, we can revisit it and try to address the issues we have seen. Max Gabrielle Crawford wrote: Hi, I'm working on state saving issues in Trinidad 2 (for JSF 2). I'm just wondering if we really want to support application view cache going forward. The application view cache has some limitations that make me wonder how commonly it's used, see the doc under The Application View Cache http://myfaces.apache.org/trinidad/trinidad-1_2/devguide/configuration.html Maybe more importantly, I'm not sure, but I think the reason it exists is to avoid rerunning the tags? Is rerunning tags as much of an issue with facelets? If not, maybe we should just say to move to facelets in 2.0. Thanks, Gabrielle
[jira] Created: (MYFACES-2439) FacesContext.getMessages() must return the messages in the same order it were added
FacesContext.getMessages() must return the messages in the same order it were added --- Key: MYFACES-2439 URL: https://issues.apache.org/jira/browse/MYFACES-2439 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Leonardo Uribe The current implementation of FacesContext.getMessages() doe not take into account the addition order, and the spec javadoc is clear on this field. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Orchestra download link missing
Hi Kito Thanks for notice it. I have updated the site, so now there is. regards, Leonardo Uribe 2009/12/1 Kito Mann kito.m...@virtua.com Hello everyone, FYI, Orchestra isn't listed on the main MyFaces download page: http://myfaces.apache.org/download.html. --- Kito D. Mann | twitter: kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter: jsfcentral +1 203-404-4848 x3 JSF Summit Conference Dec 1st-4th in Orlando: http://www.jsfsummit.com
Re: [MyFaces 2.0] how to handle _SystemEventServletRequest and _SystemEventServletResponse classes (attn:Werner)
Thanks for the thorough analysis Bernhard. Sounds like the 2nd option
that I and others were leaning towards won't work out. Based on this,
and assuming there are no objections from the community, I'll work on a
a fix using your recommendations below.
Bernhard Huemer wrote:
Hello,
regarding the 1st solution:
According to the JavaDocs the ServletRequestWrapper throws an
IllegalArgumentException if you pass null as delegate, so this won't
work (I'll come back to that later though). However, given that you're
worried about NullPointerExceptions in case someone calls methods that
have been introduced in the Servlet 3.0 version release, I assume that
MyFaces isn't really concerned about those methods anyway. Otherwise
you'd probably override those methods? If I'm mistaken, please correct
me as some suggestions later on rely on this assumption.
regarding the 2nd solution:
Just ignoring the @Override annotation won't work as the respective
interfaces introduce dependencies to artifacts that are only available
in a Servlet 3.0 environment (for example, there's the startAsync()
method that returns an AsyncContext). If a class loader were to load
your request / response dummy class, he would now also have to load
the class AsyncContext as it's a dependency of your class itself,
which apparently the class loader cannot do in a Servlet 2.5 environment.
Given that I'd say you'll have to create two different dummy
implementations, one that implements the Servlet 2.5 ServletRequest
interface and one that implements the Servlet 3.0 ServletRequest (i.e.
the only thing that changes is the set of methods you have to
implement). However, now another problem arises as you can't just use
two different versions of the same API in a single build, i.e. there's
no way to tell the compiler that one class just implements the methods
in the Servlet 2.5 version whereas another class has to implement the
methods of the Servlet 3.0 version. Both versions have to be
compilable using the same Servlet API version and as the Servlet 2.5
API is just a subset of the Servlet 3.0 API, both versions have to be
compilable using the Servlet 3.0 version.
The big issue now is that we've got a contradiction now. If we want to
support a Servlet 3.0 environment, we'll have to use this version in
our build (again, Servlet 3.0 is if I'm not mistaken a superset of
Servlet 2.5, that's the reason for that). However, the 2.5 version of
the dummy class cannot compile if one uses the 3.0 version for the
actual build. Maybe that sounds a little bit strange up until now, but
hopefully now it will get clearer: A 2.5 compatible implementation of
the ServletRequest interface must not implement the method
startAsync as it introduces an unsatisfiable dependency, but a 3.0
compatible build environment requires any implementation to implement
the method startAsync (amongs others) as it is a part of the
interface after all.
Hence I'm afraid but this solution just won't work either. Of course,
the third solution would probably work, but why bother about the
performance implications if there's another solution? :-)
I think the preferable solution is actually the first one. It's easy
to implement as we don't have to deal with the difference between the
Servlet 2.5 API and Servlet 3.0 API, but as I've already mentioned
there is the IllegalArgumentException issue that you just can't ignore
either. We just want to get rid of the null value somehow, so why not
use a dummy proxy instead? Note that there are no performance
implications if you override the wrapped methods anyway, i.e. in fact,
the proxy won't be called even once. It's sole purpose is to replace
the null, that's it. It could look like the following:
///
public class DummyServletRequest extends ServletRequestWrapper {
public DummyServletRequest() {
super(Proxy.newProxyInstance(
DummyServletRequest.class.getClassLoader(),
new Class[] { ServletRequest.class },
new InvocationHandler() {
public Object invoke(Object proxy, Method m, Object[] args) {
throw new UnsupportedOperationException(...);
}
}
);
}
// - Implement the interface ServletRequest now!
public Object getAttribute(String name) {
// ...
}
// ...
}
\\\
Hope that helps. :-)
regards,
Bernhard Huemer
On 12/01/2009 09:48PM GMT, Michael Concini wrote:
I need some help with the best way to handle updating the dummy
request/response objects that we use for system event listeners
kicked off when there isn't a request context. Currently, we're
implementing ServletRequest and ServletResponse directly. This is
broken when using a servlet 3.0 runtime though since we're not
implementing the new methods added by the servlet 3.0 spec.
I tried already updating the classes to extend the request/response
wrapper classes, but that turned out to be problematic since the
constructor requires a request/response
[jira] Created: (MYFACES-2440) org.apache.myfaces.shared_impl.webapp.webxml.WebXmlParser parse Unable to parse web.xml
org.apache.myfaces.shared_impl.webapp.webxml.WebXmlParser parse Unable to parse web.xml --- Key: MYFACES-2440 URL: https://issues.apache.org/jira/browse/MYFACES-2440 Project: MyFaces Core Issue Type: Wish Affects Versions: 1.2.8 Environment: AIX,WAS7 Reporter: viswam Hi, im getting the following exception when im deplying one of my webapplication and run the server org.apache.myfaces.shared_impl.webapp.webxml.WebXmlParser parse Unable to parse web.xml java.net.ConnectException: A remote host did not respond within the timeout period. thanks -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [MyFaces 2.0] how to handle _SystemEventServletRequest and _SystemEventServletResponse classes (attn:Werner)
I don't know why you couldn't just pass the proxy, and just throw
IllegalOperationExceptions for unrecognized methods. But this one may
be a bit cleaner. Don't know.
Sent from my iPhone
On Dec 1, 2009, at 6:21 PM, Bernhard Huemer
bernhard.hue...@gmail.com wrote:
Hello,
regarding the 1st solution:
According to the JavaDocs the ServletRequestWrapper throws an
IllegalArgumentException if you pass null as delegate, so this
won't work (I'll come back to that later though). However, given
that you're worried about NullPointerExceptions in case someone
calls methods that have been introduced in the Servlet 3.0 version
release, I assume that MyFaces isn't really concerned about those
methods anyway. Otherwise you'd probably override those methods? If
I'm mistaken, please correct me as some suggestions later on rely on
this assumption.
regarding the 2nd solution:
Just ignoring the @Override annotation won't work as the respective
interfaces introduce dependencies to artifacts that are only
available in a Servlet 3.0 environment (for example, there's the
startAsync() method that returns an AsyncContext). If a class loader
were to load your request / response dummy class, he would now also
have to load the class AsyncContext as it's a dependency of your
class itself, which apparently the class loader cannot do in a
Servlet 2.5 environment.
Given that I'd say you'll have to create two different dummy
implementations, one that implements the Servlet 2.5 ServletRequest
interface and one that implements the Servlet 3.0 ServletRequest
(i.e. the only thing that changes is the set of methods you have to
implement). However, now another problem arises as you can't just
use two different versions of the same API in a single build, i.e.
there's no way to tell the compiler that one class just implements
the methods in the Servlet 2.5 version whereas another class has to
implement the methods of the Servlet 3.0 version. Both versions have
to be compilable using the same Servlet API version and as the
Servlet 2.5 API is just a subset of the Servlet 3.0 API, both
versions have to be compilable using the Servlet 3.0 version.
The big issue now is that we've got a contradiction now. If we want
to support a Servlet 3.0 environment, we'll have to use this version
in our build (again, Servlet 3.0 is if I'm not mistaken a superset
of Servlet 2.5, that's the reason for that). However, the 2.5
version of the dummy class cannot compile if one uses the 3.0
version for the actual build. Maybe that sounds a little bit strange
up until now, but hopefully now it will get clearer: A 2.5
compatible implementation of the ServletRequest interface must not
implement the method startAsync as it introduces an unsatisfiable
dependency, but a 3.0 compatible build environment requires any
implementation to implement the method startAsync (amongs others)
as it is a part of the interface after all.
Hence I'm afraid but this solution just won't work either. Of
course, the third solution would probably work, but why bother about
the performance implications if there's another solution? :-)
I think the preferable solution is actually the first one. It's easy
to implement as we don't have to deal with the difference between
the Servlet 2.5 API and Servlet 3.0 API, but as I've already
mentioned there is the IllegalArgumentException issue that you just
can't ignore either. We just want to get rid of the null value
somehow, so why not use a dummy proxy instead? Note that there are
no performance implications if you override the wrapped methods
anyway, i.e. in fact, the proxy won't be called even once. It's sole
purpose is to replace the null, that's it. It could look like the
following:
///
public class DummyServletRequest extends ServletRequestWrapper {
public DummyServletRequest() {
super(Proxy.newProxyInstance(
DummyServletRequest.class.getClassLoader(),
new Class[] { ServletRequest.class },
new InvocationHandler() {
public Object invoke(Object proxy, Method m, Object[] args) {
throw new UnsupportedOperationException(...);
}
}
);
}
// - Implement the interface ServletRequest now!
public Object getAttribute(String name) {
// ...
}
// ...
}
\\\
Hope that helps. :-)
regards,
Bernhard Huemer
On 12/01/2009 09:48PM GMT, Michael Concini wrote:
I need some help with the best way to handle updating the dummy
request/response objects that we use for system event listeners
kicked off when there isn't a request context. Currently, we're
implementing ServletRequest and ServletResponse directly. This is
broken when using a servlet 3.0 runtime though since we're not
implementing the new methods added by the servlet 3.0 spec.
I tried already updating the classes to extend the request/response
wrapper classes, but that turned out to be problematic since the
Re: [core] 1.2.9-SNAPSHOT == updating shared ?
ok. will do so. thx! Matthias On Tue, Dec 1, 2009 at 11:52 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi I usually update shared to its next snapshot version when it is necessary to do some change in shared. In this way if shared has no changes between core release, we know in a simple way when generate this artifacts or not. There is a bug (MYFACES-2433) that affects shared and could be solved on the next release of core 1.2.x, so there is no problem if we update to the latest greatest one. regards Leonardo Uribe 2009/12/1 Matthias Wessendorf mat...@apache.org Hey, I wonder if one is against updating 1.2.9. to the latest greatest (SNAPSHOT) of shared? (= 3.0.8-SNAPSHOT) -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
RE: [orchestra] could we do a release of this artifacts?
As far as I know, a release should be fine! Ciao, Mario Von: Leonardo Uribe [mailto:lu4...@gmail.com] Gesendet: Dienstag, 01. Dezember 2009 23:46 An: MyFaces Development Betreff: [orchestra] could we do a release of this artifacts? Hi I would like to add a module for orchestra and jsf 2.0 and do a release of orchestra in the next days. Is any special step required to do it? or there is some issue that needs to be solved before release it? regards, Leonardo Uribe smime.p7s Description: S/MIME cryptographic signature
Re: [orchestra] could we do a release of this artifacts?
Hi Leonardo, I have an example with Orchestra and JSF 2 in our new JSF book and I had to patch two classes to get it running. First one was (due to new FacesContext methods): org.apache.myfaces.orchestra.lib.jsf._FacesContextWrapper to care for Second one was (due to new Facelets API) org.apache.myfaces.orchestra.conversation.jsf.components.facelets.ConverterTagHandler regards Michael Leonardo Uribe schrieb: Hi I would like to add a module for orchestra and jsf 2.0 and do a release of orchestra in the next days. Is any special step required to do it? or there is some issue that needs to be solved before release it? regards, Leonardo Uribe
Re: [orchestra] could we do a release of this artifacts?
Hello Michael On Wed, Dec 2, 2009 at 8:07 AM, Michael Kurz michi.k...@gmx.at wrote: Hi Leonardo, I have an example with Orchestra and JSF 2 in our new JSF book and I had to patch two classes to get it running. great! btw is the book somewhere online ? First one was (due to new FacesContext methods): org.apache.myfaces.orchestra.lib.jsf._FacesContextWrapper to care for Second one was (due to new Facelets API) org.apache.myfaces.orchestra.conversation.jsf.components.facelets.ConverterTagHandler feel free to provide a patch regards Michael Leonardo Uribe schrieb: Hi I would like to add a module for orchestra and jsf 2.0 and do a release of orchestra in the next days. Is any special step required to do it? or there is some issue that needs to be solved before release it? regards, Leonardo Uribe -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [orchestra] could we do a release of this artifacts?
Matthias Wessendorf schrieb: Hello Michael On Wed, Dec 2, 2009 at 8:07 AM, Michael Kurz michi.k...@gmx.at wrote: Hi Leonardo, I have an example with Orchestra and JSF 2 in our new JSF book and I had to patch two classes to get it running. great! btw is the book somewhere online ? It actually is (german only, sorry guys): http://jsfatwork.irian.at/
Re: [orchestra] could we do a release of this artifacts?
On Wed, Dec 2, 2009 at 8:50 AM, Michael Kurz michi.k...@gmx.at wrote: Matthias Wessendorf schrieb: Hello Michael On Wed, Dec 2, 2009 at 8:07 AM, Michael Kurz michi.k...@gmx.at wrote: Hi Leonardo, I have an example with Orchestra and JSF 2 in our new JSF book and I had to patch two classes to get it running. great! btw is the book somewhere online ? It actually is (german only, sorry guys): http://jsfatwork.irian.at/ works for me ;-) Perhaps you should link to it from our MyFaces wiki ? -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
