This is ending up all talk and no action so I'm going to again suggest just moving it now, pulling the bits into core as discussed and you've said you'll help with, and then seeing whats left and decide what to do with that then.
...ant On 10/11/06, Jim Marino <[EMAIL PROTECTED]> wrote:
>> I took a closer look at the ComponentType encapsulation problem. The >> problem resides in the fact that the generic component type element >> loader creates a generic component type as the component type side >> file is processed. What should happen is that the component type >> should be created by the implementation loader (e.g. >> PojoComponentType, or maybe ScriptComponentType) and passed into the >> loader. The load method on StAXElementLoader would need to be changed >> to: >> >> load(CompositeComponent parent, ModelObject object, XMLStreamReader >> reader, DeploymentContext deploymentContext) would >> >> Where "object" was a model object the loader would populate or null, >> in which case the loader would be responsible for creating one. > > > +1. So when object is null there simply no specialized component > type and > just the base would do. Right ? > Yep > In >> the case of custom component types, the implementation loader would >> create a subclass of ComponentType and pass it back into the loader >> registry. A script component type loader would then be responsible >> for introspecting the custom component type side file. > > > Here again is there a way where the custom component type loaders > are only > called for extensions i.e. only for those elements that are not > known to the > base ComponentType. This way we can avoid duplication of how the > common > stuff of properties / references / services get loaded. Am I off > track ? > I don't quite follow, can you point me to code that illustrates the problem? AtomicComponent implementations always need to deal with wires and properties being handed to them by the wiring fabric as they need to choose an injection implementation strategy. > Without this, we can't properly support scopes in side files so I'd >> like to get this fix in. > > Not only for the scopes. We are not able to get the basic sidefile > stuff up > in Pojo - meaning today if we wanted to try out Pojo implementation > of a > component with side files, we will end up in exceptions. Yes componentType side files are broken for POJOs as well but the fix I outlined will address that as well --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
