If we don't involve migration client to handle this, AFAIU we have below
approaches.

1. If they don't have customizations:

   - Option 1:  Copy everything from old synapse config to new synapse
   config. Later replace default sequences, apis of ST and tenants from the
   latest resources.
   - Option 2:  Provide an instructions to avoid copying these sequences
   from old pack to new pack, which will remain the latest sequences. Note
   that have ~10 sequences. This needs to be taken care for each tenant as
   well.


2. If there are customizations: Apply the customizations to default latest
sequences and replace in ST and tenant spaces.

Thanks,
Lakmali



On 13 January 2016 at 18:08, Lakmali Baminiwatta <[email protected]> wrote:

> According to the current instructions, latest sequences get replaced by
> the old sequences. So what I am suggesting is that we can assume that it's
> the responsibility of the person who does the migration to add the
> customizations to latest default sequences which reside in
> repository/resources/apim-synapse-config and then migration client will
> blindly replace old sequences with those.
>
> On 13 January 2016 at 17:56, Nuwan Dias <[email protected]> wrote:
>
>>
>>
>> On Wed, Jan 13, 2016 at 5:51 PM, Uvindra Dias Jayasinha <[email protected]
>> > 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 <[email protected]> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jan 13, 2016 at 3:30 PM, Lakmali Baminiwatta <[email protected]>
>>>> 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 : [email protected]
>>>> Phone : +94 777 775 729
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Uvindra
>>>
>>> Mobile: 777733962
>>>
>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Technical Lead - WSO2, Inc. http://wso2.com
>> email : [email protected]
>> Phone : +94 777 775 729
>>
>
>
>
> --
> Lakmali Baminiwatta
> Senior Software Engineer
> WSO2, Inc.: http://wso2.com
> lean.enterprise.middleware
> mobile:  +94 71 2335936
> blog : lakmali.com
>
>


-- 
Lakmali Baminiwatta
Senior Software Engineer
WSO2, Inc.: http://wso2.com
lean.enterprise.middleware
mobile:  +94 71 2335936
blog : lakmali.com
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to