Answers inline.

Ignacio Silva-Lepe wrote:
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.

It does not need to extend anything. Can you just pass the factory that you want to use to your ArtifactProcessor's constructor?

Also, you don't have to use the factory, it's up to you to choose to use a factory and then isolate yourself from a particular implementation of the model interfaces.


  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.

Sorry I forgot the first parameter :)
try resolver.resolve(ComponentType.class, implementation.getComponentType())


  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]





--
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to