I think this is an inherent problem with tasks versioning because many of the descriptors are on task module and not on core. I would like to see a new module but considering that we don't have a whole lot , best option is to migrate versioning stuff to commons and let modules/core and modules/tasks depend on that.
On Tue, Sep 24, 2013 at 1:41 PM, Thilini Gamage <[email protected]>wrote: > Hi all, > In Synapse Artifact versioning, I kept the versioning stuff like artifact > version key generators, versionFactory classes, version based serializer > classes etc in core module. But while proceeding with task versioning, I > faced with some dependency cycles between task module and core module. To > avoid this can't we migrate versioning stuff to commons module. Or is it > ok to create a separate module for versionong stuff? > > > On Tue, Aug 20, 2013 at 8:53 AM, Thilini Gamage <[email protected]>wrote: > >> The UUID's are never exposed to users. There is a conversion of a given >> artifact name and version into uuid and that particular uuid is used for >> artifact deployment, removal, dispatching etc. >> >> >> On Tue, Aug 20, 2013 at 4:52 AM, Hiranya Jayathilaka < >> [email protected]> wrote: >> >>> >>> On Aug 19, 2013, at 2:02 PM, Udayanga Wickramasinghe < >>> [email protected]> wrote: >>> >>> Hi, >>> sorry for my late reply. >>> +1 for hierarchical services. I think one other alternative is to >>> implement versioned proxy services through 'version' attribute which is how >>> sequences/endpoints are versioned right now. We plan to represent different >>> versions of same service using a unique id (uuid) and register them in >>> 'AxisConfiguration'/SynapseConfig. >>> >>> >>> This sounds good. It's consistent with how the other artifacts are >>> versioned in Synapse. >>> >>> However this requires a special handler (ie:- Axis2 handler/dispatcher) >>> to convert a name,version pair to the respective uuid and dispatch to the >>> relevant service. >>> >>> ie:- handler will convert /services/TestProxy/1.0.0 to >>> /services/TestProxy_1.0.0_{uuid} >>> >>> >>> The UUIDs are never exposed to the user right? >>> >>> Thanks, >>> Hiranya >>> >>> >>> Regards >>> Udayanga >>> >>> On Sun, Aug 11, 2013 at 2:46 PM, Hiranya Jayathilaka < >>> [email protected]> wrote: >>> >>>> >>>> On Aug 11, 2013, at 4:52 AM, Thilini Gamage <[email protected]> >>>> wrote: >>>> >>>> Hi all, >>>> >>>> I'm currently working on the GSOC project of 'Versioning of Synapse >>>> Artifact' [1] and up to now I have completed the versioning of Synapse >>>> sequences ( including main sequences) and endpoints. The versioning of >>>> sequence and endpoints is done by generating an unique identifier (based on >>>> artifact name and version) for each versioned artifact and maintaining that >>>> unique identifier in deployment and run time dispatching etc. >>>> >>>> Now I'm looking into proxy services versioning and according to my >>>> understanding the proxy services versioning can to be enabled by building >>>> axis2 service for each versioned proxy. The axis2 service deployment and >>>> dispatching should be done using a generated unique identifier. >>>> >>>> >>>> I think this should be similar to API versioning. APIs use the >>>> VersioningStrategy interface to determine how the version numbers are >>>> associated with individual APIs. The default implementation uses a >>>> URL-based strategy. >>>> >>>> e.g. /context/1.0.0/foo/bar >>>> >>>> You can take a similar approach for proxy services. May be we only need >>>> URL based versioning in the case of proxy services. Since proxy services >>>> deal with SOAP messages, I don't think other options make much sense. So we >>>> probably need something like: >>>> >>>> /services/TestProxy/1.0.0 >>>> >>>> The main problem however is representing different versions of the same >>>> service in the SynapseConfiguration/AxisConfiguration. Axis2 supports >>>> something called hierarchical services (see >>>> https://issues.apache.org/jira/browse/SYNAPSE-914). May be you can try >>>> to leverage that. >>>> >>>> Thanks, >>>> Hiranya >>>> >>>> >>>> >>>> Any comments and suggestions on this? >>>> >>>> [1]-https://issues.apache.org/jira/browse/SYNAPSE-928 >>>> -- >>>> Thilini >>>> Thilini Shanika Gamage >>>> Department of Computer Science and Engineering >>>> University of Moratuwa >>>> >>>> >>>> -- >>>> Hiranya Jayathilaka >>>> Mayhem Lab/RACE Lab; >>>> Dept. of Computer Science, UCSB; http://cs.ucsb.edu >>>> E-mail: [email protected] <[email protected]>; Mobile: +1 (805) >>>> 895-7443 >>>> Blog: >>>> http://techfeast-hiranya.**blogspot.com<http://techfeast-hiranya.blogspot.com/> >>>> >>>> >>> >>> >>> -- >>> http://www.udayangawiki.blogspot.com >>> >>> >>> -- >>> Hiranya Jayathilaka >>> Mayhem Lab/RACE Lab; >>> Dept. of Computer Science, UCSB; http://cs.ucsb.edu >>> E-mail: [email protected] <[email protected]>; Mobile: +1 (805) >>> 895-7443 >>> Blog: >>> http://techfeast-hiranya.**blogspot.com<http://techfeast-hiranya.blogspot.com/> >>> >>> >> >> >> -- >> Thilini >> Thilini Shanika Gamage >> Department of Computer Science and Engineering >> University of Moratuwa >> > > > > -- > Thilini > Thilini Shanika Gamage > Department of Computer Science and Engineering > University of Moratuwa > -- http://www.udayangawiki.blogspot.com
