Any objections to Apache? Also I would propose to publish this package in Maven Central from the beginning.

• https://github.com/52North/iceland/search?utf8=%E2%9C%93&q=sos
• https://github.com/52North/iceland/search?utf8=%E2%9C%93&q=sensor&type=Code

change the Map<String, Set<SchemaLocation>> to a Map<String, SchemaLocation> in
https://github.com/52North/iceland/blob/develop/core/src/main/java/org/n52/iceland/coding/encode/SchemaRepository.java#L63

There is an ongoing enhancement entry under the SOS issues regarding the ResponseEvent. Issue 216

Would it be possible to have also an appropriate ResponseContext implemented in the Iceland project to store additional meta-data (e.g. execution time of the process)?

I guess it is possible somehow, but I don't know the best way: How can we automate tests of downstream services, i.e. if there is a new PR on iceland, the depending projects (e.g. SOS 5.x branch and WPS 4.0 branch) are build with integration tests?

Would it be possible to have a custom button on the admin settings page?
When the user clicks on the button it should validate only a sub-group of settings fields.

Is it possible to implement this feature?

Add a new setting type that generates a random string (or number?) at every time the service starts. Can be used for security tokens etc.

IMHO this is IDE specific and should not be committed to version control, especially as it looks like there are alternatives. Any objections?

I'd like to initiate my configurable object after all the settings values had been assigned to my intance. Is it possible with the current version?

Because now the user needs to restart the whole application to restart e.g: the Elasticsearch client module with the new settings.

We should provide a list of errors and which error message are returned by iceland.

I just noticed that any Link to a Java resource is broken due to the fact, that there is no src folder on top-level of the repository. Instead there are two folders core and util, which contain the src folders.

So, each link has to be changed in order to contain the missing .../core/... or .../util/... part.

I'd like to make a query against the new SOS 5.x deployment and in the logs the following message appears.

2015-07-06 07:32:18,193 WARN [http-nio-127.0.0.1-8080-exec-31] [ProxyChain.java:133] Ignoring invalid IP address in X-Forwared-For header: ::ffff:217.173.34.182 java.lang.IllegalArgumentException: '' is not an IP string literal. at com.google.common.net.InetAddresses.forString(InetAddresses.java:153) ~[InetAddresses.class:na] at org.n52.iceland.util.net.IPAddress.parse(IPAddress.java:125) ~[IPAddress.class:na] at org.n52.iceland.util.net.IPAddress.<init>(IPAddress.java:59) ~[IPAddress.class:na] at org.n52.iceland.util.net.ProxyChain.getIPAddress(ProxyChain.java:141) ~[ProxyChain.class:na] at org.n52.iceland.util.net.ProxyChain.fromForwardedForHeader(ProxyChain.java:128)

full stacktrace: https://gist.github.com/lestarcdog/897d32d8198b29622e79

See most importantly https://github.com/52North/iceland/blob/develop/core/src/main/java/org/n52/iceland/util/Constants.java

Is this good practice?

Would it be acceptable if to the RequstContext class a new member field would be added?

The new field should represent from which Binding type the request came (i.e: JSON,SOAP,KVP...) and the member value would be then the value of JSONBinding.class, KvpBinding.class (subclasses of the SimpleBinding class), etc...
Something along this line:
private Optional<Class> bindingClass = Optional.absent();

The member field value would be initialized at this point:
SimpleBinding class

Do you see any hindrance of this addition?
It would be an elegant metrics to the statistics module.

We should add short documentation on how to release iceland.

@autermann Can you formulate a process for the branches and how to reset the master branch to the right commit etc.?

Here's what I have:

Deployment

Prerequisites

Put your Sonatype OSS credentials into your .m2/settings.xml like this:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                              http://maven.apache.org/xsd/settings-1.0.0.xsd">
    <servers>
        <server>
            <id>ossrh</id>
            <username>$username</username>
            <password>$password</password>
        </server>
    </servers>
</settings>

Release

The branches master and develop are protected in iceland, therefore changes can only be pushed there via pull requests. The release should be done in extra branches for both develop and master, from which we merge to both the main repository.

Note: It is important to call release:perform after the changes are pushed to the actual branches as the plugin will checkout these.

# first develop
git checkout develop
# pull latest changes
git pull --ff upstream/develop
# create a release branch
git checkout -b release/develop
# push it to remote
git push -u origin release/develop

# prepare the release, note down the release tag name
mvn release:prepare
# push the changes
git push origin

# now master...
git checkout master
# create a second release branch
git checkout -b release/master
# set it to the right commit
git merge --ff-only <release version tag, e.g. v1.1.0>
# push it to remote
git push -u origin release/master

# CREATE SEPERATE PULL REQUESTS AND MERGE THEM
#1. from <your fork>/release/master to 52North/master
#2. from <your fork>/release/develop to 52North/develop

