oli-d / nova Goto Github PK

HttpServer httpServer = GrizzlyHttpServerFactory.createHttpServer(
baseUri,
resourceConfig,
false // so Grizzly won't start automatically
);

httpServer.getServerConfiguration().setDefaultErrorPageGenerator(...);

httpServer.start();

https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest/wadl.html#d0e13291

WADL generation is enabled in Jersey by default. This means that OPTIONS methods are added by default to each resource and an auto-generated /application.wadl resource is deployed too. To override this default behavior and disable WADL generation in Jersey, setup the configuration property in your application:
jersey.config.server.wadl.disableWadl=true
This property can be setup in a web.xml if the Jersey application is deployed in the servlet with web.xml or the property can be returned from the Application.getProperties(). See Deployment chapter for more information on setting the application configuration properties in various deployments.
WADL support in Jersey is implemented via ModelProcessor extension. This implementation enhances the application resource model by adding the WADL providing resources. WADL ModelProcessor priority value is high (i.e. the priority is low) as it should be executed as one of the last model processors. Therefore, any ModelProcessor executed before will not see WADL extensions in the resource model. WADL handling resource model extensions (resources and OPTIONS resource methods) are not added to the application resource model if there is already a matching resource or a resource method detected in the model. In other words, if you define for example your own OPTIONS method that would produce "application.wadl" response content, this method will not be overridden by WADL model processor. See Resource builder chapter for more information on ModelProcessor extension mechanism.

We noticed a strange behaviour that may be related with Nova RpcServer->NonBlockingHttpHandler
When making a request from our services, the requests fail if the json string is longer than 256 characters which happens to be READ_CHUNK_SIZE from the above class; it seems that the unmarshalling is triggered before all data is read, thus incomplete json chunks gets to be deserialized (which of course that fails);
please take a look

Currently, the BeanExaminer uses class.getMethods() whicg only returns public methods. Therefore, if you annotate a default or package protected method, it will not be picked up and you don't see anything in the logs.

The ElasticMetricsReporter has a problem in v 6.0.0 with _@timestamp field set - it puts the LocalDateTime object and ES fails to index because of that - it should be a numeric timestamp; see:
LocalDateTime timestampInUtc = timestampInUtc(metricsDump.timestamp);
additionalAttributes.put("@timestamp", timestampInUtc);
Beside that additionalMetricAttributes field is not used anymore in the methods that are at the moment doing push to ES.

something like this should fix it:

private long timestampInUtc(long timestampInMillis) {
return Instant.ofEpochMilli(timestampInMillis).atZone(zoneForTimestamps).toInstant().toEpochMilli();
}

private Map<String, Object> buildHostAndTimestampInfo(long timestamp, String hostName, String hostAddress) {
Map<String, Object> additionalInfo = new HashMap<>();
additionalInfo.put("@timestamp", timestampInUtc(timestamp));
additionalInfo.put("host", hostName);
additionalInfo.put("hostAddress", hostAddress);
if (additionalMetricAttributes != null && !additionalInfo.isEmpty()) {
additionalInfo.putAll(additionalMetricAttributes);
}
return additionalInfo;
}

Registering for incoming HTTP requests on the root path, does not seem to work

timeTeller.http().requests("/").subscribe(rpc -> {
	rpc.complete("Welcome!");
});

Trying to send a request to that endpoint results in a 404

ch.squaredesk.nova.comm.http.HttpRequestSender doesn't have any option to pass headers to requests..
please add that additional parameter (Map<> or so) and uset it to set headers for request (connection.setRequestProperty("name", "value"))

see: https://stackoverflow.com/questions/30653012/multipart-form-data-no-injection-source-found-for-a-parameter-of-type-public-ja

Currently, MIME types are represented as an enum (MediaType) in Nova. This does not allow user to specify new MIME types when using the libs. Since we do not want to release a new version for every MIME type, it should be possible to specify arbitrary ones

The name of the bean methods doesn't correspong with the key returned from environment resulting a mess up.

@bean("httpServerTrustStore")
public String sslTrustStorePass() { // it should be sslTrustStorePath
return environment.getProperty("NOVA.HTTP.SERVER.TRUST_STORE");
}
@bean("httpServerTrustStorePass")
public String sslTrustStorePath() { // is shold be sslTrustStorePass
return environment.getProperty("NOVA.HTTP.SERVER.TRUST_STORE_PASS");
}

Exactly the same problem is with key store options:

@bean("httpServerKeyStore")
public String sslKeyStorePass() { // is shold be sslKeyStorePath
return environment.getProperty("NOVA.HTTP.SERVER.KEY_STORE");
}
@bean("httpServerKeyStorePass")
public String sslKeyStorePath() {// is shold be sslKeyStorePass
return environment.getProperty("NOVA.HTTP.SERVER.KEY_STORE_PASS");
}