The short version of this question is, how can I send a message (a file path, for example) from a Java application (NetBeans plugin, to be specific) to an already-running C# WinForms executable application?
Some details.
I currently have a Windows application that I built (it's like a parser/editor for script files to help automate the process of script building using simple GUI tools for our test team). In the application, you can load a file using the app's "Load" button, hotkey, drag/drop, etc. You can also open the application from the command line with one or more file paths as parameters, and the app will launch with the given files already loaded.
On request, I cobbled together a NetBeans plugin (Java) that grabs the file path of the file that is currently in focus in NetBeans, and then executes my application with the focused file's path as parameter. This allows me to launch my app directly from NetBeans and open the file being edited in NetBeans in my app.
So what my app can do:
Launch with file loaded from CLI parameter
Load file from internal load command on-the-fly
What it can't do (what I want to add):
Load file in running instance from external message parameter on-the-fly
Load file in running instance from CLI message parameter on-the-fly
MSMQ is a solution I can't use. Saw it suggested in a lot of other threads. Things to note are that the NetBeans plugin and my app will always be on the same system, but I can't get MSMQ on all target machines.
Two suggestions:
(1) If you can figure out a way to publish an event from a Java process into the windows event log, you can definitely set up your .net app to watch for specific event types
(2) If you can arrange for the .net app to watch for files being created in a particular directory using FileSystemWatcher (maybe in %TEMP%), you can have your Java process write a file that contains whatever info you wish to pass.
Related
I’m creating a mock OS in Processing 3, and I want my OS to be able to download and run apps which have been written by a third party.
Basically, I want my OS to be able to load an application file from the user’s computer, get the Java code from the file and run that code within a window object I have created within the OS. Is there any way I can load Java code and run it within the program currently running?
I have hard coded a Settings, Calender and Notes app into my OS, but ideally they would also be kept in files of their own and loaded during the bootup sequence, as would any other applications the user has chosen to install on the OS.
I have built a Java Play app using the latest version. Currently I am running the application using the batch file that gets generated. There's a zip file created inside target->universal folder (When I go to the bin folder inside the extracted folder this batch file is available).
How can I run this in production Windows environment? This play app is a backend service that needs to run continuously. Should this be created as a Windows Service? As in, should I try to run this batch file as a Windows Service through some means? I can't find any online references on this. Any help would be much appreciated.
There are service wrappers available, that can take almost any arbitrary application and run it as a service or daemon on some operating systems. I would highly recommend that you avoid them. Writing secure, performant services for Windows is not trivial. You can however run any script using Windows TaskManager (GUI) or Task Scheduler, and it has all the knobs you need to easily control how your application runs, when it starts and what to do if it crashes.
See schtasks.exe for command line interface reference.
I have a little .jar that executes a simple system administration task and so it needs to be run with elevated privilege. I've been researching this for hours and now know that it can be done in three ways:
1) ran from an elevated cmd prompt
2) convert the .jar to .exe and bundle it with a manifest file
3) use another .jar to launch my .jar and ask for permission.
Option 1) won't work for me because this will need to be deployed to other users that won't know how to do this. Option 2) isn't ideal because I chose to write this app in Java for its portability. This will likely be run on different systems and Java seems the most compatible. So that leaves Option 3) and is where my question comes in. I can't seem to sift through the multitude of info out there on how to accomplish creating a wrapper for my app. With my specs in mind what do you all recommend for creating a wrapper .jar that will prompt the user to allow my .jar to run? Thanks
On Windows, it is possible to run a Java application either as a desktop application, or as a Windows Service in the background. In the case of a Service, the Wrapper needs to be able to be installed, removed, started, stopped, have its status queried, etc. Depending on whether the application has a GUI or is meant to be run in a command window also determines how it will be run.
On Windows systems, the most way of launching the Wrapper is to make use of dedicated batch files to perform each action of controlling the Wrapper. This makes it possible for the end user to double click on the batch file icons or set up links in menus, just have a look if you have the java runtime env.
Nice tutorial: http://wrapper.tanukisoftware.com/doc/english/qna-service.html
Here it has some other possibilities, using Dedicated Batch File, Command Based Batch File or Standalone Binary : http://wrapper.tanukisoftware.com/doc/english/launch-win.html#dedicated
Think you can do this with .bat file. Make sure you have java runtime env, so that you can execute jar file using java -jar command.
If your looking to force the user to use elevated permissions then pure Java isn't going to cut it. I suggest you write native code and use the Java Native Interface (JNI)
I would like to "link" few file extensions to my java application under windows. When user double clicks file with "linked" extension, I would like to open my app and I need to know path to file that launched app.
If you deploy the app. using Java Web Start, an interest in file-types can be declared in the launch file. See the demo. of the file services, which..
..prompts the user to associate file extension .zzz (simply a file type unlikely to clash with existing file associations) of content type text/sleepytime. ..
When the user double clicks a .zzz file, it should open in the app. Actually, the word 'prompts' there is not the whole story. If you launch the sand-boxed version you will be prompted as to associating the file-type. The trusted version does not prompt.
To add more user-control to the process, look to the IntegrationService that was introduced in 1.6.0_18 (I don't have a demo. of that one yet). You might run it at start-up, after checking with the user.
this would have to be done during installation. how are you planning on letting your user install your application?
you have to realize at this stage that you just made things a whole lot more complicated. registering file extensions means meddling with the registry. what happens if the user doesn't want your application anymore? or moves the file that launches your application?
you'll have to pick an installation creator. here's a so question about that: https://stackoverflow.com/questions/3767/what-is-the-best-choice-for-building-windows-installers
and then you'll have to learn that installer creator's language. here's how what you're asking for is done in nsis. remember that the script takes care of questions like "if the user uninstalls my application, and i didn't change the file associations at install time, should i then remove these file associations on uninstall?" so it's a bit long. here it is anyways: http://nsis.sourceforge.net/File_Association
maybe it can be done in an easier way in another installer creator.
however, in this example, you give the register function of nsis the start command for your application, and then it adds %1 to it in the start command of the windows file association. so you should give it the start command
javaw -cp installpath\yourcode.jar package.name.MainClassName
and then things should work out. this will take some experimenting of course, and you will have to be quite sure about how to start your application from the command line.
good luck!
On his blog Scott Kovatch writes:
Without getting into too much detail, typing ‘java MyAWTCode’ from a Terminal window violates a whole lot of assumptions about what an application is on Mac OS X, and needs a lot of cooperation between the AWT and the Process Manager to sort it out.
http://skovatch.wordpress.com/2011/01/03/secret-smoke-screens/
Out of curiosity - what assumptions are violated? Surely this is just a candidate for an API call with callbacks?
Sure, I can elaborate on that a bit.
The Process Manager starts with the assumption that all applications that present a UI on Mac OS X are bundled, are packaged in a folder named Application.app, binary in Contents/MacOS/Application, and most importantly, have an Info.plist to get things like the name of the application that will be shown in the application menu. When you run a Java application from the command line (Swing or SWT) there is no Info.plist, so we had to create a CFDictionary to be passed off to a private SPI that would register the application, give it a proper name in the Dock -- as opposed to just 'java' -- and could be force-quit.
Even then, it's not perfect, because the Dock also assumes it can store an alias to the bundled application when you right-click and choose Keep In Dock, but since there isn't one that fails silently. There's no way to store a shortcut or command line to start the application like Windows can.
The SWT just calls TransformProcessType, which is a start but is nowhere near sufficient to turn a Java application into a full UI application. For doing pure SWT testing and development it's enough to get you going. When you create an Eclipse RCP-based application for deployment you end up with a bundled application with the Eclipse launcher, and plugins and features, and you're ready to go.
Of course, if you go the extra mile and package your Java application into a bundle, this is all moot, but the vast majority of developers coming from other platforms don't bother and just want to run an executable JAR file or even a folder of class files with a shell script.
I am not sure what he had in mind, but I guess a big difference is the file structure: a normal MacOS X application is a bundle with the structure NameOfTheApp.app/Contents/MacOS/NameOfTheApp , and specific files in the Contents directory. When we use the terminal with a "java" command, the JVM has to create a "virtual" application specific to the Java code, and handle all the MacOS events for it. Also, when you open an application twice in the Finder, it simply activates the application the second time, while you need to launch separate applications every time you use "java MyAWTCode".