# remove the remote release branches
git push origin --delete release/master release/develop

# back to master
git checkout master
#  pull latest changes (inkluding the actual release)
git pull --ff upstream/master
# push it to remote
git push origin
# publish the release
mvn release:perform -P sign

After performing the release on the command line, log in to Sonatype Nexus at https://oss.sonatype.org/ and complete the following steps:

• Locate the project in the the staging repository: https://oss.sonatype.org/#stagingRepositories
• Check it contains the required files (pom, asc, sources, javadoc, ...)
• "Close" the staging repository
• Click on "Release" (might have to "Refresh" first)
• Wait... then refresh - the staging repo should be gone.
• Check after some delay for the published modules at http://repo1.maven.org/maven2/org/n52/iceland/

What should Iceland contain?

• Basic service componentes
• Basic API: binding, coding, requests, responses, ....
• Binding repository
• Coding repository
• Service respository
• Settings solution of SOS 4.x
• Test client
• Converter (e.g. coordinate transformator)
• Hibernate SessionFactory
• Event bus

[copied from wiki]

Do we need a common name for loggers? I've seen log, LOG and LOGGER in iceland source code.

I prefer log, even though it is against code conventions because it is a final variable.

The class ComparisonFilter.java must be refactored since it currently provides to many constructors and setters to be easily manageable. This has considerable impact on the decoders which currently take advantage of the loose available methods.

See discussion at #36 (comment)

Better approaches on the table so far:

• static factory methods and a single private constructor
• new fluent API

The SOS documentation has a nice figure on how the different classes are related to each other and how the information flows through it. This should be adjusted for Iceland and added to the documentation (could be stored as attachment in the wiki)

... implement a abstract GetCapabilitiesHandler in iceland (or extend a existing one). Use a factory method to create the concrete capabilities class.

Iceland will only support one endpoint (/service) using one servlet, so it is out of scope to generically define additional endpoints.

However, I think it would be useful to have a common practice (or documentation) how to add more endpoints. Do I have to add a new Servlet to the web.xml? Ist the /service endpoint defined manually or using some annotation? How can I combine iceland with a Spring application (even though there is no Spring in iceland)?

Currently the statistics can only be stored to an Elasticsearch cluster. Add support for PIWIK using the Java API: https://github.com/piwik/piwik-java-tracking

Let's discuss how we might split up the Java classes of iceland into Maven modules. This is imho not urgent but might facilitate use in later releases:

• iceland-swes (for all SWE-specific services), see #47
  • could include packages ...sos., ...swe., ...swes.
• iceland-config - Would it be feasible to use the configuration meachnism without anything else?
• ... (leave comments or update this list)

Move JavaHelper.generateID() to an own class in SOS (Svalbard), e.g. IdGenerator

Java 7 will reach it's end-of-life this month. So I would say we'll directly go with 8. Objections?

//edit: of course it's next month... we still have march...

When I configure an integer setting as below, there is no error but the setting is initialized with the value 0.

    "port" : {
      "type" : "integer",
      "value" : "1234"
    },

The correct definition of the integer is of course

    "port" : {
      "type" : "integer",
      "value" : 1234
    },

The https://github.com/52North/iceland/blob/develop/src/main/java/org/n52/iceland/service/ConfigLocationProvider.java allows to support different ways of configuring where the configuration file or database is saved. Potentially useful alternatives to the currently implemented Servlet path:

• home dir config provider
• full path config provider

I am not sure how a user could choose between though.

Implement a new setting type that pairs two values.

pre() is currently executed twice in CompositeSerialAction.

• org.n52.service
• org.n52.iceland

Opinions? I do like org.n52.iceland more. Thats the name of the project. Why should we go with something generic?

Agreement about documentation location: Markdown files within the repository. Advantage: versioned, close to the code, text-based. Also suitable because iceland is for developers only.

Documentation tasks

• for desctructable und constructable, i.e. the iceland lifecycle
• for best practices (or: options) regarding configuration files, see 52North/SOS#242 (comment)
• How to develop an OGC service with iceland?
• Fix all // TODO statements in the code, see https://github.com/52North/iceland/search?utf8=%E2%9C%93&q=%2F%2F+TODO (empty class comments could just be removed...)

Where could I integrate a "watcher" mechanism that regularly (e.g. every 10 seconds) checks the configuration file for changes? @autermann

In my scenario, I do not have a user interface for changing settings, but I still want an admin to be able to change setting values without having to restart the service.

The class https://github.com/52North/iceland/blob/develop/core/src/main/java/org/n52/iceland/ogc/sos/CapabilitiesExtension.java and related classes should be in an ows package, not in org.52n.iceland.ogc.sos.

We should add iceland to our Sonar instance at http://build.dev.52north.org/sonar/