Simon Laws wrote:
On Wed, May 27, 2009 at 12:29 PM, Mike Edwards
<[email protected]> wrote:
Ram,
I think it would be wise to compare the process described here with the
words in the OASIS Assembly spec on precisely this point.
Section 11.2.1 of the Public Review draft of the Assembly Spec says:
3468 Where present, artifact-related or packaging-related artifact
resolution mechanisms MUST be used
3469 by the SCA runtime to resolve artifact dependencies. [ASM12005] The SCA
runtime MUST raise
3470 an error if an artifact cannot be resolved using these mechanisms, if
present. [ASM12021]
This says that you should not mix the use of "artifact specific" mechanisms
with SCA artifact resolution mechanisms. Use one or other but never both.
It is my understanding that the location/schemaLocation attributes for
WSDL/XSD imports provide "hints" to the runtime for locating the artifact
but don't mandate that only the specified location can be searched.
So, in this case, the "artifact specific" mechanisms mandated by the
SCA Assembly spec are very flexible and would allow an implementation
to look in some other location if the artifact is not found at the
specified location. I think they would even allow artifacts in other
locations (e.g., a local cache) to be used in preference to going to
the specified location.
The question I ask is - why would you want to mix them?? If the artifacts
(such as WSDLs) are there inside one or other contribution, why use
@wsdlLocation at all?? And if you're using @wsdlLocation, why would you
include a copy of the target WSDL in your contribution? And what happens if
the two alternative artifacts are actually different?
This could make sense when the definitive master copy of a schema
or XSD artifact is located at a well-known URL, but this URL might
not be accessible because it is on a server with poor reliability
or the application is running without an internet connection.
In such cases it could be useful to package a local copy of the
artifact with the application for use in cases when the specified
location can't be accessed. In these cases, the master copy would
be used if it is accessible, and the local copy otherwise. Any
difference between these two copies would not be detected.
Yours, Mike.
Ramkumar R wrote:
Hi All,
We had a discuss on this topic (Use of non-SCA Mechanisms for Resolving
Artifacts) in the month of March under this thread
http://www.mail-archive.com/[email protected]/msg05956.html
What we agreed on as a process to follow for the non-SCA mechanism is.....
1. get artifact location from import/include
2. if there is a location then do artifact specific resolution
3. retrieve the artifact using the location provided
4. if no artifact found look in the current contribution for an
artifact providing the appropriate namespace
5. if not found report an error
6. else do sca specific resolution
7. use the sca artifact resolution mechanism to find an artifact
providing the appropriate namespace
8. if not found report an error
So going by this process, if the artifact specified in the location
attribute is not found an error is reported either in Step 5 or 8.
I believe, TUSCANY-2906 has been re-opened with an expectation that, the
artifacts should be resolved even if the
location attribute points to an invalid location. I believe that brings
back the question which had in the past as posted here....
http://www.mail-archive.com/[email protected]/msg06028.html
Now, the question is that, should we allow the artifact (WSDL/XSD) to get
resolved even if the artifact specified in the location
attribute is not found anywhere after following the above process?
--
Thanks & Regards,
Ramkumar Ramalingam
I think this means that step 4 should be removed from the list (I
don't actually think the code does this at the moment).
Simon
I don't think the SCA Assembly spec requires step 4 to be removed - see above.
Simon
