If I want the log service to start first then I make every service depend on the log service, mandatorily. And then if the log service restarts then so does everything else, but so what? Just make sure the log service doesn't restart halfway through boot ...
> On 14/12/15 18:29, Peter Kriens wrote: >> NO startlevels is best :-) >> >> If you really need start levels (and after thinking again) then you can >> your set start levels by your management agent. One more reason why only >> one bundle is started. >> >> Though start levels can be helpful to make it look like the systems >> boots faster, it is too often used to mask bad bundles that are not >> properly handling their dependencies. Those bundles will give you pain >> in the future so it is better to fix them from the start. And then they >> do not need start levels. >> > > > As a valid use-case I see the very early starting of a log bundle... > (as an example) > >> Kind regards, >> >> Peter Kriens >> >> >> >> >>> On 14 dec. 2015, at 17:02, Seth Lana <sethlanag...@gmail.com >>> <mailto:sethlanag...@gmail.com>> wrote: >>> >>> 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> wrote: >>>>> Hello, >>>>> Im 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 ProSysts answer), there is open >>>> source (this was Marcels 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 List >>>>> osgi-dev@mail.osgi.org >>>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> osgi-dev@mail.osgi.org >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > > -- > Ferry Huberts > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
