Ok so actually if I wanted REST access for loading unstructured content in the case of a non-OSGi based consumer and loading a bundle jar directly for those that are OSGi where the REST path would distinguish the repository location would that make sense?
I know it is possible to directly store bundles in the Sling repo. and then load it as I have tested with the following scenario: curl -vvv -u admin:admin -F"sling:resourceType=test/A" -F"[email protected]" http://localhost:8181/content/provider/bundles #from karaf cli install -s http://localhost:8181/content/provider/bundles/testBundle.jar This bundle does not have the Sling-Initial-Content setup though. The preference would be instead of placing the responsibility on any third-party providers for laying out the content, they simply provide the bundles in an OBR, those bundles either contain the Sling-Initial-Content and structure for non-OSGi or without for normal bundles. Some of these providers may not work with Java providing content only so keeping the Java side of things to a minimum is best. An admin will then install them in a local mirror/cache with the possibility for some bundles to be automated through a scheduled job. So given that case how to store the data and make it accessible locally. For example to have the following: OSGi get(install) /content/osgiBundle/consumerA/testBundle.jar non-OSGi get /content/contentBundle/consumerB/{resources,binaries,...} This way things don't deviate too much and you get the same benefits such as search etc. Based on the documentation it appears the bundle needs to be activated for the Sling-Initial-Content to be processed. Obviously this is something that shouldn't happen in the standard bundle case so it should be simply stored. I'm guessing to support both cases it will require more agreed upon convention which is fine as long as it can work with REST access similar to what I mentioned before. The goal here is to provide a common packaging and distribution mechanism to handle the different consumer types. This looks to be a simpler and feasible approach compared to involving an ESB for example although that might be the better way to go, another point I'll need to determine. sam -- View this message in context: http://apache-sling.73963.n3.nabble.com/Feasible-Use-Case-tp4021906p4022017.html Sent from the Sling - Users mailing list archive at Nabble.com.
