Wert an laufenden Java-Prozess übergeben

[threadi]

Hi,

ich weiß leider nicht unter welchem Stichwort ich dazu etwas finden könnte. Folgendes würde ich gerne umsetzen:
Wenn jemand in einem Browser auf einen Link klickt der ein spezielles Protokoll (nicht http sondern z.B. javaforum://) enthält, soll der Client automatisch eine Java-Datei aufrufen die in dem Link enthaltene Werte an eine zweite, bereits laufende Java-Instanz weitergibt.

Der Part mit dem eigenen Protokoll und der Weitergabe an die erste Java-Datei habe ich bereits gelöst (keine Sorge: ist nur für einen begrenzten Personenkreis und ja, hat mit Java wenig zu tun). Woran ich scheitere ich die Übergabe der Werte von der ersten an die 2. bereits laufende Java-Instanz. Wie ich an die Prozess-ID komme habe ich schon herausgefunden, aber wie spreche ich nun diesen Prozess an und vor allem: wie übergebe ich ihm den oder die Werte? Wenn mir jemand dazu ein Stichwort dazu nennen könnte wäre ich glücklich

threadi

 

[Xyz1]

Sockets

 

[threadi]

Über die wollte ich nicht gehen da die Software auf Client-PCs läuft und ich dort nicht unbedingt einen Port öffnen wollte. Oder siehst Du das nicht als Problem an?

 

[Xyz1]

Doch, aber es muss ja gar kein Port für Außen geöffnet werden. Eine andere IPC gibt es in Java nicht. (Außer ein paar obsolete Methoden).

 

[Xyz1]

Also soweit mir bekannt gibt es noch Dateien und RMI.

 

[tommysenf]

Named Pipes sind für deinen Anwendungsfall eventuell eine Alternative

Named Pipes with Java

In this post, we will discuss using Named Pipes with Java. Let’s start with a brief overview of Pipes and Named Pipes. Overview: A pipe is a channel of communication between two processes, al…

cdimascio.wordpress.com

 

[thecain]

Das ist ja auch einfach nur ein File, oder nicht?

 

[tommysenf]

Das ist ja auch einfach nur ein File, oder nicht?

Eher ein Puffer nach dem FIFO Prinzip. Im Gegensatz zu Files kann man Named Pipes u.a. nicht in Java erzeugen.

 

[White_Fox]

Wenn es keine Datei und kein Socket sein soll, könntest du es auch mit einer virtuellen COM-Schnittstelle lösen. Irgendwo hab ich ein Programm rumzuliegen, daß jeweils zwei solcher COM-Ports, die virtuell zusammengestöpselt sind, zur Verfügung stellt. Sprich: Was man in COM-Port A reingießt, kommt aus COM-Port B wieder raus und umgekehrt. So in der Art meine ich das, nur das halt der eine COM-Port in deinem Programm drinsteckt.

Ich glaub sogar das Programm war Open Source, leider hab ich den Namen vergessen. Das wäre aber wohl keine reine Java-Lösung mehr, und sicherlich auch reichlich aufwändig. Datei und Socket sind da deutlich einfacher.

 

[threadi]

Hey,

danke für eure Antworten vor einigen Wochen. Hab mich inzwischen für named pipes über JNA entschieden (vor allem weil JNA in dem Projekt ohnehin bereits genutzt wird) und auch implementiert. Das funktioniert auch grundsätzlich gut. Bis auf ein Problem: die Anwendung, die die named pipe öffnet läuft mit vollen Admin-Rechten. Die Anwendung, die Werte an die named pipe übergeben soll, läuft ohne diese. Daher funktioniert das bisher noch nicht so wie es soll. Wenn beides mit vollen Adminrechten läuft funktioniert es perfekt.

Hier der Code mit der die named pipe in Java geöffnet wird:

WinBase.SECURITY_ATTRIBUTES saAttr = new WinBase.SECURITY_ATTRIBUTES();
        saAttr.dwLength = new WinDef.DWORD(saAttr.size());
        saAttr.bInheritHandle = true;
        saAttr.lpSecurityDescriptor = null;
        
        // create the named pipe with the defined name
        HANDLE hNamedPipe = Kernel32.INSTANCE.CreateNamedPipe(
                pipename,                                                                    // name of the pipe
                WinBase.PIPE_ACCESS_DUPLEX,                                                    // dwOpenMode
                WinBase.PIPE_TYPE_BYTE | WinBase.PIPE_READMODE_BYTE | WinBase.PIPE_WAIT,    // dwPipeMode
                1,                                                                            // nMaxInstances,
                Byte.MAX_VALUE,                                                                // nOutBufferSize,
                Byte.MAX_VALUE,                                                                // nInBufferSize,
                1000,                                                                        // nDefaultTimeOut,
                saAttr                                                                        // lpSecurityAttributes
        );

Soweit ich schon rausfinden konnte muss ich saAttr mit einem Pointer auf einen Security Descriptor definieren. Und hier hört es bei mir leider auf. Das geht ziemlich tief in Windows API-Materie rein. Weiß dazu jemand hier etwas? Ich finde einige C++-Beispiele, aber steige dort einfach nicht durch um das ggfs. in Java/JNA zu übersetzen :/

 

[threadi]

Ein Tag Pause hat geholfen. Hab eine Lösung gefunden. Hier falls es andere interessiert:

SECURITY_DESCRIPTOR_RELATIVE securityDescriptor = Advapi32Util.getFileSecurityDescriptor(new File(configDir, "log.txt"), false);
        
        // define the security-settings for named pipe
        WinBase.SECURITY_ATTRIBUTES saAttr = new WinBase.SECURITY_ATTRIBUTES();
        saAttr.dwLength = new WinDef.DWORD(saAttr.size());
        saAttr.bInheritHandle = true;
        saAttr.lpSecurityDescriptor = securityDescriptor.getPointer();

Hintergrund: ich hole einfach die DACL und SACL von einer anderen Datei, die die Anwendung selbst schreibt und verwaltet, und gebe deren Pointer an die Security-Attributes. Klappt bei mir auf bisher 3 Testgeräten problemlos.