I'm trying to make an java application to manage Linux servers from a web interface.
It is a bad idea to perform each task by calling bash shell ?
Are there any other options other than those to use C, Perl or another language?
It's not necessarily a bad idea to use bash to do the actual work. It would help if you gave us more of an idea what exactly the web interface was changing.
Java in particular does not provide much system-specific controls, because it was designed as a cross-platform language, so putting specific platform tools in would go against it's purpose.
You could certainly do it that way. Ideally you'd open up a port and accept specially crafted, specific actions which perform only the intended actions (an interface server) through a socket library.
I should think that the disadvantage(s) of calling Bash scripts for your commands is all related to error handling and return values. Each of your Bash scripts will need to return sensible, useful information to the Java app in the case of failures (or even successes). And you'll probably want a common interface for that such that each Bash script, no matter its function, returns the same types so that the Java can interpret it easily.
So, in that sense, making the changes from your Java program reduces the complexity of handing the information back and forth. On the other hand, if Bash is easier for you, you may find it more fast and flexible.
Opening up a single bash shell and sending commands (and properly parsing results) shouldn't be bad. It does tie your program to a single OS and even a single shell, but that's the nature of what you are trying to do.
What I wouldn't do is open a shell for each command and close it after each result. It seems to me that would cause unnecessary thrashing when many commands were executed in a row.
Security concerns jump at me. If you have a form like "type command" then someone clever could exploit some things. For example "configure network" is fine but "configure network; install rootkit" can be typed because a semi-colon allows commands to be chained.
All in all, this is not tight integration. If this is a personal project, go for it. It's a good learning project to turn a procedural script into a java program. If this is a serious effort to recreate the many various webapp admin tools there are, I'd seriously suggest skipping this. The VPanel/CPanel things I've seen I hate. There used to be a php based linux admin thing that looked ok but I just find them easily to learn, easy to outgrow because the net and community is full of command line knowledge.
If you are trying to automate a large deployment, look at the ruby-based puppet. It looks really neat.
I have a socket server were I perform different operations (using ifconfig by calling shell for example) and I plan to integrate an client in a JSF application.Because I'm not experienced ant I intend to make it my graduation project, but I'm not so sure if calling bash from java to configure a linux box is a good solution.
Java does have some Linux-configuring classes (well, at least, OpenJDK does). Check OperatingSystemMXBean or something like that.
You're beter to write your own server configuration utility in the language you prefer, sanitize it, make it secure and then call it via bash from your java app.
There are two questions here:
Should you try to do the configuration work in Java, or should you externalize it?
Assuming that you have externalized it, should you use bash scripts.
In this case, the answer to question 1) depends. This kind of thing can be difficult to implement in pure Java. This leaves two choices; externalize the task using a Process, or try to do it in a native code library via JNI or JPA. The latter approach is complicated and gives you JVM crashes if you make a mistake, so I would rule that out.
On the other hand, if you can find a good standard or 3rd party Java API that does what you need (without infesting your JVM with flakey JNI, etc), you should use that.
The answer to 2) is that bash scripts will work as well as any other scripting language. I think that using scripts gives you a bit more flexibility. For example, if you need to do things to compensate for differences in the different flavours of Linux, UNIX or maybe even Windows (!) you can put this into the externalized scripts. (A corollary is that the scripts need to be configurable, so don't embed them in your source code!)
Another alternative might be to run the commands (e.g. ifconfig) directly, using a fully qualified command name and supplying the arguments as an array of strings, etc. But unless your app is going to run the external command 100s of times a minute, it is probably not worth the (Java) coding effort and the loss of flexibility / configurability.
A lot of the response would depend on why you're doing this and why other more obvious solutions aren't possible. Knowing why you would choose to roll your own as opposed to installing Webmin would be good, or why you're choosing to use Web UI at all as opposed to VNC to control the box. There are some obvious responses to the later (firewall issues for instance), but there's no immediately obvious reason for the former. Without knowing more about the requirements, answering questions about implementation details like bash scripts versus perl or C is meaningless.
Related
I want to access Java library within Ruby, in example Kafka already give jar for every operation, what things I need to do if I want to use it from Ruby?
Like maybe I just need to run shell command to run the Jar within Ruby, or do I need to port the library in Ruby? If it comes down to porting the library, how to do that too?
Thank you in advance
PS: The Java, Ruby, or Kafka are just examples. What I need to know is the big picture how to porting a library. Of course if you add some code example too I'll be more than happy :)
I agree with Aetherus that the fastest and most convenient way is to use JRuby. However I believe there other options than communicating with external Java processes. What to choose probably depends on what code you want to call. I see at least two other options.
Wrap the Java code you want to call in a main program and call it on the command line. This will be slow since Java needs to start and that takes forever but may be a fast way forward in some cases.
Call the Java code from C code that you compile with your Ruby. This will still need to load the JVM but you could probably make it happen only once. I found an article outlining how to get around doing it with JNI.
Both these paths will probably cause you a lot of pain but if it is important to stay on MRI it may be worth the trip. Have fun!
With JRuby, you can import the jar file, then include the classes you need in that jar:
require 'java'
require '/path/to/your.jar'
include_class 'com.really.long.ClassName'
But with Ruby implementations other than JRuby, you have no choice but to communicate with external java processes (through socket, IPC, kill, ...).
We've been working on a quite specific coding project recently. What we want to do is:
Use Java applications to do tasks impossible (or at least very diffucult) to accomplish in PHP
Control those Java programs with Joomla 3.0
We've found out that there is support for PHP Scripts in Joomla by using this extension or we could create our own module by using this.
My question is: Is there a way to call programs / execute commands in a more practical manner than using the PHP functions shell_exec() or exec() or using popen()?
Especially since these Java programs will run under a different user (on a Windows Server ...).
Thanks in advance!
Do not use such components. This is dangerous no matter what creator says. I'm Joomla extension developer and believe me it can ruin your application and make more problems and benefits. Depends on what you want to archive and how big will be your project you have few possibilities:
1. Create component that will execute commands
Something similar to what U did but based on custom created component. Its fastest and cheapest way. Problem starts when your Java application will use more resources then website (interface). So its more like good solution for start.
2. Create component that will contact application written in Java via API
This is good solution if your Java application use a lot of resources. You can run it on several servers, manage servers load so clients gets results faster etc. This gives you many possibilities, flexibility but is
harder to implement and will cost more.
3. Just use applet running on clients computer (if your application allows it)
Simple, effective, costs less but also can be impossible depending on what tasks application have to run.
Suppose i want to search some text in a file. I want to know when we should use system utilities/programs like grep and when we should use Java API's like reading a line, and then search the text in that line or use java Scanner class.
I want to understand the trade-offs between the two approaches. I mean, suppose if we use grep, then will there be communication overhead between JVM and the grep process? Is creation of a new OS process for grep an overhead?
Does grep performs better than normal java file search?
Please help...
Yes, there will be an overhead. Starting an external process and communicating with it is costly. And moreover, many systems don't have a grep command. If you want to make your Java code portable, don't rely on OS-specific commands.
Another problem is that OS commands will be able to search (for example) in files, but not in your in-memory data structures.
You're basically trading off system independence for the perceived gain of the tool, in some cases this can't be avoid.
Not every system will have the tools you want installed, in the locations you think they should be or the version you need.
Even if you can deploy the tools with your application, you will need to provide an implementation for each of your targeted platforms.
Sure, it's easy to say "it will never be run on X", but can never come around real quick ;)
There is also the added over head of executing and managing the IO of the external applications, while not difficult, it's much more complex that a well written Java API.
As I said, sometimes, you simply don't have a choice (I have some media inspection tools that I use on Windows and Mac that I'm not about to try and implement in Java, not because it can't be, but because it's complex and time consuming and somebody has already done it (with a native program)).
You need to balance the choice over what the benefits are of the external command weight against the issues of using it. You should also investigate if a API has already begin developed that might solve the problem at hand.
IMHO
We have a scheduled task written in Java that is failing on Windows platforms because sometimes the files it needs to delete are still in use. Is there a way from within Java that I can see what processes are using a file and get information on them?
I thought I would add that I am willing to use JNA or JNI if necessary, and I assume it is going to be.
I asked a similar question on Github for the JNA project and #matthiasblaesing wrote a code to accomplish this.
The code is here.
It prints a list with all the running processes in the format: <exe>: <type>: <path>.
One dirty way to do it is to run your application with administrative privileges and invoke a command utility such as Handle using a ProcessBuilder.
You can use the excellent Sysinternals Process Explorer to do this, and it's not limited to Java processes.
See this posting for details. I don't know how to invoke this functionality from java, however.
My own preliminary answer (please, someone do better!):
Ideally, I'd like to learn how to programmatically do what tools like Process Explorer, unlocker, handler, etc., do, and then call that from Java with JNA or similar. But it looks like that involves data structures that change for each Windows release, so it sounds very fragile. The system call involved appears to be named NtQuerySystemInformation.
It looks like in cases like we are dealing with, the preferred approach for Windows Vista onward is to use the "restart manager API," which triggers a system restart, clearing all open filehandles. (source: http://social.msdn.microsoft.com/Forums/sv/netfxbcl/thread/37dc9843-2583-41fc-8260-b78183aa4bed) We sure don't want to do that, if we can help it.
Other than the Java language itself, you have to learn the java framework. Similiar to how you have to learn the .net framework in addition to the language (C#/VB).
How important is it to know unix? Or rather, what unix areas should one focus on?
Seeing as many people run java based applications (desktop/web) on unix boxes, what sort of unix skills do you need? Are we just talking basic directory traversing, creating files, etc or is there much more to it?
The answer as read from Sun marketing material is that Java is cross platform, so you don't.
The practical answer is that you need to know enough to get your own application up and running on the platform where you plan to use it. Getting to know Apache or Tomcat configuration helps if you're working with web development, and so does knowing how to use the basic network analysis tools - the ifconfig, netstat and traceroute commands are all useful. File permission tools are also a must for getting a system working - look into chmod and chown and how those commands work.
Desktop systems have it easier, since most windowing systems are very good at working cross platform, but you still need to know a little bit about how the file system and permissions are structured.
Really, you don't need unix skills directly for writing java-based applications. However, if you want to develop java-based applications on unix boxes and deploy there, you want a good working understanding of how to operate and administer a unix box.
But for the areas you mention (directory traversing, creating files), you'll be using Java APIs that only occasionally touch on Unix-specific ("\n" vs "\r\n", directories rooted at "/", etc.) information. When they do touch, it's not something you need to know in a programming sort of way, it's something you need to know in a user/administrator sort of way.
Not important for the language it self.
You can learn java very well and never have touched a unix box at all.
If you want to deploy on a unix server however you should know just the basics.
File paths, new lines, permissions, etc. but the knowledge needed can be acquired after a few hours in the typing in the terminal.
Most of the os specifics are abstracted into the language from the beginning. Those that cannot be abstracted ( such as cron for instance ) are left behind.
You don't really need Unix skills to use Java, but if you do you'll have a good toolbox relevant for any kind of development. I certainly appreciate the ability to grep my entire source tree for files, use Perl for code generation and so forth. Even a simple matter of counting all lines of source code can be hard to do in a GUI only world. Knowing the basic Unix command line tools will make you a better developer imo.
I think your metaphor means you should learn Java library in addition to the language itself.
Certainly knowing UNIX will help a bit as it increases your general knowledge, but I don't think it's really directly related to Java at all.
As well as knowing how to traverse directories, you need to be able to edit and grep files. You need to know how do do some basic process management also. But the level of detail you need depends on what you want to do on a unix system. Eg. web development requires that you run a web container such as tomcat. You will probably want to learn the package manager of your system of choice.
It depends on your OS. You can do Java development on Windows in which case no Unix/Linux knowledge is required. That said, even on Windows GNU/Cygwin utilities can be helpful.
I assume that you are talking about learning and not developing a full scale project.
Because of the JVM, which by vision should provide a uniform API towards the programmers, regardless of the underlaying system, Java programs are meant to be written in a way that is not specific to the underlaying system (up to the point of using JNI etc').
That means that as a writer of small programs for learning,
your knowledge of the underlaying system should be minimal.
If you are not using IDE, you should at least know how to run 'javac', 'java' from the command line, and to test your program.
If you are Using an IDE like Eclipse, from the point that the IDE is running, you should expect an experience that is almost isolated from the system underneath.
However keep in mind that this is the vision, and it is always advised to know at least a bit about what's going on on your own system.
You don't need to know *NIX to develop a Java application, maybe if you're going to run it on a *NIX machine or if it uses something very attached to *NIX it'll be good if you know the basis about file names and permissions, for example.
The need of knowing *NIX comes with the need of deploying the app on a *NIX server. If this is the case it'll be good if you know something about system variables (set the JAVA_HOME, for example), the tipicall directory structure of a *NIX machine, and basic use (creating files, directories, deleting, symlinks...).
I think it's very good to know some scripting (bash, csh, sh). Depending of the complexity of the deployment this can give you extra points at the look of your boss for example.