When ever i try uploading my game logic JAR it always gets knocked off the top posistion in the list of jars for that version. I.e. if i upload it first then upload another jar it gets moved down. I then delete the jar that caused the shunting so that the correct jar is at the top. I then re-upload the deleted jar but it still causes the shunting.
This means that the automatic JNLP file creator lists the incorrect JAR as the first JAR causing it to fail finding the main class and thus the game cannot load.
Feature requests
add a radio check box for each JAR to nominate the Jar that should be first in the list when generating the JNLP file
or allow game owners to edit the generated JNLP file
Each time a version is created, users have to re-download every JAR, even if those JARs are unmodified… so can you store the JARs on the sever in such a way as to not change the url for the jars each time a version is created, rather only change it when it is updated?
Specifying the main-class using the form field belwo the jar list is supposed to make this unnecessary (according to the webstart docs). That was the way Sun chose to implement it - are you saying the main-class field/tag isn’t working?
EDIT: if you’re merely saying you don’t want the hassle of doing this then I’m right with you…
That’s not a trivial change (basic SQL is poor at supporting easy custom sorts), so it’s not especially likely to happen unless there’s something wrong with the main-class system, or I find myself messing with that page (SQL filter + back-end processing code) for some other reason.
Personally, I consider it a bug (a shortsighted, foolish “feature”) that the first jar has this special effect but no others do, but there’s nothing we can do about that.
Yes, this is a nasty bug that was introduced a while back - and is one I’ve been wanting to get rid of personally for some time. It’s a side-effect of two things:
when an author changes the version, we have to keep the files independent of old copies, in case of new inadvertent bugs; versioning by directory was a very simple way of achieving this that needed no code changes at the time (and see below for why this was done, even knowing it screws up the timestamp / basic webstart protocol)
Sun’s basic download protocol sucks in many ways, and this is one of them: it has no way for you to tell it that its copy of file X is actually now named file Y (IIRC redirects cause it to break - but don’t take my word for it, and I ought to double-check); IIRC (off the top of my head) you can’t even change the codebase to have this effect, and/or changing the codebase doesn’t work because you aren’t allowed to use “…” syntax - one or the other, which is intensely annoying (and pretty stupid / shortsighted).
The intended solution was to switch to using the “other” protocol that is built-in to webstart: the “version protocol”. Rather than encode the version in the filename, this protocol has an extra attribute in the JNLP file (version="", unsuprisingly ;)) and allows the server to return whatever file it wants, including jardiffs and other exciting stuff.
However, I just heard from Mark Thornton that java 1.5 breaks the version protocol - things like webstart CD installs won’t work with the version protocol.
So … this needs more thought :(. Rest assured, I’m working on it, but with webstart on the server you often find that every avenue you try doesn’t work because of different bugs or stupidities in Sun’s webstart spec or client implementaiton. So, you have to keep on thinking up new workarounds, and testing them, in the desperate hope of finding the one that works :(.
Thanks for the comments; if nothing else, they help with deciding what to prioritise next
Unfortunetly no… it does look for the main class in my background JAR which only contains background images when i am using a full qualified main class for a class which is in a totally different JAR. When i download the jnlp and then manually edit the jnlp file so that the jar with the main class is at the top it all works peachy.
sight it is things like this that make little wonder why users perfer native executables…
oh well i guess i will go back to how i was before and combine all the jars into one big uber jar… at least then it is garenteeed to be be first
However, I just heard from Mark Thornton that java 1.5 breaks the version protocol - things like webstart CD installs won’t work with the version protocol.
So … this needs more thought :(. Rest assured, I’m working on it, but with webstart on the server you often find that every avenue you try doesn’t work because of different bugs or stupidities in Sun’s webstart spec or client implementaiton. So, you have to keep on thinking up new workarounds, and testing them, in the desperate hope of finding the one that works :(.
Thanks for the comments; if nothing else, they help with deciding what to prioritise next
sight it is things like this that make little wonder why users perfer native executables…
[/quote]
Developers producing broken code does give Java a bad name… but native executables aren’t the solution. Fix the JNLP file… sure the requirement is stupid, but it is also a trivial requirement to meet. Move on and complain about the important things.
Developers producing broken code does give Java a bad name… but native executables aren’t the solution. Fix the JNLP file… sure the requirement is stupid, but it is also a trivial requirement to meet. Move on and complain about the important things.
[/quote]
LOL!
I would love to but JGF as it is does not let me edit the JNLP file it generates…
wow, you must be using a poor SQL implementation if custom sorting is difficult. In my experience (with MySQL, at least), using the “ORDER BY” keyword sorts pretty nicely.
Lets say you added a field to the jar table called “priority” (unsigned int or whatever). You could have the author set which priorty the JARs have via some kind of list ( should help with this), the lower the priority value, the higher the priority (i.e. 1 would have more priority than 3).
Then you could sort the JARs by priority with a simple SQL statement:
SELECT * FROM `table_of_jars` ORDER BY `priority` ASC
That would return a result set with the highest priority on top
But this is all just a guess because I don’t know your SQL implementation (Postgre, mSQL, etc) and I don’t know how you have your DB set up…
SQL was not designed to do non-relational stuff; this kind of sort “I want one item in one place, and everything else doesn’t matter” is not a relational sort.
Nothing in SQL is particularly hard - even making a hierarchical XML DB only involves time and slow DB performance - but everything is relative.
For instance, editing a template file by hand (takes 3 seconds), or fixing another feature which needs to be fixed anyway (if something wrong with the main-class attribute) takes a lot less time than altering SQL, debugging it, adding unit tests, etc.[quote]
[/quote]
I wasn’t implying that the rest of the JARs don’t matter, that’s why I added the “ASC” keyword to ensure the next highest priority JAR was next in case the user found the first JAR to be corrupted or something. If I was implying “everything else doesn’t matter,” I would’ve used “LIMIT 1” in the query
And since SQL has the lovely “LIMIT” keyword, I don’t see where its not designed to single out one row of data… but thats up to opinion I suppose
Are you sure you’re just not a wee bit on the lazy side A simple SQL query such as that shouldn’t take any debugging and wouldn’t need very many tests at all
But still, I’m not sure how your DB is setup, so I don’t know how complicated it would be for you…
would seem a great idea, but then - [people writing the webstart client] would be writing code that checked each jar in turn, and, um…well, that’s what you’d expect in the first place, as the right way of doing it, and they already chose not to :(.
It doesn’t really matter right now, and this isn’t a reason for not doing it now, but FYI generally I want as few SQL queries as possible in this: the JNLP gets accessed rather a lot of times each time a game is played (4, usually!) and the SQL queries currently make it 4 times slower than it is with just all the logic code.
And bear in mind this is accessed EVERY time a game is started, anywhere, even if there’s no web browsing going on…
Indeed I am sure, because there’s a shed-load of stuff on the todo list, and anything that reduces that workload increases the amount that gets done. This isn’t laziness, it’s pragmatism ;D.
You’re lucky if “a simple SQL query” never takes “any” debugging. Since SQL has no compile-time checking (well, on JGF there’s a little, but still only 50% coverage or so) any typo takes typically a fair number of minutes to discover and fix (compile, upload, restart server, navigate to relevant page, invoke SQL query, check result, find broken query in log file, go back to source, fix, recompile, and check again…).
Shrug. Obviously I’d rather be fixing things than typing this, but haven’t got source access at the mo (still at work).
- are you saying the main-class field/tag isn’t working?
then I’m right with you…
