servicecatalog / oscm-rest-api Goto Github PK

Summary
Right now, travis configuration consists only of running the tests. Let's improve it to work efficiently and provide more error-safety

Details
TBD

Acceptance criteria

• travis yaml should allow maven dependency caching
• build stages are required
• automatic code formatting should be enabled for this project

Additional context
TBD

Summary
Instead of providing version numbers for commonly used dependencies in each sub-project, let's centralize it in master POM, using dependency management.

Details
TBD

Acceptance criteria

• dependency management is in use

Additional context
TBD

Summary
Right now, authorization configuration for REST API modules are provided inside of web.xml.
It is needed to check (and if possible - apply) wether it is possible to replace this web.xml config with java configuration.

Details
N/A

Acceptance criteria

• check if it possible to configure rest api acces in java config
• • all modules have configuration in java classes

Additional context
N/A

Summary
Right now, in order to deploy one of REST API module to oscm-core virtual machine it is necessary to perform all the steps manually.
REST API modules should be automatically built and deployed in scope of exsting Jenkins job

Details
N/A

Acceptance criteria
Following REST API modules are automatically deployable by Jenkins job:
- [x] oscm-rest-api-account
- [ ] oscm-rest-api-event
- [x] oscm-rest-api-identity
- [x] oscm-rest-api-marketplace
- [x] oscm-rest-api-operation
- [x] oscm-rest-api-service
- [ ] oscm-rest-api-subscription

Following #90:

• oscm-rest-api

Additional context
N/A

Summary
Right now, error messages that are delivered though API request are not meaningful at all.
We should review them and make it so end user actually knows what went wrong.

Details
N/A

Acceptance criteria

• error handling is reviewed
• error messages are more meningfull (no generic error messages!)
• proper error codes are used - 4xx for internal errors, 5xx for external errors

Additional context
N/A

Summary
To ensure higher code quality let's introduce SonarQube support for this repository.

Details
TBD

Acceptance criteria
TBD

Additional context

• check wether it is fine to block the build on travis, when quality gate is not met

This repository should have the same task/bug/feature templates as main OSCM repository

Add CodeCov to mesaure code coverage for the modules like it is done in other OSCM repositories.

Summary
There are some Representation-type classes that are duplicated. Let's merge/remove them up.

Details
N/A

Acceptance criteria

• There is only one Representation class of each type
• all representations and parameter classes are moved to commons module
• respective test classes are also moved to commons package
• code coverage is not decreased

Additional context

• it's best for this task to be completed after integration tests are done - this will ensure integrity
• Some example duplicates:
  

Summary
End-to-end tests should be provided for this module, to make sure that every endpoint works properly

Details
Integration tests should be implemented in form of separate maven submodule.
Worth noting is hovever that, due to submodules packaging being set to war it's not possible to use internal dependencies in this new submodule OOTB, as Maven uses jar packacking for dependencies.
It is needed to find a solution (maybe some configuration in POM?) for that issue.

Acceptance criteria

• every endpoint has it's own integrations tests
• *Backend classes are covered by tests

Additional context

• REST Assured library can be used for tests implementation ( REST Assured home page )

Summary
In several places in the code there are methods marked with FIXME tag.
They are supposed to be moved to parent class.

Details
N/A

Acceptance criteria

• methods marked as FIXME are moved to their respective parent classes
• there are no methods explicitly destined to be moved to parent class in the code

Additional context
Add any other context or screenshots about the task.

Summary
End-to-end tests should be provided for this module, to make sure that every endpoint works properly

Details
Integration tests should be implemented in form of separate maven submodule.
Worth noting is hovever that, due to submodules packaging being set to war it's not possible to use internal dependencies in this new submodule OOTB, as Maven uses jar packacking for dependencies.
It is needed to find a solution (maybe some configuration in POM?) for that issue.

Acceptance criteria

• every endpoint has it's own integrations tests
• *Backend classes are covered by tests

Additional context

• REST Assured library can be used for tests implementation ( REST Assured home page )

Task:

