L
Lindsay Pallickal
I came here last week looking for help with a 906 error code I got while
trying to load a midlet on a Sanyo SCP-5500, through SprintPCS. I got some
useful information from Darryl, but after hacking through a couple of other 90x
error codes, as well as another, 406, I found that the situation was more
complicated and not well documented. So I decided to document how to fix these
errors as I resolved them. All of these error codes frustrated because each
turned out to have multiple causes, which made them seem random. Hopefully this
will save someone else at least some of the headache involved in figuring out
how to create and serve midlets over the air.
For starters, there is some confusion about which attributes/keys are needed in
the descriptor - I found that my SprintPCS phone requires only the default
attributes/keys that KToolbar defines. Below I've listed the attributes found in
a .jad file made with the defaults, I think most phones should work with this
basic set.
MIDlet-1:
MIDlet-Jar-Size:
MIDlet-Jar-URL:
MIDlet-Name:
MIDlet-Vendor:
MIDlet-Version:
MicroEdition-Configuration:
MicroEdition-Profile:
For maximum compatibility add the attributes below as well. I have read that a
some phones need them, though I have not seen reference to a specific model that
needs "MIDlet-Data-Size:", and only the Samsung VI660 needs "Content-Folder:" to
my knowledge.
Content-Folder:
MIDlet-Data-Size:
Below are common errors loading midlets, their causes, and solutions.
-Data Error 905 - Attribute Mismatched
-Occurs when attributes in the .jar manifest and the .jad don't agree.
Potential Cause
-KToolbar adds carriage returns to attributes in the .jar manifest when
they run over 70 characters, and not to the supposedly identical
attributes in the .jad file. This leads to a mismatch between some
attributes in the .jar and the .jad. This is seen more often with the
longer "MIDlet-1:" attribute.
Solution
-Remove extra carriage returns from manifest.mf after opening the .jar
in a program like Powerarchiver. Once the .jar is modified update its
size in the .jad attribute "MIDlet-Jar-Size:" to prevent a different
sort of mismatch. Alternatively use shorter names in the attribute
where the problem arises.
Potential Cause
-MIDP 2.0 Profile has been selected in KToolbar for a MIDP 1.0 device.
Solution
-Check the "MicroEdition-Profile:" attribute in the .jad to verify the
application is MIDP 2.0 and also check that the device is MIDP 1.0 - If
so select a MIDP 1.0 Profile in KToolbar.
Potential Cause
-Bad mime type for .jar files on server.
Solution
-Set the mime type for .jar files to "application/java-archive". Apache
has a default of "application/x-java-archive", which didn't work for
me.
Potential Cause
-Sprint's server is sending older, cached versions of files because the
web server has not been configured to eliminate or minimize caching.
Solution
-Configure the server to instruct caching system's to cache .jar and
.jad files for only a minimal amount of time, or to not cache them at
all. The mod_expires module for Apache will do this.
Potential Cause
-Sprint is sending a cached version of your latest .jar file with the
application/x-java-archive mime type, even though your server's mime
types have been updated and caching is disabled or minimized.
Solution
-Rebuild the project so that the modification dates and times for the
.jad and the .jar are updated. Only then re-upload them to the server.
Failure to rebuild may result in the server figuring the .jar file has
not changed, causing it to send a "304 - Not Modified" code to Sprint's
caching server. The file would not have changed, so Sprint's caching
server wouldn't re-download it, along with the updated mime type in the
header.
-Data Error 906 - Invalid Descriptor
-Occurs when there is invalid content in a .jad file
Potential cause
-There is only a filename for the "MIDlet-Jar-URL:" attribute in the
.jad.
Solution
-Use an absolute URL to specify the location of your .jar.
i.e. - MIDlet-Jar-URL: http://myserver.com/midlets/foo.jar
Potential Cause
-Sprint's server is sending an older, cached .jad file without a
propererly formed "MIDlet-Jar-URL:" because the web server has not been
configured to eliminate or minimize caching.
Solution
-Configure the server to instruct caching system's to cache .jad files
for only a minimal amount of time, or to not cache them at all. The
mod_expires module for Apache will do this.
Potential Cause
-Some phones need the "Content-Folder:" attribute in the .jad file.
Solution
-Add this attribute for the Samsung VI660, this is the only model I've
heard has this problem.
-Data Error 907 - Server Error
-The jar file has a valid URL but can't be located, or it is bad
Potential Cause
-There is a bad "MIDlet-Jar-URL:" attribute in the .jad - the device
can't find the .jar file on the server hosting it, or the server is
down.
Solution
-Check that the server is not down, and that the correct address was
specified.
-Check that the file and pathname are specified correctly for the .jar,
remembering that they are case-sensitive.
-HTTP Error 406 - Content not acceptable
Potential Cause
-Bad mime type for .jad files.
Solution
-Set the mime type for .jad files to "text/vnd.sun.j2me.app-descriptor".
Apache's default of "text/plain" doesn't work.
Potential Cause
-Sprint is sending a cached version of your latest .jad file with the
text/plain mime type, even though your server's mime types
have been updated and caching is disabled or minimized.
Solution
-Rebuild the project so that the modification dates and times for the
.jad and the .jar are updated. Only then re-upload them to the server.
Failure to rebuild may result in the server figuring the .jad file has
not changed, causing it to send a "304 - Not Modified" code to Sprint's
caching server. The file would not have changed, so Sprint's caching
server wouldn't re-download it, along with the updated mime type in the
header.
Well, there you have it. The crux of the problem is that the same error
can be caused by a number of very different missteps. Even with perfect jar/jad
files and a properly configured server it is possible to continue getting an
error that could mean any number of things! All the error codes and causes
above, except the one related to the VI660, are from the SCP-5500. I can only
hope other devices are somewhat consistent in their implementation. If anyone
notices an inconsistency with the above or something missing, please post data
for your device.
----
Lindsay Pallickal
Resourceful progammer with a wide skill set looking for challenging work at a
friendly place. Remove NO POTTED MEAT from my email address to contact me.
----
trying to load a midlet on a Sanyo SCP-5500, through SprintPCS. I got some
useful information from Darryl, but after hacking through a couple of other 90x
error codes, as well as another, 406, I found that the situation was more
complicated and not well documented. So I decided to document how to fix these
errors as I resolved them. All of these error codes frustrated because each
turned out to have multiple causes, which made them seem random. Hopefully this
will save someone else at least some of the headache involved in figuring out
how to create and serve midlets over the air.
For starters, there is some confusion about which attributes/keys are needed in
the descriptor - I found that my SprintPCS phone requires only the default
attributes/keys that KToolbar defines. Below I've listed the attributes found in
a .jad file made with the defaults, I think most phones should work with this
basic set.
MIDlet-1:
MIDlet-Jar-Size:
MIDlet-Jar-URL:
MIDlet-Name:
MIDlet-Vendor:
MIDlet-Version:
MicroEdition-Configuration:
MicroEdition-Profile:
For maximum compatibility add the attributes below as well. I have read that a
some phones need them, though I have not seen reference to a specific model that
needs "MIDlet-Data-Size:", and only the Samsung VI660 needs "Content-Folder:" to
my knowledge.
Content-Folder:
MIDlet-Data-Size:
Below are common errors loading midlets, their causes, and solutions.
-Data Error 905 - Attribute Mismatched
-Occurs when attributes in the .jar manifest and the .jad don't agree.
Potential Cause
-KToolbar adds carriage returns to attributes in the .jar manifest when
they run over 70 characters, and not to the supposedly identical
attributes in the .jad file. This leads to a mismatch between some
attributes in the .jar and the .jad. This is seen more often with the
longer "MIDlet-1:" attribute.
Solution
-Remove extra carriage returns from manifest.mf after opening the .jar
in a program like Powerarchiver. Once the .jar is modified update its
size in the .jad attribute "MIDlet-Jar-Size:" to prevent a different
sort of mismatch. Alternatively use shorter names in the attribute
where the problem arises.
Potential Cause
-MIDP 2.0 Profile has been selected in KToolbar for a MIDP 1.0 device.
Solution
-Check the "MicroEdition-Profile:" attribute in the .jad to verify the
application is MIDP 2.0 and also check that the device is MIDP 1.0 - If
so select a MIDP 1.0 Profile in KToolbar.
Potential Cause
-Bad mime type for .jar files on server.
Solution
-Set the mime type for .jar files to "application/java-archive". Apache
has a default of "application/x-java-archive", which didn't work for
me.
Potential Cause
-Sprint's server is sending older, cached versions of files because the
web server has not been configured to eliminate or minimize caching.
Solution
-Configure the server to instruct caching system's to cache .jar and
.jad files for only a minimal amount of time, or to not cache them at
all. The mod_expires module for Apache will do this.
Potential Cause
-Sprint is sending a cached version of your latest .jar file with the
application/x-java-archive mime type, even though your server's mime
types have been updated and caching is disabled or minimized.
Solution
-Rebuild the project so that the modification dates and times for the
.jad and the .jar are updated. Only then re-upload them to the server.
Failure to rebuild may result in the server figuring the .jar file has
not changed, causing it to send a "304 - Not Modified" code to Sprint's
caching server. The file would not have changed, so Sprint's caching
server wouldn't re-download it, along with the updated mime type in the
header.
-Data Error 906 - Invalid Descriptor
-Occurs when there is invalid content in a .jad file
Potential cause
-There is only a filename for the "MIDlet-Jar-URL:" attribute in the
.jad.
Solution
-Use an absolute URL to specify the location of your .jar.
i.e. - MIDlet-Jar-URL: http://myserver.com/midlets/foo.jar
Potential Cause
-Sprint's server is sending an older, cached .jad file without a
propererly formed "MIDlet-Jar-URL:" because the web server has not been
configured to eliminate or minimize caching.
Solution
-Configure the server to instruct caching system's to cache .jad files
for only a minimal amount of time, or to not cache them at all. The
mod_expires module for Apache will do this.
Potential Cause
-Some phones need the "Content-Folder:" attribute in the .jad file.
Solution
-Add this attribute for the Samsung VI660, this is the only model I've
heard has this problem.
-Data Error 907 - Server Error
-The jar file has a valid URL but can't be located, or it is bad
Potential Cause
-There is a bad "MIDlet-Jar-URL:" attribute in the .jad - the device
can't find the .jar file on the server hosting it, or the server is
down.
Solution
-Check that the server is not down, and that the correct address was
specified.
-Check that the file and pathname are specified correctly for the .jar,
remembering that they are case-sensitive.
-HTTP Error 406 - Content not acceptable
Potential Cause
-Bad mime type for .jad files.
Solution
-Set the mime type for .jad files to "text/vnd.sun.j2me.app-descriptor".
Apache's default of "text/plain" doesn't work.
Potential Cause
-Sprint is sending a cached version of your latest .jad file with the
text/plain mime type, even though your server's mime types
have been updated and caching is disabled or minimized.
Solution
-Rebuild the project so that the modification dates and times for the
.jad and the .jar are updated. Only then re-upload them to the server.
Failure to rebuild may result in the server figuring the .jad file has
not changed, causing it to send a "304 - Not Modified" code to Sprint's
caching server. The file would not have changed, so Sprint's caching
server wouldn't re-download it, along with the updated mime type in the
header.
Well, there you have it. The crux of the problem is that the same error
can be caused by a number of very different missteps. Even with perfect jar/jad
files and a properly configured server it is possible to continue getting an
error that could mean any number of things! All the error codes and causes
above, except the one related to the VI660, are from the SCP-5500. I can only
hope other devices are somewhat consistent in their implementation. If anyone
notices an inconsistency with the above or something missing, please post data
for your device.
----
Lindsay Pallickal
Resourceful progammer with a wide skill set looking for challenging work at a
friendly place. Remove NO POTTED MEAT from my email address to contact me.
----