Skip to main content

A weird problem with bundles...

10 replies [Last post]
palineo
Offline
Joined: 2009-02-26
Points: 0

Hi everyone,

I have a very special problem with bundles.

When I fill the interview (J2meBaseTestSuite), I parameter it in order to have a bundle of 50 tests (max) and 1.000.000 bytes (max).

After this, I launch the server and it distributes about 10 bundles of 100k...whereas I was waiting for 1 bundle (or 2).

I am perplex. Have you ever had a similar problem ?

I continue investigation.
Thanks by advance if you have any idea :-)

Message was edited by: palineo

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
palineo
Offline
Joined: 2009-02-26
Points: 0

Well,

It appears that it is a solution (and a great tips) !

Thanks for your help!

Message was edited by: palineo

Message was edited by: palineo

vsizikov
Offline
Joined: 2004-11-16
Points: 0

> It appears that it is a solution (and a great tips)!
> Thanks for your help!

You're welcome! :)

And don't hesitate to contact us and ask questions in case when something is unclear or strange.

We've been doing the test suite development for JavaME for more than a decade already (time flies fast!), and there was plenty of experience collected over all these years. Sometimes, we do things one way and it never occurs to us that other users might want to do differently or might be confused by something that we consider the standard way of doing things.

So, your questions and bug reports are always welcome!

Thanks,
--Vladimir

palineo
Offline
Joined: 2009-02-26
Points: 0

Well,

I found a part of the problem...but I search how to solve it!

When I fill the interview, if I indicate that the device supports trusted MIDlet suite, it generates only one bundle otherwise it generates plenty bundles...

Vladimir Sizikov

Hi,

On 8/14/2009 9:07 AM, meframework@mobileandembedded.org wrote:
> I found a part of the problem...but I search how to solve it!
>
> When I fill the interview, if I indicate that the device supports trusted MIDlet suite, it generates only one bundle otherwise it generates plenty bundles...

Still a bit strange and unexpected. Is this the same behavior on both
OSes, Linux and Windows? Or do you still see two different behaviors
under different OSes?

Also, this difference between trusted and untrusted mode is typically
not expected.

In your test descriptions, do you have anything related to the security?
I mean: grant/deny keys, trusted/untrusted keywords, maybe jad-addons?

In case if you have jad-addon entries in the test descriptions, this
might explain why multiple bundles are created, we have some logic to
determine whether we should have one bundle or multiple bundles,
depending on the jad-addon content (sometimes the contents might be in
contradiction with each other, and in such cases we use different
bundles for tests with contradicting jad addons).

At least, the behavior must be identical on both OSes, if not -
something is wrong for sure.

Thanks,
--Vladimir
[vladimir_sizikov.vcf]
---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

palineo
Offline
Joined: 2009-02-26
Points: 0

Hi Vladimir

> Still a bit strange and unexpected. Is this the same behavior on both
> OSes, Linux and Windows? Or do you still see two different behaviors
> under different OSes?

After tests, the behavior is exactly the same under differents Oses.

> In your test descriptions, do you have anything related to the security?
> I mean: grant/deny keys, trusted/untrusted keywords, maybe jad-addons?

Yes I do, I use grants and jad-addons. I think it's could be a "grant" effects as you can see in the bundler work log, we toggle between #UNTRUSTED and not #UNTRUSTED :

