There's the options column that was added to user_layer so that might cause a problem but since your error was that it wasn't there so the migration wasn't run and as such it could work properly when restored on a new db (you can check that the columns on the newly created table matches the old db). I don't remember any changes for oskari_users
I would just configure a new db and recreate it from scratch with the app and then try moving in the existing content from the current db
I also tried deploying a war file on 2.x, but I get a different message on the logs:
2021-06-03 07:13:12,580 WARN AUDIT - {"msg":"\n### Error querying database. Cause: org.apache.ibatis.executor.result.ResultMapException: Error attempting to get column 'options' from result set. Cause: java.lang.NullPointerException\n### The error may exist in org/oskari/myplaces/service/mybatis/MyPlaceCategoryMapper.java (best guess)\n### The error may involve org.oskari.myplaces.service.mybatis.MyPlaceCategoryMapper.getByUserId\n### The error occurred while handling results\n### SQL: SELECT id, uuid, \"default\", publisher_name, category_name, options FROM categories WHERE uuid = ?\n### Cause: org.apache.ibatis.executor.result.ResultMapException: Error attempting to get column 'options' from result set. Cause: java.lang.NullPointerException","op":"ERROR","resource":"GENERIC","ip":"127.0.0.1","params":{"action_route":["MyPlacesLayers"],"_":["1622722391320"]},"user":"implan"}
[DEBUG] fi.nls.oskari.util.IOHelper: Opening connection to http://localhost:8082/geoserver/oskari/ows?
2021-06-03 07:13:12,637 ERROR org.oskari.map.userlayer.service.UserLayerDbServiceMybatisImpl - Failed to get userLayer with uuid: 76ede2a3-db5c-471f-b00f-629c0a036000
org.apache.ibatis.exceptions.PersistenceException:
### Error querying database. Cause: org.apache.ibatis.executor.result.ResultMapException: Error attempting to get column 'options' from result set. Cause: java.lang.NullPointerException
### The error may exist in org/oskari/map/userlayer/service/UserLayerMapper.xml
### The error may involve org.oskari.map.userlayer.service.UserLayerMapper.findUserLayerByUuid
### The error occurred while handling results
### SQL: select id, uuid, layer_name, layer_desc, layer_source, fields, publisher_name, wkt, options from user_layer where uuid = ?
### Cause: org.apache.ibatis.executor.result.ResultMapException: Error attempting to get column 'options' from result set. Cause: java.lang.NullPointerException
Probably there's some other message on the startup that tells why it isn't added on startup
But let me restart the app
maybe try inserting an empty json object to it if the value is null
Or check what is in there
select id, uuid, layer_name, layer_desc, layer_source, fields, publisher_name, wkt, options from user_layer where uuid = '76ede2a3-db5c-471f-b00f-629c0a036000 '
^That's what the code is trying to run
2021-06-03 07:17:00,066 ERROR fi.nls.oskari.servlet.WebappHelper - DB migration for module example failed!
org.flywaydb.core.api.FlywayException: Found more than one migration with version 1.1.3
Offenders:
-> /tmp/jetty-0.0.0.0-8080-oskari-map.war-_-any-4856569831198561382.dir/webapp/WEB-INF/lib/app-resources-1.5.0.jar (JDBC)
Should I drop it and restart the app after doing that fix?
Then rename the db to the one it was before. Or rename the current and create a new one in it's place
that's probably easier
Thanks!
Hello. Is there any way to easily calculate the left, right, top and bottom lon lat for different zoom levels? For instance if I have the getMapBbox and getMapPosition for zoom level 10, is there any way I could calculate the mapBbox values for zooms 9,8 and 7 without zooming out and running getMapBbox for every single one of those zooms? Can I use the scale value from mapPosition for this?
But yes, Java after 11 doesn't seem to work, I had some issue with 11 too but didn't have time to investigate further so I just switched to Java 8. The CSW test checks if Java version is 8 or 11 and doesn't seem to accept other ones.
Hi, couldn't get Rocket chat to work on new computer yet so putting this here! I have been tasked to apply authentication for download basket to get it to work with AWS. We also needed to add TLS/SSL encryption. Basically we need to add these lines to SendDownloadDetailsToEmailThread and DownloadServices (if I'm not mistaken):
email.setStartTLSEnabled(true);
email.setStartTLSRequired(true);
email.setSSLCheckServerIdentity(false);
String username = System.getenv(PropertyUtil.get("oskari.wfs.download.smtp.username.env", "wfs.download.smtp.username")) != null ? System.getenv(PropertyUtil.get("oskari.wfs.download.smtp.username.env", "wfs.download.smtp.username")) : PropertyUtil.get("oskari.wfs.download.smtp.username", null);
String password = System.getenv(PropertyUtil.get("oskari.wfs.download.smtp.password.env", "wfs.download.smtp.password")) != null ? System.getenv(PropertyUtil.get("oskari.wfs.download.smtp.password.env", "wfs.download.smtp.password")) : PropertyUtil.get("oskari.wfs.download.smtp.password", null);
if (username != null && password != null) {
email.setAuthentication(username, password);
}
Also it was apparently required to pull the username and password from env variables instead of properties. But the actual question is, do we want to add all these to Oskari core (guessing no), and which ones? Also if f.ex. the TSL stuff is not wanted/needed, what would be the easiest way to get these changes just for us in the server-extension?
I see only 2 rows concerning properties added in the code above. Is there more?
Though those two lines look a bit intimidating for sure :)
I think it's pretty safe to assume that one instance would only have a single smtp in use so you could simplify the propertynames a bit to just smtp.user/smtp.password. Things like "require TLS"=true or "check identity"=false should be configurable
Also you can do something like PropertyUtil.get('smtp.user, System.getEnv('smtp.user')) so if properties doesn't have a configuration it uses the env variable
If you want to have the env override a property then it will be a bit messier and I would move the code to it's own method instead of single-lining the logic. I agree it probably should be that way around (env before props). Then again I would approach this by having PropertyUtil return the env value if there is one before a properties value so it's abstracted from the code getting the variables so you don't have to repeat this everywhere. Also reconsider if you really need to make the env variable name configurable
So in here: https://github.com/oskariorg/oskari-server/blob/2.4.0/service-base/src/main/java/fi/nls/oskari/util/PropertyUtil.java#L192
the first thing in the method do something like:
the first thing in the method do something like:
String envVar = System.getEnv(propertyName);
if (envVar != null) {
return envVar;
}
The you can have clean code while using the props (
PropertyUtil.getOptional("smtp.user")) and env variables will override any properties you might have in oskari-ext.properties
Yes it was on purpose that if env variable is not found, the properties are a fallback. I thought it would be good that the env variable name would be configurable and not hard-coded just in case. Although I guess variable name like "OSKARI_SMTP_USER" would be sufficient to ensure that there will be no problems. I think we have more things incoming later that would also need to be configured in the properties, so the download basket will have like total +30 possible rows in properties but I guess that's fine and unavoidable, just felt bit intimidating at first compared to other configurations :D
so you don't need to have that 30 rows configured most of the times
I'd still rather have that as PropertyUtil.get("oskari.smtp.user") and have propertyutil do . -> _ conversion and uppercasing to make it easier to define the env variables without escaping dots etc