Ya this is fine but it has a real impact on complicating the migration. This issue has been there with migrating previous releases as well. We need to put more thought into reducing migration complexity when we add new features, more complications means more issues to deal with and lots of time consumed.
On 13 January 2016 at 07:47, Nuwan Dias <nuw...@wso2.com> wrote: > > > On Wed, Jan 13, 2016 at 6:07 PM, Uvindra Dias Jayasinha <uvin...@wso2.com> > wrote: > >> Ok if we allow these to be extended then we should not be adding our >> logic from the product here, but seems that we have made improvements >> within the extensible part. >> > > They are being modified for extending the extension support :). Ex: We > have the ability to change the message type of an error response. So we > allow users to modify a property on the sequence to do that. In the next > release we figure out that we can also change the status code using the > same mechanism. So we add another property on the same sequence so users > can change the status code as well using extensions. Therefore there are > valid cases for modifying these sequences during feature releases. > >> >> We should add our changes to a default sequence that is used unless it >> has been overridden by a custom sequence that has been defined for this >> purpose by the user. That way we can upgrade the default sequences and >> users who haven't overridden it get to use it. >> >> But seems that the way thing are now we can achieve the same affect by >> asking users to copy the sequences over if they have made any >> customizations. Either way if they have done customizations they need to >> copy them. So we can simply ask them to do that and not try to migrate >> automatically. >> >> >> :) Agree with Lakmali, who replied on the other thread, user should only >> copy the sequences if they have customized them. No need to do anything >> with the migration client >> >> On 13 January 2016 at 07:26, Nuwan Dias <nuw...@wso2.com> wrote: >> >>> >>> >>> On Wed, Jan 13, 2016 at 5:51 PM, Uvindra Dias Jayasinha < >>> uvin...@wso2.com> wrote: >>> >>>> I think the only way is to complicate the migration instructions, >>>> >>>> If user has customized any sequences they need to copy them over >>>> manually to latest pack and we will use those.(Discalimer to user: You >>>> maybe missing out on the latest changes shipped with the default sequences >>>> in the latest pack) >>>> >>>> Migration client doesn't need to do anything then, its not in a >>>> position to make a proper decision anyway. >>>> >>>> But its pretty clear this is a hole in our extensibility. We dont >>>> provide official extension points to make changes in the areas that these >>>> specific sequences address, forcing uses to change the default sequences >>>> that are shipped which makes upgrading a pain. We should address this in a >>>> future release >>>> >>> >>> The sole purpose of these sequences are for extensibility. Ex: To change >>> the message type of a auth failure error. So its understandable that people >>> edit them. >>> >>>> >>>> On 13 January 2016 at 05:23, Nuwan Dias <nuw...@wso2.com> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Jan 13, 2016 at 3:30 PM, Lakmali Baminiwatta <lakm...@wso2.com >>>>> > wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> In our migration guide, currently what we instruct is to copy & >>>>>> replace repository/deployment/server/synapse-config/default directory and >>>>>> repository/tenants from previous APIM version to new APIM version. Here >>>>>> we >>>>>> mention to skip replacing _TokenAPI_.xml, _RevokeAPI_.xml and >>>>>> _AuthorizeAPI_.xml files by which latest files of those will be remained. >>>>>> >>>>>> But with this approach, it will replace other system sequences with >>>>>> old ones (ex: _auth_failure_handler_.xml, _cors_request_handler_.xml, >>>>>> main.xml, fault.xml, etc). So some of the fixes went to those will be >>>>>> missed out. We have two ways to include those changes to the new version. >>>>>> >>>>>> 1. Include the missing changes through migration client. >>>>>> 2. Get the latest sequences from the new version pack and replace >>>>>> corresponded sequences of each tenant through migration client. >>>>>> >>>>>> Some of the changes done to these sequences are minor changes like >>>>>> adding a drop mediator after send, changing a regex value, removing a >>>>>> property etc. Since some of the users may have already done own >>>>>> customizations to these sequences, trying to add changes to existing ones >>>>>> may lead to complications. >>>>>> So I think it would be better to ask the users to add their changes >>>>>> (if there are any) to default sequences in the >>>>>> pack(repository/resources/apim-synapse-config) prior running the >>>>>> migration >>>>>> client and then through the client we can replace existing ones. WDYT? >>>>>> >>>>> >>>>> This part is tricky. Since we do not know the amount nor nature of >>>>> customisations they may have done, can we guarantee the migration client >>>>> will do its job properly since it doesn't know the content/state of the >>>>> file before it starts to execute on it? >>>>> >>>>> >>>>> >>>>>> Thanks, >>>>>> Lakmali >>>>>> >>>>>> -- >>>>>> Lakmali Baminiwatta >>>>>> Senior Software Engineer >>>>>> WSO2, Inc.: http://wso2.com >>>>>> lean.enterprise.middleware >>>>>> mobile: +94 71 2335936 >>>>>> blog : lakmali.com >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Nuwan Dias >>>>> >>>>> Technical Lead - WSO2, Inc. http://wso2.com >>>>> email : nuw...@wso2.com >>>>> Phone : +94 777 775 729 >>>>> >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Uvindra >>>> >>>> Mobile: 777733962 >>>> >>> >>> >>> >>> -- >>> Nuwan Dias >>> >>> Technical Lead - WSO2, Inc. http://wso2.com >>> email : nuw...@wso2.com >>> Phone : +94 777 775 729 >>> >> >> >> >> -- >> Regards, >> Uvindra >> >> Mobile: 777733962 >> > > > > -- > Nuwan Dias > > Technical Lead - WSO2, Inc. http://wso2.com > email : nuw...@wso2.com > Phone : +94 777 775 729 > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev