Provide the ability to upload patches #78 #104
Conversation
* created upload job request and status * renamed HealthCheckResult to CustomJobResult and HealthCheckResultLevel to CustomJobResultLevel * created a new rest endpoint for package upload with the role of instantiating a job with the given reference and time stamp * added a new endpoint to ServerInfo interface for retrieving the XWiki installation path * implemented the logic of package archive upload which includes: original file search and backup creation, batch file save (file replacement), batch backup restore in case of an error * created the ImportPackage page for user interface * created the hidden PackagesStore for archive storage * created liveData table for saving a package and starting the upload process * created liveData table (with PackagesJSON document) for showing the already uploaded packages * created a template for executing and showing the progress of a package upload * code refactoring * added transalations
# Conflicts: # application-admintools-ui/pom.xml
* remove packagesStore document
|
There are no tests added yet, I will add them in a future commit. |
* created upload job request and status * renamed HealthCheckResult to CustomJobResult and HealthCheckResultLevel to CustomJobResultLevel * code refactoring
|
This PR depends on modifications made in #107. |
* removed healthCheckJob.xml
* refactored CustomJobResult to JobResult * refactored CustomJobResultLevel to JobResultLevel
* refactored CustomJobResult to JobResult * refactored CustomJobResultLevel to JobResultLevel
# Conflicts: # application-admintools-ui/src/main/resources/AdminTools/Code/Translations.xml
# Conflicts: # application-admintools-ui/src/main/resources/AdminTools/Code/Translations.xml
* added unit tests for UploadJob * refactored UploadJob in UploadJob and UploadJobFileProcessor
application-admintools-api/src/main/java/com/xwiki/admintools/ServerInfo.java
Show resolved
Hide resolved
| */ | ||
| public PackageUploadJobRequest() | ||
| { | ||
| setDefaultId(); |
There was a problem hiding this comment.
Not sure we should do this. If we do have multiple jobs with the same id, we should be mindful that only one upload job should run at a time. Im not sure what is the behaviour of the job manager/executor if you want to execute two jobs with the same id concurrently. If you can, the job logs will probably be overwritten in the permanent directory. The job progress might also act up.
On a second thought, one might not be interested to save ALL the logs of a potentially really big number of uploads (depends on your use case). If Admin tools is installed as root, it should be ok to have only one id for all the upload jobs. Otherwise, it might be better to have an id per wiki. But i still think we should take precaution and not run these jobs simultaneously.
There was a problem hiding this comment.
Admin tools is used as root, and for the upload jobs that I'm creating I'm using the attachment reference and startTime of the job to create the job ID, this way the jobs are unique. If you think it would be safer to ensure that only one job at a time is running, I could create a general ID and check if there is any job running for said ID. The issue with this is that the logs will be overwritten. To prevent multiple jobs with the same file reference running at the same time, I'm using JobGroupPath which will prevent two jobs with the same file reference to run at the same time.
application-admintools-api/src/main/java/com/xwiki/admintools/jobs/PackageUploadJobRequest.java
Outdated
Show resolved
Hide resolved
| @Unstable | ||
| public class PackageUploadJobStatus extends DefaultJobStatus<PackageUploadJobRequest> | ||
| { | ||
| private List<JobResult> uploadLogs = new LinkedList<>(); |
There was a problem hiding this comment.
From what I understand, you use this in order to manually save some markers that you later query and display a custom message.
You can do the following instead:
- Have a custom marker (or more) defined. i.e. https://github.com/xwiki-contrib/confluence/blob/master/confluence-xml/src/main/java/org/xwiki/contrib/confluence/filter/internal/ConfluenceFilter.java#L53
- Use the market whenever you need it. i.e.https://github.com/xwiki-contrib/confluence/blob/master/confluence-xml/src/main/java/org/xwiki/contrib/confluence/filter/internal/input/ConfluenceInputFilterStream.java#L1411-L1412
- When the job is done, query the status logs for the markers you used i.e. https://github.com/xwikisas/application-confluence-migrator-pro/blob/main/application-confluence-migrator-pro-default/src/main/java/com/xwiki/confluencepro/internal/DefaultConfluenceMigrationManager.java#L328
application-admintools-api/src/main/java/com/xwiki/admintools/rest/AdminToolsResource.java
Outdated
Show resolved
Hide resolved
...ls-default/src/main/java/com/xwiki/admintools/internal/uploadJob/UploadJobFileProcessor.java
Outdated
Show resolved
Hide resolved
...ls-default/src/main/java/com/xwiki/admintools/internal/uploadJob/UploadJobFileProcessor.java
Outdated
Show resolved
Hide resolved
...ls-default/src/main/java/com/xwiki/admintools/internal/uploadJob/UploadJobFileProcessor.java
Show resolved
Hide resolved
...efault/src/test/java/com/xwiki/admintools/internal/uploadJob/UploadJobFileProcessorTest.java
Outdated
Show resolved
Hide resolved
application-admintools-ui/src/main/resources/AdminTools/Code/PackageUploadSheet.xml
Show resolved
Hide resolved
* moved save logic from UploadJob to UploadJobFileProcessor * created a method to save the backups in a special backup folder inside XWiki permanent directory * removed the batchSave function * adapted tests * modified and added comments * added translations * added more job logs * code refactoring
Created new endpoints for the package upload operation and refactored the healthCheckJob code to be usable by multiple job.
The import package page:
The import package result:
The modification for file section:
