Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fixes #67, fixes #1: Migrate to Jersey 2 and Swagger #70

Merged
merged 6 commits into from
Jan 16, 2022

Conversation

guusdk
Copy link
Member

@guusdk guusdk commented Dec 18, 2021

This updates the Jersey dependency from 1.x to 2.x.

This commit requires OF-2352 / igniterealtime/Openfire#1945 which means that this PR will not work with 4.7.0 beta (but hopefully will with 4.7.0 non-beta).

@guusdk guusdk requested a review from Redor December 18, 2021 11:13
@Redor
Copy link
Contributor

Redor commented Dec 18, 2021

wow, thats a good one. I have to take a bit of time to test it.

@Fishbowler Fishbowler force-pushed the 67_Migrate-to-Jersey-2 branch from ac5050f to 2ce034b Compare January 1, 2022 22:47
@Fishbowler
Copy link
Member

Rebased.

@Fishbowler
Copy link
Member

Testing on 4.7.0 master looks stable. Read and Write requests have identical behaviour and body content as master.

@guusdk guusdk marked this pull request as draft January 7, 2022 16:21
@guusdk
Copy link
Member Author

guusdk commented Jan 7, 2022

I've now added conversion to Swagger. It is fully functional, but not all documentation has been ported yet (work in progress).

image

@guusdk guusdk force-pushed the 67_Migrate-to-Jersey-2 branch 2 times, most recently from 38157e7 to 8a47fbc Compare January 7, 2022 19:13
@guusdk guusdk marked this pull request as ready for review January 7, 2022 19:14
@guusdk
Copy link
Member Author

guusdk commented Jan 7, 2022

I think I've added documentation for all endpoints. This is ready for review.

@guusdk guusdk changed the title fixes #67: Migrate to Jersey 2 fixes #67, fixes #1: Migrate to Jersey 2 and Swagger Jan 7, 2022
@guusdk
Copy link
Member Author

guusdk commented Jan 7, 2022

Note that the Swagger documentation that's added in this PR can't be used 'offline'. We still need to replace the static documentation (in readme.html) with something that's generated during compilation/packaging. This effort is tracked as issue #71.

I'm not sure if I get around to doing that soon (the holidays have come to an end :) ). Is this PR acceptable as-is?

@Fishbowler
Copy link
Member

This is great! I've even found a few new bugs using the swagger tool :)
Is there a way to set defaults for the XML Elements that are POST bodies? We could chip away at that in future PRs.
Also, any idea how to hide the /application.wadl entries in the default section at the bottom?

@Fishbowler
Copy link
Member

All of the descriptions look accurate. I've added one tiny tweak to mirror the same constraint on usergroup updates.

@guusdk
Copy link
Member Author

guusdk commented Jan 9, 2022

Is there a way to set defaults for the XML Elements that are POST bodies?

I don't recall that we can set defaults, but I think we can have more meaningful examples (with more valid-looking data than 'string').

Also, any idea how to hide the /application.wadl entries in the default section at the bottom?

