Java-Gaming.org    
Featured games (78)
games approved by the League of Dukes
Games in Showcase (429)
Games in Android Showcase (89)
games submitted by our members
Games in WIP (466)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Setting runtime system properties programmatically  (Read 2515 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Posted 2004-08-13 16:54:24 »

Seeing as there are problems (I'd like to say bugs, but until I find explicit documentation from Sun on this subject it's hard to judge...) in java.util.logging's post-initialization loading of configuration from a different properties file is, but it works OK with the "-D" runtime parameter, is there any way of programmatically filling that runtime parameter PRIOR to the initialization?

Obviously, you can set system properties inside your classes, but this is (it seems) called too late for the logging system (I'm guessing it initializes before then). Equally, you can tell every user that they MUST start java from a command line (Mac OS X users: ?) and that they MUST use your long and complicated command line to start it.

But that's unacceptable - you completely lose the ability to have an autorunning JAR (no double click, no kernel-loading as an app, no simple "java -jar" command line).

The best I can think of so far is to try setting the system property in the static initializer of a class and keep my fingers crossed that this gets loaded and executed before ANY calls to the logging system. Perhaps if you're really careful with how you write your code, you can wing it so that your initializer happens before the logging API's classes are ever referenced, so that (one hopes) it's identical to a command-line use of -D, as far as that API is concerned?

I thought that perhaps given the number of people around here who try / need to do the same thing (e.g. -Djava.library.path= as frequently used by the various native code OpenGL etc) that someone might have an answer / workaround? And...the fact that it's used so much means an answer to my problem is likely to help quite a few others in the long run.

malloc will be first against the wall when the revolution comes...
Offline Malohkan

Senior Member




while (true) System.out.println("WOO!!!!");


« Reply #1 - Posted 2004-08-14 13:22:30 »

I haven't done this, but I think I remember someone saying you could have your jar file embedded in another jar.  The outer jar would contain a Class that would, in the main() with help from the System Class, call a .bat  that could run your inner jar with all the parameters desired.  I don't know if that's too complicated or too easy to work, but for some reason it's in the back of my mind as a solution.  Good luck! Smiley

Admin and Game Developer at
GameLizard.com
Play Rimscape!    |    Play Conquer!
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #2 - Posted 2004-08-14 13:39:14 »

It's a hack, but a pretty good idea...although i can see potential problems with profilers, debuggers, etc - maybe attaching to the wrong jvm process ?

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #3 - Posted 2004-08-15 00:07:12 »

But you wouldn't debug or profile the entire jar, you would only debug or profile the inner jar which contains your game. Thats my understanding anyway...

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #4 - Posted 2004-08-15 00:50:10 »

Quote
But you wouldn't debug or profile the entire jar, you would only debug or profile the inner jar which contains your game. Thats my understanding anyway...


Ah. Yes. *The author* would profile the inner one, but... someone who you delivered the complete package to wouldn't necessarily realise / understand that. Also, some of the developer tools that exist are less than robust in the fact of "weird" deployment/packaging like this, because it's not something they ever imagined someone doing Smiley. I'm just a little concerned of the consequences - we've all seen problems where even the mainstream dev tools fall over when you do things that are a little bit funky.

Or, to put it another way, I'd like to carry on delivering the GrexEngine core libs to customers as self-running JAR's (some of which actually fire up a GrexEngine server automatically as a form of self-test and/or bootstrap and/or as a precursor to runnign extensive diagnostics; very useful stuff when people are customizing the environment and can easily screw things up - they just run the boot code in the JAR's, which they have the source for, and use that to work out what they broke in their customized deployment).

...but it's not going to be *me* running the debugger, or the profiler, it's going to be a GE licensee.

malloc will be first against the wall when the revolution comes...
Offline kevglass

JGO Kernel


Medals: 85
Projects: 22


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #5 - Posted 2004-08-15 09:27:18 »

Doesn't this all depend on "which" system properties you're going to set.

Anything within the standard runtime which is used by default this isn't possible without what I could only see as a hack round it.

Anything that you're loading into yourself doesn't get a chance to access any system properties before you've set them. This includes AWT and any third party libraries.

For instance, I set the Java 2D performance properties quite happily as the first thing I do in main(). Since I haven't done anything to cause Java2D/AWT to be loaded by this point they work quite happily. There are obviously a few properties that are truly "system", i.e. they're access instantly as the VM comes up but by the far the majority should be fine to set at the start of main().

Kev

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #6 - Posted 2004-08-15 11:46:07 »

Quote
There are obviously a few properties that are truly "system", i.e. they're access instantly as the VM comes up but by the far the majority should be fine to set at the start of main().

Kev


We don't have control over the main method; that gets written by the developer/licensee. None of the system setup is performed directly in the main method (this is a complex distributed system, after all - it has a reasonably complex and powerful modular "boot" system to handle all that).

The annoying thing is that logging is so fundamental, and is practically the first thing you want to get going. It would be a lot easier if we could just delay referencing logging until we were sure that we'd set the system properties etc.

The other problem is that I don't know why/how j.u.l screws up its own configuration when you try to config it at runtime. Perhaps there's some really simple subtlety - like one line of code we should or should NOT have which once corrected will just make it work, but if so then no-one here has spotted it yet. I wish Sun would document their new API's Angry - 1.4 has been out for *years* now, and still only two tiny mentions in the java trails. Sob.

malloc will be first against the wall when the revolution comes...
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #7 - Posted 2004-08-16 04:21:22 »

Quote
Equally, you can tell every user that they MUST start java from a command line (Mac OS X users: ?)

If you are Mac friendly you will distribute your Java app as a Mac Application Bundle.  Inside the bundle there is an XML file that allows you to specify property values.

Of course simple batch files or shell scripts can do the trick too.  Even a java app that just execs another java command to launch the main app can do the trick.  With clever hacks you could probably do this with a signed webstart app.. by finding at runtime the JAR file and then running a command line that will start the JAR file.  No need for an inner JAR.. It could be the same JAR.

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #8 - Posted 2004-08-16 04:22:49 »

Quote
I wish Sun would document their new API's Angry - 1.4 has been out for *years* now, and still only two tiny mentions in the java trails. Sob.


They should change the Java Trail pages to a Wiki.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #9 - Posted 2004-08-16 11:19:50 »

Quote


They should change the Java Trail pages to a Wiki.


Well, personally I'd prefer a Zope Talkback (it's a bit more specialized with the specific aim of letting users comment on a web page in such a way that the comments are embedded but can be opened/closed by viewers), but yes I agree that it would be an excellent idea to have something in that genre of app instead of a static always-out-of-date-because-Sun-doesn't-allocate-time-and-manpower-to-fix-it page.

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #10 - Posted 2004-08-16 11:22:31 »

Quote

If you are Mac friendly you will distribute ...

With clever hacks you could probably do this with a signed webstart app.. by finding at runtime the JAR file and then running a command line that will start the JAR file.  No need for an inner JAR.. It could be the same JAR.


It's the game server for a game, not the client, so OS-specific bundling is out of the question, as is webstart (most servers are headless these days).

The idea of finding the JAR file name from within webstart sounds interesting...but is it possible to work out the hashing algo it uses for naming directories? (from casual glances it looked non-deterministic). If 1.5 adds anything to let you read the CWD (long suggested / requested, but I can't remember if it's being included), then it would be easy Grin.

malloc will be first against the wall when the revolution comes...
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #11 - Posted 2004-08-16 12:24:51 »

Quote
It's the game server for a game, not the client, so OS-specific bundling is out of the question, as is webstart (most servers are headless these days).


I don't get it.  How is being the server side component at all relevant to the packaging??  (Though currently not practical for Web Start perhaps.)

Quote
The idea of finding the JAR file name from within webstart sounds interesting...but is it possible to work out the hashing algo it uses for naming directories?

I'm guessing you won't need to if you use something like
1  
URL url = MyClass.class.getClassLoader().gerResource("something in the jar");
and parse the URL which should be of the form "jar:..."

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #12 - Posted 2004-08-16 12:42:51 »

Quote


I don't get it.  How is being the server side component at all relevant to the packaging??  (Though currently not practical for Web Start perhaps.)


Apart from being headless, server admins seem to want java code to be identical from OS to OS. Since there's no fancy GUI to worry about, and no idiot user, and the admins/users are advanced java devs, many of the nice crutches you put in for clients delivered to a mass market are unnecessary - and in the case where you have multiple servers running different OS's, they can be a distraction.

What we have at the moment is:
- no-one using OS X as a server (I know it's *possible* but at the moment it's a tiny niche  in the world of co-lo and dedicate servers), so possibly some aspects of the packaging would break on OS X (I don't know!)
- a product for which licensees can create a single install procedure that is OS independent, because it is all delivered using only x-platform java features. Essentially, you just fire up a single JAR to test the system works. As a developer, you then build a custom JAR to launch your server (or you can use the pre-built ones supplied that setup generic gameservers) that does the same thing. Nice and simple (NB: all config is handled by a dedicated sub-system, since there's a LOT of config to do, and a lot of it is predicated / dynamic; so long as you can start up the base javaserver, it will automatically "boot" itself from the relevant config subsystems [there's more than one, for different kinds of config])

Quote

I'm guessing you won't need to if you use something like


Ah, you are far too cunning for me Cheesy. I've never debugged a webstarted-app-generated URL to check, but I take it they can't be purely relative (i.e. your technique should work) because they need to reference multiple JAR's and extensions all of which will potentially be in different hashed directories?

malloc will be first against the wall when the revolution comes...
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #13 - Posted 2004-08-16 21:57:34 »

Quote
Ah, you are far too cunning for me Cheesy. I've never debugged a webstarted-app-generated URL to check, but I take it they can't be purely relative (i.e. your technique should work) because they need to reference multiple JAR's and extensions all of which will potentially be in different hashed directories?


Yes, resources will be in different folders of the Web Start cache. It's up to the implementation of course, but the Web Start launcher must manage the classpath so that all the needed resources are accessible via the classpath.   I'm not sure what to expect from that hack in terms of a URL... but I suspect that it will be okay.  For a moment I thought there might be a security implication if  you could get path information from the machine without being signed.  I doubt it, but even so you would need to have the app signed to exec the "real code" with the standard java launcher.  In fact it is much more likely that you won't be able to reliably find the launcher, since the 'java' command doesn't have to be in the path.  That would lead to trying to guess the location of the 'java' executable based on examining the bootclasspath or other properties...  it is sure to become loads of fun Wink.  Let me know when you have it all figured out Tongue

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #14 - Posted 2004-08-27 03:39:54 »

I know that this is not a real solution, but the vm picks up the  properties set in env. variable _JAVA_PROPERTIES.

So if somehow the installer for your app would set that global env. variable (or, alternatively, you set it manually on all target systems =)..
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #15 - Posted 2004-08-27 12:18:59 »

Quote
I know that this is not a real solution, but the vm picks up the  properties set in env. variable _JAVA_PROPERTIES.


That would certainly be a slight improvement, in that we could write it in to the installation instructions as a single step that - once done - can be forgotten about. Unfortunately, we don't have an installer per se.

At the moment we're still pounding on log4j trying to assess the performance, but we'll be moving on to j.u.l and having another go at all this soon. Thanks.

malloc will be first against the wall when the revolution comes...
Offline Malohkan

Senior Member




while (true) System.out.println("WOO!!!!");


« Reply #16 - Posted 2004-08-27 12:59:18 »

I've read some blabber about starting more than one jvm and that gives me an idea.  Could you load up an initial Class with Webstart that sets those properties, then kills itself (hehe) and calls for a new JVM to be started with your main Class?

Admin and Game Developer at
GameLizard.com
Play Rimscape!    |    Play Conquer!
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (81 views)
2014-04-15 18:08:23

BurntPizza (73 views)
2014-04-15 03:46:01

UprightPath (84 views)
2014-04-14 17:39:50

UprightPath (67 views)
2014-04-14 17:35:47

Porlus (83 views)
2014-04-14 15:48:38

tom_mai78101 (107 views)
2014-04-10 04:04:31

BurntPizza (167 views)
2014-04-08 23:06:04

tom_mai78101 (263 views)
2014-04-05 13:34:39

trollwarrior1 (213 views)
2014-04-04 12:06:45

CJLetsGame (223 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!