Hi Brent, I'm having a lot of trouble parsing this note. You seem to be talking about several semi-related things, but I can't put it all together.
1) You say that you are currently using SDOUtil.createTypeHelper(). That has been deprecated, but it should still work ... so why are you talking about changing to using TypeHelper.INSTANCE? 2) If you want to have an XSDHelper in the same scope as a given TypeHelper you should have been calling SDOUtil.createXSDHelper(TypeHelper scope). That's also deprecated now, but should still work. 3) The proper way to do this now is to create a HelperContext whenever you want a uniquely scoped set of helpers. You call SDOUtil.createHelperContext(). Then, if you want a TypeHelper, you call context.getTypeHelper() or for an XSDHelper you call context.getXSDHelper(). 4) I don't know what your getting at with the point about passing a factory class in the config file or DAS looking up types by URI. Can you explain the problems more clearly? Frank. "Brent Daniel" <[EMAIL PROTECTED]> wrote on 12/01/2006 03:33:10 PM: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