I tried & failed. It should be easy - but disabling wadl support (which should prevent that documentation to be added didn't actually seem to disable wadl support. I'd be happy for that to be done, as I suspect that the endpoints won't be functional anyway.

@GregDThomas
Copy link
Contributor

FWIW, the values in the page default to the examples you configure in the code.

@guusdk
Copy link
Member Author

guusdk commented Jan 9, 2022

@Redor what do you think? For the 4.7.0 release of Openfire, we will need to publish a new version of this plugin. I'd love to include this PR.

@Redor
Copy link
Contributor

Redor commented Jan 9, 2022

It does look good, but didn't had the time to test it. (I will be tomorrow back from vacation). Will review it ASAP

@Override
public ContainerRequest filter(ContainerRequest containerRequest) throws WebApplicationException {
public void filter(ContainerRequestContext containerRequest) throws IOException {
if (containerRequest.getUriInfo().getRequestUri().getPath().equals("/plugins/restapi/v1/openapi.yaml")) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we exclude it? In swagger UI we can set the secret key. I think we should make fewer "exceptions" in the authentication part, which is crucial.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My reasoning for it to include it is for non-authenticated users to make use of the Swagger UI, which needs this file.

Every request made from the Swagger UI obviously needs to be authenticated, but that can be achieved through the Swagger UI-provided functionality.

@Redor
Copy link
Contributor

Redor commented Jan 12, 2022

ServiceException seems not to work, to show specific Error and status codes. E.g. instead of a "bad request", I'm getting always 500. Probably the handling is slightly different in jersey 2 or something specific to that request.

Example:
POST http://localhost:9090/plugins/restapi/v1/users

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<user>
    <username>test3</username>
</user>

which should be Bad request (because password is missing), but 500 will be returned

@Fishbowler
Copy link
Member

Another problem on a similar vein.
I've used the openapi.yaml to import as anew collection into Insomnia, which defaults to the JSON representation.
Something looks amiss with the collection-type properties.

POST http://localhost:9090/plugins/restapi/v1/users

{
  "username": "joseph",
  "name": "Joseph",
  "email": "[email protected]",
  "password": "secret",
  "properties": [
    {
      "key": "somekey",
      "value": "somevalue"
    }
  ]
}

Unrecognized field "properties" (class org.jivesoftware.openfire.plugin.rest.entity.UserEntity), not marked as ignorable (5 known properties: "name", "email", "property", "username", "password"])
at [Source: (org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$UnCloseableInputStream); line: 6, column: 18] (through reference chain: org.jivesoftware.openfire.plugin.rest.entity.UserEntity["properties"])

Using XML doesn't encounter the same issue. Something to do with the JSON representation not happy with the XmlElementWrapper? https://github.com/guusdk/openfire-restAPI-plugin/blob/67_Migrate-to-Jersey-2/src/java/org/jivesoftware/openfire/plugin/rest/entity/UserEntity.java#L140

@guusdk guusdk force-pushed the 67_Migrate-to-Jersey-2 branch from 2dfe26f to af31ebe Compare January 13, 2022 09:43
@guusdk
Copy link
Member Author

guusdk commented Jan 13, 2022

ServiceException seems not to work, to show specific Error and status codes. E.g. instead of a "bad request", I'm getting always 500.

The RestExceptionMapper didn't automatically register. I have now modified the code to do that manually which fixes the problem.

This updates the Jersey dependency from 1.x to 2.x.

This commit requires OF-2352 / igniterealtime/Openfire#1945 which means that this PR will _not_ work with 4.7.0 beta (but hopefully will with 4.7.0 non-beta).
This commit introduces an automatically generated Swagger-based REST client on /plugins/restapi/docs/index.html

Note that this can't be used 'offline'. We still need to replace the static documentation (in readme.html) with something that's generated during compilation/packaging (issue igniterealtime#71)
By adding certain annotations, the documentation as generated by Swagger becomes enriched.
@guusdk guusdk force-pushed the 67_Migrate-to-Jersey-2 branch from af31ebe to 863bd66 Compare January 13, 2022 09:56
@guusdk
Copy link
Member Author

guusdk commented Jan 13, 2022

Another problem on a similar vein.

Do you know if that happened before this PR? If so, I'd rather take on this issue in a separate effort.

@Fishbowler
Copy link
Member

Do you know if that happened before this PR?

Tested. It's new :(

@guusdk
Copy link
Member Author

guusdk commented Jan 13, 2022

Am I right to conclude that it affects POSTs, but not GETs?

@guusdk
Copy link
Member Author

guusdk commented Jan 13, 2022

Also, the JSON example titled "REST API Version 1.3.0 and later - Payload Example 3 (available parameters):" in the version prior to my changes was already not working, right? If not, then I'm not going to reinstate that. I expect that this is a bug in the documentation: it should have shown only the first element of that 'users' array, instead of the entire array.

@guusdk
Copy link
Member Author

guusdk commented Jan 13, 2022

I think I've now fixed this for all occurrences of XmlElementWrapper. I've compared JSON based retrieval and posts with version 1.6.0 of the plugin, and I think that with this update, we retain the existing behavior in 1.6.0.

@Fishbowler
Copy link
Member

I'm seeing working JSON, and the lovely custom errors when I do the wrong thing. 👍 👍
Will spend a little while longer testing this time!

@Fishbowler
Copy link
Member

I've tested everything except the MUC permissions endpoints and the legacy UserService, and pushed one additional commit to add another annotation.
Everything JSON is working - I've not tested much in XML, as it's likely safer.

@Redor Redor merged commit 5ced36b into igniterealtime:master Jan 16, 2022
@Redor
Copy link
Contributor

Redor commented Jan 16, 2022

Thy all for the great effort!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants