Hi Malmee, Great work on the migration tool. AFAIU this is as far as we can go to ease the migration process for a Stratos user.
Some improvements that can be implemented, IMO, are, 1. Rename bin/run.sh to bin/stratos.sh to conform with the existing pattern where each separate Stratos component is started with a script named stratos.sh 2. If the path of the config file (currently config.properties) can also be an input value like the log4j config file, it might be easy to reuse the same tool with several config files, pointing to several Stratos installations at the same time. 3. Since configuration is a global state throughout a running instance, IMO it can be included as static final values in a static Config class. This might prove useful than the system property approach for several reasons, one being that after loading the config, it wouldn't be accidentally changed. 4. IMO the singleton implementations can be static classes (Transformation and ConversionTool). They don't seem to have any state. 5. Apache Commons library seems to provide some functions in a safer manner for some of the implemented methods like configuration loading[1] and file writing [2]. 6. From a superficial look it seems the fetch methods on OldArtifactLoader can be refactored in to a single method. Please look in to this possibility. 7. If the existing RestClient implementation is going to be maintained, IMO it would be a better design to let the configuration decide whether to skip host and cert verification, as discussed in the code review. 8. Move Constants to the root folder, since it's been called by other classes as well. 9. The next step can be to convert the Constants code file to a configuration file (XML/YAML) for configurable options like the endpoints, default values and cert path can be configured and the tool can be run against any future versions as well. However AFAIU, that is out of scope for the initial implementation. [1] - http://fahdshariff.blogspot.com/2013/04/adding-java-system-properties-from.html [2] - http://www.avajava.com/tutorials/lessons/how-do-i-write-a-string-to-a-file-using-commons-io.html Regards, Chamila de Alwis Committer and PMC Member - Apache Stratos Software Engineer | WSO2 | +94772207163 Blog: code.chamiladealwis.com On Wed, Dec 16, 2015 at 10:07 AM, Malmee Weerasinghe <mal...@wso2.com> wrote: > Hi Imesh, > > We will include a component architecture diagram of the PPaaS Artifact > Migration Tool. > > Thanks. > > On Tue, Dec 15, 2015 at 10:53 PM, Imesh Gunaratne <im...@wso2.com> wrote: > >> Hi Malmee, >> >> It would be better if you can draw a component architecture diagram to >> illustrate how this tool works. >> >> This might help us to understand how much load it can handle if the >> existing Private PaaS 4.0.0 environment has considerable amount of >> artifacts and subscriptions and how those can be processed efficiently. >> >> Thanks >> >> On Tue, Dec 15, 2015 at 10:39 PM, Malmee Weerasinghe <mal...@wso2.com> >> wrote: >> >>> Hi All, >>> We are developing a tool to convert PPaaS 4.0.0 artifact JSON files to >>> PPaaS 4.1.x. [1] >>> >>> There are changes in the artifacts deployment process in PPaaS 4.0.0 >>> compared to 4.1.0. So this tool is developed for those who need to migrate >>> from PPaaS 4.0.0 to 4.1.0. >>> >>> We take the artifacts JSONs of PPaaS 4.0.0 through REST API endpoints, >>> convert them using the bean classes of PPaaS 4.0.0 and 4.1.0 which are >>> accessed via a dependency and generate output artifacts to to be compatible >>> with PPaaS 4.1.x. In this process, we use default values for the additional >>> artifacts. >>> >>> These are the conversions we have implemented already. >>> - auto scale policy artifacts >>> - network partition list artifacts >>> - deployment policy artifacts >>> - cartridge artifacts >>> - application artifacts >>> - application sign ups - convert the cartridge subscription artifacts >>> JSONs output from Subscription Manager [2] >>> - domain mappings >>> >>> Would appreciate it if you could give your suggestions and comments on >>> this. >>> [1] >>> https://github.com/nishadi/product-private-paas/tree/master/tools/migration/ppaas-artifact-converter >>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fnishadi%2Fproduct-private-paas%2Ftree%2Fmaster%2Ftools%2Fmigration%2Fppaas-artifact-converter&sa=D&sntz=1&usg=AFQjCNE2Dyg5DdkTZPMJ0sAUvRsl2Gd3Sw> >>> [2] >>> https://github.com/wso2/product-private-paas/tree/master/tools/migration/subscription-manager/4.0.0 >>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fwso2%2Fproduct-private-paas%2Ftree%2Fmaster%2Ftools%2Fmigration%2Fsubscription-manager%2F4.0.0&sa=D&sntz=1&usg=AFQjCNE1lGmU7j6H3n40U6uIkNLVQYO5nQ> >>> >>> -- >>> Malmee Weerasinghe >>> WSO2 Intern >>> mobile : (+94)* 71 7601905* | email : <dehan.vith...@aiesec.net> >>> mal...@wso2.com >>> >> >> >> >> -- >> *Imesh Gunaratne* >> Senior Technical Lead >> WSO2 Inc: http://wso2.com >> T: +94 11 214 5345 M: +94 77 374 2057 >> W: http://imesh.gunaratne.org >> Lean . Enterprise . Middleware >> >> > > > -- > Malmee Weerasinghe > WSO2 Intern > mobile : (+94)* 71 7601905* | email : <dehan.vith...@aiesec.net> > mal...@wso2.com > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
