Hi all,
I found [1] which has few recommended lines of code for the java as well.
When we increase the no of lines in a class/method, then we will also
increase the responsibility [2] of that class/method. Can we propose a
convention about line of codes in a method/class as well?
[1] http://www.a
Although snake_case improves readability, camelCase is actively enforced
with style guidelines for Java. So it would be best to keep using camelCase
to maintain a consistent code base.
Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
On Mon, Oct 6
Hi,
I currently have these files[1] versioned to be available whenever I deploy
a new installation.
AFAIK JSON file validation schema are enabled now, so can't we make use of
those components instead of using an end to end test with the REST api's?
[1] - https://github.com/chamilad/stratos-poli
I have fixed this in master and container-autoscaling branches
On Mon, Oct 6, 2014 at 11:26 AM, Sajith Kariyawasam wrote:
> yes, we fixed this in STRATOS-802, but seems in some commit it has been
> reverted in master branch.
>
> https://github.com/apache/stratos/blame/master/features/cloud-contr
[
https://issues.apache.org/jira/browse/STRATOS-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sajith Kariyawasam updated STRATOS-802:
---
Fix Version/s: (was: 4.1.0 M1)
4.1.0 M2
> Partition deployment
[
https://issues.apache.org/jira/browse/STRATOS-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sajith Kariyawasam resolved STRATOS-802.
Resolution: Fixed
> Partition deployment fails in EC2
> ---
[
https://issues.apache.org/jira/browse/STRATOS-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14160040#comment-14160040
]
Sajith Kariyawasam commented on STRATOS-802:
Fixed in following commits
mast
Hi Udara,
Yes this was build from master branch.
Nirmal,
I'm deploying the newly build artifacts now. I will reply with the results.
Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
On Mon, Oct 6, 2014 at 7:53 AM, Udara Liyanage wrote:
> Hi C
Udara Liyanage created STRATOS-871:
--
Summary: Ctr + C does not stop the server if broker is down
Key: STRATOS-871
URL: https://issues.apache.org/jira/browse/STRATOS-871
Project: Stratos
Issu
Hi all,
I have implemented the dependency tree as mentioned in my mail earlier. It
will return the immediate children for the start able dependencies.
FYI: a composite application has postgresGroup, php, mysqlGroup, app
server and esb as it's immediate children and their start up order is as
men
[
https://issues.apache.org/jira/browse/STRATOS-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dakshika Jayathilaka reopened STRATOS-802:
--
seems its broken in latest one. need to change
features/cloud-controller/org.apac
yes, we fixed this in STRATOS-802, but seems in some commit it has been
reverted in master branch.
https://github.com/apache/stratos/blame/master/features/cloud-controller/org.apache.stratos.cloud.controller.feature/pom.xml
will have a look
On Mon, Oct 6, 2014 at 12:25 AM, Akila Ravihansa Perera
Ya, Imesh.. I was worrying about breaking existing clients (including our
own UI /CLI) . Yes, I also felt the same after thinking a bit more and
initiated a thread here: Versioning Stratos REST API
On Mon, Oct 6, 2014 at 10:45 AM, Imesh Gunaratne wrote:
> Hi Nirmal,
>
> I think that's the appro
Great! Thanks for the clarification Isuru!
Yes I agree, I think what we can do is, identify the sub trees that will
not break the consistency of the data structure and manage locks at those
sub tree level.
Thanks
On Sun, Oct 5, 2014 at 8:07 PM, Isuru Haththotuwa wrote:
> Hi Lahiru and Imesh,
>
I think it is better to use camelCase since we are using java as our
underline language
On Mon, Oct 6, 2014 at 10:05 AM, Gayan Gunarathne wrote:
> I think camelcase is better as we are using java for developed the REST
> API.I guess lot of APIs use this as they following naming conventions of
>
Hi Nirmal,
I think that's the approach most of the well known APIs take [1, [2], [3]:
- Document APIs by version
- If version is not given in the context request is redirected to the
latest version
- If version is specified relevant API is invoked
- Deprecate and remove old API versions according
Hi,
In addition to that we have to specify in cartridge json which metadata it
expose . For instance MySQL cartridge should mention that it exposes host,
username,password so someone looking at MySQL cartridge know what details
it exposes to metadata service.
exportingProperties{
[
"H
We already have a set of scripts under the following location
stratos/tools/rest-api-client added by Imesh I think - Sorry for not
looking for this first
So we could probably extend this set to cover all scenarios and first run
this in non-build mode and then take it to build mode ?
IF we add t
On Mon, Oct 6, 2014 at 7:51 AM, Udara Liyanage wrote:
> +1 for api/version
>
>
>
> Touched, not typed. Erroneous words are a feature, not a typo.
> On Oct 5, 2014 11:11 PM, "Akila Ravihansa Perera"
> wrote:
>
>> On Sun, Oct 5, 2014 at 10:22 PM, Nirmal Fernando
>> wrote:
>> > Exactly! That's how
Hi,
On Mon, Oct 6, 2014 at 10:06 AM, Shiroshica Kulatilake
wrote:
> Hi,
>
> So - what is the guarantee that when something changes the relevant JSON
> file will also be changed ?
>
Yes. This can be a problem. Because some of the configurations can be
different among the IaaS such as zone and r
On Mon, Oct 6, 2014 at 10:10 AM, Reka Thirunavukkarasu
wrote:
> Hi Udara,
>
> AFAIK, this is obsolete code segment as of what we are doing now..
>
> @Martin/IsuruH/Udara
> Shall we remove the code segment that we are not using from grouping
> branch? Since we are having sonar integrated, it would
Hi Udara,
AFAIK, this is obsolete code segment as of what we are doing now..
@Martin/IsuruH/Udara
Shall we remove the code segment that we are not using from grouping
branch? Since we are having sonar integrated, it would be good to execute
sonar in our grouping branch too. If we remove the unuse
FYI $Subject, to carry out auto-scaling feature implementation for
container scenario.
-- Forwarded message --
From:
Date: Mon, Oct 6, 2014 at 10:01 AM
Subject: Git Push Summary
To: comm...@stratos.apache.org
Repository: stratos
Updated Branches:
refs/heads/container-autoscal
Hi,
So - what is the guarantee that when something changes the relevant JSON
file will also be changed ?
I am totally +1 for having these files plus including them in documentation
- however - not sure whether we will tend to not update these again.
So - how about having this in some format whic
Hi Martin,
Noticed that key is hard coded in Topologybuilder.java for some reason or
may be some testing purpose. Should n't this be messConfigApp.getAlias().
If so, I can make the change and commit. Could someone confirm whether it
is done with purpose or not?
1. try {
2.
3.
I think camelcase is better as we are using java for developed the REST
API.I guess lot of APIs use this as they following naming conventions of
the underlying language they are using.Also there are some arguments that
snake-case will improve the readability , it may help when documentation
and sam
+1 for single release.
On Sun, Oct 5, 2014 at 9:47 PM, Isuru Perera wrote:
> Yes! That's better.
>
> On Fri, Oct 3, 2014 at 1:33 PM, Lakmal Warusawithana
> wrote:
>
>> Hi devs,
>>
>> Two dev teams are working on main two deferent feature sets which are,
>> Grouping support (4.2.0) and Docker,Ku
Hi Martin,
Sorry for the delay...Thanks for the re-sending it..I will go through it
and update soon..
Thanks,
Reka
On Mon, Oct 6, 2014 at 1:09 AM, Martin Eppel (meppel)
wrote:
> Resending it in case you missed it,
>
>
>
> Thanks
>
>
>
> Martin
>
>
>
> *From:* Martin Eppel (meppel)
> *Sent:* T
Hi,
Previously we have EC2 and OpenStack sample JSON files in tools directory.
But currently there are not available. We can categorize sample JSON files
with the Stratos release version. Some of the sample JSON files which I'm
using for testing can be found in [1].
[1] https://github.com/manulac
Hi all,
With the REST API re-factoring effort going on, do you think we need any
changes to the permission hierarchy proposed above?. This is already
integrated in M1 and if there are any changes, we can incorporate them in
M2.
Thanks,
On Fri, Sep 12, 2014 at 11:11 AM, Lasindu Charith wrote:
>
On Mon, Oct 6, 2014 at 8:00 AM, Nirmal Fernando
wrote:
> I've enabled only comments since I am publishing it to dev list:
> https://docs.google.com/spreadsheets/d/1VP9-0xY2Oj1H1sv5yf5goIT6TakpwrCt5Z8QW1oFVOc/edit?usp=sharing
>
Great will put in comments
Thank you,
Shiro
> On Mon, Oct 6, 2014
I've enabled only comments since I am publishing it to dev list:
https://docs.google.com/spreadsheets/d/1VP9-0xY2Oj1H1sv5yf5goIT6TakpwrCt5Z8QW1oFVOc/edit?usp=sharing
On Mon, Oct 6, 2014 at 7:33 AM, Nirmal Fernando
wrote:
> Sure, I hope, I'll be able to track who suggested what?
>
> On Mon, Oct 6
Hi Chamila,
Is this from master branch built products?
Touched, not typed. Erroneous words are a feature, not a typo.
+1 for api/version
Touched, not typed. Erroneous words are a feature, not a typo.
On Oct 5, 2014 11:11 PM, "Akila Ravihansa Perera"
wrote:
> On Sun, Oct 5, 2014 at 10:22 PM, Nirmal Fernando
> wrote:
> > Exactly! That's how most of the popular APIs are designed.
> >
> > On Sun, Oct 5, 2014 at
Hi Chamila,
On Mon, Oct 6, 2014 at 1:22 AM, Chamila De Alwis wrote:
> Hi,
>
> I'm getting the following error when trying to configure a cartridge
> definition. The build is from stratos/master built on 2/10/2014. I was able
> to deploy other policies and configurations successfully, so this is
+1 for the idea. Only basic samples are available in docs.
Shall we have a sample directory in root level where it is easy to find ,
users might not search for samples in tools directory.
Touched, not typed. Erroneous words are a feature, not a typo.
Hi,
Do you have image-id property defined in clouds controller.xml, if so
remove it and restart the server and try again.
Touched, not typed. Erroneous words are a feature, not a typo.
On Oct 6, 2014 12:06 AM, "Dakshika Jayathilaka" wrote:
> Hi,
>
> I'm testing new UI for 4.1.0 and I'm gettin
Hi,
I prefer sending 404 when there are no resources for a GET request. IMO
that's why 404 is meant to be.
Touched, not typed. Erroneous words are a feature, not a typo.
This is a CNF, so I don't think it's connected to multiple IaaSes.
On Mon, Oct 6, 2014 at 12:36 AM, Dakshika Jayathilaka
wrote:
> Thanks Akila, Already did clean thing before i run setup.sh
>
> Seems issue comes when i enable multiple iaas providers. AFAIK we can have
> multiple iaas providers..
+1 and we need to document this in developer guide :)
On Mon, Oct 6, 2014 at 2:17 AM, Dakshika Jayathilaka
wrote:
> Hi Devs,
>
> Most of the time we need to maintain separate set of sample JSON to test
> things. Also
> documentation won't up to date due to rapid changes happens on dev
> environm
Sure, I hope, I'll be able to track who suggested what?
On Mon, Oct 6, 2014 at 7:31 AM, Shiroshica Kulatilake
wrote:
> Hi Nirmal,
>
> Can you share this in the form of a sheet ?
> Then we can have a suggested column to have the diffs
>
> Thank you,
> Shiro
>
> On Mon, Oct 6, 2014 at 7:23 AM, Nir
Thanks guys for the pointers. I'll create Jiras for all of these.
On Mon, Oct 6, 2014 at 12:00 AM, Isuru Perera wrote:
> I also agree with all points.
>
> On Sun, Oct 5, 2014 at 11:09 PM, Akila Ravihansa Perera <
> raviha...@wso2.com> wrote:
>
>> Hi,
>>
>> +1 for all the suggested points.
>>
>>
Hi Nirmal,
Can you share this in the form of a sheet ?
Then we can have a suggested column to have the diffs
Thank you,
Shiro
On Mon, Oct 6, 2014 at 7:23 AM, Nirmal Fernando
wrote:
> Thanks Akila for going through and identifying collisions.
>
> On Sun, Oct 5, 2014 at 11:26 PM, Akila Ravihansa
Hi Dakshika,
On Sun, Oct 5, 2014 at 11:27 PM, Dakshika Jayathilaka
wrote:
> Hi,
>
> I think we need to think about return status code and content properly.
> current return values having different approaches on different end points.
>
Thanks for bringing this up. I agree, we should clean REST A
Thanks Akila for going through and identifying collisions.
On Sun, Oct 5, 2014 at 11:26 PM, Akila Ravihansa Perera
wrote:
> Hi Nirmal,
>
> Great work on re-factoring REST API!
>
> I think these request paths might cause collisions.
>
> 1. /cartridges/multiTenant, /cartridges/singleTenant,
> /car
+1
Great idea,
Thanks
Martin
From: Dakshika Jayathilaka [mailto:daksh...@wso2.com]
Sent: Sunday, October 05, 2014 1:48 PM
To: dev
Subject: Maintain list of sample json files
Hi Devs,
Most of the time we need to maintain separate set of sample JSON to test
things. Also
documentation won't up
On Mon, Oct 6, 2014 at 2:17 AM, Dakshika Jayathilaka
wrote:
> Shall we maintain sample JSON set inside tools folder. When any developer
> changing things they can easily update sample JSONs as a part of
> implementation process.
+1 on the idea.
Regards,
Chamila de Alwis
Software Engineer | WS
Hi Devs,
Most of the time we need to maintain separate set of sample JSON to test
things. Also
documentation won't up to date due to rapid changes happens on dev
environment.
Shall we maintain sample JSON set inside tools folder. When any developer
changing things they can easily update sample JS
Hi,
I'm getting the following error when trying to configure a cartridge
definition. The build is from stratos/master built on 2/10/2014. I was able
to deploy other policies and configurations successfully, so this is not an
issue relating to any of the service endpoints being down.
TID: [0] [STR
Resending it in case you missed it,
Thanks
Martin
From: Martin Eppel (meppel)
Sent: Thursday, October 02, 2014 6:29 PM
To: 'Reka Thirunavukkarasu'; dev
Cc: Lakmal Warusawithana; Shaheedur Haque (shahhaqu); Isuru Haththotuwa; Udara
Liyanage
Subject: RE: [Discuss][Grouping] Handling Group level s
Thanks Akila, Already did clean thing before i run setup.sh
Seems issue comes when i enable multiple iaas providers. AFAIK we can have
multiple iaas providers.. Am i correct?
*Dakshika Jayathilaka*
Software Engineer
WSO2, Inc.
lean.enterprise.middleware
0771100911
On Mon, Oct 6, 2014 at 12:25 AM
Hi Dakshika,
This issue was fixed by adding jsch.agentproxy.usocket-nc as a
dependency to CC feature.
Can you try again after taking a clean build by running "mvn clean install"?
Also I've faced an issue when running stratos-installer setup.sh
without running clean.sh first. Make sure you have r
Hi,
I'm testing new UI for 4.1.0 and I'm getting below error on partition
definition deployment. I build this pack today with master.
{"Error":{ "errorCode": " 400", "errorMessage": " Invalid Partition -
Partition [id=P1, description=Test, isPublic=true, provider=ec2,
partitionMin=0, partitionMax
I also agree with all points.
On Sun, Oct 5, 2014 at 11:09 PM, Akila Ravihansa Perera
wrote:
> Hi,
>
> +1 for all the suggested points.
>
> I would like to add few more to the list to be considered.
>
> 1. Provide useful error messages for back-end API exceptions.
>
> 2. Use of snake_case instea
Hi,
I think we need to think about return status code and content properly.
current return values having different approaches on different end points.
ex:
1. GET /partition empty state return *{"partition" : []}* and GET
/policy/deployment empty state return *null*
WDYT?
Regards,
*Dakshika J
Hi Nirmal,
Great work on re-factoring REST API!
I think these request paths might cause collisions.
1. /cartridges/multiTenant, /cartridges/singleTenant,
/cartridges/{cartridgeType}
2. /clusters/{cartridgeType}, /clusters/{subscriptionAlias},
/clusters/{clusterId}
I might be wrong...but just
On Sun, Oct 5, 2014 at 10:22 PM, Nirmal Fernando wrote:
> Exactly! That's how most of the popular APIs are designed.
>
> On Sun, Oct 5, 2014 at 10:13 PM, Dakshika Jayathilaka
> wrote:
>>
>> Hi,
>>
>> i think d best approach would be having api and version number on context.
>>
>> api/v1
+1
>>
Hi,
+1 for all the suggested points.
I would like to add few more to the list to be considered.
1. Provide useful error messages for back-end API exceptions.
2. Use of snake_case instead of camelCase in APIs. It is much more readable.
3. Support gzip compression.
4. Enable Cross-site Resource
Exactly! That's how most of the popular APIs are designed.
On Sun, Oct 5, 2014 at 10:13 PM, Dakshika Jayathilaka
wrote:
> Hi,
>
> i think d best approach would be having api and version number on context.
>
> api/v1
>
> Regards,
>
> *Dakshika Jayathilaka*
> Software Engineer
> WSO2, Inc.
> lean.
Hi,
i think d best approach would be having api and version number on context.
api/v1
Regards,
*Dakshika Jayathilaka*
Software Engineer
WSO2, Inc.
lean.enterprise.middleware
0771100911
On Sun, Oct 5, 2014 at 9:15 PM, Nirmal Fernando
wrote:
> Hi Devs,
>
> Currently the API root context is 'ad
Yes! That's better.
On Fri, Oct 3, 2014 at 1:33 PM, Lakmal Warusawithana
wrote:
> Hi devs,
>
> Two dev teams are working on main two deferent feature sets which are,
> Grouping support (4.2.0) and Docker,Kubernetes,CoreOS integration (4.1.0).
>
> Since both team delivered M1 developer previews,
All,
Let's discuss how we could do $subject properly. AFAIS currently we don't
have any versioning in our REST API, but we have consumers of our REST API.
1. We can make the default API version to be the latest version, i.e. v2.
So, if someone send a request to //cartridges , it would find
//v2/
Hi Devs,
Currently the API root context is 'admin'. Does that make any sense to have
'admin' instead of having 'api' ? What consequences it would bring if we
refactor the root context?
--
Best Regards,
Nirmal
Nirmal Fernando.
PPMC Member & Committer of Apache Stratos,
Senior Software Engineer,
+1 for refactoring, some paths does not adhere to REST best practices
On Sun, Oct 5, 2014 at 8:54 PM, Nirmal Fernando
wrote:
> Hi Guys,
>
> As discussed previously, I've been going through all the API operations
> exposed via Stratos REST API and identified following set of APIs need to
> be ref
Hi Guys,
As discussed previously, I've been going through all the API operations
exposed via Stratos REST API and identified following set of APIs need to
be refactored to have a RESTful design. While doing this, I've also
identified sub-APIs that we have provided (under Entity column) and I
sugge
Hi,
Thanks Isuru for the suggestion.
On Sun, Oct 5, 2014 at 1:41 PM, Gayan Gunarathne wrote:
> +1
> Yeah I think it should be a json array.
> IMO we can use mygroup1.mygroup1mysql1 sort of a naming for identify the
> dendencies as it improves the readability of the alias.WDYT?
>
> Thanks,
> Gay
Hi Lahiru and Imesh,
Thanks a lot for the input.
What I do here is locking only the relevant sub tree of the complete
Topology tree, as locking the whole tree is rather inefficient. For an
example, when a MemberActivated event is received, we have the cluster id
of the cluster that particular mem
On Fri, Oct 3, 2014 at 9:55 PM, Martin Eppel (meppel)
wrote:
> I checked in a fix yesterday,
>
Awesome! Thanks Martin.
>
>
> Thanks
>
>
>
> Martin
>
>
>
> *From:* isu...@wso2.com [mailto:isu...@wso2.com] *On Behalf Of *Isuru
> Haththotuwa
> *Sent:* Friday, October 03, 2014 2:30 AM
> *To:* dev
>
On Sun, Oct 5, 2014 at 11:50 AM, Rajkumar Rajaratnam
wrote:
> Hi,
>
> I have done the changes as in the previous mail.
>
> I am proposing one more changes to cluster monitors.
>
> Shall we use java executor services instead of thread sleep?
>
+1
>
> For example, we are sleeping the thread in clu
GitHub user R-Rajkumar opened a pull request:
https://github.com/apache/stratos/pull/79
code review changes to cluster monitors
* introducing abstract methods in abstract cluster monitor, handing over
topology/health stats events to relevant cluster monitor and handling them in
clu
Another way to version the APIs is to use the Accept header with the
default URL (means default URL should always be the latest). But this would
make are current API users to change their clients to set the Accept header
to the correct version.
On Sun, Oct 5, 2014 at 2:18 PM, Nirmal Fernando
wrot
Hi Imesh,
Since we didn't have a version in the context in 4.0, I think we can't
redirect requests without a version to the latest, isn't it? Yes, plan is
to introduce a version in the context and mark current APIs as deprecated.
I'll start a separate thread on new REST API design.
On Sat, Oct 4,
[
https://issues.apache.org/jira/browse/STRATOS-870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14159468#comment-14159468
]
Isuru Perera commented on STRATOS-870:
--
When implementing, think properly about the
+1
Yeah I think it should be a json array.
IMO we can use mygroup1.mygroup1mysql1 sort of a naming for identify the
dendencies as it improves the readability of the alias.WDYT?
Thanks,
Gayan
On Friday, October 3, 2014, Isuru Haththotuwa wrote:
> +1 for the general idea, can we come up with the
74 matches
Mail list logo
