This sounds reasonable, except for a couple of errors I get. Details inline.
On 4/11/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Jean-Sebastien Delfino wrote:
> Ignacio Silva-Lepe wrote:
>> Ok, so to try to answer my own question, it looks like the
>> implementation
>> loader can use a ComponentTypeDocumentProcessor (passing itself in
>> the constructor) and then calling read with the URL of the component
>> type side file. Does this sound ok?
>>
>
> This can work, but there is probably a better way to do it, see my
> comments below.
>
>>
>> On 4/10/07, Ignacio Silva-Lepe <[EMAIL PROTECTED]> wrote:
>>>
>>> How is this supposed to work now? Previously, an implementation
>>> loader had the option of asking the loader registry to load a
component
>>> type from a side file, and then it was able to downcast the returned
>>> component type to an extension-specific component type.
> Previously, an implementation Loader had to take care of the loading
> the optional .componentType side file. However, I'm not sure what you
> mean "downcast the returned component type to an extension-specific
> component type", how would you downcast it?
>
> We are using ArtifactProcessors instead of Loaders now, and the
> ArtifactProcessor for a particular extension does not need to load the
> .componentType side file itself. Your ArtifactProcessor can do the
> following:
> 1. In the read method, read the implementation artifact and turn it
> into the relevant Implementation model object
> 2. In the resolve method, call ArtifactResolver.resolve() to resolve
> the corresponding .componentType, and for example save a pointer to it
> in your Implementation model
> 3. Then, in the wire() method, implement the logic to merge the info
> from the .componentType and the info derived from the Implementation
> artifact, for example in the case of a java component we may need to
> reconcile references defined in the .componentType and the references
> resulting from the introspection of the Java component implementation
> class. This logic is really specific to your particular component
> Implementation type.
>
> I think that I need to make a small fix to
> o.a.t.assembly.ComponentType and add a URI string to it for step (2)
> to actually work correctly :) I'll send an update email describing how
> to resolve the ComponentType once I commit that small fix.
>
>>>
>>> Since a component type's file is a separate stream, how does an
>>> implementation loader (as a StAXArtifactProcessor that it is) kick off
>>> a separate stream read? Is there a pattern for this, and is there an
>>> exisiting component type reader that can be invoked? Or is this all
>>> left as an exercise to the developer? Or perhaps this is coming but
>>> not complete yet?
>>>
>>> Thanks
>>>
>>>
>>
>
>
Ignacio,
Under revision 527384, I added a URI field to ComponentType and
implemented ComponentTypeImpl.equals() to allow ComponentTypes to be
resolved by URI. This will allow you to do the following:
- in ArtifactProcessor.read(...):
YourImplementation implementation;
// Read your implementation object
....
// Form the URI of the expected .componentType file;
String uri = ...;
// Create a ComponentType and mark it unresolved
ComponentType componentType = assemblyFactory.createComponentType();
Where do I get assemblyFactory? Right now, my artifact processor implements
StAXArtifactProcessor<MyImplementation> and does not extend any class, so
it cannot inherit assemblyFactory. Should it be extending anything. I am
using
CRUDImplementationLoader as a model, though I realize that the CRUD sample
does not use a separate component type.
componentType.setURI(uri);
componentType.setUnresolved(true);
implementation.setComponentType(componentType);
return implementation;
- in ArtifactProcessor.resolve(YourImplementation implementation,
ArtifactResolver resolver)
ComponentType componentType =
resolver.resolve(implementation.getComponentType());
ArtifactResolver.resolve does not seem to take a ComponentType and
so I get a compilation error here.
if (!componentType.isUnresolved()) {
// You got a .componentType file!
}
Hope this helps.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
