Hello fellow XWikiers, I now have an XWiki 5.0.3 and an XWiki 5.1 where my picture never gets downsized. e.g. /xwiki/bin/download/XWiki/polx/photo%2Dpasseport%2DPaul%2D2012%2D07.jpg?width=50&height=50&keepAspectRatio=true has width 345 x 443 (the original). How can I debug this? The log does not seem to say and it seems not related to have an AWT thread at hand (the 5.1 is run with a graphics environment). thanks in advance. Paul _______________________________________________ users mailing list users(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/users

Hello fellow XWikiers, I now have an XWiki 5.0.3 and an XWiki 5.1 where my picture never gets downsized. e.g. /xwiki/bin/download/XWiki/polx/photo%2Dpasseport%2DPaul%2D2012%2D07.jpg?width=50&height=50&keepAspectRatio=true has width 345 x 443 (the original).

Also not the case: the result of identify: 200x256 200x256+0+0 8-bit sRGB 50.8KB 0.000u 0:00.000 The image plugin would be doing this? Indeed it is configured: com.xpn.xwiki.plugin.image.ImagePlugin,\ It seems to be living inside xwiki-platform-legacy-oldcore-5.1.jar but maybe that plugin is disabled?

Yes, that's the plugin. If you found it configured in xwiki.cfg and got it in velosity it's active. I suppose it's in oldcore because it's a plugin and not a component and, afaik, it's not (yet) possible to do it in a component since it intercepts the download action. Every time you access a file using the download action (/xwiki/bin/download/...) the downloadAttachment method in the plugin gets called and the plugin checks the file. On Fri, Jul 19, 2013 at 3:52 PM, Paul Libbrecht <paul(a)hoplahup.net> wrote: > > On 19 juil. 2013, at 15:38, Paul Libbrecht wrote: > >>> 2. The image can not be properly decoded and hence not resized. One (of >>> many) reasons for that: the image uses CMYK colour scheme (from print) >>> instead of the RGB expected by the image plugin. You can check that in > any >>> decent graphics editing program. >> >> >> Also not the case: the result of identify: >> 200x256 200x256+0+0 8-bit sRGB 50.8KB 0.000u 0:00.000 >> >> The image plugin would be doing this? >> Indeed it is configured: >> com.xpn.xwiki.plugin.image.ImagePlugin,\ >> >> It seems to be living inside xwiki-platform-legacy-oldcore-5.1.jar but > maybe that plugin is disabled? > > Not disabled: in velocity xwiki.image gives me: > com.xpn.xwiki.plugin.image.ImagePluginAPI@2fc98f55 > Can it be the image plugin is not called?

The easiest first step would be to increase the logging level for the image plugin. Unfortunately there seem to be a lot of try { ... } catch (...) { // Ignore. } constructs in the code, so you will get only something logged if you are lucky. If you're unlucky you could add more logging and build the plugin jar yourself. That way you can also add something like LOG.info("starting downloadAttachment"); to see if the method gets called at all.

On Fri, Jul 19, 2013 at 4:10 PM, Paul Libbrecht <paul(a)hoplahup.net> wrote: > So that interception would fail? > > How can I inspect that? > > paul > > > On 19 juil. 2013, at 16:06, Edo Beutler wrote: > >> Yes, that's the plugin. If you found it configured in xwiki.cfg and got > it >> in velosity it's active. I suppose it's in oldcore because it's a plugin >> and not a component and, afaik, it's not (yet) possible to do it in a >> component since it intercepts the download action. >> Every time you access a file using the download action >> (/xwiki/bin/download/...) the downloadAttachment method in the plugin > gets >> called and the plugin checks the file. >> >> >> On Fri, Jul 19, 2013 at 3:52 PM, Paul Libbrecht <paul(a)hoplahup.net> > wrote: >> >>> >>> On 19 juil. 2013, at 15:38, Paul Libbrecht wrote: >>> >>>>> 2. The image can not be properly decoded and hence not resized. One > (of >>>>> many) reasons for that: the image uses CMYK colour scheme (from print) >>>>> instead of the RGB expected by the image plugin. You can check that in >>> any >>>>> decent graphics editing program. >>>> >>>> >>>> Also not the case: the result of identify: >>>> 200x256 200x256+0+0 8-bit sRGB 50.8KB 0.000u 0:00.000 >>>> >>>> The image plugin would be doing this? >>>> Indeed it is configured: >>>> com.xpn.xwiki.plugin.image.ImagePlugin,\ >>>> >>>> It seems to be living inside xwiki-platform-legacy-oldcore-5.1.jar but >>> maybe that plugin is disabled? >>> >>> Not disabled: in velocity xwiki.image gives me: >>> com.xpn.xwiki.plugin.image.ImagePluginAPI@2fc98f55 >>> Can it be the image plugin is not called?

I've debugged the thing, using remote debugging, and it seems that it is properly processing through the image plugin but the latter is supposed to write into an attachment that is a clone of the image attachment and that seems to lead to the same path as the file. For some reasons it is not written to (IOUtils.closeQuietly does not flush?). And, because it's a clone, the same file is delivered as download. I seem to suspect the file-ssytem-attachments. Is xwiki.org not using the filesystem attachment? This works well, with file-system-attachment, in xwiki 3.5 (e.g. in gpsnetwork.org). thanks Paul On 19 juil. 2013, at 16:49, Vincent Massol wrote: