I've figured out, that this might be a problem with autodetecting the content
type of a FileResourceStream. If our application uses the development mode,
we use our own ResourceStreamLocator for loading resources from the source
path rather than the class path. This was working in Wicket 1.4 without
problems. The used FileResourceStreams returned null as content type.
In the FileResourceStream class you can find this ...
@Override
public String getContentType()
{
// Let ResourceStreamRequestTarget handle content-type automatically
return null;
}
Where in Wicket 1.4 the Response class has an appropriate method to detect
the content type automatically ...
public void detectContentType(RequestCycle requestCycle, String uri)
{
...
}
But in Wicket 1.5. this might be handled in another way. The returned
content type is always unknown for css-files or image files. In addition
with our own WicketFilter implementation, where by default the content type
for all requests handled by this filter is set to "text/html", this results
in the problem described above.
Of course could our own ResourceStreamLocator handle the correct content
type, but the problem with auto-detecting the correct content type for
FileResourceStreams should be fixed anyway.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/PackageResourceReference-and-Doctype-in-Markup-file-tp3889467p3890212.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
