You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Luciano Resende <lu...@gmail.com> on 2008/02/06 19:04:26 UTC
Re: Resolving Component type files
I guess we have couple scenarios here :
- Considering contribution A importing a java package from
Contribution B, we can have the componentType in either Contribution
A(supported today) or contribution B (not working: TUSCANY-1873).
- We can also consider Contribution A importing a java package from
Contribution B, but sharing a componentType from a Contribution C.
We can also abstract the componentType file to some type of resource,
that needs to be imported from a different contribution, so I was
thinking on creating a resource import/export, that would work for
componentType and also for other types of resources that can be
addressed by a given URI.
Thoughts ?
On Oct 29, 2007 12:59 AM, Rajini Sivaram <ra...@googlemail.com> wrote:
> Thank you, Luciano.
>
> I have raise a JIRA issue (
> https://issues.apache.org/jira/browse/TUSCANY-1873).
>
>
>
> On 10/26/07, Luciano Resende <lu...@gmail.com> wrote:
> >
> > After researching what the SCA spec says, looks like your scenario is
> > valid :
> >
> > from Java C&I:
> > 391 A component type can optionally be specified in a side file. The
> > component type side file is found with the
> > 392 same classloader that loaded the Java class. The side file must be
> > located in a directory that corresponds to
> > 393 the namespace of the implementation and have the same name as the
> > Java class, but with a
> > 394 .componentType extension instead of the .class extension.
> >
> > Also, as you mentioned, the current implementation does not consider
> > "import/export" when resolving the componentTypes.
> >
> > I think we should start by raising a jira, and discussing what's the
> > best solution here, should we just reuse some already existent
> > import/export to configure the componentType model resolver ? You
> > mentioned the name space import, but as this is related to specific
> > implementation types, maybe the java import/export ?
> >
> > I'll keep thinking and do some investigation on this area...
> >
> > Thoughts ?
> >
> > On 10/25/07, Rajini Sivaram <ra...@googlemail.com> wrote:
> > > Hello,
> > >
> > > Is there any reason why unlike CompositeModelResolver and
> > > ConstrainingTypeModelResolver, ComponentTypeModelResolver does not look
> > at
> > > imported namespaces for resolving component type files?
> > >
> > > My test case contains:
> > > ContributionA : contains a composite file, with a component C1
> > > ContributionB: contains the Java implementation classes for C1 (
> > > x.y.C1.class), and the componentType file (x.y.C1.componentType)
> > >
> > > The model resolver used to resolve the composite is associated with
> > > ContributionA, and when implementation.java looks for the componentType
> > > file using this model resolver, it does not find it, since it doesn't
> > look
> > > anywhere except in ContributionA.
> > >
> > > Is this a valid test case, or should the componentType file always be in
> > > ContributionA, along with the composite?
> > >
> > > If the componentType file is allowed to be inside ContributionB (since
> > > componentType file describes an implementation, I would have expected it
> > to
> > > be colocated with the implementation), what type of import/export
> > statement
> > > should be used in ContributionA? ContributionA contains <
> > import.javapackage="
> > > x.y"/> to find the implementation class x.y.C1. Should that be somehow
> > used
> > > to resolve the componentType file as well, or should there be another
> > > namespace import specifically for the componentType file (<import
> > > namespace="x.y"/>)?
> > >
> > >
> > > Thank you...
> > >
> > > Regards,
> > >
> > > Rajini
> > >
> >
> >
> > --
> > Luciano Resende
> > Apache Tuscany Committer
> > http://people.apache.org/~lresende
> > http://lresende.blogspot.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
> Thank you...
>
> Regards,
>
> Rajini
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Resolving Component type files
Posted by Luciano Resende <lu...@gmail.com>.
I think your view is right, so that's why we are adjusting the
resolution of componentType files to also consider the imported
contribution, where the java files are located. But I think we should
also consider the scenario where you are contributing a jar that you
don't have access to modify it, and then you might need to have the
componentType file in a different contribution. Would you agree ?
On Thu, Feb 21, 2008 at 9:04 AM, Mike Edwards
<mi...@gmail.com> wrote:
> Folks,
>
> Only just noticed this.
>
> I have a particular view of componentType files, which you may not agree
> with ;-)
>
> Component type files are better named "Implementation Info" files - they
> are intimately tied to the implementation class in Java. The original
> idea was that the file would "sit alongside" the Java class file. It
> would be logical to do this as it would be created by the developer of
> the class to provide extra metadata about the Java class that cannot be
> derived from the class by introspection.
>
> So it seems foreign to me to go searching somewhere else looking for the
> componentType file - it should be there in the contribution containing
> the Java class - ideally in the "same place" (same directory). So
> searching should be virtually trivial. And if the component type file
> ain't there, don't go searching anywhere else for it !! It certainly
> makes no sense at all for the component type file to be in some other
> contribution.
>
> Of course, this does NOT apply for the other types of resource files
> that you have discussed.
>
> Yours, Mike.
>
>
>
> Luciano Resende wrote:
> > I guess we have couple scenarios here :
> >
> > - Considering contribution A importing a java package from
> > Contribution B, we can have the componentType in either Contribution
> > A(supported today) or contribution B (not working: TUSCANY-1873).
> >
> > - We can also consider Contribution A importing a java package from
> > Contribution B, but sharing a componentType from a Contribution C.
> >
> > We can also abstract the componentType file to some type of resource,
> > that needs to be imported from a different contribution, so I was
> > thinking on creating a resource import/export, that would work for
> > componentType and also for other types of resources that can be
> > addressed by a given URI.
> >
> > Thoughts ?
> >
> >
> > On Oct 29, 2007 12:59 AM, Rajini Sivaram <ra...@googlemail.com> wrote:
> >> Thank you, Luciano.
> >>
> >> I have raise a JIRA issue (
> >> https://issues.apache.org/jira/browse/TUSCANY-1873).
> >>
> >>
> >>
> >> On 10/26/07, Luciano Resende <lu...@gmail.com> wrote:
> >>> After researching what the SCA spec says, looks like your scenario is
> >>> valid :
> >>>
> >>> from Java C&I:
> >>> 391 A component type can optionally be specified in a side file. The
> >>> component type side file is found with the
> >>> 392 same classloader that loaded the Java class. The side file must be
> >>> located in a directory that corresponds to
> >>> 393 the namespace of the implementation and have the same name as the
> >>> Java class, but with a
> >>> 394 .componentType extension instead of the .class extension.
> >>>
> >>> Also, as you mentioned, the current implementation does not consider
> >>> "import/export" when resolving the componentTypes.
> >>>
> >>> I think we should start by raising a jira, and discussing what's the
> >>> best solution here, should we just reuse some already existent
> >>> import/export to configure the componentType model resolver ? You
> >>> mentioned the name space import, but as this is related to specific
> >>> implementation types, maybe the java import/export ?
> >>>
> >>> I'll keep thinking and do some investigation on this area...
> >>>
> >>> Thoughts ?
> >>>
> >>> On 10/25/07, Rajini Sivaram <ra...@googlemail.com> wrote:
> >>>> Hello,
> >>>>
> >>>> Is there any reason why unlike CompositeModelResolver and
> >>>> ConstrainingTypeModelResolver, ComponentTypeModelResolver does not look
> >>> at
> >>>> imported namespaces for resolving component type files?
> >>>>
> >>>> My test case contains:
> >>>> ContributionA : contains a composite file, with a component C1
> >>>> ContributionB: contains the Java implementation classes for C1 (
> >>>> x.y.C1.class), and the componentType file (x.y.C1.componentType)
> >>>>
> >>>> The model resolver used to resolve the composite is associated with
> >>>> ContributionA, and when implementation.java looks for the componentType
> >>>> file using this model resolver, it does not find it, since it doesn't
> >>> look
> >>>> anywhere except in ContributionA.
> >>>>
> >>>> Is this a valid test case, or should the componentType file always be in
> >>>> ContributionA, along with the composite?
> >>>>
> >>>> If the componentType file is allowed to be inside ContributionB (since
> >>>> componentType file describes an implementation, I would have expected it
> >>> to
> >>>> be colocated with the implementation), what type of import/export
> >>> statement
> >>>> should be used in ContributionA? ContributionA contains <
> >>> import.javapackage="
> >>>> x.y"/> to find the implementation class x.y.C1. Should that be somehow
> >>> used
> >>>> to resolve the componentType file as well, or should there be another
> >>>> namespace import specifically for the componentType file (<import
> >>>> namespace="x.y"/>)?
> >>>>
> >>>>
> >>>> Thank you...
> >>>>
> >>>> Regards,
> >>>>
> >>>> Rajini
> >>>>
> >>>
> >>> --
> >>> Luciano Resende
> >>> Apache Tuscany Committer
> >>> http://people.apache.org/~lresende
> >>> http://lresende.blogspot.com/
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>
> >>>
> >> Thank you...
> >>
> >> Regards,
> >>
> >> Rajini
> >>
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Resolving Component type files
Posted by Mike Edwards <mi...@gmail.com>.
Folks,
Only just noticed this.
I have a particular view of componentType files, which you may not agree
with ;-)
Component type files are better named "Implementation Info" files - they
are intimately tied to the implementation class in Java. The original
idea was that the file would "sit alongside" the Java class file. It
would be logical to do this as it would be created by the developer of
the class to provide extra metadata about the Java class that cannot be
derived from the class by introspection.
So it seems foreign to me to go searching somewhere else looking for the
componentType file - it should be there in the contribution containing
the Java class - ideally in the "same place" (same directory). So
searching should be virtually trivial. And if the component type file
ain't there, don't go searching anywhere else for it !! It certainly
makes no sense at all for the component type file to be in some other
contribution.
Of course, this does NOT apply for the other types of resource files
that you have discussed.
Yours, Mike.
Luciano Resende wrote:
> I guess we have couple scenarios here :
>
> - Considering contribution A importing a java package from
> Contribution B, we can have the componentType in either Contribution
> A(supported today) or contribution B (not working: TUSCANY-1873).
>
> - We can also consider Contribution A importing a java package from
> Contribution B, but sharing a componentType from a Contribution C.
>
> We can also abstract the componentType file to some type of resource,
> that needs to be imported from a different contribution, so I was
> thinking on creating a resource import/export, that would work for
> componentType and also for other types of resources that can be
> addressed by a given URI.
>
> Thoughts ?
>
>
> On Oct 29, 2007 12:59 AM, Rajini Sivaram <ra...@googlemail.com> wrote:
>> Thank you, Luciano.
>>
>> I have raise a JIRA issue (
>> https://issues.apache.org/jira/browse/TUSCANY-1873).
>>
>>
>>
>> On 10/26/07, Luciano Resende <lu...@gmail.com> wrote:
>>> After researching what the SCA spec says, looks like your scenario is
>>> valid :
>>>
>>> from Java C&I:
>>> 391 A component type can optionally be specified in a side file. The
>>> component type side file is found with the
>>> 392 same classloader that loaded the Java class. The side file must be
>>> located in a directory that corresponds to
>>> 393 the namespace of the implementation and have the same name as the
>>> Java class, but with a
>>> 394 .componentType extension instead of the .class extension.
>>>
>>> Also, as you mentioned, the current implementation does not consider
>>> "import/export" when resolving the componentTypes.
>>>
>>> I think we should start by raising a jira, and discussing what's the
>>> best solution here, should we just reuse some already existent
>>> import/export to configure the componentType model resolver ? You
>>> mentioned the name space import, but as this is related to specific
>>> implementation types, maybe the java import/export ?
>>>
>>> I'll keep thinking and do some investigation on this area...
>>>
>>> Thoughts ?
>>>
>>> On 10/25/07, Rajini Sivaram <ra...@googlemail.com> wrote:
>>>> Hello,
>>>>
>>>> Is there any reason why unlike CompositeModelResolver and
>>>> ConstrainingTypeModelResolver, ComponentTypeModelResolver does not look
>>> at
>>>> imported namespaces for resolving component type files?
>>>>
>>>> My test case contains:
>>>> ContributionA : contains a composite file, with a component C1
>>>> ContributionB: contains the Java implementation classes for C1 (
>>>> x.y.C1.class), and the componentType file (x.y.C1.componentType)
>>>>
>>>> The model resolver used to resolve the composite is associated with
>>>> ContributionA, and when implementation.java looks for the componentType
>>>> file using this model resolver, it does not find it, since it doesn't
>>> look
>>>> anywhere except in ContributionA.
>>>>
>>>> Is this a valid test case, or should the componentType file always be in
>>>> ContributionA, along with the composite?
>>>>
>>>> If the componentType file is allowed to be inside ContributionB (since
>>>> componentType file describes an implementation, I would have expected it
>>> to
>>>> be colocated with the implementation), what type of import/export
>>> statement
>>>> should be used in ContributionA? ContributionA contains <
>>> import.javapackage="
>>>> x.y"/> to find the implementation class x.y.C1. Should that be somehow
>>> used
>>>> to resolve the componentType file as well, or should there be another
>>>> namespace import specifically for the componentType file (<import
>>>> namespace="x.y"/>)?
>>>>
>>>>
>>>> Thank you...
>>>>
>>>> Regards,
>>>>
>>>> Rajini
>>>>
>>>
>>> --
>>> Luciano Resende
>>> Apache Tuscany Committer
>>> http://people.apache.org/~lresende
>>> http://lresende.blogspot.com/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>> Thank you...
>>
>> Regards,
>>
>> Rajini
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Resolving Component type files
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Luciano Resende wrote:
> Do you want to restrict this to file ? Some bindings, like
> binding.http can point to a specific folder, that's why I thought
> <import.resource> would be more appropriate name for this new import ?
You're right we need to support folders too, import.resource is better.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Resolving Component type files
Posted by Luciano Resende <lu...@gmail.com>.
On Feb 15, 2008 3:31 PM, Jean-Sebastien Delfino <js...@apache.org> wrote:
> Luciano Resende wrote:
> > I guess we have couple scenarios here :
> >
> > - Considering contribution A importing a java package from
> > Contribution B, we can have the componentType in either Contribution
> > A(supported today) or contribution B (not working: TUSCANY-1873).
> >
> > - We can also consider Contribution A importing a java package from
> > Contribution B, but sharing a componentType from a Contribution C.
> >
> > We can also abstract the componentType file to some type of resource,
> > that needs to be imported from a different contribution, so I was
> > thinking on creating a resource import/export, that would work for
> > componentType and also for other types of resources that can be
> > addressed by a given URI.
> >
> > Thoughts ?
> >
>
> We need a new type of import for file resources like HTML files and
> property value value files, for example:
> <import.file uri="my/pages/store.html"/>
> <import.file uri="my/properties/value.xml">
Do you want to restrict this to file ? Some bindings, like
binding.http can point to a specific folder, that's why I thought
<import.resource> would be more appropriate name for this new import ?
>
> ComponentType files are a different subject.
>
> I think that the following should be sufficient to find
> my.sample.store.Store.componentType:
> <import.java package="my.sample.store"/>
>
> or to find my/processes/Store.componentType describing
> my/processes/Store.bpel:
> <import namespace="http://my/sample/bpel/"/>
>
> In other words, the application developer should not have to write
> another <import.xyz> to import the .componentType file separately,
> importing the implementation artifact should be sufficient.
Yes, that's how I have it working locally, I should be able to committ
this soon.
As for the new import/export, I probably need little more time to get
a good iTest completed and make sure things are working in couple
different scenarios.
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Resolving Component type files
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Luciano Resende wrote:
> I guess we have couple scenarios here :
>
> - Considering contribution A importing a java package from
> Contribution B, we can have the componentType in either Contribution
> A(supported today) or contribution B (not working: TUSCANY-1873).
>
> - We can also consider Contribution A importing a java package from
> Contribution B, but sharing a componentType from a Contribution C.
>
> We can also abstract the componentType file to some type of resource,
> that needs to be imported from a different contribution, so I was
> thinking on creating a resource import/export, that would work for
> componentType and also for other types of resources that can be
> addressed by a given URI.
>
> Thoughts ?
>
We need a new type of import for file resources like HTML files and
property value value files, for example:
<import.file uri="my/pages/store.html"/>
<import.file uri="my/properties/value.xml">
ComponentType files are a different subject.
I think that the following should be sufficient to find
my.sample.store.Store.componentType:
<import.java package="my.sample.store"/>
or to find my/processes/Store.componentType describing
my/processes/Store.bpel:
<import namespace="http://my/sample/bpel/"/>
In other words, the application developer should not have to write
another <import.xyz> to import the .componentType file separately,
importing the implementation artifact should be sufficient.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org