I'm running into an issue with the DAS' usage of SDO and looking for some ideas.
Currently in the trunk code, we are calling SDOUtil.createTypeHelper() to create a TypeHelper instance. When I convert the DAS over to use TypeHelper.INSTANCE or HelperProvider.getTypeHelper(), the behavior is different -- Types from previous junit tests remain registered, so we get errors when we try to create new Types with the same package URI as a previous DAS invocation. We can get the old behavior by creating a new HelperContext each time we build up a set of Types. However, I'm not sure that this the right thing to do. It disallows the scenario where a user registers types with XSDHelper.define() (or any other helper) and the DAS looks them up by a provided URI. 1) Is the scenario above using XSDHelper.define() something we want to support? We have talked in the past about having the DAS Config specify an SDO Factory class rather than a URI, so that would disallow this scenario as well. Maybe we should instead provide a DAS Factory method that accepts a List of Types to support this scenario? 2) If the XSDHelper scenario is something we want to support, how do we accomplish it? If we don't create a new HelperContext, we run into an issue where the DAS tries to create Types with package URIs that are already registered. We can get around this some of the time by creating a new HelperContext whenever the user has not specified a URI to look up existing Types. However, we are still creating a dynamic root Type in the case where static or predefined Types are used. This dynamic root Type will always have the same URI, so creating it a second time will fail. Any thoughts? Brent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
