I am using JHipster v6.6.0 and I want to display customized error messages to users.
This question has been asked before and answered by using the class CustomParameterizedException.
But I can not find this class in the JHipster version that I am using.
Has the class been removed? And if so, what can be used instead?
The class CustomParameterizedException was removed in PR#9624 in favor of the Problem library.
Quoting the documentation on Managing Server Errors:
To handle Spring MVC REST errors, JHipster uses Zalando’s Problem Spring Web library, in order to provide rich, JSON-based error messages.
You can achieve the same custom error messages as before with less effort and more customization options.
import org.zalando.problem.Problem;
import org.zalando.problem.Status;
...
throw Problem.builder()
.withStatus(Status.BAD_REQUEST)
.with("param1", "value 1")
.with("param2", "value 2")
.build();
If you notice, this is how JHipster handles errors in base components (users, accounts, authorization).
Check the ExceptionTranslator.java class for examples and guidance. A good place to start would be handleMethodArgumentNotValid() I think, but my experience with the Problem library is very limited.
Related
I want to get all destinations on subaccount and instance level. In SAP API business Hub, I found the API information and "SAP Cloud SDK" tab to generate code by OpenAPI generator.
https://api.sap.com/api/SAP_CP_CF_Connectivity_Destination/overview
I downloaded the API specification and added dependencies into Cloud SDK for Java project. The code is generated successfully with some errors (unknown models）in generated api classes.
For example in DestinationsOnSubaccountLevelApi.class, model OneOfDestinationNameOnly is imported and used in method but it is not generated in model package.
I looked into API specification and found that there were two types of response entity. That is the reason why the code could not be generated properly. I can modify the API specification to make it work but it should not be the long term solution. Is there any other way to fix this issue?
Unfortunately the SAP Cloud SDK Generator for Open API services is not yet able to understand oneOf relationship that is modeled in the specification.
As an alternative, would you consider using the DestinationAccessor API for resolving single destinations?
You can also directly instantiate an ScpCfDestinationLoader, which allows for querying all destinations:
ScpCfDestinationLoader loader = new ScpCfDestinationLoader();
DestinationOptions options = DestinationOptions
.builder()
.augmentBuilder(ScpCfDestinationOptionsAugmenter.augmenter().retrievalStrategy(ScpCfDestinationRetrievalStrategy.ALWAYS_SUBSCRIBER))
.build();
Try<Iterable<ScpCfDestination>> destinations = loader.tryGetAllDestinations(options);
Similar to the default behavior of DestinationAccessor API, in the code above only the subscriber account will be considered. Other options are:
ScpCfDestinationRetrievalStrategy.ALWAYS_SUBSCRIBER
ScpCfDestinationRetrievalStrategy.ALWAYS_PROVIDER
ScpCfDestinationRetrievalStrategy.SUBSCRIBER_THEN_PROVIDER
I have a working ordinary Hapi application that I'm planning to migrate to Swagger. I installed swagger-node using the official instructions, and chose Hapi when executing 'swagger project create'. However, I'm now confused because there seem to be several libraries for integrating swagger-node and hapi:
hapi-swagger: the most popular one
hapi-swaggered: somewhat popular
swagger-hapi: unpopular and not that active but used by the official Swagger Node.js library (i.e. swagger-node) as default for Hapi projects
I though swagger-hapi was the "official" approach, until I tried to find information on how do various configurations on Hapi routes (e.g. authorization, scoping, etc.). It seems also that the approaches are fundamentally different, swagger-hapi taking Swagger definition as input and generating the routes automatically, whereas hapi-swagger and hapi-swaggered seem to have similar approach with each other by only generating Swagger API documentation from plain old Hapi route definitions.
Considering the amount of contributors and the number of downloads, hapi-swagger seems to be the way to go, but I'm unsure on how to proceed. Is there an "official" Swagger way to set up Hapi, and if there is, how do I set up authentication (preferably by using hapi-auth-jwt2, or other similar JWT solution) and authorization?
EDIT: I also found swaggerize-hapi, which seems to be maintained by PayPal's open source kraken.js team, which indicates that it might have some kind of corporate backing (always a good thing). swaggerize-hapi seems to be very similar to hapi-swagger, although the latter seems to provide more out-of-the-box functionality (mainly Swagger Editor).
Edit: Point 3. from your question and understanding what swagger-hapi actually does is very important. It does not directly serves the swagger-ui html. It is not intended to, but it is enabling the whole swagger idea (which the other projects in points 1. and 2. are actually a bit reversing). Please see below.
It turns out that when you are using swagger-node and swagger-hapi you do not need all the rest of the packages you mentioned, except for using swagger-ui directly (which is used by all the others anyways - they are wrapping it in their dependencies)
I want to share my understanding so far in this hapi/swagger puzzle, hope that these 8 hours that I spent can help others as well.
Libraries like hapi-swaggered, hapi-swaggered-ui, also hapi-swagger - All of them follow the same approach - that might be described like that:
You document your API while you are defining your routes
They are somewhat sitting aside from the main idea of swagger-node and the boilerplate hello_world project created with swagger-cli, which you mentioned that you use.
While swagger-node and swagger-hapi (NOTE that its different from hapi-swagger) are saying:
You define all your API documentation and routes **in a single centralized place - swagger.yaml**
and then you just focus on writing controller logic. The boilerplate project provided with swagger-cli is already exposing this centralized place swagger.yaml as json thru the /swagger endpoint.
Now, because the swagger-ui project which all the above packages are making use of for showing the UI, is just a bunch of static html - in order to use it, you have two options:
1) to self host this static html from within your app
2) to host it on a separate web app or even load the index.html directly from file system.
In both cases you just need to feed the swagger-ui with your swagger json - which as said above is already exposed by the /swagger endpoint.
The only caveat if you chose option 2) is that you need to enable cors for that end point which happened to be very easy. Just change your default.yaml, to also make use of the cors bagpipe. Please see this thread for how to do this.
As #Kitanotori said above, I also don't see the point of documenting the code programmatically. The idea of just describing everything in one place and making both the code and the documentation engine to understand it, is great.
We have used Inert, Vision, hapi-swagger.
server.ts
import * as Inert from '#hapi/inert';
import * as Vision from '#hapi/vision';
import Swagger from './plugins/swagger';
...
...
// hapi server setup
...
const plugins: any[] = [Inert, Vision, Swagger];
await server.register(plugins);
...
// other setup
./plugins/swagger
import * as HapiSwagger from 'hapi-swagger';
import * as Package from '../../package.json';
const swaggerOptions: HapiSwagger.RegisterOptions = {
info: {
title: 'Some title',
version: Package.version
}
};
export default {
plugin: HapiSwagger,
options: swaggerOptions
};
We are using Inert, Vision and hapi-swagger to build and host swagger documentation.
We load those plugins in exactly this order, do not configure Inert or Vision and only set basic properties like title in the hapi-swagger config.
I have written several functional tests for Pyramid framework application. The HTML response is generated using webtest. Then the test would assert whether a string exists in the body or does not.
Additionally I would like to inspect the global variables. Since Pyramid does not use "template context" anymore, my views and mako templates rely on the request.context.
However I don't know how to access them during a functional test using the webtest library.
Does anyone know how to access request.context or even "template context" during functional testing?
Here are some quotes relevant to this topic.
"In addition to the methods on the self.app() object, Pylons also gives you access to some of the Pylons globals that have been created during the request."
"The Pyramid structure has three major benefits:
1(...), 2( It's simpler and more modular. No magic globals ), 3(...)"
It is not documented in the Pyramid docs. Maybe their desire is to kill this feature once and for all.
import pyramid
dir(pyramid.request)
You will now see the documented and probably preferred 'Request' and the legacy 'TemplateContext'.
Import it in your controller or unit test files as usual to get it working or in your main configuration file.
I setup the Social Business Toolkit against our development system. All APIs are working correct, except for the Blog and Activities API.
For both i recieve within the Java APIs the following error:
org.apache.http.conn.EofSensorInputStream cannot be cast to org.w3c.dom.Document
The blog request url from the sbt is:
http://example.com/service/proxy/connections/blogs/homepage/feed/blogs/atom?ps=5&dojo.preventCache=13
But correct would be:
http://example.com/service/proxy/connections/blogs/atom?ps=5&dojo.preventCache=13
Any idea why that happens?
The blog path is customizable per each IBM Connection installation: to support different blogs homepages, there is a parameter exposed on the BlogService API.
To change the default, try:
BlogService svc = ...
svc.defaultHomepageHandle = "";
Lorenzo's answer is correct, most installations use homepage as the blog handle, but you can configure it using the defaultHomepageHandle member variable in the BlogService.
Just a brief comment, maybe it's better to use the setHomepageHandle() method instead.
I'm using Castle Windsor and Binsor to use dependency injection in my application. I'm no expert at either one. Usually I can figure out how to bend Windsor to my will, but I find Binsor much harder, especially since I haven't found any decent documentation for it.
I'm trying to create a binsor configuration file where I use logging. I configure logging using the following binsor code:
facility LoggingFacility:
loggingApi = LoggerImplementation.Log4net
configFile = "ParasiteLogConf.log4net"
This works great, all components that are registered with the container and that takes an ILogger object as an argument to the constructor will receive the correct ILogger instance.
However, what I want to do now is to use another logger for one specific component. I want that component to log to a file, whereas the other components should only log to screen. How would I go about expressing that using Binsor code?
Aynede#Rahien is your friend here. He has many blog posts on using and configuring Binsor.
For the special logger, you need to add it as a component and then explicitly set the logger property of the dependent component to the id of the special logger component.