Modify

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#12189 closed defect (fixed)

Automatic preference update for wiki urls not working

Reported by: Klumbumbus Owned by: team
Priority: normal Milestone: 15.12
Component: Core Version:
Keywords: URL Cc: stoecker

Description

14 months ago we switched icon handling of wiki hosted styles/presets/rules and all URL were changed to use zip. See #10581.
However now we still have users with old URLs, it seems that r8100 did not work as expected!?

See e.g. ticket:12187#comment:5. I had a missing icon for a long time too until I removed and readded the style manually.

According to ticket:12187#comment:6 it seems this problem affects also the change from http to https

Attachments (1)

preferences.xml (1.0 KB) - added by simon04 4 years ago.

Download all attachments as: .zip

Change History (19)

comment:1 Changed 4 years ago by stoecker

The code of r8100 only works if you load an older config file. If for some reason the version in the config got updated without that fix it will not be tried again.

comment:2 Changed 4 years ago by stoecker

In 9119/josm:

see #12189 - try again to update presets and style URL's

comment:3 Changed 4 years ago by stoecker

In 9120/josm:

see #12189 - also update http to https

comment:4 Changed 4 years ago by Don-vip

Milestone: 15.12

comment:5 Changed 4 years ago by simon04

Summary: updating wiki urls not workingAutomatic preference update for wiki urls not working

comment:6 Changed 4 years ago by Don-vip

Resolution: fixed
Status: newclosed

comment:7 Changed 4 years ago by stoecker

Resolution: fixed
Status: closedreopened

Not fixed. We have 130 non-https/zip requests for >= 9120 since yesterday. I overlook something essential, but what?

comment:8 Changed 4 years ago by Don-vip

On my system "josm.version" is never written to my preferences.xml, so this code is never executed.

I don't understand why, I'm looking to it.

comment:9 Changed 4 years ago by simon04

After this change, josm.version is being written:

  • src/org/openstreetmap/josm/data/Preferences.java

    diff --git a/src/org/openstreetmap/josm/data/Preferences.java b/src/org/openstreetmap/josm/data/Preferences.java
    index 7c8bc64..907124d 100644
    a b public void removeObsolete() { 
    18771877        // drop this block march 2016
    18781878        // update old style JOSM server links to use zip now, see #10581, #12189
    18791879        // actually also cache and mirror entries should be cleared
    1880         if (getInteger("josm.version", Version.getInstance().getVersion()) < 9120) {
     1880        if (getInteger("josm.version", 0) < 9120) {
    18811881            for (String key: new String[]{"mappaint.style.entries", "taggingpreset.entries"}) {
    18821882                Collection<Map<String, String>> data = getListOfStructs(key, (Collection<Map<String, String>>) null);
    18831883                if (data != null) {

comment:10 Changed 4 years ago by simon04

In 9206/josm:

see #12189 - Another attempt to update presets/style URLs

Changed 4 years ago by simon04

Attachment: preferences.xml added

comment:11 Changed 4 years ago by simon04

attachment:preferences.xml is a manually crafted preference file which should show the upgrading to https and &zip=1.

comment:12 Changed 4 years ago by Don-vip

Resolution: fixed
Status: reopenedclosed

confirmed :)

comment:13 Changed 4 years ago by stoecker

No. That's wrong. josm.version is not written in the body, but as argument to <preferences>. Please revert the change.

But it may be related. getInteger("josm.version") is probably incorrect to access the value? But somewhere the old value exists. Or it fails when other changes modify the file before this code is excecuted.

comment:14 in reply to:  13 Changed 4 years ago by Don-vip

Replying to stoecker:

josm.version is not written in the body, but as argument to <preferences>.

I see no special treatment for this behaviour (neither in Java code nor preferences.xsd).

Please revert the change.

I confirm Simon's analysis: the first request to get josm.version property returns the default value because property does not exist in property file. So the default value is memorized in defaultMap. Then, when we want to store josm version, as the current version matches the default value, it is not written to the properties file. So the change is correct: we must not return the current value as default value if the property does not exist in properties file, and it must be lower than 9120, so 0 is correct.

comment:15 Changed 4 years ago by stoecker

In 9216/josm:

fix #12189 - properly handle the file version

comment:16 Changed 4 years ago by stoecker

The analysis was right, but the fix was wrong.

comment:17 Changed 4 years ago by stoecker

It seems the "josm.version" variable was totally removed some thousand revisions ago or I remembered something wrong. At least it was an incorrect check.

comment:18 Changed 4 years ago by stoecker

Seems fixed. Only one IP of a SVN version in the logfile > 9216 which has no zip and that's our own JOSM server test system :-)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.