«

Hi all!

I'm building an app which interfaces a tool which in turn opens files.
My app is a server app, run as service, and will open files on other
computers on the network. So, how do I open the network connections
needed to be able to access remote files? I've up until now managed
this by manually opening them with "net use" or simply browsing to the
other computer using Explorer. But manual opening is of course not an
option for a run-as-service application. I've browsed around java.net
but can't figure out if that's what I need. If I open a connection with
e.g. Socket, will it be possible to use that connection later when my
app tries to access a remote file? (I guess that translates to: Will
the opened connection be stored in the process' connection 'pool', for
later use?)

Don't know much at all about stuff like this so any help here greatly
appreciated!

Regards,
Jan

On 2 Sep 2005 02:35:51 -0700, wrote:

> I'm building an app which interfaces a tool which in turn opens files.

For update, or read-only?

--
Andrew Thompson
physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
"We're lost in a cruel paradise.."
New Order 'Someone Like You'

> computers on the network. So, how do I open the network connections
> needed to be able to access remote files?

Being able to make connections is only half the battle. The other half is
what protocol to use. Java gives you generic TCP and UDP connections. My
question is: is there a remotely accessible **service** to access those
remote files? If so, then you'll need to talk the protocol of that service,
and in this way you'll be able to access the files. Just being able to
connect to the remote machine won't just magically give you access to its
files. That would be some security hole the size of a 12-lane freeway.

> but can't figure out if that's what I need. If I open a connection with
> e.g. Socket, will it be possible to use that connection later when my
> app tries to access a remote file? (I guess that translates to: Will
> the opened connection be stored in the process' connection 'pool', for
> later use?)

Forget connection pools.. you're barking up the wrong tree here. If you know
FTP, then one possible solution to your problem is to run an FTP server on
your remote machine(s), and use Java's Socket to connect to those FTP
services.. that way you can arrange to read the remote files.

wrote:
> Hi all!
>
> I'm building an app which interfaces a tool which in turn opens files.
> My app is a server app, run as service, and will open files on other
> computers on the network. So, how do I open the network connections
> needed to be able to access remote files? I've up until now managed
> this by manually opening them with "net use" or simply browsing to the
> other computer using Explorer. But manual opening is of course not an
> option for a run-as-service application. I've browsed around java.net
> but can't figure out if that's what I need. If I open a connection with
> e.g. Socket, will it be possible to use that connection later when my
> app tries to access a remote file? (I guess that translates to: Will
> the opened connection be stored in the process' connection 'pool', for
> later use?)
>
> Don't know much at all about stuff like this so any help here greatly
> appreciated!
>

It sounds as if you are running Windows and are able to access the files
via UNC pathnames (e.g. \\servername\path\to\file). If that is the
case, simply open java.io.FileXxx as needed using the filename
"\\servername\path\to\file". (It is the underlying file system run by
the OS that handles the network connections.)

One gotcha in this scenario is that be default services will run as a
system user that typically does not have the proper authorization to
access the network paths. In this case you can configure the service to
run as a specific user that does have the proper privileges.

Be sure to test your service both when someone is logged in and when
no-one is logged in. Also, be aware that some versions of the 1.3 JRE
have bugs that can cause the JRE to terminate when a user logs out of
the machine. If you are using a 1.3 version of the JRE, search sun.com
for more information.

HTH,
Ray

--
XML is the programmer's duct tape.

Thank you all for responding. As Raymond suspected, I'm running Windows
and are able to access the files via UNC pathnames. I access the files
using the extensibility interface of a tool of ours. So I simply call
openProject("\\servername\path\to\file"). Thus, I have no control of
the actual file access. Writing my own openProject is no option. To
complicate it all a little bit more, the extensibility interface of the
tool is COM, so I use J-Integra to bridge from my app written in Java
to the COM interface. This works fine in all modes but one: when DCOM
is used to access the COM component, and the domain, user, password of
the user running the process of the COM component is explicitly given.
In this case, access to files on remote computers is not allowed.
Anyway, I've learned that my customer probably can do without this
mode.

I'll try with java.io.FileXxx. And thanks again.

/JA

> Thank you all for responding. As Raymond suspected, I'm running Windows
> and are able to access the files via UNC pathnames. I access the files
> using the extensibility interface of a tool of ours. So I simply call
> openProject("\\servername\path\to\file"). Thus, I have no control of
> the actual file access. Writing my own openProject is no option. To
> complicate it all a little bit more, the extensibility interface of the
> tool is COM, so I use J-Integra to bridge from my app written in Java
> to the COM interface. This works fine in all modes but one: when DCOM
> is used to access the COM component, and the domain, user, password of
> the user running the process of the COM component is explicitly given.
> In this case, access to files on remote computers is not allowed.
> Anyway, I've learned that my customer probably can do without this
> mode.

Gee... we're not talking platform neutrality for this project, then ? ;-S