I have now done the following changes: - Added get applications resource to REST API - Added list-applications command to CLI - Removed CLI commands subscribe-cartridge, list-cartridge-subscriptions, unsubscribe-cartridge and deprecated command classes - Fixed coding convention issues in the CLI - Fixed a null pointer issues in CloudControllerUtil.toJavaUtilProperties() method - Updated info logs in ApplicationBuilder class in autoscaler
Thanks On Sat, Nov 8, 2014 at 7:48 PM, Rajkumar Rajaratnam <rajkum...@wso2.com> wrote: > Update: > > - Auto-scaling works fine for container scenario > - Faulty members are successfully terminated and new containers are > created successfully > > Thanks. > > On Sat, Nov 8, 2014 at 7:44 PM, Imesh Gunaratne <im...@apache.org> wrote: > >> My understanding is that we only need the domain classes converted to >> python. They may only contain list of properties. Therefore the generated >> code should be simple enough to validate. >> >> >> On Sat, Nov 8, 2014 at 7:10 PM, Chamila De Alwis <chami...@wso2.com> >> wrote: >> >>> Hi Imesh, >>> >>> Is it reliable to follow a code conversion tool? Given that this tool >>> doesn't guarantee working code, I'm not sure this would be a better option. >>> >>> *"The generated Python code is not guaranteed to run,"* >>> >>> >>> Regards, >>> Chamila de Alwis >>> Software Engineer | WSO2 | +94772207163 >>> Blog: code.chamiladealwis.com >>> >>> >>> >>> On Sat, Nov 8, 2014 at 1:50 PM, Imesh Gunaratne <im...@apache.org> >>> wrote: >>> >>>> I think we can use [1] to convert messaging component data model to >>>> python at the build time and the agent can refer that directly. WDYT? >>>> >>>> [1] https://github.com/natural/java2python >>>> On Nov 8, 2014 1:28 PM, "Chamila De Alwis" <chami...@wso2.com> wrote: >>>> >>>>> Hi Raj, >>>>> >>>>> On Sat, Nov 8, 2014 at 1:19 PM, Rajkumar Rajaratnam < >>>>> rajkum...@wso2.com> wrote: >>>>> >>>>>> Please double check the java agent code too. It works somehow. Don't >>>>>> know the reason :) >>>>> >>>>> >>>>> The Java agent makes use of the org.apache.stratos.messaging >>>>> component, so any changes done from a publisher's point of view is >>>>> reflected on a receiver's end. In the Python agent, the serialization and >>>>> the deserialization of the events published and received from the message >>>>> broker is written anew in Python. >>>>> >>>>> The problem rises here, when the changes made in the messaging >>>>> component needs to be reflected in the Python agent too. I think for the >>>>> time being whenever a change is done, it is better to assign the relevant >>>>> JIRA issue to the person responsible of the changes in Python cartridge >>>>> agent, which is me for now :). >>>>> >>>>> In the long run, a set of unit tests can manage the changing code >>>>> better. >>>>> >>>>> >>>>> Regards, >>>>> Chamila de Alwis >>>>> Software Engineer | WSO2 | +94772207163 >>>>> Blog: code.chamiladealwis.com >>>>> >>>>> >>>>> >>> >> >> >> -- >> Imesh Gunaratne >> >> Technical Lead, WSO2 >> Committer & PMC Member, Apache Stratos >> > > > > -- > Raj > -- Imesh Gunaratne Technical Lead, WSO2 Committer & PMC Member, Apache Stratos
