[jira] Commented: (BEANUTILS-185) New Map decorator for DynaBeans to allow BeanUtils to operate with technologies such as JSTL
[ https://issues.apache.org/jira/browse/BEANUTILS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500798 ] Gabriel Belingueres commented on BEANUTILS-185: --- I think it is a big downside. If I understood it right, you can't configure a custom ELResolver in previous versions of JSP specs like 2.0 or 1.2 (ie Tomcat 5.5 or 4.1) Even if they could, including a custom ELResolver inside BeanUtils sounds like a functionality that is out of the scope of the library. > New Map decorator for DynaBeans to allow BeanUtils to operate with > technologies such as JSTL > > > Key: BEANUTILS-185 > URL: https://issues.apache.org/jira/browse/BEANUTILS-185 > Project: Commons BeanUtils > Issue Type: Improvement > Components: DynaBean >Affects Versions: 1.7.0 > Environment: Operating System: other > Platform: Other >Reporter: Gabriel Belingueres >Assignee: Niall Pemberton >Priority: Minor > Fix For: 1.8.0 > > Attachments: AbstractRowSetDynaClass.java, > BasicDirectAccessDynaBean.java, BasicDirectAccessDynaBeanTestCase.java, > BasicIndirectAccessDynaBean.java, beanutil-diff.txt, > DirectAccessDynaBean.java, DirectRowSetDynaClass.java, > DynaBeanMapDecorator.java, DynaBeanMapDecoratorTestCase.java, > IndirectAccessDynaBean.java, IndirectRowSetDynaClass.java > > > Hi, > I've done some modifications to the beanutils package to better support the > use > of DynaBeans with the JSTL tags. Some of the changes are discussed in this > thread of the commons-user mailing list: > http://marc.theaimsgroup.com/?l=jakarta-commons-user&m=114669123403779&w=2 > I attach the diff file that comprises changes to the RowSetDynaClass.java > file > and build.xml file (since I added a TestCase.) Note: Please try to filter > carefully the diffs in the build.xml file since they include some local > settings I have for compilation on my machine. :-( > Together with the diff file, I attach the new java files added to the package. > Regards, > Gabriel Belingueres > [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VALIDATOR-221) DateValidator considers "02/29" with format "MM/dd" invalid
[
https://issues.apache.org/jira/browse/VALIDATOR-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468773
]
Gabriel Belingueres commented on VALIDATOR-221:
---
I think there is a subtle mistake here in trying to use a DateValidator to
validate if "02/29" is a valid date. The thing is that February the 29 is valid
*depending on the year* you are talking about, and this is a necessary context
information that is lacking here.
As of why SimpleDateFormat assumes by default that you are talking about 1970
instead of throwing an exception is beyond me understanding.
See this other example:
df = new SimpleDateFormat("dd");
df.setLenient(false);
d = df.parse("31");
Now d is 01/31/1970, so it is valid. Again SimpleDateFormat assumes month 1,
year 1970.
Now I think that you should better of relaying in a regexp validator or some
custom functionality since what you are trying to validate definitively is not
a date.
Perhaps DateValidator could detect those incomplete cases. May be it could
check the pattern parameter and try to ask if it include the following sub
strings: d or dd or ddd, M or MM or MMM, yy or to detect those invalid
cases?
Anyway, as long as DateValidator is relying on SimpleDateFormat I see no simple
solution here.
> DateValidator considers "02/29" with format "MM/dd" invalid
> ---
>
> Key: VALIDATOR-221
> URL: https://issues.apache.org/jira/browse/VALIDATOR-221
> Project: Commons Validator
> Issue Type: Bug
>Affects Versions: 1.3.1 Release
> Environment: Windows XP, Java 1.5.0_04
>Reporter: Carsten Drossel
>Priority: Minor
>
> When the date pattern contains only day and month the isValid(..)-method of
> DateValidator returns false for the value Feb. 29th.
> Here is a JUnit test that fails:
> public void testFebruary29th() throws Exception {
> assertTrue( DateValidator.getInstance().isValid( "02/29", "MM/dd", true ) );
> }
> The DateValidator uses the parse(..)-method of SimpleDateFormat for the
> validation. This method appears to complete any date using 01/01/1970 00:00.
> Since 1970 was not a leap year a ParseException is thrown for the input
> "02/29" with the format "MM/dd" because 02/29/1970 is not a valid date.
> But IMHO "02/29" should be valid. An example where it makes sense is a search
> for persons with a certain birthday.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-216) UrlValidator rejects top-level domains (TLDs) with more than 4 characters
[ http://issues.apache.org/jira/browse/VALIDATOR-216?page=all ] Gabriel Belingueres updated VALIDATOR-216: -- Attachment: TLDConstants.java > UrlValidator rejects top-level domains (TLDs) with more than 4 characters > - > > Key: VALIDATOR-216 > URL: http://issues.apache.org/jira/browse/VALIDATOR-216 > Project: Commons Validator > Issue Type: Bug >Affects Versions: 1.3.1 Release >Reporter: Kenji Matsuoka >Priority: Minor > Attachments: TLDConstants.java > > > org.apache.commons.validator.UrlValidator#isValidAuthority rejects top-level > domains (TLDs) with more than four characters. There are now at least two > TLDs with more characters, .museum and .travel. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VALIDATOR-216) UrlValidator rejects top-level domains (TLDs) with more than 4 characters
[
http://issues.apache.org/jira/browse/VALIDATOR-216?page=comments#action_12458009
]
Gabriel Belingueres commented on VALIDATOR-216:
---
We could modify it this way (surely there are better ways, but this will quicly
patch it for the medium term:
1) Make UrlValidator implement the TLDConstants interface.
2) Replace:
if (topLevel.length() < 2 || topLevel.length() > 4) {
for this:
if (Arrays.binarySearch(TLDs, topLevel.toUpperCase()) < 0) {
See attached file for the TLDConstants.java file, which can be easily
regenerated each time a new release is about to be generated (though I don't
really know how often TLDs varies, but I could guess that not much).
Gabriel
> UrlValidator rejects top-level domains (TLDs) with more than 4 characters
> -
>
> Key: VALIDATOR-216
> URL: http://issues.apache.org/jira/browse/VALIDATOR-216
> Project: Commons Validator
> Issue Type: Bug
>Affects Versions: 1.3.1 Release
>Reporter: Kenji Matsuoka
>Priority: Minor
> Attachments: TLDConstants.java
>
>
> org.apache.commons.validator.UrlValidator#isValidAuthority rejects top-level
> domains (TLDs) with more than four characters. There are now at least two
> TLDs with more characters, .museum and .travel.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (EL-13) Boolean bean property not found due to Introspector limitation
[ http://issues.apache.org/jira/browse/EL-13?page=comments#action_12429790
]
Gabriel Belingueres commented on EL-13:
---
AFAIK, I think this is OK regarding the JavaBean spec.
Reading sections 8.3.1and 8.3.2, I see that the get/set naming convention will
work allways, but the is/set is a special case for boolean only...just a little
sintactic sugar.
Further, please see that there is no uniformity even in the same document.
There is no equivalent naming convention for indexed boolean properties, i.e.
you can't write:
public boolean is(int a);
Anyway, regarding the patch it looks kind of expensive: there is a nested
interation inside findMissingMethods, and in foundTheReadMethod you compare
with equalsIgnoreCase, which doesn't look right, since method names are case
sensitive.
Gabriel
> Boolean bean property not found due to Introspector limitation
> --
>
> Key: EL-13
> URL: http://issues.apache.org/jira/browse/EL-13
> Project: Commons EL
> Issue Type: Bug
>Affects Versions: 1.0 Final
> Environment: Windows XP, Java 1.5.0_07-b03, Tomcat 5.5.17
>Reporter: Joe Littlejohn
> Attachments: AdditionalIntrospection.java, el_exception.txt
>
>
> There is a bug in the java.beans.Introspector which means that it cannot find
> the read method for a property of Boolean type (because it looks for the "get"
> prefix, not the "is" prefix). This is arguably the expected behaviour of the
> Introspector, however since the java.beans.PropertyDescriptor acts differently
> (it can identify the property read method), this inconsistency hints it's a
> bug.
> Also, with the advent of autoboxing, developers are supposed to be able to
> free
> themselves from primitive types.
> The commons EL library is affected by this bug, so using an interface like: -
> public interface Bean {
> Boolean isEnabled();
> }
> and an expression like: -
> ${bean.enabled}
> fails with an ELException saying that the property could not be found (see
> attached log snippet).
> WebLogic does not suffer from this problem, presumably because they implement
> their own EL parser (don't use commons.el) which doesn't use the
> Introspector. I
> have written a suggested workaround for this problem which would allow the
> commons.el library to continue its use of the Introspector, but deal with this
> flaw (see attached). The AdditionalIntrospection could be used in the
> BeanInfoManager.initialise() method, like so: -
> PropertyDescriptor [] pds = mBeanInfo.getPropertyDescriptors ();
> pds = AdditionalIntrospection.findMissingMethods(mBeanClass, pds); // new step
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VALIDATOR-188) Extend ISBN validator to support smooth transition to ISBN-13 / EAN-13 standard
[ http://issues.apache.org/jira/browse/VALIDATOR-188?page=comments#action_12423666 ] Gabriel Belingueres commented on VALIDATOR-188: --- Hi, I've seen that this functionality will be included in version 1.4, which will be centered in eliminating the ORO dependency by migrating to Java 1.4. I have two arguments I can think that this may be not the best choice. 1) From the business stand point, we have a window of opportunity that we must take advantage of. I don't personally know how much time it takes to make a new release, but if it is a period such as a month or so for each one, then waiting about two months for a functionality that is already coded doesn't make many sense to me. 2) From a technical stand point, there are many places that will be reluctant to migrate to Java 1.4 for applications that are in production just because of the ISBN thing (though it may be a good excuse anyway) since they are basically just numeric calculations. There are many conservative managers following the philosophy "if it is not broken, don't fix it". Also, the current implementation of ISBN validator uses almost trivial examples of regular expressions, so migrating later to Java 1.4 regexp I don't see it like a big problem (as it could be the email validation code that uses specific Perl semantics in the regexps, then making it more difficult to migrate). Regards, Gabriel > Extend ISBN validator to support smooth transition to ISBN-13 / EAN-13 > standard > --- > > Key: VALIDATOR-188 > URL: http://issues.apache.org/jira/browse/VALIDATOR-188 > Project: Commons Validator > Issue Type: Improvement > Components: Routines >Affects Versions: 1.2.0 Release >Reporter: Gabriel Belingueres > Fix For: 1.4.0 > > Attachments: ISBNValidator.java, ISBNValidatorTest.java > > > Hi, > I just revised the ISBNValidator to support ISBN-13 / EAN-13 standards, which > will begin its use on 2007 (see > http://www.isbn.org/standards/home/isbn/transition.asp for more information). > To support a smooth transition, I changed the isValid(String) method so that > it can validate all ISBN-10, ISBN-13 and EAN-13 codes. In addition, I created > methods for validating only ISBN-10, only EAN-13, or ISBN-13 / EAN-13 codes. > This way, anyone could have support for > the new standard by just changing the .jar file. > Please note that I've changed a few method names, and you may want to check > the code style to match the existing one (however I tried to follow it > whenever I could). > Regards, > Gabriel Belingueres -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VALIDATOR-196) GenericValidator#matchRegexp
[
http://issues.apache.org/jira/browse/VALIDATOR-196?page=comments#action_12421100
]
Gabriel Belingueres commented on VALIDATOR-196:
---
I think it is not a bug.
ORO Regexp require you to put a beginning and trailing slash to the expression:
GenericValidator.matchRegexp("as*&^%dfasd1314213","/[a-zA-Z0-9]*/")
I think the ORO dependency will be removed to Java 1.4 own regexp
implementation instead, but I don't know when will be happening.
Gabriel
> GenericValidator#matchRegexp
>
>
> Key: VALIDATOR-196
> URL: http://issues.apache.org/jira/browse/VALIDATOR-196
> Project: Commons Validator
> Issue Type: Bug
>Affects Versions: 1.3.1
> Environment: Windows 2000 ; J2SDK 1.4.2 ; Eclipse 3.1.2
>Reporter: lutianxiang
>
> GenericValidator.matchRegexp("as*&^%dfasd1314213","[a-zA-Z0-9]*");
> User this method cannot get FALSE value
> In this method Source like this...
> .
> return matcher.match("/" + regexp + "/", value);
> should be
> ..
> return matcher.match("//" + regexp + "//", value);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-185) [beanutils] Try to align BeanUtils with JSTL standard tags
[ http://issues.apache.org/jira/browse/BEANUTILS-185?page=comments#action_12415771 ] Gabriel Belingueres commented on BEANUTILS-185: --- I take your point though about having a way to indicate to the BasicDynaBean whether a modifiable to read only instance should be created - also the BasicDynaClass too since its newInstance() method creates BasicDynaBean. I think you should that option everywhere inside the library where a BasicDynaBean is instantiated. > [beanutils] Try to align BeanUtils with JSTL standard tags > -- > > Key: BEANUTILS-185 > URL: http://issues.apache.org/jira/browse/BEANUTILS-185 > Project: Commons BeanUtils > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Gabriel Belingueres > Priority: Minor > Attachments: AbstractRowSetDynaClass.java, BasicDirectAccessDynaBean.java, > BasicDirectAccessDynaBeanTestCase.java, BasicIndirectAccessDynaBean.java, > DirectAccessDynaBean.java, DirectRowSetDynaClass.java, > DynaBeanMapDecorator.java, DynaBeanMapDecoratorTestCase.java, > IndirectAccessDynaBean.java, IndirectRowSetDynaClass.java, beanutil-diff.txt > > Hi, > I've done some modifications to the beanutils package to better support the > use > of DynaBeans with the JSTL tags. Some of the changes are discussed in this > thread of the commons-user mailing list: > http://marc.theaimsgroup.com/?l=jakarta-commons-user&m=114669123403779&w=2 > I attach the diff file that comprises changes to the RowSetDynaClass.java > file > and build.xml file (since I added a TestCase.) Note: Please try to filter > carefully the diffs in the build.xml file since they include some local > settings I have for compilation on my machine. :-( > Together with the diff file, I attach the new java files added to the package. > Regards, > Gabriel Belingueres > [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-185) [beanutils] Try to align BeanUtils with JSTL standard tags
[ http://issues.apache.org/jira/browse/BEANUTILS-185?page=comments#action_12415729 ] Gabriel Belingueres commented on BEANUTILS-185: --- OK but I don't see anything different here that changes my mind about what I said about the existing createDynaBean() in RowSetDynaClass - your new direct/indirect DynaClass implementations could extend RowSetDynaClass and override that method. Of course you can extend RowSetDynaClass directly to override the createDynaBean() method. If you decide both to do this and decide to keep the createDynaBean() method, I guess you should add a remark in the javadocs to show that the "best practice" for creating a different kind of DynaBean for the RowSet is by overriding createDynaBean() method. This should be sufficient guide for everyone. RowSetDynaClass is still the DynaClass (i.e. property meta data) for the individual "row" DynaBeans (in this case BasicDynaBean) and so I would disagree with you - newInstance() is exactly what should be called. Just because it bizarely creates a List of those DynaBeans as well doesn't change that. If this work as you said, then I guess the class name RowSetDynaClass is very confusing/misleading, because when you call newInstance, it creates an instance of a single row of a RowSet, not the whole RowSet. A better name would be RowDynaBean? In addition, I see a problem here because creating a new instance make sense ONLY when iterating over the java.sql.ResultSet; i.e. only make sense calling it from the inside, never from the outside (the ResultSet could be already closed). Now, the newInstance() is public, and createDynaBean() is protected...this also makes sense to me. Perhaps the best course of action would be to separate the two concepts of RowSet and the Row itself? We know that the DynaBean concept fits very well with the Row concept, but the RowSet I see it more like an utility class to create the list of Rows and then I can discard it whenever I want (usually in my applications I'm interested in the dynabean list, not the RowSetDynaClass per se) Also I'm happy to add getMap() method to BasicDynaBean which returns a Map decorator - which would provide the "indirect" access method of your requirement. Don't know if this is a good idea and I suppose we think different here. >From a performance point of view, you probably want to add a boolean >isReadonly flag as a parameter in the BasicDynaBean constructor so that you >can add a private Map instance variable representing the unmodifiable map of >properties (if isReadonly==true, or the DynaBeanMapDecorator if false), so >that whenever any of the dynabean clients call the getMap() method, only the >first time is the unmodifiable map created. (This performance optimization is >probably to make a difference if you think that the dynabean will be >referenced from several JSTL expressions in the same JSP page.) Now if my particular application never have to deal with this new getMap() functionality: Why would it have to pay for this new functionality/overhead on the BasicDynaBean? May be I'm over complicating things...don't know what is the policy here in this cases. Gabriel > [beanutils] Try to align BeanUtils with JSTL standard tags > -- > > Key: BEANUTILS-185 > URL: http://issues.apache.org/jira/browse/BEANUTILS-185 > Project: Commons BeanUtils > Type: Improvement > Environment: Operating System: other > Platform: Other > Reporter: Gabriel Belingueres > Priority: Minor > Attachments: AbstractRowSetDynaClass.java, BasicDirectAccessDynaBean.java, > BasicDirectAccessDynaBeanTestCase.java, BasicIndirectAccessDynaBean.java, > DirectAccessDynaBean.java, DirectRowSetDynaClass.java, > DynaBeanMapDecorator.java, DynaBeanMapDecoratorTestCase.java, > IndirectAccessDynaBean.java, IndirectRowSetDynaClass.java, beanutil-diff.txt > > Hi, > I've done some modifications to the beanutils package to better support the > use > of DynaBeans with the JSTL tags. Some of the changes are discussed in this > thread of the commons-user mailing list: > http://marc.theaimsgroup.com/?l=jakarta-commons-user&m=114669123403779&w=2 > I attach the diff file that comprises changes to the RowSetDynaClass.java > file > and build.xml file (since I added a TestCase.) Note: Please try to filter > carefully the diffs in the build.xml file since they include some local > settings I have for compilation on my machine. :-( > Together with the diff file, I attach the new java files added to the package. > Regards, > Gabriel Belingueres > [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira ---
[jira] Updated: (VALIDATOR-190) EmailValidator allows control characters (ASCII 0-31)
[ http://issues.apache.org/jira/browse/VALIDATOR-190?page=all ]
Gabriel Belingueres updated VALIDATOR-190:
--
Attachment: EmailValidator-diff.txt
EmailTest-diff.txt
Hi,
I'm uploading the patch files that would solve the issue (ie not allowing ASCII
0..31 in the local part of the email address), along with a test case.
Gabriel
> EmailValidator allows control characters (ASCII 0-31)
> -
>
> Key: VALIDATOR-190
> URL: http://issues.apache.org/jira/browse/VALIDATOR-190
> Project: Commons Validator
> Type: Bug
> Versions: 1.3.0 Release
> Reporter: Cott
> Priority: Minor
> Attachments: EmailTest-diff.txt, EmailValidator-diff.txt
>
> EmailValidator allows ASCII 0 - 31 in an email address.
> According to RFC 821, these are forbidden.
> import org.apache.commons.validator.EmailValidator;
> public class Test {
> public static void main(String[] args) {
> EmailValidator ev = EmailValidator.getInstance();
> String email ="[EMAIL PROTECTED]";
> System.err.println(ev.isValid(email));
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (BEANUTILS-185) [beanutils] Try to align BeanUtils with JSTL standard tags
[ http://issues.apache.org/jira/browse/BEANUTILS-185?page=comments#action_12415646 ] Gabriel Belingueres commented on BEANUTILS-185: --- Hi Niall (answers starting with *) Thanks for the patches, however I'm not that keen on implementing what you propose. 1) In regards to RowSetDynaClass and the createDynaBean() method, the contract of that method is IMO clear since the return type is a DynaBean - if a specific implementation was required then the return type should have been the specific implementation (such as BasicDynaBean). Therefore I'm against introducing your new AbstractRowSetDynaClass as IMO its unnecessary. * I introduced the AbstractRowSetDynaClass class for two reasons I can remember of now: a) To tell with the code by itself that there is a Factory Method createDynaBean() and it is OK to create your own type of RowSetDynaClass which create the kind of row beans you want. b) The introduction of the AbstractRowSetDynaClass class made it really easy to introduce both the DirectRowSetDynaClass and IndirectRowSetDynaClass (we only implement the createDynaBean() method) Looking at RowSetDynaClass I am surprised there is a createDynaBean() method at all, since DynaClass defines a perfectly good public newInstance() method for that very purpose. IMO we should deprecate the createDynaBean() method and switch to using newInstance() instead. * If I understood it well, I think newInstance() would not be an adequate method to use in this situation. From the DynaClass javadoc: "A DynaClass is a simulation of the functionality of java.lang.Class for classes implementing the DynaBean interface". If in a regular Java program I call newInstance() on the java.util.ArrayList class, I would not expect to be returned a new Object instance because it is the type of objects an ArrayList can hold, but I would expect to be returned an instance of a new ArrayList. With RowSetDynaClass I think it happens the same: calling newInstance() one would expect I get returned a new RowSetDynaBean (which it is a concept that doesn't exist!), not a BasicDynaBean instance (which is the type of the elements in the RowSet. I think that it is why when called it throws an UnsupportedOperationException. May be we need to replace RowSetDynaClass with something more meaningful? RowSetDynaClass is like an abstract class: We have the class available but we can't instantiate it. Maybe we need to align the definition with the standard JDBC RowSet implementation? 2) DirectAccessDynaBean gives me some concern since it is both a Map and a DynaBean and I'm unsure whether this may confuse other BeanUtils functionality or cause it to act inconsistently. Even if that didn't turn out to be a problem I'm against this "super" interface as I don't see how this provides any advantage/benefit over an object that implements the two interfaces separtely rather than this combined one. * I agree that this is dangerous. I wanted to use JSTL tags like with my dynabeans, so the combination of DynaBean and Map seemed a good idea. The BasicDirectAccessDynaBean implementation I provided treats the dynabean (when accessed from a Map method) as immutable. In the one hand, read access was the only thing I needed since I use JSTL with a model 2 mvc framework (so no writing is performed in the JSP pages), and in the other hand, I wrapped the map in a Collections.unmodifiableMap to protect the dynabean integrity from writing. I tend to agree that this super interface may be opening the door for bugs. However, I think that before dropping it we could consult with a JSF implementer to see if it would simplify the implementation of expressions like , which will read and WRITE on the dynabean. An alternative thought I had to this is to provide a Map implementation to decorate DynaBeans - that way any DynaBean could be decorated to look like a Map? * This can be a good idea, however if you wrap a DynaBean with a Map interface, then it is no longer a DynaBean. Don't know if this loss of functionality can be counter productive or not, but would cover the requirement of being JSTL friendly. Also, this will require to either change the RowSetDynaClass.copy() implementation to wrap the dynabean with an optional Map, or (easier I think) add a getRowsAsMap() method which would create a list of Map-wrapped dynabeans. 3) On the IndirectAccessDynaBean I'm afraid I don't see any benefit in JSTL terms since simply adding a getMap() method to a DynaBean implementation will enable it to be used by JSTL. Also perhaps it would have wider benefit if it was simply an interface with that one method (rather than extending DynaBean) - that way any object could provide a Map representation of itself. * I agree in both. The reasons I added this interface were: a) To have the alternate method to access a dynabean in JSTL. b) Added the exact getMap() method name to align the i
[jira] Commented: (VALIDATOR-190) EmailValidator allows control characters (ASCII 0-31)
[
http://issues.apache.org/jira/browse/VALIDATOR-190?page=comments#action_12414623
]
Gabriel Belingueres commented on VALIDATOR-190:
---
Hi Cott,
I found this other link on the net that may be helpful. Apparently, there are
some more chars that should be forbidden/discouraged to use in the local part
of the email address.
It may be worth take a look at it:
http://www.remote.org/jochen/mail/info/chars.html
Gabriel
> EmailValidator allows control characters (ASCII 0-31)
> -
>
> Key: VALIDATOR-190
> URL: http://issues.apache.org/jira/browse/VALIDATOR-190
> Project: Commons Validator
> Type: Bug
> Versions: 1.3.0 Release
> Reporter: Cott
> Priority: Minor
>
> EmailValidator allows ASCII 0 - 31 in an email address.
> According to RFC 821, these are forbidden.
> import org.apache.commons.validator.EmailValidator;
> public class Test {
> public static void main(String[] args) {
> EmailValidator ev = EmailValidator.getInstance();
> String email ="[EMAIL PROTECTED]";
> System.err.println(ev.isValid(email));
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (VALIDATOR-190) EmailValidator allows control characters (ASCII 0-31)
[
http://issues.apache.org/jira/browse/VALIDATOR-190?page=comments#action_12414348
]
Gabriel Belingueres commented on VALIDATOR-190:
---
Hi,
RFC 821 is obsoleted by RFC 2821
.
I found this one on the net what may be worth looking: RFC 2822 (Internet
Message format) and RFC 2234 (Augmented BNF).
However it may well be a lot easier to post a question on the Apache Web server
list.
Gabriel
> EmailValidator allows control characters (ASCII 0-31)
> -
>
> Key: VALIDATOR-190
> URL: http://issues.apache.org/jira/browse/VALIDATOR-190
> Project: Commons Validator
> Type: Bug
> Versions: 1.3.0 Release
> Reporter: Cott
> Priority: Minor
>
> EmailValidator allows ASCII 0 - 31 in an email address.
> According to RFC 821, these are forbidden.
> import org.apache.commons.validator.EmailValidator;
> public class Test {
> public static void main(String[] args) {
> EmailValidator ev = EmailValidator.getInstance();
> String email ="[EMAIL PROTECTED]";
> System.err.println(ev.isValid(email));
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (VALIDATOR-188) Extend ISBN validator to support smooth transition to ISBN-13 / EAN-13 standard
[ http://issues.apache.org/jira/browse/VALIDATOR-188?page=all ] Gabriel Belingueres updated VALIDATOR-188: -- Attachment: ISBNValidator.java ISBNValidatorTest.java The modified ISBNValidator class and its test cases. Regards, Gabriel Belingueres > Extend ISBN validator to support smooth transition to ISBN-13 / EAN-13 > standard > --- > > Key: VALIDATOR-188 > URL: http://issues.apache.org/jira/browse/VALIDATOR-188 > Project: Commons Validator > Type: Improvement > Versions: 1.2 Final > Reporter: Gabriel Belingueres > Attachments: ISBNValidator.java, ISBNValidatorTest.java > > Hi, > I just revised the ISBNValidator to support ISBN-13 / EAN-13 standards, which > will begin its use on 2007 (see > http://www.isbn.org/standards/home/isbn/transition.asp for more information). > To support a smooth transition, I changed the isValid(String) method so that > it can validate all ISBN-10, ISBN-13 and EAN-13 codes. In addition, I created > methods for validating only ISBN-10, only EAN-13, or ISBN-13 / EAN-13 codes. > This way, anyone could have support for > the new standard by just changing the .jar file. > Please note that I've changed a few method names, and you may want to check > the code style to match the existing one (however I tried to follow it > whenever I could). > Regards, > Gabriel Belingueres -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (VALIDATOR-188) Extend ISBN validator to support smooth transition to ISBN-13 / EAN-13 standard
Extend ISBN validator to support smooth transition to ISBN-13 / EAN-13 standard --- Key: VALIDATOR-188 URL: http://issues.apache.org/jira/browse/VALIDATOR-188 Project: Commons Validator Type: Improvement Versions: 1.2 Final Reporter: Gabriel Belingueres Hi, I just revised the ISBNValidator to support ISBN-13 / EAN-13 standards, which will begin its use on 2007 (see http://www.isbn.org/standards/home/isbn/transition.asp for more information). To support a smooth transition, I changed the isValid(String) method so that it can validate all ISBN-10, ISBN-13 and EAN-13 codes. In addition, I created methods for validating only ISBN-10, only EAN-13, or ISBN-13 / EAN-13 codes. This way, anyone could have support for the new standard by just changing the .jar file. Please note that I've changed a few method names, and you may want to check the code style to match the existing one (however I tried to follow it whenever I could). Regards, Gabriel Belingueres -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
