#275 closed defect (fixed)
Image not showing
Reported by: | osjonathan | Owned by: | josegar74 |
---|---|---|---|
Priority: | critical | Milestone: | v2.6.0 |
Component: | User interface (web) | Version: | v2.6.0RC1 |
Keywords: | Cc: |
Description
See screenshot. In RC1 (wasn't in RC0) to the left of each item of metadata, either in the result or when using metadata.show, there's an "image" box where the browser can't find the image it's supposed to find. This is true for your "example metadata", as well as my own metadata. Inspecting the element show's it's looking for something like: "/geonetwork/images/logos/b0314262-bccc-40df-b08a-c997fda81598.gif"
The logos directory only has two item in and one of them is my own (a new logo). In RC0 it would point to the "dummy" logo. It's not actually clear what this image is supposed to represent or where you'd edit the URL to it.
Screenshot attached.
Attachments (1)
Change History (11)
by , 14 years ago
Attachment: | Clipboard01.jpg added |
---|
comment:1 by , 14 years ago
comment:2 by , 14 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Tested RC1 installer and the display of logo image seem ok
comment:3 by , 14 years ago
Priority: | minor → trivial |
---|---|
Resolution: | worksforme |
Status: | closed → reopened |
My current "install" was by downloading the 2.6.0RC1 "geonetwork.war" ( http://sourceforge.net/projects/geonetwork/files/GeoNetwork%20unstable%20development%20versions/v2.6.0RC1/geonetwork.war/download ) and extracting it to my jetty web directory (which came as a result of installing 2.6.0RC0 using the installer - "geonetwork-install-2.6.0-RC0.exe" ).
I've just downloaded the installer and sure enough, the logo works.
BUT if I then remove the geonetwork/geoserver directories that come with the full installer and copy over the separate geonetwork.war file that I've just re-downloaded separately, the bug is re-evident (the logo's don't show).
So the bug is real, it's just restricted to the geonetwork.war release.
comment:4 by , 14 years ago
Hi
I think you're using an external database to store the metadata. In that case is normal about the logo due to this:
The geonetwork of installer generated a site-id (b0314262-bccc-40df-b08a-c997fda81598) and the metadata you created got this site-id , that also is used in the logo image name. You can check the metadata table (source column) and the sources table.
But when you replace geonetwork application with the one in war file, i think a new site-id was created for geonetwork (that's correct behaviour). So the problem is that source column of metadata table refers to old site-id. You can update the column directly in database setting new site-id and should be shown the logo correctly.
Also GAST has a migration option, but in this case you need to have both the old an new installations and i think it manages about updating the source for metadata.
comment:5 by , 14 years ago
Hi Jose, I think I get what's going on but am still slightly confused. I infer from your reply that the site-id changes between installs. So how come the data/logo combination for rc0 works with rc1 when the installer is used (despite my not migrating the data), yet when I simply copy the .war file in, it doesn't work?
The other thing I don't get is - why does the dummy logo need to have a unique ID with it? I imagine it may relate to harvesting (just a guess), but then can't it just use dummy.gif if the ISHARVESTED is "n"? It just adds an extra step to the update process otherwise.
Also, the .war file only comes with the "dummy.gif" logo file. And yes, I'm using an external database (Oracle). Hope I'm not being too obtuse. :-) Jonathan
comment:6 by , 14 years ago
I was also having problems with this, and have similar questions. So there's no easier way to migrate the data between sites, without breaking the logos? I'm also using an external Oracle database.
comment:7 by , 14 years ago
Priority: | trivial → critical |
---|
The code will need to be checked to ensure a server UUID is not overwritten when it already exists in the DBMS upon installation of a new geonetwork.war file
comment:8 by , 14 years ago
Owner: | changed from | to
---|---|
Status: | reopened → new |
comment:9 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
The server UUID is NOT overwritten when application is updated and using an existing database. Sorry about confusion caused.
The problem was:
The logo image for the GeoNetwork server was only created the first time when the database was initialized.
If the application was updated with a new version (images/logos folder only contains dummy.gif logo then) and preserving the database, the logo was not created again.
Changed to check always in startup if logo for GeoNetwork server exists, if not then creates it.
This solves the problem for server logo image. But if the user changed the default logo image for server or has logos from harvested sites, she must copy the content of images/logos folder from previous installation to new one.
comment:10 by , 14 years ago
We should probably make a specific folder with all resources (logos, codelist, lucene index) which could be update by the GeoNetwork node in order to make update from one version to another much easier. This folder could be placed outside webapp install dir. We should create a ticket for enhancement for that I think.
To be tested on the installer