TEST PROVIDER: dispatchTestBundle test1.jar
TEST PROVIDER: com/xxx/JSR118/Interactive/MIDP20_IMG_SUPPORT_HTTP_BMP_FORMAT_FORM.html#UNTRUSTED
TEST PROVIDER: dispatchTestBundle test2.jar
TEST PROVIDER: com/xxx/JSR118/Interactive/MIDP20_IMG_SUPPORT_PNG_FORMAT_FORM.html
TEST PROVIDER: com/xxx/JSR118/Interactive/MIDP20_GAMEAPI_SUPPORT_GAMECANVAS.html
TEST PROVIDER: com/xxx/JSR118/Interactive/MIDP20_GAMEAPI_SUPPORT_SPRITETRANSFORMATION.html
TEST PROVIDER: com/orangelabs/JSR118/Interactive/MIDP20_GAMEAPI_SUPPORT_TILEDLAYERCLASS.html
TEST PROVIDER: com/xxx/JSR118/Interactive/MIDP20_SCREEN_SIZE.html
TEST PROVIDER: dispatchTestBundle test3.jar
TEST PROVIDER: com/xxx/JSR118/Interactive/MIDP20_TCP_SOCKET.html#UNTRUSTED
TEST PROVIDER: dispatchTestBundle test4.jar
TEST PROVIDER: com/xxx/JSR118/Interactive/MIDP20_IMG_SUPPORT_BMP_FORMAT_FORM.html
TEST PROVIDER: com/xxx/JSR118/Interactive/MIDP20_IMG_SUPPORT_TIFF_FORMAT_FORM.html
TEST PROVIDER: com/orangelabs/JSR118/Interactive/MIDP20_GAMEAPI_SUPPORT_SPRITECOLLISION.html
TEST PROVIDER: com/xxx/JSR118/Interactive/MIDP20_UI_SUPPORT_CHOICEGROUP.html
TEST PROVIDER: com/orangelabs/JSR118/Interactive/MIDP20_UI_SUPPORT_STRINGITEM.html
TEST PROVIDER: com/orangelabs/JSR118/Interactive/MIDP20_UI_SUPPORT_TEXTBOX.html
TEST PROVIDER: com/xxx/JSR118/Interactive/MIDP20_TWO_KEY_PRESS.html
TEST PROVIDER: com/xxx/JSR118/Interactive/MIDP20_GAMEAPI_SUPPORT_SPRITEANIMATION.html
TEST PROVIDER: com/xxx/JSR118/Interactive/MIDP20_UI_SUPPORT_WMA.html

Do you know if I can avoid this ?
I am going to put the following grants in each file in order to have a #UNTRUSTED file for each test :
(TR>
(TD SCOPE="row") (B)grant(/B) (/TD)
(TD)
javax.microedition.io.Connector.http
(/TD)
(/TR)

Thanks,
Brice.
Message was edited by: palineo

Message was edited by: palineo

Vladimir Sizikov

Hi Brice,

> After tests, the behavior is exactly the same under differents Oses.

Excellent! So there is no OS-specific behavior (which would have been a
bug).

>> In your test descriptions, do you have anything related to the security?
>> I mean: grant/deny keys, trusted/untrusted keywords, maybe jad-addons?
>
> Yes I do, I use grants and jad-addons. I think it's could be a "grant" effects

Indeed. This explains the situation. That's how it should work. The
tests that should run in trusted mode can't be bundled with the tests
that should run in untrusted mode, so we have no other choice but bundle
the tests in the different bundles.

> as you can see in the bundler work log, we toggle between #UNTRUSTED and not #UNTRUSTED :
>
> TEST PROVIDER: dispatchTestBundle test1.jar
> TEST PROVIDER: com/xxx/JSR118/Interactive/MIDP20_IMG_SUPPORT_HTTP_BMP_FORMAT_FORM.html#UNTRUSTED
> TEST PROVIDER: dispatchTestBundle test2.jar
> TEST PROVIDER: com/xxx/JSR118/Interactive/MIDP20_IMG_SUPPORT_PNG_FORMAT_FORM.html
>
> Do you know if I can avoid this ?

It can't be fully avoided, since there is way to insert tests that
require different security environments in the same bundle.

But, there is a quick workaround that helps out in some cases. For
example, instead of running ALL tests at once, you could configure
JTHarness to exectue only tests with particular keywords. This is
configured via JTHarness interview (or by simply clicking on the second
button on the toolbar, the one with two lines), and then going to
'Keywords' tab.

For example, you could specify in the keywords filter the following:
!untrusted

That way, all tests with untrusted keyword will be grayed out, and
you'll be able to execute all other tests, which should be bundled into
one bundle, without interruptions caused by untrusted tests.

Thanks,
--Vladimir
[vladimir_sizikov.vcf]
---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Vladimir Sizikov

Hi,

> I am perplex. Have you ever had a similar problem ?

Whoa! Working with JTHarness and ME Framework for the last 9 years, I
have never seen or heard anything like that. Something is very, very
weird here. Especially the difference between bundling under different OSes.

> I continue investigation.
> Thanks by advance if you have any idea :-)

