Re: ClientCommandLine and Daemon - Changing boot approach?
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 [EMAIL PROTECTED] 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?
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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?
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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?
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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?
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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?
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?
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 [EMAIL PROTECTED] 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
