You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@karaf.apache.org by "Glen Mazza (Issue Comment Edited) (JIRA)" <ji...@apache.org> on 2011/11/25 15:03:40 UTC
[jira] [Issue Comment Edited] (KARAF-1027) Have
cave:update-repository work with proxy repositories
[ https://issues.apache.org/jira/browse/KARAF-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157157#comment-13157157 ]
Glen Mazza edited comment on KARAF-1027 at 11/25/11 2:01 PM:
-------------------------------------------------------------
But isn't proxying a core *Cave* behavior, if not an OBR one? To be most functional, a Cave repository's repository.xml file may need to move beyond its strict definition in Felix, in particular, the need for extension elements and attributes like "proxiedurl".
I had to override (actually, copy) much more of DataModelHelper than I would have liked because too much of it is private rather than public. (Perhaps the Felix project can see the need to allow for more subclassing of these elements, and change that.) While DataModelHelper nominally allows us to subclass the serializing of each element within a repo file (so we can add more elements/attributes in), the top-level method used for writing the repository as a whole unhelpfully calls only the Felix-specific methods for writing each child element.
While the proxiedurl attribute is not being used in the patch (and that portion of the patch can be omitted for the time being at least), presently the lifespan of a cave repository is only as long as its parent Karaf instance is active. (We have cave:create-repository but not cave:attach-repository*, the former is doubling up for the latter.) If we wish to be able to reattach cave repositories (including proxy ones) upon a shutdown and restart of Karaf, Karaf will later need to read the proxiedurl attribute in to know (1) that it's a proxy repository, and (2) the remote repository it's pointing to. Else the user is going to have to recreate the proxy repo with cave:proxy-repository again each time he restarts Karaf, typing in the ugly & lengthy remote URL every time--rather clumsy and unpleasant unless he uses some form of automated script.
But the here-and-now purpose of this patch is just to have cave:update-repository also work with proxy repositories. If you can do this in a less intrusive manner, great, be my guest.
*a potentially new command which would have the exact opposite semantics of the already existing cave:remove-repository command. (But that's another topic.)
was (Author: gmazza):
But isn't proxying a core *Cave* behavior, if not an OBR one? To be most functional, a Cave repository's repository.xml file may need to move beyond its strict definition in Felix, in particular, the need for extension elements and attributes like "proxiedurl".
I had to override (actually, copy) much more of DataModelHelper than I would have liked because too much of it is private rather than public. (Perhaps the Felix project can see the need to allow for more subclassing of these elements, and change that.) While DataModelHelper nominally allows us to subclass the serializing of each element within a repo file (so we can add more elements/attributes in), the top-level method used for writing the repository as a whole unhelpfully calls only the Felix-specific methods for writing each child element.
While the proxiedurl attribute is not being used in the patch (and that portion of the patch can be omitted for the time being at least), presently the lifespan of a cave repository is only as long as its parent Karaf instance is active. (We have cave:create-repository but not cave:attach-repository*, the former is doubling up for the latter.) If we wish to be able to reattach cave repositories--including proxy ones--upon a shutdown and restart of Karaf, Karaf will later need to read the proxiedurl attribute in to know (1) that it's a proxy repository, and (2) the remote repository it's pointing to. Else the user is going to have to recreate the proxy repo with cave:proxy-repository again each time he restarts Karaf, typing in the ugly & lengthy remote URL every time--rather clumsy and unpleasant unless he uses some form of automated script.
But the here-and-now purpose of this patch is just to have cave:update-repository also work with proxy repositories. If you can do this in a less intrusive manner, great, be my guest.
*a potentially new command which would have the exact opposite semantics of the already existing cave:remove-repository command. (But that's another topic.)
> Have cave:update-repository work with proxy repositories
> --------------------------------------------------------
>
> Key: KARAF-1027
> URL: https://issues.apache.org/jira/browse/KARAF-1027
> Project: Karaf
> Issue Type: Improvement
> Components: cave-repository
> Affects Versions: cave-3.0.0
> Reporter: Glen Mazza
> Assignee: Jean-Baptiste Onofré
> Fix For: cave-3.0.0
>
> Attachments: proxyupdate.patch
>
>
> Supplied patch makes following changes:
> 1.) cave:proxy-repository now creates the repository before populating its repository.xml with the remote repository's contents (prior functionality would raise an exception if the repository did not exist.)
> 2.) switches the "non-register" to OBR option from -nu to -nr (like create repository)
> 3.) Like create-repository, will raise an exception if the proxy repository already exists.
> 4.) Adds a proxiedurl attribute to the repository.xml file (for subsequent reading when loading an already created proxy repository--functionality is not yet used.) Warning: the schema for the repository.xml now deviates from Felix because of this additional attribute (unsure if that matters), although it still loads into the Karaf OBR (obr:listurl).
> 5.) cave:update-repository will now work for both normal and proxied cave repositories, in the latter case it does a rescan of the remote repository and recreates the repository.xml file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira