Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Javadoc of URL constraint is really misleading

Description

The implementation of the URL validator is really odd because it basically relies on the constructor of java.net.URL. This has been discussed here before (HV-406, HV-513) and I understand and accept there's no perfect solution.

However, I'd expect that this be clearly stated in the Javadoc of the @URL constraint. IMO despite https://hibernate.atlassian.net/browse/HV-437#icft=HV-437 this is still not the case. I see 2 obvious issues:

  1. Type Javadoc claims that "Per default the constraint verifies that the annotated value conforms to RFC2396". Doesn't https://hibernate.atlassian.net/browse/HV-513#icft=HV-513 prove that statement wrong? If RFC2396 were really supported wouldn't the validator have to accept URLs such as ldap://... or sip://...?

  2. The annotation attribute Javadoc contradicts the type Javadoc. Because of 1. a statement like "Per default any protocol is allowed" (port attribute) is not correct.

Environment

None

relates to

Activity

Show:

Gunnar MorlingOctober 22, 2014 at 7:23 AM

Marcel StörOctober 5, 2014 at 8:35 PM

Do you have any concrete wording in mind?

No, I don't, sorry.

I think we have to separate between the constraint @URL and its constraint validator implementation

Hhmm, true, that's a good point. Still, the constraint makes certain promises (must do so) as for the valid data range. The chosen implementation must adhere to that. Hence, I see the Javadoc of the constraint as a set of requirements for the validator implementation. If the constraint documentation claims that it ensures all values conform to RFC2396 then the validator implementation must fulfill that.

Hardy FerentschikOctober 2, 2014 at 8:00 PM

Hi , thanks for the issue report. Do you have any concrete wording in mind?

Also, I think we have to separate between the constraint @URL and its constraint validator implementation, in our case URLValidator. The latter is atm using the java.net.URL constructor in an attempt to implement the @URL constraint. Its limitations should imo really be documented there. Maybe we could add a note to @URL, saying that a constraint validator implementation of this constraint needs to support the 'http' protocol, but potentially could provide more.

The URLValidator documentation could then deal with the fact that in this particular case java.net.URL is used and that more protocols can be supported by installing more protocol handlers.

Fixed

Details

Assignee

Reporter

Bug Testcase Reminder (view)

Bug reports should generally be accompanied by a test case!

Bug Testcase Reminder (edit)

Bug reports should generally be accompanied by a test case!

Participants

Gunnar Morling
Hardy Ferentschik
Marcel Stör

Original estimate

Time tracking

No time logged0.5h remaining

Components

Fix versions

Affects versions

Priority

Created May 3, 2014 at 8:44 PM
Updated October 22, 2014 at 2:50 PM
Resolved October 22, 2014 at 7:22 AM

Flag notifications