That's understandable. Thanks for pointing them out. As I said, I am
more interested in module addition, updation and removal. May be I did
not make myself very clear. By updation, I mean the updation of the
module's jar file (for patching or upgrading).
Thanks,
Sahoo
Byron Nevins wrote:
> Changing a JVM option can require a restart. E.g. you change the
> memory heap size. Or switch to server-VM from client-VM.
>
>
>
> Lloyd Chambers wrote:
>> Sahoo,
>>
>> Some modules might not be able to reconfigure....suppose a port
>> number is changed. The module might not be able to dynamically
>> switch ports for example, or change SSL certificates on an existing
>> port, or whatever.
>>
>> Lloyd
>>
>>
>>
>> On Jul 24, 2008, at 4:40 PM, Sahoo wrote:
>>
>>> I am trying to understand when and why we need server restart. By
>>> server restart, I mean starting in a new JVM. I am particularly
>>> interested in addition, updation and removal of modules. OSGi
>>> framework provides us the necessary facilities to do all these
>>> things without server restart, so it must be something to do with
>>> our implementation. I am aware one such implementation bottle-neck,
>>> which is the way we do application class loading. Let's say we
>>> address that. Actually, I know one more such bottle-neck, which is
>>> our naming manager implementation which relies on some singleton
>>> object in JRE. What are the other places? I will appreciate if each
>>> module owner takes some time and tells us why they think server
>>> needs to be restarted when their module is added, updated or
>>> removed. At least identifying those issues during development of
>>> modules will go a long way in being able to overcome them in future.
>>>
>>> Thanks,
>>> Sahoo
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>