You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Ignacio Silva-Lepe <is...@gmail.com> on 2007/04/10 21:55:55 UTC
Component types and loading them
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.
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
Re: Component types and loading them
Posted by ant elder <an...@gmail.com>.
On 4/11/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > On 4/11/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >>
> >> ant elder wrote:
> >> > I'm attempting the same thing just now for script components see [1].
> >> > Doesn't work yet, the .componentType file doesn't seem to get
> >> picked up.
> >> > Comments welcome...
> >> >
> >> > ...ant
> >> >
> >> > [1]
> >> >
> >>
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-script/src/main/java/org/apache/tuscany/implementation/script/ScriptArtifactProcessor.java
> >>
> >> >
> >> >
> >>
> >> Can you see a .componentType being loaded at all? Is
> >> ComponentTypeDocumentProcessor called to process .componentType
> >> documents in your SCA contribution? If not then maybe Luciano can jump
> >> in here and take a look as the processors are triggered by the
> >> Contribution service...
> >
> >
> > I'm still debugging and trying to understand how this should work so
> > can't
> > articulate well whats going on yet..but so far it looks like in the
> > SimpleRuntimeImpl start method there are two artifact processor
> > registries
> > created, and the one where the ComponentTypeProcessor is added to is
> > not the
> > one that processes the contribution so the .componentType side file is
> > ignored. Does that make any sense?
> >
> > ...ant
> >
>
> Yes it makes sense, the SimpleRuntimeImpl is missing the registration of
> the ComponentTypeDocumentProcessor, I added it under revision r527566.
> Can you update and try again? Thanks.
Yes thanks thats better, gets past this for now.
...ant
Re: Component types and loading them
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> On 4/11/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>> ant elder wrote:
>> > I'm attempting the same thing just now for script components see [1].
>> > Doesn't work yet, the .componentType file doesn't seem to get
>> picked up.
>> > Comments welcome...
>> >
>> > ...ant
>> >
>> > [1]
>> >
>> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-script/src/main/java/org/apache/tuscany/implementation/script/ScriptArtifactProcessor.java
>>
>> >
>> >
>>
>> Can you see a .componentType being loaded at all? Is
>> ComponentTypeDocumentProcessor called to process .componentType
>> documents in your SCA contribution? If not then maybe Luciano can jump
>> in here and take a look as the processors are triggered by the
>> Contribution service...
>
>
> I'm still debugging and trying to understand how this should work so
> can't
> articulate well whats going on yet..but so far it looks like in the
> SimpleRuntimeImpl start method there are two artifact processor
> registries
> created, and the one where the ComponentTypeProcessor is added to is
> not the
> one that processes the contribution so the .componentType side file is
> ignored. Does that make any sense?
>
> ...ant
>
Yes it makes sense, the SimpleRuntimeImpl is missing the registration of
the ComponentTypeDocumentProcessor, I added it under revision r527566.
Can you update and try again? Thanks.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component types and loading them
Posted by Luciano Resende <lu...@gmail.com>.
Yes, I think you are right about the registry where the
componentTypeProcessor is being ignored and not passed to the
contributionService. Let me see if I can find a quick solution...
On 4/11/07, ant elder <an...@gmail.com> wrote:
>
> On 4/11/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> > ant elder wrote:
> > > I'm attempting the same thing just now for script components see [1].
> > > Doesn't work yet, the .componentType file doesn't seem to get picked
> up.
> > > Comments welcome...
> > >
> > > ...ant
> > >
> > > [1]
> > >
> >
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-script/src/main/java/org/apache/tuscany/implementation/script/ScriptArtifactProcessor.java
> > >
> > >
> >
> > Can you see a .componentType being loaded at all? Is
> > ComponentTypeDocumentProcessor called to process .componentType
> > documents in your SCA contribution? If not then maybe Luciano can jump
> > in here and take a look as the processors are triggered by the
> > Contribution service...
>
>
> I'm still debugging and trying to understand how this should work so can't
> articulate well whats going on yet..but so far it looks like in the
> SimpleRuntimeImpl start method there are two artifact processor registries
> created, and the one where the ComponentTypeProcessor is added to is not
> the
> one that processes the contribution so the .componentType side file is
> ignored. Does that make any sense?
>
> ...ant
>
--
Luciano Resende
http://people.apache.org/~lresende
Re: Component types and loading them
Posted by ant elder <an...@gmail.com>.
On 4/11/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > I'm attempting the same thing just now for script components see [1].
> > Doesn't work yet, the .componentType file doesn't seem to get picked up.
> > Comments welcome...
> >
> > ...ant
> >
> > [1]
> >
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-script/src/main/java/org/apache/tuscany/implementation/script/ScriptArtifactProcessor.java
> >
> >
>
> Can you see a .componentType being loaded at all? Is
> ComponentTypeDocumentProcessor called to process .componentType
> documents in your SCA contribution? If not then maybe Luciano can jump
> in here and take a look as the processors are triggered by the
> Contribution service...
I'm still debugging and trying to understand how this should work so can't
articulate well whats going on yet..but so far it looks like in the
SimpleRuntimeImpl start method there are two artifact processor registries
created, and the one where the ComponentTypeProcessor is added to is not the
one that processes the contribution so the .componentType side file is
ignored. Does that make any sense?
...ant
Re: Component types and loading them
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> I'm attempting the same thing just now for script components see [1].
> Doesn't work yet, the .componentType file doesn't seem to get picked up.
> Comments welcome...
>
> ...ant
>
> [1]
> https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-script/src/main/java/org/apache/tuscany/implementation/script/ScriptArtifactProcessor.java
>
>
Can you see a .componentType being loaded at all? Is
ComponentTypeDocumentProcessor called to process .componentType
documents in your SCA contribution? If not then maybe Luciano can jump
in here and take a look as the processors are triggered by the
Contribution service...
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component types and loading them
Posted by ant elder <an...@gmail.com>.
I'm attempting the same thing just now for script components see [1].
Doesn't work yet, the .componentType file doesn't seem to get picked up.
Comments welcome...
...ant
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/implementation-script/src/main/java/org/apache/tuscany/implementation/script/ScriptArtifactProcessor.java
On 4/11/07, Ignacio Silva-Lepe <is...@gmail.com> wrote:
>
> This sounds reasonable, except for a couple of errors I get. Details
> inline.
>
> On 4/11/07, Jean-Sebastien Delfino <js...@apache.org> 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 <is...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
Re: Component types and loading them
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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 <js...@apache.org> 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 <is...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component types and loading them
Posted by Ignacio Silva-Lepe <is...@gmail.com>.
This sounds reasonable, except for a couple of errors I get. Details inline.
On 4/11/07, Jean-Sebastien Delfino <js...@apache.org> 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 <is...@gmail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Component types and loading them
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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 <is...@gmail.com> 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();
componentType.setURI(uri);
componentType.setUnresolved(true);
implementation.setComponentType(componentType);
return implementation;
- in ArtifactProcessor.resolve(YourImplementation implementation,
ArtifactResolver resolver)
ComponentType componentType =
resolver.resolve(implementation.getComponentType());
if (!componentType.isUnresolved()) {
// You got a .componentType file!
}
Hope this helps.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component types and loading them
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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 <is...@gmail.com> 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
>>
>>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Component types and loading them
Posted by Ignacio Silva-Lepe <is...@gmail.com>.
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?
On 4/10/07, Ignacio Silva-Lepe <is...@gmail.com> 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.
>
> 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
>
>