[OpenJDK 2D-Dev] [9] RFR JDK-8025439: [TEST BUG] [macosx] PrintServiceLookup.lookupPrintServices doesn't work properly since jdk8b105
Prasanta Sadhukhan
prasanta.sadhukhan at oracle.com
Wed Nov 30 10:19:59 UTC 2016
Please find the modifed the webrev as per review comments
http://cr.openjdk.java.net/~psadhukhan/8025439/webrev.02/
Regards
Prasanta
On 11/30/2016 1:04 AM, Phil Race wrote:
> Leaving aside platform printer naming conventions and the like, it
> seems that
> PrintService.getName() returns "Rich Aficio" but then when
> the test does new PrinterName("Rich Aficio") and try to locate a printer
> with that name it says "no such printer" ?
>
> Yes, that is possible since PrinterName is allowed to be different
> than PrintService.getName() :-
> https://docs.oracle.com/javase/8/docs/api/javax/print/PrintService.html#getName--
> so this strictly a test bug.
>
> So it seems to me that what the test should be doing is
> querying the PrinterName attribute on the service and then
> using the string obtained from there to initialise the PrinterName
> used in the lookup.
>
> -phil.
>
>
> On 11/16/2016 12:53 AM, Ajit Ghaisas wrote:
>>
>> The test should not worry about linux/solaris future change. If there
>> is any change, we will get to know with test failure.
>>
>> Change is OK.
>>
>> Please update the year in banner & add this bug id in jtreg @bug tag
>> before pushing.
>>
>> Regards,
>>
>> Ajit
>>
>> *From:*Prasanta Sadhukhan
>> *Sent:* Wednesday, November 16, 2016 11:55 AM
>> *To:* Ajit Ghaisas; Philip Race; 2d-dev
>> *Subject:* Re: [OpenJDK 2D-Dev] [9] RFR JDK-8025439: [TEST BUG]
>> [macosx] PrintServiceLookup.lookupPrintServices doesn't work properly
>> since jdk8b105
>>
>> It can be done that way and it will solve this specific problem but I
>> did !Windows because even though linux/solaris GUI does not support
>> spaces as of now, GUI is easy to change and can accomodate spaces in
>> near future
>> but CUPS library will not accomodate the spaces so it might fail in
>> linux/solaris then.
>> Anyways, I am ok with making this mac specific
>> http://cr.openjdk.java.net/~psadhukhan/8025439/webrev.01/
>> <http://cr.openjdk.java.net/%7Epsadhukhan/8025439/webrev.01/>
>>
>> Regards
>> Prasanta
>>
>> On 11/15/2016 4:11 PM, Ajit Ghaisas wrote:
>>
>> If we know that exceptional behavior (service name containing
>> spaces) is only limited to Mac, then the check in test should be
>> only Mac specific and not (!windows).
>>
>> Regards,
>>
>> Ajit
>>
>> *From:*Prasanta Sadhukhan
>> *Sent:* Tuesday, November 15, 2016 12:32 PM
>> *To:* Phil Race; 2d-dev
>> *Subject:* Re: [OpenJDK 2D-Dev] [9] RFR JDK-8025439: [TEST BUG]
>> [macosx] PrintServiceLookup.lookupPrintServices doesn't work
>> properly since jdk8b105
>>
>> On 11/15/2016 4:39 AM, Phil Race wrote:
>>
>> This evaluation needs to go in the bug report, not (just) here.
>>
>> mac. shows spaces in the name in its GUI but "_" in the names
>> reported by lpstat
>> so it may be that the replacement is right but I'd still like
>> to dig a bit here.
>> Can you point to the code that does the " "->"_" replacement.
>> I can't see it
>> in CUPSPrinter.getAllPrinters().
>>
>> As per
>> http://hg.openjdk.java.net/jdk9/client/jdk/file/449518f6a468/src/java.desktop/unix/classes/sun/print/CUPSPrinter.java#l425
>> it gets the response from CUPS server and the printer names
>> obtained from server is stored in jdk. In my case, even though I
>> specified "Ricoh Aficio..." in GUI
>> the "nameStr" obtained from CUPS responseMap is "Ricoh_Aficio..."
>>
>>
>> And you saying that
>>
>> PrintServiceLookup.lookupPrintServices(null, null)
>>
>> will return an array with a "null" element ?
>>
>> No, sorry to "eat-up words". What I meant to say,
>> lookupPrintServices(null, attributes) returns array with 0
>> elements as checkPrinterName() return false [as user is asking to
>> find "Ricoh Aficio" and not "Ricoh_Aficio"]
>> resulting in getServiceByName() returning null
>> which in turn causes lookByName() in the testcase to return null
>>
>> Regards
>>
>> Prasanta
>>
>> That would be a bug.
>>
>> -phil.
>>
>> On 11/14/2016 02:18 AM, Prasanta Sadhukhan wrote:
>>
>> Hi All,
>>
>> Please review a small bugfix whereby it is seen that if
>> we specify printer with space in its name, then
>> javax/print/PrintServiceLookup/GetPrintServices.java
>> fails citing NPE.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8025439
>> webrev:
>> http://cr.openjdk.java.net/~psadhukhan/8025439/webrev.00/
>> <http://cr.openjdk.java.net/%7Epsadhukhan/8025439/webrev.00/>
>>
>> The NPE happens because
>> http://hg.openjdk.java.net/jdk9/client/jdk/file/b1543c5eb8af/src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java#l460
>> calls checkPrinterName() which checks it name contains
>> letter or digit
>> http://hg.openjdk.java.net/jdk9/client/jdk/file/b1543c5eb8af/src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java#l433
>> and returns null if has spaces
>> so lookupPrintServices() gets null
>>
>> Now, if we remove this <space> check then also, it will
>> not work as
>> In system running with CUPS, refreshServices calls
>> CUPSPrinter#getAllPrinters() which returns a set of
>> printers. It seems it replaces " " with "_" when
>> populating the list
>> for e.g Ricoh Aficio MP 5002 printer name is sent as
>> Ricoh_Aficio_MP_5002 and stored in the list so we cannot
>> have <space> in printer name.
>>
>> In Mac, it takes <sp> in printer name when we add
>> printers but in linux, solaris it does not allow spaces
>> in printer name during addition
>> so in the proposed fix, a check for <sp> is added to make
>> it automatic pass for non-windows (CUPS) system.
>>
>> Regards
>> Prasanta
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20161130/354ba409/attachment.html>
More information about the 2d-dev
mailing list