geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rakesh Midha" <midha.rak...@gmail.com>
Subject Re: ClientCommandLine and Daemon - Changing boot approach?
Date Thu, 08 Mar 2007 12:44:29 GMT
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 <gianny.damour@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
> >
>
>

Mime
View raw message