[Registry-dev] Resource lifecycle handling

[Deepal Jayasinghe]

Hi all,

Considering all the stuff we discussed in the thread , following is the 
plan for doing lifecycle handling.

- We defined a set of lifecycle  phases in the registry.xml (user also 
can change that add remove etc.. )with "name" , "order" and "LifecycleImpl"
   <lifecycle name="development" order="1" class="org.foo.MyLifecycleImpl"/>
  Here the name indicates the name of the phase  , while order indicates 
where to run the lifecycle , or if we have multiple phases then  order 
between those phase (which one to run first , second and so on) . And 
class indicate the corresponding lifecycle handling class.
- Any given resource can assigned one or more (or all) the phases in the 
lifecycle phases , which can be done using registry API
- Then at the runtime we can do the transition when do the transition  
it will check the order of phases.
-  Depending on the phase right lifecycle class will be invoked , for 
example if we change the state from "development" to "qa" then the 
lifecycle corresponding to the development  will be invoked. So at that 
time it is upto the LifeCycle class to do the validation and other 
processing.


Required changes
 - Introduce an abstract class called Lifecycle
 - New database table to store resource to lifecycle mapping
 - Keep the current state in the resource table
 - New APIs to the registry API to do the lifecycle handling


Thank you,
Deepal

>
> Please see my comments below;
>>
>>
>> Deepal Jayasinghe wrote:
>>>> So in *some* cases, we'll want to have particular directories in 
>>>> the Registry for particular states - for instance it definitely 
>>>> seems appropriate for some users to have "/qa/"  and "/production/" 
>>>> or "/tested/" and "/deployed/".  When something has been approved 
>>>> after testing, actually copying to somewhere like "/deployed/" 
>>>> seems good, since the production system is probably running 
>>>> pointing it's configuration at the "http://registry/deployed/" 
>>>> URL.  But there are other transitions (for example "ready for 
>>>> review -> reviewed" which might not warrant a copy, just a state 
>>>> change.
>> >
>>> Well I can not completely agree with "ready for review" and 
>>> "reviewed" transitions. Because once you review you might do some 
>>> changes. So it will not just state changes , I do agree we can find 
>>> many instance where when we do such transitions changes with no 
>>> content changes.
>>
>> I was thinking that changes could occur while the resource was in the 
>> "ready for review" state (you could also think of that as "in 
>> review") - it might go through several versions before passing 
>> review, but once reviewed there still might not be an explicit copy 
>> to a new path.  So it's not changes to content that I'm calling 
>> "copies", it's changes to the path.  In any case, I'm glad we agree 
>> about the possibility of state changes where nothing else changes.
> I agree with you in this , but for easy of development point of view 
> and version point of view I think if we make a deep copy of the 
> resource when state changes will be very useful.
>>
>>>
>>
>> Hm, well the same point applies at the top level doesn't it? :)  
> Well not really , or we can enforce user not to do that.
>> This is exactly why I hold the opinion that we shouldn't bake in any 
>> notion of particular directory structures except as part of 
>> particular lifecycles.  When a given user decides to install a given 
>> lifecycle, they are making a choice (if that lifecycle mandates 
>> control of particular parts of the path) to restrict the use of some 
>> paths in very particular ways.  Which particular paths are used are 
>> up to the lifecycle - and in fact might even be configurable....
>>
>> MyLifecycle {
>>   void transition(RequestContext rc, String action) {
>>     ...
>>     if ("deploy".equals(action)) {
>>       // Get the deploy path property
>>       String deployPath = resource.getProperty("deployPath");
>>
>>       // Default under "/deployed/" if not overridden
>>       if (deployPath == null) {
>>         deployPath = "/deployed/" + calcPath(resource);
>>       }
>>
>>       registry.put(deployPath + name, resource);
>>     }
>>   }
>> }
>>
>> This would allow me to use the same lifecycle in different places in 
>> my hierarchy, with Handlers which automatically set the "deployPath" 
>> property correctly for the different places.  For instance every 
>> resource under "/myDept/services" could use 
>> "/myDept/services/deployed/" as the deploy path (with the 
>> understanding that this reserves that path), and other departments 
>> might use the top level default.
> Sound good.
>>
>>>> So I'm envisioning something like this:
>>>>
>>>> Each resource can be on potentially multiple lifecycles.  On the 
>>>> Java side, we have something like:
>>> Its depend on the way you identifying the resource , if we going to 
>>> identify the resource be its path then resource can have only one 
>>> state at any given time.
>>
>> Not in the model I suggest.  Since each lifecycle can potentially use 
>> a different property or properties to represent its "state", a given 
>> resource can be in many states at one time.  
> Will that be a practical use case , I mean one resource in a number of 
> lifecycle states.
>
> -Deepal
>
>
> _______________________________________________
> Registry-dev mailing list
> Registry-dev at wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>