Hi,

The above scenario is implemented. Please verify the PR[1]

[1]  https://github.com/wso2/carbon-mediation/pull/160

On Tue, Apr 28, 2015 at 2:30 PM, Priyadarssini Kishokumar <
[email protected]> wrote:

> Hi,
>
> According to the discussion, we'll drop persisting artifacts to CApp.
> We are planning ti implement
>     1. Indicating the artifacts deploy from CApp in UI
>     2. Enabling editing artifacts, but not saving into the deployment
> directory, instead saving into the temp location.
>     3. Identifying the artifacts being edited through management console &
> showing that detail in UI.
>     4. Avoiding to deploy artifacts into the default location while saving
> through main source view.(config admin)
>
> Thanks
>
>
> On Tue, Apr 28, 2015 at 1:25 PM, Isuru Udana <[email protected]> wrote:
>
>> Hi Kishanthan/Manoj,
>>
>> We agree with your points. We'll drop the task of persisting artifacts
>> back to CApp and will do only the task of disabling editing capability from
>> Mgt console for artifacts coming from a CApp .
>>
>> Thanks.
>>
>> On Tue, Apr 28, 2015 at 12:47 PM, Kishanthan Thangarajah <
>> [email protected]> wrote:
>>
>>>
>>>
>>> On Mon, Apr 27, 2015 at 11:38 PM, Isuru Udana <[email protected]> wrote:
>>>
>>>> Hi Kishanthan,
>>>>
>>>> On Mon, Apr 27, 2015 at 11:05 PM, Kishanthan Thangarajah <
>>>> [email protected]> wrote:
>>>>
>>>>> So for #3, are we going to support mgt console level changes for
>>>>> artifacts that comes from CApp's ? What are the user requirements and do 
>>>>> we
>>>>> actually need this?
>>>>>
>>>> I thought we decided to remove the editing functionality for artifacts
>>>>> that comes from CApps in mgt console level.
>>>>>
>>>> We are having lot of issue with users accidentally editing artifacts
>>>> coming from CApps in mgt console.
>>>> As the first thing we can disable the editing option.
>>>> However sometimes users need to do quick changes in artifacts using
>>>> MgtConsole for testing purposes etc.. So if we disable editing
>>>> functionality we won't be able to satisfy that.
>>>> So we decided to see the possibility to persisting modifications back
>>>> the CApp.
>>>>
>>>
>>> But if we think from the platform point of view, we do not support the
>>> above for all the artifacts that comes from various products (Eg : DSS,
>>> Registry-Artifacts, etc). Also the above approach also has some
>>> issues/drawbacks. If something goes wrong during saving back to the CApp,
>>> the complete CApp may become faulty and all artifacts from the CApp may get
>>> removed.
>>>
>>> IMHO, we should avoid this and allow modification only from Dev-Studio.
>>>
>>>
>>>
>>>>
>>>>> On Mon, Apr 27, 2015 at 7:15 PM, Priyadarssini Kishokumar <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I'm implementing $Subject with related redmine[1]
>>>>>>
>>>>>> The main tasks should be
>>>>>> 1. Identifying the artifacts deployed with CAR
>>>>>> 2. Changes done through the management console for CAR artifacts
>>>>>> should not be saved in default deployment location
>>>>>> 3. Persisting the changes into the CAR file.
>>>>>>
>>>>>> Currently I'm identifying the artifacts coming from CAR and set the
>>>>>> details in the synapse level. By this way requirements 1 & 2 can be 
>>>>>> solved.
>>>>>> To persisting into CAR file, we need to get the CAPP name in the synapse
>>>>>> level. Currently I'm doing by modify the "DeploymentFileData" in the 
>>>>>> axis2.
>>>>>> In carbon application deployment "SynapseAppDeployer" class passing the
>>>>>> DeploymentFileData to synapse. This is the only place the deployed file
>>>>>> details are passing to synapse. To avoid axis2 level changes, we need to
>>>>>> come up with  a way to send the CAPP file details to synapse. Please 
>>>>>> advise
>>>>>> a better way to handle this.
>>>>>>
>>>>>>
>>>>>> [1] https://redmine.wso2.com/issues/3837
>>>>>>
>>>>>> --
>>>>>> Priya Kishok
>>>>>> Software Engineer
>>>>>> WSO2, Inc : http://wso2.com
>>>>>> Mob : +94774457404
>>>>>>
>>>>>> _______________________________________________
>>>>>> Dev mailing list
>>>>>> [email protected]
>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Kishanthan Thangarajah*
>>>>> Associate Technical Lead,
>>>>> Platform Technologies Team,
>>>>> WSO2, Inc.
>>>>> lean.enterprise.middleware
>>>>>
>>>>> Mobile - +94773426635
>>>>> Blog - *http://kishanthan.wordpress.com
>>>>> <http://kishanthan.wordpress.com>*
>>>>> Twitter - *http://twitter.com/kishanthan
>>>>> <http://twitter.com/kishanthan>*
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *Isuru Udana*
>>>> Associate Technical Lead
>>>> WSO2 Inc.; http://wso2.com
>>>> email: [email protected] cell: +94 77 3791887
>>>> blog: http://mytecheye.blogspot.com/
>>>>
>>>
>>>
>>>
>>> --
>>> *Kishanthan Thangarajah*
>>> Associate Technical Lead,
>>> Platform Technologies Team,
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>>
>>> Mobile - +94773426635
>>> Blog - *http://kishanthan.wordpress.com
>>> <http://kishanthan.wordpress.com>*
>>> Twitter - *http://twitter.com/kishanthan
>>> <http://twitter.com/kishanthan>*
>>>
>>
>>
>>
>> --
>> *Isuru Udana*
>> Associate Technical Lead
>> WSO2 Inc.; http://wso2.com
>> email: [email protected] cell: +94 77 3791887
>> blog: http://mytecheye.blogspot.com/
>>
>
>
>
> --
> Priya Kishok
> Software Engineer
> WSO2, Inc : http://wso2.com
> Mob : +94774457404
>



-- 
Priya Kishok
Software Engineer
WSO2, Inc : http://wso2.com
Mob : +94774457404
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to