I am wondering if it is somehow possible to have an OSGi environment with GoGo shell running with different consoles for input and output.
It is not very handy to write gogo commands into a console where your system is logging a lot of data.
Is there a good solution for that?
There are a number of solutions for your question.
You can use the telnet or ssh interface to gogo. Apache Felix provides both in separate bundles.
Gogo registers a CommandProcessor from which you can make a CommandSession by supplying an Input and Output Stream. It is quite easy to make a small Java Swing program that acts as a shell
Stop logging so much :-)
Related
is there any way to play inform7 from the command line? I'd like to write some automated test script that plays the play with certain commands and don't want to do it manually. Is there any way to do that?
This is easiest to do with the CLI Linux package of Inform 7. It contains a perl CLI script you can run, but you may also like to consider this alternative script I wrote: https://github.com/i7/kerkerkruip/blob/master/tools/build-i7-project
You can invoke this with
build-i7-project -p "Project Folder"
(Leave off the .inform.)
You can also run the binaries which are installed with the IDE packages by themselves instead of installing the CLI Linux package. The command line options are probably mostly the same in other operating systems, but you may need to change them slightly. If you can't get it to work, compare with what the Inform 7 IDE says when you build with it.
If what you really want to do is periodically run some test scripts that verify that your work is still performing as expected, then Inform 7 has the capability do do that from within the IDE. Take a look at chapter 24.2 of Writing with Inform for details. In combination with good use of the Skein, this should handle the more common unit-testing requirements.
Of course, if you're doing something more outré, running bash scripts from the command line may wind up being the way to go. Still, don't do any more work than you have to. :)
I am currently trying to understand various security protocol implementation like EAP in wpa_supplicant. But its very complex way by reading wpa-supplicant-devel.pdf from w1.fi.
I want to know from expert in wpa_supplicant how to start in efficient way to deep drive in it. What advance c concept should know to better understand it.
Any resource/material/website/book for this can be suggested.
Please also don't ignore this as descriptive question as you well know that its hard to start in wpa_supplicant.
Thanks in advance.
Run the wpa_supplicant on a Linux machine in verbose mode :wpa_supplicant -Dnl80211 -i wlan0 -c wpa_supplicant.conf -ddd. Use appropriate interface name (-i) and configuration file (-c). To create a simple configuration file please refer this link. With the debug messages from the above command output, browse the source. This provides a starting point to understand various terms in wpa_supplicant security.
We are using RDI (IBM Rational Developer for System i) to do cobol development work, we are eager to write automation test cases for our program, to make the testing work easier. But we don't know how to use script to compile and run cobol, which on i-series server.
For now, our solution is that we use scripts prepare test data (insert data to database/files),and then run cobol on RDI manually, finally, run scripts to check the results. It makes our work easier, but still not real automation test.
So, I want to know if there are some methods to invoke the compile&run process according to scripts, such eclipse headless or telnet technologies.
We've already found the solution: use telnet to compile/run program. Because green screen is one kind of telnet, it reliable.
I am pretty newbie by this question.
I want to know about possibilities of how to manipulate Jmeter through the console (bash or cmd).
My goal for a start consists in understanding of how to run my testplan.jmx for several URLS. For this I add "server" and "port" parameters into my testplan.
How could I can change these parameters through the console and then run Jmeter ?
Morover, I want to ask you guys to suggest any free online tutorials where I can learn more about "Jmeter in non gui mode" and possibilities for integration Jmeter between different frameworks to use for automated testing.
Thank you very much indeed.
See:
http://jmeter.512774.n5.nabble.com/How-to-Run-Jmeter-in-command-line-td2640725.html
You can launch your test plan from the command line, specifying parameters, like:
jmeter -n -t plan.jmx -Jmy_url=http://www.firsturl.com
Inside your testplan you'd reference that command line param as ${__P(my_url)}
In terms of capturing results when running in non-gui mode, you may want to see:
http://blogs.amd.com/developer/2009/03/31/using-apache-jmeter-in-non-gui-mode/
Personally, my experience is with using the GUI and writing and running test plans that way but this seems workable.
Can anyone please share their experience of invoking unix scripts from a Java EE env, either servlet or EJBs? Note that these scripts are to be invoked for real time processing and not offline processing.
Spawning processes from a Java EE container is probably not the right way to this.
If these are shell scripts they will not be portable.
If you want to use transaction support, the scripts could be rewritten as Jobs using Quartz Scheduler.
This is more likely the Java EE way to do things like that.
EDIT:With your requirements added in the commented this should work
Process process = new ProcessBuilder(command).start();
More details here
please note that if you use scripts and/or pipes (no native executables) you must include the shell to invoke the command (and setup pipes)
One possibility would be to write a small application that listens to a JMS queue and invokes the scripts. That way, the script execution is separated from the app server, so doesn't run into any spec limitations.
The biggest problem you will have is if your app server memory image is large, when you fork to run the script you may well run out of memory and have the fork fail. When you fork, the system needs to make a complete copy of the executable image. It doesn't make a physical copy, but it does need to make a virtual one. So, if you have a large Java EE heap, like 4G of real memory (i.e. not just Java heap, total process size), then you need an extra "free" 4G of real RAM and/or Swap for the fork to have enough virtual space to happen.
Yes, you're going to immediately exec sh or some other command that isn't going to suck up a gazillion resources. But the system can't know that, and so it needs to act as if it's going to have to run two copies of your Java EE container at once, even for a nanosecond.
If you don't have the resources for the fork, the fork fails.
If you're strapped for space, then what you can do is create a little mini exec launcher daemon. Then instead of your Java EE app forking the process, you just open a socket to your daemon, and IT forks the process. Obviously the expectation is that this little daemon is consuming much fewer resources than your container, so it's cheap to fork.
The daemon can be as simple taking the command line to execute over the socket, and just execing what it gets (potentially unsafe, naturally, but...), or simple rpc with a command code and some arguments. Whatever is appropriate for your project. You can write it in Java, a scripting language (Python, Perl, Ruby), whatever. Lots of ways to do that.