You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Gianny Damour <gi...@optusnet.com.au> on 2007/03/07 12:10:57 UTC
ClientCommandLine and Daemon - Changing boot approach?
Hi,
Following the introduction of a potentially simpler bootstrapping
mechanism (currently used by the deployers), we now have an
opportunity to refactor ClientCommandLine and Daemon to leverage this
same approach.
The idea of the new bootstrapping mechanism is as follows:
MainBootstrapper boots a configuration, gets from the Kernel a Main
implementation and then delegates to it. As the Main implementation
class can be loaded from the boot repository, rooted at repository/
by default, the executable jar instantiating MainBootstrapper can be
pretty generic with respect to its Class-Path entries: only geronimo-
kernel plus its dependencies are needed.
ClientCommandLine and Daemon could be refactored to implement the
Main interface MainBootstrapper is looking for. With these changes,
we should be able to move some dependencies from lib/ to repository/
and also uniform the way CLIs are working.
Any concerns if I do these changes?
Thanks,
Gianny
Re: ClientCommandLine and Daemon - Changing boot approach?
Posted by David Jencks <da...@yahoo.com>.
On Mar 7, 2007, at 6:10 AM, Gianny Damour wrote:
> Hi,
>
> Following the introduction of a potentially simpler bootstrapping
> mechanism (currently used by the deployers), we now have an
> opportunity to refactor ClientCommandLine and Daemon to leverage
> this same approach.
>
> The idea of the new bootstrapping mechanism is as follows:
> MainBootstrapper boots a configuration, gets from the Kernel a Main
> implementation and then delegates to it. As the Main implementation
> class can be loaded from the boot repository, rooted at repository/
> by default, the executable jar instantiating MainBootstrapper can
> be pretty generic with respect to its Class-Path entries: only
> geronimo-kernel plus its dependencies are needed.
>
> ClientCommandLine and Daemon could be refactored to implement the
> Main interface MainBootstrapper is looking for. With these changes,
> we should be able to move some dependencies from lib/ to
> repository/ and also uniform the way CLIs are working.
>
> Any concerns if I do these changes?
I think this is a great idea!
thanks
david jencks
>
> Thanks,
> Gianny
Re: ClientCommandLine and Daemon - Changing boot approach?
Posted by Matt Hogstrom <ma...@hogstrom.org>.
I like the approach Gianny ... +1
On Mar 8, 2007, at 8:19 AM, Gianny Damour wrote:
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 0.039 sec
>
> :-)
>
>
> On 09/03/2007, at 12:01 AM, David Jencks wrote:
>
>> This is a test to see if I understand how this will work :-)
>>
>> I think that ClientCommandLine won't be the java main class any
>> more, it will be the class implementing o.a.g. ... Main that the
>> java main class will call after booting a classloader containing
>> geronimo-system.
>>
>> thanks
>> david jencks
>>
>> On Mar 8, 2007, at 7:44 AM, Rakesh Midha wrote:
>>
>>> Hello Gianny
>>>
>>> Oh I got it now, I think this sounds great to me.
>>>
>>> Wait just one more question, how will you use ClientCommandLine,
>>> I mean when geronimo-system is not in lib directory,
>>> ClientCommandLine class will be available for direct access. Are
>>> you sure you can move geronimo-system-2.0-SNAPSHOT.jar out of lib.
>>>
>>> Thanks
>>> Rakesh
>>>
>>> On 3/8/07, Gianny Damour <gianny.damour@optusnet.com.au >
>>> wrote:Hello Rakesh,
>>>
>>> The dependencies which will move out of lib/ are:
>>> backport-util-concurrent-2.2.jar
>>> commons-jexl-1.1.jar
>>> geronimo-common-2.0-SNAPSHOT.jar
>>> geronimo-system-2.0-SNAPSHOT.jar
>>> geronimo-util-2.0-SNAPSHOT.jar
>>> ognl-2.6.9.jar
>>> xstream-1.1.3.jar
>>>
>>> ClientCommandLine and Daemon will still reside in geronimo-system
>>> and
>>> they will implement org.apache.geronimo.kernel.util.Main.
>>>
>>> The offline deployer already uses the same approach we are
>>> suggesting
>>> to apply to ClientCommandLine and Daemon. And it is not impacted by
>>> the change.
>>>
>>> Thanks,
>>> Gianny
>>>
>>> On 08/03/2007, at 1:04 AM, Rakesh Midha wrote:
>>>
>>> > Hello Gianny
>>> >
>>> > Question? What all dependency will you be able to move out of lib
>>> > using this.
>>> >
>>> > Where will ClientCommandLine and Daemon implenting tje
>>> > MainBootstrapper interface will reside.
>>> >
>>> > I am not sure what all advantages will you be able to get out of
>>> > this redistribution. Also any thoughts on effect it may have on
>>> > offline deployer.
>>> >
>>> > Thanks
>>> > Rakesh
>>> >
>>> > On 3/7/07, Gianny Damour <gi...@optusnet.com.au> wrote:
>>> Hi,
>>> >
>>> > Following the introduction of a potentially simpler bootstrapping
>>> > mechanism (currently used by the deployers), we now have an
>>> > opportunity to refactor ClientCommandLine and Daemon to
>>> leverage this
>>> > same approach.
>>> >
>>> > The idea of the new bootstrapping mechanism is as follows:
>>> > MainBootstrapper boots a configuration, gets from the Kernel a
>>> Main
>>> > implementation and then delegates to it. As the Main
>>> implementation
>>> > class can be loaded from the boot repository, rooted at
>>> repository/
>>> > by default, the executable jar instantiating MainBootstrapper
>>> can be
>>> > pretty generic with respect to its Class-Path entries: only
>>> geronimo-
>>> > kernel plus its dependencies are needed.
>>> >
>>> > ClientCommandLine and Daemon could be refactored to implement the
>>> > Main interface MainBootstrapper is looking for. With these
>>> changes,
>>> > we should be able to move some dependencies from lib/ to
>>> repository/
>>> > and also uniform the way CLIs are working.
>>> >
>>> > Any concerns if I do these changes?
>>> >
>>> > Thanks,
>>> > Gianny
>>> >
>>>
>>>
>>
>
>
Re: ClientCommandLine and Daemon - Changing boot approach?
Posted by Gianny Damour <gi...@optusnet.com.au>.
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.039
sec
:-)
On 09/03/2007, at 12:01 AM, David Jencks wrote:
> This is a test to see if I understand how this will work :-)
>
> I think that ClientCommandLine won't be the java main class any
> more, it will be the class implementing o.a.g. ... Main that the
> java main class will call after booting a classloader containing
> geronimo-system.
>
> thanks
> david jencks
>
> On Mar 8, 2007, at 7:44 AM, Rakesh Midha wrote:
>
>> Hello Gianny
>>
>> Oh I got it now, I think this sounds great to me.
>>
>> Wait just one more question, how will you use ClientCommandLine, I
>> mean when geronimo-system is not in lib directory,
>> ClientCommandLine class will be available for direct access. Are
>> you sure you can move geronimo-system-2.0-SNAPSHOT.jar out of lib.
>>
>> Thanks
>> Rakesh
>>
>> On 3/8/07, Gianny Damour <gianny.damour@optusnet.com.au >
>> wrote:Hello Rakesh,
>>
>> The dependencies which will move out of lib/ are:
>> backport-util-concurrent-2.2.jar
>> commons-jexl-1.1.jar
>> geronimo-common-2.0-SNAPSHOT.jar
>> geronimo-system-2.0-SNAPSHOT.jar
>> geronimo-util-2.0-SNAPSHOT.jar
>> ognl-2.6.9.jar
>> xstream-1.1.3.jar
>>
>> ClientCommandLine and Daemon will still reside in geronimo-system and
>> they will implement org.apache.geronimo.kernel.util.Main.
>>
>> The offline deployer already uses the same approach we are suggesting
>> to apply to ClientCommandLine and Daemon. And it is not impacted by
>> the change.
>>
>> Thanks,
>> Gianny
>>
>> On 08/03/2007, at 1:04 AM, Rakesh Midha wrote:
>>
>> > Hello Gianny
>> >
>> > Question? What all dependency will you be able to move out of lib
>> > using this.
>> >
>> > Where will ClientCommandLine and Daemon implenting tje
>> > MainBootstrapper interface will reside.
>> >
>> > I am not sure what all advantages will you be able to get out of
>> > this redistribution. Also any thoughts on effect it may have on
>> > offline deployer.
>> >
>> > Thanks
>> > Rakesh
>> >
>> > On 3/7/07, Gianny Damour <gi...@optusnet.com.au> wrote: Hi,
>> >
>> > Following the introduction of a potentially simpler bootstrapping
>> > mechanism (currently used by the deployers), we now have an
>> > opportunity to refactor ClientCommandLine and Daemon to leverage
>> this
>> > same approach.
>> >
>> > The idea of the new bootstrapping mechanism is as follows:
>> > MainBootstrapper boots a configuration, gets from the Kernel a Main
>> > implementation and then delegates to it. As the Main implementation
>> > class can be loaded from the boot repository, rooted at repository/
>> > by default, the executable jar instantiating MainBootstrapper
>> can be
>> > pretty generic with respect to its Class-Path entries: only
>> geronimo-
>> > kernel plus its dependencies are needed.
>> >
>> > ClientCommandLine and Daemon could be refactored to implement the
>> > Main interface MainBootstrapper is looking for. With these changes,
>> > we should be able to move some dependencies from lib/ to
>> repository/
>> > and also uniform the way CLIs are working.
>> >
>> > Any concerns if I do these changes?
>> >
>> > Thanks,
>> > Gianny
>> >
>>
>>
>
Re: ClientCommandLine and Daemon - Changing boot approach?
Posted by David Jencks <da...@yahoo.com>.
This is a test to see if I understand how this will work :-)
I think that ClientCommandLine won't be the java main class any more,
it will be the class implementing o.a.g. ... Main that the java main
class will call after booting a classloader containing geronimo-system.
thanks
david jencks
On Mar 8, 2007, at 7:44 AM, Rakesh Midha wrote:
> Hello Gianny
>
> Oh I got it now, I think this sounds great to me.
>
> Wait just one more question, how will you use ClientCommandLine, I
> mean when geronimo-system is not in lib directory,
> ClientCommandLine class will be available for direct access. Are
> you sure you can move geronimo-system-2.0-SNAPSHOT.jar out of lib.
>
> Thanks
> Rakesh
>
> On 3/8/07, Gianny Damour <gianny.damour@optusnet.com.au > wrote:
> Hello Rakesh,
>
> The dependencies which will move out of lib/ are:
> backport-util-concurrent-2.2.jar
> commons-jexl-1.1.jar
> geronimo-common-2.0-SNAPSHOT.jar
> geronimo-system-2.0-SNAPSHOT.jar
> geronimo-util-2.0-SNAPSHOT.jar
> ognl-2.6.9.jar
> xstream-1.1.3.jar
>
> ClientCommandLine and Daemon will still reside in geronimo-system and
> they will implement org.apache.geronimo.kernel.util.Main.
>
> The offline deployer already uses the same approach we are suggesting
> to apply to ClientCommandLine and Daemon. And it is not impacted by
> the change.
>
> Thanks,
> Gianny
>
> On 08/03/2007, at 1:04 AM, Rakesh Midha wrote:
>
> > Hello Gianny
> >
> > Question? What all dependency will you be able to move out of lib
> > using this.
> >
> > Where will ClientCommandLine and Daemon implenting tje
> > MainBootstrapper interface will reside.
> >
> > I am not sure what all advantages will you be able to get out of
> > this redistribution. Also any thoughts on effect it may have on
> > offline deployer.
> >
> > Thanks
> > Rakesh
> >
> > On 3/7/07, Gianny Damour <gi...@optusnet.com.au> wrote: Hi,
> >
> > Following the introduction of a potentially simpler bootstrapping
> > mechanism (currently used by the deployers), we now have an
> > opportunity to refactor ClientCommandLine and Daemon to leverage
> this
> > same approach.
> >
> > The idea of the new bootstrapping mechanism is as follows:
> > MainBootstrapper boots a configuration, gets from the Kernel a Main
> > implementation and then delegates to it. As the Main implementation
> > class can be loaded from the boot repository, rooted at repository/
> > by default, the executable jar instantiating MainBootstrapper can be
> > pretty generic with respect to its Class-Path entries: only
> geronimo-
> > kernel plus its dependencies are needed.
> >
> > ClientCommandLine and Daemon could be refactored to implement the
> > Main interface MainBootstrapper is looking for. With these changes,
> > we should be able to move some dependencies from lib/ to repository/
> > and also uniform the way CLIs are working.
> >
> > Any concerns if I do these changes?
> >
> > Thanks,
> > Gianny
> >
>
>
Re: ClientCommandLine and Daemon - Changing boot approach?
Posted by Rakesh Midha <mi...@gmail.com>.
Hello Gianny
Oh I got it now, I think this sounds great to me.
Wait just one more question, how will you use ClientCommandLine, I mean when
geronimo-system is not in lib directory, ClientCommandLine class will be
available for direct access. Are you sure you can move
geronimo-system-2.0-SNAPSHOT.jar out of lib.
Thanks
Rakesh
On 3/8/07, Gianny Damour <gi...@optusnet.com.au> wrote:
>
> Hello Rakesh,
>
> The dependencies which will move out of lib/ are:
> backport-util-concurrent-2.2.jar
> commons-jexl-1.1.jar
> geronimo-common-2.0-SNAPSHOT.jar
> geronimo-system-2.0-SNAPSHOT.jar
> geronimo-util-2.0-SNAPSHOT.jar
> ognl-2.6.9.jar
> xstream-1.1.3.jar
>
> ClientCommandLine and Daemon will still reside in geronimo-system and
> they will implement org.apache.geronimo.kernel.util.Main.
>
> The offline deployer already uses the same approach we are suggesting
> to apply to ClientCommandLine and Daemon. And it is not impacted by
> the change.
>
> Thanks,
> Gianny
>
> On 08/03/2007, at 1:04 AM, Rakesh Midha wrote:
>
> > Hello Gianny
> >
> > Question? What all dependency will you be able to move out of lib
> > using this.
> >
> > Where will ClientCommandLine and Daemon implenting tje
> > MainBootstrapper interface will reside.
> >
> > I am not sure what all advantages will you be able to get out of
> > this redistribution. Also any thoughts on effect it may have on
> > offline deployer.
> >
> > Thanks
> > Rakesh
> >
> > On 3/7/07, Gianny Damour <gi...@optusnet.com.au> wrote: Hi,
> >
> > Following the introduction of a potentially simpler bootstrapping
> > mechanism (currently used by the deployers), we now have an
> > opportunity to refactor ClientCommandLine and Daemon to leverage this
> > same approach.
> >
> > The idea of the new bootstrapping mechanism is as follows:
> > MainBootstrapper boots a configuration, gets from the Kernel a Main
> > implementation and then delegates to it. As the Main implementation
> > class can be loaded from the boot repository, rooted at repository/
> > by default, the executable jar instantiating MainBootstrapper can be
> > pretty generic with respect to its Class-Path entries: only geronimo-
> > kernel plus its dependencies are needed.
> >
> > ClientCommandLine and Daemon could be refactored to implement the
> > Main interface MainBootstrapper is looking for. With these changes,
> > we should be able to move some dependencies from lib/ to repository/
> > and also uniform the way CLIs are working.
> >
> > Any concerns if I do these changes?
> >
> > Thanks,
> > Gianny
> >
>
>
Re: ClientCommandLine and Daemon - Changing boot approach?
Posted by Gianny Damour <gi...@optusnet.com.au>.
Hello Rakesh,
The dependencies which will move out of lib/ are:
backport-util-concurrent-2.2.jar
commons-jexl-1.1.jar
geronimo-common-2.0-SNAPSHOT.jar
geronimo-system-2.0-SNAPSHOT.jar
geronimo-util-2.0-SNAPSHOT.jar
ognl-2.6.9.jar
xstream-1.1.3.jar
ClientCommandLine and Daemon will still reside in geronimo-system and
they will implement org.apache.geronimo.kernel.util.Main.
The offline deployer already uses the same approach we are suggesting
to apply to ClientCommandLine and Daemon. And it is not impacted by
the change.
Thanks,
Gianny
On 08/03/2007, at 1:04 AM, Rakesh Midha wrote:
> Hello Gianny
>
> Question? What all dependency will you be able to move out of lib
> using this.
>
> Where will ClientCommandLine and Daemon implenting tje
> MainBootstrapper interface will reside.
>
> I am not sure what all advantages will you be able to get out of
> this redistribution. Also any thoughts on effect it may have on
> offline deployer.
>
> Thanks
> Rakesh
>
> On 3/7/07, Gianny Damour <gi...@optusnet.com.au> wrote: Hi,
>
> Following the introduction of a potentially simpler bootstrapping
> mechanism (currently used by the deployers), we now have an
> opportunity to refactor ClientCommandLine and Daemon to leverage this
> same approach.
>
> The idea of the new bootstrapping mechanism is as follows:
> MainBootstrapper boots a configuration, gets from the Kernel a Main
> implementation and then delegates to it. As the Main implementation
> class can be loaded from the boot repository, rooted at repository/
> by default, the executable jar instantiating MainBootstrapper can be
> pretty generic with respect to its Class-Path entries: only geronimo-
> kernel plus its dependencies are needed.
>
> ClientCommandLine and Daemon could be refactored to implement the
> Main interface MainBootstrapper is looking for. With these changes,
> we should be able to move some dependencies from lib/ to repository/
> and also uniform the way CLIs are working.
>
> Any concerns if I do these changes?
>
> Thanks,
> Gianny
>
Re: ClientCommandLine and Daemon - Changing boot approach?
Posted by Rakesh Midha <mi...@gmail.com>.
Hello Gianny
Question? What all dependency will you be able to move out of lib using
this.
Where will ClientCommandLine and Daemon implenting tje MainBootstrapper
interface will reside.
I am not sure what all advantages will you be able to get out of this
redistribution. Also any thoughts on effect it may have on offline deployer.
Thanks
Rakesh
On 3/7/07, Gianny Damour <gi...@optusnet.com.au> wrote:
>
> Hi,
>
> Following the introduction of a potentially simpler bootstrapping
> mechanism (currently used by the deployers), we now have an
> opportunity to refactor ClientCommandLine and Daemon to leverage this
> same approach.
>
> The idea of the new bootstrapping mechanism is as follows:
> MainBootstrapper boots a configuration, gets from the Kernel a Main
> implementation and then delegates to it. As the Main implementation
> class can be loaded from the boot repository, rooted at repository/
> by default, the executable jar instantiating MainBootstrapper can be
> pretty generic with respect to its Class-Path entries: only geronimo-
> kernel plus its dependencies are needed.
>
> ClientCommandLine and Daemon could be refactored to implement the
> Main interface MainBootstrapper is looking for. With these changes,
> we should be able to move some dependencies from lib/ to repository/
> and also uniform the way CLIs are working.
>
> Any concerns if I do these changes?
>
> Thanks,
> Gianny
>