Talking to Java

Hi,

I'm trying to connect to a Java application from within Dolphin. Basically I
have to set a classpath, start a command (java class), set a couple of
parameters, flush some XML and then capture the XML that is returned by the
Java app.

I can do the first bit through a command line (similar to the Hello World
example from my previous mail) and then flush via files but I can imagine
there's a better way.

Basically this is the command line version:

jview -cp %CLASSPATH% class -param1 -param2 file:c:\somexml.xml >result.xml

Any hints how I can start that app and talk through a handle with it?

Thanks in advance

Ted

"Ted Bracht" <[hidden email]> wrote in message
news:8vm80m$4giio$[hidden email]...
>
> I'm trying to connect to a Java application from within Dolphin.
>...
> Basically this is the command line version:
>
> jview -cp %CLASSPATH% class -param1 -param2 file:c:\somexml.xml
>result.xml
>
> Any hints how I can start that app and talk through a handle with it?

If running on the Microsoft VM, then every Java object is automatically a
COM object, which means you can call it directly from Dolphin. This will be
easiest if the Java app is built into a DLL with a type library, as then the
only way you'll know its in Java at all is by the startup delay. Believe me,
this really does work. I remain blissfully ignorant of the precise details
of how it is achieved, but I believe it involves either starting from IDL
and a type library, or writing some "annotations" for the classes. You'll
have to check MSDN for further details, or perhaps someone more
knowledgeable will throw in some pearls of wisdom.

If that's not an option, or you don't have the time to research it, then a
better way to catch the output of an application without having to use a
temporary file is illustracted by the CRTLibrary>>spawnForOutput: method.
You could also redirect the input to the spawned process.

Regards

Blair

Hi Blair,

>
> If running on the Microsoft VM, then every Java object is automatically a
> COM object, which means you can call it directly from Dolphin. This will
be
> easiest if the Java app is built into a DLL with a type library, as then
the
> only way you'll know its in Java at all is by the startup delay. Believe
me,
> this really does work. I remain blissfully ignorant of the precise details
> of how it is achieved, but I believe it involves either starting from IDL
> and a type library, or writing some "annotations" for the classes. You'll
> have to check MSDN for further details, or perhaps someone more
> knowledgeable will throw in some pearls of wisdom.

This sounds super cool. Only I wouldn't have a clue how/where to start. Any
hints?

>
> If that's not an option, or you don't have the time to research it, then a
> better way to catch the output of an application without having to use a
> temporary file is illustracted by the CRTLibrary>>spawnForOutput: method.
> You could also redirect the input to the spawned process.

I've been playing with this, and it looks promising. Note that I think
there's some debugging leftover in CRTLibrary>>spawnForOutput:args:  namely
the delete of the temporary file is commented out. Quite helpful for me at
this moment though.....

>
> Regards
>
> Blair
>
>

Hi Blair,

> >
> > If that's not an option, or you don't have the time to research it, then
a
> > better way to catch the output of an application without having to use a
> > temporary file is illustracted by the CRTLibrary>>spawnForOutput:
method.
> > You could also redirect the input to the spawned process.
>
> I've been playing with this, and it looks promising. Note that I think
> there's some debugging leftover in CRTLibrary>>spawnForOutput:args:
namely
> the delete of the temporary file is commented out. Quite helpful for me at
> this moment though.....
>

for some reason the command window does not return the output. A simple test
to prove it; create a batch file 'test.bat' with the command 'dir c:\' in
it. Call this through

CRTLibrary default spawnForOutput: 'c:\xml\test.bat'

The result is an empty string.

I've been looking around in MSDN and came across the CommandLineToArgvW
command, which looked promising. However, this isn't part of the standard
image (probably because it's only supported on NT/2000?). I tried to
implement it myself, but this really is not just a little bit outside my
knowledge. This is what I did, and NOT to my surprise it didn't run:

commandLine: aString toArgvW: anInt
 <stdcall: LPWSTR CommandLineToArgvW lpstr dword>
 ^self invalidCall

Any other hints?

Thanks in advance.

Ted