Skip to main content

howto get verbose output (mr3 on wm6)

10 replies [Last post]
hnipak
Offline
Joined: 2006-02-03

I'm trying to run a midlet in Davy's MR3 rev13050 build on WM6 device, but it seems as if it just does not run (Opera Mini 4.1 runs ok!). In MR2 the midlet was running "fine"...

Is there any way to get some log or messages about what is going on? I tried to run runMidlet from command line but saw nothing...

Thank you.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
davyp
Offline
Joined: 2007-01-03

Hi hnipak,

Regarding the mr2/mr3 numbering: I used the pMEF sources from the subversion tree, which I
assume are just updates to the mr3 release. One of the splash screen images also carries the
mr3 label. That is why I relabeled the packages from mr2 to mr3. If this assumption is wrong, I
will relabel the packages again. The changes between the last mr2 build and the current one
should not be that big. In fact, my patches haven't changed over the last few WinCE builds.

Regarding your midlet problem: without any more information, I cannot tell what your problem
is. pMEF seems to run fine on my device. My test applications just work like they used to and
Opera Mini 4.1 appears to be working for you as well. Have you tried with a clean installation?

Davy

hnipak
Offline
Joined: 2006-02-03

Hello Davy,

I cannot say I understood which pMEF milestone it actually is ;-) ... Did you build it from main trunk so you assume it is MR3 with latest updates?

Your current build - whatever milestone it is - is running fine on my HTC Artemis with WM6, Opera Mini 4.1 runs fine, but my midlet does not. I hoped to hear that there is a logfile or something, because I get no error, just nothing happens. And is is going to be quite time-consuming task findingout what's wrong I'm afraid.

Anyway, what is -debug option good for?

Thank you a lot for your effort of providing pMEF binaries for WM!

-hnipak

davyp
Offline
Joined: 2007-01-03

Hi hnipak

> Hello Davy,
>
> I cannot say I understood which pMEF milestone it
> actually is ;-) ... Did you build it from main trunk
> so you assume it is MR3 with latest updates?

Indeed!

> Your current build - whatever milestone it is - is
> running fine on my HTC Artemis with WM6, Opera Mini
> 4.1 runs fine, but my midlet does not. I hoped to
> hear that there is a logfile or something, because I
> get no error, just nothing happens. And is is going
> to be quite time-consuming task findingout what's
> wrong I'm afraid.

I basically test my own midlet by printing out debug statements. For that,
you need a command prompt environment. The process is quite
cumbersome, but I haven't found a proper way to debug on the device
itself.

The only place where the current build may differ a bit from previous builds,
is in the implementation of some of the JSRs. For some JSRs that are not
available in svn trunk, I migrated from the sources of an old mr2 zip file to
jsr sources of the mr3 zip file. Are you using any particular JSR?

Have you tried if you have the same problem e.g. on a linux build? If you
like you can send me a jar/jad file to locate the problem.

> Anyway, what is -debug option good for?

I guess for debugging purposes :-), but I am not quite sure how to actually
use it to debug on a PDA.

Davy

hnipak
Offline
Joined: 2006-02-03

> Are you using any particular JSR?

Many :-)

Thanks to good old stdout I can tell you now where exactly it crashes:

[i]Connector.open("file:///Storage%20Card/some path that exists/some file that exists");[/i]

Now this did not work in MR2 as we already spoke of it (no access to "real" fs yet on WM), however it did not crash the midlet.

davyp
Offline
Joined: 2007-01-03

Then I might know what the cause of this problem could be. You are using
JSR 75, and as there are no svn sources for this one, I used those from
phoneme_feature-mr2-rel-src-b23-08_may-2007.zip for the older builds.

To get these old sources working again I removed some security
permission checks because this code was completely inconsistent with the
current midp sources. Once mr3 came out, I rebuilt pMEF with the newer
JSR 75 sources from phoneme_feature-mr3-rel-src-b01-17_jul_2008.zip.

Now the question of course is: is it a crash or a security permission
error (i.e. a bug or a feature :-)). I will see if I can reproduce the
problem.

A question to the project leaders: why aren't the jsr sources present in the
above zip file not available in svn?

Best regards,
Davy

Hinkmond Wong

davyp wrote:
> Then I might know what the cause of this problem could be. You are using
> JSR 75, and as there are no svn sources for this one, I used those from
> phoneme_feature-mr2-rel-src-b23-08_may-2007.zip for the older builds.
>
> To get these old sources working again I removed some security
> permission checks because this code was completely inconsistent with the
> current midp sources. Once mr3 came out, I rebuilt pMEF with the newer
> JSR 75 sources from phoneme_feature-mr3-rel-src-b01-17_jul_2008.zip.
>
> Now the question of course is: is it a crash or a security permission
> error (i.e. a bug or a feature :-)). I will see if I can reproduce the
> problem.
>
> A question to the project leaders: why aren't the jsr sources present in the
> above zip file not available in svn?
>

Hi Davy,

We don't own JSR 75 (we at Sun are not the spec. leads of that specific
JSR). So, while we at Sun Microsystems, Inc. make it a rule for
ourselves to open source all of the source code we own, Palm and IBM own
the source code for JSR 75:

See:
http://jcp.org/en/jsr/detail?id=75
...
Specification Lead
Tom Chavez PalmSource, Inc.
Ken Walker IBM

