I think part of the concerns here are being addressed by the lazy loading piece described by Sebastien [1]. Now let me try to address some of the other issues related to how contribution root is calculated and how it finds the necessary artifacts inside a contribution.
- Calculating the contribution root : If not specified directly, this is done in couple ways by the runtime, basically considering the location of some artifacts, such as the composite file especified, or the sca-contribution.xml or the sca-deployables directory. When a composite file is specified on the initialization of SCADomain, that is going to be used to calculate the root of the contribution, and also to identify the contribution deployable .... See getContributionLocation [2] for more details. In the case of the implementation-spring, even tough you are providing different composite files, they are all located on the same folder, thus the contribution root is going to be the same. - Processing contribution artifacts : In order to allow for future plugability, the contribution service finds all artifacts on a given contribution, BUT will only process an artifact if there is a given artifact processor for the file type (e.g it might find text files, gif images, in the list of artifacts, but they will never be processed if there is no artifact processor for that specific file type). This approach allows you to plug different extensions that might have interest in specific file types in the future. It also provides you with a mechanism to resolve referenced artifacts, as the runtime will not look for specific files based on location anymore (e.g composites file can be placed anywhere, processors can be implemented to discover SDO types available, instead of having to provide <import.sdo> with given location of the SDO types, etc). Before, when we were not doing this way, a composite file was being expected in a given location (without flexibility), the load of this composite file was done recursively without much room for a resolve phase, and all other artifacts were being referenced by giving a specific location on the composite file, and I can't remember if you were really able to process new file types just by adding a new extension, you would probably have to update the composite file and provide a location of the file you want to process, so I think the contribution service is providing more flexibility here. That said, I'm open to suggestions for improvements. [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg18684.html [2] https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/host-embedded/src/main/java/org/apache/tuscany/sca/host/embedded/impl/DefaultSCADomain.java On 6/8/07, Mike Edwards <[EMAIL PROTECTED]> wrote:
Simon, That's exactly what happens. If fact, it is far, far worse than that - it searches for ALL resources, not just composites. In the case of Spring, I have sets of application-context.xml files in there - and it creates pointers to all of them. Whether resolution occurs for all the resources simply depends on whether there are resolvers for each type of resource. In a distributed environment, this is going to be nightmarish. It has to be changed, in my opinion. Yours, Mike. Simon Laws wrote: > I just tried this with the JMS test, i.e. added a second composite, and it > does feel a little odd. In the case where there is no > sca-contribution.xmlthe logc seems to look for the directory that > holds the composite file you > specify and load all the composites there rather that just the one you ask > for. Is that right? > > Simon > --------------------------------------------------------------------- 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]
