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 <[EMAIL PROTECTED]> wrote: > Thank you, Luciano. > > I have raise a JIRA issue ( > https://issues.apache.org/jira/browse/TUSCANY-1873). > > > > On 10/26/07, Luciano Resende <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > Thank you... > > Regards, > > Rajini > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
