How to make java client app to download jar package from server autoly?

[Andrew Thompson]

On 1ÔÂ1ÈÕ, ÏÂÎç2ʱ36·Ö, "Andrew Thompson"
<[email protected]> wrote:

Please refrain from top-posting. It makes
threads very hard to follow.

(top-post corrected, as an example.
no guarantees on attributions)

(sealo)

I think it will be a cache usage.

That makes sense, otherwise there will be a
noticable delay at start-up, while the Jar is
fetched fresh from the server.

You might use an URLClassLoader to download
the classes initially, but you might also simply
open an generic ( URL.openStream() style)
Inputstream, get the bytes of the Jar, store those
bytes to the local file system, then add the
downloaded Jar to the classpath at run-time.

The reason I have kept focusing (to the point of
tunnel vision) on web-start, is because it provides
an inbuilt way to do not only that, but also to
update the local Jar, if the Jar on the server
is updated!

That might 'never happen', and there are also ways
for a *command* *line* based app. to check for updates
itself, but if this *might* be useful for your application,
it is getting to the point of 'reinventing the wheel', since
web-start is an established deployment technology
that is well suited to the task described.

So far, you have been very vague* about what this
application actually *does*. Could you fill in a little
detail? It might help me determine exactly what level
of privileges it needs.

(Note that this is significant for the web-start application,
which by default operates in an applet like security
sandbox - I am guessing your application ight need
extended privileges to access files, or get secure
system properties..)

* As an aside, I find it very frustrating to be discussing
technical details of an 'application'. What the heck does
it *do*? What is it, some sort of 'state secret'?

Andrew T.

 

[sealo]

threads very hard to follow.

Sorry, you are right, and I will correct it in the future.

You might use an URLClassLoader to download
the classes initially, but you might also simply
open an generic ( URL.openStream() style)
Inputstream, get the bytes of the Jar, store those
bytes to the local file system, then add the
downloaded Jar to the classpath at run-time.

Yes, I must consider the change of the jar package in the server. But,
the jar package will not change at run time. So, I want the program to
be loaded every time at the startup.

So far, you have been very vague* about what this
application actually *does*. Could you fill in a little
detail? It might help me determine exactly what level
of privileges it needs.

The client will retrieve information of the server, such as server
configuration.
1. It will use the jar package to login to the server. And a tcp
connection will be established with the Server Gatekeeper.
2. Use the interface to send the request to the server Gatekeeper.
Gatekeeper handle it and send back the information in response.
3. Client handle the response from the server. Then display it to the
local output(screen).

The process is not very complex, and it will not change local system
settings, such as file, or semaphore So, I think it will not impact
the privileges.

(Note that this is significant for the web-start application,
which by default operates in an applet like security
sandbox - I am guessing your application ight need
extended privileges to access files, or get secure
system properties..)

* As an aside, I find it very frustrating to be discussing
technical details of an 'application'. What the heck does
it *do*? What is it, some sort of 'state secret'?

I want it to be used as a Simple Java Interface, for monitoring a
telecom call server status. And in the server, we have a
gatekeeper(JAVA made) to handle the client request and send back
response.

 

[sealo]

(Post Again, Follow the TOP-Post Rule)

threads very hard to follow.

(top-post corrected, as an example.
no guarantees on attributions)

(sealo)

noticable delay at start-up, while the Jar is
fetched fresh from the server.

You might use an URLClassLoader to download
the classes initially, but you might also simply
open an generic ( URL.openStream() style)
Inputstream, get the bytes of the Jar, store those
bytes to the local file system, then add the
downloaded Jar to the classpath at run-time.

Yes, I must consider the change of the jar package in the server. But,
the jar package will not change at run time. So, I want the program to
be loaded every time at the startup.

The reason I have kept focusing (to the point of
tunnel vision) on web-start, is because it provides
an inbuilt way to do not only that, but also to
update the local Jar, if the Jar on the server
is updated!

That might 'never happen', and there are also ways
for a *command* *line* based app. to check for updates
itself, but if this *might* be useful for your application,
it is getting to the point of 'reinventing the wheel', since
web-start is an established deployment technology
that is well suited to the task described.

So far, you have been very vague* about what this
application actually *does*. Could you fill in a little
detail? It might help me determine exactly what level
of privileges it needs.

