search

computerline1z / okapi

Automatically exported from code.google.com/p/okapi
0 stars 0 forks source link

XMLFilter cannot be overridden cleanly due to mime type clash #361

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
If I want to subclass XMLFilter and use a different MIME type, things don't 
quite work out.  The XMLFilter constructor hard-codes 
MimeTypeMapper.XML_MIME_TYPE as the mime type for resources created by the 
filter.  But the encoderManager uses the subclass's getMimeType() to create the 
encoder mapping.  This mismatch can result in un-encoded output in target files.

I suggest adding a constructor for subclasses that accepts the overridden mime 
type.  Patch will be attached.  An allternate approach would be to hard-code 
MimeTypeMapper.XML_MIME_TYPE in getEncoderManager.  But the first seems more 
correct to me.

Original issue reported on code.google.com by tol...@gmail.com on 15 Aug 2013 at 11:23

GoogleCodeExporter commented 9 years ago 
Patch attached.  Apply with git am < FILE.

Original comment by tol...@gmail.com on 15 Aug 2013 at 11:33

Attachments:

GoogleCodeExporter commented 9 years ago 
Patch updated with documentation.

Original comment by tol...@gmail.com on 16 Aug 2013 at 3:31

Attachments:

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
public XMLFilter () {
   super(false, getMimeType(), IProcessor.DC_ALL);
}
Was obviously a dumb idea (too early in the morning...). Never mind.

Andrew: The problem with using a constructor with a parameter is that I don't 
think it'll work with the dynamic creation we use in the Filter configuration 
mapper. But maybe that is not an issue for you.

But I cannot think of any other way.

Original comment by yves.sav...@gmail.com on 17 Aug 2013 at 9:49

GoogleCodeExporter commented 9 years ago 
This issue was closed by revision acbeb87ab74f.

Original comment by yves.sav...@gmail.com on 17 Aug 2013 at 9:57

GoogleCodeExporter commented 9 years ago

Original comment by yves.sav...@gmail.com on 17 Aug 2013 at 9:57

GoogleCodeExporter commented 9 years ago 
Sorry for the late reply...

I don't think this would be a problem for dynamic creation, since the 
constructor is protected and thus only for use by subclasses, which themselves 
can offer a no-arg constructor.  Thanks for committing!

Original comment by tol...@gmail.com on 26 Aug 2013 at 7:49

GoogleCodeExporter commented 9 years ago 
This issue was closed by revision acbeb87ab74f.

Original comment by yves.sav...@gmail.com on 4 Sep 2013 at 8:47