Is it expected to work in embedded mode as well?
thanks,
-marina
Lloyd Chambers wrote:
> modules-autostart makes sense to me too.
>
> Lloyd
>
> On Aug 21, 2009, at 10:20 AM, Byron Nevins wrote:
>
>> If there is nothing in /modules other than autostart than modules-
>> autostart is less hassle
>>
>> Sahoo wrote:
>>
>>> I meant a directory that's specific to a GlassFish installation
>>> (something under installRoot), not something specific to an
>>> administrative domain.
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> Lloyd Chambers wrote:
>>>
>>>> Sahoo,
>>>>
>>>> By "installation specific", you mean per-platform, or per-install
>>>> on each platform, or something else?
>>>>
>>>> Or are you just saying there is an autostart directory?
>>>>
>>>>
>>>> Lloyd
>>>>
>>>> On Aug 21, 2009, at 12:58 AM, 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.
>>>>>
>>>>
>>>> Lloyd Chambers
>>>> lloyd.chambers_at_sun.com
>>>> GlassFish Team
>>>>
>>>>
>>>>
>>
>
> Lloyd Chambers
> lloyd.chambers_at_sun.com
> GlassFish Team
>
>
>