You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Daniel McGreal <da...@redbite.com> on 2014/03/05 17:42:20 UTC
Gogo Shell, leveraging existing Java capabilities
Hi Felix users,
https://felix.apache.org/documentation/subprojects/apache-felix-gogo/rfc-147-overview.html (which has quite some formatting issues, btw).
> // add all public methods on java.lang.System as commands:
>
> g! addcommand system (loadClass java.lang.System)
> g! system:getproperties
> sun.io.unicode.encodingUnicodeLittle
> java.version 1.5.0_19
> java.class.path bin/felix.jar
> java.awt.graphicsenvapple.awt.CGraphicsEnvironment
> user.language en
> sun.os.patch.level unknown
> os.version 10.6.2
> [snip]
g! addcommand (loadClass java.lang.System)
gogo: CommandNotFoundException: Command not found: loadClass
What am I doing wrong? I have the three org.apache.felix.gogo.* jars from https://felix.apache.org/downloads.cgi
I actually want to try to call Runtime.getInstance().maxMemory(). Is this possible?
Best, Dan.
Re: Gogo Shell, leveraging existing Java capabilities
Posted by Daniel McGreal <da...@redbite.com>.
gogo: IllegalArgumentException: Cannot coerce loadclass(String) to any of []
On 5 Mar 2014, at 17:03, Guillaume Nodet wrote:
> Try the following:
> addcommand ($.context loadClass java.lang.System)
>
>
> 2014-03-05 17:42 GMT+01:00 Daniel McGreal <da...@redbite.com>:
>
>> Hi Felix users,
>>
>>
>> https://felix.apache.org/documentation/subprojects/apache-felix-gogo/rfc-147-overview.html(which has quite some formatting issues, btw).
>>> // add all public methods on java.lang.System as commands:
>>>
>>> g! addcommand system (loadClass java.lang.System)
>>> g! system:getproperties
>>> sun.io.unicode.encodingUnicodeLittle
>>> java.version 1.5.0_19
>>> java.class.path bin/felix.jar
>>> java.awt.graphicsenvapple.awt.CGraphicsEnvironment
>>> user.language en
>>> sun.os.patch.level unknown
>>> os.version 10.6.2
>>> [snip]
>>
>> g! addcommand (loadClass java.lang.System)
>> gogo: CommandNotFoundException: Command not found: loadClass
>>
>> What am I doing wrong? I have the three org.apache.felix.gogo.* jars from
>> https://felix.apache.org/downloads.cgi
>>
>> I actually want to try to call Runtime.getInstance().maxMemory(). Is this
>> possible?
>>
>> Best, Dan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Gogo Shell, leveraging existing Java capabilities
Posted by Marcel Offermans <ma...@luminis.nl>.
On 06 Mar 2014, at 13:19 , Daniel McGreal <da...@redbite.com> wrote:
> Does the Shell bundle put a CommandSession into the OSGi service registry, for example?
A CommandProcessor is exposed as a service (by the Gogo runtime bundle). You can use it to create a new CommandSession.
Greetings, Marcel
Re: Gogo Shell, leveraging existing Java capabilities
Posted by Daniel McGreal <da...@redbite.com>.
Hi again,
I realised I could get the bundle command via
addcommand context ${.context}
which I took from gosh_profile. Now the commands to setup access to Runtime commands work well.
However, when I execute the maxMemory command, I get no response to the server.
I guess this is because the object is returned from the call, and yet my line
>>> Object result = commandSession.execute(command);
>>> String reply = out.toString() + err.toString();
doesn't include it.
I'm still interested in hearing other mechanisms of integrating with delivering commands to Gogo as I feel like I'm missing out by not having that bundle available, I don't have the 'echo' (which would help in this case) or 'type' commands, for example.
Dan.
On 6 Mar 2014, at 12:19, Daniel McGreal wrote:
> Thanks Derek,
>
> If I add the shell bundle with -Dgogo.args=—no interactive, will the startup (e.g. gosh_profile) affect the commandSession I make to process server messages? If not, is there another way to achieve this? Does the Shell bundle put a CommandSession into the OSGi service registry, for example?
>
> Best, Dan.
>
> On 6 Mar 2014, at 12:11, Derek Baum wrote:
>
>> The gogo ‘bundle’ command, is not a specific command, it is actually a direct call to the BundleContext.getBundle() method.
>>
>> You can determine this using the ‘type’ command:
>>
>> g! type -t bundle
>> Bundle org.apache.felix.framework.BundleContextImpl.getBundle()
>> Bundle org.apache.felix.framework.BundleContextImpl.getBundle(long)
>> Bundle org.apache.felix.framework.BundleContextImpl.getBundle(String)
>>
>>
>> All the methods are registered as commands by the gogo shell startup:
>> (gogo startup actually executes the gosh_profile script embedded within the togo.shell bundle)
>>
>> # add methods on BundleContext object as commands
>> addcommand context ${.context}
>>
>>
>> You mentioned that you are not using the gogo.shell bundle as you do not want interactive input:
>> You can also achieve this by setting the System property -Dgogo.args=—no interactive
>>
>> —
>> Derek
>>
>>
>>
>>
>>
>>
>> On 6 Mar 2014, at 10:16, Dan <d....@gmail.com> wrote:
>>
>>> Unfortunately, when I come to execute the first command on a deployment machine, I get:
>>>
>>> org.apache.felix.gogo.runtime.CommandNotFoundException: Command not found: bundle
>>>
>>> In production, the application runs without org.apache.felix.gogo.shell, and with my own bundle which looks like this:
>>>
>>> ByteArrayOutputStream out = new ByteArrayOutputStream();
>>> ByteArrayOutputStream err = new ByteArrayOutputStream();
>>> commandSession = commandProcessor.createSession(System.in, new PrintStream(out), new PrintStream(err));
>>>
>>> and calls
>>>
>>> private synchronized String executeCommand(String command) throws Exception {
>>> out.reset();
>>> err.reset();
>>> Object result = commandSession.execute(command);
>>> String reply = out.toString() + err.toString();
>>> return reply;
>>> }
>>>
>>> when commands are received from the server.
>>>
>>> Is there anything in this setup that would lead to the above error? (Something I'm missing from the gogo.shell bundle, for example?)
>>>
>>> On 6 Mar 2014, at 09:39, Dan wrote:
>>>
>>>> g! addcommand runtime ((bundle 0) loadClass java.lang.Runtime)
>>>> g! addcommand rt (runtime:getRuntime)
>>>> g! rt:maxMemory
>>>> 1256456192
>>>>
>>>> Thanks for the help, Dan.
>>>>
>>>> On 6 Mar 2014, at 09:15, Daniel McGreal wrote:
>>>>
>>>>> Success, thank you.
>>>>> Going to try and reach the runtime now, unless someone can provide a hint?
>>>>>
>>>>> I wish to call Runtime.maxMemory() for example
>>>>>
>>>>>
>>>>> On 5 Mar 2014, at 17:06, Richard S. Hall wrote:
>>>>>
>>>>>> g! addcommand system ((bundle 0) loadClass java.lang.System)
>>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Gogo Shell, leveraging existing Java capabilities
Posted by Daniel McGreal <da...@redbite.com>.
Thanks Derek,
If I add the shell bundle with -Dgogo.args=—no interactive, will the startup (e.g. gosh_profile) affect the commandSession I make to process server messages? If not, is there another way to achieve this? Does the Shell bundle put a CommandSession into the OSGi service registry, for example?
Best, Dan.
On 6 Mar 2014, at 12:11, Derek Baum wrote:
> The gogo ‘bundle’ command, is not a specific command, it is actually a direct call to the BundleContext.getBundle() method.
>
> You can determine this using the ‘type’ command:
>
> g! type -t bundle
> Bundle org.apache.felix.framework.BundleContextImpl.getBundle()
> Bundle org.apache.felix.framework.BundleContextImpl.getBundle(long)
> Bundle org.apache.felix.framework.BundleContextImpl.getBundle(String)
>
>
> All the methods are registered as commands by the gogo shell startup:
> (gogo startup actually executes the gosh_profile script embedded within the togo.shell bundle)
>
> # add methods on BundleContext object as commands
> addcommand context ${.context}
>
>
> You mentioned that you are not using the gogo.shell bundle as you do not want interactive input:
> You can also achieve this by setting the System property -Dgogo.args=—no interactive
>
> —
> Derek
>
>
>
>
>
>
> On 6 Mar 2014, at 10:16, Dan <d....@gmail.com> wrote:
>
>> Unfortunately, when I come to execute the first command on a deployment machine, I get:
>>
>> org.apache.felix.gogo.runtime.CommandNotFoundException: Command not found: bundle
>>
>> In production, the application runs without org.apache.felix.gogo.shell, and with my own bundle which looks like this:
>>
>> ByteArrayOutputStream out = new ByteArrayOutputStream();
>> ByteArrayOutputStream err = new ByteArrayOutputStream();
>> commandSession = commandProcessor.createSession(System.in, new PrintStream(out), new PrintStream(err));
>>
>> and calls
>>
>> private synchronized String executeCommand(String command) throws Exception {
>> out.reset();
>> err.reset();
>> Object result = commandSession.execute(command);
>> String reply = out.toString() + err.toString();
>> return reply;
>> }
>>
>> when commands are received from the server.
>>
>> Is there anything in this setup that would lead to the above error? (Something I'm missing from the gogo.shell bundle, for example?)
>>
>> On 6 Mar 2014, at 09:39, Dan wrote:
>>
>>> g! addcommand runtime ((bundle 0) loadClass java.lang.Runtime)
>>> g! addcommand rt (runtime:getRuntime)
>>> g! rt:maxMemory
>>> 1256456192
>>>
>>> Thanks for the help, Dan.
>>>
>>> On 6 Mar 2014, at 09:15, Daniel McGreal wrote:
>>>
>>>> Success, thank you.
>>>> Going to try and reach the runtime now, unless someone can provide a hint?
>>>>
>>>> I wish to call Runtime.maxMemory() for example
>>>>
>>>>
>>>> On 5 Mar 2014, at 17:06, Richard S. Hall wrote:
>>>>
>>>>> g! addcommand system ((bundle 0) loadClass java.lang.System)
>>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Gogo Shell, leveraging existing Java capabilities
Posted by Derek Baum <de...@baums.org.uk>.
The gogo ‘bundle’ command, is not a specific command, it is actually a direct call to the BundleContext.getBundle() method.
You can determine this using the ‘type’ command:
g! type -t bundle
Bundle org.apache.felix.framework.BundleContextImpl.getBundle()
Bundle org.apache.felix.framework.BundleContextImpl.getBundle(long)
Bundle org.apache.felix.framework.BundleContextImpl.getBundle(String)
All the methods are registered as commands by the gogo shell startup:
(gogo startup actually executes the gosh_profile script embedded within the togo.shell bundle)
# add methods on BundleContext object as commands
addcommand context ${.context}
You mentioned that you are not using the gogo.shell bundle as you do not want interactive input:
You can also achieve this by setting the System property -Dgogo.args=—no interactive
—
Derek
On 6 Mar 2014, at 10:16, Dan <d....@gmail.com> wrote:
> Unfortunately, when I come to execute the first command on a deployment machine, I get:
>
> org.apache.felix.gogo.runtime.CommandNotFoundException: Command not found: bundle
>
> In production, the application runs without org.apache.felix.gogo.shell, and with my own bundle which looks like this:
>
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> ByteArrayOutputStream err = new ByteArrayOutputStream();
> commandSession = commandProcessor.createSession(System.in, new PrintStream(out), new PrintStream(err));
>
> and calls
>
> private synchronized String executeCommand(String command) throws Exception {
> out.reset();
> err.reset();
> Object result = commandSession.execute(command);
> String reply = out.toString() + err.toString();
> return reply;
> }
>
> when commands are received from the server.
>
> Is there anything in this setup that would lead to the above error? (Something I'm missing from the gogo.shell bundle, for example?)
>
> On 6 Mar 2014, at 09:39, Dan wrote:
>
>> g! addcommand runtime ((bundle 0) loadClass java.lang.Runtime)
>> g! addcommand rt (runtime:getRuntime)
>> g! rt:maxMemory
>> 1256456192
>>
>> Thanks for the help, Dan.
>>
>> On 6 Mar 2014, at 09:15, Daniel McGreal wrote:
>>
>>> Success, thank you.
>>> Going to try and reach the runtime now, unless someone can provide a hint?
>>>
>>> I wish to call Runtime.maxMemory() for example
>>>
>>>
>>> On 5 Mar 2014, at 17:06, Richard S. Hall wrote:
>>>
>>>> g! addcommand system ((bundle 0) loadClass java.lang.System)
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Gogo Shell, leveraging existing Java capabilities
Posted by Daniel McGreal <da...@redbite.com>.
Hi Marcel,
Thanks for your help.
On 6 Mar 2014, at 10:28, Marcel Offermans wrote:
> The error message states the command cannot be found. That's probably either caused by the fact that the bundle that supplies this command is not yet started, or the bundle is missing altogether.
I understand what the error means, but "bundle" doesn't seem to be quite a regular command (nor does loadClass in this case)?
> Remember that shell commands are registered "whiteboard style" meaning that if you startup a framework and immediately execute a script, it might fail because not all of the command bundles have been started yet.
I guess my question is, where does the bundle "command" come from, and if it's in org.apache.felix.shell, how can I access it without loading the shell bundle (which causes my application to crash as, I guess, they don't have a stdin).
> A simple way to test that is to start your script with the 'help' command, which lists all available commands.
The output from help is identical in both the development and deployment environments.
felix:bundlelevel
felix:cd
felix:frameworklevel
felix:headers
felix:help
felix:inspect
felix:install
felix:lb
felix:log
felix:ls
felix:refresh
felix:resolve
felix:start
felix:stop
felix:uninstall
felix:update
felix:which
obr:deploy
obr:info
obr:javadoc
obr:list
obr:repos
obr:source
scr:config
scr:disable
scr:enable
scr:info
scr:list
>
> Greetings, Marcel
>
>
> On 06 Mar 2014, at 11:16 am, Dan <d....@gmail.com> wrote:
>
>> Unfortunately, when I come to execute the first command on a deployment machine, I get:
>>
>> org.apache.felix.gogo.runtime.CommandNotFoundException: Command not found: bundle
>>
>> In production, the application runs without org.apache.felix.gogo.shell, and with my own bundle which looks like this:
>>
>> ByteArrayOutputStream out = new ByteArrayOutputStream();
>> ByteArrayOutputStream err = new ByteArrayOutputStream();
>> commandSession = commandProcessor.createSession(System.in, new PrintStream(out), new PrintStream(err));
>>
>> and calls
>>
>> private synchronized String executeCommand(String command) throws Exception {
>> out.reset();
>> err.reset();
>> Object result = commandSession.execute(command);
>> String reply = out.toString() + err.toString();
>> return reply;
>> }
>>
>> when commands are received from the server.
>>
>> Is there anything in this setup that would lead to the above error? (Something I'm missing from the gogo.shell bundle, for example?)
>>
>> On 6 Mar 2014, at 09:39, Dan wrote:
>>
>>> g! addcommand runtime ((bundle 0) loadClass java.lang.Runtime)
>>> g! addcommand rt (runtime:getRuntime)
>>> g! rt:maxMemory
>>> 1256456192
>>>
>>> Thanks for the help, Dan.
>>>
>>> On 6 Mar 2014, at 09:15, Daniel McGreal wrote:
>>>
>>>> Success, thank you.
>>>> Going to try and reach the runtime now, unless someone can provide a hint?
>>>>
>>>> I wish to call Runtime.maxMemory() for example
>>>>
>>>>
>>>> On 5 Mar 2014, at 17:06, Richard S. Hall wrote:
>>>>
>>>>> g! addcommand system ((bundle 0) loadClass java.lang.System)
>>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Gogo Shell, leveraging existing Java capabilities
Posted by Marcel Offermans <ma...@luminis.eu>.
The error message states the command cannot be found. That's probably either caused by the fact that the bundle that supplies this command is not yet started, or the bundle is missing altogether.
Remember that shell commands are registered "whiteboard style" meaning that if you startup a framework and immediately execute a script, it might fail because not all of the command bundles have been started yet.
A simple way to test that is to start your script with the 'help' command, which lists all available commands.
Greetings, Marcel
On 06 Mar 2014, at 11:16 am, Dan <d....@gmail.com> wrote:
> Unfortunately, when I come to execute the first command on a deployment machine, I get:
>
> org.apache.felix.gogo.runtime.CommandNotFoundException: Command not found: bundle
>
> In production, the application runs without org.apache.felix.gogo.shell, and with my own bundle which looks like this:
>
> ByteArrayOutputStream out = new ByteArrayOutputStream();
> ByteArrayOutputStream err = new ByteArrayOutputStream();
> commandSession = commandProcessor.createSession(System.in, new PrintStream(out), new PrintStream(err));
>
> and calls
>
> private synchronized String executeCommand(String command) throws Exception {
> out.reset();
> err.reset();
> Object result = commandSession.execute(command);
> String reply = out.toString() + err.toString();
> return reply;
> }
>
> when commands are received from the server.
>
> Is there anything in this setup that would lead to the above error? (Something I'm missing from the gogo.shell bundle, for example?)
>
> On 6 Mar 2014, at 09:39, Dan wrote:
>
>> g! addcommand runtime ((bundle 0) loadClass java.lang.Runtime)
>> g! addcommand rt (runtime:getRuntime)
>> g! rt:maxMemory
>> 1256456192
>>
>> Thanks for the help, Dan.
>>
>> On 6 Mar 2014, at 09:15, Daniel McGreal wrote:
>>
>>> Success, thank you.
>>> Going to try and reach the runtime now, unless someone can provide a hint?
>>>
>>> I wish to call Runtime.maxMemory() for example
>>>
>>>
>>> On 5 Mar 2014, at 17:06, Richard S. Hall wrote:
>>>
>>>> g! addcommand system ((bundle 0) loadClass java.lang.System)
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Gogo Shell, leveraging existing Java capabilities
Posted by Dan <d....@gmail.com>.
Unfortunately, when I come to execute the first command on a deployment machine, I get:
org.apache.felix.gogo.runtime.CommandNotFoundException: Command not found: bundle
In production, the application runs without org.apache.felix.gogo.shell, and with my own bundle which looks like this:
ByteArrayOutputStream out = new ByteArrayOutputStream();
ByteArrayOutputStream err = new ByteArrayOutputStream();
commandSession = commandProcessor.createSession(System.in, new PrintStream(out), new PrintStream(err));
and calls
private synchronized String executeCommand(String command) throws Exception {
out.reset();
err.reset();
Object result = commandSession.execute(command);
String reply = out.toString() + err.toString();
return reply;
}
when commands are received from the server.
Is there anything in this setup that would lead to the above error? (Something I'm missing from the gogo.shell bundle, for example?)
On 6 Mar 2014, at 09:39, Dan wrote:
> g! addcommand runtime ((bundle 0) loadClass java.lang.Runtime)
> g! addcommand rt (runtime:getRuntime)
> g! rt:maxMemory
> 1256456192
>
> Thanks for the help, Dan.
>
> On 6 Mar 2014, at 09:15, Daniel McGreal wrote:
>
>> Success, thank you.
>> Going to try and reach the runtime now, unless someone can provide a hint?
>>
>> I wish to call Runtime.maxMemory() for example
>>
>>
>> On 5 Mar 2014, at 17:06, Richard S. Hall wrote:
>>
>>> g! addcommand system ((bundle 0) loadClass java.lang.System)
>>
>
Re: Gogo Shell, leveraging existing Java capabilities
Posted by Dan <d....@gmail.com>.
g! addcommand runtime ((bundle 0) loadClass java.lang.Runtime)
g! addcommand rt (runtime:getRuntime)
g! rt:maxMemory
1256456192
Thanks for the help, Dan.
On 6 Mar 2014, at 09:15, Daniel McGreal wrote:
> Success, thank you.
> Going to try and reach the runtime now, unless someone can provide a hint?
>
> I wish to call Runtime.maxMemory() for example
>
>
> On 5 Mar 2014, at 17:06, Richard S. Hall wrote:
>
>> g! addcommand system ((bundle 0) loadClass java.lang.System)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Gogo Shell, leveraging existing Java capabilities
Posted by Daniel McGreal <da...@redbite.com>.
Success, thank you.
Going to try and reach the runtime now, unless someone can provide a hint?
I wish to call Runtime.maxMemory() for example
On 5 Mar 2014, at 17:06, Richard S. Hall wrote:
> g! addcommand system ((bundle 0) loadClass java.lang.System)
Re: Gogo Shell, leveraging existing Java capabilities
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 3/5/14, 12:03 , Guillaume Nodet wrote:
> Try the following:
> addcommand ($.context loadClass java.lang.System)
Or:
g! addcommand system ((bundle 0) loadClass java.lang.System)
You need to give it a class loader for doing the loadClass...
-> richard
>
>
> 2014-03-05 17:42 GMT+01:00 Daniel McGreal <da...@redbite.com>:
>
>> Hi Felix users,
>>
>>
>> https://felix.apache.org/documentation/subprojects/apache-felix-gogo/rfc-147-overview.html(which has quite some formatting issues, btw).
>>> // add all public methods on java.lang.System as commands:
>>>
>>> g! addcommand system (loadClass java.lang.System)
>>> g! system:getproperties
>>> sun.io.unicode.encodingUnicodeLittle
>>> java.version 1.5.0_19
>>> java.class.path bin/felix.jar
>>> java.awt.graphicsenvapple.awt.CGraphicsEnvironment
>>> user.language en
>>> sun.os.patch.level unknown
>>> os.version 10.6.2
>>> [snip]
>> g! addcommand (loadClass java.lang.System)
>> gogo: CommandNotFoundException: Command not found: loadClass
>>
>> What am I doing wrong? I have the three org.apache.felix.gogo.* jars from
>> https://felix.apache.org/downloads.cgi
>>
>> I actually want to try to call Runtime.getInstance().maxMemory(). Is this
>> possible?
>>
>> Best, Dan.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Gogo Shell, leveraging existing Java capabilities
Posted by Guillaume Nodet <gn...@apache.org>.
Try the following:
addcommand ($.context loadClass java.lang.System)
2014-03-05 17:42 GMT+01:00 Daniel McGreal <da...@redbite.com>:
> Hi Felix users,
>
>
> https://felix.apache.org/documentation/subprojects/apache-felix-gogo/rfc-147-overview.html(which has quite some formatting issues, btw).
> > // add all public methods on java.lang.System as commands:
> >
> > g! addcommand system (loadClass java.lang.System)
> > g! system:getproperties
> > sun.io.unicode.encodingUnicodeLittle
> > java.version 1.5.0_19
> > java.class.path bin/felix.jar
> > java.awt.graphicsenvapple.awt.CGraphicsEnvironment
> > user.language en
> > sun.os.patch.level unknown
> > os.version 10.6.2
> > [snip]
>
> g! addcommand (loadClass java.lang.System)
> gogo: CommandNotFoundException: Command not found: loadClass
>
> What am I doing wrong? I have the three org.apache.felix.gogo.* jars from
> https://felix.apache.org/downloads.cgi
>
> I actually want to try to call Runtime.getInstance().maxMemory(). Is this
> possible?
>
> Best, Dan.