So, you would have to question those 2 companies why they have not open
sourced their source code for JSR 75.

Thanks,
Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: feature-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: feature-help@phoneme.dev.java.net

davyp
Offline
Joined: 2007-01-03

Hi Hinkmond,

I guess "owning" a jsr means being the spec lead. I just had a look at all the
source and configuration files for the jsr 75 implementation in the mr3 zip
file, and all the files carry the GPLv2 license declaration at the top with a
copyright by Sun Microsystems. This pretty much to me means an
open source implementation of the jsr.

So it is Sun Microsystems' policy to make these GPLv2 sources only
available in the publicly available mr3 zip file but not in svn? If these
sources are truly GPLv2, then I don't really get the reasons behind this
policy, not from a technical or legal point of view. Or what do you mean
with "open sourcing their source code"? Is there something I should be
aware of if I make binary builds with these source codes?

Davy

Hinkmond Wong

davyp wrote:
> Hi Hinkmond,
>
> I guess "owning" a jsr means being the spec lead. I just had a look at
> all the
> source and configuration files for the jsr 75 implementation in the
> mr3 zip
> file, and all the files carry the GPLv2 license declaration at the top
> with a
> copyright by Sun Microsystems. This pretty much to me means an
> open source implementation of the jsr.
>
> So it is Sun Microsystems' policy to make these GPLv2 sources only
> available in the publicly available mr3 zip file but not in svn? If these
> sources are truly GPLv2, then I don't really get the reasons behind this
> policy, not from a technical or legal point of view. Or what do you mean
> with "open sourcing their source code"? Is there something I should be
> aware of if I make binary builds with these source codes?
>

Hi Davy,

Yes (this is tricky to explain). The JSR 75 implementation files that
you find in all the pMEF MR1, MR2, and now MR3 source bundles are Sun's
implementation of Palm's/IBM's JSR 75 spec. and correctly have the GPLv2
license on them (since they are Sun's implementation source files and we
chose to open source that specific instance of our JSR 75 compliant
source files). They are true open source source files freely available
to use and develop under the GPLv2 license.

It is Sun's policy to make these (and other non-Sun-owned JSRs) source
files available publicly _only_ in the MR# zip bundles but not in the
SVN repo because of legal issues with the Java Community Process.

From Sun's legal guidance on the JCP rules, we can only open source
implementations of JSR 75 (and other non-Sun-owned JSRs) with 2
restrictions: we get the permission of the spec. lead(s), and we are
always in TCK compliance with their JSR specific TCK tests. (The rules
are different for Sun-owned JSRs, since we can chose what to do to
ourselves in case of non-conformance to our own JSR TCK tests :-) )

We can only ensure the 2nd rule (TCK conformance) when all our
Sun-modified source files for that particular JSR are "frozen" and do
not change (such as inside a zip bundle, but not in a source repository).

So, that is why you see JSR 75 Sun-modified source files in the pMEF MR*
zip bundles and why they have GPLv2 headers.

So, technically, you could use those source files extracted from the
pMEF MR* zip bundles any way you wish as long as you follow the GPLv2
license they are under and if you modify those files you would be
responsible for being in TCK compliance. You can change them and port
them to new platforms as long as you make your changes freely available
under GPLv2. If you make changes to them and do not pass the JSR 75 TCK
conformance tests, under the JCP rules, Palm and IBM can take recourse
against you.

Following that rule, we at Sun chose not to provide Sun constantly
mutable source files to the public (like in our phoneME SVN repo), since
we would have to guarantee to run _and_ _pass_ the JSR 75 TCK testsuite
for each and every commit revision that happens to any of those files in
that component. Since that is not reasonable to do given the
constraints we have on all our non-Sun-owned JSRs, we chose to include
the non-Sun-owned JSRs we have permission to open source only in zip
bundles.

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: feature-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: feature-help@phoneme.dev.java.net

davyp
Offline
Joined: 2007-01-03

I have removed support for JSR 75, 179 and 180 from the builds I have put on my website,
as it is clear that I cannot comply with these restrictions either.

The Location API (JSR 179) was not fully functional as it only supported a replay of an NMEA
log, and I don't think that many people need SIP support (JSR 180). For JSR 75, I have sent
an email to Tom Chavez (the JSR 75 spec lead from Palm) explaining the situation, and I am
waiting for feedback.

I left in support for JSR 172 (a Sun-owned JSR for Web Services). As Hinkmond stated: "we
can chose what to do to ourselves in case of non-conformance to our own JSR TCK tests",
I can only hope that Sun Microsystems will play nice with their community contributors.

Davy

Hinkmond Wong

davyp wrote:
> ...
>
> I left in support for JSR 172 (a Sun-owned JSR for Web Services). As Hinkmond stated: "we
> can chose what to do to ourselves in case of non-conformance to our own JSR TCK tests",
> I can only hope that Sun Microsystems will play nice with their community contributors.

Sounds good, Davy. (I can't see any reason why Sun would give you any
hassles about JSR 172, unless there was a blatant non-conformance
action, like trying to usurp the JSR. Having open source community
developers work with our JSR implementations would be more helpful than
harmful for the Mobile & Embedded community overall, as you'd guess) :-)

Hinkmond

---------------------------------------------------------------------
To unsubscribe, e-mail: feature-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: feature-help@phoneme.dev.java.net