You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Simon Laws (JIRA)" <tu...@ws.apache.org> on 2007/09/20 18:27:31 UTC
[jira] Created: (TUSCANY-1779) Determining the contribution
location (confusion over relative location URLs)
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Closed: (TUSCANY-1779) Determining the contribution location
(confusion over relative location URLs)
Posted by "Simon Laws (JIRA)" <tu...@ws.apache.org>.
[ 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org