| Re: [concierge-dev] Bundle.getDataFile(), expected behavior? |
final File file = new File(path + "/data", filename);
file.getParentFile().mkdirs();
return file;
If filename is empty string (like in test case), the parent dir is not storage/default/1/data, but storage/default/1 folder.
I think we have to handle the case of "" in mkdirs() code.
I will provide a patch for that.
Bye, Jochen
I agree that the directory should be created once getDataFile is called even though I don't think that this is specified anywhere. However, looking into the code, it seems like this is the implemented behavior?
--Jan.
Jochen Hiller ---12/01/2014 10:12:34 AM---Hi all, I came during testing of Apache Felix Gogo across some problems with
From: Jochen Hiller <jo.hiller@xxxxxxxxxxxxxx>
To: Concierge developer discussions <concierge-dev@xxxxxxxxxxx>
Date: 12/01/2014 10:12 AM
Subject: [concierge-dev] Bundle.getDataFile(), expected behavior?
Sent by: concierge-dev-bounces@xxxxxxxxxxx
_______________________________________________
Hi all,
I came during testing of Apache Felix Gogo across some problems with getDataFile().
I just fixed this morning the method to return null in case of bundle is a fragment (and no bundleContext available). This is according to OSGi spec.
Now I added another test case for a bundle to check whether I can write/read from data folder of a bundle.
I am wondering whether the folder (which is ./data below the bundle, e.g. storage/default/1/data) has to be created by the framework of by the caller. In OSGi spec there is nothing defined for that, except that framework has to care about FilePermissions (which is out-of-scope of this question).
Intuitively I would expect that the folder should be created by framework (at least layz when getDataFile() has been called at least once). This is actually NOT the case.
I am not sure how other frameworks will do that, as I remember normally I dont care about creating the data folder, just subfolders below.
Any thoughts?
Bye, Jochen
concierge-dev mailing list
concierge-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/concierge-dev
_______________________________________________
concierge-dev mailing list
concierge-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/concierge-dev
