Re: validation required
hi Sanjay, sorry for late response but our project in a hard deployment process in these days... since my project restricts code distribution, i've created a demo project that demonstrates the RequiredValidatorChecker usage... note that this may not be the best/recommendable solution for everyone,,, this is just my solution for our project's special requirements... you can reach all the project(code + war file(under deploy dir)) from herehttp://requiredvalidatorcheckerdemo.googlecode.com/svn/ . hope it helps, hasan... On 3/20/07, Sanjay Choudhary [EMAIL PROTECTED] wrote: Hi Hasan, I read your blog and was quite pleased after reading it. It it possible to share the code? It will be nice if you can zip it up in a small sample project. It can be very simple and Form may have just one required field that uses JSF validator. Later , we can enhance it to support other use cases. I am sure it will help several others using JSF. Appreciate your help. Thanks, Sanjay On 3/20/07, Hasan Turksoy [EMAIL PROTECTED] wrote: I took a look on the url you provided and on the wiki I also read that the 'required' validator is a special case. The JSF framework will only call a Validator if a value was submitted. Usually, you would set required=true as an attribute on the input component. If I set requied=true on the input component then JSF built in validation kicks in and Shale required validator is never processed. as you noticed, shale's serverside required validator will never be called by JSF... because JSF will handle (isRequired isEmpty) case by its way and not call any validator for such a condition.. Is there a way to display JSF required validator? or Is there a way to pass an argument to JSF required validator message? There is no way to pass parameter to JSF required validator... By default, JSF will add the ID of the field into message as parameter and send it... you can only override the same message key (as you did)... your removing required=true doesn't matter.. Because commonsvalidator(type=required) already set it inside.. This means; in either way, JSF's required validator message will be shown.. I have faced with the same problem and found a solution by removing both required=true and commonsvalidator's required attribute setting code... So, how will required attribute work? I have implemented a workaround for this problem... Basically, remove the required=true and write a component that will find the required commonsvalidators and call the validate method for them... For a detailed explanation of problem, JSF's working and found alternative solution, you can look at this blog http://www.jroller.com/page/hasant?entry=jsf_bypassable_client_and_server (under Bypassing serverside required validation title). Althogh that blog is about bypassing validations, it is suggesting a solution for your case too... hasan... On 3/20/07, Sanjay Choudhary [EMAIL PROTECTED] wrote:
Re: [validator] conversion error while validating listbox component's value
Tomahawk sandbox subForm (and probably others like Trinidad's subForm) will allow you to do validation grouping like you've specified below. infact subforms can not handle all our requirements.. because we need to validate crossform fields too... suppose we are required to validate ( Form1.fieldA,Form1.fieldB,Form2.fieldC) when comboX submitted and ( Form1.fieldD,Form2.fieldE) when a buttonY submitted... this means, it's needed, for our project, to validate grouped fields independent from their forms... hasan.. On 3/19/07, Mike Kienenberger [EMAIL PROTECTED] wrote: Tomahawk sandbox subForm (and probably others like Trinidad's subForm) will allow you to do validation grouping like you've specified below. On 3/19/07, Hasan Turksoy [EMAIL PROTECTED] wrote: Sounds like your doing some creating stuff with the validator. Yes, i've customized so many parts at both shale-validator and commons-validator jars... our project needs urgent validation requirements.. so, i have injected some extra solutions into framework.. nowadays i'm working on validating only some specific(grouped) fields for only some specific submits.. This means; for instance, a combo will only validate A,B,C fields while another button(in the same form) will validate only E,F,G fields... This is a hard requirement :).. and needs core changes at framework.. that's why i have to track and hold all my changes strictly and go parallel with original shale code at the same time... best regards, hasan... On 3/17/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Hasan Turksoy [EMAIL PROTECTED] i have implemented a workaround for this serverside required problem... shortly: if validatorscript sets the required attribute, as you say, JSF won't call my serverside validator when that field's value is empty... to overcome this, i've commented the validatorscript's required attribute setting code.. this means JSF can't see that field as required and not call any required validator for that field... So, how can we call serverside required validators? I've implemented an idea from myfaces wiki.. Implementation in short; i have developed an RequiredValidatorChecker component.. it traverses all the component tree and calls validate methods for found required validators... i have entered a blog about this solution... So, you can think that serverside required validations are being called when needed... In fact, the problem is ConverterHelper can not handle array/list types in current situation... although i can't think of any such scenario, somehow a validation may be necessary to validate an array/list value.. so, how should it work in this case? (May be such a scenario is not possible ;) ) Shale Clay has an example of using a converter for string arrays[1][2]. I don't understand your problem with the validators. I think I would have tried using the immediate flag on the commands to stop short of validation. Or, looked at one of tomahawk or trinidad's subform components but you might have a complex layout that won't let you do that. Sounds like your doing some creating stuff with the validator. [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/convert/StringArrayConverter.java?view=markup [2] http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/resources/META-INF/faces-config.xml?view=markup Hasan... On 3/16/07, Gary VanMatre wrote: The server-side required commons validator rule is kind of bogus. I've only seen it useful for client side validation. This is because JSF requires a value before it will even invoke the server side validation logic. A component's validator will not be invoked if the component doesn't have a value. There is a separate required attribute for components that are EditableValueHolders. The shale ValidatorScript component, that must be added at the end of the page, looks through the component tree and toggles on the required attribute for components that include the shale commons validator required server side rule. So, the ValidatorScript component is needed even if you are only using sever side rules. Gary
Re: validation required
I took a look on the url you provided and on the wiki I also read that the 'required' validator is a special case. The JSF framework will only call a Validator if a value was submitted. Usually, you would set required=true as an attribute on the input component. If I set requied=true on the input component then JSF built in validation kicks in and Shale required validator is never processed. as you noticed, shale's serverside required validator will never be called by JSF... because JSF will handle (isRequired isEmpty) case by its way and not call any validator for such a condition.. Is there a way to display JSF required validator? or Is there a way to pass an argument to JSF required validator message? There is no way to pass parameter to JSF required validator... By default, JSF will add the ID of the field into message as parameter and send it... you can only override the same message key (as you did)... your removing required=true doesn't matter.. Because commonsvalidator(type=required) already set it inside.. This means; in either way, JSF's required validator message will be shown.. I have faced with the same problem and found a solution by removing both required=true and commonsvalidator's required attribute setting code... So, how will required attribute work? I have implemented a workaround for this problem... Basically, remove the required=true and write a component that will find the required commonsvalidators and call the validate method for them... For a detailed explanation of problem, JSF's working and found alternative solution, you can look at this bloghttp://www.jroller.com/page/hasant?entry=jsf_bypassable_client_and_server (under Bypassing serverside required validation title). Althogh that blog is about bypassing validations, it is suggesting a solution for your case too... hasan... On 3/20/07, Sanjay Choudhary [EMAIL PROTECTED] wrote:
Re: [validator] conversion error while validating listbox component's value
hi, javax.faces.ServletException: You have requested a conversion for type [ Lmy.app.CarType;, but there is no by-type converter registered for this type as seen from exception above, a converter for string array is not needed.. in fact, exception says it can not find converter for array of my.app.CarType.. if it would ask for a string array converter, your suggestion may help but it is looking for a converter of my domain type's array.. so, i can not declare a converter for all my domain types' arrays (in this case, i have to declare converters for arrays of my.app.PhoneType, my.app.CarType, my.app.DocumentType, etc...)... hundreds of types... note that the above error exists at the current jars of shale framework... but, if we put your fix(validate method looking submittedvalues instead of converted values - SHALE-412https://issues.apache.org/struts/browse/SHALE-412) from a previous conversation into usage, we can overcome this issue by adding a string array converter... because in this case, it will look for conversion between String[] and String... as a result, it seems that your solution is wise and validator should take submitted values into accout.. so, i want to implement the same thing in our app too.. i can put it directly but it's better to use shale's built codes.. but, i can not find your fix for SHALE-412 issue in nightly builds... can you check it? and please direct me if i'm looking at wrong place? Sounds like your doing some creating stuff with the validator. Yes, i've customized so many parts at both shale-validator and commons-validator jars... our project needs urgent validation requirements.. so, i have injected some extra solutions into framework.. nowadays i'm working on validating only some specific(grouped) fields for only some specific submits.. This means; for instance, a combo will only validate A,B,C fields while another button(in the same form) will validate only E,F,G fields... This is a hard requirement :).. and needs core changes at framework.. that's why i have to track and hold all my changes strictly and go parallel with original shale code at the same time... best regards, hasan... On 3/17/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Hasan Turksoy [EMAIL PROTECTED] i have implemented a workaround for this serverside required problem... shortly: if validatorscript sets the required attribute, as you say, JSF won't call my serverside validator when that field's value is empty... to overcome this, i've commented the validatorscript's required attribute setting code.. this means JSF can't see that field as required and not call any required validator for that field... So, how can we call serverside required validators? I've implemented an idea from myfaces wiki.. Implementation in short; i have developed an RequiredValidatorChecker component.. it traverses all the component tree and calls validate methods for found required validators... i have entered a blog about this solution... So, you can think that serverside required validations are being called when needed... In fact, the problem is ConverterHelper can not handle array/list types in current situation... although i can't think of any such scenario, somehow a validation may be necessary to validate an array/list value.. so, how should it work in this case? (May be such a scenario is not possible ;) ) Shale Clay has an example of using a converter for string arrays[1][2]. I don't understand your problem with the validators. I think I would have tried using the immediate flag on the commands to stop short of validation. Or, looked at one of tomahawk or trinidad's subform components but you might have a complex layout that won't let you do that. Sounds like your doing some creating stuff with the validator. [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/apache/shale/clay/convert/StringArrayConverter.java?view=markup [2] http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/resources/META-INF/faces-config.xml?view=markup Hasan... On 3/16/07, Gary VanMatre wrote: The server-side required commons validator rule is kind of bogus. I've only seen it useful for client side validation. This is because JSF requires a value before it will even invoke the server side validation logic. A component's validator will not be invoked if the component doesn't have a value. There is a separate required attribute for components that are EditableValueHolders. The shale ValidatorScript component, that must be added at the end of the page, looks through the component tree and toggles on the required attribute for components that include the shale commons validator required server side rule. So, the ValidatorScript component is needed even if you are only using sever side rules. Gary
[validator] conversion error while validating listbox component's value
hi,
i have a problem about using commons-validator(CV) with selectmanylistbox of
my JSF pages'.. the problem is; CV trying to convert my listboxes' value(an
Array of objects) to string to make a required validation... And it throws
below exception;
javax.faces.ServletException: You have requested a conversion for type [
Lmy.app.CarType;, but there is no by-type converter registered for this
type
as you can understand from exception, it's trying to find a converter for
the array of my.app.CarType.. and couldn't find as expected...
however, instead of looking directly for a converter of the coming value's
type, ConverterHelper class should control the coming value's being
array/list condition and if so; traverse that array/list and convert each
element of it separately... In JSF RI, MenuRenderer class(
com.sun.faces.renderkit.html_basic.MenuRenderer) is working as this way
while converting coming array/list values to string or object...
what do you think about this issue... i think this is an issue (and may be i
should enter it on shale-JIRA)... But is there any other solution? or
anybody used required validator with h:selectManyListBox component?
my usage is as below;
h:selectManyListbox value=#{myPageCode.selectedCarTypesArray} ...
f:selectItems value=#{myPageCode.carTypesList}/f:selectItems
s:commonsvalidator type=required ... /
/h:selectManyListbox
regards,
hasan...
Re: [validator] conversion error while validating listbox component's value
i have implemented a workaround for this serverside required problem... shortly: if validatorscript sets the required attribute, as you say, JSF won't call my serverside validator when that field's value is empty... to overcome this, i've commented the validatorscript's required attribute setting code.. this means JSF can't see that field as required and not call any required validator for that field... So, how can we call serverside required validators? I've implemented an ideahttp://wiki.apache.org/myfaces/OptionalValidationFrameworkfrom myfaces wiki.. Implementation in short; i have developed an RequiredValidatorChecker component.. it traverses all the component tree and calls validate methods for found required validators... i have entered a bloghttp://www.jroller.com/page/hasant?entry=jsf_bypassable_client_and_serverabout this solution... So, you can think that serverside required validations are being called when needed... In fact, the problem is ConverterHelper can not handle array/list types in current situation... although i can't think of any such scenario, somehow a validation may be necessary to validate an array/list value.. so, how should it work in this case? (May be such a scenario is not possible ;) ) Hasan... On 3/16/07, Gary VanMatre [EMAIL PROTECTED] wrote: The server-side required commons validator rule is kind of bogus. I've only seen it useful for client side validation. This is because JSF requires a value before it will even invoke the server side validation logic. A component's validator will not be invoked if the component doesn't have a value. There is a separate required attribute for components that are EditableValueHolders. The shale ValidatorScript component, that must be added at the end of the page, looks through the component tree and toggles on the required attribute for components that include the shale commons validator required server side rule. So, the ValidatorScript component is needed even if you are only using sever side rules. Gary
Re: [shale-validator] CommonsValidator doesn't take component converters into account!
I agree it is not acceptable but they are not behaving differently. The
validator assigned to the component will be invoked before the
CommonsValidator is invoked.
there is NO custom validator Gary, only custom converters there :).. i've
realized that i made a mistake while writing my previous mail.. It should be
custom converter instead of custom validator.. Sorry for this mistake...
I'm not disagreeing that you have uncovered a bug that will be addressed
but what I'm saying is that Shales Commons Validator is using JSF
converters as a utility [1] for converting from one data type to another.
what i'm sayin is that too :) i only want to draw attention to custom
converters of components before using those JSF converters.
It does this nonsense to provide a generic way (single converter that works
for any rule) to invoke any custom validation rule that you might add.
i am not talking about using a generic converter or etc - as i say previous
sentence...
Let me summarize the conversation:
in current case; when i assigned a custom converter for a field, JSF RI is
using that custom converter but CommonsValidator is using by-type
converter.. This leads some misbehaviours...
Your comments light my mind,, and asked the same question for whole
yesterday...
if the value passed to the validator already converted, so why
commonsvalidator trying to convert that value again? The answer is; to use a
generic validator to do all validations.. As you say at your previous entry;
The data conversion occurs because the apache commons validator needs a
String data type and not a date data type.
Exactly at this point my issue/suggestion comes:
Main point is: Validator have to use the SAME CONVERTER which used before
sending that value to it...
i mean; if a value converted to java.util.Date type by ConverterX and send
to CommonsValidator to validate, so, CommmonsValidator must use that same
converter(ConverterX) too, to convert that value again toString/toObject...
not java.util.Date type's registered converter...
regards,
hasan
http://www.jroller.com/hasant
On 2/23/07, Gary VanMatre [EMAIL PROTECTED] wrote:
From: Hasan Turksoy [EMAIL PROTECTED]
jsf-ri1.1 contains converter for javax.faces.DateTime class only...
not
for java.util.Date class you can download and look at
jsf-ri-config.xml...
in fact, this is not the main problem... i can overcome my issue by
adding a
converter for java.util.Date... But this doesn't solve the problem in
the
origin
Because; in JSF, one can add custom converter for each component
separately... in such a case, using my by-type java.util.Date converter
is
meaningless! because, user assigned a custom converter for that field!!
JSF
will use it instead of by-type converter... so, commons should use it
too...
now, when assigned custom validator for fields,, JSF RI and
CommonsValidator
behaving differently!!! this is not an acceptable situation! isn't it?
I agree it is not acceptable but they are not behaving differently. The
validator assigned to the component will be invoked before the
CommonsValidator is invoked.
to realize the problem... when returned to my sample in the previous
post;
suppose that i have a java.util.Date converter... and no custom
converter... in this case, CommonsValidator and JSF RI will work same..
both will use our by-type converter...
But, if i use a custom converter for my inputtext as below;
**
/
then, JSF RI will use this custom component converter to convert it's
value
but CommonsValidator will use our by-type java.util.Date converter...
different behaviours!!...
Not exactly, the java.util.Date converter is used by commons validator
to convert a Date object to a String (within the validator's validate
method). The custom converter assigned to the component (the same component
that is using commons validator), is being invoked prior to the call to
commons validator.
I'm not disagreeing that you have uncovered a bug that will be addressed
but what I'm saying is that Shales Commons Validator is using JSF converters
as a utility [1] for converting from one data type to another. It does this
nonsense to provide a generic way (single converter that works for any rule)
to invoke any custom validation rule that you might add.
I'll try to summarize with code:
// Validator's interface
public void validate(FacesContext context, UIComponent component, Object
value) {
..
Date obj = (Date) value;// value is already processed by the
components converter (String -- Date)
ConverterHelper converterHelper = new ConverterHelper();
// uses the a JSF converter Object to String
String objString = converterHelper.asString(context, obj.getClass(), obj);
boolean isValid = isDate(objString, datepattern);
[1]
http://svn.apache.org/viewvc/shale/framework/trunk/shale-core/src/main/java/org/apache/shale/util/ConverterHelper.java?view=markup
In conclusion; when we look at JSF RI code, we see that; it first looks
for
custom
why the arg argument is not early binding?
hi all,
commonsvalidator's arg argument used as the first argument of messages at
validator-rules.xml... in my application, i'm using those arg arguments to
hold some info(in general field's name) about my field which is being
validated
it's like:
h:inputtext ...
s:commonsvalidator type=required *arg=User Name* . /
/h:inputtext ...
above code works as expected and gives appropriate validation message if
that field is not valid (like: User Name is required.)
But, if i bind my arg argument to a key in my bundle, my message is being
as null is required... sample code is as below;
h:inputtext ...
s:commonsvalidator type=required *arg=#{varMyBundle.lblUserName}*. /
/h:inputtext ...
I dive into code and find the problem solution... ValidatorTag class is
setting arg argument's value directly instead of evaluating the expression
and putting the resulting value into it... Some of the arguments (type,
message, client, server) are early binding at the tag class but not
arg argument...
shouldn't the arg argument set by early binding as above attributes? isn't
this an issue?
regards,
hasan..
http://www.jroller.com/page/hasant
Re: [shale-validator] CommonsValidator doesn't take component converters into account!
jsf-ri1.1 contains converter for javax.faces.DateTime class only... not for java.util.Date class you can download and look at jsf-ri-config.xml... in fact, this is not the main problem... i can overcome my issue by adding a converter for java.util.Date... But this doesn't solve the problem in the origin Because; in JSF, one can add custom converter for each component separately... in such a case, using my by-type java.util.Date converter is meaningless! because, user assigned a custom converter for that field!! JSF will use it instead of by-type converter... so, commons should use it too... now, when assigned custom validator for fields,, JSF RI and CommonsValidator behaving differently!!! this is not an acceptable situation! isn't it? to realize the problem... when returned to my sample in the previous post; suppose that i have a java.util.Date converter... and no custom converter... in this case, CommonsValidator and JSF RI will work same.. both will use our by-type converter... But, if i use a custom converter for my inputtext as below; h:inputtext ... *f:convertDateTime dateStyle=short /* s:commonsvalidator type=required arg=... client=true server=true / /h:inputtext then, JSF RI will use this custom component converter to convert it's value but CommonsValidator will use our by-type java.util.Date converter... different behaviours!!... In conclusion; when we look at JSF RI code, we see that; it first looks for custom component converter then, if can not find, searches for a by-type converter... CommonsValidator must work same i think... i have injected my solution into my CommonsValidator class and it works perfect... above suggestion should be implemented in original CommonsValidator releases as soon as possible i think... i can provide code if required... regards.. hasan.. On 2/21/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Hasan Turksoy [EMAIL PROTECTED] hi all, Env: jsf1.1, commons-validator1.3.1, shale1.0.4.. i'am trying to put a required validator for my date entering field.. My field has a f:convertDateTime to make conversion between String - java.util.Date. it's like; h:inputtext ... f:convertDateTime dateStyle=short / s:commonsvalidator type=required arg=... client=true server=true / /h:inputtext When i entered a valid value into my date field it throws a ConverterException as below; javax.faces.ConverterException: You have requested a conversion for type java.util.Date, but there is no by-type converter registered for this type. I'm not sure why you are seeing this exception. I belive that the java.util.Data converter should be registered with the JSF runtime. Can you tell where the exception is being raised from the stack trace? The reason for asking is that the shale commons validator uses JSF converters to coerce data types to match the signatures of the server side validation methods. as i understand; it needs a converter for the java.util.Date class.. But in JSF, one can assign custom converter tags as above sample... this means, (my suggestion) commonsvalidator should get the converter for that type from component. if component don't have any converters assigned, it should lookup for a by-type converter then... Otherwise, i will have to define by-type converters for all my component converters! this will be stupid i think... any comments?? or solutions?? What version of the JSF runtime are you using? This sounds like a rutime issue. thanks in advance, hasan.. Gary.
Re: [shale-validator] CommonsValidator doesn't take component converters into account!
Craig i have created an issue.. you can reach it from herehttp://www.nabble.com/CommonsValidator-doesn%2527t-take-component-converters-into-account%2521-tf3266040.html ... Matthias you are absolutely right :). converters only defined(by id) in config file but they aren't registered for special types in general.. these converters generally assigned for components externally... may be, i've over consantrated about looking for custom component converters before by-type converters part of conversation ;) Gary in fact, it doesn't matter, whether there is a converter for that type or not... in any case, CommonsValidator should look for component's custom converter first. if can not find, look up for a by-type converter later. this is the main issue... JSF RI works as this way.. there might be a registered converter for my type.. But if i assigned a custom converter for a field, JSF RI will use it not the registered by-type converter.. so CommonsValidator should work like it too hasan.. http://www.jroller.com/page/hasant On 2/22/07, Gary VanMatre [EMAIL PROTECTED] wrote: From: Matthias Wessendorf [EMAIL PROTECTED] On 2/22/07, Hasan Turksoy wrote: jsf-ri1.1 contains converter for javax.faces.DateTime class only... not for java.util.Date class you can download and look at jsf-ri-config.xml... in fact, this is not the main problem... i can overcome my issue by adding a converter for java.util.Date... But this doesn't solve the problem in the origin are you talking about this: javax.faces.DateTime javax.faces.convert.DateTimeConverter that is just the id... I think the -for-class is only there for simple converters like javax.faces.convert.FloatConverter Yeah, for some reason I was thinking that the RI already has a converter registered by type for the java.util.Date type. converter-for-classjava.util.Date/converter-for-class The shale commons validator uses the ConverterHelper [1] (uses JSF type converters) to convert the submitted value, after the components converter has already converted to a Date object, back to a String to match the commons validator methodParams. validator name=date classname=org.apache.shale.validator.CommonsValidator method=isDate methodParams=java.lang.String,java.lang.String msg=errors.date jsFunctionName=validateDate jsFunction= org.apache.commons.validator.javascript.validateDate depends=/ [1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-core/src/main/java/org/apache/shale/util/ConverterHelper.java?view=markup -M Gary Because; in JSF, one can add custom converter for each component separately... in such a case, using my by-type java.util.Dateconverter is meaningless! because, user assigned a custom converter for that field!! JSF will use it instead of by-type converter... so, commons should use it too... now, when assigned custom validator for fields,, JSF RI and CommonsValidator behaving differently!!! this is not an acceptable situation! isn't it? to realize the problem... when returned to my sample in the previous post; suppose that i have a java.util.Date converter... and no custom converter... in this case, CommonsValidator and JSF RI will work same.. both will use our by-type converter... But, if i use a custom converter for my inputtext as below; ** / then, JSF RI will use this custom component converter to convert it's value but CommonsValidator will use our by-type java.util.Date converter... different behaviours!!... In conclusion; when we look at JSF RI code, we see that; it first looks for custom component converter then, if can not find, searches for a by-type converter... CommonsValidator must work same i think... i have injected my solution into my CommonsValidator class and it works perfect... above suggestion should be implemented in original CommonsValidator releases as soon as possible i think... i can provide code if required... regards.. hasan.. On 2/21/07, Gary VanMatre wrote: From: Hasan Turksoy hi all, Env: jsf1.1, commons-validator1.3.1, shale1.0.4.. i'am trying to put a required validator for my date entering field.. My field has a f:convertDateTime to make conversion between String - java.util.Date. it's like; server=true / When i entered a valid value into my date field it throws a ConverterException as below; javax.faces.ConverterException: You have requested a conversion for type java.util.Date, but there is no by-type converter registered for this type. I'm not sure why you are seeing this exception. I belive that the java.util.Data converter should be registered with the JSF runtime. Can you tell where the exception is being
[shale-validator] CommonsValidator doesn't take component converters into account!
hi all, Env: jsf1.1, commons-validator1.3.1, shale1.0.4.. i'am trying to put a required validator for my date entering field.. My field has a f:convertDateTime to make conversion between String - java.util.Date. it's like; h:inputtext ... f:convertDateTime dateStyle=short / s:commonsvalidator type=required arg=... client=true server=true / /h:inputtext When i entered a valid value into my date field it throws a ConverterException as below; javax.faces.ConverterException: You have requested a conversion for type java.util.Date, but there is no by-type converter registered for this type. as i understand; it needs a converter for the java.util.Date class.. But in JSF, one can assign custom converter tags as above sample... this means, (my suggestion) commonsvalidator should get the converter for that type from component. if component don't have any converters assigned, it should lookup for a by-type converter then... Otherwise, i will have to define by-type converters for all my component converters! this will be stupid i think... any comments?? or solutions?? thanks in advance, hasan...
are shale1.0.3 and shale1.0.4 versions JDK1.4 complient?
hi, i'm using shale.1.0.2 in my project(using JDK1.4).. i want to shift shale version up.. but as far as i see, shale1.0.3 and shale1.0.4 versions built with JDK1.5 (as manifest file says)... in fact shale1.0.4's release notes includes an issue to build it with JDK1.4too.. but i can not understand the problem... aren't those versions JDK1.4 complient? thanks in advance... hasan
