Wednesday, June 26, 2013

How to revert all the local changes in SVN

When working with SVN now and then you will need to revert changes that was done by you or by applying a patch. Recently i wanted to revert all the changes done locally and found a nice command that can get this done :). Thanks goes to the original poster here.

 svn st -q | awk '{print $2;}' | xargs svn revert 

Hope this helps someone who is looking for the same functionality.

Monday, June 24, 2013

WSO2 Governance Registry - Lifecycle Management Part 1 - Check Items

The Lifecycle Management(LCM) plays a major role in SOA Governance. The default LCM supported by the WSO2 Governance Registry allows users to promote and demote life cycle states of a given resource. Furthermore, it can be configured to use checklists as well check out the documentation here.

The Lifecycle configuration templates allows advance users to extend its functionality through 6 data elements which are listed below
  • check items
  • transition validations
  • transition permissions
  • transition executions
  • transition UI
  • transition scripts
Bellow is the full template of the lifecycle configuration. in this article series we will take a look at each item and see how they can be used to customize lifecycle management in WSO2 Governance Registry. In this article we will look at check items. 

check items

Check items allow you to define a list, ideally an check list that can be used to control changes in lifecycle states and make sure specific requirements are met before the lifecycle is changed to the next state. It is also possible to
  • Define permissions for each check item
  • Define custom validations for each check item
To check this out we will create a sample lifecycle with a new set of check items. First we have to create a new  lifecycle. The steps to create a new lifecycle can be found here - Adding Lifecycles. There will be a default lifecycle configuration when you create one using the steps since it is a complex configuration we will replace it with the following configuration. 

<aspect name="SimpleLifeCycle" class="org.wso2.carbon.governance.registry.extensions.aspects.DefaultLifeCycle">
    <configuration type="literal">
            <scxml xmlns=""
                <state id="Development">
                        <data name="checkItems">
                            <item name="Code Completed" forEvent="Promote">
                                    <permission roles="wso2.eng,admin"/>
                                 <validation forEvent="" class="">
                                         <parameter name="" value=""/>
                            <item name="WSDL, Schema Created" forEvent="">
                            <item name="QoS Created" forEvent="">
                    <transition event="Promote" target="Tested"/>                  
                <state id="Tested">
                        <data name="checkItems">
                            <item name="Effective Inspection Completed" forEvent="">
                            <item name="Test Cases Passed" forEvent="">
                            <item name="Smoke Test Passed" forEvent="">
                    <transition event="Promote" target="Production"/>
                    <transition event="Demote" target="Development"/>
                <state id="Production">  
                    <transition event="Demote" target="Tested"/>

As you can see several check items are listed below the "Development" and "Tested" states, the two main attributes in the check list data item is name and forEvent. 

name - The name of the check item, this is the text that will be displayed for the check item.
forEvent - The event that is associated with this check item, for example if the forEvent is set to "Promote" this check item must be clicked in order to proceed with the promote operation for that state.

Custom permissions

As you can see in the "Development" state there is a sub element as follows
     <permission roles="eng,admin"/>

In this element it is possible to define a set of roles that are allowed to check this check item. in this sample only engineers and admins are allowed to check this item

Custom validations
     <validation forEvent="" class="">
          <parameter name="" value=""/>

As seen in the commented out section under the "Code Completed" check item it is also possible to define custom validations. But the validations will only be called when during a state transition. we will look into custom validations under "transition validations" in the next post. 

Now you can save the newly created lifecycle configuration and use it in an artifact like an "api" or "service" and see its functionality.

We will look at Transition Validations and how to use them in the next post of this series.

Wednesday, June 5, 2013

How to define XSD to allow any XML element as child element

While working on a new feature for WSO2 GREG i came across a requirement  to allow any arbitrary XML element to be passed as a child element and i needed to define this in an XSD file. After a bit of searching and some help i was able to find the correct XSD structure for this and thought i might be helpful to share it

<xs:element maxoccurs="unbounded" minoccurs="0" name="parameter">
     <xs:any maxoccurs="unbounded" minoccurs="0" processcontents="skip">
        <xs:attribute name="name" type="xs:string" use="optional">
        <xs:attribute name="value" type="xs:string" use="optional">

The given XSD will allow an XML such as the example given below

<parameter name="payload">
 <p:adderprocessrequest xmlns:p="">
  <!--Exactly 1 occurrence -->
  <x xmlns="">x</x>
  <!--Exactly 1 occurrence -->
  <y xmlns="">y</y>
Hope this is helpful to anyone who needs to to configure an XSD for a similar situation


Amazon Deals