Re: Loading commands from classpath
68 views
Skip to first unread message
Julien Viet
May 11, 2014, 5:20:54 AM5/11/14
to crash...@googlegroups.com
Can you tell me the values of the String[] args in your case ?
Julien Viet
julienviet.com
On Saturday 10 May 2014 at 20:58, Curt Beattie wrote:
> The following class does almost exactly what I want, except I need it to load the commands from the classpath rather than from the file system. However I can't for the life of me figure out how to do this.
>
> public class MyMain {
> public static void main(String[] args) throws Exception {
> CRaSH.main(args);
> }
> }
>
> Some help would be appreciated.
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (mailto:crash-users...@googlegroups.com).
> Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
Julien Viet
julienviet.com
On Saturday 10 May 2014 at 20:58, Curt Beattie wrote:
> The following class does almost exactly what I want, except I need it to load the commands from the classpath rather than from the file system. However I can't for the life of me figure out how to do this.
>
> public class MyMain {
> public static void main(String[] args) throws Exception {
> CRaSH.main(args);
> }
> }
>
> Some help would be appreciated.
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (mailto:crash-users...@googlegroups.com).
> Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
Benny Lutati
May 15, 2014, 4:59:54 PM5/15/14
to crash...@googlegroups.com
Hello,
I am also new to CRaSH (started looking at it today), and I wanted to achieve exactly what you wanted,
I wanted to be able to embed CRaSH into my java application (no spring, webserver, etc. just plain old java app) and in order for it to be useful I needed
to add commands that directly modify the state of my application - this means that the commands needed to reside inside my application jar.
After reading the source code I came out with the following way:
Field systemCommandsField = org.crsh.shell.impl.command.CRaSH.class.getDeclaredField("systemCommands");
systemCommandsField.setAccessible(true);
if (systemCommandsField == null) throw new UnsupportedOperationException("PANIC - CRaSH IMPLEMENTATION CHANGE!");
HashMap<String, Class<? extends BaseCommand>> systemCommands = (HashMap) systemCommandsField.get(null);
Reflections r = new Reflections("commands.package.here", new SubTypesScanner());
for (Class<? extends BaseCommand> c : r.getSubTypesOf(BaseCommand.class)){
systemCommands.put(c.getSimpleName(), c);
}
CRaSH.main(args);
*note that i use the Reflections library which allows me to scan my classpath in order to find all the subtypes of BaseCommand that resides in a given package.
It works BUT I am not sure that this is the right way to do so and will be very happy if someone will suggest a "less hackish" way..
Benny.
On Sunday, May 11, 2014 12:20:54 PM UTC+3, Julien Viet wrote:
Can you tell me the values of the String[] args in your case ?
Julien Viet
julienviet.com
On Saturday 10 May 2014 at 20:58, Curt Beattie wrote:
> The following class does almost exactly what I want, except I need it to load the commands from the classpath rather than from the file system. However I can't for the life of me figure out how to do this.
>
> public class MyMain {
> public static void main(String[] args) throws Exception {
> CRaSH.main(args);
> }
> }
>
> Some help would be appreciated.
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (mailto:crash-users+unsub...@googlegroups.com).
Julien Viet
May 15, 2014, 5:30:22 PM5/15/14
to crash...@googlegroups.com
Hi,
two comments:
1/ there will be at least one option to achieve something like this in the near future
https://jira.exoplatform.org/browse/CRASH-185
In your case you would set the “command path” to “classpath:/commands/crash/;classpath:/commands/package/here/“ which aggregates the classic CRaSH commands and also your package. Note that will work with source files and your command will be compiled on the fly by CRaSH at the moment it is loaded.
This would work with classpath, file and war (the content of the war file). The goal of this feature is to remove the default path “hardcoded” in CRaSH.
This feature will be done very soon (next monday I hope).
2/ I see you are hacking the system commands. Those are commands that should be *always there* like “help” or “repl”. They are precompiled (so written in Java) and therefore at the moment added manually in the systemCommands field.
It makes sense to me to allow people to augment the set of system commands to further more customize CRaSH. The java.util.ServiceLoader extension mechanism could be used to allow this, so you would have to declare your BaseCommand subclasses in a META-INF/services/org.crsh.command.BaseCommand file.
Unless I’m wrong, this feature would be quite trivial to add and not much work.
what do you think ?
Julien Viet
julienviet.com
On Thursday 15 May 2014 at 22:59, Benny Lutati wrote:
> Hello,
> I am also new to CRaSH (started looking at it today), and I wanted to achieve exactly what you wanted,
> I wanted to be able to embed CRaSH into my java application (no spring, webserver, etc. just plain old java app) and in order for it to be useful I needed
> to add commands that directly modify the state of my application - this means that the commands needed to reside inside my application jar.
>
> After reading the source code I came out with the following way:
>
> Field systemCommandsField = org.crsh.shell.impl.command.CRaSH.class.getDeclaredField("systemCommands");
> systemCommandsField.setAccessible(true);
> if (systemCommandsField == null) throw new UnsupportedOperationException("PANIC - CRaSH IMPLEMENTATION CHANGE!");
> HashMap<String, Class<? extends BaseCommand>> systemCommands = (HashMap) systemCommandsField.get(null);
>
> Reflections r = new Reflections("commands.package.here", new SubTypesScanner());
> for (Class<? extends BaseCommand> c : r.getSubTypesOf(BaseCommand.class)){
> systemCommands.put(c.getSimpleName(), c);
> }
>
> CRaSH.main(args);
>
>
> *note that i use the Reflections (https://github.com/ronmamo/reflections) library which allows me to scan my classpath in order to find all the subtypes of BaseCommand that resides in a given package.
two comments:
1/ there will be at least one option to achieve something like this in the near future
https://jira.exoplatform.org/browse/CRASH-185
In your case you would set the “command path” to “classpath:/commands/crash/;classpath:/commands/package/here/“ which aggregates the classic CRaSH commands and also your package. Note that will work with source files and your command will be compiled on the fly by CRaSH at the moment it is loaded.
This would work with classpath, file and war (the content of the war file). The goal of this feature is to remove the default path “hardcoded” in CRaSH.
This feature will be done very soon (next monday I hope).
2/ I see you are hacking the system commands. Those are commands that should be *always there* like “help” or “repl”. They are precompiled (so written in Java) and therefore at the moment added manually in the systemCommands field.
It makes sense to me to allow people to augment the set of system commands to further more customize CRaSH. The java.util.ServiceLoader extension mechanism could be used to allow this, so you would have to declare your BaseCommand subclasses in a META-INF/services/org.crsh.command.BaseCommand file.
Unless I’m wrong, this feature would be quite trivial to add and not much work.
what do you think ?
Julien Viet
julienviet.com
On Thursday 15 May 2014 at 22:59, Benny Lutati wrote:
> Hello,
> I am also new to CRaSH (started looking at it today), and I wanted to achieve exactly what you wanted,
> I wanted to be able to embed CRaSH into my java application (no spring, webserver, etc. just plain old java app) and in order for it to be useful I needed
> to add commands that directly modify the state of my application - this means that the commands needed to reside inside my application jar.
>
> After reading the source code I came out with the following way:
>
> Field systemCommandsField = org.crsh.shell.impl.command.CRaSH.class.getDeclaredField("systemCommands");
> systemCommandsField.setAccessible(true);
> if (systemCommandsField == null) throw new UnsupportedOperationException("PANIC - CRaSH IMPLEMENTATION CHANGE!");
> HashMap<String, Class<? extends BaseCommand>> systemCommands = (HashMap) systemCommandsField.get(null);
>
> Reflections r = new Reflections("commands.package.here", new SubTypesScanner());
> for (Class<? extends BaseCommand> c : r.getSubTypesOf(BaseCommand.class)){
> systemCommands.put(c.getSimpleName(), c);
> }
>
> CRaSH.main(args);
>
>
>
> It works BUT I am not sure that this is the right way to do so and will be very happy if someone will suggest a "less hackish" way..
>
> Benny.
>
> On Sunday, May 11, 2014 12:20:54 PM UTC+3, Julien Viet wrote:
> > Can you tell me the values of the String[] args in your case ?
> >
> >
> > Julien Viet
> > julienviet.com (http://julienviet.com)
> It works BUT I am not sure that this is the right way to do so and will be very happy if someone will suggest a "less hackish" way..
>
> Benny.
>
> On Sunday, May 11, 2014 12:20:54 PM UTC+3, Julien Viet wrote:
> > Can you tell me the values of the String[] args in your case ?
> >
> >
> > Julien Viet
> >
> >
> > On Saturday 10 May 2014 at 20:58, Curt Beattie wrote:
> >
> > > The following class does almost exactly what I want, except I need it to load the commands from the classpath rather than from the file system. However I can't for the life of me figure out how to do this.
> > >
> > > public class MyMain {
> > > public static void main(String[] args) throws Exception {
> > > CRaSH.main(args);
> > > }
> > > }
> > >
> > > Some help would be appreciated.
> > >
> > > --
> > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users...@googlegroups.com (javascript:)).
> >
> > On Saturday 10 May 2014 at 20:58, Curt Beattie wrote:
> >
> > > The following class does almost exactly what I want, except I need it to load the commands from the classpath rather than from the file system. However I can't for the life of me figure out how to do this.
> > >
> > > public class MyMain {
> > > public static void main(String[] args) throws Exception {
> > > CRaSH.main(args);
> > > }
> > > }
> > >
> > > Some help would be appreciated.
> > >
> > > --
> > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (mailto:crash-users...@googlegroups.com).
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
Benny Lutati
May 15, 2014, 5:45:26 PM5/15/14
to crash...@googlegroups.com
Hi, thank you for the fast response!
regards the second comment - I still not fully understand what plugins can and cannot do - but for me it looks like it would be
a great option to be able to add some sort of a "commands supplier plugin" - this way one will be able to create such a plugin that will automatically generate commands based on the application it attached on (this is what I am working on currently and why i needed to hack the system commands.. )
Benny.
> > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users+unsub...@googlegroups.com (javascript:)).
> > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> >
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (mailto:crash-users+unsub...@googlegroups.com).
Julien Viet
May 15, 2014, 6:26:23 PM5/15/14
to crash...@googlegroups.com
Basically you would just have to declare your commands in a text file in your jar file.
so if you have
package foo;
public class mycommand extends BaseCommand {
...
}
this command would be declared in a META-INF/services/org.crsh.command.BaseCommand file in the same jar:
“foo.mycommand"
This can contain as many implementations as you need.
As far as I can think, it should fit your needs, shouldn’t it ?
Julien Viet
julienviet.com
On Thursday 15 May 2014 at 23:45, Benny Lutati wrote:
> Hi, thank you for the fast response!
>
> regards the second comment - I still not fully understand what plugins can and cannot do - but for me it looks like it would be
> a great option to be able to add some sort of a "commands supplier plugin" - this way one will be able to create such a plugin that will automatically generate commands based on the application it attached on (this is what I am working on currently and why i needed to hack the system commands.. )
>
> Benny.
> On Friday, May 16, 2014 12:30:22 AM UTC+3, Julien Viet wrote:
> > Hi,
> >
> > two comments:
> >
> > 1/ there will be at least one option to achieve something like this in the near future
> >
> > https://jira.exoplatform.org/browse/CRASH-185
> >
> > In your case you would set the “command path” to “classpath:/commands/crash/;classpath:/commands/package/here/“ which aggregates the classic CRaSH commands and also your package. Note that will work with source files and your command will be compiled on the fly by CRaSH at the moment it is loaded.
> >
> > This would work with classpath, file and war (the content of the war file). The goal of this feature is to remove the default path “hardcoded” in CRaSH.
> >
> > This feature will be done very soon (next monday I hope).
> >
> > 2/ I see you are hacking the system commands. Those are commands that should be *always there* like “help” or “repl”. They are precompiled (so written in Java) and therefore at the moment added manually in the systemCommands field.
> >
> > It makes sense to me to allow people to augment the set of system commands to further more customize CRaSH. The java.util.ServiceLoader extension mechanism could be used to allow this, so you would have to declare your BaseCommand subclasses in a META-INF/services/org.crsh.command.BaseCommand file.
> >
> > Unless I’m wrong, this feature would be quite trivial to add and not much work.
> >
> > what do you think ?
> >
> > Julien Viet
> > julienviet.com (http://julienviet.com)
so if you have
package foo;
public class mycommand extends BaseCommand {
...
}
this command would be declared in a META-INF/services/org.crsh.command.BaseCommand file in the same jar:
“foo.mycommand"
This can contain as many implementations as you need.
As far as I can think, it should fit your needs, shouldn’t it ?
Julien Viet
julienviet.com
On Thursday 15 May 2014 at 23:45, Benny Lutati wrote:
> Hi, thank you for the fast response!
>
> regards the second comment - I still not fully understand what plugins can and cannot do - but for me it looks like it would be
> a great option to be able to add some sort of a "commands supplier plugin" - this way one will be able to create such a plugin that will automatically generate commands based on the application it attached on (this is what I am working on currently and why i needed to hack the system commands.. )
>
> Benny.
> On Friday, May 16, 2014 12:30:22 AM UTC+3, Julien Viet wrote:
> > Hi,
> >
> > two comments:
> >
> > 1/ there will be at least one option to achieve something like this in the near future
> >
> > https://jira.exoplatform.org/browse/CRASH-185
> >
> > In your case you would set the “command path” to “classpath:/commands/crash/;classpath:/commands/package/here/“ which aggregates the classic CRaSH commands and also your package. Note that will work with source files and your command will be compiled on the fly by CRaSH at the moment it is loaded.
> >
> > This would work with classpath, file and war (the content of the war file). The goal of this feature is to remove the default path “hardcoded” in CRaSH.
> >
> > This feature will be done very soon (next monday I hope).
> >
> > 2/ I see you are hacking the system commands. Those are commands that should be *always there* like “help” or “repl”. They are precompiled (so written in Java) and therefore at the moment added manually in the systemCommands field.
> >
> > It makes sense to me to allow people to augment the set of system commands to further more customize CRaSH. The java.util.ServiceLoader extension mechanism could be used to allow this, so you would have to declare your BaseCommand subclasses in a META-INF/services/org.crsh.command.BaseCommand file.
> >
> > Unless I’m wrong, this feature would be quite trivial to add and not much work.
> >
> > what do you think ?
> >
> > Julien Viet
> >
> >
> > On Thursday 15 May 2014 at 22:59, Benny Lutati wrote:
> >
> > > Hello,
> > > I am also new to CRaSH (started looking at it today), and I wanted to achieve exactly what you wanted,
> > > I wanted to be able to embed CRaSH into my java application (no spring, webserver, etc. just plain old java app) and in order for it to be useful I needed
> > > to add commands that directly modify the state of my application - this means that the commands needed to reside inside my application jar.
> > >
> > > After reading the source code I came out with the following way:
> > >
> > > Field systemCommandsField = org.crsh.shell.impl.command.CRaSH.class.getDeclaredField("systemCommands");
> > > systemCommandsField.setAccessible(true);
> > > if (systemCommandsField == null) throw new UnsupportedOperationException("PANIC - CRaSH IMPLEMENTATION CHANGE!");
> > > HashMap<String, Class<? extends BaseCommand>> systemCommands = (HashMap) systemCommandsField.get(null);
> > >
> > > Reflections r = new Reflections("commands.package.here", new SubTypesScanner());
> > > for (Class<? extends BaseCommand> c : r.getSubTypesOf(BaseCommand.class)){
> > > systemCommands.put(c.getSimpleName(), c);
> > > }
> > >
> > > CRaSH.main(args);
> > >
> > >
> > > *note that i use the Reflections (https://github.com/ronmamo/reflections) library which allows me to scan my classpath in order to find all the subtypes of BaseCommand that resides in a given package.
> > >
> > > It works BUT I am not sure that this is the right way to do so and will be very happy if someone will suggest a "less hackish" way..
> > >
> > > Benny.
> > >
> > > On Sunday, May 11, 2014 12:20:54 PM UTC+3, Julien Viet wrote:
> > > > Can you tell me the values of the String[] args in your case ?
> > > >
> > > >
> > > > Julien Viet
> > > > julienviet.com (http://julienviet.com) (http://julienviet.com)
> >
> > On Thursday 15 May 2014 at 22:59, Benny Lutati wrote:
> >
> > > Hello,
> > > I am also new to CRaSH (started looking at it today), and I wanted to achieve exactly what you wanted,
> > > I wanted to be able to embed CRaSH into my java application (no spring, webserver, etc. just plain old java app) and in order for it to be useful I needed
> > > to add commands that directly modify the state of my application - this means that the commands needed to reside inside my application jar.
> > >
> > > After reading the source code I came out with the following way:
> > >
> > > Field systemCommandsField = org.crsh.shell.impl.command.CRaSH.class.getDeclaredField("systemCommands");
> > > systemCommandsField.setAccessible(true);
> > > if (systemCommandsField == null) throw new UnsupportedOperationException("PANIC - CRaSH IMPLEMENTATION CHANGE!");
> > > HashMap<String, Class<? extends BaseCommand>> systemCommands = (HashMap) systemCommandsField.get(null);
> > >
> > > Reflections r = new Reflections("commands.package.here", new SubTypesScanner());
> > > for (Class<? extends BaseCommand> c : r.getSubTypesOf(BaseCommand.class)){
> > > systemCommands.put(c.getSimpleName(), c);
> > > }
> > >
> > > CRaSH.main(args);
> > >
> > >
> > > *note that i use the Reflections (https://github.com/ronmamo/reflections) library which allows me to scan my classpath in order to find all the subtypes of BaseCommand that resides in a given package.
> > >
> > > It works BUT I am not sure that this is the right way to do so and will be very happy if someone will suggest a "less hackish" way..
> > >
> > > Benny.
> > >
> > > On Sunday, May 11, 2014 12:20:54 PM UTC+3, Julien Viet wrote:
> > > > Can you tell me the values of the String[] args in your case ?
> > > >
> > > >
> > > > Julien Viet
> > > >
> > > >
> > > > On Saturday 10 May 2014 at 20:58, Curt Beattie wrote:
> > > >
> > > > > The following class does almost exactly what I want, except I need it to load the commands from the classpath rather than from the file system. However I can't for the life of me figure out how to do this.
> > > > >
> > > > > public class MyMain {
> > > > > public static void main(String[] args) throws Exception {
> > > > > CRaSH.main(args);
> > > > > }
> > > > > }
> > > > >
> > > > > Some help would be appreciated.
> > > > >
> > > > > --
> > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users...@googlegroups.com (javascript:) (javascript:)).
> > > >
> > > > On Saturday 10 May 2014 at 20:58, Curt Beattie wrote:
> > > >
> > > > > The following class does almost exactly what I want, except I need it to load the commands from the classpath rather than from the file system. However I can't for the life of me figure out how to do this.
> > > > >
> > > > > public class MyMain {
> > > > > public static void main(String[] args) throws Exception {
> > > > > CRaSH.main(args);
> > > > > }
> > > > > }
> > > > >
> > > > > Some help would be appreciated.
> > > > >
> > > > > --
> > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > > >
> > > >
> > >
> > >
> > > --
> > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users...@googlegroups.com (javascript:)).
> > > >
> > > >
> > >
> > >
> > > --
> > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> >
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (mailto:crash-users...@googlegroups.com).
> >
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
Julien Viet
May 15, 2014, 6:30:54 PM5/15/14
to crash...@googlegroups.com
that being said, the idea of supplier plugin could also be used and the actual system that compiles commands would be also a supplier.
currently this is done in the org.crsh.shell.impl.command.CRaSH class with the CommandManager and such.
This code would be extracted and encapsulated into a command supplier, allowing other suppliers to do the same.
Julien Viet
julienviet.com
On Friday 16 May 2014 at 00:26, Julien Viet wrote:
> Basically you would just have to declare your commands in a text file in your jar file.
>
> so if you have
>
> package foo;
> public class mycommand extends BaseCommand {
> ...
> }
>
> this command would be declared in a META-INF/services/org.crsh.command.BaseCommand file in the same jar:
>
> “foo.mycommand"
>
> This can contain as many implementations as you need.
>
> As far as I can think, it should fit your needs, shouldn’t it ?
>
> Julien Viet
currently this is done in the org.crsh.shell.impl.command.CRaSH class with the CommandManager and such.
This code would be extracted and encapsulated into a command supplier, allowing other suppliers to do the same.
Julien Viet
julienviet.com
On Friday 16 May 2014 at 00:26, Julien Viet wrote:
> Basically you would just have to declare your commands in a text file in your jar file.
>
> so if you have
>
> package foo;
> public class mycommand extends BaseCommand {
> ...
> }
>
> this command would be declared in a META-INF/services/org.crsh.command.BaseCommand file in the same jar:
>
> “foo.mycommand"
>
> This can contain as many implementations as you need.
>
> As far as I can think, it should fit your needs, shouldn’t it ?
>
> Julien Viet
Benny Lutati
May 15, 2014, 6:54:01 PM5/15/14
to crash...@googlegroups.com
For my use case it will be unfeasible to list the commands ahead of time - let me explain what i am trying to achieve
I am running a "standalone" shell from within my program
before execution of the shell I am scanning my packages and looking for singleton controllers (annotated classes)
for each such controller i am generating on the fly (using reflectasm) instances of "git style" commands with sub commands reflecting some public functions of that controller.
than I am using the systemcommands hack to inject these commands into the shell - and finally when all done i am starting the shell
that gives me a very powerful shell that is automatically customized to any of my programs and allows me to debug/automate stuff..
this is why i think that the supplier plugin can be very powerful addition - but this is only my opinion..
Benny.
> > > > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users+unsub...@googlegroups.com (javascript:) (javascript:)).
> > > > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users+unsub...@googlegroups.com (javascript:)).
> > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > >
> >
> >
> >
> > --
> > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (mailto:crash-users+unsub...@googlegroups.com).
Julien Viet
May 16, 2014, 2:49:14 AM5/16/14
to crash...@googlegroups.com
I see, so I think we can go with some “command provider” interface and retrofit the current dynamic command system of crash as one provider among others.
Julien Viet
julienviet.com
On Friday 16 May 2014 at 00:54, Benny Lutati wrote:
> For my use case it will be unfeasible to list the commands ahead of time - let me explain what i am trying to achieve
>
> I am running a "standalone" shell from within my program
> before execution of the shell I am scanning my packages and looking for singleton controllers (annotated classes)
> for each such controller i am generating on the fly (using reflectasm) instances of "git style" commands with sub commands reflecting some public functions of that controller.
> than I am using the systemcommands hack to inject these commands into the shell - and finally when all done i am starting the shell
>
> that gives me a very powerful shell that is automatically customized to any of my programs and allows me to debug/automate stuff..
> this is why i think that the supplier plugin can be very powerful addition - but this is only my opinion..
>
> Benny.
>
>
> On Friday, May 16, 2014 1:30:54 AM UTC+3, Julien Viet wrote:
> > that being said, the idea of supplier plugin could also be used and the actual system that compiles commands would be also a supplier.
> >
> > currently this is done in the org.crsh.shell.impl.command.CRaSH class with the CommandManager and such.
> >
> > This code would be extracted and encapsulated into a command supplier, allowing other suppliers to do the same.
> >
> > Julien Viet
> > julienviet.com (http://julienviet.com)
Julien Viet
julienviet.com
On Friday 16 May 2014 at 00:54, Benny Lutati wrote:
> For my use case it will be unfeasible to list the commands ahead of time - let me explain what i am trying to achieve
>
> I am running a "standalone" shell from within my program
> before execution of the shell I am scanning my packages and looking for singleton controllers (annotated classes)
> for each such controller i am generating on the fly (using reflectasm) instances of "git style" commands with sub commands reflecting some public functions of that controller.
> than I am using the systemcommands hack to inject these commands into the shell - and finally when all done i am starting the shell
>
> that gives me a very powerful shell that is automatically customized to any of my programs and allows me to debug/automate stuff..
> this is why i think that the supplier plugin can be very powerful addition - but this is only my opinion..
>
> Benny.
>
>
> On Friday, May 16, 2014 1:30:54 AM UTC+3, Julien Viet wrote:
> > that being said, the idea of supplier plugin could also be used and the actual system that compiles commands would be also a supplier.
> >
> > currently this is done in the org.crsh.shell.impl.command.CRaSH class with the CommandManager and such.
> >
> > This code would be extracted and encapsulated into a command supplier, allowing other suppliers to do the same.
> >
> > Julien Viet
> >
> >
> > On Friday 16 May 2014 at 00:26, Julien Viet wrote:
> >
> > > Basically you would just have to declare your commands in a text file in your jar file.
> > >
> > > so if you have
> > >
> > > package foo;
> > > public class mycommand extends BaseCommand {
> > > ...
> > > }
> > >
> > > this command would be declared in a META-INF/services/org.crsh.command.BaseCommand file in the same jar:
> > >
> > > “foo.mycommand"
> > >
> > > This can contain as many implementations as you need.
> > >
> > > As far as I can think, it should fit your needs, shouldn’t it ?
> > >
> > > Julien Viet
> > > julienviet.com (http://julienviet.com) (http://julienviet.com)
> >
> > On Friday 16 May 2014 at 00:26, Julien Viet wrote:
> >
> > > Basically you would just have to declare your commands in a text file in your jar file.
> > >
> > > so if you have
> > >
> > > package foo;
> > > public class mycommand extends BaseCommand {
> > > ...
> > > }
> > >
> > > this command would be declared in a META-INF/services/org.crsh.command.BaseCommand file in the same jar:
> > >
> > > “foo.mycommand"
> > >
> > > This can contain as many implementations as you need.
> > >
> > > As far as I can think, it should fit your needs, shouldn’t it ?
> > >
> > > Julien Viet
> > >
> > >
> > > On Thursday 15 May 2014 at 23:45, Benny Lutati wrote:
> > >
> > > > Hi, thank you for the fast response!
> > > >
> > > > regards the second comment - I still not fully understand what plugins can and cannot do - but for me it looks like it would be
> > > > a great option to be able to add some sort of a "commands supplier plugin" - this way one will be able to create such a plugin that will automatically generate commands based on the application it attached on (this is what I am working on currently and why i needed to hack the system commands.. )
> > > >
> > > > Benny.
> > > > On Friday, May 16, 2014 12:30:22 AM UTC+3, Julien Viet wrote:
> > > > > Hi,
> > > > >
> > > > > two comments:
> > > > >
> > > > > 1/ there will be at least one option to achieve something like this in the near future
> > > > >
> > > > > https://jira.exoplatform.org/browse/CRASH-185
> > > > >
> > > > > In your case you would set the “command path” to “classpath:/commands/crash/;classpath:/commands/package/here/“ which aggregates the classic CRaSH commands and also your package. Note that will work with source files and your command will be compiled on the fly by CRaSH at the moment it is loaded.
> > > > >
> > > > > This would work with classpath, file and war (the content of the war file). The goal of this feature is to remove the default path “hardcoded” in CRaSH.
> > > > >
> > > > > This feature will be done very soon (next monday I hope).
> > > > >
> > > > > 2/ I see you are hacking the system commands. Those are commands that should be *always there* like “help” or “repl”. They are precompiled (so written in Java) and therefore at the moment added manually in the systemCommands field.
> > > > >
> > > > > It makes sense to me to allow people to augment the set of system commands to further more customize CRaSH. The java.util.ServiceLoader extension mechanism could be used to allow this, so you would have to declare your BaseCommand subclasses in a META-INF/services/org.crsh.command.BaseCommand file.
> > > > >
> > > > > Unless I’m wrong, this feature would be quite trivial to add and not much work.
> > > > >
> > > > > what do you think ?
> > > > >
> > > > > Julien Viet
> > > > > julienviet.com (http://julienviet.com) (http://julienviet.com)
> > >
> > > On Thursday 15 May 2014 at 23:45, Benny Lutati wrote:
> > >
> > > > Hi, thank you for the fast response!
> > > >
> > > > regards the second comment - I still not fully understand what plugins can and cannot do - but for me it looks like it would be
> > > > a great option to be able to add some sort of a "commands supplier plugin" - this way one will be able to create such a plugin that will automatically generate commands based on the application it attached on (this is what I am working on currently and why i needed to hack the system commands.. )
> > > >
> > > > Benny.
> > > > On Friday, May 16, 2014 12:30:22 AM UTC+3, Julien Viet wrote:
> > > > > Hi,
> > > > >
> > > > > two comments:
> > > > >
> > > > > 1/ there will be at least one option to achieve something like this in the near future
> > > > >
> > > > > https://jira.exoplatform.org/browse/CRASH-185
> > > > >
> > > > > In your case you would set the “command path” to “classpath:/commands/crash/;classpath:/commands/package/here/“ which aggregates the classic CRaSH commands and also your package. Note that will work with source files and your command will be compiled on the fly by CRaSH at the moment it is loaded.
> > > > >
> > > > > This would work with classpath, file and war (the content of the war file). The goal of this feature is to remove the default path “hardcoded” in CRaSH.
> > > > >
> > > > > This feature will be done very soon (next monday I hope).
> > > > >
> > > > > 2/ I see you are hacking the system commands. Those are commands that should be *always there* like “help” or “repl”. They are precompiled (so written in Java) and therefore at the moment added manually in the systemCommands field.
> > > > >
> > > > > It makes sense to me to allow people to augment the set of system commands to further more customize CRaSH. The java.util.ServiceLoader extension mechanism could be used to allow this, so you would have to declare your BaseCommand subclasses in a META-INF/services/org.crsh.command.BaseCommand file.
> > > > >
> > > > > Unless I’m wrong, this feature would be quite trivial to add and not much work.
> > > > >
> > > > > what do you think ?
> > > > >
> > > > > Julien Viet
> > > > >
> > > > >
> > > > > On Thursday 15 May 2014 at 22:59, Benny Lutati wrote:
> > > > >
> > > > > > Hello,
> > > > > > I am also new to CRaSH (started looking at it today), and I wanted to achieve exactly what you wanted,
> > > > > > I wanted to be able to embed CRaSH into my java application (no spring, webserver, etc. just plain old java app) and in order for it to be useful I needed
> > > > > > to add commands that directly modify the state of my application - this means that the commands needed to reside inside my application jar.
> > > > > >
> > > > > > After reading the source code I came out with the following way:
> > > > > >
> > > > > > Field systemCommandsField = org.crsh.shell.impl.command.CRaSH.class.getDeclaredField("systemCommands");
> > > > > > systemCommandsField.setAccessible(true);
> > > > > > if (systemCommandsField == null) throw new UnsupportedOperationException("PANIC - CRaSH IMPLEMENTATION CHANGE!");
> > > > > > HashMap<String, Class<? extends BaseCommand>> systemCommands = (HashMap) systemCommandsField.get(null);
> > > > > >
> > > > > > Reflections r = new Reflections("commands.package.here", new SubTypesScanner());
> > > > > > for (Class<? extends BaseCommand> c : r.getSubTypesOf(BaseCommand.class)){
> > > > > > systemCommands.put(c.getSimpleName(), c);
> > > > > > }
> > > > > >
> > > > > > CRaSH.main(args);
> > > > > >
> > > > > >
> > > > > > *note that i use the Reflections (https://github.com/ronmamo/reflections) library which allows me to scan my classpath in order to find all the subtypes of BaseCommand that resides in a given package.
> > > > > >
> > > > > > It works BUT I am not sure that this is the right way to do so and will be very happy if someone will suggest a "less hackish" way..
> > > > > >
> > > > > > Benny.
> > > > > >
> > > > > > On Sunday, May 11, 2014 12:20:54 PM UTC+3, Julien Viet wrote:
> > > > > > > Can you tell me the values of the String[] args in your case ?
> > > > > > >
> > > > > > >
> > > > > > > Julien Viet
> > > > > > > julienviet.com (http://julienviet.com) (http://julienviet.com) (http://julienviet.com)
> > > > >
> > > > > On Thursday 15 May 2014 at 22:59, Benny Lutati wrote:
> > > > >
> > > > > > Hello,
> > > > > > I am also new to CRaSH (started looking at it today), and I wanted to achieve exactly what you wanted,
> > > > > > I wanted to be able to embed CRaSH into my java application (no spring, webserver, etc. just plain old java app) and in order for it to be useful I needed
> > > > > > to add commands that directly modify the state of my application - this means that the commands needed to reside inside my application jar.
> > > > > >
> > > > > > After reading the source code I came out with the following way:
> > > > > >
> > > > > > Field systemCommandsField = org.crsh.shell.impl.command.CRaSH.class.getDeclaredField("systemCommands");
> > > > > > systemCommandsField.setAccessible(true);
> > > > > > if (systemCommandsField == null) throw new UnsupportedOperationException("PANIC - CRaSH IMPLEMENTATION CHANGE!");
> > > > > > HashMap<String, Class<? extends BaseCommand>> systemCommands = (HashMap) systemCommandsField.get(null);
> > > > > >
> > > > > > Reflections r = new Reflections("commands.package.here", new SubTypesScanner());
> > > > > > for (Class<? extends BaseCommand> c : r.getSubTypesOf(BaseCommand.class)){
> > > > > > systemCommands.put(c.getSimpleName(), c);
> > > > > > }
> > > > > >
> > > > > > CRaSH.main(args);
> > > > > >
> > > > > >
> > > > > > *note that i use the Reflections (https://github.com/ronmamo/reflections) library which allows me to scan my classpath in order to find all the subtypes of BaseCommand that resides in a given package.
> > > > > >
> > > > > > It works BUT I am not sure that this is the right way to do so and will be very happy if someone will suggest a "less hackish" way..
> > > > > >
> > > > > > Benny.
> > > > > >
> > > > > > On Sunday, May 11, 2014 12:20:54 PM UTC+3, Julien Viet wrote:
> > > > > > > Can you tell me the values of the String[] args in your case ?
> > > > > > >
> > > > > > >
> > > > > > > Julien Viet
> > > > > > >
> > > > > > >
> > > > > > > On Saturday 10 May 2014 at 20:58, Curt Beattie wrote:
> > > > > > >
> > > > > > > > The following class does almost exactly what I want, except I need it to load the commands from the classpath rather than from the file system. However I can't for the life of me figure out how to do this.
> > > > > > > >
> > > > > > > > public class MyMain {
> > > > > > > > public static void main(String[] args) throws Exception {
> > > > > > > > CRaSH.main(args);
> > > > > > > > }
> > > > > > > > }
> > > > > > > >
> > > > > > > > Some help would be appreciated.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users...@googlegroups.com (javascript:) (javascript:) (javascript:)).
> > > > > > >
> > > > > > > On Saturday 10 May 2014 at 20:58, Curt Beattie wrote:
> > > > > > >
> > > > > > > > The following class does almost exactly what I want, except I need it to load the commands from the classpath rather than from the file system. However I can't for the life of me figure out how to do this.
> > > > > > > >
> > > > > > > > public class MyMain {
> > > > > > > > public static void main(String[] args) throws Exception {
> > > > > > > > CRaSH.main(args);
> > > > > > > > }
> > > > > > > > }
> > > > > > > >
> > > > > > > > Some help would be appreciated.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users...@googlegroups.com (javascript:) (javascript:)).
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users...@googlegroups.com (javascript:)).
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > >
> > >
> >
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (mailto:crash-users...@googlegroups.com).
> > >
> > >
> >
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
Benny Lutati
May 16, 2014, 6:01:49 AM5/16/14
to crash...@googlegroups.com
Thank you very much - this can be great!
> > > > > > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users+unsub...@googlegroups.com (javascript:) (javascript:) (javascript:)).
> > > > > > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users+unsub...@googlegroups.com (javascript:) (javascript:)).
> > > > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users+unsub...@googlegroups.com (javascript:)).
> > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > >
> > >
> >
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (mailto:crash-users+unsub...@googlegroups.com).
Julien Viet
May 18, 2014, 4:07:23 PM5/18/14
to crash...@googlegroups.com
you can have a look at the plugable command resolver system.
keep in mind that this is an internal API because it is potentially subject to change (that does not mean it has to change of course), however the API is fairly simple to implement…
here is the test case class that tests the feature, that will help you to implement it:
https://github.com/crashub/crash/blob/master/shell/src/test/java/org/crsh/shell/CustomCommandResolverTestCase.java
As this is done under the form of CRaSHPlugin you should in a real life case declare the plugin in the META-INF/services/org.crsh.plugin.CRaSHPlugin file.
let me know how it goes for you (note that you need to build a SNAPSHOT to use this feature at the moment).
Julien Viet
julienviet.com
On Friday 16 May 2014 at 12:01, Benny Lutati wrote:
> Thank you very much - this can be great!
>
> On Friday, May 16, 2014 9:49:14 AM UTC+3, Julien Viet wrote:
> > I see, so I think we can go with some “command provider” interface and retrofit the current dynamic command system of crash as one provider among others.
> >
> >
> > Julien Viet
keep in mind that this is an internal API because it is potentially subject to change (that does not mean it has to change of course), however the API is fairly simple to implement…
here is the test case class that tests the feature, that will help you to implement it:
https://github.com/crashub/crash/blob/master/shell/src/test/java/org/crsh/shell/CustomCommandResolverTestCase.java
As this is done under the form of CRaSHPlugin you should in a real life case declare the plugin in the META-INF/services/org.crsh.plugin.CRaSHPlugin file.
let me know how it goes for you (note that you need to build a SNAPSHOT to use this feature at the moment).
Julien Viet
julienviet.com
On Friday 16 May 2014 at 12:01, Benny Lutati wrote:
> Thank you very much - this can be great!
>
> On Friday, May 16, 2014 9:49:14 AM UTC+3, Julien Viet wrote:
> > I see, so I think we can go with some “command provider” interface and retrofit the current dynamic command system of crash as one provider among others.
> >
> >
> > Julien Viet
> > julienviet.com (http://julienviet.com)
> >
> >
> > On Friday 16 May 2014 at 00:54, Benny Lutati wrote:
> >
> > > For my use case it will be unfeasible to list the commands ahead of time - let me explain what i am trying to achieve
> > >
> > > I am running a "standalone" shell from within my program
> > > before execution of the shell I am scanning my packages and looking for singleton controllers (annotated classes)
> > > for each such controller i am generating on the fly (using reflectasm) instances of "git style" commands with sub commands reflecting some public functions of that controller.
> > > than I am using the systemcommands hack to inject these commands into the shell - and finally when all done i am starting the shell
> > >
> > > that gives me a very powerful shell that is automatically customized to any of my programs and allows me to debug/automate stuff..
> > > this is why i think that the supplier plugin can be very powerful addition - but this is only my opinion..
> > >
> > > Benny.
> > >
> > >
> > > On Friday, May 16, 2014 1:30:54 AM UTC+3, Julien Viet wrote:
> > > > that being said, the idea of supplier plugin could also be used and the actual system that compiles commands would be also a supplier.
> > > >
> > > > currently this is done in the org.crsh.shell.impl.command.CRaSH class with the CommandManager and such.
> > > >
> > > > This code would be extracted and encapsulated into a command supplier, allowing other suppliers to do the same.
> > > >
> > > > Julien Viet
> > > > julienviet.com (http://julienviet.com) (http://julienviet.com)
> >
> >
> > On Friday 16 May 2014 at 00:54, Benny Lutati wrote:
> >
> > > For my use case it will be unfeasible to list the commands ahead of time - let me explain what i am trying to achieve
> > >
> > > I am running a "standalone" shell from within my program
> > > before execution of the shell I am scanning my packages and looking for singleton controllers (annotated classes)
> > > for each such controller i am generating on the fly (using reflectasm) instances of "git style" commands with sub commands reflecting some public functions of that controller.
> > > than I am using the systemcommands hack to inject these commands into the shell - and finally when all done i am starting the shell
> > >
> > > that gives me a very powerful shell that is automatically customized to any of my programs and allows me to debug/automate stuff..
> > > this is why i think that the supplier plugin can be very powerful addition - but this is only my opinion..
> > >
> > > Benny.
> > >
> > >
> > > On Friday, May 16, 2014 1:30:54 AM UTC+3, Julien Viet wrote:
> > > > that being said, the idea of supplier plugin could also be used and the actual system that compiles commands would be also a supplier.
> > > >
> > > > currently this is done in the org.crsh.shell.impl.command.CRaSH class with the CommandManager and such.
> > > >
> > > > This code would be extracted and encapsulated into a command supplier, allowing other suppliers to do the same.
> > > >
> > > > Julien Viet
> > > >
> > > >
> > > > On Friday 16 May 2014 at 00:26, Julien Viet wrote:
> > > >
> > > > > Basically you would just have to declare your commands in a text file in your jar file.
> > > > >
> > > > > so if you have
> > > > >
> > > > > package foo;
> > > > > public class mycommand extends BaseCommand {
> > > > > ...
> > > > > }
> > > > >
> > > > > this command would be declared in a META-INF/services/org.crsh.command.BaseCommand file in the same jar:
> > > > >
> > > > > “foo.mycommand"
> > > > >
> > > > > This can contain as many implementations as you need.
> > > > >
> > > > > As far as I can think, it should fit your needs, shouldn’t it ?
> > > > >
> > > > > Julien Viet
> > > > > julienviet.com (http://julienviet.com) (http://julienviet.com) (http://julienviet.com)
> > > >
> > > > On Friday 16 May 2014 at 00:26, Julien Viet wrote:
> > > >
> > > > > Basically you would just have to declare your commands in a text file in your jar file.
> > > > >
> > > > > so if you have
> > > > >
> > > > > package foo;
> > > > > public class mycommand extends BaseCommand {
> > > > > ...
> > > > > }
> > > > >
> > > > > this command would be declared in a META-INF/services/org.crsh.command.BaseCommand file in the same jar:
> > > > >
> > > > > “foo.mycommand"
> > > > >
> > > > > This can contain as many implementations as you need.
> > > > >
> > > > > As far as I can think, it should fit your needs, shouldn’t it ?
> > > > >
> > > > > Julien Viet
> > > > >
> > > > >
> > > > > On Thursday 15 May 2014 at 23:45, Benny Lutati wrote:
> > > > >
> > > > > > Hi, thank you for the fast response!
> > > > > >
> > > > > > regards the second comment - I still not fully understand what plugins can and cannot do - but for me it looks like it would be
> > > > > > a great option to be able to add some sort of a "commands supplier plugin" - this way one will be able to create such a plugin that will automatically generate commands based on the application it attached on (this is what I am working on currently and why i needed to hack the system commands.. )
> > > > > >
> > > > > > Benny.
> > > > > > On Friday, May 16, 2014 12:30:22 AM UTC+3, Julien Viet wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > two comments:
> > > > > > >
> > > > > > > 1/ there will be at least one option to achieve something like this in the near future
> > > > > > >
> > > > > > > https://jira.exoplatform.org/browse/CRASH-185
> > > > > > >
> > > > > > > In your case you would set the “command path” to “classpath:/commands/crash/;classpath:/commands/package/here/“ which aggregates the classic CRaSH commands and also your package. Note that will work with source files and your command will be compiled on the fly by CRaSH at the moment it is loaded.
> > > > > > >
> > > > > > > This would work with classpath, file and war (the content of the war file). The goal of this feature is to remove the default path “hardcoded” in CRaSH.
> > > > > > >
> > > > > > > This feature will be done very soon (next monday I hope).
> > > > > > >
> > > > > > > 2/ I see you are hacking the system commands. Those are commands that should be *always there* like “help” or “repl”. They are precompiled (so written in Java) and therefore at the moment added manually in the systemCommands field.
> > > > > > >
> > > > > > > It makes sense to me to allow people to augment the set of system commands to further more customize CRaSH. The java.util.ServiceLoader extension mechanism could be used to allow this, so you would have to declare your BaseCommand subclasses in a META-INF/services/org.crsh.command.BaseCommand file.
> > > > > > >
> > > > > > > Unless I’m wrong, this feature would be quite trivial to add and not much work.
> > > > > > >
> > > > > > > what do you think ?
> > > > > > >
> > > > > > > Julien Viet
> > > > > > > julienviet.com (http://julienviet.com) (http://julienviet.com) (http://julienviet.com)
> > > > >
> > > > > On Thursday 15 May 2014 at 23:45, Benny Lutati wrote:
> > > > >
> > > > > > Hi, thank you for the fast response!
> > > > > >
> > > > > > regards the second comment - I still not fully understand what plugins can and cannot do - but for me it looks like it would be
> > > > > > a great option to be able to add some sort of a "commands supplier plugin" - this way one will be able to create such a plugin that will automatically generate commands based on the application it attached on (this is what I am working on currently and why i needed to hack the system commands.. )
> > > > > >
> > > > > > Benny.
> > > > > > On Friday, May 16, 2014 12:30:22 AM UTC+3, Julien Viet wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > two comments:
> > > > > > >
> > > > > > > 1/ there will be at least one option to achieve something like this in the near future
> > > > > > >
> > > > > > > https://jira.exoplatform.org/browse/CRASH-185
> > > > > > >
> > > > > > > In your case you would set the “command path” to “classpath:/commands/crash/;classpath:/commands/package/here/“ which aggregates the classic CRaSH commands and also your package. Note that will work with source files and your command will be compiled on the fly by CRaSH at the moment it is loaded.
> > > > > > >
> > > > > > > This would work with classpath, file and war (the content of the war file). The goal of this feature is to remove the default path “hardcoded” in CRaSH.
> > > > > > >
> > > > > > > This feature will be done very soon (next monday I hope).
> > > > > > >
> > > > > > > 2/ I see you are hacking the system commands. Those are commands that should be *always there* like “help” or “repl”. They are precompiled (so written in Java) and therefore at the moment added manually in the systemCommands field.
> > > > > > >
> > > > > > > It makes sense to me to allow people to augment the set of system commands to further more customize CRaSH. The java.util.ServiceLoader extension mechanism could be used to allow this, so you would have to declare your BaseCommand subclasses in a META-INF/services/org.crsh.command.BaseCommand file.
> > > > > > >
> > > > > > > Unless I’m wrong, this feature would be quite trivial to add and not much work.
> > > > > > >
> > > > > > > what do you think ?
> > > > > > >
> > > > > > > Julien Viet
> > > > > > >
> > > > > > >
> > > > > > > On Thursday 15 May 2014 at 22:59, Benny Lutati wrote:
> > > > > > >
> > > > > > > > Hello,
> > > > > > > > I am also new to CRaSH (started looking at it today), and I wanted to achieve exactly what you wanted,
> > > > > > > > I wanted to be able to embed CRaSH into my java application (no spring, webserver, etc. just plain old java app) and in order for it to be useful I needed
> > > > > > > > to add commands that directly modify the state of my application - this means that the commands needed to reside inside my application jar.
> > > > > > > >
> > > > > > > > After reading the source code I came out with the following way:
> > > > > > > >
> > > > > > > > Field systemCommandsField = org.crsh.shell.impl.command.CRaSH.class.getDeclaredField("systemCommands");
> > > > > > > > systemCommandsField.setAccessible(true);
> > > > > > > > if (systemCommandsField == null) throw new UnsupportedOperationException("PANIC - CRaSH IMPLEMENTATION CHANGE!");
> > > > > > > > HashMap<String, Class<? extends BaseCommand>> systemCommands = (HashMap) systemCommandsField.get(null);
> > > > > > > >
> > > > > > > > Reflections r = new Reflections("commands.package.here", new SubTypesScanner());
> > > > > > > > for (Class<? extends BaseCommand> c : r.getSubTypesOf(BaseCommand.class)){
> > > > > > > > systemCommands.put(c.getSimpleName(), c);
> > > > > > > > }
> > > > > > > >
> > > > > > > > CRaSH.main(args);
> > > > > > > >
> > > > > > > >
> > > > > > > > *note that i use the Reflections (https://github.com/ronmamo/reflections) library which allows me to scan my classpath in order to find all the subtypes of BaseCommand that resides in a given package.
> > > > > > > >
> > > > > > > > It works BUT I am not sure that this is the right way to do so and will be very happy if someone will suggest a "less hackish" way..
> > > > > > > >
> > > > > > > > Benny.
> > > > > > > >
> > > > > > > > On Sunday, May 11, 2014 12:20:54 PM UTC+3, Julien Viet wrote:
> > > > > > > > > Can you tell me the values of the String[] args in your case ?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Julien Viet
> > > > > > > > > julienviet.com (http://julienviet.com) (http://julienviet.com) (http://julienviet.com) (http://julienviet.com)
> > > > > > >
> > > > > > > On Thursday 15 May 2014 at 22:59, Benny Lutati wrote:
> > > > > > >
> > > > > > > > Hello,
> > > > > > > > I am also new to CRaSH (started looking at it today), and I wanted to achieve exactly what you wanted,
> > > > > > > > I wanted to be able to embed CRaSH into my java application (no spring, webserver, etc. just plain old java app) and in order for it to be useful I needed
> > > > > > > > to add commands that directly modify the state of my application - this means that the commands needed to reside inside my application jar.
> > > > > > > >
> > > > > > > > After reading the source code I came out with the following way:
> > > > > > > >
> > > > > > > > Field systemCommandsField = org.crsh.shell.impl.command.CRaSH.class.getDeclaredField("systemCommands");
> > > > > > > > systemCommandsField.setAccessible(true);
> > > > > > > > if (systemCommandsField == null) throw new UnsupportedOperationException("PANIC - CRaSH IMPLEMENTATION CHANGE!");
> > > > > > > > HashMap<String, Class<? extends BaseCommand>> systemCommands = (HashMap) systemCommandsField.get(null);
> > > > > > > >
> > > > > > > > Reflections r = new Reflections("commands.package.here", new SubTypesScanner());
> > > > > > > > for (Class<? extends BaseCommand> c : r.getSubTypesOf(BaseCommand.class)){
> > > > > > > > systemCommands.put(c.getSimpleName(), c);
> > > > > > > > }
> > > > > > > >
> > > > > > > > CRaSH.main(args);
> > > > > > > >
> > > > > > > >
> > > > > > > > *note that i use the Reflections (https://github.com/ronmamo/reflections) library which allows me to scan my classpath in order to find all the subtypes of BaseCommand that resides in a given package.
> > > > > > > >
> > > > > > > > It works BUT I am not sure that this is the right way to do so and will be very happy if someone will suggest a "less hackish" way..
> > > > > > > >
> > > > > > > > Benny.
> > > > > > > >
> > > > > > > > On Sunday, May 11, 2014 12:20:54 PM UTC+3, Julien Viet wrote:
> > > > > > > > > Can you tell me the values of the String[] args in your case ?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Julien Viet
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Saturday 10 May 2014 at 20:58, Curt Beattie wrote:
> > > > > > > > >
> > > > > > > > > > The following class does almost exactly what I want, except I need it to load the commands from the classpath rather than from the file system. However I can't for the life of me figure out how to do this.
> > > > > > > > > >
> > > > > > > > > > public class MyMain {
> > > > > > > > > > public static void main(String[] args) throws Exception {
> > > > > > > > > > CRaSH.main(args);
> > > > > > > > > > }
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > Some help would be appreciated.
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > > > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users...@googlegroups.com (javascript:) (javascript:) (javascript:) (javascript:)).
> > > > > > > > >
> > > > > > > > > On Saturday 10 May 2014 at 20:58, Curt Beattie wrote:
> > > > > > > > >
> > > > > > > > > > The following class does almost exactly what I want, except I need it to load the commands from the classpath rather than from the file system. However I can't for the life of me figure out how to do this.
> > > > > > > > > >
> > > > > > > > > > public class MyMain {
> > > > > > > > > > public static void main(String[] args) throws Exception {
> > > > > > > > > > CRaSH.main(args);
> > > > > > > > > > }
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > Some help would be appreciated.
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > > > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users...@googlegroups.com (javascript:) (javascript:) (javascript:)).
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users...@googlegroups.com (javascript:) (javascript:)).
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users...@googlegroups.com (javascript:)).
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> >
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (mailto:crash-users...@googlegroups.com).
> >
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
Benny Lutati
May 19, 2014, 11:46:39 AM5/19/14
to crash...@googlegroups.com
Thank you very much! - i will test it today and will let you know how it goes.
Benny.
Benny.
> > > > > > > > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users+unsub...@googlegroups.com (javascript:) (javascript:) (javascript:) (javascript:)).
> > > > > > > > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users+unsub...@googlegroups.com (javascript:) (javascript:) (javascript:)).
> > > > > > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users+unsub...@googlegroups.com (javascript:) (javascript:)).
> > > > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users+unsub...@googlegroups.com (javascript:)).
> > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> >
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (mailto:crash-users+unsub...@googlegroups.com).
Benny Lutati
May 22, 2014, 5:09:05 PM5/22/14
to crash...@googlegroups.com
Hi, I just wanted to thank you again - I build the latest snapshot and modified my code to use the command resolver and it works great!
Thank you very much.
Benny.
Julien Viet
May 23, 2014, 1:43:48 AM5/23/14
to crash...@googlegroups.com
great to see that!
you can use too the latest beta21 that was released 2 days ago.
Julien Viet
julienviet.com
On Thursday 22 May 2014 at 23:09, Benny Lutati wrote:
> Hi, I just wanted to thank you again - I build the latest snapshot and modified my code to use the command resolver and it works great!
> Thank you very much.
>
> Benny.
>
> On Monday, May 19, 2014 6:46:39 PM UTC+3, Benny Lutati wrote:
> > Thank you very much! - i will test it today and will let you know how it goes.
> >
> > Benny.
> > On Sunday, May 18, 2014 11:07:23 PM UTC+3, Julien Viet wrote:
> > > you can have a look at the plugable command resolver system.
> > >
> > > keep in mind that this is an internal API because it is potentially subject to change (that does not mean it has to change of course), however the API is fairly simple to implement…
> > >
> > > here is the test case class that tests the feature, that will help you to implement it:
> > >
> > > https://github.com/crashub/crash/blob/master/shell/src/test/java/org/crsh/shell/CustomCommandResolverTestCase.java
> > >
> > > As this is done under the form of CRaSHPlugin you should in a real life case declare the plugin in the META-INF/services/org.crsh.plugin.CRaSHPlugin file.
> > >
> > > let me know how it goes for you (note that you need to build a SNAPSHOT to use this feature at the moment).
> > >
> > > Julien Viet
you can use too the latest beta21 that was released 2 days ago.
Julien Viet
julienviet.com
On Thursday 22 May 2014 at 23:09, Benny Lutati wrote:
> Hi, I just wanted to thank you again - I build the latest snapshot and modified my code to use the command resolver and it works great!
> Thank you very much.
>
> Benny.
>
> On Monday, May 19, 2014 6:46:39 PM UTC+3, Benny Lutati wrote:
> > Thank you very much! - i will test it today and will let you know how it goes.
> >
> > Benny.
> > On Sunday, May 18, 2014 11:07:23 PM UTC+3, Julien Viet wrote:
> > > you can have a look at the plugable command resolver system.
> > >
> > > keep in mind that this is an internal API because it is potentially subject to change (that does not mean it has to change of course), however the API is fairly simple to implement…
> > >
> > > here is the test case class that tests the feature, that will help you to implement it:
> > >
> > > https://github.com/crashub/crash/blob/master/shell/src/test/java/org/crsh/shell/CustomCommandResolverTestCase.java
> > >
> > > As this is done under the form of CRaSHPlugin you should in a real life case declare the plugin in the META-INF/services/org.crsh.plugin.CRaSHPlugin file.
> > >
> > > let me know how it goes for you (note that you need to build a SNAPSHOT to use this feature at the moment).
> > >
> > > Julien Viet
> > > julienviet.com (http://julienviet.com)
> > >
> > >
> > > On Friday 16 May 2014 at 12:01, Benny Lutati wrote:
> > >
> > > > Thank you very much - this can be great!
> > > >
> > > > On Friday, May 16, 2014 9:49:14 AM UTC+3, Julien Viet wrote:
> > > > > I see, so I think we can go with some “command provider” interface and retrofit the current dynamic command system of crash as one provider among others.
> > > > >
> > > > >
> > > > > Julien Viet
> > > > > julienviet.com (http://julienviet.com) (http://julienviet.com)
> > >
> > >
> > > On Friday 16 May 2014 at 12:01, Benny Lutati wrote:
> > >
> > > > Thank you very much - this can be great!
> > > >
> > > > On Friday, May 16, 2014 9:49:14 AM UTC+3, Julien Viet wrote:
> > > > > I see, so I think we can go with some “command provider” interface and retrofit the current dynamic command system of crash as one provider among others.
> > > > >
> > > > >
> > > > > Julien Viet
> > > > >
> > > > >
> > > > > On Friday 16 May 2014 at 00:54, Benny Lutati wrote:
> > > > >
> > > > > > For my use case it will be unfeasible to list the commands ahead of time - let me explain what i am trying to achieve
> > > > > >
> > > > > > I am running a "standalone" shell from within my program
> > > > > > before execution of the shell I am scanning my packages and looking for singleton controllers (annotated classes)
> > > > > > for each such controller i am generating on the fly (using reflectasm) instances of "git style" commands with sub commands reflecting some public functions of that controller.
> > > > > > than I am using the systemcommands hack to inject these commands into the shell - and finally when all done i am starting the shell
> > > > > >
> > > > > > that gives me a very powerful shell that is automatically customized to any of my programs and allows me to debug/automate stuff..
> > > > > > this is why i think that the supplier plugin can be very powerful addition - but this is only my opinion..
> > > > > >
> > > > > > Benny.
> > > > > >
> > > > > >
> > > > > > On Friday, May 16, 2014 1:30:54 AM UTC+3, Julien Viet wrote:
> > > > > > > that being said, the idea of supplier plugin could also be used and the actual system that compiles commands would be also a supplier.
> > > > > > >
> > > > > > > currently this is done in the org.crsh.shell.impl.command.CRaSH class with the CommandManager and such.
> > > > > > >
> > > > > > > This code would be extracted and encapsulated into a command supplier, allowing other suppliers to do the same.
> > > > > > >
> > > > > > > Julien Viet
> > > > > > > julienviet.com (http://julienviet.com) (http://julienviet.com) (http://julienviet.com)
> > > > >
> > > > > On Friday 16 May 2014 at 00:54, Benny Lutati wrote:
> > > > >
> > > > > > For my use case it will be unfeasible to list the commands ahead of time - let me explain what i am trying to achieve
> > > > > >
> > > > > > I am running a "standalone" shell from within my program
> > > > > > before execution of the shell I am scanning my packages and looking for singleton controllers (annotated classes)
> > > > > > for each such controller i am generating on the fly (using reflectasm) instances of "git style" commands with sub commands reflecting some public functions of that controller.
> > > > > > than I am using the systemcommands hack to inject these commands into the shell - and finally when all done i am starting the shell
> > > > > >
> > > > > > that gives me a very powerful shell that is automatically customized to any of my programs and allows me to debug/automate stuff..
> > > > > > this is why i think that the supplier plugin can be very powerful addition - but this is only my opinion..
> > > > > >
> > > > > > Benny.
> > > > > >
> > > > > >
> > > > > > On Friday, May 16, 2014 1:30:54 AM UTC+3, Julien Viet wrote:
> > > > > > > that being said, the idea of supplier plugin could also be used and the actual system that compiles commands would be also a supplier.
> > > > > > >
> > > > > > > currently this is done in the org.crsh.shell.impl.command.CRaSH class with the CommandManager and such.
> > > > > > >
> > > > > > > This code would be extracted and encapsulated into a command supplier, allowing other suppliers to do the same.
> > > > > > >
> > > > > > > Julien Viet
> > > > > > >
> > > > > > >
> > > > > > > On Friday 16 May 2014 at 00:26, Julien Viet wrote:
> > > > > > >
> > > > > > > > Basically you would just have to declare your commands in a text file in your jar file.
> > > > > > > >
> > > > > > > > so if you have
> > > > > > > >
> > > > > > > > package foo;
> > > > > > > > public class mycommand extends BaseCommand {
> > > > > > > > ...
> > > > > > > > }
> > > > > > > >
> > > > > > > > this command would be declared in a META-INF/services/org.crsh.command.BaseCommand file in the same jar:
> > > > > > > >
> > > > > > > > “foo.mycommand"
> > > > > > > >
> > > > > > > > This can contain as many implementations as you need.
> > > > > > > >
> > > > > > > > As far as I can think, it should fit your needs, shouldn’t it ?
> > > > > > > >
> > > > > > > > Julien Viet
> > > > > > > > julienviet.com (http://julienviet.com) (http://julienviet.com) (http://julienviet.com) (http://julienviet.com)
> > > > > > >
> > > > > > > On Friday 16 May 2014 at 00:26, Julien Viet wrote:
> > > > > > >
> > > > > > > > Basically you would just have to declare your commands in a text file in your jar file.
> > > > > > > >
> > > > > > > > so if you have
> > > > > > > >
> > > > > > > > package foo;
> > > > > > > > public class mycommand extends BaseCommand {
> > > > > > > > ...
> > > > > > > > }
> > > > > > > >
> > > > > > > > this command would be declared in a META-INF/services/org.crsh.command.BaseCommand file in the same jar:
> > > > > > > >
> > > > > > > > “foo.mycommand"
> > > > > > > >
> > > > > > > > This can contain as many implementations as you need.
> > > > > > > >
> > > > > > > > As far as I can think, it should fit your needs, shouldn’t it ?
> > > > > > > >
> > > > > > > > Julien Viet
> > > > > > > >
> > > > > > > >
> > > > > > > > On Thursday 15 May 2014 at 23:45, Benny Lutati wrote:
> > > > > > > >
> > > > > > > > > Hi, thank you for the fast response!
> > > > > > > > >
> > > > > > > > > regards the second comment - I still not fully understand what plugins can and cannot do - but for me it looks like it would be
> > > > > > > > > a great option to be able to add some sort of a "commands supplier plugin" - this way one will be able to create such a plugin that will automatically generate commands based on the application it attached on (this is what I am working on currently and why i needed to hack the system commands.. )
> > > > > > > > >
> > > > > > > > > Benny.
> > > > > > > > > On Friday, May 16, 2014 12:30:22 AM UTC+3, Julien Viet wrote:
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > two comments:
> > > > > > > > > >
> > > > > > > > > > 1/ there will be at least one option to achieve something like this in the near future
> > > > > > > > > >
> > > > > > > > > > https://jira.exoplatform.org/browse/CRASH-185
> > > > > > > > > >
> > > > > > > > > > In your case you would set the “command path” to “classpath:/commands/crash/;classpath:/commands/package/here/“ which aggregates the classic CRaSH commands and also your package. Note that will work with source files and your command will be compiled on the fly by CRaSH at the moment it is loaded.
> > > > > > > > > >
> > > > > > > > > > This would work with classpath, file and war (the content of the war file). The goal of this feature is to remove the default path “hardcoded” in CRaSH.
> > > > > > > > > >
> > > > > > > > > > This feature will be done very soon (next monday I hope).
> > > > > > > > > >
> > > > > > > > > > 2/ I see you are hacking the system commands. Those are commands that should be *always there* like “help” or “repl”. They are precompiled (so written in Java) and therefore at the moment added manually in the systemCommands field.
> > > > > > > > > >
> > > > > > > > > > It makes sense to me to allow people to augment the set of system commands to further more customize CRaSH. The java.util.ServiceLoader extension mechanism could be used to allow this, so you would have to declare your BaseCommand subclasses in a META-INF/services/org.crsh.command.BaseCommand file.
> > > > > > > > > >
> > > > > > > > > > Unless I’m wrong, this feature would be quite trivial to add and not much work.
> > > > > > > > > >
> > > > > > > > > > what do you think ?
> > > > > > > > > >
> > > > > > > > > > Julien Viet
> > > > > > > > > > julienviet.com (http://julienviet.com) (http://julienviet.com) (http://julienviet.com) (http://julienviet.com)
> > > > > > > >
> > > > > > > > On Thursday 15 May 2014 at 23:45, Benny Lutati wrote:
> > > > > > > >
> > > > > > > > > Hi, thank you for the fast response!
> > > > > > > > >
> > > > > > > > > regards the second comment - I still not fully understand what plugins can and cannot do - but for me it looks like it would be
> > > > > > > > > a great option to be able to add some sort of a "commands supplier plugin" - this way one will be able to create such a plugin that will automatically generate commands based on the application it attached on (this is what I am working on currently and why i needed to hack the system commands.. )
> > > > > > > > >
> > > > > > > > > Benny.
> > > > > > > > > On Friday, May 16, 2014 12:30:22 AM UTC+3, Julien Viet wrote:
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > two comments:
> > > > > > > > > >
> > > > > > > > > > 1/ there will be at least one option to achieve something like this in the near future
> > > > > > > > > >
> > > > > > > > > > https://jira.exoplatform.org/browse/CRASH-185
> > > > > > > > > >
> > > > > > > > > > In your case you would set the “command path” to “classpath:/commands/crash/;classpath:/commands/package/here/“ which aggregates the classic CRaSH commands and also your package. Note that will work with source files and your command will be compiled on the fly by CRaSH at the moment it is loaded.
> > > > > > > > > >
> > > > > > > > > > This would work with classpath, file and war (the content of the war file). The goal of this feature is to remove the default path “hardcoded” in CRaSH.
> > > > > > > > > >
> > > > > > > > > > This feature will be done very soon (next monday I hope).
> > > > > > > > > >
> > > > > > > > > > 2/ I see you are hacking the system commands. Those are commands that should be *always there* like “help” or “repl”. They are precompiled (so written in Java) and therefore at the moment added manually in the systemCommands field.
> > > > > > > > > >
> > > > > > > > > > It makes sense to me to allow people to augment the set of system commands to further more customize CRaSH. The java.util.ServiceLoader extension mechanism could be used to allow this, so you would have to declare your BaseCommand subclasses in a META-INF/services/org.crsh.command.BaseCommand file.
> > > > > > > > > >
> > > > > > > > > > Unless I’m wrong, this feature would be quite trivial to add and not much work.
> > > > > > > > > >
> > > > > > > > > > what do you think ?
> > > > > > > > > >
> > > > > > > > > > Julien Viet
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Thursday 15 May 2014 at 22:59, Benny Lutati wrote:
> > > > > > > > > >
> > > > > > > > > > > Hello,
> > > > > > > > > > > I am also new to CRaSH (started looking at it today), and I wanted to achieve exactly what you wanted,
> > > > > > > > > > > I wanted to be able to embed CRaSH into my java application (no spring, webserver, etc. just plain old java app) and in order for it to be useful I needed
> > > > > > > > > > > to add commands that directly modify the state of my application - this means that the commands needed to reside inside my application jar.
> > > > > > > > > > >
> > > > > > > > > > > After reading the source code I came out with the following way:
> > > > > > > > > > >
> > > > > > > > > > > Field systemCommandsField = org.crsh.shell.impl.command.CRaSH.class.getDeclaredField("systemCommands");
> > > > > > > > > > > systemCommandsField.setAccessible(true);
> > > > > > > > > > > if (systemCommandsField == null) throw new UnsupportedOperationException("PANIC - CRaSH IMPLEMENTATION CHANGE!");
> > > > > > > > > > > HashMap<String, Class<? extends BaseCommand>> systemCommands = (HashMap) systemCommandsField.get(null);
> > > > > > > > > > >
> > > > > > > > > > > Reflections r = new Reflections("commands.package.here", new SubTypesScanner());
> > > > > > > > > > > for (Class<? extends BaseCommand> c : r.getSubTypesOf(BaseCommand.class)){
> > > > > > > > > > > systemCommands.put(c.getSimpleName(), c);
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > CRaSH.main(args);
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > *note that i use the Reflections (https://github.com/ronmamo/reflections) library which allows me to scan my classpath in order to find all the subtypes of BaseCommand that resides in a given package.
> > > > > > > > > > >
> > > > > > > > > > > It works BUT I am not sure that this is the right way to do so and will be very happy if someone will suggest a "less hackish" way..
> > > > > > > > > > >
> > > > > > > > > > > Benny.
> > > > > > > > > > >
> > > > > > > > > > > On Sunday, May 11, 2014 12:20:54 PM UTC+3, Julien Viet wrote:
> > > > > > > > > > > > Can you tell me the values of the String[] args in your case ?
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Julien Viet
> > > > > > > > > > > > julienviet.com (http://julienviet.com) (http://julienviet.com) (http://julienviet.com) (http://julienviet.com) (http://julienviet.com)
> > > > > > > > > >
> > > > > > > > > > On Thursday 15 May 2014 at 22:59, Benny Lutati wrote:
> > > > > > > > > >
> > > > > > > > > > > Hello,
> > > > > > > > > > > I am also new to CRaSH (started looking at it today), and I wanted to achieve exactly what you wanted,
> > > > > > > > > > > I wanted to be able to embed CRaSH into my java application (no spring, webserver, etc. just plain old java app) and in order for it to be useful I needed
> > > > > > > > > > > to add commands that directly modify the state of my application - this means that the commands needed to reside inside my application jar.
> > > > > > > > > > >
> > > > > > > > > > > After reading the source code I came out with the following way:
> > > > > > > > > > >
> > > > > > > > > > > Field systemCommandsField = org.crsh.shell.impl.command.CRaSH.class.getDeclaredField("systemCommands");
> > > > > > > > > > > systemCommandsField.setAccessible(true);
> > > > > > > > > > > if (systemCommandsField == null) throw new UnsupportedOperationException("PANIC - CRaSH IMPLEMENTATION CHANGE!");
> > > > > > > > > > > HashMap<String, Class<? extends BaseCommand>> systemCommands = (HashMap) systemCommandsField.get(null);
> > > > > > > > > > >
> > > > > > > > > > > Reflections r = new Reflections("commands.package.here", new SubTypesScanner());
> > > > > > > > > > > for (Class<? extends BaseCommand> c : r.getSubTypesOf(BaseCommand.class)){
> > > > > > > > > > > systemCommands.put(c.getSimpleName(), c);
> > > > > > > > > > > }
> > > > > > > > > > >
> > > > > > > > > > > CRaSH.main(args);
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > *note that i use the Reflections (https://github.com/ronmamo/reflections) library which allows me to scan my classpath in order to find all the subtypes of BaseCommand that resides in a given package.
> > > > > > > > > > >
> > > > > > > > > > > It works BUT I am not sure that this is the right way to do so and will be very happy if someone will suggest a "less hackish" way..
> > > > > > > > > > >
> > > > > > > > > > > Benny.
> > > > > > > > > > >
> > > > > > > > > > > On Sunday, May 11, 2014 12:20:54 PM UTC+3, Julien Viet wrote:
> > > > > > > > > > > > Can you tell me the values of the String[] args in your case ?
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Julien Viet
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Saturday 10 May 2014 at 20:58, Curt Beattie wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > The following class does almost exactly what I want, except I need it to load the commands from the classpath rather than from the file system. However I can't for the life of me figure out how to do this.
> > > > > > > > > > > > >
> > > > > > > > > > > > > public class MyMain {
> > > > > > > > > > > > > public static void main(String[] args) throws Exception {
> > > > > > > > > > > > > CRaSH.main(args);
> > > > > > > > > > > > > }
> > > > > > > > > > > > > }
> > > > > > > > > > > > >
> > > > > > > > > > > > > Some help would be appreciated.
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > > > > > > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users...@googlegroups.com (javascript:) (javascript:) (javascript:) (javascript:)).
> > > > > > > > > > > >
> > > > > > > > > > > > On Saturday 10 May 2014 at 20:58, Curt Beattie wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > The following class does almost exactly what I want, except I need it to load the commands from the classpath rather than from the file system. However I can't for the life of me figure out how to do this.
> > > > > > > > > > > > >
> > > > > > > > > > > > > public class MyMain {
> > > > > > > > > > > > > public static void main(String[] args) throws Exception {
> > > > > > > > > > > > > CRaSH.main(args);
> > > > > > > > > > > > > }
> > > > > > > > > > > > > }
> > > > > > > > > > > > >
> > > > > > > > > > > > > Some help would be appreciated.
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > > > > > > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > > > > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users...@googlegroups.com (javascript:) (javascript:) (javascript:)).
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > > > > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users...@googlegroups.com (javascript:) (javascript:)).
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (javascript:) (mailto:crash-users...@googlegroups.com (javascript:)).
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (mailto:crash-users...@googlegroups.com).
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> > > > Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
> > >
> >
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse crash-users...@googlegroups.com (mailto:crash-users...@googlegroups.com).
> > >
> >
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "CRaSH User Group".
Reply all
Reply to author
Forward
0 new messages