• Test deployment of war file in tomee and investigate required adaption if any
• Test retrieving an existing organiztion: Build resource URL from yaml file (/organizations/{id}) and test access in the browser

Summary
End-to-end tests should be provided for this module, to make sure that every endpoint works properly

Details
Integration tests should be implemented in form of separate maven submodule.
Worth noting is hovever that, due to submodules packaging being set to war it's not possible to use internal dependencies in this new submodule OOTB, as Maven uses jar packacking for dependencies.
It is needed to find a solution (maybe some configuration in POM?) for that issue.

Acceptance criteria

• every endpoint has it's own integrations tests
• *Backend classes are covered by tests

Additional context

• REST Assured library can be used for tests implementation ( REST Assured home page )

Summary
Swagger documentation should be provided for Event API endpoints

Details
N/A

Acceptance criteria

• Event API module has its own Swagger documentation
• Swagger version is updated to the latest one
• Mandatory parameters are documented

Additional context

• there are some swagger-related filed that can be used as a guideline (ex. account-service-rest-api.yaml)
• swagger documentation should be configured using Java annotations

By migrating to JEE 7 in OSCM v17.0 the core REST APIs have been upgraded to JAX-RS 2.0 requiring jersey 2.0. In order to compile with latest OSCM, the contained dependent API projects need to be upgraded as well.

Summary****Summary
Swagger documentation should be provided for Identity API endpoints

Details
N/A

Acceptance criteria

• Identity API module has its own Swagger documentation
• Swagger version is updated to the latest one
• Mandatory parameters are documented

Additional context

• there are some swagger-related filed that can be used as a guideline (ex. account-service-rest-api.yaml)
• swagger documentation should be configured using Java annotations

Clear description or/and business justification of what the task is about.

Details
If applicable, detailed information regarding things to be considered, requirements etc.

Acceptance criteria
Precise and detailed conditions under which the task is considered to be completed.

Additional context
Add any other context or screenshots about the task.

Describe the bug
From PR #80 travis builds begant to fail. The build on the branch passed (thus it was possible to merge the PR), but when post-merge build was triggered on master - it failed due to some unexpected exeption (see the screenshot). It is necessary to fix that issue as it basically blocks all the merges and renders the CI unusable.

To Reproduce
Steps to reproduce the behavior:

1. Create new branch
2. Create commit and push it
3. Go to travis page for your build
4. See build failing

Expected behavior
When there is no issue with the code itself, builds should pass

Observed behavior
All builds are failing even before attempting to run the maven goals

Screenshots

Additional context

• https://travis-ci.community/t/the-travis-ci-build-could-not-be-completed-due-to-an-error/1345/3.
• travis-ci/travis-ci#10290
• It appears that the error is caused by xenial (where jdk8 is not preinstalled) being default build distro now. All passing build were run on trusty where failing ones runs on xenial

For building on Jitpack find instructions on https://jitpack.io. This is very easy and useful for later integration with the OSCM Core build.

Generate snapshot build from master branch on this repo.
Simply click this URL -> https://jitpack.io/#servicecatalog/oscm-rest-api/master-SNAPSHOT
Add the snipet to the parent pom file of this multi module project.

Compare the settings with the configuration in oscm-interfaces.

Summary
Swagger documentation should be provided for Subscription API endpoints

Details
N/A

Acceptance criteria

• Subscription API module has its own Swagger documentation
• Swagger version is updated to the latest one
• Mandatory parameters are documented

Additional context

• there are some swagger-related filed that can be used as a guideline (ex. account-service-rest-api.yaml)
• swagger documentation should be configured using Java annotations

Summary
After initial investigation, the single war package for event related API is deployable after aligning module's web.xml configuration.

Details
org.oscm.rest.common.BasicAuthFilter does not exist in any of the project dependencies. It leads to problem with API deployment. After removing it deployment is possible, but the API is not working as there is no authentication provided - OSCM's EJBs which are used underneath require proper user roles. Such authentication filter must be reintroduced.

Acceptance criteria

