db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luigi Lauro <luigi.la...@gmail.com>
Subject Re: [DERBY-2469] First alpha implementation available - help needed :)
Date Wed, 28 Mar 2007 05:35:23 GMT

On 28 Mar 2007, at 0:19, David Van Couvering wrote:

> I think everything is covered, except for the question of testing.   
> I recognize you just wanted to get something started and some  
> feedback. But before anything gets checked in, I would need to see  
> some validation that it works, even partially works.

This is for sure, I was not hoping for 'inclusion' or anything. I  
just wanted some feedbacks in order to avoid losing tons of time in  
things obvious to you derbyers and absolutely not obvious to me (this  
is what you are perfectly done BTW). Once I have what I need, I'll  
prepare a nicer package along with test cases for submission.

> Thinking about it further, rather than building new tests, I guess  
> all you need to exercise this code is to modify the  
> modules.properties file to use this storage factory, and then run  
> some subset of the Derby unit tests.

Good to know, so I need to check module.properties to enable my  
storage instead of the default ons

> I don't know the storage area very well, but I did find the following:
>
> java/testing/org/apache/derbyTesting/unitTests/store

I noticed them as well, but didn't find the time to try them yet. I  
will soon.

> I have never run these tests, but if you ask on the list with a new  
> subject header you should get some help.  Also, any help you may  
> need on configuring Derby to use your storage factory. What is  
> unclear to me is how to automate running in a Java Web Start  
> environment, vs. in a standard no-sandbox VM.  Do you know how to  
> do this?

This is another of my problem. I've even asked on the sun JNLP forums  
and JUnit ML regarding this (you can read about it here: http:// 
tech.groups.yahoo.com/group/junit/message/19132 ), and there seems  
there is _NO_ way to automate tests regarding JNLP APIs.

This is because even if the JNLP interfaces are available in every  
JVM in the jnlp.jar, the implementation classes doesn't get loaded  
unless you run your program from the javaws executable, which  
requires a JNLP descriptor file (which in turns requires you to put  
the file in a proper jar archive on a working webserver, etc...).

This means each time you even do a single change to a line of code  
you have to rebuild the whole package and test it outside the IDE by  
launching the javaws executable. I have YET to find a way for  
automating tests or debugging jnlp-api applications: even on the  
JUnit ML no luck, they just suggested to stub out the  
PersistenceService API, which is possible would 'defy' most of the  
testing since I would also want to test my implementation against the  
persistent service for real and not in theory :)

I've even tried a dirty trick, such as manually including the  
javaws.jar which cointans the com.sun.jnlp.* implementation classes,  
and manually initializing the registering the services, but it all  
fails horribly because of many missing tidbits (such as needed set  
system properties and the like... all this get probably done by the  
javaws executable itself or by some other yet to be found class).

Maybe by digging into the code for the needed time one can find a way  
to properly 'force' the implementation classes to get loaded  
manually, but I didn't have the time to try this for real.

> I also want to see at least some subset of our higher-level system  
> tests run under the JNLP storage factory configuration. Most of the  
> times the database created is quite small, so I don't think it  
> should be an issue.  In particular, I'm be curious to see what  
> security bugs/issues we hit as Derby tries to do various things  
> with the system under such a constrained SecurityManager as JWS.

I'm curious of this as well, let's hope derby doesn't go too far and  
it's JWS sandbox-friendly :) If it isn't, that will be my next step:  
to make it! :P

> In terms of running derbyall, a general principle is that no  
> checkin takes place without running derbyall.  However, I do  
> recognize that in your case this is not necessarily applicaable  
> since your code will never be hit by running the existing  
> regression suites.

I will try to run the most tests possible, but I have yet to find an  
easy way for doing this. Testing JNLP is only possible outside an IDE  
in a full JNLP deployed application package.

> What I would like to see is that one you have identified new tests  
> or new configurations of old tests that exercise your storage  
> service, then these new tests/configurations should be added to  
> derbyall.  I don't think this is required for initial checkin, though.

If I get the time, I would also love to provide a full test suite for  
exercising the whole StorageFactory/StorageFile interfaces in an  
implementation-agnostic way, and this would mean we would have an  
easy way to fully test each (old and new) storage implementations  
just by running this suite to check if the storage is fully  
specifications and API-compliant.

Currently I don't have enough derby storage knowledge to implement  
such an extensive test suite, and it's not my main focus. Maybe  
later, once JNLP is done :)

>
> Make sense?

It does! :)

To sum it up: I'll try my best to test my storageFactory with the  
tools I find or I have to develop for, and will report back once a  
minimal testing is done. Any help here is appreciated of course :)


Mime
View raw message