Re: [Facelets] deploying old Facelets templates with MyFaces 2
Thank you so much everyone for your efforts. I will instantly start testing with dojofaces and report my progres. Matthias Wessendorf schrieb: can you try, now ? On Thu, Feb 25, 2010 at 7:53 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi, I implemented the lookup for the presence of the facelets-1.1.x view-handler in the faces-config.xml in the factory, so that the users don't have to explicitly set the related web.xml config parameter when they already said that they want to use facelets-1.1.x in faces-config.xml (via defining the facelets-1.1.x view-handler). Mojarra actually does exactly the same. Regards, Jakob 2010/2/25 Matthias Wessendorf mat...@apache.org On Thu, Feb 25, 2010 at 7:15 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Ganesh I think dojofaces will not work until apply the patch on MYFACES-2564 (look on subversion commits). This change was reverted but now we need it to complete the solution. Anyway we need to change it a little and maybe remove the code that checks for facelets view handler and takes into account to right, as I understand it users are asked/forced to get rid of that. -M check if it is facelets for jsf 2.0 working or not. regards, Leonardo Uribe 2010/2/25 Matthias Wessendorf mat...@apache.org it should work, by now, just go svn up on trunk. I am interested in the results of testing your project. thx On Thu, Feb 25, 2010 at 7:08 PM, Ganesh gan...@j4fry.org wrote: Hi Matthias, Currently I'm putting my effords into dojofaces, so interest is there, but time is scarce ... sorry. Best regards, Ganesh Matthias Wessendorf schrieb: Yeah, I understand that. Any interest in helping with the fix ? :) -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: [Facelets] deploying old Facelets templates with MyFaces 2
that's great! The more feedback (from different lib) we get, the better On Fri, Feb 26, 2010 at 9:16 AM, Ganesh gan...@j4fry.org wrote: Thank you so much everyone for your efforts. I will instantly start testing with dojofaces and report my progres. Matthias Wessendorf schrieb: can you try, now ? On Thu, Feb 25, 2010 at 7:53 PM, Jakob Korherr jakob.korh...@gmail.com wrote: Hi, I implemented the lookup for the presence of the facelets-1.1.x view-handler in the faces-config.xml in the factory, so that the users don't have to explicitly set the related web.xml config parameter when they already said that they want to use facelets-1.1.x in faces-config.xml (via defining the facelets-1.1.x view-handler). Mojarra actually does exactly the same. Regards, Jakob 2010/2/25 Matthias Wessendorf mat...@apache.org On Thu, Feb 25, 2010 at 7:15 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi Ganesh I think dojofaces will not work until apply the patch on MYFACES-2564 (look on subversion commits). This change was reverted but now we need it to complete the solution. Anyway we need to change it a little and maybe remove the code that checks for facelets view handler and takes into account to right, as I understand it users are asked/forced to get rid of that. -M check if it is facelets for jsf 2.0 working or not. regards, Leonardo Uribe 2010/2/25 Matthias Wessendorf mat...@apache.org it should work, by now, just go svn up on trunk. I am interested in the results of testing your project. thx On Thu, Feb 25, 2010 at 7:08 PM, Ganesh gan...@j4fry.org wrote: Hi Matthias, Currently I'm putting my effords into dojofaces, so interest is there, but time is scarce ... sorry. Best regards, Ganesh Matthias Wessendorf schrieb: Yeah, I understand that. Any interest in helping with the fix ? :) -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 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2565) BeanValidator throws Exception if external ExpressionLanguageFactory is being used
[
https://issues.apache.org/jira/browse/MYFACES-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12838802#action_12838802
]
Jan-Kees van Andel commented on MYFACES-2565:
-
Just looking at the JavaDocs of BeanValidator#validate(), it looks like a
null-check is missing.
If ValueReference.getBase() return null, take no action and return.
I'll try to fix this issue (as well as the other BeanValidator related issues)
this weekend, but it depends, since I'm a bit behind schedule after JSFDays...
BeanValidator throws Exception if external ExpressionLanguageFactory is being
used
--
Key: MYFACES-2565
URL: https://issues.apache.org/jira/browse/MYFACES-2565
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.0-beta
Reporter: Mark Struberg
Currently the BeanValidator has the following code:
if (_ExternalSpecifications.isUnifiedELAvailable())
{
//TODO: Implement when Unified EL for Java EE6 is available.
throw new FacesException(Unified EL for Java EE6 support is not yet
implemented);
}
I'm using EL-2.2 in MyFaces-2.0.0-SNAPSHOT and now switched from using
facelets-1.1.15.B1 to the built-in facelets-2.
After that I get this rather unfunny Exception in the code above.
I tried to remove this condition in BeanValidator and so far all works well.
Afaik the new EL-2.1 interface should be backward compatible to the EL of
JSF-2.1, isn't?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ExtVal] PropertyValidationInterceptor and BeanVal Model validation
hi,
I have following test scenario:
A class with 3 properties that are shown on a screen and were a
BeanValidation ModelValidation annotation is placed on the type.
@MyModelValidation(message = {person.notallowed})
@BeanValidation(modelValidation = @ModelValidation(isActive = true))
It is a bit difficult to describe the situation but I give it a try. I hope
I don't loose too many people during the explanation.
The *BeanValidationMetaDataExtractorInterceptor *adds for every property (3
in my case) a *ModelValidationEntry *to the storage. As component it places
the different properties in the *ModelValidationEntry *.
A custom *PropertyValidationInterceptor*, which is registered in the system,
receives a before and after event for each property in the bean which is
placed on the screen. This is from the Validation phase where the
validation of the fields itself is performed and thus normal.
Then the *ModelValidationPhaseListener *kicks in (in the after update model
phase). The custom registered interceptor receives now for each
*ModelValidationEntry
*a before event, with the UIComponent as a parameter but with the model
object as converted object.
After the first before event, the actual validation by the JSR303 provider
is performed, and later on blocked by keeping the validated object in a Map
(together with the Group for which the validation took place.).
The after event of the interceptor is finally called with no parameters
(except the facesContext) at all.
So my point is:
In case of a modelValidation, the use of a validator interceptor is not very
functional and confusing.
- The before method is called twice for each component, once with the actual
converted object from the screen and once with the model object. But there
is no indication of what kind of ModelValidation will be performed and thus
difficult to determine if the validation should continue.
- The after method is called but no info about was is done is available.
Since PropertyValidationInterceptor is marked API, we can't change it to
have more parameters that can be used in case of a model validation.
So I think we need a *ModelValidationIntercepter *with parameters that can
be used to make some decision of what to do (before method to block the
validation and after to do some additional things.)
One of the things the after method should receive is the list of
ModelValidationResult objects, so the interceptor can change these.
Too late for x.x.3 , I guess ??
PS I came to this issue when I tried to create a beanValidation version of
the transactional model validation light addon. Need to test it more but
commit to sandboxos890 will follow.
regards,
Rudy
[jira] Created: (MYFACES-2579) Support the dynamic adding of servlets and servlet-mappings on Servlet API 3.0 to make web.xml entries for Faces Servlet not mandatory
Support the dynamic adding of servlets and servlet-mappings on Servlet API 3.0 to make web.xml entries for Faces Servlet not mandatory -- Key: MYFACES-2579 URL: https://issues.apache.org/jira/browse/MYFACES-2579 Project: MyFaces Core Issue Type: New Feature Affects Versions: 2.0.0-beta-3 Environment: Environment with Servlet API 3.0 available. Reporter: Jakob Korherr This would be a really cool new feature, because we could use the new Servlet API to add the entries for Faces Servlet dynamically at startup and so the user does not have to configure it anymore in web.xml. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2565) BeanValidator throws Exception if external ExpressionLanguageFactory is being used
[
https://issues.apache.org/jira/browse/MYFACES-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12838838#action_12838838
]
Mark Struberg commented on MYFACES-2565:
oki, then it seems I at least locally patched it the right way already -txs.
And don't worry, I think JSFdays was a big boost again in terms of ideas,
knowledge and of course motivation which will overcompensate loosing those 3
days easily ;)
BeanValidator throws Exception if external ExpressionLanguageFactory is being
used
--
Key: MYFACES-2565
URL: https://issues.apache.org/jira/browse/MYFACES-2565
Project: MyFaces Core
Issue Type: Bug
Affects Versions: 2.0.0-beta
Reporter: Mark Struberg
Currently the BeanValidator has the following code:
if (_ExternalSpecifications.isUnifiedELAvailable())
{
//TODO: Implement when Unified EL for Java EE6 is available.
throw new FacesException(Unified EL for Java EE6 support is not yet
implemented);
}
I'm using EL-2.2 in MyFaces-2.0.0-SNAPSHOT and now switched from using
facelets-1.1.15.B1 to the built-in facelets-2.
After that I get this rather unfunny Exception in the code above.
I tried to remove this condition in BeanValidator and so far all works well.
Afaik the new EL-2.1 interface should be backward compatible to the EL of
JSF-2.1, isn't?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [ExtVal] PropertyValidationInterceptor and BeanVal Model validation
hi rudy,
to keep it short - it isn't too late for r3. i'll start with the first steps
of the release (which have to be done before the release-vote) as soon as
leonardo is available. so if we find a nice solution for it without api
changes, it might be possible to include it in r3. with a workaround it's
possible (right now). i didn't publish it so far because it's just a
workaround and not that nice. however, it's possible to use it in an add-on.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/2/26 Rudy De Busscher rdebussc...@gmail.com
hi,
I have following test scenario:
A class with 3 properties that are shown on a screen and were a
BeanValidation ModelValidation annotation is placed on the type.
@MyModelValidation(message = {person.notallowed})
@BeanValidation(modelValidation = @ModelValidation(isActive = true))
It is a bit difficult to describe the situation but I give it a try. I
hope I don't loose too many people during the explanation.
The *BeanValidationMetaDataExtractorInterceptor *adds for every property
(3 in my case) a *ModelValidationEntry *to the storage. As component it
places the different properties in the *ModelValidationEntry *.
A custom *PropertyValidationInterceptor*, which is registered in the
system, receives a before and after event for each property in the bean
which is placed on the screen. This is from the Validation phase where the
validation of the fields itself is performed and thus normal.
Then the *ModelValidationPhaseListener *kicks in (in the after update
model phase). The custom registered interceptor receives now for each
*ModelValidationEntry
*a before event, with the UIComponent as a parameter but with the model
object as converted object.
After the first before event, the actual validation by the JSR303 provider
is performed, and later on blocked by keeping the validated object in a Map
(together with the Group for which the validation took place.).
The after event of the interceptor is finally called with no parameters
(except the facesContext) at all.
So my point is:
In case of a modelValidation, the use of a validator interceptor is not
very functional and confusing.
- The before method is called twice for each component, once with the
actual converted object from the screen and once with the model object. But
there is no indication of what kind of ModelValidation will be performed and
thus difficult to determine if the validation should continue.
- The after method is called but no info about was is done is available.
Since PropertyValidationInterceptor is marked API, we can't change it to
have more parameters that can be used in case of a model validation.
So I think we need a *ModelValidationIntercepter *with parameters that can
be used to make some decision of what to do (before method to block the
validation and after to do some additional things.)
One of the things the after method should receive is the list of
ModelValidationResult objects, so the interceptor can change these.
Too late for x.x.3 , I guess ??
PS I came to this issue when I tried to create a beanValidation version of
the transactional model validation light addon. Need to test it more but
commit to sandboxos890 will follow.
regards,
Rudy
[jira] Created: (TOMAHAWK-1494) HtmlMessageRenderer evaluates value expressions of not rendered components
HtmlMessageRenderer evaluates value expressions of not rendered components
--
Key: TOMAHAWK-1494
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1494
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Message(s)
Affects Versions: 1.1.9
Environment: tomahawk12_1.1.9,
myfaces 1.2.8,
richfaces 3.3.3
jsp
Reporter: Michael Heinen
Priority: Critical
I produced a validation error in an inputText field. This field ha a
corresponding outputLabel component.
Now HtmlMessageRenderer creates a Map with all inputLabels, even if they are
not rendered at all.
This can result in exceptions because the value attribute of not rendered and
not initialized components is evaluated!
Sample content:
t:div rendered=false
t:outputLabel id=abcabcLbl for=abcabc value=#{MyController.testme} /
t:inputText id=abcabc value=#{requestScope['test222']}/
/t:div
Method MyController.getTestme() is called if messages are rendered although the
parent div component has attribute rendered=false
proposed fix:
if (root.isRendered())
should be added to method createOutputLabelMap.
Components should not be checked recursively if the root is not rendered at all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1494) HtmlMessageRenderer evaluates value expressions of not rendered components
[
https://issues.apache.org/jira/browse/TOMAHAWK-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12838857#action_12838857
]
Michael Heinen commented on TOMAHAWK-1494:
--
exact class is org.apache.myfaces.renderkit.html.ext.HtmlMessageRenderer
HtmlMessageRenderer evaluates value expressions of not rendered components
--
Key: TOMAHAWK-1494
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1494
Project: MyFaces Tomahawk
Issue Type: Bug
Components: Message(s)
Affects Versions: 1.1.9
Environment: tomahawk12_1.1.9,
myfaces 1.2.8,
richfaces 3.3.3
jsp
Reporter: Michael Heinen
Priority: Critical
I produced a validation error in an inputText field. This field ha a
corresponding outputLabel component.
Now HtmlMessageRenderer creates a Map with all inputLabels, even if they are
not rendered at all.
This can result in exceptions because the value attribute of not rendered and
not initialized components is evaluated!
Sample content:
t:div rendered=false
t:outputLabel id=abcabcLbl for=abcabc value=#{MyController.testme}
/
t:inputText id=abcabc value=#{requestScope['test222']}/
/t:div
Method MyController.getTestme() is called if messages are rendered although
the parent div component has attribute rendered=false
proposed fix:
if (root.isRendered())
should be added to method createOutputLabelMap.
Components should not be checked recursively if the root is not rendered at
all.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[Test] Configuration resource for Myfaces 1.2
Hi, I tried to create a testcase using the myfaces-test12 beta release. However the ConfigParser object isn't aware of the Myfaces 1.2 configuration. The configuration resource */META-INF/standard-faces-config.xml* must also be tried (as indicated in the code, that it will be supported but isn't in yet). regards, Rudy.
[jira] Created: (TOMAHAWK-1495) Converters are singleton on class instead of Id
Converters are singleton on class instead of Id --- Key: TOMAHAWK-1495 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1495 Project: MyFaces Tomahawk Issue Type: Bug Components: Converters Affects Versions: 1.1.9 Reporter: David Tarr Priority: Minor If multiple converters of the same class are defined, the behaviour is as is defined by the last converter defined. Assume: A class org.company.jsf.converter.CalendarConverter implements Converter. Supports a field pattern of type java.lang.String faces-config defines several converter-id's using the same class passing different patterns. This way a single converter ID can be used to indicate how a calendar field should be displayed. The alternative would be to either create different subclasses, or, create tag(s), or, pass f:attribute with each field. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-853) JSF 2.0 support
JSF 2.0 support --- Key: TOBAGO-853 URL: https://issues.apache.org/jira/browse/TOBAGO-853 Project: MyFaces Tobago Issue Type: Improvement Reporter: Bernd Bohmann Assignee: Bernd Bohmann -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-854) Create C
Create C Key: TOBAGO-854 URL: https://issues.apache.org/jira/browse/TOBAGO-854 Project: MyFaces Tobago Issue Type: Sub-task Reporter: Bernd Bohmann -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-855) Create a TobagoTagHandler for JSF 2.0
Create a TobagoTagHandler for JSF 2.0 -- Key: TOBAGO-855 URL: https://issues.apache.org/jira/browse/TOBAGO-855 Project: MyFaces Tobago Issue Type: Sub-task Reporter: Bernd Bohmann -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Test] Configuration resource for Myfaces 1.2
Created Jira issue MYFACESTEST-3 and provided patch On 26 February 2010 14:14, Rudy De Busscher rdebussc...@gmail.com wrote: Hi, I tried to create a testcase using the myfaces-test12 beta release. However the ConfigParser object isn't aware of the Myfaces 1.2 configuration. The configuration resource * /META-INF/standard-faces-config.xml* must also be tried (as indicated in the code, that it will be supported but isn't in yet). regards, Rudy.
[jira] Created: (MYFACES-2580) OSGi: Missing javax.validation imports in api module manifest
OSGi: Missing javax.validation imports in api module manifest - Key: MYFACES-2580 URL: https://issues.apache.org/jira/browse/MYFACES-2580 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.0.0-beta-2 Reporter: Jarek Gawor The OSGi manifest for api module is missing imports for javax.validation packages needed primarily by the BeanValidator.java, -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2581) double slash breaks new prefix mapping (/faces//faces/*) - CTS failure
double slash breaks new prefix mapping (/faces//faces/*) - CTS failure -- Key: MYFACES-2581 URL: https://issues.apache.org/jira/browse/MYFACES-2581 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Michael Concini Assignee: Michael Concini Priority: Minor when using prefix mapping (e.g. /faces/*), according to the new algorithm for JSF 2.0 we need to treat multiple iterations of /faces (/faces/faces, /faces/faces/faces) the same when calculating the view ID. Right now we fail to do this if we have a double slash in the URL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2581) double slash breaks new prefix mapping (/faces//faces/*) - CTS failure
[ https://issues.apache.org/jira/browse/MYFACES-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Concini resolved MYFACES-2581. -- Resolution: Fixed Fix Version/s: 2.0.0-beta-3 double slash breaks new prefix mapping (/faces//faces/*) - CTS failure -- Key: MYFACES-2581 URL: https://issues.apache.org/jira/browse/MYFACES-2581 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Michael Concini Assignee: Michael Concini Priority: Minor Fix For: 2.0.0-beta-3 when using prefix mapping (e.g. /faces/*), according to the new algorithm for JSF 2.0 we need to treat multiple iterations of /faces (/faces/faces, /faces/faces/faces) the same when calculating the view ID. Right now we fail to do this if we have a double slash in the URL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