The client will retrieve information of the server, such as server
configuration.
1. It will use the jar package to login to the server. And a tcp
connection will be established with the Server Gatekeeper.
2. Use the interface to send the request to the server Gatekeeper.
Gatekeeper handle it and send back the information in response.
3. Client handle the response from the server. Then display it to the
local output(screen).

The process is not very complex, and it will not change local system
settings, such as file, or semaphore So, I think it will not impact
the privileges.

(Note that this is significant for the web-start application,
which by default operates in an applet like security
sandbox - I am guessing your application ight need
extended privileges to access files, or get secure
system properties..)

* As an aside, I find it very frustrating to be discussing
technical details of an 'application'. What the heck does
it *do*? What is it, some sort of 'state secret'?

Andrew T.

I want it to be used as a Simple Java Interface, for monitoring a
telecom call server status. And in the server, we have a
gatekeeper(JAVA made) to handle the client request and send back
response.

 

[Andrew Thompson]

...
Yes, I must consider the change of the jar package in the server. But,
the jar package will not change at run time. So, I want the program to
be loaded every time at the startup.

It does *not* have to be downloaded every time!
(Whether using web-start or not)

....
The client will retrieve information of the server, such as server
configuration.
1. It will use the jar package to login to the server. And a tcp
connection will be established with the Server Gatekeeper.
2. Use the interface to send the request to the server Gatekeeper.
Gatekeeper handle it and send back the information in response.
3. Client handle the response from the server. Then display it to the
local output(screen).

I think that scenario can be handled from the
command-line, but I *think* it might be easier
to program *repeated* client-server responses
in a simple GUI.

The process is not very complex, and it will not change local system
settings, such as file, or semaphore So, I think it will not impact
the privileges.

That is convenient - if the application can remain
fully in a 'sand-box', then it does not have to be
signed for use with web-start.

I want it to be used as a Simple Java Interface, for monitoring a
telecom call server status. And in the server, we have a
gatekeeper(JAVA made) to handle the client request and send back
response.

I think that if the client application might simply
'sit on-screen' waiting for the user to issue their
next command, or if a client-server interaction
can be *initiated* by the server (e.g. telling
clients that a particular area of the server has
gone 'off-line' or otherwise changed status)
that this will be easier to code as a basic GUI.
(but I do not have experience with CLI based
applications that require anything more than
initial run-time parameters).

Andrew T.

 

[Chris Uppal]

I want to write a command line java client program. And the program
need to use the jar package, but the package was located in the server.
I want the client program to download the jar package automarically at
the program startup.

If the JAR file on the server is accessible via HTTP, FTP, or a shared
filesystem, then all you need to do is ensure that URL to the JAR is on your
Java app's classpath, it requires no extra code. How you do that depends on
how you package your application for the end-users to run. For instance, if
your application is launched by the "java" command (possibly buried inside
some sort of script file) then you should use the -classpath argument to that
command.

You can also (if the JAR is accessible via an URL) use a
java.net.URLClassloader (as Arne has already said), which moves the added
complexity out of the application delivery/packaging mechanism and into your
own code. That may be an advantage if you have special requirements, or if
your application delivery/packaging mechanism is particularly awkward.
However, even if that is the case, you will need to understand how Java locates
and loads .class files at runtime -- and that is precisely what you need to
understand in order to use the simpler option in my first paragraph.

I am not familiar with java. Could you tell me how to do it?

I'm sorry, but you'll have to /become/ familiar with (this part of) how Java
works. It is completely fundamental to Java (not just to your problem), so
there is no easy substitute. If you are a programmer at all (I assume you are)
then you'll find it simple enough -- start with the -classpath argument to
java.exe or the $CLASSPATH (%CLASSPATH% on Windows) environment variable, and
continue from there (its better to use the -classpath parameter, but the two do
much the same thing so information about either will be useful).

-- chris

 

[Jhair Tocancipa Triana]

> sealo wrote:
> ....

Why? Or rather, why would you want to use Java to program a tool
intended to be run from within the command line, as opposed to a
program with a GUI?

Why not?

Java is by no way a language to develop only GUI applications. In fact
the javax.swing.* classes are only a small part from the whole Java
API (and the rest of the API is not there to serve GUI applications
*only*).

 

[Andrew Thompson]

Why not?

Java is by no way a language to develop only GUI applications. In fact
the javax.swing.*