• OSCM EVENT REST API war is deployable inside existing oscm-core container
• it is possible to access API using BASIC authentication
• endpoints functionality is verified

Additional context
N/A

Unit tests have to be implemented for oscm-rest-api-service submodule.

Details
N/A

Acceptance criteria

• overall code coverage is at least 60%

Unit tests for following submodules are implemented:

• oscm-rest-api-service

Additional context:
N/A

Summary
After initial investigation, the single war package for marketplace related API is deployable after aligning module's web.xml configuration.

Details
org.oscm.rest.common.BasicAuthFilter does not exist in any of the project dependencies. It leads to problem with API deployment. After removing it deployment is possible, but the API is not working as there is no authentication provided - OSCM's EJBs which are used underneath require proper user roles. Such authentication filter must be reintroduced.

Acceptance criteria

• OSCM MARKETPLACE REST API war is deployable inside existing oscm-core container
• it is possible to access API using BASIC authentication
• endpoints functionality is verified

Additional context
N/A

Summary
After initial investigation, the single war package for subscription related API is deployable after aligning module's web.xml configuration.

Details
org.oscm.rest.common.BasicAuthFilter does not exist in any of the project dependencies. It leads to problem with API deployment. After removing it deployment is possible, but the API is not working as there is no authentication provided - OSCM's EJBs which are used underneath require proper user roles. Such authentication filter must be reintroduced.

Acceptance criteria

• OSCM SUBSCRIPTION REST API war is deployable inside existing oscm-core container
• it is possible to access API using BASIC authentication
• endpoints functionality is verified

Additional context
N/A

Unit tests have to be implemented for oscm-rest-api-subscription submodule.

Details
N/A

Acceptance criteria

• overall code coverage is at least 60%

Unit tests for following submodules are implemented:

• oscm-rest-api-subscription

Additional context:
No

Summary
Swagger documentation should be provided for Account API endpoints

Details
N/A

Acceptance criteria

• Account API module has its own Swagger documentation
• Swagger version is updated to the latest one
• Mandatory parameters are documented

Additional context

• there are some swagger-related filed that can be used as a guideline (ex. account-service-rest-api.yaml)
• swagger documentation should be configured using Java annotations

Unit tests have to be implemented for oscm-rest-api-account and oscm-rest-api-identity submodules.

Details
No

Acceptance criteria

• overall code coverage is at least 60%

Unit tests for following submodules are implemented:

• oscm-rest-api-account
• oscm-rest-api-identity

Additional context:
No

Remove dependency to com.github.servicecatalog.oscm-commons. Check shared modules from oscm-commons and integrate those which are needed here.

Also, move oscm-rest-api-commons module to this repo

See servicecatalog/oscm-commons#5

Summary
After initial investigation, the single war package for account related API is deployable aliging module's web.xml configuration.

Details
org.oscm.rest.common.BasicAuthFilter does not exist in any of the project dependencies. It leads to problem with API deployment. After removing it deployment is possible, but the API is not working as there is no authentication provided - OSCM's EJBs which are used underneath require proper user roles. Such authentication filter must be reintroduced.

Acceptance criteria

• OSCM ACCOUNT REST API war is deployable inside existing oscm-core container
• it is possible to access API using BASIC authentication
• endpoints functionality is verified

Additional context
N/A

Unit tests have to be implemented for oscm-rest-api-event submodule.

Details
N/A

Acceptance criteria

• overall code coverage is at least 60%

Unit tests for following submodules are implemented:

• oscm-rest-api-event

Additional context:
N/A

Summary
End-to-end tests should be provided for this module, to make sure that every endpoint works properly

Details
Integration tests should be implemented in form of separate maven submodule.
Worth noting is hovever that, due to submodules packaging being set to war it's not possible to use internal dependencies in this new submodule OOTB, as Maven uses jar packacking for dependencies.
It is needed to find a solution (maybe some configuration in POM?) for that issue.

Acceptance criteria

• every endpoint has it's own integrations tests
• *Backend classes are covered by tests

Additional context

