[
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
