geosolutions-it / geostore Goto Github PK

We need to place a licenze file in the root directory.

In certain use cases it could be useful to auto-create new users on incoming requests.
This should be enabled by configuration.
New users should be assigned a default role (USER) and password (if not specified in the request).

Log4J exception if GeoStore e GeoBatch are in the same tomcat.

following the log:

// -----------------------------------------------------------------------------------------------------------------------------
14:45:57,026 INFO GBFileSystemMonitorJob - Building the observer tree...
14:45:57,036 INFO GBFileSystemMonitorJob - Observer tree complete.
Oct 25, 2012 2:45:57 PM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive geostore-gliders.war
Oct 25, 2012 2:45:57 PM org.apache.catalina.core.StandardContext listenerStart
SEVERE: Exception sending context initialized event to listener instance of class org.springframework.web.util.Log4jConfigListener
java.lang.IllegalStateException: Web app root system property already set to different value: 'webapp.root' = [/home/nurc/nurc-gliders/webapps/geobatch-gliders/] instead of [/home/nurc/nurc-gliders/webapps/g
eostore-gliders/] - Choose unique values for the 'webAppRootKey' context-param in your web.xml files!
at org.springframework.web.util.WebUtils.setWebAppRootSystemProperty(WebUtils.java:144)
at org.springframework.web.util.Log4jWebConfigurer.initLogging(Log4jWebConfigurer.java:117)
at org.springframework.web.util.Log4jConfigListener.contextInitialized(Log4jConfigListener.java:45)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4206)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4705)
// -----------------------------------------------------------------------------------------------------------------------------

So both applications attempt to set the 'webapp.root' parameter.

A possible solutions is configuring the web.xml file with the following context parameter:

Implement in GeoStore a functionality to delete resources by a filter (we can do it inside the Resource Service).

When we copy twice a resource a 'Violate Constraint' exception occurs GeoStore side because the name property is UNIQUE inside the database.

We have to investigate the possibility to add more checks GeoStore side during the save operation (for example returning a specific code to advise the client when a resource already exists) in order to manage this issue.

How to deploy on Oracle

When accessing a resource via web browser, we are getting a 500 Internal Server Error:
http://demo1.geo-solutions.it/stg_geostore/rest/categories?_wadl&_type=xml

Returning a 401 Unauthorized, plus standard HTTP (hasic|digest) authentication headers, will allow browser to display a login window.

This is the usual auth method, used v.gr. in GeoServer REST interface:
http://demo1.geo-solutions.it/stg_geoserver/rest

In order not to have external dependencies to be able to build geostore (at the moment a postgres DB is needed), it would be nice to use some kind of embedded dbms.
A sample property file is already in the web module, used as a customization example.

Note that the DB is accessed only when building the modules

• persistence
• services-impl

We need to provide a link for the current war. In the future we need to come up with something better, like CI and so on.

http://maven.geo-solutions.it/it/geosolutions/geostore/geostore-webapp/1.0/geostore-webapp-1.0.war

How To deploy on PostgreSQL.

In section "Building instructions"

Use primitive type where possible and investigate on postgres error using autoincrement fields:

Hibernate: select count(usergroup0_.id) as col_0_0_ from geostore.gs_usergroup usergroup0_
INFO 2012-08-03 19:09:17.860 it.geosolutions.geostore.core.dao.AttributeDAOTest::setUp - ##### Ending setup for testSearchAttribute ###----------------------
Hibernate: insert into geostore.gs_category (id, name) values (null, ?)
WARN 2012-08-03 19:09:17.862 org.hibernate.util.JDBCExceptionReporter::logExceptions - SQL Error: 0, SQLState: 23502
ERROR 2012-08-03 19:09:17.862 org.hibernate.util.JDBCExceptionReporter::logExceptions - ERROR: null value in column "id" violates not-null constraint
INFO 2012-08-03 19:09:17.868 it.geosolutions.geostore.core.dao.AttributeDAOTest::setUp - ################ Running AttributeDAOTest::testCheckDAOs
Hibernate: select resource0_.id as id1_, resource0_.category_id as category7_1_, resource0_.creation as creation1_, resource0_.description as descript3_1_, resource0_.lastUpdate as lastUpdate1_, resource0_.metadata as metadata1_, resource0_.name as name1_ from geostore.gs_resource resource0_
Hibernate: select count(resource0_.id) as col_0_0_ from geostore.gs_resource resource0_

