fraunhoferiosb/frost-client

Library implementing a client interface to the SensorThingsAPI

frost-client's Issues

Add alert box to invalid inputs for properties fields

Adding invalid JSON in Properties field informs in console but not in GUI like other fields.
I suggest adding the same alert box to the exception caused by properties field.

Need more information for DataArray for Observation creation

Thus far I have used the http://localhost:8080/FROST-Server/v1.0 URL (with the frost-server running) for the examples provided in the readme file without issue. I am having issues using that URL for the Data Array for Observation creation example as it appends /createObservations to the URL provided which gives me back a status 500 error. Please advise

Not all server interaction throws exception in case of communication problems

I have a server set up to work with BasicAuthentification.

Then I execute the following line:
ObservedProperty obsProp=service.observedProperties().find(obsPropId);

With the proper (wrong) configuration this yields in a 401 response code.
There is no exception thrown (as expected and as described in the java doc). Instead a null is returned.

Error in Readme.md

Given Code example is:
URI serviceEndpoint = URI.create("http://example.org/v1.0/");
SensorThingsService service = new SensorThingsService(serviceEndpoint);

Correct would be:
URL serviceEndpoint = new URL(http://example.org/v1.0/);
SensorThingsService service = new SensorThingsService(serviceEndpoint);

`EntityModule` only keeps `@iot.id` of nested entities after JSON serialization

Currently, it is not clear enough how the EntityModule intends to serialize entities.

FROST-Client/src/main/java/de/fraunhofer/iosb/ilt/sta/jackson/EntitySerializer.java

Line 58 in 2ff4182

gen.writeFieldName("@iot.id");

FROST-Client/src/main/java/de/fraunhofer/iosb/ilt/sta/jackson/EntitySerializer.java

Line 80 in 2ff4182

gen.writeFieldName("@iot.id");

Due to the above lines, prepopulated fields of subentities are thrown away. I would like to know the reasoning for this design decision to further understand if this is intended behaviour or not. In our use case, we would like to serialize/deserialize a Thing including its Datastreams and Locations. However, the fields of Datastreams and Locations that were populated by an Expand query are thrown away during JSON serialization. Could you maybe elaborate a bit on the above, and point me into the right direction on how I can serialize the subentities without losing their populated fields and not having to perform separate fetch queries?

Abstraction layer for SensorThings API query and filter functions

SensorThings API: query and filter functions

The SensorThings API offers many built-in query and filter functions for queries to the SensorThings Service.
Some examples:

• st_within: Find things in an area
• eq: Find things where some property equals some value
• distance: Calculate the distance between two points

The full documentation can be found here: OGC SensorThings API Part 1: Sensing in section 9.3.3.5

Current state

Currently it is possible to add filters to queries by calling filter() on a query: method definition
This method takes a string which is placed into the query which means that part of the query has to be defined manually.

Suggestion

It would be great if filters could be controlled with built-in methods.
A query could for example have a list of filters where each filter has a operation and a list of arguments.
This would provide a layer of abstraction so that users of the FROST-Client don't have to know the SensorThings API Syntax.

MQTT Service reconnects every time the `publish` method is called

Problem description

We use a setup as follows

final MqttConnectOptions mqttConnectOptions = new MqttConnectOptions();
mqttConnectOptions.setCleanSession(true);
mqttConnectOptions.setConnectionTimeout(0);
// ...
final SensorThingsService service = new SensorThingsService(serviceURL, mqttConfig);
// ...
final Observation observation = new Observation();
// ...
service.publish(topic, observation);

In our use case, we want to publish multiple observations to a Mosquitto broker in a short period of time. When we do this, we observe two problems:

1. The Mosquitto broker will log a connect - publish - disconnect for each published message
2. The host application crashes when subsequent calls are in a short period of time with de.fraunhofer.iosb.ilt.sta.MqttException: Error publishing via MQTT - Caused by: No connection to Client.

However, from our POV, the MQTT client should keep the connection open to allow for fast subsequent publish calls.

Workaround

We managed to workaround this problem by using Paho MQTT directly, as follows:

// Generate a unique client id
final String clientId = "java-client-" + UUID.randomUUID().toString();
client = new MqttClient(mqttEndpoint, clientId);
client.connect(mqttConnectOptions);
// ...
client.publish(topic, new MqttMessage(ObjectMapperFactory.get().writeValueAsBytes(observation)));
// ...
client.disconnect();

Possible Solution

We could not locate why the SensorThingsService disconnects after a successful publish call. We recommend to investigate the problem using our workaround given above.

NullPointerException in checkAutoRefreshTimer method when using TokenManagerOpenIDConnect

I am encountering a NullPointerException in the checkAutoRefreshTimer method of the TokenManagerOpenIDConnect class when setting up OpenID Connect. The exception occurs at the line refreshTask.cancel(). Here is the code reference:

FROST-Client/src/main/java/de/fraunhofer/iosb/ilt/sta/service/TokenManagerOpenIDConnect.java

Line 204 in 693da44

refreshTask.cancel();

The issue arises when setting autoRefresh to true.
Setting autoRefresh to false works, but the token eventually expires, requiring autoRefresh to be enabled for proper functionality.
It seems that there is a missing check to ensure refreshTask is not null before calling cancel on it, leading to the NullPointerException.

Has anyone else successfully implemented this feature?
Is there a recommended approach to ensure refreshTask is properly initialized before calling cancel?

Any guidance or suggestions to resolve this issue would be greatly appreciated.

Thank you!

Problems building with Java 1.8 due to slf4j-api and mockito-core

@hylkevds , I was trying to build this application this morning and received errors about the slf4j and mockito core libraries being compiled with an incompatible version of Java. This is the original error that I received:

[ERROR] /D:/frostclient/FROST-Client/src/test/java/de/iosb/fraunhofer/ilt/sta/MqttTest.java:[60,26] cannot access org.mockito.Mockito
[ERROR] bad class file: C:\Users\rclark.m2\repository\org\mockito\mockito-core\5.1.1\mockito-core-5.1.1.jar(org/mockito/Mockito.class)
[ERROR] class file has wrong version 55.0, should be 52.0
[ERROR] Please remove or make sure it appears in the correct subdirectory of the classpath.

I was able to build successfully after I changed the sl4j-api.version to 1.7.36 and the mockito.version to 4.0.0. I just randomly chose an earlier version of the libraries. Let me know how I can help to resolve this issue. Are you hoping to change the application to use a more up to date version of Java? Or would you like for me to do a pull request to update the versions of these two libraries so that they will be compatible with Java 1.8?

Add Keycloak AuthProvider to the MQTT Part

Hello, i use the docker-compose-seperated.yaml to deploy the FROST-Server.

I added successfull the Keycloak AuthProvider to the HTTP Part (edited the context.xml File)
@ "FROST-Server.HTTP/target/FROST-Server.HTTP-1.12-SNAPSHOT/META-INF/context.xml"

But i have no Idea where i can setup the MQTT Configuration.

Thanks for your advice.

Best wishes,
Francesco
EDIT: Moved to FROST-Server

Where is the 0.15 version?

Hi,

Documentation says there is the 0.15 version available in jcenter.bintray.com. However, I can only reach the 0.10 version (btw under the SensorThingsClient artifactId)

Is jcenter.bintray still in use?

Thanks,
Aurélien

Additional header before every HttpRequest

Hi,
I've been attempting to add or manipulate http request header for authentication usage before the "SensorThingsService" send this request to server. I've tried TokenManager but in vain. My goal is to ask user to provide token and send this token with FROST-Client's each http requests. Is there a documentation to guide or any existed case to follow?
Any advice would be helpful.

All tests are failing due to recent pom changes

I noticed that the frost client pom was changed to use this instead of 1.8:
<maven.compiler.source>11</maven.compiler.source> <maven.compiler.target>11</maven.compiler.target>

I am receiving the following error when building with mvn version 3.6.3 with java version 11
java.lang.UnsupportedClassVersionError: org/mockito/Mockito has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

Using Gradle as Build Tool

Just had to figure out, how to use gradle as build tool. Perhaps you can integrate this information:
In app build.gradle you have to add:
implementation "de.fraunhofer.iosb.ilt:FROST-Client:0.15"
in the dependencies section
and in project build.gradle you have to add
maven { url "https://dl.bintray.com/fraunhoferiosb/Maven" }
in the repositories section

ExpandedEntity behaving unexpected

I wanted to use an Expansion to fetch a Datastream with its inner entities and inner entities of those entities.

Expansion.of(EntityType.DATASTREAM)
                    .with(ExpandedEntity.from(EntityType.THING, EntityType.LOCATIONS))

This is my code I expected to work but it throws an InvalidRelationException. I checked the implementation and found out that it will check EntityType.LOCATIONS.hasRelationTo(EntityType.THING) (but a list of Locations doesn't have a relation to one Thing) instead of EntityType.THING.hasRelationTo(EntityType.LOCATIONS). The ExpandedEntity#toString method would produce the expected output that can be used for $expand, so I guess I'm using it right.

I can create a pull request changing the direction of the relation check if you agree that this is a bug and my usage is correct.

Unable to extend the FROST-Client entity model

Hi,

I extended the base OGC SensorThings API entity model to fit with my business needs. However, I’m unable to express those extensions to the FROST-Client entity model.

Let’s take a concrete example: I would like to define a FooObservation that inherits of Observation (e.g. to only handle Foo Observation#result type instead of the base Any type).

To use my FooObservation with FROST-Client, the first trivial solution would be to extend the FROST-Client’s Observation entity. However, as any FROST-Client’s entities inherit of Entity<T extends Entity<T>>, then Observation inherits of Entity<Observation>, and so T is restricted to only be Observation and not an extension of Observation as our FooObservation.

The second solution would be to directly inherits of Entity<T extends Entity<T>>. But in this case, we have to call Entity’s constructors with a given EntityType. And this EntityType is a enum (so not extensible) of FROST-Client’s entities then we lost our specific FooObservation type.

Do you plan to let FROST-Client’s users to use their own OGC SensorThings API entity based model? If not, have you any advice to let me do that?

Regards,
Aurélien