Swing? Note that you are the first to mention Swing,
specifically (to my recollection). This could be done
using Swing, the AWT, ..or SWT.

...classes are only a small part from the whole Java
API (and the rest of the API is not there to serve GUI applications
*only*).

There are a lot of comments I could make at
this point, but I feel the most appropriate is
"Well ..DuHH!"

At last count, 19/20 jobs were servlet/JSP based,
with strong implicaiton of a HTML based thin client,
as opposed to any sort of 'rich client GUI'.

(And that is not even considering the Java
applications that run in headless environments/
entirely from the command line..)

Andrew T.

 

[Andrew Thompson]

....
Why not?

<http://groups.google.com/[email protected]>

Andrew T.

 

[Andrew Thompson]

Jhair Tocancipa Triana wrote: ....

(blah, blah)

Sorry about the second reply..

GG seems to be doing really ..odd things when I
attempt to link directly to a search based on
message ID.*

For example, the links to these messages are
appearing to me (when I view them through GG)
as a 'click-thru' type link..

I am hoping that folks following that link from their
own news client do not suffer the same BS?

* Which seems more robust than using the usual
links Google offers, the equivalent of which is..
<http://groups.google.com/group/comp.lang.java.programmer/msg/6806614275944435>

Andrew T.

 

[sealo]

filesystem, then all you need to do is ensure that URL to the JAR is on your
Java app's classpath, it requires no extra code. How you do that depends on
how you package your application for the end-users to run. For instance, if
your application is launched by the "java" command (possibly buried inside
some sort of script file) then you should use the -classpath argument to that
command.

You can also (if the JAR is accessible via an URL) use a
java.net.URLClassloader (as Arne has already said), which moves the added
complexity out of the application delivery/packaging mechanism and into your
own code. That may be an advantage if you have special requirements, or if
your application delivery/packaging mechanism is particularly awkward.
However, even if that is the case, you will need to understand how Java locates
and loads .class files at runtime -- and that is precisely what you need to
understand in order to use the simpler option in my first paragraph.

works. It is completely fundamental to Java (not just to your problem), so
there is no easy substitute. If you are a programmer at all (I assume you are)
then you'll find it simple enough -- start with the -classpath argument to
java.exe or the $CLASSPATH (%CLASSPATH% on Windows) environment variable, and
continue from there (its better to use the -classpath parameter, but the two do
much the same thing so information about either will be useful).

-- chris

Thanks to all of you!

 

[sealo]

Hello,
I try to add http:// into the class path, but the classpath are
seperated by colon. There will be a colon confusion.
I try like this:

java -classpath ./:http://192.168.101.145/jar/test.jar ClassName

Is there a example to show the usage of http in the classpath ? It
seems not much description to the classpath of url usage in the
reference.

 

[Andrew Thompson]

Hello,

(snip - top-posted response)

(from earlier in thread)

Sorry, you are right, and I will correct it in the future.

Forgotten *already*?

Andrew T.

 

[sealo]

filesystem, then all you need to do is ensure that URL to the JAR is on your
Java app's classpath, it requires no extra code. How you do that depends on
how you package your application for the end-users to run. For instance, if
your application is launched by the "java" command (possibly buried inside
some sort of script file) then you should use the -classpath argument to that
command.

I have try to add http url address into classpath, but it was failed at
runtime. It's Linux os, and JDK was jdk1.5.0_09.

$ java -classpath ./:./tools:http://192.168.145.101/jar/ServerPkg.jar
HelloDate
Exception in thread "main" java.lang.NoClassDefFoundError:
ServerPkg/MyService
at HelloDate.<clinit>(HelloDate.java:8)

I think this might be the wrong format in the classpath, the colon was
not only used as seperator, but also http suffix.
Could you give me a good example to this http classpath usage? I
searched the google, it seems no good example to this.

My original code was like this.

Client Host:
// HelloDate.java
import java.util.*;
import ServerPkg.*;

public class HelloDate {
static ServerPkg.MyService myService=new ServerPkg.MyService();
public static void main(String[] args) {
myService.getDate();

}
}


Server Jar Package: Class MyService.java

package ServerPkg;

public class MyService {
public void getDate() {
System.out.println("The Current time: XX:XX:XX ");
}
}

I also copy the MyService.class to client ./ServerPkg/MyService.class ,
for the HelloDate.class compile. After compile finish, I remove the
MyService.class.