• REST Assured library can be used for tests implementation ( REST Assured home page )

Summary
After initial investigation, the single war package for identity related API is deployable after aligning module's web.xml configuration.

Details
org.oscm.rest.common.BasicAuthFilter does not exist in any of the project dependencies. It leads to problem with API deployment. After removing it deployment is possible, but the API is not working as there is no authentication provided - OSCM's EJBs which are used underneath require proper user roles. Such authentication filter must be reintroduced.

Acceptance criteria

• OSCM IDENTITY REST API war is deployable inside existing oscm-core container
• it is possible to access API using BASIC authentication
• endpoints functionality is verified

Additional context
N/A

Summary
In order for this repos unit tests to be consistent, let's recheck and improve the code whereever possible.

Details
N/A

Acceptance criteria

• overall code coverage is at least 70%
• unit tests for following modules are checked and refactored (if applicable)
• • oscm-rest-commons
• • oscm-rest-account
• • oscm-rest-identity
• • oscm-rest-marketplace
• • oscm-rest-operation
• • oscm-rest-service

Additional context
N/A

Summary
After initial investigation, the single war package for operation related API is deployable after aligning module's web.xml configuration.

Details
org.oscm.rest.common.BasicAuthFilter does not exist in any of the project dependencies. It leads to problem with API deployment. After removing it deployment is possible, but the API is not working as there is no authentication provided - OSCM's EJBs which are used underneath require proper user roles. Such authentication filter must be reintroduced.

Acceptance criteria

• OSCM OPERATION REST API war is deployable inside existing oscm-core container
• it is possible to access API using BASIC authentication
• endpoints functionality is verified

Additional context
N/A

Summary
Please remove @produces annotation where it is not needed.

Details
I noticed that @produces (json) annotation is used in every endpoint and it is obviously not necessary.

Acceptance criteria
@produces annotation is left only where it is necessary.

Summary
Right now, error messages that are delivered though API request are not meaningful at all.
We should review them and make it so end user actually knows what went wrong.

Details
N/A

Acceptance criteria

• error handling is reviewed
• error messages are more meningfull (no generic error messages!)
• proper error codes are used - 4xx for internal errors, 5xx for external errors

Additional context
N/A

Unit tests have to be implemented for oscm-rest-api-operation submodule.

Details
No

Acceptance criteria

• overall code coverage is at least 60%

Unit tests for following submodules are implemented:

• oscm-rest-api-operation

Additional context:
No

Building the API from source requires an OSCM workspace and with contained ANT based scripts. Instead of later dependency provide for a separate maven build from OSCM binaries.

Summary
End-to-end tests should be provided for this module, to make sure that every endpoint works properly

Details
Integration tests should be implemented in form of separate maven submodule.
Worth noting is hovever that, due to submodules packaging being set to war it's not possible to use internal dependencies in this new submodule OOTB, as Maven uses jar packacking for dependencies.
It is needed to find a solution (maybe some configuration in POM?) for that issue.

Acceptance criteria

• every endpoint has it's own integrations tests
• *Backend classes are covered by tests

Additional context

• REST Assured library can be used for tests implementation ( REST Assured home page )
• it would be cleaner if integration tests have their own submodule. Here's the reference how to add wars as dependencies: https://stackoverflow.com/questions/31020038/how-can-i-add-war-file-to-another-java-web-application-dependencies
• it could be necessary to run these tests in separate container!
• to setup test data, check for SAMPLE_DATA in jenkins or export existing table and import it before test run
• maybe use Maven Cargo Plugin?

Provide for description in this repository readme on how to deploy the API with latest OSCM.

Summary
I think it would be a good idea to write a few lines of documentation in the README file.

Acceptance criteria
Readme is informing about simple details, such as where it is deployed or how to access Swagger UI after it is merged to master.

Additional context
I think it should be done after merging swagger branch to master.

Summary
End-to-end tests should be provided for this module, to make sure that every endpoint works properly

