[ https://issues.apache.org/jira/browse/TUSCANY-1779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Simon Laws closed TUSCANY-1779. ------------------------------- Resolution: Won't Fix There is now a new mechanism (workspace) for locating and parsing contributions and for configuring nodes > Determining the contribution location (confusion over relative location URLs) > ----------------------------------------------------------------------------- > > Key: TUSCANY-1779 > URL: https://issues.apache.org/jira/browse/TUSCANY-1779 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Core Runtime > Affects Versions: Java-SCA-1.0 > Environment: All > Reporter: Simon Laws > Fix For: Java-SCA-Next > > > SCADomain, in both of its guises, allows the details of which contribution to > load to be specified. > the standalone version > o.a.t.s.host.embedded.SCADomain.newInstance(String domainURI, String > contributionLocation, String... composites) > and the distributed version > o.a.t.s.domain.SCADomain.newInstance(String domainURI, String nodeURI, String > contributionLocation, String... composites) { > I have found this confusing so, by looking at the code, here is what I think > the rules are; > contributionLocation - an absolute path to a contribution in URL form, e.g > file://C:/mydirA > jar:file://C:/myjar.jar > composite(s) - the name of a composite file(s) e.g. > mycomposite.composite > somedir/mycomposite.composite > So the various combinations give rise to > contributionLocation set / composite null > loads all contributions under the contribution location identified > contributionLocation null / composite set > finds the location of your compsite on the classpath and uses that as the > contribution location. It loads the named composite from there > contributionLocation / composite > loads the named composite from the specified contribution path > contributionLocation null / composite null > This option is also used if the above rules don't identify a contribution > URL for whatever reason. > No contribution has been specified so look for the following in order and > use the location of the first one found as the contribution location > META-INF/sca-contribution.xml > META-INF/sca-contribution-generated.xml > META-INF/sca-deployables directory > > The slight wrinkle with the code currently is that the algorithm is coded > such that if you specify a relative ContributionLocation (which is not valid > according to what I have set out above) then it is simply ignored and the > algorithm falls back to the other mechanisms for finding the contribution > location with potentially confusing results, for example, if I use the > reasonable looking > SCADomain domain = SCADomain.newInstance("http://localhost:8080", > "somedir/someotherdir", "some.composite"); > Then this will actually just look on the classpath for " some.composite" > which is probably not what was expected. > We could fix this in code by not testing for an absolute contribution > location path and letting it throw a malformed url exception. However this > doesn't seem absolutely essential to be done right now so I propose to raise > a JIRA and tidy up the above as a section in the documentation. -- 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]