[ https://hibernate.onjira.com/browse/HV-499?page=com.atlassian.jira.plugin... ] Hardy Ferentschik commented on HV-499: -------------------------------------- How would you know how a relative URL looks like? Or you just talking http? Can you provide some examples and use cases. Would a pattern constraint work? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HV-499?page=com.atlassian.jira.plugin... ] Ted Bergeron commented on HV-499: --------------------------------- http://docs.oracle.com/javase/6/docs/api/java/net/URI.html The simple explanation is just a path, with http in mind. The relative URI for this page is: /browse/HV-499. I think the simplest implementation is: {code} String stringURI = "/browse/HV-499"; try { new URI(stringURI); // Valid } catch (URISyntaxException e) { // Invalid } {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HV-499?page=com.atlassian.jira.plugin... ] Hardy Ferentschik updated HV-499: --------------------------------- Fix Version/s: 4.3.0.CR1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HV-499?page=com.atlassian.jira.plugin... ] Hardy Ferentschik edited comment on HV-499 at 4/10/12 1:09 PM: --------------------------------------------------------------- Throwing our some ideas: * Obviously we could create an _@URI_ constraint. However, the URI constructor (as well as the URL constructor) are only applying very weak validation of the URL/URI. A _@URI_ constraint would for that reason also require a regexp part * An alternative is to "allow" relative URLs w/ the _@URL_ constraint. I think this can be achieved while staying backwards compatible. In this case you would have to specify, however, at least the protocal, eg _@URL(protocol="http")_. See also - https://github.com/hferentschik/hibernate-validator/commit/acaddf789c284d... * Yet another (backwards compatible) solution could be to add a _regexpOnly_ flag which is defaulted to _false_. If set to _true_ the validation only uses regular expression. Of course this requires that the user specifies a regexp which works for example for absolute and relative URLs. Independent from _@URI_ and _@URL_ is there a need for something like _@Path_ and/or _@File_? WDYT? was (Author: hardy.ferentschik): Just throwing our some ideas: * Obviously we could create an _@URI_ constraint. However, the URI constructor (as well as the URL constructor) are only applying very weak validation of the URL/URI. A _@URI_ constraint would for that reason also require a regexp part * An alternative is to "allow" relative URLs w/ the _@URL_ constraint. I think this can be achieved while staying backwards compatible. In this case you would have to specify, however, at least the protocal, eg _@URL(protocol="http")_. See also - https://github.com/hferentschik/hibernate-validator/commit/acaddf789c284d... * Yet another (backwards compatible) solution could be to add a _regexpOnly_ flag which is defaulted to _false_. If set to _true_ the validation only uses regular expression. Of course this requires that the user specifies a regexp which works for example for absolute and relative URLs. Independent from _@URI_ and _@URL_ is there a need for something like _@Path_ and/or _@File_? WDYT? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HV-499?page=com.atlassian.jira.plugin... ] Hardy Ferentschik commented on HV-499: -------------------------------------- {quote} I think @URI and relative URLs are different kinds of things, probably we should handle them separately. {quote} Sure. I was not implying that we should mix them together. The usecase, however, was to support relative URLs and I want to explore different solutions. {quote} AFAIK relative URLs are only valid within the context of another URL, see we might add an attribute context() to @URL which specifies this context. We then could use the URL(URL context, String spec) constructor for validation (I think that's what you suggested to use protocol for). {quote} Right, the commit I was linking to was basically using the protocol string to create a context URL. During validation it then uses the _URL(URL context, String spec)_ constructor. I did not see the need for a new parameter _context_, but that's an additional possibility. {quote} On the other hand I think one would always need an additional regular expression to specify the structure of the relative URL and I'm wondering what one actually gains by applying the @URL constraint to relative URLs at all? Maybe a simple @Pattern would suffice? {quote} +1 The biggest problem is that the URL constructor (the same for the URI constructor btw) don't (or very sparingly) validate the _spec_ string. The RFC places much more constraints on URI/URL. Using the _URL_ in _URLValidator_ is really more of a very simple solution for the most basic use cases. I expect that for more advanced use cases need to use the _regexp_ as well. We had long discussion whether _URLValidator_ should not purely be regular expression based however, it is hard to find an expression which really would be RFC compliant (if it even exit). For this reason we settled for the _URL_ + regexp approach. A _@Pattern_ would definitely work, but by using _@URL_ adds some more context information (it is not just any odd pattern the string has to match, it is a (part) of a URL). The _regexpOnly_ flag might be worth exploring. We could collect a bunch of existing regular expressions and add them as constants to _@URL_ for the user to chose from. Or we just leave things as they are and they "use @Pattern" ;-) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HV-499?page=com.atlassian.jira.plugin... ] Hardy Ferentschik resolved HV-499. ---------------------------------- Resolution: Won't Fix Fix Version/s: (was: 4.3.0.CR1) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HV-499?page=com.atlassian.jira.plugin... ] Hardy Ferentschik edited comment on HV-499 at 4/11/12 1:01 PM: --------------------------------------------------------------- In the lights of the latest discussion (on hibernate-dev) I fully agree :-) was (Author: hardy.ferentschik): In the lights of the latest discussion I fully agree :-) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira