Opened 17 years ago
Closed 17 years ago
#25 closed defect (fixed)
JDOM cannot handle metadata attributes with namespace prefix
Reported by: | Owned by: | simonp | |
---|---|---|---|
Priority: | major | Milestone: | v2.1 beta 2 |
Component: | User interface (web) | Version: | |
Keywords: | JDOM, namespace awareness, advanced view | Cc: |
Description
An example: consider this element in the INSPIRE metadata profile from ISO 19139:
INSPIRE metadata level: Discovery level 1 INSPIRE element: Date - temporal extent ISO definition: Date and time for the content of the dataset INSPIRE category: Temporal Reference INSPIRE code: A.2.2.1 INSPIRE obligation: Conditional
Now, this could (or must) be implemented using a GML element like TimePeriod, for instance:
<gmd:MD_Metadata xmlns:gml="http://www.opengis.net/gml" ...> <!-- ... --> <!-- ... --> <!-- ... --> <gmd:identificationInfo> <gmd:MD_DataIdentification> <!-- ... --> <!-- ... --> <!-- ... --> <gmd:extent> <gmd:EX_Extent> <gmd:temporalElement> <gmd:EX_TemporalExtent> <gmd:extent> <gml:TimePeriod gml:id="id"> <gml:beginPosition>2007-05-28T12:34:56</gml:beginPosition> <gml:endPosition>2007-05-28T12:34:56</gml:endPosition> </gml:TimePeriod> </gmd:extent> </gmd:EX_TemporalExtent> </gmd:temporalElement> </gmd:EX_Extent> </gmd:extent> </gmd:MD_DataIdentification> </gmd:identificationInfo> <!-- ... --> <!-- ... --> <!-- ... --> </gmd:MD_Metadata>
The GML attribute "gml:id" is required, and it requires the namespace prefix to be valid, but JDOM cannot handle it. It tries to create a classname with it, also using the colon (:) which is invalid in Java. The metadata can be validated and saved into the catalogue, but when I try to show it in advanced view, I receive this error:
HTTP Status 400 - Cannot build ServiceRequest Cause : The name "_117_gml:id" is not legal for JDOM/XML elements: Element names cannot contain colons. Error : org.jdom.IllegalNameException Stack : org.jdom.IllegalNameException: The name "_117_gml:id" is not legal for JDOM/XML elements: Element names cannot contain colons. at org.jdom.Element.setName(Element.java:206) at org.jdom.Element.<init>(Element.java:140) at org.jdom.Element.<init>(Element.java:152) at jeeves.server.sources.ServiceRequestFactory.getMultipartParams(ServiceRequestFactory.java:256) at jeeves.server.sources.ServiceRequestFactory.extractParameters(ServiceRequestFactory.java:214) at jeeves.server.sources.ServiceRequestFactory.create(ServiceRequestFactory.java:136) at jeeves.server.sources.http.JeevesServlet.execute(JeevesServlet.java:146) at jeeves.server.sources.http.JeevesServlet.doPost(JeevesServlet.java:98) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) ...
This is also a known bug in JDOM in general, for instance:
Change History (6)
follow-up: 2 comment:1 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 by , 17 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:3 by , 17 years ago
Problem isn't JDOM ":" in attributes debug - although the bug manifests itself when you use an attribute with a namespace, it actually relates to the fact that JDOM is being asked to create an XML element from what is returned by the html form in the editor - this happens to be an attribute with a colon in the name. Can you let me know where else you've found this problem as I have a fix ready to commit to the trunk and would like to hear about your testing?
Thanks! Simon Pigot sppigot@…
follow-up: 5 comment:4 by , 17 years ago
Owner: | changed from | to
---|---|
Status: | reopened → new |
Replying to joeri.theelen@gim.be:
An example: consider this element in the INSPIRE metadata profile from ISO 19139:
INSPIRE metadata level: Discovery level 1 INSPIRE element: Date - temporal extent ISO definition: Date and time for the content of the dataset INSPIRE category: Temporal Reference INSPIRE code: A.2.2.1 INSPIRE obligation: ConditionalNow, this could (or must) be implemented using a GML element like TimePeriod, for instance:
<gmd:MD_Metadata xmlns:gml="http://www.opengis.net/gml" ...> <!-- ... --> <!-- ... --> <!-- ... --> <gmd:identificationInfo> <gmd:MD_DataIdentification> <!-- ... --> <!-- ... --> <!-- ... --> <gmd:extent> <gmd:EX_Extent> <gmd:temporalElement> <gmd:EX_TemporalExtent> <gmd:extent> <gml:TimePeriod gml:id="id"> <gml:beginPosition>2007-05-28T12:34:56</gml:beginPosition> <gml:endPosition>2007-05-28T12:34:56</gml:endPosition> </gml:TimePeriod> </gmd:extent> </gmd:EX_TemporalExtent> </gmd:temporalElement> </gmd:EX_Extent> </gmd:extent> </gmd:MD_DataIdentification> </gmd:identificationInfo> <!-- ... --> <!-- ... --> <!-- ... --> </gmd:MD_Metadata>The GML attribute "gml:id" is required, and it requires the namespace prefix to be valid, but JDOM cannot handle it. It tries to create a classname with it, also using the colon (:) which is invalid in Java. The metadata can be validated and saved into the catalogue, but when I try to show it in advanced view, I receive this error:
HTTP Status 400 - Cannot build ServiceRequest Cause : The name "_117_gml:id" is not legal for JDOM/XML elements: Element names cannot contain colons. Error : org.jdom.IllegalNameException Stack : org.jdom.IllegalNameException: The name "_117_gml:id" is not legal for JDOM/XML elements: Element names cannot contain colons. at org.jdom.Element.setName(Element.java:206) at org.jdom.Element.<init>(Element.java:140) at org.jdom.Element.<init>(Element.java:152) at jeeves.server.sources.ServiceRequestFactory.getMultipartParams(ServiceRequestFactory.java:256) at jeeves.server.sources.ServiceRequestFactory.extractParameters(ServiceRequestFactory.java:214) at jeeves.server.sources.ServiceRequestFactory.create(ServiceRequestFactory.java:136) at jeeves.server.sources.http.JeevesServlet.execute(JeevesServlet.java:146) at jeeves.server.sources.http.JeevesServlet.doPost(JeevesServlet.java:98) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) ...This is also a known bug in JDOM in general, for instance:
comment:6 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Replying to acarboni: According to my testing of Geonetwork 2.1 final release (and the testing of others as well), this problem has not been fixed.