Create an alternative DAO which will persist StoredData on filesystem and not on DB.

Specify all the necessary steps to configure the postgres database as an example.

Add interfaces to add users to GeoStore.
At the moment you have to add users directly in the database.

Some attributes names for the GS_ATTRIBUTE, GS_STORED_DATA and GS_USERS entities must be changed due to ORACLE compatibility.

In order to do this the @Column.name annotation should be changed.

Fields indicated are:

• textValue -> gs_attribute
• numberValue -> gs_attribute
• dateValue -> gs_attribute
• type -> gs_attribute
• role -> gs_user
• data -> gs_sotred_data

Make user attribute of "UserAttribute" XMLTransient"

the examples provided for the geostore users initializations using an external xml file is wrong, it uses the attribute geostoreInitializer.categoryListInitFile instead of geostoreInitializer.userListInitFile .
It can cause errors on startup and waste time to fix when geostore is deployed.

When "Bad pw for user admin", it seems that the returned http code is 500.

The GeoStoreClient depends from too many javax stuff (persistence,annotations) and is not compatibile with Android for instance. Remove the annotations and do the mapping with XML files to make the client portable.

RESTUserServiceImpl:147

[...]
 }else if(old.getName().equals(authUser.getName())){ // Check if the User is the same
[...]

checks the name, so 'change name' action can't be performed

Currently the key is hard coded. We should make it externally configurable

Allow to get Attributes of the from the REST interface and the client.
Now you can get them only in the whole list.

Allow also this option for insert.

The default DB configuration could be hardcoded in the application-context and using a property override you can setup another DB.

The SecutityRule entity must be refactored due to ORACLE compatibility (UNIQUE constraints generates errors for 'null' values on ORACLE).

As expected from the original model, two new entities should be created in order to manage separatelly Resource and Category security rules.

Actually the information are hardcoded in the class GeoStoreInit (module geostore-webapp)

We should introduce a configurable way to authenticate requests not only with the current HTTP Basic Authentication, but also using other http headers / environment variables set by an external security system.

The PwEncoder class uses a symmetric algorithm that allows to retrieve back the password.

Pw decoding is not useful here, so let use a one-way algorithm.

Note that the PwEncoder.decode(...) method is only used in tests.

Add info about how to use GeoStore maven artifacts.
In particular the user will use the full webapp and the geostore rest client.
Add info about maven repository.

Current ftp-wagon version (1.0 beta) in pom often has problem when uploading new artifacts.

The current GeoStore model provides the support to user groups following the constraint below:

• One user can be assigned to only a single group

But the services aren't implemented yet.

Implement the Services needed for manage the groups creation/deletions and fit the Security stuff as well.

The jetty's maven2 repository [1] has moved to another urls.

If you have a clean local maven2 repository and try to compile, maven download corrupt pom files and the build fail.

[1] http://docs.codehaus.org/display/JETTY/Maven+Repositories

We need to make sure licenses are everywhere.

It could be usefull to specify a workspace for each resource and category in order to separate logically the data managed by geostore.
So an user can be granted for a certain workspace and have access to all resources contained. Also a default workspace is needed because specifying them isn't be mandatory.

A typical use case is a System with staging and dissemination environment: instead of use two different geostore instances (so also two different running servlet container) it could be used only one geostore instance with all data logically separated by two workspace called staging and dissemination.