Re: Content Loader and Overwrite logic
On 24 Sep 2010, at 10:15, Ian Boston wrote:
Bug or expected behaviour ?
The registered bundle content contains no uninstall-paths so IIUC, nothing
should have been uninstalled and yet the folders go awal
x43543-2:contenttest ieb$ curl
http://localhost:8080/var/sling/bundle-content.tidy.3.json
org.sakaiproject.nakamura.contenttest1: {
content-loaded-by: 25cced8c-72a4-4c80-9611-1b63f071c0d5,
content-load-time: Fri Sep 24 2010 10:05:59 GMT+0100,
jcr:mixinTypes: [mix:lockable],
content-loaded: true,
jcr:primaryType: nt:unstructured
},
org.sakaiproject.nakamura.contenttest2: {
content-loaded-by: 25cced8c-72a4-4c80-9611-1b63f071c0d5,
content-load-time: Fri Sep 24 2010 10:05:41 GMT+0100,
jcr:mixinTypes: [mix:lockable],
content-loaded: true,
jcr:primaryType: nt:unstructured
}
Ian
Ian
Re: Content Loader and Overwrite logic
On 24 Sep 2010, at 10:35, Ian Boston wrote:
On 24 Sep 2010, at 10:15, Ian Boston wrote:
Bug or expected behaviour ?
The registered bundle content contains no uninstall-paths so IIUC, nothing
should have been uninstalled and yet the folders go awal
x43543-2:contenttest ieb$ curl
http://localhost:8080/var/sling/bundle-content.tidy.3.json
org.sakaiproject.nakamura.contenttest1: {
content-loaded-by: 25cced8c-72a4-4c80-9611-1b63f071c0d5,
content-load-time: Fri Sep 24 2010 10:05:59 GMT+0100,
jcr:mixinTypes: [mix:lockable],
content-loaded: true,
jcr:primaryType: nt:unstructured
},
org.sakaiproject.nakamura.contenttest2: {
content-loaded-by: 25cced8c-72a4-4c80-9611-1b63f071c0d5,
content-load-time: Fri Sep 24 2010 10:05:41 GMT+0100,
jcr:mixinTypes: [mix:lockable],
content-loaded: true,
jcr:primaryType: nt:unstructured
}
Ian
DefaultContentCreator:252
-// if node already exists but should be overwritten, delete it
-if (!this.ignoreOverwriteFlag this.configuration.isOverwrite()
parentNode.hasNode(name)) {
+// if the parent node already exists and should be overwritten,
delete it but only if uninstall is set to false.
+if (!this.ignoreOverwriteFlag this.configuration.isOverwrite()
!this.configuration.isUninstall() parentNode.hasNode(name)) {
parentNode.getNode(name).remove();
}
configuration.isUninstall() does not exists at the moment.
WDYT ?
or do we need a new flag update:=true ?
Ian
Ian
Re: Content Loader and Overwrite logic
Hi, Am 24.09.2010 11:50, schrieb Ian Boston: On 24 Sep 2010, at 10:47, Carsten Ziegeler wrote: Ian Boston wrote contentFolder1/contentInFolder2.txt is missing, indicating that subfolders are deleted when uninstall=false even if the content of the sub folder came from another bundle. Bug or expected behaviour ? I think this is expected behaviour as you have overwrite=true - so installing a bundle with contents for the same node overwrites existing content. In your case contentFolder1 contains the contents of the last bundle installed. Ok, So you cant split content between bundles or Have a bundle update content. I think what I really want is something update:=true which looks at the lastModified on every file and only updates it if the bundled file is later. The overwrite functionality probably needs to stay. Do we need such a flag ? Shouldn't this be default ? Not really sure and not having thought of all the backwards-compatibility consequences. Regards Felix WDYT? Ian Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Content Loader and Overwrite logic
On 24 Sep 2010, at 10:54, Felix Meschberger wrote: Do we need such a flag ? Shouldn't this be default ? Not really sure and not having thought of all the backwards-compatibility consequences. Well that would make sense, at the moment an updated bundle doesn't result in updated content, having it do so will change backwards behaviour, logically if each file in the bundle is newer than the file in the jcr then it should be updated. The only time when this will cause a problem is if the file in JCR was edited after the bundle loaded it. We probably only want to consider this for files and not for things that modify properties. (.json, .xml etc) wdyt? Ian
Re: Content Loader and Overwrite logic
Ian Boston wrote On 24 Sep 2010, at 11:06, Carsten Ziegeler wrote: So if you want to update this content, you should update the corresponding bundle. Thats the bit thats not really working (unless I say overwrite:=true) Yes, right - that's why you should have overwrite:=true :) as Felix said, perhaps the default should be the content gets updated if the bundle gets updated, although thats going to break for anyone who was expecting edits post bundle load to remain. Yepp, right, I think this would make more sense for the a default. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Content Loader and Overwrite logic
On 24 Sep 2010, at 11:21, Carsten Ziegeler wrote: Ian Boston wrote On 24 Sep 2010, at 11:06, Carsten Ziegeler wrote: So if you want to update this content, you should update the corresponding bundle. Thats the bit thats not really working (unless I say overwrite:=true) Yes, right - that's why you should have overwrite:=true :) as Felix said, perhaps the default should be the content gets updated if the bundle gets updated, although thats going to break for anyone who was expecting edits post bundle load to remain. Yepp, right, I think this would make more sense for the a default. Ok, I will open a jira and fix, just for files. Ian Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Content Loader and Overwrite logic
On 24 Sep 2010, at 11:21, Carsten Ziegeler wrote: Ian Boston wrote On 24 Sep 2010, at 11:06, Carsten Ziegeler wrote: So if you want to update this content, you should update the corresponding bundle. Thats the bit thats not really working (unless I say overwrite:=true) Yes, right - that's why you should have overwrite:=true :) as Felix said, perhaps the default should be the content gets updated if the bundle gets updated, although thats going to break for anyone who was expecting edits post bundle load to remain. Yepp, right, I think this would make more sense for the a default. There is one problem with using the lastModified timestamp per content file, it comes from the URL, which comes from the Jar, and since that comes from the temporary file where the jar is being installed from it may not represent the last modified time of the bundle. In the case of a bundle that has been posted over http, that is certainly the case. Not so certain about a bundle that was installed via bootstrap. Is this going to be Ok ? Ian Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Content Loader and Overwrite logic
Hi, Am 24.09.2010 13:06, schrieb Ian Boston: On 24 Sep 2010, at 11:57, Felix Meschberger wrote: Hi, Am 24.09.2010 12:39, schrieb Ian Boston: On 24 Sep 2010, at 11:21, Carsten Ziegeler wrote: Ian Boston wrote On 24 Sep 2010, at 11:06, Carsten Ziegeler wrote: So if you want to update this content, you should update the corresponding bundle. Thats the bit thats not really working (unless I say overwrite:=true) Yes, right - that's why you should have overwrite:=true :) as Felix said, perhaps the default should be the content gets updated if the bundle gets updated, although thats going to break for anyone who was expecting edits post bundle load to remain. Yepp, right, I think this would make more sense for the a default. There is one problem with using the lastModified timestamp per content file, it comes from the URL, which comes from the Jar, and since that comes from the temporary file where the jar is being installed from it may not represent the last modified time of the bundle. In the case of a bundle that has been posted over http, that is certainly the case. Not so certain about a bundle that was installed via bootstrap. That's not entirely true, actually. IIRC the timestamp in fact comes from the URL but it comes either from the actual file inside the bundle JAR or it comes from the providing bundle's last modification time (Bundle.getLastModified()). Ahh, Ok, although that is the time when the bundle was installed or updated, not when it was last bundled. Yes. Bnd-LastModfied looks like it gets updated when bundled (provided the Bnd Tool is used) Yes, well for most bundles, this is probably usable nowadays ;-) Use that, and fall back to Bundle.getLastModified() is missing? The correct thing is to use URLConnection.getLastModified(), which unfortunately gives you the Bundle.getLastModified() in Felix but may at the same time give you the correct answer ... How about this: Get both (if available) and assume the older (smaller number) ? Regards Felix Ian Regards Felix Is this going to be Ok ? Ian Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Content Loader and Overwrite logic
On 24 Sep 2010, at 12:12, Felix Meschberger wrote: Use that, and fall back to Bundle.getLastModified() is missing? The correct thing is to use URLConnection.getLastModified(), which unfortunately gives you the Bundle.getLastModified() in Felix but may at the same time give you the correct answer ... How about this: Get both (if available) and assume the older (smaller number) ? yes that appears to work ok, will commit in a moment. Ian
