 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 2007How to make java client app to download jar package from server autoly?
Hello, 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? .... > 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. Andrew Thompson wrote on 31.12.2006 12:54: > .... >> 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 wrote on 31.12.2006 12:54: > > .... [quoted text clipped - 5 lines] > > 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. Andrew Thompson wrote on 31.12.2006 14:24: [...] >>> 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? > [quoted text clipped - 3 lines] > 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 > 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 >> Andrew Thompson wrote on 31.12.2006 12:54: >>> .... [quoted text clipped - 9 lines] > 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 [quoted text clipped - 14 lines] > 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 .... (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. > .... > (snip) [quoted text clipped - 10 lines] > > Andrew T. 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 > > .... > > (snip) [quoted text clipped - 8 lines] > > 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 [quoted text clipped - 4 lines] > 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. >>> .... >>> (snip) [quoted text clipped - 24 lines] > you are refering to your own builds and such) needs to > 'choose a file' to run, right? 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? [quoted text clipped - 8 lines] > 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 [quoted text clipped - 5 lines] > 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 Hello, dear all, 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. .. > ..I will try to use "URLClassLoader" to have a try. Are you going to cache the jar locally, for future use? Andrew T. I think it will be a cache usage. 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. > 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. > > <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. > 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 [quoted text clipped - 5 lines] > 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. > > > <andrewtho...@gmail.com> wrote:Please refrain from top-posting. .. > > 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. [quoted text clipped - 4 lines] > 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. (Post Again, Follow the TOP-Post Rule) On 1月1日, 下午4时16分, "Andrew Thompson" <andrewtho...@gmail.com> wrote: > > On 1月1日, 下午2时36分, "Andrew Thompson" > > <andrewtho...@gmail.com> wrote:Please refrain from top-posting. It makes [quoted text clipped - 17 lines] > 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 [quoted text clipped - 13 lines] > 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 [quoted text clipped - 7 lines] > > 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. > > 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.  SignatureC. Benson Manica | I *should* know what I'm talking about - if I cbmanica(at)gmail.com | don't, I need to know. Flames welcome. > .... >> 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 > .... >> 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*). Signature-- Jhair > > sealo wrote: > > .... [quoted text clipped - 5 lines] > > Why not? <http://groups.google.com/groups?selm=1167571456.413876.322520@48g2000cwx.googleg roups.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. ... > > 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 wrote: > > .... > >> I want to write a command line java client program. > > > Why? ... > Why not? <http://groups.google.com/groups?selm=1167571456.413876.322520@48g2000cwx.googleg roups.com> Andrew T. > Hello, > 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? 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 > 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. Arne Arne Vajh?j 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. [quoted text clipped - 4 lines] > 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. ( 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. >>> 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. [quoted text clipped - 19 lines] > 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 > 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 On 1月2日, 上午12时15分, "Chris Uppal" <chris.up...@metagnostic.REMOVE-THIS.org> 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. [quoted text clipped - 25 lines] > > -- chris Thanks to all of you! :-) 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. On 1月2日, 上午12时15分, "Chris Uppal" <chris.up...@metagnostic.REMOVE-THIS.org> 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. [quoted text clipped - 25 lines] > > -- chris > 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. On 1月2日, 上午12时15分, "Chris Uppal" <chris.up...@metagnostic.REMOVE-THIS.org> 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. [quoted text clipped - 6 lines] > 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 [quoted text clipped - 14 lines] > > -- chris Free MagazinesGet 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 ...
|
Reply to this Message
|
 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.