Kelvin, I don't have a strong opinion on which approach to take, but I would lean towards putting it on the generated Factory. For me, it seems more intuitive to tell a Factory to register itself into a specifix context rather than use an SDOUtil method to do the same.
One question, though: is it necessary to return the factory? registerStaticTypes() does not do this today. My concern is that a "getFactory()" method in either place does not automatically imply that registration is taking place. Brent On 12/8/06, kelvin goodson <[EMAIL PROTECTED]> wrote:
I've been thinking about this issue ( http://issues.apache.org/jira/browse/TUSCANY-684) and plan to work on it. Here are some thoughts In summary, we want to be able to hold and access type definitions, expressed in terms of generated java classes, within the context of a type scoping artifact. So first a few invariants about how I think this should work, and then I'd like to solicit input on some options. 1) We use the tuple of (XXXFactory.class,HelperContext instance) to get-or-create an instance of the generated XXXFactory class implementation. For every invocation of the Factory access method with a given XXXFactory.class,HelperContext pair, the same instance of XXXFactoryImpl is returned. 2) After invoking the factory access methods, using the TypeHelper instance associated with the HelperContext instance to create a DataObject in the namespace of the factory would return an instance of a generated class 3) We deprecate SDOUtil.registerStaticTypes(Class) So what I'm not yet convinced about is 1) where the interface to the function should sit and 2) where we maintain the state that maps the (XXXFactory.class,HelperContext instance) tuple to an XXXFactoryImpl instance In terms of where the function should sit, I think our choices in the absence of guidance from the spec is either on SDOUtil or on the generated classes themselves. Either of these choices have their upsides and downsides. Considering first the housing of the function on SDOUtil. We might imagine a method such as class SDOUtil { ... public static Factory getFactory(Class factoryInterface, HelperContext scope) } This method would examine state (wherever that may be housed) to see if a Factory for the namespace and within the scope already exists, and if so it would return it, if not it would create the factory, update the state to reference the newly created factory, and return the new factory The issues here are that 1) we don't currently have an abstract "Factory" artifact in our interface (We have the FactoryBase impl class, but the most concrete artifact in the inhertance scheme of things that is currently designed for user consumption is java.lang.Object) 2) every call to this method is going to require a cast to the specific XXXFactory before anything can be done We could avoid both these issues by housing the factory get-or-create method on a generated artifact, e.g. interface XXXFactory_InterfaceOfSomeSort { public XXXFactory getFactory(HelperContext scope); } or class XXXFactory_ClassOfSomeSort { static XXXFactory getFactory(HelperContext scope); } We could use the interface approach, and use the existing static XXXFactory INSTANCE as the object which the user can bootstrap Factory creation with ( XXXFactory.INSTANCE.getFactory(scope)) but we are trying to move away from dependencies on static INSTANCEs (should we be aiming to deprecate the generated static INSTANCEs in this update?) We could use the class approach, and use a static method on the exisiting XXXFactoryImpl (XXXFactoryImpl.getFactory(scope)) but it's ugly requiring the user to import an impl class We could introduce a new generated Helper type class per Factory to house the static method, e.g. public class XXXFactoryHelper { public static XXXFactory getFactory(HelperContext scope) } so that the user's code would look fairly clean XXXFactory xFac = XXXFactoryHelper.getFactory(scope); Of the generated artifact approaches, I like the last example best. We could use both approaches, and give the user the choice. The SDOUtil method would just delegate to the generated artifact method. The second issue is where to house the state that holds the mapping between the tuple and the factory instance. It seems to me that there are two reasonable choices 1) in the HelperContext instance, as a hashmap from namespace to Factory instance, or 2) in static state associated with the generated classes, as a hashmap from HelperContext instance to XXXFactory I favour (1) quite strongly, as I see the HelperContext as an instrument of placing control of concurrency and class loader issues firmly in the hands of the user. Assuming (1) it may be worth giving the implementation issue of exacly where with the HelperContext and it's associated helpers this state is maintained (or course if we ensure the implementation doesn't leak then we have flexibility to change this in the light of spec updates) It might seem natural to put it in the TypeHelperImpl, but TypeHelper is a spec artifact that ought to stay language neutral, so clouding the impl with Java considerations is not perhaps a good move. We could try to second guess the spec and create a JavaHelperImpl to house the state, but that would be its only function currently, so my thoughts are that I will house the state directly in the HelperContextImpl for now, and move it if and when it logically becomes part of a specified artifact. I'll give this a while for some feedback, and in the meantime I'm going to explore / prototype the the combination of SDOUtil.getFactory(Class, HelperContext) with housing the Factory instance mappings in the HelperContext. This would seem an OK approach, since I think little or no effort will wasted if anyone comes up with a convincing argument that we should take alternative elements of my proposition, or something completely different. Regards, Kelvin.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
