Have you looked at Karaf features ? those do support bundle start levels. Cheers, Guillaume Nodet
2015-12-14 17:02 GMT+01:00 Seth Lana <sethlanag...@gmail.com>: > Hi Peter, > > many thanks for your inputs, it really helped us to defined the way our > team should to go. > > We had some difficulties defining the requirements of this pilot project > due to, as you said, the large number of possibilities and combinations > that we could have. But we are getting there... > > One last doubt, we have found no reference about bundle start level on > both Initial Provisioning and Deployment Admin specs. > > In case of IP, we thought about two possibilities. One is to use IP > archive's manifest file to hold the information and let the IP > implementation bundle to use it after it install the bundle. for example: > > InitialProvisioning-Entries: org.apache.felix.scr;type=bundle; > *startLevel=2* > > Another one is to add a text entry on the IP zip. as that will be stored > in the provisioning dictionary then the management agent can obtain that > information using the provisioning service and use it to set the > startLevel. > > We are inclined for the option one. which would be the best approach for > you? > > best regards, > > Seth > > > On 10-12-2015 11:48, Peter Kriens wrote: > > On 9 dec. 2015, at 00:46, Seth Lana <sethlanag...@gmail.com> > <sethlanag...@gmail.com> wrote: > Hello, > I’m researching about the best ways to provide automatic remote provisioning > for small devices and also for the servers that will provide content for such > devices. Reading the OSGi compendium, some specs caught my attention: Initial > Provisioning, Deployment Admin, Subsystems and Repository Services. > > If I got it right, we can have a device with only the OSGi container(with a > minimal deps) and the IP Agent bundle jars assembled at factory. > > Yes. The core idea is that you deliver identical devices to all your > customers except for the identity (serial number or so). > > > At first use, the IP agent will contact the remote provisioning service > (using Http or another protocol) and will download one or more IP zip files > containing one or more bundles and configuration files defined by the remote > provisioning operator for that device. All bundles inside the IP zips will be > installed by the IP agent. So, this process follows until all necessary > bundles are installed, ending with the Management Agent bundle being started. > Am I right? > > Yup. > > > What I found strange was the fact that only one bundle can be started at each > time (each zip can have only one start entry pointing to only one bundle). > Why this restriction? > > This allows this single bundle to verify the environment, do some checks, and > setup security & start levels for example. > > > Should the Management Agent uninstall the IP agent after it is fully > operational? or the IP must run every time the device starts up ? > > There is no obligation here. Personally, I would make sure that in certain > situations the device can go back to initial mode so that the operator can > regain control of the device after a catastrophic event. But again, there are > not rules defined here. > > > But the biggest doubt is about that Management Agent itself. It seems that > one needs to be developed, right?. > > Yes. Something needs to provide YOUR policy, this is the management agent. > You could buy one (this was ProSyst’s answer), there is open source (this was > Marcel’s answer, or there is building it yourself. I prefer the latter > because it allows you to provide your policy to the management operations. It > is not a big deal because the management operations are part of the well > defined OSGi API and are almost trivial to use. > > > Should the Management Agent to use a Deployment Admin service provided by > another bundle or should it be itself the provider of such service? > > There are no restrictions here. Make sure the Management Agent only provides > policy so if you insist on using Deployment Admin then it is not a good idea > to implement it yourself. > > > And about the Repository Service, should it be used by the Management Agent > or Deployment Admin or both? > > I think you are focusing too much on all potential possibilities. What are > your requirements? OSGi is a bit like a box of Lego. Once you have a clear > vision of how you want to manage your devices you find the components in > OSGi. However, you can combine these components in infinite ways and > exploring all combinations is not providing you with the right solution any > time soon. > > > Can a Subsystem (.esa) be package inside a Deployment Package? > > You can write your own Resource Processor with Deployment Admin so in > principle yes. However, both Deployment Admin and subsystems struggle with > sharing bundles. Deployment Admin took the easy way out and decided to not > share bundles. Subsystems do allow sharing but struggles because of the > complexity this creates. > > > Can the Deployment Packages (*.dp) or Subsystems (*.esa) also be provided by > an OSGi repository ? > > Again yes. You will need to write a Resource Processor and then you can > install anything anywhere with Deployment Admin. > > You might get more useful advice from this group if you provide us with the > actual use case. > > Kind regards, > > Peter Kriens > > > thanks for any opinion. > > regards, Seth. > > > _______________________________________________ > OSGi Developer Mail > listosgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev > > _______________________________________________ > OSGi Developer Mail > listosgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- ----------------------- Guillaume Nodet ------------------------ Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
