Re: Import/Export Resources, was Re: Resolving Component type files
I have completed the remaining work for (contribution-resource). You can now define a import.resource element in your sca-contribution.xml and then it will be used by contribution service when resolving resources/artifacts. Exporting resources using sca-contribution.xml : contribution xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://store; xmlns:helloworld=http://store; export.resource uri=ufservices/store.html/ /contribution Importing resources using sca-contribution-xml : contribution xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://store; xmlns:store=http://store; deployable composite=store:store/ import.resource uri=ufservices/store.html/ /contribution These definition will be used in conjunction with ArtifactModelResolver to properly resolve artifacts in different contributions using resource import/export. Please let me know if you have questions or comments. On Tue, Feb 19, 2008 at 1:20 PM, Luciano Resende [EMAIL PROTECTED] wrote: I have committed the new import/export resource module (contribution-resource) under revision #629235. This still need to be integrated to the runtime and proper iTests need to be created. These all should be ready in the next day or so. On Feb 18, 2008 6:35 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- 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]
Re: Resolving Component type files
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 [EMAIL PROTECTED] 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 [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 CI: 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
Re: Resolving Component type files
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 CI: 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]
Import/Export Resources, was Re: Resolving Component type files
I have committed the new import/export resource module (contribution-resource) under revision #629235. This still need to be integrated to the runtime and proper iTests need to be created. These all should be ready in the next day or so. On Feb 18, 2008 6:35 PM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
Re: Resolving Component type files
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Assigned: (TUSCANY-1873) Imported contributions not used in resolving component type files
[ https://issues.apache.org/jira/browse/TUSCANY-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende reassigned TUSCANY-1873: Assignee: Luciano Resende Imported contributions not used in resolving component type files -- Key: TUSCANY-1873 URL: https://issues.apache.org/jira/browse/TUSCANY-1873 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Reporter: Rajini Sivaram Assignee: Luciano Resende Fix For: Java-SCA-Next The details of the failing scenario and Luciano's response are on the dev mailing list at: http://marc.info/?l=tuscany-devm=119332616624723w=2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (TUSCANY-1873) Imported contributions not used in resolving component type files
[ https://issues.apache.org/jira/browse/TUSCANY-1873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luciano Resende resolved TUSCANY-1873. -- Resolution: Fixed Scenario added to java import/export contribution iTests. Enhancements available in componentType modelResolver under revision #628592. Imported contributions not used in resolving component type files -- Key: TUSCANY-1873 URL: https://issues.apache.org/jira/browse/TUSCANY-1873 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Reporter: Rajini Sivaram Assignee: Luciano Resende Fix For: Java-SCA-Next The details of the failing scenario and Luciano's response are on the dev mailing list at: http://marc.info/?l=tuscany-devm=119332616624723w=2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resolving Component type files
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (TUSCANY-1873) Imported contributions not used in resolving component type files
Imported contributions not used in resolving component type files -- Key: TUSCANY-1873 URL: https://issues.apache.org/jira/browse/TUSCANY-1873 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Reporter: Rajini Sivaram The details of the failing scenario and Luciano's response are on the dev mailing list at: http://marc.info/?l=tuscany-devm=119332616624723w=2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Resolving Component type files
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 CI: 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
Re: Resolving Component type files
After researching what the SCA spec says, looks like your scenario is valid : from Java CI: 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]
Resolving Component type files
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
