How to make java client app to download jar package from server autoly?
sealo
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.
I am not familiar with java. Could you tell me how to do it?
Andrew Thompson
....
> I want to write a command line java client program.
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?
>..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.
> I am not familiar with java. Could you tell me how to do it?
If it is the GUI'd program, it could be launched using
web-start, with the Jar file being downloaded lazily
(when 1st needed) or eagerly (at time of first run).
Web-start was designed to launch GUI'd, but not
command line based, client programs.
Andrew T.
Thomas Kellerer
> sealo wrote:
> ....
>> I want to write a command line java client program.
>
> 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?
It's a very good language to write a cross-platform application be it a GUI or a
commandline app.
Thomas
Andrew Thompson
> Andrew Thompson wrote on 31.12.2006 12:54:
> > sealo wrote:
> > ....
> >> I want to write a command line java client program.
> >
> > 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?
1) I expect most things invoked from the command
line to be 'quicker than the eye can see'. Which is
not the case with any Java application, where the
JVM needs to load, loads some basic classes, load
the appliaction classes, and run.
2) Java is not well suited (from what I understand) to
adding those 'little extras' that make CLI based
programs better/bearable. Font colors, 'menus' etc.
> It's a very good language to write a cross-platform application be it a GUI or a
> commandline app.
I disagree with the latter, unless you are referring
to starting a server (or some other long running
process) from the command line, and also presuming
the application does not need to thereafter gain
input (beyond the very basic) from the end user.
(oh, and of course for those just learning programming,
no need to go rushing into GUI programming until
you've got some understanding of the language)
But then, I did want to push the web-start aspect,
which is another plus for GUI'd desktop apps. ;-)
Andrew T.
Thomas Kellerer
[...]
>>> 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?
>
> 1) I expect most things invoked from the command
> line to be 'quicker than the eye can see'. Which is
> not the case with any Java application, where the
> JVM needs to load, loads some basic classes, load
> the appliaction classes, and run.
What makes a Java app slow to start is (in most of the cases) the Swing classes
that are loaded. A pure CLI is not that slow nowadays. On my machine I can't
really detect a huge "starting phase" for e.g. a Hello World program (especially
not with Java6). Of course it depends on what the program is doing.
C:\>date +%s
1167572635
C:\>java Hello
Hello, world
C:\>date.exe +%s
1167572636
(date is a small unix utility that can output the current seconds since
00:00:00, Jan 1, 1970)
As you can see running Hello.java only took one second, which I consider
acceptable for a CLI program.
> 2) Java is not well suited (from what I understand) to
> adding those 'little extras' that make CLI based
> programs better/bearable. Font colors, 'menus' etc.
Agreed, although my understanding of a CLI is, that you invoke the program, it
carries out it's tasks and then ends. When menus come into play, I'd call it a
text-mode-GUI. But then that is probably personal "taste" ;)
Thomas
Patricia Shanahan
> Thomas Kellerer wrote:
>> Andrew Thompson wrote on 31.12.2006 12:54:
>>> sealo wrote:
>>> ....
>>>> I want to write a command line java client program.
>>> 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?
>
> 1) I expect most things invoked from the command
> line to be 'quicker than the eye can see'. Which is
> not the case with any Java application, where the
> JVM needs to load, loads some basic classes, load
> the appliaction classes, and run.
Presumably a program that needs to download part of itself from a server
is not going to be a "quicker than the eye can see".
My current research project involves a lot of simulations. I do all my
development, including testing, on various Windows XP machines. However,
they are useless when I need to do a hundred runs with different
parameters, some taking hours.
Fortunately, I have access to a Linux grid computer where I can do up to
64 jobs at a time.
A GUI would be a disaster for this type of work - there is no way I'm
going to manually enter the parameters for each simulation individually.
>
> 2) Java is not well suited (from what I understand) to
> adding those 'little extras' that make CLI based
> programs better/bearable. Font colors, 'menus' etc.
>
>> It's a very good language to write a cross-platform application be it a GUI or a
>> commandline app.
>
> I disagree with the latter, unless you are referring
> to starting a server (or some other long running
> process) from the command line, and also presuming
> the application does not need to thereafter gain
> input (beyond the very basic) from the end user.
> (oh, and of course for those just learning programming,
> no need to go rushing into GUI programming until
> you've got some understanding of the language)
>
> But then, I did want to push the web-start aspect,
> which is another plus for GUI'd desktop apps. ;-)
You did give me the impression that you thought that Java should only be
used for GUI programs. It seems now that you think it should not be used
for two special classes, non-GUI programs that need fancy console
interaction with the user, and quicker-than-the-eye-can-see programs.
Since I would use a GUI if I wanted user interaction with color etc.,
and most of my programs would take long enough to be visible anyway, I
think I'll go on using Java for command line application programming.
Patricia
Patricia Shanahan
Does the jar in question contain the whole program, or just a part of
it? In particular, is the main that you want run in that jar?
Patricia
Andrew Thompson
....
(snip)
> Fortunately, I have access to a Linux grid computer where I can do up to
> 64 jobs at a time.
>
> A GUI would be a disaster for this type of work - there is no way I'm
> going to manually enter the parameters for each simulation individually.
I don't get it. What 'non-manual' way is there to
enter parameters to a CLI based program, that is
not *also* available to a GUI'd program (if not in
the same exact way, then in some similar form)?
Andrew T.
Tom Hawtin
>
> What makes a Java app slow to start is (in most of the cases) the Swing
> classes that are loaded. A pure CLI is not that slow nowadays. On my
> machine I can't really detect a huge "starting phase" for e.g. a Hello
> World program (especially not with Java6). Of course it depends on what
> the program is doing.
> (date is a small unix utility that can output the current seconds since
> 00:00:00, Jan 1, 1970)
time is more appropriate (or ptime on Solaris):
$ time java Hi
Hello world
real 0m0.156s
user 0m0.052s
sys 0m0.020s
156 ms for running it first time. Almost good (for interactive work).
Perl does it in 7 ms. A responsive program should be in the range 50 -
140 ms.
I suppose you could start a Java process on a well known port/pipe and
connect to it from something simple.
Tom Hawtin
Patricia Shanahan
The way I use is a make file that looks at the set of parameter files in
the working directory, and generates a task for each parameter file
using it as input and a result file whose name is based on the parameter
file name as output.
There are all sorts of automation and mass production techniques that
can be used to generate, edit, and manage a collection of small, closely
related, structured text files without editing each of them individually.
Patricia
Arne Vajhøj
> sealo wrote:
> ....
>> I want to write a command line java client program.
>
> 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?
I think that many people write command line
(console) programs.
Easier to script. Can be run via a simple telnet
connection. In some cases even faster to just write
the right command line arguments.
Arne
Arne Vajhøj
It should be possible to use an URLClassLoader to
do that.
Arne
Andrew Thompson
Of course it is. Many things are possible.
OTOH, I think it might profit the OP to fill in
some of the answers to the questions already
raised on this thread (with particular attention to
how the application is used/scripted, and what it
does) before we begin to consider the best way
to deliver the required functionality to the end-user.
To put that another, simpler way.
I *suspect* the OP is not approaching the
final objective (the goal) with the best strategy,
and until we know what that objective is -
we cannot really help solve it.
( Of course, I might also be accused of snobbily
'holding on to the answer - until the OP
negotiates the standard obstacle course'
..but I don't see it that way ;)
Andrew T.
Christopher Benson-Manica
> > It's a very good language to write a cross-platform application be it a GUI or a
> > commandline app.
> I disagree with the latter, unless you are referring
> to starting a server (or some other long running
> process) from the command line, and also presuming
> the application does not need to thereafter gain
> input (beyond the very basic) from the end user.
One possibility that you omitted is an application invokable with
either a command-line or GUI interface. If need be, the command line
version can include a JMX interface for interacting with it, which is
much better than nothing, or can merely be a scaled-down version of
the GUI program for use with command-line arguments in batch mode.
--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
Arne Vajhøj
> Arne Vajhøj wrote:
>> sealo wrote:
>>> 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.
>>> I am not familiar with java. Could you tell me how to do it?
>> It should be possible to use an URLClassLoader to
>> do that.
>
> Of course it is. Many things are possible.
>
> OTOH, I think it might profit the OP to fill in
> some of the answers to the questions already
> raised on this thread (with particular attention to
> how the application is used/scripted, and what it
> does) before we begin to consider the best way
> to deliver the required functionality to the end-user.
>
> To put that another, simpler way.
>
> I *suspect* the OP is not approaching the
> final objective (the goal) with the best strategy,
> and until we know what that objective is -
> we cannot really help solve it.
I doubt it.
He stated command line program.
You started a weird subthread arguing that the OP
should use a GUI instead.
A discussion I consider rather pointless.
He asked a question about a command line program.
There are nothing wrong with using a command line
program.
He could rewrite it to be GUI.
He could also rewrite it to Python.
Since there are no technical reasons not to do
what he are doing, then I would not suggest
rewriting to GUI or rewriting to Python or
anything else.
Arne
Andrew Thompson
> Andrew Thompson wrote:
> > Patricia Shanahan wrote:
> > ....
> > (snip)
> >> Fortunately, I have access to a Linux grid computer where I can do up to
> >> 64 jobs at a time.
> >>
> >> A GUI would be a disaster for this type of work - there is no way I'm
> >> going to manually enter the parameters for each simulation individually.
> >
> > I don't get it. What 'non-manual' way is there to
> > enter parameters to a CLI based program, that is
> > not *also* available to a GUI'd program (if not in
> > the same exact way, then in some similar form)?
> The way I use is a make file that looks at the set of parameter files in
> the working directory, and generates a task for each parameter file
> using it as input and a result file whose name is based on the parameter
> file name as output.
>
> There are all sorts of automation and mass production techniques that
> can be used to generate, edit, and manage a collection of small, closely
> related, structured text files without editing each of them individually.
...mmm, Yeh-OK ..but
At some point, the 'operator' (I am not quite sure, from
your description above, whether you are referring to things
as you might expect your *end* *users* to see, or whether
you are refering to your own builds and such) needs to
'choose a file' to run, right?
I mean, the scenario above seems to link it all
to the 'current directory', so how about this?
Instead of navigating to the correct directory
and 'starting the application' as it seems the
minimum might be for this process to happen,
the user simply 'starts the application' - which
then produces a dialog asking ..
'Current Directory? Yes/No'
..if the user answers 'yes' it proceeds, if 'no',
it shows a JFileChooser to navigate to whatever
directory the process should be performed in.
Which brings me back to the point that a GUI'd
application could not only do what you described
(as far as I vaguely understand it), but do it
(slightly) more easily/slickly for the end user.
..sure it means more programming, but even for things
that I design for running in a headless environment,
if I intend to run them more than a handful of times,
I will 'wrap a GUI around it' as well.
[ It seemed to take a lot of words, to get to that
minor point.. ]
More closely focused on the OP's statement to
'use a command line' (presumably as opposed
to using a GUI), I will stress that *most* command
line apps. could be 'fitted' with a GUI if 'needed',
for instance, if you wanted to launch using
web-start..
(pauses, considers..)
You know, I never have checked specifically,
whether web-start *can* launch command-line apps. -
its just I cannot see how the user could easily
specify input, or view output - of a command-line
based, web-start application...
(wander off slowly, muttering.. '2007, already?')
Andrew T.
Patricia Shanahan
I'm my own end user. This is a research project in which I am using a
simulation as a tool. I want to optimize my total time, which means I'll
do infrastructure programming if, and only if, the result will save me
more time than it costs.
>
> I mean, the scenario above seems to link it all
> to the 'current directory', so how about this?
>
> Instead of navigating to the correct directory
> and 'starting the application' as it seems the
> minimum might be for this process to happen,
> the user simply 'starts the application' - which
> then produces a dialog asking ..
> 'Current Directory? Yes/No'
> ..if the user answers 'yes' it proceeds, if 'no',
> it shows a JFileChooser to navigate to whatever
> directory the process should be performed in.
I generally leave a PUTTY window on the grid computer's control server,
sitting in the right directory. The actual actions to fire up a series
of runs, once I have the parameter files, is something like "!qm"
followed by enter. I'm a touch typist, so the time for four keystrokes
can be ignored - most of the time is bringing up the right window, which
I would have to do anyway.
> Which brings me back to the point that a GUI'd
> application could not only do what you described
> (as far as I vaguely understand it), but do it
> (slightly) more easily/slickly for the end user.
>
> ..sure it means more programming, but even for things
> that I design for running in a headless environment,
> if I intend to run them more than a handful of times,
> I will 'wrap a GUI around it' as well.
I think you are underestimating the cost. If I were not using qmake I
would have to have some other grid-aware program throwing jobs at the
grid's queues, keeping track of the number of jobs, and adding more when
there is more work to do and the number of jobs is under the limit. Why
reinvent the wheel?
Moreover, the simulator itself would still be a command line program,
because it has to be something I can ship to a grid queue, and in any
case I don't have time to interact with them individually. A batch may
contain over a hundred runs, and up to 50 of them can be running at any
one time.
Patricia
sealo
I just want to write a simple command line java app in linux. Don't
want to cost any effort on the GUI design. Because the client need to
use the jar package in the server, so it need to download to local
firstly. And the interface in the jar package are already known. The
client just need to get the jar package and use it.
Thanks all of you!
Maybe, like Arne said, I will try to use "URLClassLoader" to have a try.
Andrew Thompson
..
> ..I will try to use "URLClassLoader" to have a try.
Are you going to cache the jar locally, for future use?
Andrew T.
sealo
On 1月1日, 下午2时36分, "Andrew Thompson"
<andrewtho...@gmail.com> wrote:
> sealo wrote:..
>
> > ..I will try to use "URLClassLoader" to have a try.Are you going to cache the jar locally, for future use?
>
> Andrew T.
Andrew Thompson
> On 1月1日, 下午2时36分, "Andrew Thompson"
> <andrewtho...@gmail.com> 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 will try to use "URLClassLoader" to have a try.
> > Are you going to cache the jar locally, for future use?
> 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
On 1月1日, 下午4时16分, "Andrew Thompson"
<andrewtho...@gmail.com> wrote:
> sealo wrote:
> > On 1月1日, 下午2时36分, "Andrew Thompson"
> > <andrewtho...@gmail.com> 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 will try to use "URLClassLoader" to have a try.
> > > Are you going to cache the jar locally, for future use?
> > 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.
>
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.
Andrew Thompson
> > You might use an URLClassLoader to download
> > the classes initially,
> 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)
> > So far, you have been very vague* about what this
> > application actually *does*. Could you fill in a little
> > detail?
...
> 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:
> ....
>> I want to write a command line java client program.
> 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*).
--
-- Jhair
Andrew Thompson
> Andrew Thompson writes:
>
> > sealo wrote:
> > ....
> >> I want to write a command line java client program.
>
> > 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?
<http://groups.google.com/groups?selm=1167571456.4...@48g2000cwx.googlegroups.com>
> 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
> Andrew Thompson writes:
> > sealo wrote:
> > ....
> >> I want to write a command line java client program.
>
> > Why?
> Why not?
<http://groups.google.com/groups?selm=1167571456.4...@48g2000cwx.googlegroups.com>
Andrew T.
Andrew Thompson
> Jhair Tocancipa Triana wrote:
...
> > Why not?
(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
On 1月2日, 上午12时15分, "Chris Uppal"
<chris.up...@metagnostic.REMOVE-THIS.org> wrote:
> sealo wrote:
> > 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
Thanks to all of you! :-)
Andrew Thompson
> Hello,
(snip - top-posted response)
(from earlier in thread)
> > > <andrewtho...@gmail.com> wrote:
> > Please refrain from top-posting. It makes
> > threads very hard to follow.
> Sorry, you are right, and I will correct it in the future.
Forgotten *already*?
Andrew T.
sealo
On 1月2日, 上午12时15分, "Chris Uppal"
<chris.up...@metagnostic.REMOVE-THIS.org> wrote:
> sealo wrote:
> > 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.
>
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.
> 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