Hi,
> 1) When someone deploy a car, we directly deploy artifacts in the carbon >> by calling deployers without copying them to file system >> > > Correct! > >> 2) Either we should not let users edit artifacts come via car, or >> update the underline car file when the update is done. >> > > I'm strongly -1 for involving Carbon server for manipulating CAR files in > the runtime since IMO server is trying to do something out side of its > scope and it could lead us to unnecessary complexities in terms of > persistence, application governance,etc. > > If a car file is required o be updated, it is the task of the > developer/Dev ops person to package it using Dev Studio or Maven and > redeploy the new CAR file. > > We have already decided in a previous meeting we do not let users to > manipulate artifacts deployed via CAR. For example delete should be > disabled for artifacts deployed via CAR. > > These UI Level chanes has to be done for Carbon 4,2.0. > >> >> To do this, each artifact has to keep track where it came from (which >> car). >> >> How much of these do we have? I will schedule an review to discuss this. >> > > We already have admin services to do this. Application Admin is performing > it. > > This admin service is used to populate the C-App dashboard. So there is > nothing to implement in terms of tracking the C-App artifacts source. > > Only missing features at this point is the ability to limit/disable the Ui > for certain operations on the artifacts deployed via C-Apps. > > For this scenario I think we can show some information message that artifact cannot be delete/edit mentioning the service is deployed by CApp. Will that be ok. Thanks, Manoj
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
