Thanks for the feedback. Based on the feedback, I have configured
modules/autostart to be the directory which will be monitored for bundle
addition/updation/deletion.
Sahoo
Sahoo wrote:
> Problem Context:
> When GlassFish starts, the bootstrap process starts an OSGi framework
> (default is Felix), which is configured to start one of our bundles
> called osgi-main.jar. This primordial bundle is responsible for
> installing all the OSGi bundles available in modules directory tree. It
> also takes care of updating modified bundles and deleting removed
> bundles from OSGi runtime so as to keep the OSGi persistent cache in
> sync with the GlassFish installation. It then starts all other bundles
> that are necessary for server to start. This includes any bundle that
> has a Startup service or Init service. When such a service requires
> service from some other bundle, that bundle is started in the process.
> So, in essence, not all bundles are started automatically when the
> server starts. This lazy startup of bundles gives us good startup time
> and memory footprint. /But, it causes problems when we host bundles
> developed elsewhere in the modules dir/. e.g. Felix Web Console which
> can be used to manage OSGi runtime. Those bundles do not necessarily
> contain a Startup service to be started automatically. Unless they are
> started, they are not much useful. Although we have a domain specific
> autostart directory where users can drop OSGi bundles to be started
> automatically when server starts, such a domain specific directory can't
> be used to install update centre packages. As a result, we can't make
> useful bundles like the one mentioned earlier made available via update
> centre.
>
> Proposal:
> I am proposing to add an installation specific autostart directory,
> where user can drop an OSGi bundle for it to be started automatically.
> We already have necessary infrastructure to implement it. I am open to
> the choice of names. The ones that come to my mind are
> modules/autostart/ and modules-autostart/. I am also of the opinion that
> these bundles should have same security privileges as bundles in
> modules/, as this directory is owned by the user who owns the
> installation, so it is already protected. These bundles will be started
> after server startup is complete unless there is a deployed application
> that uses a package exported by any of these bundles, so they can't
> typically affect startup time.
>
> Opinions, objections?
>
> Thanks,
> Sahoo
>
> p.s.: This issue came up during a conversation with Abhijit earlier
> today.
>