You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Kevin Williams (JIRA)" <ji...@apache.org> on 2006/01/26 04:38:10 UTC

[jira] Closed: (TUSCANY-16) NPE when attempting to use ConnectionProperties (defined in config.xml) with CommandGroup

     [ http://issues.apache.org/jira/browse/TUSCANY-16?page=all ]
     
Kevin Williams closed TUSCANY-16:
---------------------------------


> NPE when attempting to use ConnectionProperties (defined in config.xml) with CommandGroup
> -----------------------------------------------------------------------------------------
>
>          Key: TUSCANY-16
>          URL: http://issues.apache.org/jira/browse/TUSCANY-16
>      Project: Tuscany
>         Type: Bug
>   Components: Java DAS RDB
>  Environment: Windows XP Pro, Eclipse 3.2M4 , jdk 1.5,  1/23/2006 tuscany DAS code stream. (build locally) 
>     Reporter: Ying Chen
>     Assignee: Kevin Williams

>
> This is an attempt to use the ConnectionProperties defined within .xml file,  in combination to CommandGroup. 
> The config.xml file contains a list of Command elements, and one ConnectionProperties element, along with some table definition. 
>         CommandGroup group = CommandGroup.FACTORY.createCommandGroup(getMappingInputStream());	
> 	Command updateCustomer =  group.getCommand("updateCustomer");   // here NPE happens. 
> This problem happens when a command group's getCommand() is called without envoking group.setConnection() .  
> As it seems normal for setConnection() not to be envoked due to the existence of the ConnectionProperties element in the config.xml.   Perhaps setConnection() is required??  Why wouldn't the CommandGroup pick up the connection definition from the config.xml ?
> The NPE trace is as follows: 
> java.lang.NullPointerException
> 	at org.apache.tuscany.das.rdb.impl.ConnectionImpl.<init>(ConnectionImpl.java:39)
> 	at org.apache.tuscany.das.rdb.impl.CommandImpl.setConnection(CommandImpl.java:113)
> 	at org.apache.tuscany.das.rdb.impl.CommandGroupImpl.getCommand(CommandGroupImpl.java:87)
> 	at com.ibm.etools.sdo.das.tests.suites.UpdateTest.testUpdateConfigWithConnection(UpdateTest.java:98)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:585)
> 	at junit.framework.TestCase.runTest(TestCase.java:154)
> 	at junit.framework.TestCase.runBare(TestCase.java:127)
> 	at junit.framework.TestResult$1.protect(TestResult.java:106)
> 	at junit.framework.TestResult.runProtected(TestResult.java:124)
> 	at junit.framework.TestResult.run(TestResult.java:109)
> 	at junit.framework.TestCase.run(TestCase.java:118)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:208)
> 	at junit.framework.TestSuite.run(TestSuite.java:203)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira