That's quite interesting analysis. I would definitely consider this a bug as
we SHOULD also be able to work with the Sun version. I'm not sure what the
"fix" is yet. My THOUGHT would be in the LazyDataSource.load method would
do:
for (Attachment a : attachments) {
if (a.getId().equals(id)) {
this.dataSource = a.getDataHandler().getDataSource();
break;
} else {
//do something to force a load if applicable to make
//sure the later attachments work
}
}
Having a test case would be a huge help though.
Dan
On Friday, May 06, 2011 2:05:11 AM ext2 wrote:
> Hi:
> This problem is caused by javax.activation library;
> The failure project using javax.activation/activation/1.1. while the
> correct project using
> org.apache.geronimo.specs/geronimo-activation_1.1_spec/ 1.1;
>
> For illustrate the problem more clearly, check the difference of two
> activation library:
>
> Geronimo's :
> public DataHandler(DataSource ds) {
> this.ds = ds;
> this.flavor = new ActivationDataFlavor(ds.getContentType(), null);
> }
> // getContentType() of CXF's LazyDataSource will en-force it to be
> loaded; then: attachments(not last) will cached, and the last attachment
> still keep delegate to network stream;
>
> Sun's:
> public DataHandler(DataSource ds) {
> // save a reference to the incoming DS
> dataSource = ds;
> oldFactory = factory; // keep track of the factory
> }
> //doesn't call any method of LazyDataSource, so it cannot enforce
> the CXF's LazyDataSource to Load; so the attachments(not last one) , cannot
> be pre-cached; then 2 problem will occurs: 1) cannot release
> http-connection 2)if user-application doesn't consume the inputstream,
> just it. A temporary file will be left on disk and keep open;
--
Daniel Kulp
[email protected]
http://dankulp.com/blog
Talend - http://www.talend.com
