Luciano Resende wrote:
A few thoughts:
- You need the URI of an artifact inside the SCA contribution.
- I indicated before that I needed input/outputStreams as well.
- I think it's useful to have the URL of the contribution to have a base
URL to load artifacts (for example for WSDLs and XSDs if they do <import
... location="/aFile.xsd or /aFile.wsdl">).
So I suggest read/write(URL contributionURL, String artifactURI,
Input/OutputStream input/outputStream). In most cases you just use the
input/outputStream, sometimes you need to know the contributionURL, and
if you want to know the artifact URL you do new URL(contributionURL,
artifactURI).
I have committed under revision 533250 the base contribution URL and the
artifact URI to the read method.
I still have some concerns with the inputStream as today, inputStreams
are
created only if there is a particular processor for the artifactType
and if
the artifactProcessor needs to perform something with the artifact, by
moving the creation of the stream to the contribution service level, a
stream will need to be created for every artifact even if there is no
artifactProcesor to handle the file.
I'll investigate possible refactoring to make this more situable .
Luciano,
You probably don't need to create the input stream if there's no
URLArtifactProcessor to handle it. However, there is a potential issue
if a URLArtifactProcessor does not need the input stream because it's
going get the artifact contents in a different way, or if the
URLArtifactProcessor is only interested in artifacts matching a specific
name for example and is going to skip the other artifacts, in this case
we don't want to open all these input streams if they're not needed by
the URLArtifactProcessor.
That being said, the actual requirement for a stream was for
URLArtifactProcessor.write(...) as the URLArtifactProcessor wouldn't be
able to create an output stream from a URL. However, after more
thinking, I don't see a good use case for URLArtifactProcessor.write().
If somebody wants to write an artifact (a .composite file for example),
he can use the StAXArtifactProcessor.write(...) method.
So, I think that URLArtifactProcessor.write(...) is not necessary, and
we should just remove it from the URLArtifactProcessor interface.
URLArtifactProcessor.read(...) can stay as is, i.e. we do not pass a
stream to it, and the implementer of a URLArtifactProcessor has the
flexibility to create the stream from the URL the way he wants, and only
when he needs it.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