Could you please double-check the following values (by opening up "Show
Test Environment" menu from the JTHarness GUI):

concurrency: it should be 50
jarFileSizeLimit: it should be 1000000 (no spaces, no commas)

If you start up the JTHarness part via some kind of script, could you
please try to start it manually, just java -jar javatest.jar and then
opening the test suite, creating the workdir and answering the interview
manually, under both OSes and compare the behavior?

Thanks,
--Vladimir
[vladimir_sizikov.vcf]
---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

palineo
Offline
Joined: 2009-02-26
Points: 0

Hi Vladimir,

Well, I didn't see your post, we cross !

> Especially the difference between bundling under different OSes.
After investigation the difference was on the "trusted Midlet" field and not the OS (oufff...)

> concurrency: it should be 50
That's Ok
> jarFileSizeLimit: it should be 1000000 (no spaces, no commas)
That's Ok, I tryed with 0 (I saw in a previous post that it corresponds to an infinite size of bundle! I like this one) same result.

> Could you please try to start it manually, just java -jar javatest.jar
I do this yesterday...I had the same result. But for information, I use two kind of scripts usually to launch harness :

- from a shell :
java -cp "./lib/*" com.sun.javatest.tool.Main -testsuite ./ -workDirectory -create -overwrite ./WorkDirectory

- Ant task from Netbeans :

(java classname="com.sun.javatest.tool.Main" fork="true")
(classpath)
(pathelement location="${javatest.jar}"/)
(pathelement location="${j2mefw_jt.jar}"/)
(pathelement location="${project.lib.servertests.jar}"/)
(/classpath)
(arg value="-testsuite"/)
(arg value="${project.home}"/)
(arg value="-config"/)
(arg value="${interview.jti}"/)
(arg value="-startHttp"/)
(/java)

Vladimir Sizikov

Hi Brice,

Thanks for the extra info. My comments below.

> I use two kind of scripts usually to launch harness :
>
> - from a shell :
> java -cp "./lib/*" com.sun.javatest.tool.Main -testsuite ./ -workDirectory -create -overwrite ./WorkDirectory

It is highly recommended to _not_ include everything in the classpath,
but only a javatest.jar.

So, in your case it would look like:

java -jar lib/javatest.jar -testsuite ./ .....

It is also simpler to remember, and to type ;)

> - Ant task from Netbeans :
>
> (java classname="com.sun.javatest.tool.Main" fork="true")
> (classpath)
> (pathelement location="${javatest.jar}"/)
> (pathelement location="${j2mefw_jt.jar}"/)
> (pathelement location="${project.lib.servertests.jar}"/)
> (/classpath)

Same here, you probably need to remove the last 2 JAR entries from the
classpath.

The reason for such recommendations is that JTHarnes uses its own
classloader to load the testsuite and testsuite related classes
(interview, custom test suite, etc). When the extra classes are in the
system classpath, this might lead to a *very* tricky and subtle bugs
(like some classes loaded by the system classloader and some others by
the JTHarness one), which are not immediately obvious, but still confusing.

Thanks,
--Vladimir
[vladimir_sizikov.vcf]
---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Vladimir Sizikov

On 8/14/2009 9:46 AM, Vladimir Sizikov wrote:
> So, in your case it would look like:
>
> java -jar lib/javatest.jar -testsuite ./ .....

And while we're at it, my typical way to start the JTHarness is as
simple as:

java -jar lib/javatest.jar

There is no need for additional parameters. JTHarness remembers all the
test suites configured and opened in it. So once you open a test suite
and configure it to you needs, next time when you start the JTHarness,
it will be there.

Thanks,
--Vladimir
[vladimir_sizikov.vcf]
---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net