We run a reverse proxy and use Openjdk8 and Jetty9.4 on a RHEL8 server. Jetty is working fine, and serving geoserver with no problems.
We implemented Elasticsearch as a daemon from the RPM source. Implementation checks with systemctl and with curl http://localhost:9200 show everything as expected. The ES config.properties in GN are as expected. The external data folder gn_dir contains the complete expected tree structure, with ES features, records, records_french and searchlogs. ES queries work.
A clean install of the postgres-postgis GN database yielded the expected tables structure with appropriate elements.
No errors are reported in the geonetwork log or in the jetty log. The Jetty log reports both geonetwork and geoserver as AVAILABLE.
However, when we attempt to access GN with a browser using https://{website}/geonetwork, we get a header response https://{website}/geonetwork/srv/eng/catalog.search complete with the standard earth-like logo, but with a completely blank screen. So it seems like it is trying to work.
We have also tried the h2 database with exactly the same results. We have opened port 8080 and tried http access, with the same result.
Any ideas as to what we are missing?
Hi Terry
Have you checked in the Chrome dev console if the request has any errors?
Regards,
Jose García
On Mon, Apr 19, 2021 at 4:14 AM Terry <terry.curran@anonymised.com> wrote:
We run a reverse proxy and use Openjdk8 and Jetty9.4 on a RHEL8 server.
Jetty is working fine, and serving geoserver with no problems.
We implemented Elasticsearch as a daemon from the RPM source.
Implementation checks with systemctl and with curl http://localhost:9200
show everything as expected. The ES config.properties in GN are as
expected. The external data folder gn_dir contains the complete
expected tree structure, with ES features, records, records_french and
searchlogs. ES queries work.
A clean install of the postgres-postgis GN database yielded the expected
tables structure with appropriate elements.
No errors are reported in the geonetwork log or in the jetty log. The
Jetty log reports both geonetwork and geoserver as AVAILABLE.
However, when we attempt to access GN with a browser using
https://{website}/geonetwork, we get a header response
https://{website}/geonetwork/srv/eng/catalog.search complete with the
standard earth-like logo, but with a completely blank screen. So it
seems like it is trying to work.
We have also tried the h2 database with exactly the same results. We
have opened port 8080 and tried http access, with the same result.
Any ideas as to what we are missing?
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
--
*Vriendelijke groeten / Kind regards,Jose García
<http://www.geocat.net/>Veenderweg 136721 WD BennekomThe NetherlandsT: +31
(0)318 416664 <+31318416664>Please consider the environment before printing
this email.*
Thank you. I had not thought to use the dev console- this is an excellent suggestion. The resulting log seems to indicate a "<" somewhere in the angularjs module.
How could I isolate this further?
gn_search_default.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6&:1 Uncaught SyntaxError: Unexpected token '<'
lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:20 Uncaught Error: [$injector:nomod] http://errors.angularjs.org/1.5.2/$injector/nomod?p0=gn_search
at lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:20
at lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:39
at b (lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:38)
at Object.module (lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:38)
at catalog.search:84
(anonymous) @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:20
(anonymous) @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:39
b @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:38
(anonymous) @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:38
(anonymous) @ catalog.search:84
lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:20 Uncaught Error: [$injector:nomod] http://errors.angularjs.org/1.5.2/$injector/nomod?p0=gn_search
at lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:20
at lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:39
at b (lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:38)
at Object.module (lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:38)
at catalog.search:91
(anonymous) @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:20
(anonymous) @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:39
b @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:38
(anonymous) @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:38
(anonymous) @ catalog.search:91
lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:20 Uncaught Error: [$injector:modulerr] http://errors.angularjs.org/1.5.2/$injector/modulerr?p0=gn_search_default&p1=Error%3A%20[%24injector%3Anomod]%20http%3A%2F%2Ferrors.angularjs.org%2F1.5.2%2F%24injector%2Fnomod%3Fp0%3Dgn_search_default
%20%20%20%20at%20https%3A%2F%2Fsoggy2.zoology.ubc.ca%2Fgeonetwork%2Fstatic%2Flib.js%3Fv%3D353b4ad4b87d6d708a27c5dab93b70109db683d6%3A20%3A416
%20%20%20%20at%20https%3A%2F%2Fsoggy2.zoology.ubc.ca%2Fgeonetwork%2Fstatic%2Flib.js%3Fv%3D353b4ad4b87d6d708a27c5dab93b70109db683d6%3A39%3A147
%20%20%20%20at%20b%20(https%3A%2F%2Fsoggy2.zoology.ubc.ca%2Fgeonetwork%2Fstatic%2Flib.js%3Fv%3D353b4ad4b87d6d708a27c5dab93b70109db683d6%3A38%3A211)
%20%20%20%20at%20https%3A%2F%2Fsoggy2.zoology.ubc.ca%2Fgeonetwork%2Fstatic%2Flib.js%3Fv%3D353b4ad4b87d6d708a27c5dab93b70109db683d6%3A38%3A454
%20%20%20%20at%20https%3A%2F%2Fsoggy2.zoology.ubc.ca%2Fgeonetwork%2Fstatic%2Flib.js%3Fv%3D353b4ad4b87d6d708a27c5dab93b70109db683d6%3A53%3A287
%20%20%20%20at%20p%20(https%3A%2F%2Fsoggy2.zoology.ubc.ca%2Fgeonetwork%2Fstatic%2Flib.js%3Fv%3D353b4ad4b87d6d708a27c5dab93b70109db683d6%3A21%3A355)
%20%20%20%20at%20g%20(https%3A%2F%2Fsoggy2.zoology.ubc.ca%2Fgeonetwork%2Fstatic%2Flib.js%3Fv%3D353b4ad4b87d6d708a27c5dab93b70109db683d6%3A53%3A135)
%20%20%20%20at%20db%20(https%3A%2F%2Fsoggy2.zoology.ubc.ca%2Fgeonetwork%2Fstatic%2Flib.js%3Fv%3D353b4ad4b87d6d708a27c5dab93b70109db683d6%3A57%3A164)
%20%20%20%20at%20c%20(https%3A%2F%2Fsoggy2.zoology.ubc.ca%2Fgeonetwork%2Fstatic%2Flib.js%3Fv%3D353b4ad4b87d6d708a27c5dab93b70109db683d6%3A34%3A463)
%20%20%20%20at%20xc%20(https%3A%2F%2Fsoggy2.zoology.ubc.ca%2Fgeonetwork%2Fstatic%2Flib.js%3Fv%3D353b4ad4b87d6d708a27c5dab93b70109db683d6%3A35%3A274)
at lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:20
at lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:54
at p (lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:21)
at g (lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:53)
at db (lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:57)
at c (lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:34)
at xc (lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:35)
at be \(lib\.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:34\)
at HTMLDocument\.<anonymous> \(lib\.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:322\)
at i \(lib\.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:7\)
(anonymous) @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:20
(anonymous) @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:54
p @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:21
g @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:53
db @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:57
c @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:34
xc @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:35
be @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:34
(anonymous) @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:322
i @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:7
fireWith @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:7
ready @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:7
J @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:7
extension.js:24 onMessage extension
ial.js:450 Clean the cache of the scraper (new onComplete event)
On 2021-04-18 11:15 p.m., Jose Garcia wrote:
Hi Terry
Have you checked in the Chrome dev console if the request has any errors?
Regards,
Jose García
On Mon, Apr 19, 2021 at 4:14 AM Terry <terry.curran@anonymised.com <mailto:terry.curran@anonymised.com>> wrote:
We run a reverse proxy and use Openjdk8 and Jetty9.4 on a RHEL8
server.
Jetty is working fine, and serving geoserver with no problems.
We implemented Elasticsearch as a daemon from the RPM source.
Implementation checks with systemctl and with curl
http://localhost:9200
show everything as expected. The ES config.properties in GN are as
expected. The external data folder gn_dir contains the complete
expected tree structure, with ES features, records, records_french
and
searchlogs. ES queries work.
A clean install of the postgres-postgis GN database yielded the
expected
tables structure with appropriate elements.
No errors are reported in the geonetwork log or in the jetty log.
The
Jetty log reports both geonetwork and geoserver as AVAILABLE.
However, when we attempt to access GN with a browser using
https://{website}/geonetwork, we get a header response
https://{website}/geonetwork/srv/eng/catalog.search complete with the
standard earth-like logo, but with a completely blank screen. So it
seems like it is trying to work.
We have also tried the h2 database with exactly the same results. We
have opened port 8080 and tried http access, with the same result.
Any ideas as to what we are missing?
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net
<mailto:GeoNetwork-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geonetwork-users
<https://lists.sourceforge.net/lists/listinfo/geonetwork-users>
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
<http://sourceforge.net/projects/geonetwork>
--
***
Vriendelijke groeten / Kind regards,
Jose García
<http://www.geocat.net/>
Veenderweg 13
6721 WD Bennekom
The Netherlands
T: +31 (0)318 416664 <tel:+31318416664>
Please consider the environment before printing this email.
***
Hi,
Indeed there seem to be an issue on the frontend side.
You can run the debug mode to check if the error is more releavant:
geonetwork/srv/eng/catalog.search?debug
Hope it helps
On Mon, Apr 19, 2021 at 9:33 AM Terry <terry.curran@anonymised.com> wrote:
Thank you. I had not thought to use the dev console- this is an
excellent suggestion. The resulting log seems to indicate a "<"
somewhere in the angularjs module.
How could I isolate this further?
gn_search_default.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6&:1
Uncaught SyntaxError: Unexpected token '<'
lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:20 Uncaught Error:
[$injector:nomod]
AngularJS
at lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:20
at lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:39
at b (lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:38)
at Object.module
(lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:38)
at catalog.search:84
(anonymous) @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:20
(anonymous) @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:39
b @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:38
(anonymous) @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:38
(anonymous) @ catalog.search:84
lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:20 Uncaught Error:
[$injector:nomod]
AngularJS
at lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:20
at lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:39
at b (lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:38)
at Object.module
(lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:38)
at catalog.search:91
(anonymous) @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:20
(anonymous) @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:39
b @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:38
(anonymous) @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:38
(anonymous) @ catalog.search:91
lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:20 Uncaught Error:
[$injector:modulerr]
AngularJS
at lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:20
at lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:54
at p (lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:21)
at g (lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:53)
at db (lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:57)
at c (lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:34)
at xc (lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:35)
at be (lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:34)
at HTMLDocument.<anonymous>
(lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:322)
at i (lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:7)
(anonymous) @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:20
(anonymous) @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:54
p @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:21
g @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:53
db @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:57
c @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:34
xc @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:35
be @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:34
(anonymous) @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:322
i @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:7
fireWith @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:7
ready @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:7
J @ lib.js?v=353b4ad4b87d6d708a27c5dab93b70109db683d6:7
extension.js:24 onMessage extension
ial.js:450 Clean the cache of the scraper (new onComplete event)
On 2021-04-18 11:15 p.m., Jose Garcia wrote:
> Hi Terry
>
> Have you checked in the Chrome dev console if the request has any errors?
>
> Regards,
> Jose García
>
> On Mon, Apr 19, 2021 at 4:14 AM Terry <terry.curran@anonymised.com
> <mailto:terry.curran@anonymised.com>> wrote:
>
> We run a reverse proxy and use Openjdk8 and Jetty9.4 on a RHEL8
> server.
> Jetty is working fine, and serving geoserver with no problems.
>
> We implemented Elasticsearch as a daemon from the RPM source.
> Implementation checks with systemctl and with curl
> http://localhost:9200
> show everything as expected. The ES config.properties in GN are as
> expected. The external data folder gn_dir contains the complete
> expected tree structure, with ES features, records, records_french
> and
> searchlogs. ES queries work.
>
> A clean install of the postgres-postgis GN database yielded the
> expected
> tables structure with appropriate elements.
>
> No errors are reported in the geonetwork log or in the jetty log.
> The
> Jetty log reports both geonetwork and geoserver as AVAILABLE.
>
> However, when we attempt to access GN with a browser using
> https://{website}/geonetwork, we get a header response
> https://{website}/geonetwork/srv/eng/catalog.search complete with
the
> standard earth-like logo, but with a completely blank screen. So it
> seems like it is trying to work.
>
> We have also tried the h2 database with exactly the same results. We
> have opened port 8080 and tried http access, with the same result.
>
> Any ideas as to what we are missing?
>
>
>
>
> _______________________________________________
> GeoNetwork-users mailing list
> GeoNetwork-users@lists.sourceforge.net
> <mailto:GeoNetwork-users@lists.sourceforge.net>
> geonetwork-users List Signup and Options
> <https://lists.sourceforge.net/lists/listinfo/geonetwork-users>
> GeoNetwork OpenSource is maintained at
> GeoNetwork - Geographic Metadata Catalog download | SourceForge.net
> <http://sourceforge.net/projects/geonetwork>
>
>
>
> --
> ***
> Vriendelijke groeten / Kind regards,
>
> Jose García
>
> <http://www.geocat.net/>
> Veenderweg 13
> 6721 WD Bennekom
> The Netherlands
> T: +31 (0)318 416664 <tel:+31318416664>
>
> Please consider the environment before printing this email.
> ***
_______________________________________________
GeoNetwork-users mailing list
GeoNetwork-users@lists.sourceforge.net
geonetwork-users List Signup and Options
GeoNetwork OpenSource is maintained at
GeoNetwork - Geographic Metadata Catalog download | SourceForge.net
--
*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS
*Florent Gravin*
*Technical Leader - Architect*
+33 4 58 48 20 36