geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: ClientCommandLine and Daemon - Changing boot approach?
Date Fri, 09 Mar 2007 03:41:31 GMT
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 <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