3

Error thrown at execution suddenly:

org.xml.sax.SAXParseExceptionpublicId: 
http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd; lineNumber: 
1; columnNumber: 1; Deployment descriptor file META-INF/persistence.xml 
in archive [classes].  Premature end of file.



curl -v http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd
*   Trying 2600:1402:f000:392::f6b...
* TCP_NODELAY set
* Connected to xmlns.jcp.org (2600:1402:f000:392::f6b) port 80 (#0)
> GET /xml/ns/persistence/persistence_2_1.xsd HTTP/1.1
> Host: xmlns.jcp.org
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: AkamaiGHost
< Content-Length: 0
< Location: https://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd
< Cache-Control: max-age=0
< Expires: Sun, 23 Jun 2019 23:21:20 GMT
< Date: Sun, 23 Jun 2019 23:21:20 GMT
< Connection: keep-alive
<
 * Connection #0 to host xmlns.jcp.org left intact

This has not been a problem until today, and it appears this file is no longer available, but it is the standard reference for JPA persistence xml files:

HTTP/1.1 301 Moved Permanently

Does anyone else have this problem all the sudden. I cannot trace this to any change and I am experiencing this locally and on the server.

Siong Thye Goh
  • 3,518
  • 10
  • 23
  • 31
lifer
  • 31
  • 2

5 Answers5

2

The root of the problem seems to lie with Oracle and a concern for security, prompting a recent switch to the HTTPS protocol.
XMLMetaDataParser in org.apache.openjpa.lib.meta uses the SaxParser to read xml files in the parseNewResource method, which throws a premature end of file error. The error text is not particularly informative. However, resorting to XML Copy Editor [http://xml-copy-editor.sourceforge.net] to validate the schema reveals the error actually involved:
Fatal Error at line 0, column 0: unsupported protocol in URL. That information ultimately led me to this post, involving OpenEdge, dated 11/6/2018: [https://knowledgebase.progress.com/articles/Article/Unsupported-protocol-in-URL-reading-XML-from-a-URI].
Under Cause, it states, "The URL used before with HTTP is now redirecting to HTTPS."
And under Resolution, "This is a limitation within the Apache Xerces parser that the OpenEdge client is using internally. It only has limited URL support, so the parser is unable to process the URL redirection or an HTTPS URL similar to a webbrowser."
So the significant portion of the xml text identified in the error message as "systemId" is the http protocol statement, which is now redirected to https at Oracle's web site, causing the parsing error. This explains why code that ran just fine one day suddenly stopped working the following morning. Just how many ORM implementations have this limitation should be known fairly quickly.

Problem solved. I replaced
https://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd
with
https://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd
and the program now builds normally.

Robert Peake
  • 118
  • 8
  • OpenJPA has resolved the problem in their next release [OpenJPA-2791](https://issues.apache.org/jira/browse/OPENJPA-2791?filter=-2). – Robert Peake Jun 26 '19 at 15:51
1

I have the same problem since today. My quick fix was to change persistance.xml version from 2.1 to 1.0, it worked for me.

jin99
  • 13
  • 4
1

I resolved by changing http to https, so redirection (which is the problem) will not happen.

<? xml version = "1.0" encoding = "UTF-8"?>
<persistence version = "2.1"
xmlns = "https://xmlns.jcp.org/xml/ns/persistence" xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance"
xsi: schemaLocation = "https://xmlns.jcp.org/xml/ns/persistence https://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd">

Note: I had this problem with java 7 and glassfish 3, with java 8 and glassfish 4 it works.

Rafael Matiello
  • 11
  • 2
  • Thanks Rafael. I had hacked /etc/hosts to avoid the problem. On the day this change was made by Oracle, it did not appear that https url worked. I will implement this approach. – lifer Jul 11 '19 at 12:34
1

Fix for now is to modify your persistence.xml with the schema location:

http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd

Complete first line of persistence.xml looks like this:

<persistence xmlns="http://xmlns.jcp.org/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd" version="2.1">

More details and cause: The root cause of this issue is because of the multiple redirections from http to https and vice versa. I used curl to get to the final URL:

curl -v  http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd

HTTP/1.1 301 Moved Permanently Location: https://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd

curl -v https://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd

HTTP/1.1 301 Moved Permanently http://www.oracle.com/webfolder/technetwork/jsc/xml/ns/persistence/persistence_2_1.xsd

Use this in all of your persistence.xml. This worked for me.

NOTE: Oracle might change this final URL again. If at all they change the URL and your build fails, you know how to get to the final URL using curl command.

Thanks

Sumanth
  • 91
  • 1
  • 4
0

quick fix would be to make the URL http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd just return a 404 and no redirect to https. Like adding 127.0.0.1 xmlns.jcp.org to /etc/hosts.

Peter Foo
  • 1