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
  jat: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.

Regards

Simon

Reply via email to