Details
Integration tests should be implemented in form of separate maven submodule.
Worth noting is hovever that, due to submodules packaging being set to war it's not possible to use internal dependencies in this new submodule OOTB, as Maven uses jar packacking for dependencies.
It is needed to find a solution (maybe some configuration in POM?) for that issue.

Acceptance criteria

• every endpoint has it's own integrations tests
• *Backend classes are covered by tests

Additional context

• REST Assured library can be used for tests implementation ( REST Assured home page )

Summary
As Integration tests are most likely needed to be performed outside of travis flow, code coverage coming from them will not by countend towards overall code coverage.
It is needed then to provide unit-like tests for that purpose.

Details
N/A

Acceptance criteria

• all * Backend-type classes have code coverage

Additional context
N/A

Unit tests have to be implemented for oscm-rest-api-marketplace submodule.

Details
No

Acceptance criteria

• overall code coverage is at least 60%

Unit tests for following submodules are implemented:

• oscm-rest-api-marketplace

Additional context:
No

Summary
End-to-end tests should be provided for this module, to make sure that every endpoint works properly

Details
Integration tests should be implemented in form of separate maven submodule.
Worth noting is hovever that, due to submodules packaging being set to war it's not possible to use internal dependencies in this new submodule OOTB, as Maven uses jar packacking for dependencies.
It is needed to find a solution (maybe some configuration in POM?) for that issue.

Acceptance criteria

• every endpoint has it's own integrations tests
• *Backend classes are covered by tests

Additional context

• REST Assured library can be used for tests implementation ( REST Assured home page )

Summary
Swagger documentation should be provided for Service API endpoints

Details
N/A

Acceptance criteria

• Service API module has its own Swagger documentation
• Swagger version is updated to the latest one
• Mandatory parameters are documented

Additional context

• there are some swagger-related filed that can be used as a guideline (ex. account-service-rest-api.yaml)
• swagger documentation should be configured using Java annotations

Describe the bug
We've noticed that sometimes pull requests are being merged automatically without confirmation from the user.

To Reproduce
There are no specific steps yet. Let's observe the repository and try to find something that's common for all of the cases.

Expected behavior
Pull Requests are merged only after all checks have passed and user responsible for merging particular PR, explicitly triggered the merging action.

Observed behavior
Pull Requests are being merged without user explicit approval and even no checks have passed.

Screenshots

Additional context

• the issue does not appear on main oscm repository
• for now branch protection settings are the same as on the main oscm repo, but checks are enforced on administrative users also

Summary
Swagger documentation should be provided for Marketplace API endpoints

Details
N/A

Acceptance criteria

• Marketplace API module has its own Swagger documentation
• Swagger version is updated to the latest one
• Mandatory parameters are documented

Additional context

• there are some swagger-related filed that can be used as a guideline (ex. account-service-rest-api.yaml)
• swagger documentation should be configured using Java annotations

Summary
It is possible to replace anonymous classes with lambda expressions (ex. in .EventBackend#24)
Let's do this in separate task to keep the code clean and changes transparent.

Details
N/A

Acceptance criteria
Lambda expressions are used instead of anonymous classes

Additional context

Before:

After:

Summary
Swagger documentation should be provided for Operation API endpoints

Details
N/A

Acceptance criteria

• Operation API module has its own Swagger documentation
• Swagger version is updated to the latest one
• Mandatory parameters are documented

Additional context

• there are some swagger-related filed that can be used as a guideline (ex. account-service-rest-api.yaml)
• swagger documentation should be configured using Java annotations

Summary
After initial investigation, the single war package for service related API is deployable after aligning module's web.xml configuration.

Details
org.oscm.rest.common.BasicAuthFilter does not exist in any of the project dependencies. It leads to problem with API deployment. After removing it deployment is possible, but the API is not working as there is no authentication provided - OSCM's EJBs which are used underneath require proper user roles. Such authentication filter must be reintroduced.

Acceptance criteria

• OSCM SERVICE REST API war is deployable inside existing oscm-core container
• it is possible to access API using BASIC authentication
• endpoints functionality is verified

Additional context
N/A