[Registry-dev] Resource lifecycle handling
Paul Fremantle
paul at wso2.com
Tue Mar 11 03:01:52 PDT 2008
Plus also we need a default lifecycle impl that does nothing (just
accepts the change).
How do we manage security? How do I configure who can change lifecycles?
Can we set properties onto Lifecycle handlers? So in other words can I
have a pre-defined lifecycle handler that I parameterize with config
properties in the registry.xml?
Finally is there any way we can script the lifecycle handling? Maybe
have a lifecycle handler that calls out to BSF, and I configure it with
a simple javascript to do some checking when it gets called. The script
would need access to the Registry.
Paul
Deepal Jayasinghe wrote:
> 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
>>
>
>
>
> _______________________________________________
> Registry-dev mailing list
> Registry-dev at wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
>
--
Paul Fremantle
Co-Founder and VP of Technical Sales, WSO2
OASIS WS-RX TC Co-chair
Office: +1 646 290 8050
Cell: +44 798 447 4618
blog: http://pzf.fremantle.org
paul at wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
More information about the Registry-dev
mailing list