Topic
4 replies Latest Post - ‏2013-07-01T12:17:05Z by gsager
KenwyneJones
KenwyneJones
7 Posts
ACCEPTED ANSWER

Pinned topic Writing and unit testing WPF code 'outside' of WPF

‏2013-06-21T13:38:19Z |

Hi,

We have a number of different applications all written in WPF 6.1.5.2.  There is a bit of common functionality that needs to be introduced into each of them and rather than duplicate it in each application, we want to add it into a utility JAR that we have which is already being used by the WPF applications.

The issue is that this common functionality needs to manipulate data stored in IXml shared session variables.  Therefore, the code needs to have access to the IXml and other associated classes.  To allow this we have added factory.jar as a dependency within our utility JAR project (as a maven dependency with scope as 'provided').

We use TDD and so have started by writing our unit tests.  The unit tests use the IXml class and associated XmlUtil class to create the variables to be used in our tests.  The tests compile fine but when I try and run them I get the following error in the console:

!BSConfig.15!

And the following stack trace:

java.lang.ExceptionInInitializerError
at java.lang.J9VMInternals.initialize(J9VMInternals.java:222)
at com.XXXX.XXXX.XXXX.business.wpf.WPFToDistributorMappingTest.testWpfToDistributorMapping(WPFToDistributorMappingTest.java:66)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:600)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:24)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.lang.RuntimeException: !BSConfig.15!
at com.bowstreet.BSConfig.initHomeDir(BSConfig.java:922)
at com.bowstreet.BSConfig.getHomedir(BSConfig.java:1004)
at com.bowstreet.BSConfig.getConfigFilePath(BSConfig.java:1087)
at com.bowstreet.BSConfig.initConfigProperties(BSConfig.java:353)
at com.bowstreet.BSConfig.getProperty(BSConfig.java:517)
at com.bowstreet.BSConfig.getPropertyBoolean(BSConfig.java:780)
at com.bowstreet.BSConfig.isRunningOnServer(BSConfig.java:1075)
at com.bowstreet.util.XmlUtil.<clinit>(XmlUtil.java:1021)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
... 32 more

Which appears to be some WPF initialisation issue.

So, my question is, is it possible to utilise factory.jar in this way?  I.e. write code and unit test which exist outside of a WPF WAR file at compile, unit test and build time but will always be within a WPF WAR during runtime (our utility JAR is included in the WPF WAR that is created).

 

  • mburati
    mburati
    2466 Posts
    ACCEPTED ANSWER

    Re: Writing and unit testing WPF code 'outside' of WPF

    ‏2013-06-21T13:50:26Z  in response to KenwyneJones

    The WEF runtime relies on configuration information under the project and/or WAR's WEB-INF/config folder.    In order to find that outside of an appserver environment it uses the bowstreet.rootDirectory env variable.

    The reason you're getting a resource key as a message instead of an error string is likely due to missing bstres.jar in the classpath (English resource message bundles for WEF).   The non-English messages, for the languages WEF supports ootb are in bstres_nl1.jar.

    Try setting a VM argument to

    -Dbowstreet.rootDirectory=[path to one of your project's WEB-INF folder]

     

    Note,  overuse of session data is what limits many apps' scalability and performance, so try not to share anything via session that doesn't need to be shared (eg, nothing common across all users, nothing that can more easily be recalculated than stored).

    Note, 6.1.5.2 is getting fairly old.  If you're doing any new development you may want to consider a newer release (current is 8.0.0.2) and consider migrating the older portlets to a newer release if you're doing any updates to them, to take advantage of fixes, performance improvements and new features/functionality provided in the last couple of years.

    I hope that information helps.

    ..Mike Burati 
    The postings on this site are my own and do not necessarily represent the positions, strategies, or opinions of IBM.
  • KenwyneJones
    KenwyneJones
    7 Posts
    ACCEPTED ANSWER

    Re: Writing and unit testing WPF code 'outside' of WPF

    ‏2013-06-21T14:12:34Z  in response to KenwyneJones

    Thanks for the quick response.

    I'm not sure I was clear enough in my original question.  The project where we are attempting to do this development is ultimately built into a JAR file which is then packaged inside our WPF WAR files.  This project is not a web project, it is a 'common utilities' project and so does not have a WEB-INF project.

    I'm guessing that by the first paragraph in your reply, it is not possible to run unit tests which contain usage of things such as the IXml class against a project which has no knowledge of the WPF runtime (apart from having the factory.jar added as a dependency)?

    • KenwyneJones
      KenwyneJones
      7 Posts
      ACCEPTED ANSWER

      Re: Writing and unit testing WPF code 'outside' of WPF

      ‏2013-07-01T11:23:30Z  in response to KenwyneJones

      Hi,

      Is anyone able to provide any help to the above post?

      Thanks in advance.

      • gsager
        gsager
        98 Posts
        ACCEPTED ANSWER

        Re: Writing and unit testing WPF code 'outside' of WPF

        ‏2013-07-01T12:17:05Z  in response to KenwyneJones

         

        MB The WEF runtime relies on configuration information under the project and/or WAR's WEB-INF/config folder.    In order to find that outside of an appserver environment it uses the bowstreet.rootDirectory env variable

        So what mike is saying here is that the factory.jar when running  needs the bowstreet.rootDirectory .property set to a directory where some of our configuration files are located.  One that has to be available is the bowstreet.properties file  which the factory uses for a bunch of configuration settings,  there are other files here that are also used by the factory.jar.  So depending on what factory functions you are calling different parts of the project from the webinf directory might be used.  For example if all you are accessing is the IXml routinnes then maybe just having the property set to a directory that has your bowstreet.properties file might be good enough.  But if you are invoking builders or having the factory generate code it will need much more than the properties file.