Ok... would it be possible to add a warning note into the Javadoc about
this? Something along the lines of: "Subclasses may use SoftReferences
to reference internal state. To ensure consist results, always create a
strong reference to result of getData() before invoking any other method
such as getContentType()".
If you guys can think of cleaner approach, I'm all ears.
Thanks,
Gili
Johan Compagner wrote:
i think testing for data == null on all getXXX in the IResourceStream
does fix all that.
public String getContentType()
{
if(data == null)
{
data = getData();
}
return DynamicByteArrayResource.this.getContentType();
}
/**
* @see wicket.util.resource.IResourceStream#getInputStream()
*/
public InputStream getInputStream() throws
ResourceStreamNotFoundException
{
if(data == null)
{
data = getData();
}
if (inputStream == null)
{
inputStream = new ByteArrayInputStream(data);
}
return inputStream;
}
/**
* @see wicket.util.watch.IModifiable#lastModifiedTime()
*/
public Time lastModifiedTime()
{
if(data == null)
{
data = getData();
}
return DynamicByteArrayResource.this.lastModifiedTime();
}
public long length()
{
if(data == null)
{
data = getData();
}
return (data != null) ? data.length : 0;
}
so now for one IResourceStream it will always work fine.
And you are guaranteed that all the methods like
lenght/lastmodfied/getContentType() are also exactly
for that data that is currently in the IResourceStream
johan
Gili wrote:
Many thanks.
One other little quirk... In my subclass, the cache is implemented
using SoftReferences. This means that when you invoke getData() you
get a strong reference to the cache data.
The implication is that if you want getContentType() to be
consistent with getData(), you must first invoke getData(), store the
strong reference, and *then* invoke getContentType(). This will
prevent the cache from being garbage collected before you retrieve the
content-type. If you do not do this, in theory the underlying database
value could change and the content-type value you'll get back will not
correspond to the same data you retrieved in a separated call.
This is all explained very neatly in my class' Javadoc but what
about Wicket's own code? I doubt it follows these procedures. The
DynamicByteArrayResource Javadoc does not mention any requirements or
concerns when using these two methods. Any ideas?
Gili
Johan Compagner wrote:
ok i removed the field, the setter an the constructor param
And made getContentType() abstract.
So besides getData() you also have to implement getContentType()
which is more logical..
johan
Gili wrote:
Hi,
I've got a problem with DynamicByteArrayResource. It requires
one to specify the content-type at construction time. If one is
reading the data from a database, this defeats the entire point of
lazy initialization.
I have an image repository and I don't know in advance the image
content-type or its data. Hitting it prematurely is expensive.
There should be a constructor that does not require a
content-type and it should be safe for one to defer until around the
time when getData() is invoked. That is, the specification of this
class should mention that getContentType() is guaranteed to be valid
only after getData() is invoked. Or alternatively, just make
getContentType() abstract and I'll lazy-initialize both values when
either method is invoked.
I could override getContentType() now, but there is still no
guarantee that callers of this class know that getContentType() is
potentially an expensive call. I have no idea how liberally Wicket
currently invokes this method. And it's also just the principal of
the matter, DynamicByteArrayResource shouldn't make such
assumptions. Remember, I proposed adding
StreamedDynamicImageResource and that patch was rejected in favor of
adding DynamicByteArrayResource instead; that's fine so long as it
actually meets the same requirements (which it does not yet).
Gili
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
--
http://www.desktopbeautifier.com/
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
