Check, I think that would indeed be the easiest solution, thanks!
-Christian
Felix Meschberger wrote:
Hi Christian,
One simple fix would be to create a simple wrapper around the
InputStream provided to the RP whose close method simply does nothing.
Regards
Felix
Am Freitag, den 14.03.2008, 15:51 +0100 schrieb Christian van Spaandonk:
Hi all,
I was looking into a problem with our Deployment Admin implementation
and it turned out that the cause was a Resource Processor closing the
stream it receives in the process(name, stream) method. This was a
problem because the DA implementation just passes on it's own stream
(containing the complete source deployment package) pointing to the
correct resource entry, if a RP decides to close the stream the DA runs
into problems when it tries to read the next resource.
One way to prevent this is by having the DA read the data from the
stream itself and then handing over an inputstream pointing to this
cached set of data, which may/should be closed by RP's. This, however,
does not really match with the on-the-fly/no-buffering installation
concept the DA specification illustrates.
Onto my question, should DA implementations make sure that RP's closing
streams do not cause problems or should RP's never close the stream they
receive (which may be common practice, as they did not create the stream
in the first place)? The spec seems to be a bit vague here.
friendly,
Christian van Spaandonk
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
