Hi,
Bertrand Delacretaz (JIRA) schrieb:
Revision 680753 contains a first usable version, here's how to test it:
Good.
Note that the same config can be edited from the Sling console, which will show
changes made in the cfg file, but the opposite is not true: changes made in the
Sling console are not visible in the cfg file, that's a problem that we'll need
to solve. Not to mention potential security implications - we might need to
restrict what can be done with jcrbundles, or make sure that it doesn't mess
with bundles and configs installed via other means.
First off, the only correct answer to "which configuration is used" and
"what bundle is active" comes from the running framework and not from
any other location.
Having said that, the jcrbundles module is free to listen for
configuration events from the ConfigurationAdmin to write back any
configuration files.
With bundles, it is somewhat different. Because you cannot extract the
bundle file of installed bundles from the framework (this is probably
also not what you want).
So, we should just keep in mind, that the jcrbundles functionality is
just one of many frontend options to manage bundles and configurations.
But you raise an interesting question: What if the same bundle (same
symbolic name, different version) is stored in different locations ?
What if multiple differing configurations exist ?
Note that jcrbundles will resynchronize the OSGi state with what's in the
bundles folders when the service starts: bundles and configs added, removed or
updated while the service is not active are taken into account at the next
restart.
Wow: Removed and updated ! While update may or may not work on
configuration files. It may not work as expected most of the time. Same
for bundles.
Consider this situation:
* user starts jcrbundles
* user puts bundle A, version 1.0
* jcrbundles is stopped
* bundle A is updated to version 1.1 by some other means
* jcrbundles is started
Now, you can say, we would not downgrade. That is ok here. But in some
situations, it is not ok (ok, generally a downgrade is not what we want)
For Remove the situation is even worse: How do you decide whether a
bundle or configuration has been removed if it does not exist in the
repository when jcrbundles starts ? I would assume, you can't.
So, for a startup sync, install/add is probably the only save bet we can
make. And not even this: Consider bundle A being removed from the
framework while jcrbundles has been stopped. Now jcrbundles is started
again. Do you really want bundle A to be reinstalled ?
And of, course the security implications you also noted come to it: I
assume the JCR location should be ACL-secured to prevent John Doe from
modifying it. This should probably do the trick. Right ?
Regards
Felix
