Re: unit tests and woapplication bundles, resources, etc. SOLVED (sorta)
Re: unit tests and woapplication bundles, resources, etc. SOLVED (sorta)
- Subject: Re: unit tests and woapplication bundles, resources, etc. SOLVED (sorta)
- From: Chuck Hill <email@hidden>
- Date: Tue, 15 Apr 2008 10:52:35 -0700
On Apr 15, 2008, at 8:00 AM, Mr.G Brown wrote:
On Apr 11, 2008, at 5:05 PM, Chuck Hill wrote:
On Apr 11, 2008, at 1:08 PM, Greg Brown wrote:
Hi,
I am having trouble with my testing of my woapp.
FWIW, I never unit test my woapps. I never have any code in them
worth unit testing.
I test some utilitiies methods that are used everywhere, with regex
patterns that get changed, evolved.
"utilitiies methods that are used everywhere" sounds like something
that wants to live in a framework.
I have parameters that are in the Properties file, the woapp
accesses them through
System.getProperty("importLogFilename");
BUT, when running with the testng environment in eclipse, all the
strings from calls like System.getProperty("importLogFilename")
come up null. I am guessing it can't find/use the Properties file.
1. For bundle loading to work properly, you need to use a custom
Working Directory for the JUnit/TestNG launcher:
${workspace_loc:MyFW/dist/MyFW.framework/Resources/Java}
Apps are similar but a different path.
That looks suspiciously like my mutterings. Where is that from?
Your writings! I did look a little in the mailing list before asking
a question... :>)
Grin.
${workspace_loc:nucptdb/build/nucptdb.woa/Contents/Resources/Java}
Probably this for an app
${workspace_loc:nucptdb/build/nucptdb.woa}
Yes the above seems to work
I thought so. .framework and .woa bundles need a different "current
working directory" to load properly.
or maybe
${workspace_loc:nucptdb/build/nucptdb.woa/Contents}
2. Again, for bundle loading, add the jars from the built
framework / application (can be in the projects in the Eclipse
workspace) to the User Entries of the classpath and move above
whatever is there. Do the same for all the frameworks that it
references.
3. The usual connection dictionary setting classes to set things
up and switch prototypes etc.
4. Sometimes I need to call primeApplication, IIRC for component
tests:
WOApplication.primeApplication("MyFW", null,
"net.foo.bar.appserver.FWApplication");
Same result if I call WOApplication.primeApplication or not.
Where FWApplication is a subclass of WOApplication. You can also
leave the last param blank and it will use WOApplication -
sometimes that works for simple stuff.
Chuck
Not a BUNDLE of joy.
But NSBundles are always a joy! :-P
If the above does not work, try logging out NSBundle.allBundles()
and the details of NSBundle.mainBundle(). That might show up
something odd that points to the problem.
Chuck
I did add:
NSBundle.mainBundle.properties().list(System.out); which lists all
the properties and keys it can find.
And at one point in execution the properties where all there! But
at a prior time they were not. I thought it may be the how or when
the properties were accessed, they were used to initialize Strings
in a static block like:
public interface PropertyStrings {
final static String LOG4JCONFIGFILE =
System.getProperty("log4jconfigfile");
// For MedImage importerer & logs
final static String IMPORTLOGFILENAME =
System.getProperty("importLogFilename");
final static String IMPORTLOGDESTFILENAME =
System.getProperty("importLogDestFilename");
final static String IMPORTERDESTINATIONDIR =
System.getProperty("importerDestinationDir");
.....
}
IIRC, nothing gets loaded from the bundles until NSBundle is loaded
(and its static initializers set things up). Calling
NSBundle.allBundles() is one way to do this.
Which works fine for WOApp, when launched in the regular manner.
Want to guess what that loads? calling primeApplication() should also
do that, but you need to do it early in the test process.
( I hear somebody changed Java, and now its easy to bring in
constants with a: import static ..... statement. )
No idea on that.
When the static block is first referenced the Strings should be
initialized; they were being set to null, the problem I had, in case
anybody forgot. I added a static reference to the main bundle
first, before the strings got initialized, to reference and see what
was in the bundle when the static block gets initialized.
public interface PropertyStrings {
static NSBundle MYBUNDLE = NSBundle.mainBundle(); << NECESSARY
final static String LOG4JCONFIGFILE =
System.getProperty("log4jconfigfile");
// For MedImage importerer & logs
final static String IMPORTLOGFILENAME =
System.getProperty("importLogFilename");
final static String IMPORTLOGDESTFILENAME =
System.getProperty("importLogDestFilename");
...
}
and just by referring to NSBundle.mainBundle() first the
System.getProperty() methods then properly initialize the static
Strings, and everything works.
Yes.
I don't need to call WOApplication.primeApplication() or anything
else. It seems a little strange, but it seems the woapp environment
isn't quite set up.
It is not.
If I comment out the statement:
static NSBundle MYBUNDLE = NSBundle.mainBundle();
then it all the Strings get initialized to null, and if I leave it
in, then they get their values.
Moral of story: access your NSBundle early, as things don't seem to
be setup properly until you do ( or some call from some part of the
WO framework does, but this may occur much later than you want.)
Correct.
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden