Re: [OpenJDK 2D-Dev] [9] RFR JDK-8025439: [TEST BUG] [macosx] PrintServiceLookup.lookupPrintServices doesn't work properly since jdk8b105

[Prasanta Sadhukhan]

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