[
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]
