Hi Samisa,
Sorry for late reply.
On Thu, Dec 19, 2013 at 10:46 AM, Samisa Abeysinghe sam...@wso2.com wrote:
On Wed, Dec 11, 2013 at 9:25 PM, Samisa Abeysinghe sam...@wso2.comwrote:
So, no staging right? If yes, then where do we roll back to in CI?
Yes, No staging, but we have the support
So if we deploy an app into production, v1, then it works, then we deploy
v2 into production and it does not work, how do we revert back to v1?
Thanks,
Samisa...
Samisa Abeysinghe
Vice President Training
WSO2 Inc.
http://wso2.com
On Thu, Dec 19, 2013 at 1:50 PM, Manjula Rathnayake
Hi Malaka,
SugarCRM does not provide direct operation for delete and update. Instead
you can user set_entry and be sure to set deleted = 1 in your parameter
array. This doesn't actually remove it from the database but will prevent it
from being returned by Sugar unless you have specifically asked
Hi Samisa,
Having application version v1 in production doesn't effect having v2 also
in production. since artifacts of V1 and V2 are two different artifacts (
e.g. myapp-v1.war, myapp-v2.war) that will end up in relevant run time (e.g
production app server). In that sense, demoting V2 also
Hi all,
Do we need to support v1.build1, v1.build2 like artifacts when we have a
version concept already such as v1, v2 ? It seems to me that, having
v1.build1, v1,build2 introduces another version concept based on build
version on top of v1(source version).
thank you.
On Thu, Dec 19, 2013 at
Hi Samisa,
Having a 'Staging' doesn't seem to solve the problem. let me explain the
work flow:
V1.build1 is deployed in Production - Devops demote v1.build1 to
'Staging' - Dev ops demote v1.build1 to Testing - QA demote v1.build1 to
Development -
Developer make changes (and make V1.build2)
The question is about promoting and demoting build2. For build1 if we
deploy and that fails, there is no such scenario of service continuation as
there was no service to start with.
Thanks,
Samisa...
Samisa Abeysinghe
Vice President Training
WSO2 Inc.
http://wso2.com
On Thu, Dec 19, 2013
Hi Prabath,
One more suggestion I wanted to tell and missed is, what if we have the
Identifier classes of each entity as a static nested class of the
corresponding entity? This way it will make the packaging more neat.
On Thu, Dec 19, 2013 at 1:26 PM, Prabath Siriwardena prab...@wso2.comwrote:
Hi Johann,
Why would we need to do that? If we do so we cannot inherit the
EntityIdentifier behavior isn't it? Therefore we need to change that in
every class if we come across any issues.
Can you please provide a sample why we need to add that as a inner class?
Regards,
Venura
On Thu, Dec
A nested class should exist only to serve its enclosing class... if the
purpose of it goes beyond that - then it should be a top level one. For
that reason, I did't want to have Identifier classes as nested classes...
Thanks regards,
-Prabath
On Thu, Dec 19, 2013 at 6:07 PM, Johann Nallathamby
Hi Prabath,
On Thu, Dec 19, 2013 at 7:56 PM, Prabath Siriwardena prab...@wso2.comwrote:
A nested class should exist only to serve its enclosing class... if the
purpose of it goes beyond that - then it should be a top level one. For
that reason, I did't want to have Identifier classes as
Yes.. you got a point - it only alters packaging - but, from design point
of view, it adds bit confusion - that's why I do not prefer that quite..
Thanks regards,
-Prabath
On Thu, Dec 19, 2013 at 8:06 PM, Johann Nallathamby joh...@wso2.com wrote:
Hi Prabath,
On Thu, Dec 19, 2013 at 7:56
I'm not quite sure whether we have already define the architectural
approach for ${Subject} in either way I have some inputs about
${Subject} from AS point of view.
If you go through Tomcat changelog[1] doc you can understand it's vital to
upgrade Tomcat version with AS releases when ever
13 matches
Mail list logo
