Not unless embedded uses OSGi.
Thanks,
Sahoo
Marina Vatkina wrote:
> 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
>>
>>
>>
>