Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / October 2007

Tip: Looking for answers? Try searching our database.

How to download metafiles using a signed applet

Thread view: 
Brian - 08 Oct 2007 22:34 GMT
I want an applet which, once launched, downloads 3 metafiles (files
that it will need later on to work properly) and proceeds into a
processing phase only if the files have been successfully fetched.

So far I do not have a solution for requesting these files and writing
them locally.

Am I following the right track with URL and HttpURLConnection, or
should I be looking into packages like the Apache Jakarta project?

Is there possibly a more straightforward way to instruct the JRE to go
get file "http://www.foo.com/dist/localdata.dat" and put it at
location "C:\localdata.dat" ?

Is there possibly some correlation between the domain mentioned in my
signing certificate and the domain from which I download any
particular file?

Thanks for any ideas,

Brian Herbert Withun
Andrew Thompson - 09 Oct 2007 00:47 GMT
> I want an applet which, once launched, downloads 3 metafiles

Easy enough done.  If they are coming from the same
server, it can be done in a sandboxed applet.  A
trusted applet could obtain them from any server
on which they available as a publicly fetchable
resource (assuming the server does not specifically
refuse connections to whatever UA the URLConnection
identifies itself as).

>..(files
> that it will need later on to work properly) and proceeds into a
> processing phase only if the files have been successfully fetched.
>
> So far I do not have a solution for requesting these files

There are a number of ways to do it.

>...and writing them locally.

Why do you want to do that?

Andrew T.
Brian - 09 Oct 2007 16:04 GMT
> Easy enough done.  If they are coming from the same
> server, it can be done in a sandboxed applet.  A
[quoted text clipped - 3 lines]
> refuse connections to whatever UA the URLConnection
> identifies itself as).

I'll have a signed applet hosted on a partner's site (not the same
company as identified in the signing cert)  The files will be coming
from the same server as the applet, though.

That being said, what is a reasonable *way* to retrieve the files?
I'm new to Java and I'm looking for some best-practices.  I have read
about HttpURLConnection and have looked briefly at Jakarta.

What's the equivalent to

C:\XCOPY www.domain.com/dist/file.dat C:\LOCALDATA\

> >...and writing them locally.
>
> Why do you want to do that?

One of the files is a java-compatible Windows DLL that automotive
repair shops will need when using this applet to interface with their
vehicle VCI.  That DLL needs to go into the Windows directory.

..or will Windows LoadLibrary find a DLL within the sandbox?

Brian Herbert Withun
Andrew Thompson - 09 Oct 2007 17:42 GMT
(DLL+metafile applet)
...
>I'll have a signed applet hosted on a partner's site (not the same
>company as identified in the signing cert)  The files will be coming
>from the same server as the applet, though.
>
>That being said, what is a reasonable *way* to retrieve the files?

Retrieving them - InputStream.  That might sound like a
dumb answer, but to make it more specific and less
dumb, I will add, to use..
a) for a resource available 'loose' on the server -
URL.openStream() for that InputStream
b) for a resource inside a jar file on the applet(/application)'s
classpath, use Class.getResource() for that URL, then see a).

The other side to your question is either using,
or storing and using them.  ..

>..classpath, Class.getResource(name) for an URL, then a)..
>I'm new to Java and I'm looking for some best-practices.  I have read
>about HttpURLConnection and have looked briefly at Jakarta.

It can be done with HttpURLConnection, but now I
check the JavaDocs, I realise it has a lot of cruft
(over URL) not needed for simply gettting an input
stream.

>What's the equivalent to
>
>C:\XCOPY www.domain.com/dist/file.dat C:\LOCALDATA\

(checks)  XCOPY    Copies files and directory trees.

>> >...and writing them locally.

I'll return to that later (if needed).

>> Why do you want to do that?
>
[quoted text clipped - 3 lines]
>
>..or will Windows LoadLibrary find a DLL within the sandbox?

Hmm.. OK.

Not in an applet, it must be located in the 'Win' directory
for the applet to use it.  *But* a web start based (and
sandboxed) applet or application can use DLLs that are
identified as nativelib's in the launch file (put on the
classpath).  The only issue with using a sandboxed JWS
app. remains these metafiles.  

Most well behaving DLLs that use external files expect
them to be in the 'same directory' so these could
(find and) use any metafiles supplied at the 'root' of
an archive also on the classpath of the JWS app.

BTW.  I just realised this was the first time I'd
mentioned Java web start (JWS) in this thread, so
in case you are unfamiliar with it, check here for
some examples. <http://www.physci.org/jws/>

I am hoping you will abandon the idea of doing this
as an applet.  That will be very problematic.

Signature

Andrew Thompson
http://www.athompson.info/andrew/

Roedy Green - 09 Oct 2007 04:12 GMT
>So far I do not have a solution for requesting these files and writing
>them locally.

Have a look at the code for Download.  It does all that.  It is part
of the package at http://mindprod.com/jgloss/filetransfer.html
Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.