Hi, Thank you for the suggestions. We have updated the code as per the suggestions. [1] There was an error in trying to assign property values directly to a config class. Thus we have used the approach to set system properties.[2] (line 164)
We highly appreciate your suggestions on the approach taken. [1]. https://github.com/nishadi/product-private-paas/tree/master/tools/migration/ppaas-artifact-converter [2]. https://github.com/nishadi/product-private-paas/blob/master/tools/migration/ppaas-artifact-converter/src/main/java/org/wso2/ppaas/tools/artifactmigration/ConversionTool.java Thank you On Mon, Dec 21, 2015 at 1:49 PM, Malmee Weerasinghe <mal...@wso2.com> wrote: > Hi All, > This is the component architecture diagram of PPaaS Artifact Migration > Tool. > @ Chamila : Thank you for the suggestions and we will improve the tool as > mentioned. > > > > We highly appreciate your suggestions on this model. > Thank you. > > On Fri, Dec 18, 2015 at 1:09 AM, Chamila De Alwis <chami...@wso2.com> > wrote: > >> 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 >> >> > > > -- > Malmee Weerasinghe > WSO2 Intern > mobile : (+94)* 71 7601905* | email : <dehan.vith...@aiesec.net> > mal...@wso2.com > -- Nishadi Kirielle *Software Engineering Intern* Mobile : +94 (0) 714722148 nish...@wso2.com
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
