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 <[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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
