geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <gianny.dam...@optusnet.com.au>
Subject Re: ClientCommandLine and Daemon - Changing boot approach?
Date Thu, 08 Mar 2007 13:19:46 GMT
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 <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