From mark at klomp.org Mon Nov 3 08:01:51 2014 From: mark at klomp.org (Mark Wielaard) Date: Mon, 03 Nov 2014 09:01:51 +0100 Subject: bugzilla emails bouncing? In-Reply-To: <1414710297.18323.43.camel@bordewijk.wildebeest.org> References: <1414710297.18323.43.camel@bordewijk.wildebeest.org> Message-ID: <1415001711.18323.60.camel@bordewijk.wildebeest.org> On Fri, 2014-10-31 at 00:04 +0100, Mark Wielaard wrote: > Anybody know why the bugzilla emails have started to bounce when sent to > the distro-pkg-dev list? They used to go through fine and not having > them sent to the list will make it harder for people to track issues. Ping. Could someone take a look. This has been going on for the whole weekend. The error message given by host ucsinet40.oracle.com is: 550 Denied by policy. Which isn't very helpful. Thanks, Mark From jvanek at redhat.com Mon Nov 3 10:51:50 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 03 Nov 2014 11:51:50 +0100 Subject: bugzilla emails bouncing? In-Reply-To: <1415001711.18323.60.camel@bordewijk.wildebeest.org> References: <1414710297.18323.43.camel@bordewijk.wildebeest.org> <1415001711.18323.60.camel@bordewijk.wildebeest.org> Message-ID: <54575E46.3060602@redhat.com> On 11/03/2014 09:01 AM, Mark Wielaard wrote: > On Fri, 2014-10-31 at 00:04 +0100, Mark Wielaard wrote: >> Anybody know why the bugzilla emails have started to bounce when sent to >> the distro-pkg-dev list? They used to go through fine and not having >> them sent to the list will make it harder for people to track issues. > > Ping. Could someone take a look. This has been going on for the whole > weekend. The error message given by host ucsinet40.oracle.com is: 550 > Denied by policy. Which isn't very helpful. > > Thanks, > Hmm. I got the same, but only for my own hg push to ITW:( J. From gnu.andrew at redhat.com Mon Nov 3 14:08:37 2014 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 3 Nov 2014 09:08:37 -0500 (EST) Subject: bugzilla emails bouncing? In-Reply-To: <1415001711.18323.60.camel@bordewijk.wildebeest.org> References: <1414710297.18323.43.camel@bordewijk.wildebeest.org> <1415001711.18323.60.camel@bordewijk.wildebeest.org> Message-ID: <475478777.4176949.1415023717959.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On Fri, 2014-10-31 at 00:04 +0100, Mark Wielaard wrote: > > Anybody know why the bugzilla emails have started to bounce when sent to > > the distro-pkg-dev list? They used to go through fine and not having > > them sent to the list will make it harder for people to track issues. > > Ping. Could someone take a look. This has been going on for the whole > weekend. The error message given by host ucsinet40.oracle.com is: 550 > Denied by policy. Which isn't very helpful. > > Thanks, > > Mark > I'm seeing the same. The admin password I have for the list no longer seems to work either. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: 248BDC07 (https://keys.indymedia.org/) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From jvanek at redhat.com Mon Nov 3 15:48:56 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 03 Nov 2014 16:48:56 +0100 Subject: [rfc][icedtea-web] get rid of custom@@ markup for documentation In-Reply-To: <544BBEE3.2090008@redhat.com> References: <543D42C1.6050705@redhat.com> <543D7356.5010304@gmx.de> <543E28EA.9050708@redhat.com> <543ED73F.3090806@gmx.de> <543FEEBA.7010408@redhat.com> <54453612.5000206@redhat.com> <5449245F.2070208@redhat.com> <544BBEE3.2090008@redhat.com> Message-ID: <5457A3E8.1060600@redhat.com> On 10/25/2014 05:16 PM, Andrew Azores wrote: > On 10/23/2014 11:53 AM, Jiri Vanek wrote: >> On 10/20/2014 06:19 PM, Andrew Azores wrote: >>> On 10/16/2014 12:13 PM, Jiri Vanek wrote: >>>> ... >>>>>>> >>>>>>> Yet another approach would be to accept only HTML formatted code >>>>>>> in the >>>>>>> property files and have it >>>>>>> converted to man or what ever document format when generated. It >>>>>>> should be >>>>>>> pretty easy to strip HTML >>>>>>> tags from strings in Java. ;-) >>>>>> >>>>>> uh... this is exactly what the aptch was doing...???... >>>>> >>>>> No, it does not. This would require a HTML validator, or at least >>>>> calls for one. If we set out to >>>>> accept only HTML in message property files then we should also have a >>>>> decent HTML validator test. >>>>> The provided test does not test HTML but some very specific character >>>>> sequences which /tend/ to be, >>>>> almost by accident, a subset of valid HTML. And although I am not a >>>>> strong proponent of software >>>>> tests (for various reasons), I can see a great benefit to a proper and >>>>> complete test in this case >>>>> because we have no other way to enforce proper formatting of property >>>>> values in message property >>>>> files which in turn makes sure that the document generators will not >>>>> break. So again, your approach >>>>> to the problem is not holistic. >>>> >>>> >>>> I really understand your point, but I really do not wont to fall into >>>> this kind of complexity. Not even from far remote. >>>> >>>> The must for anything what will be done is, that proper man is generated >>>> from it. Compared to html, man supports *really* small number of >>>> formatting "elements". So our "html" can support just this minimal >>>> intersection of elements. So wy not only B? >>>> >>>> All the markup is out of properties, the only one which remained is >>>> bolding. There is no reason to add some other features unless it is >>>> needed. >>>> >>>> Another option I have in mind is to have here {0} for opening and {1} >>>> for closing. But it seems even little bit more stupid. >>>> >>>> Rather then support even anything close to html, I would rather get rid >>>> of any formatting at all. But it seems to me quite unhappy to dont have >>>> possibility to do small higlighting. >>>> >>>> >>>> On contrary, I do not understand why you are standing so strongly >>>> against:( >>>> >>> >>> I don't see the need for anything beyond bolding either, really. Using >>> a proper HTML validator would >>> make sense to me if we were to be accepting some fairly sized subset >>> of HTML elements, but if it's >>> just a bolding tag, that's extreme overkill. >>> >>> I think saying that this is "almost by accident" a subset of HTML is >>> completely fair and actually >>> entirely the point. It's not meant to be actual HTML, it's meant to be >>> a minimal and domain specific >>> markup language. Just for familiarity's sake, it's made to look like >>> something else well-known. This >>> could also be done with Markdown style **bold asterisk tag things** or >>> Asciidoc style *single >>> asterisk bold tags*, but that's probably a lot more ambiguous to parse >>> than HTML-style bolding. >>> >> Thank you for suggestions, >> >> >> upodated patch attached. I actually do not care to much if it is >> included, but get rid of @BOLD_..@ is probably beter way . >> >> >> If this will be approved of denied, I consider work on generator as >> finished. (excepot soem bug is found) . >> >> >> J. > > Hi, > > Looks like a reasonable improvement to me. One nit before push: typos/misspellings in > Messages.properties. You have "RepalcingTextFormatter" instead of " ReplacingTextFormatter" ;) > > Thanks, fixed & pushed :( J. From jvanek at redhat.com Mon Nov 3 16:15:40 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 03 Nov 2014 17:15:40 +0100 Subject: [rfc][icedtea-web] ResourceTracker Download Refactor In-Reply-To: <1047396171.780529.1414615524414.JavaMail.zimbra@redhat.com> References: <1427890798.21679342.1408117850747.JavaMail.zimbra@redhat.com> <544A4B2F.9090303@redhat.com> <1047396171.780529.1414615524414.JavaMail.zimbra@redhat.com> Message-ID: <5457AA2C.3050407@redhat.com> On 10/29/2014 09:45 PM, Jie Kang wrote: > > > ----- Original Message ----- >> On 08/15/2014 05:50 PM, Jie Kang wrote: >>> Hello, >>> >>> >>> The attached patch makes what looks like a huge refactor to >>> ResourceTracker's function: 'downloadResource'. >>> >>> Previously downloadResource was a single function over 100 lines long. >>> Inspired by the book 'Clean Code' by Robert C. Martin, I believe this to >>> be quite bad. The patch simply extracts portions of the function into >>> other functions with descriptive names. >>> >>> As 'downloadResource' is extremely important to ITW's function, I want to >>> stress that there is NO new code and that when refactoring I made sure >>> that there was NO reordering of code. The execution is the exact same >>> prior to this patch. >>> >>> The reason for this patch is that the codebase for ITW is in some places >>> quite old (code from 2003?) and unnecessarily complicated. This is a small >>> part of an attempt to clean the code up and increase extensibility for >>> future enhancements (ie. supporting more of JNLP's spec). >>> >>> >>> PS. I have manual tested ITW with the patch applied and have not seen any >>> regressions. >>> >>> >>> >>> Thanks, >>> >> Please adapt to a head and test again. I think there is no longer any need to >> delay this good patch. >> >> Sory for dealying! >> >> J. >> > > Hello, > > > The attached patch is a refactor to ResourceTrackers download function. > > Also attached is a copy of the results from one run of reproducers with the patch applied. Since this affects a critical part of ITW, I have tried to be extremely careful in order to make sure there are no regressions. I have done a large amount of testing prior to posting this patch to the list. > > The main purpose of this patch is to make it easier to understand what the download function is doing, in order to make further improvements on it in the future. > > > Thoughts? If you could apply the patch and read over the new code, and see if you can understand what is going on, it would be greatly appreciated. Yes, the code is much more readable! > > > > PS Notes: > > There is a function added to CacheUtil: public static File getCacheFile(URL source) > > This calls the previously existing function: getCacheFile(URL source, Version version) with version==null. This might seem dangerous but, if you read through the code-lines for getCacheFile, you will notice that 'version' is never used. 'version' is passed to two functions, 'isCacheable' and 'makeNewCacheFile', both of which do not use version at all. > > I am not sure what the intentions of the previous developers were with the Version object so I have chosen to keep the code intact for now. > > > > Hi! The patch looks good. Few nits: You are removing some comments or renaming variables (like e to ex) whcih reallys eems to be unnecessary. I would let them as they are. But depends on you. I'm not sure what to think about versionless method overloading:( How rest of ITW is doing it? If the (string,null) call is more wide spread, then I'm for it, and also to replace other calls like that. Last nit you will not like - unit XOR reproducers for your new methods is really wonted. I think that reproducer - moreover being written as unittestm and only using prepared resources, would be completely enough. Also you did few: - catch (Exception ex) { + } catch (IOException e) { I would strongly discourage you from doing so... Not only IO exception can happen here.... And we do not wont to die... Thank you for doing this extremely necessary stuff! J. From aazores at redhat.com Mon Nov 3 18:41:18 2014 From: aazores at redhat.com (Andrew Azores) Date: Mon, 03 Nov 2014 13:41:18 -0500 Subject: [rfc][icedtea-web] Preparing PolicyEditor for future full policyfile featureset Message-ID: <5457CC4E.5020701@redhat.com> Hi, PolicyEditor is currently not a viable total replacement for the existing JDK policytool for a few reasons. 1) Only supports CodeBase, not SignedBy and Principal 2) No KeyStore entry support 3) Parser is not a real parser 4) CustomPolicyViewer is a little underpowered Once these issues are all resolved, then I think it would be fair for us to push using PolicyEditor alone, and remove the button from itweb-settings which launches policytool as the "Advanced editor". This patch is aimed at working on #1 and #2. It adds a few more simple data structures (KeystoreInfo and PolicyIdentifier) so that, once a proper parser exists, a full-featured policy file can be fully modelled with PolicyEditor's structures. KeystoreInfo is currently completely unused, and PolicyIdentifier is used only for its codebase attribute, so there are no behavioural changes after this patch is applied. All unit tests should come up with the same results (and the only unit test changes made are refactoring for builder pattern) and manual testing should work exactly the same as well. Since PolicyEntries now have many more attributes, its constructor has been made private and PolicyEntry is now constructed with a Builder. Changing each of the existing unit test cases dealing with PolicyEntry to use the builder introduced some unfortunate noise to this patch. Missing with this changeset are any changes to PolicyFileModel so that these new attributes might be written to file if (somehow) present. Since there is no UI to modify these attributes and no parser to read them from files, for now it will have to be done simply with mock data and performed only in unit tests. I'd like to add this as a separate changeset simply because of the limited and highly variable amounts of time I have to commit to this at the moment. Thanks, -- Andrew Azores -------------- next part -------------- A non-text attachment was scrubbed... Name: policyeditor-identifiers.patch Type: text/x-patch Size: 36253 bytes Desc: not available URL: From jkang at redhat.com Mon Nov 3 21:17:18 2014 From: jkang at redhat.com (Jie Kang) Date: Mon, 3 Nov 2014 16:17:18 -0500 (EST) Subject: [rfc][icedtea-web] Fix to PluginMessage dates for PR2063 In-Reply-To: <2105568611.3077724.1415049371067.JavaMail.zimbra@redhat.com> Message-ID: <1999948458.3078034.1415049438993.JavaMail.zimbra@redhat.com> Hello, The attached patch is a small fix to PluginMessage addressing PR2063. http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2063 Thoughts? Regards, -- Jie Kang -------------- next part -------------- A non-text attachment was scrubbed... Name: itw-pr2063-plugin-message-date.patch Type: text/x-patch Size: 976 bytes Desc: not available URL: From jvanek at redhat.com Tue Nov 4 13:09:42 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 04 Nov 2014 14:09:42 +0100 Subject: [rfc][icedtea-web] Fix to PluginMessage dates for PR2063 In-Reply-To: <1999948458.3078034.1415049438993.JavaMail.zimbra@redhat.com> References: <1999948458.3078034.1415049438993.JavaMail.zimbra@redhat.com> Message-ID: <5458D016.1020206@redhat.com> On 11/03/2014 10:17 PM, Jie Kang wrote: I really did no mess? I really would expect console to show invlaid dates header now... (aka = ar eyou sure??) Also I would keep the comments ffom my original pastebin here. If you disagree with the comments, then maybe remove the duplicated date at all? Ty! J. > Hello, > > > The attached patch is a small fix to PluginMessage addressing PR2063. > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2063 > > > Thoughts? > > > Regards, > From jvanek at redhat.com Tue Nov 4 13:13:34 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 04 Nov 2014 14:13:34 +0100 Subject: [rfc][icedtea-web][itweb-settings] itweb-settings use Option Parser In-Reply-To: <708228352.22183782.1413915984272.JavaMail.zimbra@redhat.com> References: <2136433079.7489666.1411075684213.JavaMail.zimbra@redhat.com> <54255285.6080406@redhat.com> <1570273198.15632389.1412630652794.JavaMail.zimbra@redhat.com> <54341EBA.4080707@redhat.com> <269960645.16172064.1412718558976.JavaMail.zimbra@redhat.com> <54350512.6010606@redhat.com> <372997163.21557883.1413816212472.JavaMail.zimbra@redhat.com> <54467183.1000500@redhat.com> <708228352.22183782.1413915984272.JavaMail.zimbra@redhat.com> Message-ID: <5458D0FE.3060307@redhat.com> Hi! This looks ok. With some fear.. go on and push :) J. On 10/21/2014 08:26 PM, Lukasz Dracz wrote: > Hello, > >> From: "Jiri Vanek" >> To: "Lukasz Dracz" >> Cc: "IcedTea" , "Jie Kang" >> Sent: Tuesday, October 21, 2014 10:45:23 AM >> Subject: Re: [rfc][icedtea-web][itweb-settings] itweb-settings use Option Parser >> >> On 10/20/2014 04:43 PM, Lukasz Dracz wrote: >>> Hello, >>> >>> I believe I managed to simplify this patch, thanks to jkang's helpful >>> suggestions. >>> >>>> Please split the patch to three parts >>>> - first - add support for the list ParsedOption >>>> - second - add support for the equls chars >>>> - third - integrate it into itweb settings >>>> - fourth - policy editor. >>>> >> >> After chat on IRC: >> - please return 0-n hyphens. It is really god feature > > Okay added back the method removeLeadingHyphens, to support this feature > >> - please return the EVEN_NUMBER_OR_WITHEQUALCHAR on long run. >> - that means - it is ok to remove it now, but for itweb settings I think >> it will be necessary. Or to drop the set name=val syntaxe, which I will >> be missing. > > I decided to keep it in this patch. Also renamed EVEN_NUMBER_OR_WITHEQUALCHAR to EVEN_NUMBER_SUPPORTS_EQUALS_CHAR, I think this might be a better name. > >> - the rmeoval of QUALS_CHAR can be dropepd, as it is default behaviour of >> parser now (to consider arg val same as arg=val) >> Except that the quality of code improved > > Removed it. > >> >> More in IRC log :) >> >> Thank you both! > > Thank you, > Lukasz Dracz > >> J. >> >>> >>> This patch adds support for the ParsedOption list, and also the parser has >>> been changed to be simpler. >>> Notable changes are that options require a hyphen in front of them, ex. >>> -headless OKAY headless NOT OKAY any more. >>> The placement of main arguments is not as flexible as before, it cannot >>> come after an option with many arguments, >>> but after option with no args or option with just one arg is okay. >>> Unit tests changed to reflect that. >>> >>> Also from OptionsDefinitions removed EQUALSCHAR and >>> EVEN_NUMBER_Or_WITHEQUALSCHAR enums. The option=arg functionality is still >>> present but does not utilize or plan to use EQUALSCHAR. >>> >>> Also edited the NEWS and changed back the launcher splashscreen to what it >>> was before. >>> >>> Thoughts on he changes ? >>> >>> Thank you, >>> Lukasz Dracz >>> >>> ----- Original Message ----- >>>> From: "Jiri Vanek" >>>> To: "Lukasz Dracz" >>>> Cc: "IcedTea" >>>> Sent: Wednesday, October 8, 2014 5:34:10 AM >>>> Subject: Re: [rfc][icedtea-web][itweb-settings] itweb-settings use Option >>>> Parser >>>> >>>> On 10/07/2014 11:49 PM, Lukasz Dracz wrote: >>>>> Hello, >>>>> >>>>>>> I implemented your ParsedOption idea, which I think is really good. I >>>>>>> also >>>>>>> changed it back to allowing Multiple Options again instead of limited >>>>>>> options so I didn't implement ArgumentOccurence. Should we go with >>>>>>> Multiple Options being allowed or limited options ? I think with the >>>>>>> List >>>>>>> of ParsedOption approach, multiple option is implemented better than >>>>>>> before. Also the main help message is displayed only if help is the >>>>>>> first >>>>>>> command or after headless as the 2nd command, any help after that will >>>>>>> count display help for the command before it, which means you could >>>>>>> display multiple helps ex. ./itweb-settings get help set help reset >>>>>>> help >>>>>>> will show the command help for get set reset. >>>>>> >>>>>> "main help message is displayed only if help is the first command or >>>>>> after >>>>>> headless as t" >>>>>> >>>>>> Cant it be done better? >>>>> >>>>> Yes, >>>>> What if we make it that if only help is put in then it displays the main >>>>> help but if help is put with any other combination of commands (get, >>>>> reset, check, etc.) it will display the help for those commands (also >>>>> disregarding what the command wants) so ex. get deployment.security.level >>>>> set help reset, will just get help for get, set and reset ? (and won't >>>>> actually display deploymentsecurity.level) >>>>> >>>> >>>> I would say go with simplest(+ simpelst code) possible solution >>>> >>>>>> well - it does not meter when headless is decalred - you only ask >>>>>> "optionPArser.hasOption(headles): >>>>>> and set JnlpRuntime accordingly. >>>>>> >>>>>> the help should decide whether it is global one, or command one more >>>>>> cleverly. >>>>>>> >>>>>>> Also now the static splitListOnEquals/Symbols is no longer used/needed >>>>>>> other than the unit tests, Should I remove them ? (I'm of the opinion >>>>>>> yes). >>>>>> >>>>>> Move it to test file then. >>>>> >>>>> Going to just delete it since I meant the unit tests that use it were >>>>> ones >>>>> that were specifically testing those two methods. I was unclear in my >>>>> phrasing sorry :) >>>>> >>>> oook. >>>> >>>>>>> >>>>>>> Thank you, >>>>>>> Lukasz Dracz >>>>>>> >>>>>>> >>>>>>> itweb-settingsOptionParser-10.patch >>>>>>> >>>>>>> >>>>>>> diff -r 8071a44fe6de netx/net/sourceforge/jnlp/OptionsDefinitions.java >>>>>>> --- a/netx/net/sourceforge/jnlp/OptionsDefinitions.java Fri Oct 03 >>>>>>> 14:20:40 >>>>>>> 2014 -0400 >>>>>>> +++ b/netx/net/sourceforge/jnlp/OptionsDefinitions.java Mon Oct 06 >>>>>>> 17:16:18 >>>>>>> 2014 -0400 >>>>>>> @@ -73,14 +73,13 @@ >>>>>>> TRUSTNONE("-Xtrustnone","BOTrustnone"), >>>>>>> JNLP("-jnlp","BOJnlp", NumberOfArguments.ONE), >>>>>>> //itweb settings >>>>>>> - NODASHHELP("help", "IBOHelp"), >>>>>>> - LIST("list", "IBOList"), >>>>>>> - GET("get", "name", "IBOGet"), >>>>>>> - INFO("info", "name", "IBOInfo"), >>>>>>> - SET("set", "name value", "IBOSet"), >>>>>>> - RESETALL("reset", "all", "IBOResetAll"), >>>>>>> - RESET("reset", "name", "IBOReset"), >>>>>>> - CHECK("check", "name", "IBOCheck"), >>>>>>> + LIST("-list", "IBOList"), >>>>>>> + GET("-get", "name", "IBOGet", NumberOfArguments.ONE_OR_MORE), >>>>>>> + INFO("-info", "name", "IBOInfo", >>>>>>> NumberOfArguments.ONE_OR_MORE), >>>>>>> + SET("-set", "name value", "IBOSet", >>>>>>> NumberOfArguments.EVEN_NUMBER_OR_WITHEQUALCHAR), >>>>>>> + RESETALL("-reset", "all", "IBOResetAll"), >>>>>>> + RESET("-reset", "name", "IBOReset", >>>>>>> NumberOfArguments.ONE_OR_MORE), >>>>>>> + CHECK("-check", "name", "IBOCheck"), >>>>>>> //policyeditor >>>>>>> //-help >>>>>>> FILE("-file", "policy_file", "PBOFile"), >>>>>>> @@ -123,6 +122,8 @@ >>>>>>> return numberOfArguments == >>>>>>> NumberOfArguments.EQUALS_CHAR; >>>>>>> } >>>>>>> >>>>>>> + public boolean hasEvenNumberOrWithEqualsChar() { return >>>>>>> numberOfArguments == NumberOfArguments.EVEN_NUMBER_OR_WITHEQUALCHAR; } >>>>>>> + >>>>>>> public boolean hasOneOrMoreArguments() { >>>>>>> return numberOfArguments == >>>>>>> NumberOfArguments.ONE_OR_MORE; >>>>>>> } >>>>>>> @@ -140,7 +141,8 @@ >>>>>>> NONE("No argument expected"), >>>>>>> ONE("Exactly one argument expected"), >>>>>>> ONE_OR_MORE("Expected one or more arguments"), >>>>>>> - EQUALS_CHAR("Expected -param=value vaue declaration"); >>>>>>> + EVEN_NUMBER_OR_WITHEQUALCHAR("Expected one or more arguments >>>>>>> with >>>>>>> param=value as valid argument"), >>>>>> >>>>>> this is micro nit, but wgy it was inserted, and not jsut added? >>>>> >>>>> I have no idea, I probably accidently added a space somewhere in there, >>>>> now >>>>> its added :) >>>>> >>>>>> >>>>>> Also - this hunk no longer applies, as I pushed the localization for >>>>>> this >>>>>> class. >>>>>>> + EQUALS_CHAR("Expected -param=value value declaration"); >>>>>>> >>>>>>> String messageKey; >>>>>>> >>>>>>> @@ -155,13 +157,14 @@ >>>>>>> >>>>>>> public static List getItwsettingsCommands() { >>>>>>> return Arrays.asList(new OPTIONS[]{ >>>>>>> - OPTIONS.NODASHHELP, >>>>>>> + OPTIONS.HELP, >>>>>>> OPTIONS.LIST, >>>>>>> OPTIONS.GET, >>>>>>> OPTIONS.INFO, >>>>>>> OPTIONS.SET, >>>>>>> + OPTIONS.RESET, >>>>>>> OPTIONS.RESETALL, >>>>>>> - OPTIONS.RESET, >>>>>>> + OPTIONS.HEADLESS, >>>>>>> OPTIONS.CHECK >>>>>>> }); >>>>>> >>>>>> why the change of order?? >>>>> >>>>> RESET and RESETALL both check for -reset when parsing and the first one >>>>> in >>>>> the list is the option that gets recognized, meaning either I switch the >>>>> order or I change the option I am checking value with, to be RESETALL. So >>>>> only one is really parsed for which is RESET, but I left RESETALL since >>>>> for the help message I think it is a nice entry to show that -reset all >>>>> is >>>>> a special property. >>>>> >>>> >>>> oh interesting.... ok then. >>>>>>> } >>>>>>> @@ -210,7 +213,7 @@ >>>>>>> l.addAll(getJavaWsRuntimeOptions()); >>>>>>> l.addAll(getJavaWsControlOptions()); >>>>>>> //trustall is not returned by getJavaWsRuntimeOptions >>>>>>> - //or getJavaWsControlOptions, as it is not desitred in >>>>>>> documentation >>>>>>> + //or getJavaWsControlOptions, as it is not desired in >>>>>>> documentation >>>>>>> l.add(OPTIONS.TRUSTALL); >>>>>>> return l; >>>>>>> } >>>>>> >>>>>> Any way, please push this part of this patch >>>>>> = changes to netx/net/sourceforge/jnlp/OptionsDefinitions.java >>>>>> + according properties IBOCheck, new one for >>>>>> EVEN_NUMBER_OR_WITHEQUALCHAR. and BOHelp >>>>>> >>>>>> About the BOHelp, I'm for small rewording. What about >>>>>> +BOHelp = Prints out information about supported command and basic >>>>>> usage. >>>>>> >>>>>> ? >>>>> >>>>> I like it :) changed it. >>>>> >>>>>> >>>>>> Do as your wish, and please push this specified part of your patch. >>>>> >>>>> I attached the patch you wanted me to push, since there is one small >>>>> change >>>>> in that since nodashhelp is removed I had to change CommandLine.java to >>>>> check for OPTIONS.HELP instead of OPTIONS.NODASHHELP on one line. >>>>> Here is the changelog I plan to add to it >>>>> >>>>> 2014-10-07 Lukasz Dracz >>>>> >>>>> Standardize all options to use hyphens >>>>> * netx/net/sourceforge/jnlp/OptionsDefinitions.java: >>>>> itweb-settings options changed to have hyphens in front, >>>>> added new enum to NumberOfArguments >>>>> (getItwsettingsCommands): added headless, changed nodashhelp to help >>>>> * netx/net/sourceforge/jnlp/controlpanel/CommandLine.java >>>>> * netx/net/sourceforge/jnlp/resources/Messages.properties: >>>>> (BOHelp, IBOCheck): modified (NOAevennumberorequalschar): added >>>>> >>>>>> >>>> >>>> looks ok to me. One minor - tehr eis one method strongly violating >>>> formating >>>> rules, please format >>>> :) (if you dnt find it, its on the end of the email [1] >>>> >>>> after the formating of this method, ok to push. >>>> >>>>>> Will try at least something from the rest, but you are doing so much >>>>>> things >>>>>> in so much complicated >>>>>> ways to achive so simple results:(( Maybe you can arrange face2face >>>>>> meeting >>>>>> with Jie and he mayhelp >>>>>> you to establish basic structures more simple? >>>>>> >>>>>> But at least we agreed on "what should be done" >>>>>> ... >>>>> >>>>> This reply is mainly to make sure that the changes to what you wanted to >>>>> be >>>>> pushed are approved. >>>>> I agree my code has become messy and unnecessarily complicated, I will >>>>> look >>>>> into simplifying it >>>>> as much as I can. >>>>> >>>>>> + for (String arg : args) { >>>>>> + if (args.indexOf(arg) % 2 == 0) { >>>>>> >>>>>> Again this terrible modulo? >>>>>> >>>>>> >>>>>> Why you dont just get list of the parameters, then iterates +2 and >>>>>> get(i) >>>>>> and >>>>>> get(i+1) ? >>>>>> You are terribly leaking the parsers encapsulated functionalities. Also, >>>>>> why >>>>>> >>>>>> + String key = ""; >>>>>> + String value; >>>>>> >>>>>> is declared out of the loop? >>>>>> >>>>>> >>>>>> ugh, isNextOption? isCurrentOption? whyyyyyy? ouch whyyyy:( >>>>>> >>>>>> you you really should get only list<[key,list] /list of objcets, >>>>>> where is key + its >>>>>> arguments in another list. This strucutre IS the result of parsing, and >>>>>> parsing is exactly what you >>>>>> parser is doing. >>>>>> >>>>>> and then iterate through it, no more complications around. >>>>>> >>>>>> (ps - the usage of isNextOption have its reasons in other palces of >>>>>> your >>>>>> impls) >>>>>> >>>>>> >>>>>> + if (args.contains("all")) { >>>>>> resetAll = true; >>>>>> + if (args.size() > 1) { >>>>>> + for (String arg : args) { >>>>>> + if (!arg.equals("all")) { >>>>>> + >>>>>> OutputController.getLogger().log(OutputController.Level.MESSAGE_ALL, >>>>>> R("CLUnknownCommand", arg)); >>>>>> + } >>>>>> + } >>>>>> + } >>>>>> >>>>>> Why this simple logic so complicatedly written? >>>>>> for (int count = 0; count < optionParser.getNumberOfOptions(); >>>>>> count++) >>>>>> + >>>>>> optionParser.nextOption(); >>>>>> >>>>>> is really terrible. If you wont to do so, then lets your parser >>>>>> implements >>>>>> iterable, and do it >>>>>> properly. Or iterate by index on the result of parsing, but do nt do >>>>>> this >>>>>> terrible mixture. >>>>>> But I think that that parser should be long ago splitted into two >>>>>> classes >>>>>> - one - responsible for parsing, and second respnsible for varisous >>>>>> operations above parsed items >>>>>> (result of parsing). >>>>>> >>>>>> Feel free to do this refactoring as separate changeset before this >>>>>> actual >>>>>> patch, or simply ignore me. >>>>>> >>>>>> >>>>>> >>>>>> try { >>>>>> + optionParser = new OptionParser(args, >>>>>> OptionsDefinitions.getItwsettingsCommands(), true); >>>>>> + } catch (UnevenParameterException e) { >>>>>> + >>>>>> OutputController.getLogger().log(OutputController.Level.ERROR_ALL, >>>>>> e.getMessage()); >>>>>> + JNLPRuntime.exit(ERROR); >>>>>> + } >>>>>> >>>>>> >>>>>> for boot.java, keep the exception as debug only, for commandline, hhmhm >>>>>> well >>>>>> yes, erro_all should be ok. >>>>> >>>>> okay >>>>> >>>>>> >>>>>> - public OptionParser(String[] args, List >>>>>> options) { >>>>>> + public OptionParser(String[] args, List >>>>>> options, boolean >>>>>> orderMatters) throws UnevenParameterException { >>>>>> >>>>>> >>>>>> no No NO. No order metters here. PArser do not care. PArser do parsing. >>>>>> And >>>>>> prepare datat structure. >>>>>> Other operation may depend o it, but then the parammeter hsould go to >>>>>> them. >>>>>> >>>>>> >>>>>> >>>>>> + private void checkNumberOfArgumentsIsEven(boolean orderMatters) >>>>>> throws >>>>>> UnevenParameterException { >>>>>> + String exceptionMessage; >>>>>> + >>>>>> + if (orderMatters) { >>>>>> + exceptionMessage = checkEachOptionOccurenceHasEvenParams(); >>>>>> + } else { >>>>>> + exceptionMessage = >>>>>> checkTotalOptionOccurenceHasEvenParams(); >>>>>> + } >>>>>> + >>>>>> + if (exceptionMessage != "") { >>>>>> + throw new UnevenParameterException(exceptionMessage); >>>>>> + } >>>>>> + } >>>>>> + >>>>>> + private String checkEachOptionOccurenceHasEvenParams() { >>>>>> + String exceptionMessage = ""; >>>>>> + for (ParsedOption parsed : parsedOptions) { >>>>>> + if (parsed.getOption() != null && >>>>>> parsed.getOption().hasEvenNumberOrWithEqualsChar()) { >>>>>> + if (parsed.getParams().size() % 2 != 0) { >>>>>> + exceptionMessage += R("OPUnevenParams", >>>>>> parsed.getOption().option); >>>>>> + } >>>>>> + } >>>>>> + } >>>>>> + return exceptionMessage; >>>>>> + } >>>>>> + >>>>>> + private String checkTotalOptionOccurenceHasEvenParams() { >>>>>> + Map> evenNumbersTracker = new HashMap<>(); >>>>>> + String exceptionMessage = ""; >>>>>> + for (ParsedOption parsed : parsedOptions) { >>>>>> + if (parsed.getOption().hasEvenNumberOrWithEqualsChar()) { >>>>>> + if (evenNumbersTracker.isEmpty()) { >>>>>> + evenNumbersTracker.put(parsed.getOption().option, >>>>>> new >>>>>> ArrayList()); >>>>>> + } else { >>>>>> + for (String pop : evenNumbersTracker.keySet()) { >>>>>> + if (pop != parsed.getOption().option) { >>>>>> + >>>>>> evenNumbersTracker.put(parsed.getOption().option, >>>>>> new ArrayList()); >>>>>> + } >>>>>> + } >>>>>> + } >>>>>> + >>>>>> evenNumbersTracker.get(parsed.getOption().option).addAll(parsed.getParams()); >>>>>> + } >>>>>> + } >>>>>> >>>>>> >>>>>> I really did nto transalted what this hell code is doing and why it is >>>>>> needed. >>>>>> >>>>>> From the new methods in oarser, imho only getAllValues have sens. >>>>>> Other >>>>>> are >>>>>> bringing in extremly >>>>>> unclear code. >>>>>> >>>>>> imho you have only one possibility. To separate parser and parsed data >>>>>> (you >>>>>> already have >>>>>> ParsedOption, and it is good). Whensome class wonts to do some >>>>>> iterations >>>>>> abow parsed data, lets >>>>>> give him the unmodificable llists for iterations. why not? >>>>>> >>>>>> >>>>>> + public void removeParam(String param) { >>>>>> + params.remove(param); >>>>>> + } >>>>>> >>>>>> >>>>>> why that? This itemshould be as immutable as possible. >>>>>> >>>>>> >>>>>> I liek the exception handling. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Please - one note. you are adding to much overhead to really simple >>>>>> task. >>>>>> Your ideas are good, but >>>>>> the code design is really terrible. Each review costs me several hours. >>>>>> I >>>>>> can >>>>>> not afford it. Please >>>>>> really try to sit withjie or withanybody in Torronto, and let him help >>>>>> to >>>>>> redesign this patch. >>>>>> >>>>>> >>>>>> Sorry for saying it:( >>>>> >>>>> No don't be ;) >>>>> I'm sorry for costing you several hours :( >>>>> I'm going to simplify it the best I can >>>>> and see if Jie or someone else if they are not busy can quickly review it >>>>> before sending it to the list again. >>>>> >>>>> Thanks for the review ! >>>> >>>> One hint to my previosu review: >>>> >>>> Please split the patch to three parts >>>> - first - add support for the list ParsedOption >>>> - second - add support for the equls chars >>>> - third - integrate it into itweb settings >>>> - fourth - policy editor. >>>> >>>> >>>> I think it will be much simpler to write, and even much simpelr to review. >>>> >>>> >>>> J. >>>> >>>> >>>> >>>> [1] public boolean hasEvenNumberOrWithEqualsChar() { return >>>> numberOfArguments == >>>> NumberOfArguments.EVEN_NUMBER_OR_WITHEQUALCHAR; } BLEEEEE >>>> >> >> From jkang at redhat.com Tue Nov 4 14:27:03 2014 From: jkang at redhat.com (Jie Kang) Date: Tue, 4 Nov 2014 09:27:03 -0500 (EST) Subject: [rfc][icedtea-web] Fix to PluginMessage dates for PR2063 In-Reply-To: <5458D016.1020206@redhat.com> References: <1999948458.3078034.1415049438993.JavaMail.zimbra@redhat.com> <5458D016.1020206@redhat.com> Message-ID: <1216621730.3404691.1415111223746.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 11/03/2014 10:17 PM, Jie Kang wrote: > > I really did no mess? I really would expect console to show invlaid dates > header now... (aka = ar eyou sure??) Hmm. You are right, the headers don't get localized. I have attached two new patches with two different versions of fixes. I am not sure which is better: The most important difference is: Version 1: p.date = main[4]; versus Version 2: p.date = FileLog.getPluginSharedFormatter().format(p.originalTimeStamp); I tried it with LANG=en_CA, en_US, cs_CZ, de_CZ, pl_PL and the console seems to show valid dates. Below are the dates shown: Version 1: en_CA: Tue Nov 04 08:44:59 EST 2014 en_US: Tue Nov 04 08:45:35 EST 2014 de_DE Di Nov 04 09:01:04 EST 2014 cs_CZ ?t lis 04 09:02:52 EST 2014 pl_PL wto lis 04 09:21:56 EST 2014 Version 2: en_CA: Tue Nov 04 08:44:59 EST 2014 en_US: Tue Nov 04 08:45:35 EST 2014 de_DE Di Nov 04 09:01:04 EST 2014 cs_CZ ?t XI 04 09:02:52 EST 2014 pl_PL wto lis 04 09:21:04 EST 2014 Between the two versions, the only difference (so far) is the output in cs_CZ locale. Which do you prefer? > > Also I would keep the comments ffom my original pastebin here. Sure, I will add them. I meant to but I forgot, sorry;; Regards, > > If you disagree with the comments, then maybe remove the duplicated date at > all? > > Ty! > J. > > Hello, > > > > > > The attached patch is a small fix to PluginMessage addressing PR2063. > > > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2063 > > > > > > Thoughts? > > > > > > Regards, > > > > -- Jie Kang -------------- next part -------------- A non-text attachment was scrubbed... Name: itw-pr2063-version-2.patch Type: text/x-patch Size: 2686 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: itw-pr2063-version-1.patch Type: text/x-patch Size: 2690 bytes Desc: not available URL: From jvanek at redhat.com Tue Nov 4 16:21:04 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 04 Nov 2014 17:21:04 +0100 Subject: [rfc][icedtea-web] 1.5.2 release? In-Reply-To: <544BBF23.5010307@redhat.com> References: <544A4C3A.6010507@redhat.com> <544BBF23.5010307@redhat.com> Message-ID: <5458FCF0.3060504@redhat.com> On 10/25/2014 05:17 PM, Andrew Azores wrote: > On 10/24/2014 08:55 AM, Jiri Vanek wrote: >> Hi! >> >> There appeared few fixes in head which are maybe worthy to go to 1.5 and >> afterward calling for release: >> >> http://icedtea.classpath.org/hg/icedtea-web/rev/99d5407fab4a >> http://icedtea.classpath.org/hg/icedtea-web/rev/dd6be5e03667 >> http://icedtea.classpath.org/hg/icedtea-web/rev/df05d1de5af4 >> http://icedtea.classpath.org/hg/icedtea-web/rev/c6af2f50a95e >> http://icedtea.classpath.org/hg/icedtea-web/rev/6d62f68fb037 >> http://icedtea.classpath.org/hg/icedtea-web/rev/d8e057783109 >> http://icedtea.classpath.org/hg/icedtea-web/rev/90faf53bb981 >> http://icedtea.classpath.org/hg/icedtea-web/rev/2979fa371add >> >> >> Thoughts? >> >> J. > > Sounds like a good plan to me. > > Thanks, Hi! I have backported most of them today, except two. "2" is Andrew's and "3" Lukas' "4" is mine, but it is(?) already backported. Guys, please decide whether yours 2 and/or 3 should go to 1.5. If so, please backport. After doing so, and once i got confirmed RH115417 7, I will try to do a release. TY! J. -------------- next part -------------- A non-text attachment was scrubbed... Name: backports.tar.xz Type: application/x-xz Size: 8312 bytes Desc: not available URL: From mark at klomp.org Wed Nov 5 16:27:55 2014 From: mark at klomp.org (Mark Wielaard) Date: Wed, 05 Nov 2014 17:27:55 +0100 Subject: bugzilla emails bouncing? In-Reply-To: <1415001711.18323.60.camel@bordewijk.wildebeest.org> References: <1414710297.18323.43.camel@bordewijk.wildebeest.org> <1415001711.18323.60.camel@bordewijk.wildebeest.org> Message-ID: <1415204875.19702.8.camel@bordewijk.wildebeest.org> On Mon, 2014-11-03 at 09:01 +0100, Mark Wielaard wrote: > On Fri, 2014-10-31 at 00:04 +0100, Mark Wielaard wrote: > > Anybody know why the bugzilla emails have started to bounce when sent to > > the distro-pkg-dev list? They used to go through fine and not having > > them sent to the list will make it harder for people to track issues. > > Ping. Could someone take a look. This has been going on for the whole > weekend. The error message given by host ucsinet40.oracle.com is: 550 > Denied by policy. Which isn't very helpful. Ping again. ops at openjdk.java.net added to CC. See whole thread here: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-October/030095.html And here: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-November/thread.html#30096 This is still causing massive bouncing. We might just have to move to a different server/mailinglist if this isn't fixed soon. Thanks, Mark From aazores at redhat.com Wed Nov 5 17:19:14 2014 From: aazores at redhat.com (Andrew Azores) Date: Wed, 05 Nov 2014 12:19:14 -0500 Subject: [rfc][icedtea-web] 1.5.2 release? In-Reply-To: <5458FCF0.3060504@redhat.com> References: <544A4C3A.6010507@redhat.com> <544BBF23.5010307@redhat.com> <5458FCF0.3060504@redhat.com> Message-ID: <545A5C12.1000408@redhat.com> On 11/04/2014 11:21 AM, Jiri Vanek wrote: > On 10/25/2014 05:17 PM, Andrew Azores wrote: >> On 10/24/2014 08:55 AM, Jiri Vanek wrote: >>> Hi! >>> >>> There appeared few fixes in head which are maybe worthy to go to 1.5 and >>> afterward calling for release: >>> >>> http://icedtea.classpath.org/hg/icedtea-web/rev/99d5407fab4a >>> http://icedtea.classpath.org/hg/icedtea-web/rev/dd6be5e03667 >>> http://icedtea.classpath.org/hg/icedtea-web/rev/df05d1de5af4 >>> http://icedtea.classpath.org/hg/icedtea-web/rev/c6af2f50a95e >>> http://icedtea.classpath.org/hg/icedtea-web/rev/6d62f68fb037 >>> http://icedtea.classpath.org/hg/icedtea-web/rev/d8e057783109 >>> http://icedtea.classpath.org/hg/icedtea-web/rev/90faf53bb981 >>> http://icedtea.classpath.org/hg/icedtea-web/rev/2979fa371add >>> >>> >>> Thoughts? >>> >>> J. >> >> Sounds like a good plan to me. >> >> Thanks, > Hi! I have backported most of them today, except two. > "2" is Andrew's and "3" Lukas' > > "4" is mine, but it is(?) already backported. > > Guys, please decide whether yours 2 and/or 3 should go to 1.5. If so, > please backport. After doing so, and once i got confirmed RH115417 > 7, I will try to do a release. > > > TY! > > J. Attached is the fixed backport for #2. Thanks, -- Andrew Azores -------------- next part -------------- A non-text attachment was scrubbed... Name: temporary-permissions-button-npe-fix-backport.patch Type: text/x-patch Size: 8205 bytes Desc: not available URL: From jvanek at redhat.com Wed Nov 5 17:22:26 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Wed, 05 Nov 2014 18:22:26 +0100 Subject: [rfc][icedtea-web] 1.5.2 release? In-Reply-To: <545A5C12.1000408@redhat.com> References: <544A4C3A.6010507@redhat.com> <544BBF23.5010307@redhat.com> <5458FCF0.3060504@redhat.com> <545A5C12.1000408@redhat.com> Message-ID: <545A5CD2.70707@redhat.com> On 11/05/2014 06:19 PM, Andrew Azores wrote: > On 11/04/2014 11:21 AM, Jiri Vanek wrote: >> On 10/25/2014 05:17 PM, Andrew Azores wrote: >>> On 10/24/2014 08:55 AM, Jiri Vanek wrote: >>>> Hi! >>>> >>>> There appeared few fixes in head which are maybe worthy to go to 1.5 and >>>> afterward calling for release: >>>> >>>> http://icedtea.classpath.org/hg/icedtea-web/rev/99d5407fab4a >>>> http://icedtea.classpath.org/hg/icedtea-web/rev/dd6be5e03667 >>>> http://icedtea.classpath.org/hg/icedtea-web/rev/df05d1de5af4 >>>> http://icedtea.classpath.org/hg/icedtea-web/rev/c6af2f50a95e >>>> http://icedtea.classpath.org/hg/icedtea-web/rev/6d62f68fb037 >>>> http://icedtea.classpath.org/hg/icedtea-web/rev/d8e057783109 >>>> http://icedtea.classpath.org/hg/icedtea-web/rev/90faf53bb981 >>>> http://icedtea.classpath.org/hg/icedtea-web/rev/2979fa371add >>>> >>>> >>>> Thoughts? >>>> >>>> J. >>> >>> Sounds like a good plan to me. >>> >>> Thanks, >> Hi! I have backported most of them today, except two. >> "2" is Andrew's and "3" Lukas' >> >> "4" is mine, but it is(?) already backported. >> >> Guys, please decide whether yours 2 and/or 3 should go to 1.5. If so, >> please backport. After doing so, and once i got confirmed RH115417 >> 7, I will try to do a release. >> >> >> TY! >> >> J. > > Attached is the fixed backport for #2. > > Thanks, > -- > Andrew Azores > > temporary-permissions-button-npe-fix-backport.patch > > > diff --git a/ChangeLog b/ChangeLog > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,3 +1,18 @@ > +2014-11-05 Andrew Azores > + > + * netx/net/sourceforge/jnlp/resources/Messages.properties > + (CertWarnHTTPSAcceptTip, CertWarnHTTPSRejectTip): new messages more > + applicable for HTTPS cert warning dialogs > + * netx/net/sourceforge/jnlp/security/dialogs/CertWarningPane.java: > + distinguish between HTTPS cert warnings and signed applet cert warnings. > + Display appropriate text labels and buttons corresponding to either case. > + * netx/net/sourceforge/jnlp/security/dialogs/TemporaryPermissionsButton.java: > + If any of file, securityDelegate, or linkedButton are null, simply > + disable this component and do not add component listeners dependent upon > + these fields. Also, do not add multiple groups of permissions, and do not > + add the permissions to the securityDelegate until the linkedButton is > + actually clicked (rather than when the menu item is clicked) > + > 2014-10-21 Jiri Vanek > > Fixed case when already decoded file is wonted from cache (RH1154177) > diff --git a/netx/net/sourceforge/jnlp/resources/Messages.properties b/netx/net/sourceforge/jnlp/resources/Messages.properties > --- a/netx/net/sourceforge/jnlp/resources/Messages.properties > +++ b/netx/net/sourceforge/jnlp/resources/Messages.properties > @@ -25,6 +25,8 @@ > CertWarnCancelTip=Do not run this applet > CertWarnPolicyTip=Advanced sandbox settings > CertWarnPolicyEditorItem=Launch PolicyEditor > +CertWarnHTTPSAcceptTip=Accept this certificate and trust the HTTPS connection > +CertWarnHTTPSRejectTip=Do not accept this certificate and do not establish the HTTPS connection > Hmm. What to do with those two messages? I can supply CZ trasnaltion, maybe also DE (with help of Severin, Roman or similar :) ) How about PL? I rembere There was somebody in your surrounding. Wasnt? By otherwise - you agree it is ok for 1.5 thsi backport oook? Ty! J. From tim.bell at oracle.com Wed Nov 5 17:13:23 2014 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 05 Nov 2014 09:13:23 -0800 Subject: bugzilla emails bouncing? In-Reply-To: <1415204875.19702.8.camel@bordewijk.wildebeest.org> References: <1414710297.18323.43.camel@bordewijk.wildebeest.org> <1415001711.18323.60.camel@bordewijk.wildebeest.org> <1415204875.19702.8.camel@bordewijk.wildebeest.org> Message-ID: <545A5AB3.2080102@oracle.com> On 11/05/14 08:27, Mark Wielaard wrote: > On Mon, 2014-11-03 at 09:01 +0100, Mark Wielaard wrote: >> On Fri, 2014-10-31 at 00:04 +0100, Mark Wielaard wrote: >>> Anybody know why the bugzilla emails have started to bounce when sent to >>> the distro-pkg-dev list? They used to go through fine and not having >>> them sent to the list will make it harder for people to track issues. >> Ping. Could someone take a look. This has been going on for the whole >> weekend. The error message given by host ucsinet40.oracle.com is: 550 >> Denied by policy. Which isn't very helpful. > Ping again. ops at openjdk.java.net added to CC. > See whole thread here: > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-October/030095.html > And here: > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-November/thread.html#30096 > This is still causing massive bouncing. Checking... If the upstream (corporate) email servers are killing the emails by some policy, we will need to find the right person in the organization to fix it. Tim From aazores at redhat.com Wed Nov 5 17:25:43 2014 From: aazores at redhat.com (Andrew Azores) Date: Wed, 05 Nov 2014 12:25:43 -0500 Subject: [rfc][icedtea-web] 1.5.2 release? In-Reply-To: <545A5CD2.70707@redhat.com> References: <544A4C3A.6010507@redhat.com> <544BBF23.5010307@redhat.com> <5458FCF0.3060504@redhat.com> <545A5C12.1000408@redhat.com> <545A5CD2.70707@redhat.com> Message-ID: <545A5D97.803@redhat.com> On 11/05/2014 12:22 PM, Jiri Vanek wrote: > On 11/05/2014 06:19 PM, Andrew Azores wrote: >> On 11/04/2014 11:21 AM, Jiri Vanek wrote: >>> On 10/25/2014 05:17 PM, Andrew Azores wrote: >>>> On 10/24/2014 08:55 AM, Jiri Vanek wrote: >>>>> Hi! >>>>> >>>>> There appeared few fixes in head which are maybe worthy to go to >>>>> 1.5 and >>>>> afterward calling for release: >>>>> >>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/99d5407fab4a >>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/dd6be5e03667 >>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/df05d1de5af4 >>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/c6af2f50a95e >>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/6d62f68fb037 >>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/d8e057783109 >>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/90faf53bb981 >>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/2979fa371add >>>>> >>>>> >>>>> Thoughts? >>>>> >>>>> J. >>>> >>>> Sounds like a good plan to me. >>>> >>>> Thanks, >>> Hi! I have backported most of them today, except two. >>> "2" is Andrew's and "3" Lukas' >>> >>> "4" is mine, but it is(?) already backported. >>> >>> Guys, please decide whether yours 2 and/or 3 should go to 1.5. If so, >>> please backport. After doing so, and once i got confirmed RH115417 >>> 7, I will try to do a release. >>> >>> >>> TY! >>> >>> J. >> >> Attached is the fixed backport for #2. >> >> Thanks, >> -- >> Andrew Azores >> >> temporary-permissions-button-npe-fix-backport.patch >> >> >> diff --git a/ChangeLog b/ChangeLog >> --- a/ChangeLog >> +++ b/ChangeLog >> @@ -1,3 +1,18 @@ >> +2014-11-05 Andrew Azores >> + >> + * netx/net/sourceforge/jnlp/resources/Messages.properties >> + (CertWarnHTTPSAcceptTip, CertWarnHTTPSRejectTip): new messages more >> + applicable for HTTPS cert warning dialogs >> + * netx/net/sourceforge/jnlp/security/dialogs/CertWarningPane.java: >> + distinguish between HTTPS cert warnings and signed applet cert >> warnings. >> + Display appropriate text labels and buttons corresponding to >> either case. >> + * >> netx/net/sourceforge/jnlp/security/dialogs/TemporaryPermissionsButton.java: >> >> + If any of file, securityDelegate, or linkedButton are null, simply >> + disable this component and do not add component listeners >> dependent upon >> + these fields. Also, do not add multiple groups of permissions, >> and do not >> + add the permissions to the securityDelegate until the >> linkedButton is >> + actually clicked (rather than when the menu item is clicked) >> + >> 2014-10-21 Jiri Vanek >> >> Fixed case when already decoded file is wonted from cache >> (RH1154177) >> diff --git a/netx/net/sourceforge/jnlp/resources/Messages.properties >> b/netx/net/sourceforge/jnlp/resources/Messages.properties >> --- a/netx/net/sourceforge/jnlp/resources/Messages.properties >> +++ b/netx/net/sourceforge/jnlp/resources/Messages.properties >> @@ -25,6 +25,8 @@ >> CertWarnCancelTip=Do not run this applet >> CertWarnPolicyTip=Advanced sandbox settings >> CertWarnPolicyEditorItem=Launch PolicyEditor >> +CertWarnHTTPSAcceptTip=Accept this certificate and trust the HTTPS >> connection >> +CertWarnHTTPSRejectTip=Do not accept this certificate and do not >> establish the HTTPS connection >> > > > Hmm. What to do with those two messages? I can supply CZ trasnaltion, > maybe also DE (with help of Severin, Roman or similar :) ) How about > PL? I rembere There was somebody in your surrounding. Wasnt? > > By otherwise - you agree it is ok for 1.5 thsi backport oook? > > Ty! > > J. > Yup, otherwise the backport looks/sounds fine to me. I do know someone from school who might be able to provide PL translations still. But... what about ldracz? ;) probably easier than pulling in some other "volunteer". Thanks, -- Andrew Azores From ldracz at redhat.com Wed Nov 5 21:25:51 2014 From: ldracz at redhat.com (Lukasz Dracz) Date: Wed, 5 Nov 2014 16:25:51 -0500 (EST) Subject: [rfc][icedtea-web] 1.5.2 release? In-Reply-To: <545A5D97.803@redhat.com> References: <544A4C3A.6010507@redhat.com> <544BBF23.5010307@redhat.com> <5458FCF0.3060504@redhat.com> <545A5C12.1000408@redhat.com> <545A5CD2.70707@redhat.com> <545A5D97.803@redhat.com> Message-ID: <1599683181.4258978.1415222751770.JavaMail.zimbra@redhat.com> Hello, I don't think there is a point to backporting http://icedtea.classpath.org/hg/icedtea-web/rev/d8e057783109 since I would probably need to backport also: http://icedtea.classpath.org/hg/icedtea-web/rev/e30d71ab91c6 which was the refactor of the cache panel. I can do that if you still think it would be worthwhile to be backported. All it adds was a tooltip for the spinner, and 1.5 still uses the slider. I could add a tooltip for the slider I guess but they are somewhat different so the Messages would be different. Sorry for missing the IRC chat I was in a thermostat scrum, then went to lunch without noticing. I can do the PL translations, my PL should be good enough if needed. I speak it regularly at home, and attended Polish Saturday School here in Canada from elementary to high school. I do have a good understanding of Polish though I must admit my writing is a little bit rusty with all the Polish grammar rules but I can look stuff up if I am unsure :) What do we want translated specifically ? I translated the two parts from Andrew's patch in the messages.properties CertWarnHTTPSAcceptTip=Zaakceptuj ten certyfikat i zaufaj po??czenie przez HTTPS (Accept this certificate and trust a connection via HTTPS) CertWarnHTTPSRejectTip=Nie akceptuj ten certyfikat i nie buduj po??czenie HTTPS (Do not Accept this certificate and do not build a HTTPS connection) Establish looked/sounded odd to me so I thought build was more natural. I have attached the translation, is there anywhere else that needs editing or translating ? Thank you, Lukasz Dracz ----- Original Message ----- > From: "Andrew Azores" > To: "Jiri Vanek" , "IcedTea Distro List" , "Lukasz Dracz" > > Sent: Wednesday, November 5, 2014 12:25:43 PM > Subject: Re: [rfc][icedtea-web] 1.5.2 release? > > On 11/05/2014 12:22 PM, Jiri Vanek wrote: > > On 11/05/2014 06:19 PM, Andrew Azores wrote: > >> On 11/04/2014 11:21 AM, Jiri Vanek wrote: > >>> On 10/25/2014 05:17 PM, Andrew Azores wrote: > >>>> On 10/24/2014 08:55 AM, Jiri Vanek wrote: > >>>>> Hi! > >>>>> > >>>>> There appeared few fixes in head which are maybe worthy to go to > >>>>> 1.5 and > >>>>> afterward calling for release: > >>>>> > >>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/99d5407fab4a > >>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/dd6be5e03667 > >>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/df05d1de5af4 > >>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/c6af2f50a95e > >>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/6d62f68fb037 > >>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/d8e057783109 > >>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/90faf53bb981 > >>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/2979fa371add > >>>>> > >>>>> > >>>>> Thoughts? > >>>>> > >>>>> J. > >>>> > >>>> Sounds like a good plan to me. > >>>> > >>>> Thanks, > >>> Hi! I have backported most of them today, except two. > >>> "2" is Andrew's and "3" Lukas' > >>> > >>> "4" is mine, but it is(?) already backported. > >>> > >>> Guys, please decide whether yours 2 and/or 3 should go to 1.5. If so, > >>> please backport. After doing so, and once i got confirmed RH115417 > >>> 7, I will try to do a release. > >>> > >>> > >>> TY! > >>> > >>> J. > >> > >> Attached is the fixed backport for #2. > >> > >> Thanks, > >> -- > >> Andrew Azores > >> > >> temporary-permissions-button-npe-fix-backport.patch > >> > >> > >> diff --git a/ChangeLog b/ChangeLog > >> --- a/ChangeLog > >> +++ b/ChangeLog > >> @@ -1,3 +1,18 @@ > >> +2014-11-05 Andrew Azores > >> + > >> + * netx/net/sourceforge/jnlp/resources/Messages.properties > >> + (CertWarnHTTPSAcceptTip, CertWarnHTTPSRejectTip): new messages more > >> + applicable for HTTPS cert warning dialogs > >> + * netx/net/sourceforge/jnlp/security/dialogs/CertWarningPane.java: > >> + distinguish between HTTPS cert warnings and signed applet cert > >> warnings. > >> + Display appropriate text labels and buttons corresponding to > >> either case. > >> + * > >> netx/net/sourceforge/jnlp/security/dialogs/TemporaryPermissionsButton.java: > >> > >> + If any of file, securityDelegate, or linkedButton are null, simply > >> + disable this component and do not add component listeners > >> dependent upon > >> + these fields. Also, do not add multiple groups of permissions, > >> and do not > >> + add the permissions to the securityDelegate until the > >> linkedButton is > >> + actually clicked (rather than when the menu item is clicked) > >> + > >> 2014-10-21 Jiri Vanek > >> > >> Fixed case when already decoded file is wonted from cache > >> (RH1154177) > >> diff --git a/netx/net/sourceforge/jnlp/resources/Messages.properties > >> b/netx/net/sourceforge/jnlp/resources/Messages.properties > >> --- a/netx/net/sourceforge/jnlp/resources/Messages.properties > >> +++ b/netx/net/sourceforge/jnlp/resources/Messages.properties > >> @@ -25,6 +25,8 @@ > >> CertWarnCancelTip=Do not run this applet > >> CertWarnPolicyTip=Advanced sandbox settings > >> CertWarnPolicyEditorItem=Launch PolicyEditor > >> +CertWarnHTTPSAcceptTip=Accept this certificate and trust the HTTPS > >> connection > >> +CertWarnHTTPSRejectTip=Do not accept this certificate and do not > >> establish the HTTPS connection > >> > > > > > > Hmm. What to do with those two messages? I can supply CZ trasnaltion, > > maybe also DE (with help of Severin, Roman or similar :) ) How about > > PL? I rembere There was somebody in your surrounding. Wasnt? > > > > By otherwise - you agree it is ok for 1.5 thsi backport oook? > > > > Ty! > > > > J. > > > > Yup, otherwise the backport looks/sounds fine to me. > > I do know someone from school who might be able to provide PL > translations still. But... what about ldracz? ;) probably easier than > pulling in some other "volunteer". > > Thanks, > -- > Andrew Azores > -------------- next part -------------- A non-text attachment was scrubbed... Name: temporary-permissions-PL-translation.patch Type: text/x-patch Size: 724 bytes Desc: not available URL: From jvanek at redhat.com Thu Nov 6 09:07:51 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 06 Nov 2014 10:07:51 +0100 Subject: [rfc][icedtea-web] 1.5.2 release? In-Reply-To: <1599683181.4258978.1415222751770.JavaMail.zimbra@redhat.com> References: <544A4C3A.6010507@redhat.com> <544BBF23.5010307@redhat.com> <5458FCF0.3060504@redhat.com> <545A5C12.1000408@redhat.com> <545A5CD2.70707@redhat.com> <545A5D97.803@redhat.com> <1599683181.4258978.1415222751770.JavaMail.zimbra@redhat.com> Message-ID: <545B3A67.9020509@redhat.com> On 11/05/2014 10:25 PM, Lukasz Dracz wrote: > Hello, > > I don't think there is a point to backporting http://icedtea.classpath.org/hg/icedtea-web/rev/d8e057783109 > since I would probably need to backport also: http://icedtea.classpath.org/hg/icedtea-web/rev/e30d71ab91c6 which was the refactor of the cache panel. > I can do that if you still think it would be worthwhile to be backported. > All it adds was a tooltip for the spinner, and 1.5 still uses the slider. I could add a tooltip for the slider I guess but they are somewhat different so the Messages would be different. > Fair enough. Then do not backport it. ty fir check! > Sorry for missing the IRC chat I was in a thermostat scrum, then went to lunch without noticing. > I can do the PL translations, my PL should be good enough if needed. I speak it regularly at home, and attended Polish Saturday School here in Canada from elementary to high school. I do have a good understanding of Polish though I must admit my writing is a little bit rusty with all the Polish grammar rules but I can look stuff up if I am unsure :) > What do we want translated specifically ? > > I translated the two parts from Andrew's patch in the messages.properties > > CertWarnHTTPSAcceptTip=Zaakceptuj ten certyfikat i zaufaj po??czenie przez HTTPS > (Accept this certificate and trust a connection via HTTPS) > > CertWarnHTTPSRejectTip=Nie akceptuj ten certyfikat i nie buduj po??czenie HTTPS > (Do not Accept this certificate and do not build a HTTPS connection) > Establish looked/sounded odd to me so I thought build was more natural. > Great! ty! This is all :) Once Andrew pushes his backport, please push thsoe two lines. (ps: go on wiht transaltor :) > I have attached the translation, is there anywhere else that needs editing or translating ? > > Thank you, > Lukasz Dracz > > > > ----- Original Message ----- >> From: "Andrew Azores" >> To: "Jiri Vanek" , "IcedTea Distro List" , "Lukasz Dracz" >> >> Sent: Wednesday, November 5, 2014 12:25:43 PM >> Subject: Re: [rfc][icedtea-web] 1.5.2 release? >> >> On 11/05/2014 12:22 PM, Jiri Vanek wrote: >>> On 11/05/2014 06:19 PM, Andrew Azores wrote: >>>> On 11/04/2014 11:21 AM, Jiri Vanek wrote: >>>>> On 10/25/2014 05:17 PM, Andrew Azores wrote: >>>>>> On 10/24/2014 08:55 AM, Jiri Vanek wrote: >>>>>>> Hi! >>>>>>> >>>>>>> There appeared few fixes in head which are maybe worthy to go to >>>>>>> 1.5 and >>>>>>> afterward calling for release: >>>>>>> >>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/99d5407fab4a >>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/dd6be5e03667 >>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/df05d1de5af4 >>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/c6af2f50a95e >>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/6d62f68fb037 >>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/d8e057783109 >>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/90faf53bb981 >>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/2979fa371add >>>>>>> >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> J. >>>>>> >>>>>> Sounds like a good plan to me. >>>>>> >>>>>> Thanks, >>>>> Hi! I have backported most of them today, except two. >>>>> "2" is Andrew's and "3" Lukas' >>>>> >>>>> "4" is mine, but it is(?) already backported. >>>>> >>>>> Guys, please decide whether yours 2 and/or 3 should go to 1.5. If so, >>>>> please backport. After doing so, and once i got confirmed RH115417 >>>>> 7, I will try to do a release. >>>>> >>>>> >>>>> TY! >>>>> >>>>> J. >>>> >>>> Attached is the fixed backport for #2. >>>> >>>> Thanks, >>>> -- >>>> Andrew Azores >>>> >>>> temporary-permissions-button-npe-fix-backport.patch >>>> >>>> >>>> diff --git a/ChangeLog b/ChangeLog >>>> --- a/ChangeLog >>>> +++ b/ChangeLog >>>> @@ -1,3 +1,18 @@ >>>> +2014-11-05 Andrew Azores >>>> + >>>> + * netx/net/sourceforge/jnlp/resources/Messages.properties >>>> + (CertWarnHTTPSAcceptTip, CertWarnHTTPSRejectTip): new messages more >>>> + applicable for HTTPS cert warning dialogs >>>> + * netx/net/sourceforge/jnlp/security/dialogs/CertWarningPane.java: >>>> + distinguish between HTTPS cert warnings and signed applet cert >>>> warnings. >>>> + Display appropriate text labels and buttons corresponding to >>>> either case. >>>> + * >>>> netx/net/sourceforge/jnlp/security/dialogs/TemporaryPermissionsButton.java: >>>> >>>> + If any of file, securityDelegate, or linkedButton are null, simply >>>> + disable this component and do not add component listeners >>>> dependent upon >>>> + these fields. Also, do not add multiple groups of permissions, >>>> and do not >>>> + add the permissions to the securityDelegate until the >>>> linkedButton is >>>> + actually clicked (rather than when the menu item is clicked) >>>> + >>>> 2014-10-21 Jiri Vanek >>>> >>>> Fixed case when already decoded file is wonted from cache >>>> (RH1154177) >>>> diff --git a/netx/net/sourceforge/jnlp/resources/Messages.properties >>>> b/netx/net/sourceforge/jnlp/resources/Messages.properties >>>> --- a/netx/net/sourceforge/jnlp/resources/Messages.properties >>>> +++ b/netx/net/sourceforge/jnlp/resources/Messages.properties >>>> @@ -25,6 +25,8 @@ >>>> CertWarnCancelTip=Do not run this applet >>>> CertWarnPolicyTip=Advanced sandbox settings >>>> CertWarnPolicyEditorItem=Launch PolicyEditor >>>> +CertWarnHTTPSAcceptTip=Accept this certificate and trust the HTTPS >>>> connection >>>> +CertWarnHTTPSRejectTip=Do not accept this certificate and do not >>>> establish the HTTPS connection >>>> >>> >>> >>> Hmm. What to do with those two messages? I can supply CZ trasnaltion, >>> maybe also DE (with help of Severin, Roman or similar :) ) How about >>> PL? I rembere There was somebody in your surrounding. Wasnt? >>> >>> By otherwise - you agree it is ok for 1.5 thsi backport oook? >>> >>> Ty! >>> >>> J. >>> >> >> Yup, otherwise the backport looks/sounds fine to me. >> >> I do know someone from school who might be able to provide PL >> translations still. But... what about ldracz? ;) probably easier than >> pulling in some other "volunteer". >> >> Thanks, >> -- >> Andrew Azores >> From jvanek at redhat.com Thu Nov 6 14:45:30 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 06 Nov 2014 15:45:30 +0100 Subject: [rfc][icedtea-web] Fix to PluginMessage dates for PR2063 In-Reply-To: <1216621730.3404691.1415111223746.JavaMail.zimbra@redhat.com> References: <1999948458.3078034.1415049438993.JavaMail.zimbra@redhat.com> <5458D016.1020206@redhat.com> <1216621730.3404691.1415111223746.JavaMail.zimbra@redhat.com> Message-ID: <545B898A.5070304@redhat.com> On 11/04/2014 03:27 PM, Jie Kang wrote: > > > ----- Original Message ----- >> On 11/03/2014 10:17 PM, Jie Kang wrote: >> >> I really did no mess? I really would expect console to show invlaid dates >> header now... (aka = ar eyou sure??) > > Hmm. You are right, the headers don't get localized. I have attached two new patches with two different versions of fixes. I am not sure which is better: > > The most important difference is: > > Version 1: p.date = main[4]; Yes , I vote for v1 deffinitely. However - the sorting in consoel could not work for you - have youtried!?!?!? Tehre is: case 4: Collections.sort(sortedData, new CatchedMessageWithHeaderComparator() { @Override public int body(MessageWithHeader o1, MessageWithHeader o2) { return o1.getHeader().date.compareTo(o2.getHeader().date); } }); You had to got compley insane results.... I think the fix must go deeper. What I consider as best fix is: in console ouput (in header is on) to have the most correct "result of main[4]" //rfc However, the sorting operation must be done against originalTimeStamp . hmm. I would like to test, if there canbe case when the originalTimeStamp and p.date may have really different (eg by hours or more) values.... J. > > versus > > Version 2: p.date = FileLog.getPluginSharedFormatter().format(p.originalTimeStamp); > > > I tried it with LANG=en_CA, en_US, cs_CZ, de_CZ, pl_PL and the console seems to show valid dates. Below are the dates shown: > > Version 1: > > en_CA: > Tue Nov 04 08:44:59 EST 2014 > en_US: > Tue Nov 04 08:45:35 EST 2014 > de_DE > Di Nov 04 09:01:04 EST 2014 > cs_CZ > ?t lis 04 09:02:52 EST 2014 > pl_PL > wto lis 04 09:21:56 EST 2014 > > > Version 2: > > en_CA: > Tue Nov 04 08:44:59 EST 2014 > en_US: > Tue Nov 04 08:45:35 EST 2014 > de_DE > Di Nov 04 09:01:04 EST 2014 > cs_CZ > ?t XI 04 09:02:52 EST 2014 > pl_PL > wto lis 04 09:21:04 EST 2014 > > > Between the two versions, the only difference (so far) is the output in cs_CZ locale. > > > Which do you prefer? > >> >> Also I would keep the comments ffom my original pastebin here. > > > Sure, I will add them. I meant to but I forgot, sorry;; > > > Regards, > >> >> If you disagree with the comments, then maybe remove the duplicated date at >> all? >> >> Ty! >> J. >>> Hello, >>> >>> >>> The attached patch is a small fix to PluginMessage addressing PR2063. >>> >>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2063 >>> >>> >>> Thoughts? >>> >>> >>> Regards, >>> >> >> > From jkang at redhat.com Thu Nov 6 20:04:29 2014 From: jkang at redhat.com (Jie Kang) Date: Thu, 6 Nov 2014 15:04:29 -0500 (EST) Subject: [rfc][icedtea-web] Added reproducer for pack-gz applets In-Reply-To: <754359593.4905361.1415303946019.JavaMail.zimbra@redhat.com> Message-ID: <1322607003.4907449.1415304269808.JavaMail.zimbra@redhat.com> Hello, This patch adds a reproducer to test for pack-gz applets in the three scenarios: Browser - JNLP href (file) Browser - Applet tags Javaws - JNLP file In order to pass these tests, modifications have been made to: 1. The test server implementation (TinyHttpdImpl) to take into account Accept-Encoding requests and serve the correct jar files. 2. The PluginBridge to take into account the jnlp parameters for using packaging or versioning in order to allow the Browser - JNLP situation to work. All of this is in respect to the guidelines found here: http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/tools/pack200.html Thoughts? Cheers, -- Jie Kang -------------- next part -------------- A non-text attachment was scrubbed... Name: itw-packgz-reproducer-1.patch Type: text/x-patch Size: 20680 bytes Desc: not available URL: From jkang at redhat.com Thu Nov 6 20:39:49 2014 From: jkang at redhat.com (Jie Kang) Date: Thu, 6 Nov 2014 15:39:49 -0500 (EST) Subject: [rfc][icedtea-web] ResourceTracker Download Refactor In-Reply-To: <5457AA2C.3050407@redhat.com> References: <1427890798.21679342.1408117850747.JavaMail.zimbra@redhat.com> <544A4B2F.9090303@redhat.com> <1047396171.780529.1414615524414.JavaMail.zimbra@redhat.com> <5457AA2C.3050407@redhat.com> Message-ID: <1875851257.4928700.1415306389952.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 10/29/2014 09:45 PM, Jie Kang wrote: > > > > > > ----- Original Message ----- > >> On 08/15/2014 05:50 PM, Jie Kang wrote: > >>> Hello, > >>> > >>> > >>> The attached patch makes what looks like a huge refactor to > >>> ResourceTracker's function: 'downloadResource'. > >>> > >>> Previously downloadResource was a single function over 100 lines long. > >>> Inspired by the book 'Clean Code' by Robert C. Martin, I believe this to > >>> be quite bad. The patch simply extracts portions of the function into > >>> other functions with descriptive names. > >>> > >>> As 'downloadResource' is extremely important to ITW's function, I want to > >>> stress that there is NO new code and that when refactoring I made sure > >>> that there was NO reordering of code. The execution is the exact same > >>> prior to this patch. > >>> > >>> The reason for this patch is that the codebase for ITW is in some places > >>> quite old (code from 2003?) and unnecessarily complicated. This is a > >>> small > >>> part of an attempt to clean the code up and increase extensibility for > >>> future enhancements (ie. supporting more of JNLP's spec). > >>> > >>> > >>> PS. I have manual tested ITW with the patch applied and have not seen any > >>> regressions. > >>> > >>> > >>> > >>> Thanks, > >>> > >> Please adapt to a head and test again. I think there is no longer any need > >> to > >> delay this good patch. > >> > >> Sory for dealying! > >> > >> J. > >> > > > > Hello, > > > > > > The attached patch is a refactor to ResourceTrackers download function. > > > > Also attached is a copy of the results from one run of reproducers with the > > patch applied. Since this affects a critical part of ITW, I have tried to > > be extremely careful in order to make sure there are no regressions. I > > have done a large amount of testing prior to posting this patch to the > > list. > > > > The main purpose of this patch is to make it easier to understand what the > > download function is doing, in order to make further improvements on it in > > the future. > > > > > > Thoughts? If you could apply the patch and read over the new code, and see > > if you can understand what is going on, it would be greatly appreciated. > > Yes, the code is much more readable! > > > > > > > > PS Notes: > > > > There is a function added to CacheUtil: public static File getCacheFile(URL > > source) > > > > This calls the previously existing function: getCacheFile(URL source, > > Version version) with version==null. This might seem dangerous but, if you > > read through the code-lines for getCacheFile, you will notice that > > 'version' is never used. 'version' is passed to two functions, > > 'isCacheable' and 'makeNewCacheFile', both of which do not use version at > > all. > > > > I am not sure what the intentions of the previous developers were with the > > Version object so I have chosen to keep the code intact for now. > > > > > > > > > > Hi! > > The patch looks good. > > Few nits: > You are removing some comments or renaming variables (like e to ex) whcih > reallys eems to be > unnecessary. I would let them as they are. But depends on you. I have changed them back. > > I'm not sure what to think about versionless method overloading:( How rest of > ITW is doing it? > If the (string,null) call is more wide spread, then I'm for it, and also to > replace other calls like > that. I have spent a lot of time looking at Resource:requestVersion and Resource:downloadVersion fields and it seems to me, that downloadVersion is useless, and requestVersion is used to support versioned JARs. I personally think we should change the functions to not require Version since they do not even use the field. Maybe I can post a patch so you can see what it looks like? > > Last nit you will not like - unit XOR reproducers for your new methods is > really wonted. I think > that reproducer - moreover being written as unittestm and only using prepared > resources, would be > completely enough. Technically, nearly every reproducer for IT-W tests this code. I am having a lot of trouble trying to create tests for this since there aren't any public methods changed. As well, I haven't been able to write any unit tests using local files because the Resource/Cache system prevents download+caching of local files from occurring. Given the number of reproducers we have, I feel like it is decently tested already. Can you provide any suggestions or hints on what kind of tests to write? > > Also you did few: > - catch (Exception ex) { > + } catch (IOException e) { > I would strongly discourage you from doing so... Not only IO exception can > happen here.... And we > do not wont to die... Right. I have changed it back. > > Thank you for doing this extremely necessary stuff! > J. > > -- Jie Kang -------------- next part -------------- A non-text attachment was scrubbed... Name: itw-rt-download-refactor-3.patch Type: text/x-patch Size: 20270 bytes Desc: not available URL: From jvanek at redhat.com Fri Nov 7 13:10:57 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 07 Nov 2014 14:10:57 +0100 Subject: [rfc][icedtea-web] Added reproducer for pack-gz applets In-Reply-To: <1322607003.4907449.1415304269808.JavaMail.zimbra@redhat.com> References: <1322607003.4907449.1415304269808.JavaMail.zimbra@redhat.com> Message-ID: <545CC4E1.1070902@redhat.com> On 11/06/2014 09:04 PM, Jie Kang wrote: > Hello, > > This patch adds a reproducer to test for pack-gz applets in the three scenarios: > > Browser - JNLP href (file) > Browser - Applet tags > Javaws - JNLP file > > > In order to pass these tests, modifications have been made to: > > 1. The test server implementation (TinyHttpdImpl) to take into account Accept-Encoding requests and serve the correct jar files. > > 2. The PluginBridge to take into account the jnlp parameters for using packaging or versioning in order to allow the Browser - JNLP situation to work. > > All of this is in respect to the guidelines found here: > > http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/tools/pack200.html > > Thoughts? > > > Cheers, > This is moreover excelent work, ty! few nits - "doNotRunInOpera" Whyyyyyy? - acceptEncoding again -why? - +PACKER=pack200 you should nto be lazy and use (BOOT_DIR)/bin/pack200 - is it onot in boot dir? Configure check? ..checking for pack200 ...found and then PACKER=(PACK200).Not fund - warn that "reproducer blah balh will fail" - because if build of reproducer fail, the suite continu - I know that this is abit stric but may save hours later. One though - looking to the changes in server and why it is cusotm one - why not to move th elogic to serverimpl ? If (pack).gz is the requested file, then return result of runtome compression of this resource ? J. From jvanek at redhat.com Fri Nov 7 13:38:01 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 07 Nov 2014 14:38:01 +0100 Subject: [rfc][icedtea-web] ResourceTracker Download Refactor In-Reply-To: <1875851257.4928700.1415306389952.JavaMail.zimbra@redhat.com> References: <1427890798.21679342.1408117850747.JavaMail.zimbra@redhat.com> <544A4B2F.9090303@redhat.com> <1047396171.780529.1414615524414.JavaMail.zimbra@redhat.com> <5457AA2C.3050407@redhat.com> <1875851257.4928700.1415306389952.JavaMail.zimbra@redhat.com> Message-ID: <545CCB39.3050809@redhat.com> ...snip... > >> >> I'm not sure what to think about versionless method overloading:( How rest of >> ITW is doing it? >> If the (string,null) call is more wide spread, then I'm for it, and also to >> replace other calls like >> that. > > I have spent a lot of time looking at Resource:requestVersion and Resource:downloadVersion fields and it seems to me, that downloadVersion is useless, and requestVersion is used to support versioned JARs. > > I personally think we should change the functions to not require Version since they do not even use the field. Maybe I can post a patch so you can see what it looks like? What I'm really afraid is, that the version will be forgoten. I was thinking about it, and it resulted (yaaaH! :D) that I would like to keep only (string, version) signature - and so fforce yu to use several more nulls:( > >> >> Last nit you will not like - unit XOR reproducers for your new methods is >> really wonted. I think >> that reproducer - moreover being written as unittestm and only using prepared >> resources, would be >> completely enough. > > Technically, nearly every reproducer for IT-W tests this code. fair point:) > > I am having a lot of trouble trying to create tests for this since there aren't any public methods changed. As well, I haven't been able to write any unit tests using local files because the Resource/Cache system prevents download+caching of local files from occurring. > > Given the number of reproducers we have, I feel like it is decently tested already. > I agree. > Can you provide any suggestions or hints on what kind of tests to write? What I had in mind were moreover unittests for new methods you have created. To supply resources you can use our SeverAccess (in unittests) and so be done. I actually do not wont you to add reproducere - you are more then right that there are tons of reproducers already testing it. But build some first wall deffence in unittests. This may be added as separate changeset. > >> >> Also you did few: >> - catch (Exception ex) { >> + } catch (IOException e) { >> I would strongly discourage you from doing so... Not only IO exception can >> happen here.... And we >> do not wont to die... > > > Right. I have changed it back. > >> Otherwise ok for head. after fixing the version. If you insists on removing of version from this method, then I would encourage you to do so as separate changest. J. From jvanek at redhat.com Fri Nov 7 13:53:12 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 07 Nov 2014 14:53:12 +0100 Subject: [rfc][icedtea-web] log jnlp file to console In-Reply-To: <544663B9.4020000@redhat.com> References: <544663B9.4020000@redhat.com> Message-ID: <545CCEC8.3090907@redhat.com> On 10/21/2014 03:46 PM, Jiri Vanek wrote: > hi! > > This is not just rfc, but RFC :) as I'm not sure which way to go. The only one I found suitbale - > this oen - is not nice. > > Curently all the logs are going to logger, which determine if debug is on and what channels are > enabled (stdout/err, file, console) > > According to those, it consume the message. This workflow had one exception, the reprinting of > jnlpfiel, which went only to console, if debug was online. > Most of the bugreports now contains whole console - and it is very good - but that measn the jnlp > file is missing. > > > The jnlpfile reprint was excluded, becasue console is using html formatting, to higlight outputs - > for palintext the reprint is and willbe working fine, but it is not working with syntax higlighting > from obvious reasons. > > I wont to avoid escaping of inpout - the message object is sahred between stdou/file/html > console/plain console so to make special decoding for html console do need copy of it (and in case > of console solid rework of console itself) and then proces via esapcping. > Another issue is that html in java is terribly old, and hard to say what specification it supports > (if any). > > To my surpise it support (yes nothing else do so...) So I have tryed to include the jnlp > reprint wrapped by this tags. And it seems to be working fine wiht all supported outputs without any > encodings or copying. > > There is drawback - eg firefox now have issues to show everything behind </plaintext> :( (note - > <pre> do not work for jeeditorpane:( )) > > J. ping, thoughts? I amde an attmept with <pre><plaintext></paintext></pre> and it did not helped. Still the jnlp fiel should appear inconsole :( From jvanek at redhat.com Fri Nov 7 13:53:36 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 07 Nov 2014 14:53:36 +0100 Subject: [rfc][icedtea-web] merge property arguments into config singleton (was Re: javaws CLI with Icedtea-web) In-Reply-To: <5448DEB0.1040508@redhat.com> References: <53B2CC4F.3080501@redhat.com> <5448DEB0.1040508@redhat.com> Message-ID: <545CCEE0.8020509@redhat.com> On 10/23/2014 12:55 PM, Jiri Vanek wrote: > > > > -------- Forwarded Message -------- > Subject: Re: javaws CLI with Icedtea-web > Date: Tue, 01 Jul 2014 16:57:19 +0200 > From: Jiri Vanek <jvanek at redhat.com> > To: distro-pkg-dev at openjdk.java.net, Omair Majid <omajid at redhat.com> > > On 07/01/2014 01:32 PM, Jiri Vanek wrote: >> On 06/30/2014 05:41 PM, Chris Lee wrote: >>> Hi Jacob, >>> On Jun 30, 2014, at 5:23 PM, Jacob Wisor wrote: >>> >>>> On 06/30/2014 04:39 PM, Chris Lee wrote: >>>>> Hi Jiri >>>>> >>>>> Thanks so much >>>>> >>>>> To explain as well, what I am trying to do is use a specific proxy server and port for a >>>>> specific website. >>>>> I had thought that a link to the CLI might be the quickest if I can get it working, If there is >>>>> an easier way to configure, then I am open to suggestions. >>>> >>>> Try using Java's network configuration properties like http.proxyHost, http.proxyPort, >>>> https.proxyHost, https.proxyPort, ftp.proxyHost, ftp.proxyPort, gopher.proxyHost, >>>> gopher.proxyPort, socksProxyHost, socksProxyPort with the -J-D switch. For more information have >>>> a look into >>>> <JRE_HOME>/lib/net.properties. >>> Assuming that they can/should be applied in the same manner as the properties from before, but I >>> appear to be having the same issue where it is not being applied. >>> >>> ie: >>> [chlee at pc-atlas-cr-35 .icedtea]$ javaws -verbose -J-Dhttp.proxy.Host=atlasgw-exp.cern.ch >>> -J-Dhttp.proxyPort=3128 http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp >>> Loading User level properties from: /atlas-home/1/chlee/.icedtea/deployment.properties >>> Starting security dialog thread >>> Using firefox's profiles file: /atlas-home/1/chlee/.mozilla/firefox/profiles.ini >>> Found preferences file: /atlas-home/1/chlee/.mozilla/firefox/4mi0hwbe.default/prefs.js >>> Read 77 entries from Firefox's preferences >>> JNLP file location: http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp >>> call privileged method: getCodeBase >>> result: null >>> Status: CONNECT STARTED +(CONNECT STARTED) @ /dipbrowser/launch.jnlp >>> Status: CONNECT DOWNLOAD STARTED +(DOWNLOAD) @ /dipbrowser/launch.jnlp >>> Status: CONNECTING DOWNLOAD STARTED +(CONNECTING) -(CONNECT) @ /dipbrowser/launch.jnlp >>> All possible urls for location=http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp >>> state=CONNECTING DOWNLOAD STARTED : [http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp, >>> http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp] >>> Selecting proxy for: http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp >>> Browser proxy option "4" (Automatic) not supported yet. >>> Browser selected proxies: [DIRECT] >>> Selected proxies: [DIRECT] >>> Selecting proxy for: socket://dipbrowser.web.cern.ch:80 >>> Browser proxy option "4" (Automatic) not supported yet. >>> Browser selected proxies: [DIRECT] >>> Selected proxies: [DIRECT] >>>> >>>>>> 1.4.1 is outdated. If you need for some reason to stay with 1.4, please update to 1.4.2, >>>>>> however - please swap to 1.5. It was released few month ago, is stable, and a a lot of fixes >>>>>> was fixed here. >>>>> >>>>> This installation is for the ATLAS experiment at CERN. For security reason, we are usually >>>>> compelled to use what is available in the SLC repos, which unfortunately for me right now is 1.4.1 >>>> >>>> If security is key to you, you shouldn't probably be using IcedTea-Web yet. Instead, resort to >>>> Oracle's Java Web Start implementation. This product is feature and specification complete, in >>>> contrast to IcedTea-Web. Java Web Start has most probably received far more security fixes and >>>> screening than IcedTea-Web. Personally, at the current stage of IcedTea-Web I would advise any >>>> enterprise or security aware user not to use IcedTea-Web. >>> I believe we had a number of issues with the Oracles Javaws. somethings like the latest updates >>> forced us to keep things current all the time, and while we are in production runs, things can be >>> locked down for months at a time or we could lose data taking at our experiment. >>> Right now this is me testing to see if I can get this to work >>> >> Chris, Just to completeness, may you try the -Xnofork together with your Experiments? >> >> Anyway it sounds like bug. I will look into it. >> > > Well this is bug. As it is done in ITW, the proxy* settings are loaded from configurations before > the value of -property is merged. > > But it do not explain why even the -J-Ddeployment.blah is not working. //me must find what > specification says > > Looking inisde > > as it was: > the ITW properties are loaded form file > + they are mixed into system properties > proxy is selected > launcher object is created > "-property" argument's values are merged into JNLPresources > and later ... I'mnot sure if they are even later merged into properties > > It is clear that original NETX wanted to keep the -property's params as isolated per jnlpfile > > > After attached patch > the ITW properties are loaded form file > + they are mixed into system properties > "-property" argument's values are merged into ITW properties (so not into system properties) > proxy is selected > launcher object is created > "-property" argument's values are still merged into JNLPresources > > So now the config singleton have the -property(s) shared. Also set on jnlpconfig value will not > change the value in per-jnlpresource > > > I believe that this can be correct as > - javaws have always isolated JVM > - applets, with shared JVM, have always same -property(s) set via itwsettings (command-line args) > > Well my fix can probably go into 1.4 and 1.5, but for head the properties should be revisited one > more times. Maybe also -D and -J-D should be handled differently. > Are actually -J working with forked JVM? By check on code.. not > > The patch contains small refactoring to not duplicate code. The test is attached likewise. > > > Chis, are you able to build patched RPMs? > > J. > > > > > > > ping? Security thoughts? J. From jvanek at redhat.com Fri Nov 7 14:12:16 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 07 Nov 2014 15:12:16 +0100 Subject: [rfc][icedtea-web] Preparing PolicyEditor for future full policyfile featureset In-Reply-To: <5457CC4E.5020701@redhat.com> References: <5457CC4E.5020701@redhat.com> Message-ID: <545CD340.8090600@redhat.com> On 11/03/2014 07:41 PM, Andrew Azores wrote: > Hi, > > PolicyEditor is currently not a viable total replacement for the existing JDK policytool for a few > reasons. Form quick look to code, changeset looks ok, but I'm quite wondering aout final goal. ... > > 1) Only supports CodeBase, not SignedBy and Principal > 2) No KeyStore entry support > 3) Parser is not a real parser > 4) CustomPolicyViewer is a little underpowered > > Once these issues are all resolved, then I think it would be fair for us to push using PolicyEditor > alone, and remove the button from itweb-settings which launches policytool as the "Advanced editor". And - do we wont to do so? Yes, maybe policy tool will be removed, then we will be forced. But still - is good idea to rape this beautifully simple app - especially when used from "tmp permissions" button. > > This patch is aimed at working on #1 and #2. It adds a few more simple data structures (KeystoreInfo > and PolicyIdentifier) so that, once a proper parser exists, a full-featured policy file can be fully > modelled with PolicyEditor's structures. KeystoreInfo is currently completely unused, and > PolicyIdentifier is used only for its codebase attribute, so there are no behavioural changes after > this patch is applied. All unit tests should come up with the same results (and the only unit test > changes made are refactoring for builder pattern) and manual testing should work exactly the same as > well. > > Since PolicyEntries now have many more attributes, its constructor has been made private and > PolicyEntry is now constructed with a Builder. Changing each of the existing unit test cases dealing > with PolicyEntry to use the builder introduced some unfortunate noise to this patch. > > Missing with this changeset are any changes to PolicyFileModel so that these new attributes might be > written to file if (somehow) present. Since there is no UI to modify these attributes and no parser > to read them from files, for now it will have to be done simply with mock data and performed only in > unit tests. I'd like to add this as a separate changeset simply because of the limited and highly > variable amounts of time I have to commit to this at the moment. > On contrary - there always was an question - what policyeditor do when it finds one of many unsupported parts of policy files. The only solution is what you suggest - to support them. But Any full supporting will lead to nasty PociyTool_II :( So before actually doing any code change, i would probably like to discuse final usecases, final gui, and final reactions to some cases. Some advance mode? Blah :( <me to stupid even for gui design> :( Completely reworked gui to support "everything" in really simple way? Some jtree with checkboxes and popupmenus? Maybe levels of advancenes? I'mnot sure if such editor is in scope of ITW. J. From aazores at redhat.com Fri Nov 7 15:07:46 2014 From: aazores at redhat.com (Andrew Azores) Date: Fri, 07 Nov 2014 10:07:46 -0500 Subject: [rfc][icedtea-web] Preparing PolicyEditor for future full policyfile featureset In-Reply-To: <545CD340.8090600@redhat.com> References: <5457CC4E.5020701@redhat.com> <545CD340.8090600@redhat.com> Message-ID: <545CE042.6080407@redhat.com> On 11/07/2014 09:12 AM, Jiri Vanek wrote: > On 11/03/2014 07:41 PM, Andrew Azores wrote: >> Hi, >> >> PolicyEditor is currently not a viable total replacement for the >> existing JDK policytool for a few >> reasons. > > Form quick look to code, changeset looks ok, but I'm quite wondering > aout final goal. ... >> >> 1) Only supports CodeBase, not SignedBy and Principal >> 2) No KeyStore entry support >> 3) Parser is not a real parser >> 4) CustomPolicyViewer is a little underpowered >> >> Once these issues are all resolved, then I think it would be fair for >> us to push using PolicyEditor >> alone, and remove the button from itweb-settings which launches >> policytool as the "Advanced editor". > > And - do we wont to do so? Yes, maybe policy tool will be removed, then > we will be forced. But still - is good idea to rape this beautifully > simple app - especially when used from "tmp permissions" button. >> >> This patch is aimed at working on #1 and #2. It adds a few more simple >> data structures (KeystoreInfo >> and PolicyIdentifier) so that, once a proper parser exists, a >> full-featured policy file can be fully >> modelled with PolicyEditor's structures. KeystoreInfo is currently >> completely unused, and >> PolicyIdentifier is used only for its codebase attribute, so there are >> no behavioural changes after >> this patch is applied. All unit tests should come up with the same >> results (and the only unit test >> changes made are refactoring for builder pattern) and manual testing >> should work exactly the same as >> well. >> >> Since PolicyEntries now have many more attributes, its constructor has >> been made private and >> PolicyEntry is now constructed with a Builder. Changing each of the >> existing unit test cases dealing >> with PolicyEntry to use the builder introduced some unfortunate noise >> to this patch. >> >> Missing with this changeset are any changes to PolicyFileModel so that >> these new attributes might be >> written to file if (somehow) present. Since there is no UI to modify >> these attributes and no parser >> to read them from files, for now it will have to be done simply with >> mock data and performed only in >> unit tests. I'd like to add this as a separate changeset simply >> because of the limited and highly >> variable amounts of time I have to commit to this at the moment. >> > > On contrary - there always was an question - what policyeditor do when > it finds one of many unsupported parts of policy files. The only > solution is what you suggest - to support them. But Any full supporting > will lead to nasty PociyTool_II :( > > So before actually doing any code change, i would probably like to > discuse final usecases, final gui, and final reactions to some cases. > > Some advance mode? Blah :( <me to stupid even for gui design> :( > Completely reworked gui to support "everything" in really simple way? > Some jtree with checkboxes and popupmenus? Maybe levels of advancenes? > I'mnot sure if such editor is in scope of ITW. > > > J. > Fair enough. I'd still like for PolicyEditor to be able to support these policy file features in the back end at least. Even if the GUI it exposes doesn't have any controls to view or modify these things, it feels broken to make a tool for editing policy files and have it actually be able to handle only some (arbitrary) subset of policy file syntax. policytool also still frankly isn't very nice to use, and I think after giving PolicyEditor a nice back end with full policy file support, it wouldn't be *too* much work to create another front end on top of it to replace policytool, although this also would be made easier if more work is put in to refactoring what we have now into proper MVC (which I'm also willing to work on, slowly). Having both PolicyEditor and policytool2, both using the same back end, sounds pretty nice to me... maybe policytool2 and the back end could even be upstreamed and the nice, simple PolicyEditor GUI kept local to ITW, one day. Thanks, -- Andrew Azores From jkang at redhat.com Fri Nov 7 15:53:30 2014 From: jkang at redhat.com (Jie Kang) Date: Fri, 7 Nov 2014 10:53:30 -0500 (EST) Subject: [rfc][icedtea-web] merge property arguments into config singleton (was Re: javaws CLI with Icedtea-web) In-Reply-To: <545CCEE0.8020509@redhat.com> References: <53B2CC4F.3080501@redhat.com> <5448DEB0.1040508@redhat.com> <545CCEE0.8020509@redhat.com> Message-ID: <1020878052.5351286.1415375610115.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 10/23/2014 12:55 PM, Jiri Vanek wrote: > > > > > > > > -------- Forwarded Message -------- > > Subject: Re: javaws CLI with Icedtea-web > > Date: Tue, 01 Jul 2014 16:57:19 +0200 > > From: Jiri Vanek <jvanek at redhat.com> > > To: distro-pkg-dev at openjdk.java.net, Omair Majid <omajid at redhat.com> > > > > On 07/01/2014 01:32 PM, Jiri Vanek wrote: > >> On 06/30/2014 05:41 PM, Chris Lee wrote: > >>> Hi Jacob, > >>> On Jun 30, 2014, at 5:23 PM, Jacob Wisor wrote: > >>> > >>>> On 06/30/2014 04:39 PM, Chris Lee wrote: > >>>>> Hi Jiri > >>>>> > >>>>> Thanks so much > >>>>> > >>>>> To explain as well, what I am trying to do is use a specific proxy > >>>>> server and port for a > >>>>> specific website. > >>>>> I had thought that a link to the CLI might be the quickest if I can get > >>>>> it working, If there is > >>>>> an easier way to configure, then I am open to suggestions. > >>>> > >>>> Try using Java's network configuration properties like http.proxyHost, > >>>> http.proxyPort, > >>>> https.proxyHost, https.proxyPort, ftp.proxyHost, ftp.proxyPort, > >>>> gopher.proxyHost, > >>>> gopher.proxyPort, socksProxyHost, socksProxyPort with the -J-D switch. > >>>> For more information have > >>>> a look into > >>>> <JRE_HOME>/lib/net.properties. > >>> Assuming that they can/should be applied in the same manner as the > >>> properties from before, but I > >>> appear to be having the same issue where it is not being applied. > >>> > >>> ie: > >>> [chlee at pc-atlas-cr-35 .icedtea]$ javaws -verbose > >>> -J-Dhttp.proxy.Host=atlasgw-exp.cern.ch > >>> -J-Dhttp.proxyPort=3128 > >>> http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp > >>> Loading User level properties from: > >>> /atlas-home/1/chlee/.icedtea/deployment.properties > >>> Starting security dialog thread > >>> Using firefox's profiles file: > >>> /atlas-home/1/chlee/.mozilla/firefox/profiles.ini > >>> Found preferences file: > >>> /atlas-home/1/chlee/.mozilla/firefox/4mi0hwbe.default/prefs.js > >>> Read 77 entries from Firefox's preferences > >>> JNLP file location: http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp > >>> call privileged method: getCodeBase > >>> result: null > >>> Status: CONNECT STARTED +(CONNECT STARTED) @ /dipbrowser/launch.jnlp > >>> Status: CONNECT DOWNLOAD STARTED +(DOWNLOAD) @ /dipbrowser/launch.jnlp > >>> Status: CONNECTING DOWNLOAD STARTED +(CONNECTING) -(CONNECT) @ > >>> /dipbrowser/launch.jnlp > >>> All possible urls for > >>> location=http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp > >>> state=CONNECTING DOWNLOAD STARTED : > >>> [http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp, > >>> http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp] > >>> Selecting proxy for: http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp > >>> Browser proxy option "4" (Automatic) not supported yet. > >>> Browser selected proxies: [DIRECT] > >>> Selected proxies: [DIRECT] > >>> Selecting proxy for: socket://dipbrowser.web.cern.ch:80 > >>> Browser proxy option "4" (Automatic) not supported yet. > >>> Browser selected proxies: [DIRECT] > >>> Selected proxies: [DIRECT] > >>>> > >>>>>> 1.4.1 is outdated. If you need for some reason to stay with 1.4, > >>>>>> please update to 1.4.2, > >>>>>> however - please swap to 1.5. It was released few month ago, is > >>>>>> stable, and a a lot of fixes > >>>>>> was fixed here. > >>>>> > >>>>> This installation is for the ATLAS experiment at CERN. For security > >>>>> reason, we are usually > >>>>> compelled to use what is available in the SLC repos, which > >>>>> unfortunately for me right now is 1.4.1 > >>>> > >>>> If security is key to you, you shouldn't probably be using IcedTea-Web > >>>> yet. Instead, resort to > >>>> Oracle's Java Web Start implementation. This product is feature and > >>>> specification complete, in > >>>> contrast to IcedTea-Web. Java Web Start has most probably received far > >>>> more security fixes and > >>>> screening than IcedTea-Web. Personally, at the current stage of > >>>> IcedTea-Web I would advise any > >>>> enterprise or security aware user not to use IcedTea-Web. > >>> I believe we had a number of issues with the Oracles Javaws. somethings > >>> like the latest updates > >>> forced us to keep things current all the time, and while we are in > >>> production runs, things can be > >>> locked down for months at a time or we could lose data taking at our > >>> experiment. > >>> Right now this is me testing to see if I can get this to work > >>> > >> Chris, Just to completeness, may you try the -Xnofork together with your > >> Experiments? > >> > >> Anyway it sounds like bug. I will look into it. > >> > > > > Well this is bug. As it is done in ITW, the proxy* settings are loaded > > from configurations before > > the value of -property is merged. > > > > But it do not explain why even the -J-Ddeployment.blah is not working. //me > > must find what > > specification says > > > > Looking inisde > > > > as it was: > > the ITW properties are loaded form file > > + they are mixed into system properties > > proxy is selected > > launcher object is created > > "-property" argument's values are merged into JNLPresources > > and later ... I'mnot sure if they are even later merged into properties > > > > It is clear that original NETX wanted to keep the -property's params as > > isolated per jnlpfile > > > > > > After attached patch > > the ITW properties are loaded form file > > + they are mixed into system properties > > "-property" argument's values are merged into ITW properties (so not into > > system properties) > > proxy is selected > > launcher object is created > > "-property" argument's values are still merged into JNLPresources > > > > So now the config singleton have the -property(s) shared. Also set on > > jnlpconfig value will not > > change the value in per-jnlpresource > > > > > > I believe that this can be correct as > > - javaws have always isolated JVM > > - applets, with shared JVM, have always same -property(s) set via > > itwsettings (command-line args) > > > > Well my fix can probably go into 1.4 and 1.5, but for head the properties > > should be revisited one > > more times. Maybe also -D and -J-D should be handled differently. > > Are actually -J working with forked JVM? By check on code.. not > > > > The patch contains small refactoring to not duplicate code. The test is > > attached likewise. > > > > > > Chis, are you able to build patched RPMs? > > > > J. > > > > > > > > > > > > > > > ping? Security thoughts? Hello, Looking at the code, it seems reasonable. Only nit would be to fix the typos;; In terms of security: What this patch does is take user-supplied properties: ./javaws -property name=value -jnlp jnlpFile.jnlp property: name, value: value and apply them into JNLPRuntime's configuration, yes? From this view, I don't know if there is a security issue since it's the user setting the property and not the applet. As long as applets can't set these properties, it should be okay... What kind of things are you worried about? I am no expert here :\ Regards, > > J. > -- Jie Kang From jvanek at redhat.com Mon Nov 10 14:02:11 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 10 Nov 2014 15:02:11 +0100 Subject: [rfc][icedtea-web] Preparing PolicyEditor for future full policyfile featureset In-Reply-To: <545CE042.6080407@redhat.com> References: <5457CC4E.5020701@redhat.com> <545CD340.8090600@redhat.com> <545CE042.6080407@redhat.com> Message-ID: <5460C563.70207@redhat.com> On 11/07/2014 04:07 PM, Andrew Azores wrote: > On 11/07/2014 09:12 AM, Jiri Vanek wrote: >> On 11/03/2014 07:41 PM, Andrew Azores wrote: >>> Hi, >>> >>> PolicyEditor is currently not a viable total replacement for the >>> existing JDK policytool for a few >>> reasons. >> >> Form quick look to code, changeset looks ok, but I'm quite wondering >> aout final goal. ... >>> >>> 1) Only supports CodeBase, not SignedBy and Principal >>> 2) No KeyStore entry support >>> 3) Parser is not a real parser >>> 4) CustomPolicyViewer is a little underpowered >>> >>> Once these issues are all resolved, then I think it would be fair for >>> us to push using PolicyEditor >>> alone, and remove the button from itweb-settings which launches >>> policytool as the "Advanced editor". >> >> And - do we wont to do so? Yes, maybe policy tool will be removed, then >> we will be forced. But still - is good idea to rape this beautifully >> simple app - especially when used from "tmp permissions" button. >>> >>> This patch is aimed at working on #1 and #2. It adds a few more simple >>> data structures (KeystoreInfo >>> and PolicyIdentifier) so that, once a proper parser exists, a >>> full-featured policy file can be fully >>> modelled with PolicyEditor's structures. KeystoreInfo is currently >>> completely unused, and >>> PolicyIdentifier is used only for its codebase attribute, so there are >>> no behavioural changes after >>> this patch is applied. All unit tests should come up with the same >>> results (and the only unit test >>> changes made are refactoring for builder pattern) and manual testing >>> should work exactly the same as >>> well. >>> >>> Since PolicyEntries now have many more attributes, its constructor has >>> been made private and >>> PolicyEntry is now constructed with a Builder. Changing each of the >>> existing unit test cases dealing >>> with PolicyEntry to use the builder introduced some unfortunate noise >>> to this patch. >>> >>> Missing with this changeset are any changes to PolicyFileModel so that >>> these new attributes might be >>> written to file if (somehow) present. Since there is no UI to modify >>> these attributes and no parser >>> to read them from files, for now it will have to be done simply with >>> mock data and performed only in >>> unit tests. I'd like to add this as a separate changeset simply >>> because of the limited and highly >>> variable amounts of time I have to commit to this at the moment. >>> >> >> On contrary - there always was an question - what policyeditor do when >> it finds one of many unsupported parts of policy files. The only >> solution is what you suggest - to support them. But Any full supporting >> will lead to nasty PociyTool_II :( >> >> So before actually doing any code change, i would probably like to >> discuse final usecases, final gui, and final reactions to some cases. >> >> Some advance mode? Blah :( <me to stupid even for gui design> :( >> Completely reworked gui to support "everything" in really simple way? >> Some jtree with checkboxes and popupmenus? Maybe levels of advancenes? >> I'mnot sure if such editor is in scope of ITW. >> >> >> J. >> > here you go: http://icedtea.classpath.org/wiki/IcedTea-Web#IcedTea-Web_1.6 > Fair enough. I'd still like for PolicyEditor to be able to support these policy file features in the back end at least. "these" ? Are there some more of them? (X) How will our current gui behave, when "backend supported" features are detected? What if user changes somehting. How will "backend only" fields persisted? > Even if the GUI it exposes doesn't have any controls to view or modify these things, it feels broken to make a tool for editing policy files and have it actually be able to handle only some (arbitrary) subset of policy file syntax. That unquestionable. > > policytool also still frankly isn't very nice to use, hehe :)) You are to kind to it :)) > and I think after giving PolicyEditor a nice back end with full policy file support, it wouldn't be *too* much work to create another Another sounds to me like advanced mode. Which actually adds more question marks to (X) > front end on top of it to replace policytool, although this also would be made easier if more work is put in to refactoring what we have now into proper MVC (which I'm also willing to work on, slowly). Having both PolicyEditor and policytool2, both using the same back end, sounds pretty nice to me... maybe policytool2 and the back end could even be upstreamed and the nice, simple PolicyEditor GUI kept local to ITW, one day. Thats once day in far far future :) thank you for looking into it! J. ---------code Keystore equals and hascode They looks pretty much autogenerated. The readability of equals is very poor. May you rewrite it at least without ?: operator? Hascode - have it actually sense as it is written now? Maybe just store initial string and return its hash? + public static class PolicyEntryBuilder { I think it deserve seaprate file. Also - from quick wiew, it is not clear its purpose. So maybe some javadoc? +public class PolicyIdentifier { I really ahte those genrated equals and hashcode. Well the PolicyIdentifier is ismpel enough to be kept like this. Maybe onnly - again - equals without ternary? Otherwise the classes to support backend have their senses. ty! J. From jvanek at redhat.com Mon Nov 10 14:45:23 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 10 Nov 2014 15:45:23 +0100 Subject: [rfc][icedtea-web] 1.5.2 release? In-Reply-To: <545B3A67.9020509@redhat.com> References: <544A4C3A.6010507@redhat.com> <544BBF23.5010307@redhat.com> <5458FCF0.3060504@redhat.com> <545A5C12.1000408@redhat.com> <545A5CD2.70707@redhat.com> <545A5D97.803@redhat.com> <1599683181.4258978.1415222751770.JavaMail.zimbra@redhat.com> <545B3A67.9020509@redhat.com> Message-ID: <5460CF83.2080509@redhat.com> On 11/06/2014 10:07 AM, Jiri Vanek wrote: > On 11/05/2014 10:25 PM, Lukasz Dracz wrote: >> Hello, >> >> I don't think there is a point to backporting http://icedtea.classpath.org/hg/icedtea-web/rev/d8e057783109 >> since I would probably need to backport also: http://icedtea.classpath.org/hg/icedtea-web/rev/e30d71ab91c6 which was the refactor of the cache panel. >> I can do that if you still think it would be worthwhile to be backported. >> All it adds was a tooltip for the spinner, and 1.5 still uses the slider. I could add a tooltip for the slider I guess but they are somewhat different so the Messages would be different. >> > > Fair enough. Then do not backport it. ty fir check! > >> Sorry for missing the IRC chat I was in a thermostat scrum, then went to lunch without noticing. >> I can do the PL translations, my PL should be good enough if needed. I speak it regularly at home, and attended Polish Saturday School here in Canada from elementary to high school. I do have a good understanding of Polish though I must admit my writing is a little bit rusty with all the Polish grammar rules but I can look stuff up if I am unsure :) >> What do we want translated specifically ? >> >> I translated the two parts from Andrew's patch in the messages.properties >> >> CertWarnHTTPSAcceptTip=Zaakceptuj ten certyfikat i zaufaj po??czenie przez HTTPS >> (Accept this certificate and trust a connection via HTTPS) >> >> CertWarnHTTPSRejectTip=Nie akceptuj ten certyfikat i nie buduj po??czenie HTTPS >> (Do not Accept this certificate and do not build a HTTPS connection) >> Establish looked/sounded odd to me so I thought build was more natural. >> > > Great! ty! This is all :) > > Once Andrew pushes his backport, please push thsoe two lines. > (ps: go on wiht transaltor :) >> I have attached the translation, is there anywhere else that needs editing or translating ? >> >> Thank you, >> Lukasz Dracz >> >> >> >> ----- Original Message ----- >>> From: "Andrew Azores" <aazores at redhat.com> >>> To: "Jiri Vanek" <jvanek at redhat.com>, "IcedTea Distro List" <distro-pkg-dev at openjdk.java.net>, "Lukasz Dracz" >>> <ldracz at redhat.com> >>> Sent: Wednesday, November 5, 2014 12:25:43 PM >>> Subject: Re: [rfc][icedtea-web] 1.5.2 release? >>> >>> On 11/05/2014 12:22 PM, Jiri Vanek wrote: >>>> On 11/05/2014 06:19 PM, Andrew Azores wrote: >>>>> On 11/04/2014 11:21 AM, Jiri Vanek wrote: >>>>>> On 10/25/2014 05:17 PM, Andrew Azores wrote: >>>>>>> On 10/24/2014 08:55 AM, Jiri Vanek wrote: >>>>>>>> Hi! >>>>>>>> >>>>>>>> There appeared few fixes in head which are maybe worthy to go to >>>>>>>> 1.5 and >>>>>>>> afterward calling for release: >>>>>>>> >>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/99d5407fab4a >>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/dd6be5e03667 >>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/df05d1de5af4 >>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/c6af2f50a95e >>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/6d62f68fb037 >>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/d8e057783109 >>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/90faf53bb981 >>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/2979fa371add >>>>>>>> >>>>>>>> >>>>>>>> Thoughts? >>>>>>>> >>>>>>>> J. >>>>>>> >>>>>>> Sounds like a good plan to me. >>>>>>> >>>>>>> Thanks, >>>>>> Hi! I have backported most of them today, except two. >>>>>> "2" is Andrew's and "3" Lukas' >>>>>> >>>>>> "4" is mine, but it is(?) already backported. >>>>>> >>>>>> Guys, please decide whether yours 2 and/or 3 should go to 1.5. If so, >>>>>> please backport. After doing so, and once i got confirmed RH115417 >>>>>> 7, I will try to do a release. >>>>>> >>>>>> >>>>>> TY! >>>>>> >>>>>> J. >>>>> >>>>> Attached is the fixed backport for #2. >>>>> >>>>> Thanks, >>>>> -- >>>>> Andrew Azores >>>>> >>>>> temporary-permissions-button-npe-fix-backport.patch >>>>> >>>>> >>>>> diff --git a/ChangeLog b/ChangeLog >>>>> --- a/ChangeLog >>>>> +++ b/ChangeLog >>>>> @@ -1,3 +1,18 @@ >>>>> +2014-11-05 Andrew Azores<aazores at redhat.com> >>>>> + >>>>> + * netx/net/sourceforge/jnlp/resources/Messages.properties >>>>> + (CertWarnHTTPSAcceptTip, CertWarnHTTPSRejectTip): new messages more >>>>> + applicable for HTTPS cert warning dialogs >>>>> + * netx/net/sourceforge/jnlp/security/dialogs/CertWarningPane.java: >>>>> + distinguish between HTTPS cert warnings and signed applet cert >>>>> warnings. >>>>> + Display appropriate text labels and buttons corresponding to >>>>> either case. >>>>> + * >>>>> netx/net/sourceforge/jnlp/security/dialogs/TemporaryPermissionsButton.java: >>>>> >>>>> + If any of file, securityDelegate, or linkedButton are null, simply >>>>> + disable this component and do not add component listeners >>>>> dependent upon >>>>> + these fields. Also, do not add multiple groups of permissions, >>>>> and do not >>>>> + add the permissions to the securityDelegate until the >>>>> linkedButton is >>>>> + actually clicked (rather than when the menu item is clicked) >>>>> + >>>>> 2014-10-21 Jiri Vanek<jvanek at redhat.com> >>>>> >>>>> Fixed case when already decoded file is wonted from cache >>>>> (RH1154177) >>>>> diff --git a/netx/net/sourceforge/jnlp/resources/Messages.properties >>>>> b/netx/net/sourceforge/jnlp/resources/Messages.properties >>>>> --- a/netx/net/sourceforge/jnlp/resources/Messages.properties >>>>> +++ b/netx/net/sourceforge/jnlp/resources/Messages.properties >>>>> @@ -25,6 +25,8 @@ >>>>> CertWarnCancelTip=Do not run this applet >>>>> CertWarnPolicyTip=Advanced sandbox settings >>>>> CertWarnPolicyEditorItem=Launch PolicyEditor >>>>> +CertWarnHTTPSAcceptTip=Accept this certificate and trust the HTTPS >>>>> connection >>>>> +CertWarnHTTPSRejectTip=Do not accept this certificate and do not >>>>> establish the HTTPS connection >>>>> >>>> >>>> >>>> Hmm. What to do with those two messages? I can supply CZ trasnaltion, >>>> maybe also DE (with help of Severin, Roman or similar :) ) How about >>>> PL? I rembere There was somebody in your surrounding. Wasnt? >>>> >>>> By otherwise - you agree it is ok for 1.5 thsi backport oook? >>>> >>>> Ty! >>>> >>>> J. >>>> >>> >>> Yup, otherwise the backport looks/sounds fine to me. >>> >>> I do know someone from school who might be able to provide PL >>> translations still. But... what about ldracz? ;) probably easier than >>> pulling in some other "volunteer". >>> >>> Thanks, >>> -- >>> Andrew Azores >>> > So on my side ITW 1.5.2 loosk good. I'm still a bit hesitating with waiting to two more fixes: - the [rfc][icedtea-web] merge property arguments into config singleton - and Re: [rfc][icedtea-web] Fix to PluginMessage dates for PR2063 Especially the second one should be harmless and is bit nasty to be presented. thoughts? From jvanek at redhat.com Mon Nov 10 14:47:37 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 10 Nov 2014 15:47:37 +0100 Subject: [icedtea-web] broken(?) downlaod servcice Message-ID: <5460D009.1090708@redhat.com> hi! During 1.5.2 testing I found Passed: DownloadServiceTest.testRepeatedlyLoadingAndUnloadingJnlpResources FAILED: testExtensioncheckCachesUsingArray(DownloadServiceTest) stdout should contain "CHECKEXTENSIONCACHEUSINGMUTIPLEPARTS-isExtensionPartCached(Array): ValidExtensionParts: true" but did not. FAILED: testLoadExtensionPartUsingArray(DownloadServiceTest) stdout should contain "LOADEXTENSIONUSINGVALIDPARTINARRAY-loadExtensionPart(Array): ValidExtensionParts-AFTER: true" but did not. Passed: DownloadServiceTest.checkIfRequiredResourcesExist Passed: DownloadServiceTest.testRepeatedlyLoadingAndUnloadingExternalResources Passed: DownloadServiceTest.testRemoveExternalResource FAILED: testRemoveExtensionPart(DownloadServiceTest) stdout should contain "REMOVEEXTENSIONPART-removeExtensionPart: ExtensionPartOne-BEFORE: true" but did not. FAILED: testExtensioncheckCaches(DownloadServiceTest) stdout should contain "CHECKEXTENSIONCACHE-isExtensionPartCached: ExtensionPartOne: true" but did not. Passed: DownloadServiceTest.testRemovePart FAILED: testLoadExtensionPart(DownloadServiceTest) stdout should contain "LOADEXTENSIONPART-loadExtensionPart: ExtensionPartOne-AFTER: true" but did not. FAILED: testRemoveExtensionPartUsingArray(Download Whcih seems to be never working in 1.5, adn in head was working prior this group of changesets[1] < changeset: 838:956b6bd1b23e < tag: tip < user: Andrew Azores <aazores at redhat.com> < date: Thu Nov 14 13:15:46 2013 -0500 < summary: Move "dialog center" line in NEWS to be consistent with NEWS in 1.4 < < changeset: 837:db2624a28263 < user: Andrew Azores <aazores at redhat.com> < date: Thu Nov 14 11:22:14 2013 -0500 < summary: Added "dialogs center on-screen before appearing" to NEWS < < changeset: 836:0ceee01764a1 < user: Jiri Vanek <jvanek at redhat.com> < date: Thu Nov 14 10:57:24 2013 +0100 < summary: Fixed NPE in getting the attribute < < changeset: 835:a9e1b9e256cf < user: Andrew Azores <aazores at redhat.com> < date: Wed Nov 13 10:12:28 2013 -0500 < summary: JNLPClassLoader cleanup, avoid Enumerations and use strict typing. < < changeset: 834:c5e882e0b7f6 < user: Andrew Azores <aazores at redhat.com> < date: Wed Nov 13 09:55:45 2013 -0500 < summary: BasicExceptionDialog centers on-screen before appearing Strange isnt it? Ayway in head this is regression. Befor 1.6 tehre seesm ot be much more things like this:( J. [1]http://tyr.brq.redhat.com/icedtea-web-dailyreport/ICWDR_1384833512/index.html From jvanek at redhat.com Mon Nov 10 14:55:09 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 10 Nov 2014 15:55:09 +0100 Subject: [rfc][icedtea-web] merge property arguments into config singleton (was Re: javaws CLI with Icedtea-web) In-Reply-To: <1020878052.5351286.1415375610115.JavaMail.zimbra@redhat.com> References: <53B2CC4F.3080501@redhat.com> <5448DEB0.1040508@redhat.com> <545CCEE0.8020509@redhat.com> <1020878052.5351286.1415375610115.JavaMail.zimbra@redhat.com> Message-ID: <5460D1CD.2020701@redhat.com> On 11/07/2014 04:53 PM, Jie Kang wrote: > > > ----- Original Message ----- >> On 10/23/2014 12:55 PM, Jiri Vanek wrote: >>> >>> >>> >>> -------- Forwarded Message -------- >>> Subject: Re: javaws CLI with Icedtea-web >>> Date: Tue, 01 Jul 2014 16:57:19 +0200 >>> From: Jiri Vanek <jvanek at redhat.com> >>> To: distro-pkg-dev at openjdk.java.net, Omair Majid <omajid at redhat.com> >>> >>> On 07/01/2014 01:32 PM, Jiri Vanek wrote: >>>> On 06/30/2014 05:41 PM, Chris Lee wrote: >>>>> Hi Jacob, >>>>> On Jun 30, 2014, at 5:23 PM, Jacob Wisor wrote: >>>>> >>>>>> On 06/30/2014 04:39 PM, Chris Lee wrote: >>>>>>> Hi Jiri >>>>>>> >>>>>>> Thanks so much >>>>>>> >>>>>>> To explain as well, what I am trying to do is use a specific proxy >>>>>>> server and port for a >>>>>>> specific website. >>>>>>> I had thought that a link to the CLI might be the quickest if I can get >>>>>>> it working, If there is >>>>>>> an easier way to configure, then I am open to suggestions. >>>>>> >>>>>> Try using Java's network configuration properties like http.proxyHost, >>>>>> http.proxyPort, >>>>>> https.proxyHost, https.proxyPort, ftp.proxyHost, ftp.proxyPort, >>>>>> gopher.proxyHost, >>>>>> gopher.proxyPort, socksProxyHost, socksProxyPort with the -J-D switch. >>>>>> For more information have >>>>>> a look into >>>>>> <JRE_HOME>/lib/net.properties. >>>>> Assuming that they can/should be applied in the same manner as the >>>>> properties from before, but I >>>>> appear to be having the same issue where it is not being applied. >>>>> >>>>> ie: >>>>> [chlee at pc-atlas-cr-35 .icedtea]$ javaws -verbose >>>>> -J-Dhttp.proxy.Host=atlasgw-exp.cern.ch >>>>> -J-Dhttp.proxyPort=3128 >>>>> http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp >>>>> Loading User level properties from: >>>>> /atlas-home/1/chlee/.icedtea/deployment.properties >>>>> Starting security dialog thread >>>>> Using firefox's profiles file: >>>>> /atlas-home/1/chlee/.mozilla/firefox/profiles.ini >>>>> Found preferences file: >>>>> /atlas-home/1/chlee/.mozilla/firefox/4mi0hwbe.default/prefs.js >>>>> Read 77 entries from Firefox's preferences >>>>> JNLP file location: http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp >>>>> call privileged method: getCodeBase >>>>> result: null >>>>> Status: CONNECT STARTED +(CONNECT STARTED) @ /dipbrowser/launch.jnlp >>>>> Status: CONNECT DOWNLOAD STARTED +(DOWNLOAD) @ /dipbrowser/launch.jnlp >>>>> Status: CONNECTING DOWNLOAD STARTED +(CONNECTING) -(CONNECT) @ >>>>> /dipbrowser/launch.jnlp >>>>> All possible urls for >>>>> location=http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp >>>>> state=CONNECTING DOWNLOAD STARTED : >>>>> [http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp, >>>>> http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp] >>>>> Selecting proxy for: http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp >>>>> Browser proxy option "4" (Automatic) not supported yet. >>>>> Browser selected proxies: [DIRECT] >>>>> Selected proxies: [DIRECT] >>>>> Selecting proxy for: socket://dipbrowser.web.cern.ch:80 >>>>> Browser proxy option "4" (Automatic) not supported yet. >>>>> Browser selected proxies: [DIRECT] >>>>> Selected proxies: [DIRECT] >>>>>> >>>>>>>> 1.4.1 is outdated. If you need for some reason to stay with 1.4, >>>>>>>> please update to 1.4.2, >>>>>>>> however - please swap to 1.5. It was released few month ago, is >>>>>>>> stable, and a a lot of fixes >>>>>>>> was fixed here. >>>>>>> >>>>>>> This installation is for the ATLAS experiment at CERN. For security >>>>>>> reason, we are usually >>>>>>> compelled to use what is available in the SLC repos, which >>>>>>> unfortunately for me right now is 1.4.1 >>>>>> >>>>>> If security is key to you, you shouldn't probably be using IcedTea-Web >>>>>> yet. Instead, resort to >>>>>> Oracle's Java Web Start implementation. This product is feature and >>>>>> specification complete, in >>>>>> contrast to IcedTea-Web. Java Web Start has most probably received far >>>>>> more security fixes and >>>>>> screening than IcedTea-Web. Personally, at the current stage of >>>>>> IcedTea-Web I would advise any >>>>>> enterprise or security aware user not to use IcedTea-Web. >>>>> I believe we had a number of issues with the Oracles Javaws. somethings >>>>> like the latest updates >>>>> forced us to keep things current all the time, and while we are in >>>>> production runs, things can be >>>>> locked down for months at a time or we could lose data taking at our >>>>> experiment. >>>>> Right now this is me testing to see if I can get this to work >>>>> >>>> Chris, Just to completeness, may you try the -Xnofork together with your >>>> Experiments? >>>> >>>> Anyway it sounds like bug. I will look into it. >>>> >>> >>> Well this is bug. As it is done in ITW, the proxy* settings are loaded >>> from configurations before >>> the value of -property is merged. >>> >>> But it do not explain why even the -J-Ddeployment.blah is not working. //me >>> must find what >>> specification says >>> >>> Looking inisde >>> >>> as it was: >>> the ITW properties are loaded form file >>> + they are mixed into system properties >>> proxy is selected >>> launcher object is created >>> "-property" argument's values are merged into JNLPresources >>> and later ... I'mnot sure if they are even later merged into properties >>> >>> It is clear that original NETX wanted to keep the -property's params as >>> isolated per jnlpfile >>> >>> >>> After attached patch >>> the ITW properties are loaded form file >>> + they are mixed into system properties >>> "-property" argument's values are merged into ITW properties (so not into >>> system properties) >>> proxy is selected >>> launcher object is created >>> "-property" argument's values are still merged into JNLPresources >>> >>> So now the config singleton have the -property(s) shared. Also set on >>> jnlpconfig value will not >>> change the value in per-jnlpresource >>> >>> >>> I believe that this can be correct as >>> - javaws have always isolated JVM >>> - applets, with shared JVM, have always same -property(s) set via >>> itwsettings (command-line args) >>> >>> Well my fix can probably go into 1.4 and 1.5, but for head the properties >>> should be revisited one >>> more times. Maybe also -D and -J-D should be handled differently. >>> Are actually -J working with forked JVM? By check on code.. not >>> >>> The patch contains small refactoring to not duplicate code. The test is >>> attached likewise. >>> >>> >>> Chis, are you able to build patched RPMs? >>> >>> J. >>> >>> >>> >>> >>> >>> >>> >> ping? Security thoughts? > > Hello, > > > Looking at the code, it seems reasonable. Only nit would be to fix the typos;; > > In terms of security: > > What this patch does is take user-supplied properties: > > ./javaws -property name=value -jnlp jnlpFile.jnlp > > property: name, value: value and apply them into JNLPRuntime's configuration, yes? From this view, I don't know if there is a security issue since it's the user setting the property and not the applet. As long as applets can't set these properties, it should be okay... Thats quite good and nice point :)) > > What kind of things are you worried about? I am no expert here :\ I dont know. Unluckily the world of various merged properties is so.. strange that I doubt there is any expert arround :(( Escpecially not me. I have somehow strange feelings about htis changeset. Maybe better palce where to put it? Maybe some security check? Tahx for check! J. > > > Regards, > >> >> J. >> > From jkang at redhat.com Mon Nov 10 20:09:23 2014 From: jkang at redhat.com (Jie Kang) Date: Mon, 10 Nov 2014 15:09:23 -0500 (EST) Subject: [rfc][icedtea-web] Download Resource Unit Test for ResourceTracker In-Reply-To: <259519386.6213490.1415650092289.JavaMail.zimbra@redhat.com> Message-ID: <1431325567.6214144.1415650163295.JavaMail.zimbra@redhat.com> Hello, This patch adds a simple test to cover ResourceTracker's ability to download a file into the cache system. How does it look? Regards, -- Jie Kang -------------- next part -------------- A non-text attachment was scrubbed... Name: itw-rt-download-test-1.patch Type: text/x-patch Size: 5145 bytes Desc: not available URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141110/d28dc46d/itw-rt-download-test-1.patch> From jkang at redhat.com Wed Nov 12 16:34:11 2014 From: jkang at redhat.com (Jie Kang) Date: Wed, 12 Nov 2014 11:34:11 -0500 (EST) Subject: [rfc][icedtea-web] Added reproducer for pack-gz applets In-Reply-To: <545CC4E1.1070902@redhat.com> References: <1322607003.4907449.1415304269808.JavaMail.zimbra@redhat.com> <545CC4E1.1070902@redhat.com> Message-ID: <455075320.7235939.1415810051444.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 11/06/2014 09:04 PM, Jie Kang wrote: > > Hello, > > > > This patch adds a reproducer to test for pack-gz applets in the three > > scenarios: > > > > Browser - JNLP href (file) > > Browser - Applet tags > > Javaws - JNLP file > > > > > > In order to pass these tests, modifications have been made to: > > > > 1. The test server implementation (TinyHttpdImpl) to take into account > > Accept-Encoding requests and serve the correct jar files. > > > > 2. The PluginBridge to take into account the jnlp parameters for using > > packaging or versioning in order to allow the Browser - JNLP situation to > > work. > > > > All of this is in respect to the guidelines found here: > > > > http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/tools/pack200.html > > > > Thoughts? > > > > > > Cheers, > > > > This is moreover excelent work, ty! > > few nits > - "doNotRunInOpera" Whyyyyyy? Hello, Removed. Was from the reproducer I copied off of and edited. > - acceptEncoding again -why? Removed (from discussion on IRC). > - +PACKER=pack200 > you should nto be lazy and use (BOOT_DIR)/bin/pack200 > - is it onot in boot dir? Configure check? ..checking for pack200 ...found > and then > PACKER=(PACK200).Not fund - warn that "reproducer blah balh will fail" - > because if build of > reproducer fail, the suite continu > - I know that this is abit stric but may save hours later. Added. > > > One though - looking to the changes in server and why it is cusotm one > - why not to move th elogic to serverimpl ? If (pack).gz is the requested > file, then return result > of runtome compression of this resource ? Changes to tinyhttpdimpl removed. How does it look now? Regards, > > > > J. > -- Jie Kang -------------- next part -------------- A non-text attachment was scrubbed... Name: itw-packgz-reproducer-3.patch Type: text/x-patch Size: 14209 bytes Desc: not available URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141112/977ea03a/itw-packgz-reproducer-3-0001.patch> From jkang at redhat.com Wed Nov 12 21:25:45 2014 From: jkang at redhat.com (Jie Kang) Date: Wed, 12 Nov 2014 16:25:45 -0500 (EST) Subject: [rfc][icedtea-web] AccessClassInPackage Reproducer Failure In-Reply-To: <1565858626.7381043.1415822396917.JavaMail.zimbra@redhat.com> Message-ID: <718500686.7415092.1415827545074.JavaMail.zimbra@redhat.com> Hello, I have been running a lot of reproducers lately and some consistent failures caught my eye today. In the AccessClassInPackage reproducers, a number of asserts are made including the following two: Assert.assertFalse("AccessClassInPackageTestLunch1 should not be terminated, but was", pr.wasTerminated); Assert.assertEquals((Integer) 0, pr.returnValue); The tests all fail due to these two asserts (wasTerminated is always true, not false, and return value is always 130 (exit due to control-C? [1]), not 0). When removing these lines and checking the tests, they all work and pass. The Class.forName call succeeds and is printed to stdout. So I am wondering, what are these two lines for? Is there some regression causing these failures? P.S. patch attached is for easy reference to code I am talking about above; not an actual patch (though we may want to apply a similar patch) [1] http://tldp.org/LDP/abs/html/exitcodes.html Regards, -- Jie Kang -------------- next part -------------- A non-text attachment was scrubbed... Name: itw-accessclass-reproducer-1.patch Type: text/x-patch Size: 1678 bytes Desc: not available URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141112/de1c145d/itw-accessclass-reproducer-1.patch> From jkang at redhat.com Wed Nov 12 21:46:50 2014 From: jkang at redhat.com (Jie Kang) Date: Wed, 12 Nov 2014 16:46:50 -0500 (EST) Subject: [rfc][icedtea-web] merge property arguments into config singleton (was Re: javaws CLI with Icedtea-web) In-Reply-To: <5460D1CD.2020701@redhat.com> References: <53B2CC4F.3080501@redhat.com> <5448DEB0.1040508@redhat.com> <545CCEE0.8020509@redhat.com> <1020878052.5351286.1415375610115.JavaMail.zimbra@redhat.com> <5460D1CD.2020701@redhat.com> Message-ID: <2048952498.7424549.1415828810409.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 11/07/2014 04:53 PM, Jie Kang wrote: > > > > > > ----- Original Message ----- > >> On 10/23/2014 12:55 PM, Jiri Vanek wrote: > >>> > >>> > >>> > >>> -------- Forwarded Message -------- > >>> Subject: Re: javaws CLI with Icedtea-web > >>> Date: Tue, 01 Jul 2014 16:57:19 +0200 > >>> From: Jiri Vanek <jvanek at redhat.com> > >>> To: distro-pkg-dev at openjdk.java.net, Omair Majid <omajid at redhat.com> > >>> > >>> On 07/01/2014 01:32 PM, Jiri Vanek wrote: > >>>> On 06/30/2014 05:41 PM, Chris Lee wrote: > >>>>> Hi Jacob, > >>>>> On Jun 30, 2014, at 5:23 PM, Jacob Wisor wrote: > >>>>> > >>>>>> On 06/30/2014 04:39 PM, Chris Lee wrote: > >>>>>>> Hi Jiri > >>>>>>> > >>>>>>> Thanks so much > >>>>>>> > >>>>>>> To explain as well, what I am trying to do is use a specific proxy > >>>>>>> server and port for a > >>>>>>> specific website. > >>>>>>> I had thought that a link to the CLI might be the quickest if I can > >>>>>>> get > >>>>>>> it working, If there is > >>>>>>> an easier way to configure, then I am open to suggestions. > >>>>>> > >>>>>> Try using Java's network configuration properties like http.proxyHost, > >>>>>> http.proxyPort, > >>>>>> https.proxyHost, https.proxyPort, ftp.proxyHost, ftp.proxyPort, > >>>>>> gopher.proxyHost, > >>>>>> gopher.proxyPort, socksProxyHost, socksProxyPort with the -J-D switch. > >>>>>> For more information have > >>>>>> a look into > >>>>>> <JRE_HOME>/lib/net.properties. > >>>>> Assuming that they can/should be applied in the same manner as the > >>>>> properties from before, but I > >>>>> appear to be having the same issue where it is not being applied. > >>>>> > >>>>> ie: > >>>>> [chlee at pc-atlas-cr-35 .icedtea]$ javaws -verbose > >>>>> -J-Dhttp.proxy.Host=atlasgw-exp.cern.ch > >>>>> -J-Dhttp.proxyPort=3128 > >>>>> http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp > >>>>> Loading User level properties from: > >>>>> /atlas-home/1/chlee/.icedtea/deployment.properties > >>>>> Starting security dialog thread > >>>>> Using firefox's profiles file: > >>>>> /atlas-home/1/chlee/.mozilla/firefox/profiles.ini > >>>>> Found preferences file: > >>>>> /atlas-home/1/chlee/.mozilla/firefox/4mi0hwbe.default/prefs.js > >>>>> Read 77 entries from Firefox's preferences > >>>>> JNLP file location: > >>>>> http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp > >>>>> call privileged method: getCodeBase > >>>>> result: null > >>>>> Status: CONNECT STARTED +(CONNECT STARTED) @ /dipbrowser/launch.jnlp > >>>>> Status: CONNECT DOWNLOAD STARTED +(DOWNLOAD) @ /dipbrowser/launch.jnlp > >>>>> Status: CONNECTING DOWNLOAD STARTED +(CONNECTING) -(CONNECT) @ > >>>>> /dipbrowser/launch.jnlp > >>>>> All possible urls for > >>>>> location=http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp > >>>>> state=CONNECTING DOWNLOAD STARTED : > >>>>> [http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp, > >>>>> http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp] > >>>>> Selecting proxy for: > >>>>> http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp > >>>>> Browser proxy option "4" (Automatic) not supported yet. > >>>>> Browser selected proxies: [DIRECT] > >>>>> Selected proxies: [DIRECT] > >>>>> Selecting proxy for: socket://dipbrowser.web.cern.ch:80 > >>>>> Browser proxy option "4" (Automatic) not supported yet. > >>>>> Browser selected proxies: [DIRECT] > >>>>> Selected proxies: [DIRECT] > >>>>>> > >>>>>>>> 1.4.1 is outdated. If you need for some reason to stay with 1.4, > >>>>>>>> please update to 1.4.2, > >>>>>>>> however - please swap to 1.5. It was released few month ago, is > >>>>>>>> stable, and a a lot of fixes > >>>>>>>> was fixed here. > >>>>>>> > >>>>>>> This installation is for the ATLAS experiment at CERN. For security > >>>>>>> reason, we are usually > >>>>>>> compelled to use what is available in the SLC repos, which > >>>>>>> unfortunately for me right now is 1.4.1 > >>>>>> > >>>>>> If security is key to you, you shouldn't probably be using IcedTea-Web > >>>>>> yet. Instead, resort to > >>>>>> Oracle's Java Web Start implementation. This product is feature and > >>>>>> specification complete, in > >>>>>> contrast to IcedTea-Web. Java Web Start has most probably received far > >>>>>> more security fixes and > >>>>>> screening than IcedTea-Web. Personally, at the current stage of > >>>>>> IcedTea-Web I would advise any > >>>>>> enterprise or security aware user not to use IcedTea-Web. > >>>>> I believe we had a number of issues with the Oracles Javaws. somethings > >>>>> like the latest updates > >>>>> forced us to keep things current all the time, and while we are in > >>>>> production runs, things can be > >>>>> locked down for months at a time or we could lose data taking at our > >>>>> experiment. > >>>>> Right now this is me testing to see if I can get this to work > >>>>> > >>>> Chris, Just to completeness, may you try the -Xnofork together with your > >>>> Experiments? > >>>> > >>>> Anyway it sounds like bug. I will look into it. > >>>> > >>> > >>> Well this is bug. As it is done in ITW, the proxy* settings are loaded > >>> from configurations before > >>> the value of -property is merged. > >>> > >>> But it do not explain why even the -J-Ddeployment.blah is not working. > >>> //me > >>> must find what > >>> specification says > >>> > >>> Looking inisde > >>> > >>> as it was: > >>> the ITW properties are loaded form file > >>> + they are mixed into system properties > >>> proxy is selected > >>> launcher object is created > >>> "-property" argument's values are merged into JNLPresources > >>> and later ... I'mnot sure if they are even later merged into > >>> properties > >>> > >>> It is clear that original NETX wanted to keep the -property's params as > >>> isolated per jnlpfile > >>> > >>> > >>> After attached patch > >>> the ITW properties are loaded form file > >>> + they are mixed into system properties > >>> "-property" argument's values are merged into ITW properties (so not > >>> into > >>> system properties) > >>> proxy is selected > >>> launcher object is created > >>> "-property" argument's values are still merged into JNLPresources > >>> > >>> So now the config singleton have the -property(s) shared. Also set on > >>> jnlpconfig value will not > >>> change the value in per-jnlpresource > >>> > >>> > >>> I believe that this can be correct as > >>> - javaws have always isolated JVM > >>> - applets, with shared JVM, have always same -property(s) set via > >>> itwsettings (command-line args) > >>> > >>> Well my fix can probably go into 1.4 and 1.5, but for head the properties > >>> should be revisited one > >>> more times. Maybe also -D and -J-D should be handled differently. > >>> Are actually -J working with forked JVM? By check on code.. not > >>> > >>> The patch contains small refactoring to not duplicate code. The test is > >>> attached likewise. > >>> > >>> > >>> Chis, are you able to build patched RPMs? > >>> > >>> J. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> ping? Security thoughts? > > > > Hello, > > > > > > Looking at the code, it seems reasonable. Only nit would be to fix the > > typos;; > > > > In terms of security: > > > > What this patch does is take user-supplied properties: > > > > ./javaws -property name=value -jnlp jnlpFile.jnlp > > > > property: name, value: value and apply them into JNLPRuntime's > > configuration, yes? From this view, I don't know if there is a security > > issue since it's the user setting the property and not the applet. As long > > as applets can't set these properties, it should be okay... > > Thats quite good and nice point :)) > > > > What kind of things are you worried about? I am no expert here :\ > > I dont know. Unluckily the world of various merged properties is so.. strange > that I doubt there is any expert arround :(( Escpecially not me. > > I have somehow strange feelings about htis changeset. Maybe better palce > where to put it? Maybe some security check? Hello, I don't have any major issues with this patch. Is there a reproducer/test-case to make sure this fixes the issue that Chris is experiencing? Regards, > > Tahx for check! > > J. > > > > > > Regards, > > > >> > >> J. > >> > > > > -- Jie Kang From jkang at redhat.com Wed Nov 12 22:09:30 2014 From: jkang at redhat.com (Jie Kang) Date: Wed, 12 Nov 2014 17:09:30 -0500 (EST) Subject: [rfc][icedtea-web] log jnlp file to console In-Reply-To: <545CCEC8.3090907@redhat.com> References: <544663B9.4020000@redhat.com> <545CCEC8.3090907@redhat.com> Message-ID: <1973528863.7458224.1415830170907.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 10/21/2014 03:46 PM, Jiri Vanek wrote: > > hi! > > > > This is not just rfc, but RFC :) as I'm not sure which way to go. The > > only one I found suitbale - > > this oen - is not nice. > > > > Curently all the logs are going to logger, which determine if debug is on > > and what channels are > > enabled (stdout/err, file, console) > > > > According to those, it consume the message. This workflow had one > > exception, the reprinting of > > jnlpfiel, which went only to console, if debug was online. > > Most of the bugreports now contains whole console - and it is very good - > > but that measn the jnlp > > file is missing. > > > > > > The jnlpfile reprint was excluded, becasue console is using html > > formatting, to higlight outputs - > > for palintext the reprint is and willbe working fine, but it is not working > > with syntax higlighting > > from obvious reasons. > > > > I wont to avoid escaping of inpout - the message object is sahred between > > stdou/file/html > > console/plain console so to make special decoding for html console do need > > copy of it (and in case > > of console solid rework of console itself) and then proces via esapcping. > > Another issue is that html in java is terribly old, and hard to say what > > specification it supports > > (if any). > > > > To my surpise it support <plaintext> (yes nothing else do so...) So I have > > tryed to include the jnlp > > reprint wrapped by this tags. And it seems to be working fine wiht all > > supported outputs without any > > encodings or copying. > > > > There is drawback - eg firefox now have issues to show everything behind > > </plaintext> :( (note - > > <pre> do not work for jeeditorpane:( )) > > > > J. > ping, thoughts? I amde an attmept with <pre><plaintext></paintext></pre> and > it did not helped. > Still the jnlp fiel should appear inconsole :( Hello, In user-testing, the JavaConsole now displays the entire jnlp file in one line, making it difficult to read. It seems the break tags do not get formatted when displayed in Java Console (at least for me). However if you copy and paste it into a text file, it becomes multiple lines: e.g. <br/> <?xml version="1.0" standalone="yes"?><br/> line: 2 <br/> line: 3 <jnlp spec="1.0" href="SimpleJNLP.jnlp" xmlns="http://www.w3.org/1999/xhtml"><br/> line: 4? <information><br/> line: 5? ? <title>simple application</title><br/> line: 6? ? <vendor>IcedTea</vendor><br/> line: 7? ? <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"></homepage><br/> line: 8? ? <description></description><br/> line: 9? ? <offline-allowed></offline-allowed><br/> line: 10? </information><br/> line: 11? <resources><br/> line: 12? ? <j2se version="1.4+"></j2se><br/> line: 13? ? <jar href="SimpleJNLP.jar"></jar><br/> line: 14? </resources><br/> line: 15? <applet-desc name="SimpleJNLP Applet" main-class="SimpleJNLP"><br/> line: 16? </applet-desc><br/> line: 17 <br/> line: 18 <br/> line: 19 <br/> line: 20 </jnlp><br/> line: 21 <br/> line: 22 Also, I do not think it's useful to display the line numbers (e.g. line: 2, line: 3, ...). Could these be removed? I feel like sending multiple messages to the Java Console might be okay however I don't fully understand the concerns you have at the moment;; Personally, it would be most useful if there were no break tags or line numbers so I could copy and paste the output into a file and have it be pretty much the same as the original jnlp file. Is the Java Console limited and unable to do this? Maybe we can modify Java Console to support what we need;; Regards, > -- Jie Kang From jvanek at redhat.com Thu Nov 13 08:51:45 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 13 Nov 2014 09:51:45 +0100 Subject: [rfc][icedtea-web] AccessClassInPackage Reproducer Failure In-Reply-To: <718500686.7415092.1415827545074.JavaMail.zimbra@redhat.com> References: <718500686.7415092.1415827545074.JavaMail.zimbra@redhat.com> Message-ID: <54647121.9090003@redhat.com> On 11/12/2014 10:25 PM, Jie Kang wrote: > Hello, > > > I have been running a lot of reproducers lately and some consistent failures caught my eye today. In the AccessClassInPackage reproducers, a number of asserts are made including the following two: > > Assert.assertFalse("AccessClassInPackageTestLunch1 should not be terminated, but was", pr.wasTerminated); > Assert.assertEquals((Integer) 0, pr.returnValue); > > > The tests all fail due to these two asserts (wasTerminated is always true, not false, and return value is always 130 (exit due to control-C? [1]), not 0). When removing these lines and checking the tests, they all work and pass. The Class.forName call succeeds and is printed to stdout. > > So I am wondering, what are these two lines for? Is there some regression causing these failures? > > > P.S. patch attached is for easy reference to code I am talking about above; not an actual patch (though we may want to apply a similar patch) > > [1] http://tldp.org/LDP/abs/html/exitcodes.html > > > Regards, > > hi! I will look into it later, but general hint is - those are javaws tests. Javaws should print it out and clsoe itself. Tahts the "Assert.assertEquals((Integer) 0, pr.returnValue);" Fact that it do not close itself and is timouted - and so killed - is wrong. Probablyjavaws hangs. ?J? From jvanek at redhat.com Thu Nov 13 16:10:41 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 13 Nov 2014 17:10:41 +0100 Subject: [rfc][icedea-web] fixing -Xoffline in COnnectionFactory Message-ID: <5464D801.7080009@redhat.com> Obviously, when sysetme is offline, no connection is created. No need to NPE here -------------- next part -------------- A non-text attachment was scrubbed... Name: brokenOfflineNPEfix.patch Type: text/x-patch Size: 1230 bytes Desc: not available URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141113/fa83a019/brokenOfflineNPEfix.patch> From jvanek at redhat.com Thu Nov 13 16:12:43 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 13 Nov 2014 17:12:43 +0100 Subject: [rfc][icedtea-web] ignore npe in pac Message-ID: <5464D87B.5010103@redhat.com> When debugging, one need to set a lot of to ide already. Setting valid apc provider is one of those. Afaik it unnecessary burden - yes the pac will be broken, but one is not debuging pac every day. For head adding also closeables... Thoughts? J. -------------- next part -------------- A non-text attachment was scrubbed... Name: catchNpeInPac-1.5.patch Type: text/x-patch Size: 728 bytes Desc: not available URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141113/3fc2a31a/catchNpeInPac-1.5-0001.patch> -------------- next part -------------- A non-text attachment was scrubbed... Name: catchNpeInPac-head.patch Type: text/x-patch Size: 1048 bytes Desc: not available URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141113/3fc2a31a/catchNpeInPac-head-0001.patch> From jkang at redhat.com Thu Nov 13 16:21:03 2014 From: jkang at redhat.com (Jie Kang) Date: Thu, 13 Nov 2014 11:21:03 -0500 (EST) Subject: [rfc][icedea-web] fixing -Xoffline in COnnectionFactory In-Reply-To: <5464D801.7080009@redhat.com> References: <5464D801.7080009@redhat.com> Message-ID: <97023778.7794526.1415895663352.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Obviously, when sysetme is offline, no connection is created. No need to NPE > here Looks fine. Regards, > -- Jie Kang From jkang at redhat.com Thu Nov 13 16:30:51 2014 From: jkang at redhat.com (Jie Kang) Date: Thu, 13 Nov 2014 11:30:51 -0500 (EST) Subject: [rfc][icedtea-web] ignore npe in pac In-Reply-To: <5464D87B.5010103@redhat.com> References: <5464D87B.5010103@redhat.com> Message-ID: <1250835389.7801816.1415896251526.JavaMail.zimbra@redhat.com> ----- Original Message ----- > When debugging, one need to set a lot of to ide already. Setting valid apc > provider is one of those. > Afaik it unnecessary burden - yes the pac will be broken, but one is not > debuging pac every day. > > For head adding also closeables... > > Thoughts? Looks fine. Can you add a comment to explain the catch? Something like: 'PAC provider can be null, okay when not debugging pac.' Regards, > > J. > -- Jie Kang From jvanek at redhat.com Thu Nov 13 16:59:02 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 13 Nov 2014 17:59:02 +0100 Subject: [rfc][icedtea-web] menu support Message-ID: <5464E356.7060506@redhat.com> Hi! This is support for XDG menus. Work can be divided into two bug parts 1) additional features to "install desktop icon" dialogue 2) install the menu item 2: Tested in KDE, Gnome3, mate, xfce. (gnome 2 must-to-do) - see javadoc in XdesktopEntry.java for some interesting differences. But works surprisingly well. 1) our glorious accessdialogue is returning only int. I had to rape it a bit:( The only other workaround is to separate desktops's creation to separate class. COnsidering the many logic in AccessWarningPane I had inclined to those few if lines (anyway there is only small possible workaroound around this "rape 70,40,30,20,0 codes :-/) Happy reading :)) J. Pleas enote, that [rfc][icedtea-web] ignore npe in pac,a nd fixing --Xoffliner are also part of this patch. I will remove them in next rounds/before push (As the fixxes were already approved anyway). After this is in/during reviw, I will work on new panel to itweb-settings, which allows removing of icons and menu entries added by javaws.itweb. General thoughs? J. -------------- next part -------------- A non-text attachment was scrubbed... Name: menuSupport.diff Type: text/x-patch Size: 44146 bytes Desc: not available URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141113/30e9d021/menuSupport-0001.diff> From jvanek at redhat.com Thu Nov 13 17:17:29 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 13 Nov 2014 18:17:29 +0100 Subject: [rfc][icedtea-web] menu support In-Reply-To: <5464E356.7060506@redhat.com> References: <5464E356.7060506@redhat.com> Message-ID: <5464E7A9.4050704@redhat.com> On 11/13/2014 05:59 PM, Jiri Vanek wrote: > Hi! > > This is support for XDG menus. > > Work can be divided into two bug parts > 1) additional features to "install desktop icon" dialogue > 2) install the menu item > > 2: > Tested in KDE, Gnome3, mate, xfce. (gnome 2 must-to-do) - see javadoc in XdesktopEntry.java for some > interesting differences. But works surprisingly well. > > 1) our glorious accessdialogue is returning only int. I had to rape it a bit:( The only other > workaround is to separate desktops's creation to separate class. COnsidering the many logic in > AccessWarningPane I had inclined to those few if lines (anyway there is only small possible > workaroound around this "rape 70,40,30,20,0 codes :-/) > > Happy reading :)) > > > J. > > Pleas enote, that [rfc][icedtea-web] ignore npe in pac,a nd fixing --Xoffliner are also part of this > patch. I will remove them in next rounds/before push (As the fixxes were already approved anyway). > > > After this is in/during reviw, I will work on new panel to itweb-settings, which allows removing of > icons and menu entries added by javaws.itweb. > > > General thoughs? > > J. Jsut realized an NPE - in case of ALWAYS_ASK, the information, and getShortcut may be null... J. -------------- next part -------------- A non-text attachment was scrubbed... Name: menuSupport_2.diff Type: text/x-patch Size: 44410 bytes Desc: not available URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141113/7ca1c713/menuSupport_2-0001.diff> From jvanek at redhat.com Fri Nov 14 13:21:56 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 14 Nov 2014 14:21:56 +0100 Subject: [rfc][icedtea-web] menu support In-Reply-To: <5464E7A9.4050704@redhat.com> References: <5464E356.7060506@redhat.com> <5464E7A9.4050704@redhat.com> Message-ID: <546601F4.4030209@redhat.com> On 11/13/2014 06:17 PM, Jiri Vanek wrote: > On 11/13/2014 05:59 PM, Jiri Vanek wrote: >> Hi! >> >> This is support for XDG menus. >> >> Work can be divided into two bug parts >> 1) additional features to "install desktop icon" dialogue >> 2) install the menu item >> >> 2: >> Tested in KDE, Gnome3, mate, xfce. (gnome 2 must-to-do) - see javadoc in XdesktopEntry.java for some >> interesting differences. But works surprisingly well. >> >> 1) our glorious accessdialogue is returning only int. I had to rape it a bit:( The only other >> workaround is to separate desktops's creation to separate class. COnsidering the many logic in >> AccessWarningPane I had inclined to those few if lines (anyway there is only small possible >> workaroound around this "rape 70,40,30,20,0 codes :-/) >> >> Happy reading :)) >> >> >> J. >> >> Pleas enote, that [rfc][icedtea-web] ignore npe in pac,a nd fixing --Xoffliner are also part of this >> patch. I will remove them in next rounds/before push (As the fixxes were already approved anyway). >> >> >> After this is in/during reviw, I will work on new panel to itweb-settings, which allows removing of >> icons and menu entries added by javaws.itweb. >> >> >> General thoughs? >> >> J. > > Jsut realized an NPE - in case of ALWAYS_ASK, the information, and getShortcut may be null... > > > J. > just adapted to head.. Hei I like this menu +offline support :)) -------------- next part -------------- A non-text attachment was scrubbed... Name: menuSupport_3.diff Type: text/x-patch Size: 42132 bytes Desc: not available URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141114/3641e63b/menuSupport_3-0001.diff> From jvanek at redhat.com Fri Nov 14 13:51:23 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 14 Nov 2014 14:51:23 +0100 Subject: [rfc][icedtea-web] Download Resource Unit Test for ResourceTracker In-Reply-To: <1431325567.6214144.1415650163295.JavaMail.zimbra@redhat.com> References: <1431325567.6214144.1415650163295.JavaMail.zimbra@redhat.com> Message-ID: <546608DB.2060102@redhat.com> On 11/10/2014 09:09 PM, Jie Kang wrote: > Hello, > > This patch adds a simple test to cover ResourceTracker's ability to download a file into the cache system. > > How does it look? > > > Regards, > Well - this is ok, but I got little bit more in mind. Please no unrelated changes like import reordering, static import and so on... unless necesary. Afaik cache management allows you to clean only one downloaded resource - so you may think about this instead of clearcache. Also I think you need to clean cache in @beforeclass. Otherwise rt.getCacheFile will return cached file (if any) and so not verifing that the new one actually was downlaoded. Also you are testing only downloading of simple resource.. well I guess it is ok. but what I had in mind, were atomic tests also for + private URLConnection getDownloadConnection(URL location) throws IOException { + private void downloadGZipFile(Resource resource, URLConnection connection, URL downloadFrom, + private void downloadFile(Resource resource, URLConnection connection, URL downloadFrom) + private void storeEntryFields(CacheEntry entry, long contentLength, long lastModified) { + private void writeDownloadToFile(Resource resource, URL downloadLocation, InputStream in) + private void uncompressGzip(URL compressedLocation, URL uncompressedLocation) + private void uncompressPackGz(URL compressedLocation, URL uncompressedLocation) throws new methods. J. Note - in patch as it is now, I would not allow the unrelated chnages. However, if you will test all the new methods, then they may become really handy and it will be ok from my side. From jvanek at redhat.com Fri Nov 14 14:02:37 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 14 Nov 2014 15:02:37 +0100 Subject: [rfc][icedtea-web] Added reproducer for pack-gz applets In-Reply-To: <455075320.7235939.1415810051444.JavaMail.zimbra@redhat.com> References: <1322607003.4907449.1415304269808.JavaMail.zimbra@redhat.com> <545CC4E1.1070902@redhat.com> <455075320.7235939.1415810051444.JavaMail.zimbra@redhat.com> Message-ID: <54660B7D.2040004@redhat.com> On 11/12/2014 05:34 PM, Jie Kang wrote: > > > ----- Original Message ----- >> On 11/06/2014 09:04 PM, Jie Kang wrote: >>> Hello, >>> >>> This patch adds a reproducer to test for pack-gz applets in the three >>> scenarios: >>> >>> Browser - JNLP href (file) >>> Browser - Applet tags >>> Javaws - JNLP file >>> >>> >>> In order to pass these tests, modifications have been made to: >>> >>> 1. The test server implementation (TinyHttpdImpl) to take into account >>> Accept-Encoding requests and serve the correct jar files. >>> >>> 2. The PluginBridge to take into account the jnlp parameters for using >>> packaging or versioning in order to allow the Browser - JNLP situation to >>> work. >>> >>> All of this is in respect to the guidelines found here: >>> >>> http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/tools/pack200.html >>> >>> Thoughts? >>> >>> >>> Cheers, >>> >> >> This is moreover excelent work, ty! >> >> few nits >> - "doNotRunInOpera" Whyyyyyy? > > Hello, > > > Removed. Was from the reproducer I copied off of and edited. > >> - acceptEncoding again -why? > > Removed (from discussion on IRC). > >> - +PACKER=pack200 >> you should nto be lazy and use (BOOT_DIR)/bin/pack200 >> - is it onot in boot dir? Configure check? ..checking for pack200 ...found >> and then >> PACKER=(PACK200).Not fund - warn that "reproducer blah balh will fail" - >> because if build of >> reproducer fail, the suite continu >> - I know that this is abit stric but may save hours later. > > Added. > >> >> >> One though - looking to the changes in server and why it is cusotm one >> - why not to move th elogic to serverimpl ? If (pack).gz is the requested >> file, then return result >> of runtome compression of this resource ? > > Changes to tinyhttpdimpl removed. > > > How does it look now? Looks great! Ty! I have not tested. Assuming reproducers works and: - configure/make run fine (aka build dont fail, only reproducer fail) I like the idea with substituting script :)) Really nice! Assuming it works on jdk without pack200 (please really test) ok to head. J. From jvanek at redhat.com Fri Nov 14 14:04:32 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 14 Nov 2014 15:04:32 +0100 Subject: [rfc][icedtea-web] Download Resource Unit Test for ResourceTracker In-Reply-To: <1431325567.6214144.1415650163295.JavaMail.zimbra@redhat.com> References: <1431325567.6214144.1415650163295.JavaMail.zimbra@redhat.com> Message-ID: <54660BF0.8040506@redhat.com> On 11/10/2014 09:09 PM, Jie Kang wrote: > Hello, > > This patch adds a simple test to cover ResourceTracker's ability to download a file into the cache system. > > How does it look? > > > Regards, > oh - without the unrelated changes, with cleanCache before testrun, and (maybe) wit clean of the only downlaoded file - this sounds good (as it is now) to me also fo 1.5. J. From jvanek at redhat.com Fri Nov 14 14:16:28 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 14 Nov 2014 15:16:28 +0100 Subject: [rfc][icedtea-web] menu support In-Reply-To: <546601F4.4030209@redhat.com> References: <5464E356.7060506@redhat.com> <5464E7A9.4050704@redhat.com> <546601F4.4030209@redhat.com> Message-ID: <54660EBC.2080704@redhat.com> On 11/14/2014 02:21 PM, Jiri Vanek wrote: > On 11/13/2014 06:17 PM, Jiri Vanek wrote: >> On 11/13/2014 05:59 PM, Jiri Vanek wrote: >>> Hi! >>> >>> This is support for XDG menus. >>> >>> Work can be divided into two bug parts >>> 1) additional features to "install desktop icon" dialogue >>> 2) install the menu item >>> >>> 2: >>> Tested in KDE, Gnome3, mate, xfce. (gnome 2 must-to-do) - see javadoc in XdesktopEntry.java for some >>> interesting differences. But works surprisingly well. >>> >>> 1) our glorious accessdialogue is returning only int. I had to rape it a bit:( The only other >>> workaround is to separate desktops's creation to separate class. COnsidering the many logic in >>> AccessWarningPane I had inclined to those few if lines (anyway there is only small possible >>> workaroound around this "rape 70,40,30,20,0 codes :-/) >>> >>> Happy reading :)) >>> >>> >>> J. >>> >>> Pleas enote, that [rfc][icedtea-web] ignore npe in pac,a nd fixing --Xoffliner are also part of this >>> patch. I will remove them in next rounds/before push (As the fixxes were already approved anyway). >>> >>> >>> After this is in/during reviw, I will work on new panel to itweb-settings, which allows removing of >>> icons and menu entries added by javaws.itweb. >>> >>> >>> General thoughs? >>> >>> J. >> >> Jsut realized an NPE - in case of ALWAYS_ASK, the information, and getShortcut may be null... >> >> >> J. >> > just adapted to head.. Hei I like this menu +offline support :)) Fixed few messages - thay will go to properties at the end anyway. Also I have chnaged default icon from java to javaws. My system dont know javaicon, but knows javaws (wellif you run jnlp you have to installe dbooth java, and javaws, but javaws icon is under itw maintainance) Actually - I have this line in fedora specfile: cp javaws.png $RPM_BUILD_ROOT%{_datadir}/pixmaps Shouldnt our make install do so? (afaik yes) J. -------------- next part -------------- A non-text attachment was scrubbed... Name: menuSupport_4.diff Type: text/x-patch Size: 42265 bytes Desc: not available URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141114/35881b9c/menuSupport_4-0001.diff> From jvanek at redhat.com Fri Nov 14 14:17:51 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 14 Nov 2014 15:17:51 +0100 Subject: [rfc][icedtea-web] merge property arguments into config singleton (was Re: javaws CLI with Icedtea-web) In-Reply-To: <2048952498.7424549.1415828810409.JavaMail.zimbra@redhat.com> References: <53B2CC4F.3080501@redhat.com> <5448DEB0.1040508@redhat.com> <545CCEE0.8020509@redhat.com> <1020878052.5351286.1415375610115.JavaMail.zimbra@redhat.com> <5460D1CD.2020701@redhat.com> <2048952498.7424549.1415828810409.JavaMail.zimbra@redhat.com> Message-ID: <54660F0F.7050902@redhat.com> On 11/12/2014 10:46 PM, Jie Kang wrote: > > > ----- Original Message ----- >> On 11/07/2014 04:53 PM, Jie Kang wrote: >>> >>> >>> ----- Original Message ----- >>>> On 10/23/2014 12:55 PM, Jiri Vanek wrote: >>>>> >>>>> >>>>> >>>>> -------- Forwarded Message -------- >>>>> Subject: Re: javaws CLI with Icedtea-web >>>>> Date: Tue, 01 Jul 2014 16:57:19 +0200 >>>>> From: Jiri Vanek <jvanek at redhat.com> >>>>> To: distro-pkg-dev at openjdk.java.net, Omair Majid <omajid at redhat.com> >>>>> >>>>> On 07/01/2014 01:32 PM, Jiri Vanek wrote: >>>>>> On 06/30/2014 05:41 PM, Chris Lee wrote: >>>>>>> Hi Jacob, >>>>>>> On Jun 30, 2014, at 5:23 PM, Jacob Wisor wrote: >>>>>>> >>>>>>>> On 06/30/2014 04:39 PM, Chris Lee wrote: >>>>>>>>> Hi Jiri >>>>>>>>> >>>>>>>>> Thanks so much >>>>>>>>> >>>>>>>>> To explain as well, what I am trying to do is use a specific proxy >>>>>>>>> server and port for a >>>>>>>>> specific website. >>>>>>>>> I had thought that a link to the CLI might be the quickest if I can >>>>>>>>> get >>>>>>>>> it working, If there is >>>>>>>>> an easier way to configure, then I am open to suggestions. >>>>>>>> >>>>>>>> Try using Java's network configuration properties like http.proxyHost, >>>>>>>> http.proxyPort, >>>>>>>> https.proxyHost, https.proxyPort, ftp.proxyHost, ftp.proxyPort, >>>>>>>> gopher.proxyHost, >>>>>>>> gopher.proxyPort, socksProxyHost, socksProxyPort with the -J-D switch. >>>>>>>> For more information have >>>>>>>> a look into >>>>>>>> <JRE_HOME>/lib/net.properties. >>>>>>> Assuming that they can/should be applied in the same manner as the >>>>>>> properties from before, but I >>>>>>> appear to be having the same issue where it is not being applied. >>>>>>> >>>>>>> ie: >>>>>>> [chlee at pc-atlas-cr-35 .icedtea]$ javaws -verbose >>>>>>> -J-Dhttp.proxy.Host=atlasgw-exp.cern.ch >>>>>>> -J-Dhttp.proxyPort=3128 >>>>>>> http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp >>>>>>> Loading User level properties from: >>>>>>> /atlas-home/1/chlee/.icedtea/deployment.properties >>>>>>> Starting security dialog thread >>>>>>> Using firefox's profiles file: >>>>>>> /atlas-home/1/chlee/.mozilla/firefox/profiles.ini >>>>>>> Found preferences file: >>>>>>> /atlas-home/1/chlee/.mozilla/firefox/4mi0hwbe.default/prefs.js >>>>>>> Read 77 entries from Firefox's preferences >>>>>>> JNLP file location: >>>>>>> http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp >>>>>>> call privileged method: getCodeBase >>>>>>> result: null >>>>>>> Status: CONNECT STARTED +(CONNECT STARTED) @ /dipbrowser/launch.jnlp >>>>>>> Status: CONNECT DOWNLOAD STARTED +(DOWNLOAD) @ /dipbrowser/launch.jnlp >>>>>>> Status: CONNECTING DOWNLOAD STARTED +(CONNECTING) -(CONNECT) @ >>>>>>> /dipbrowser/launch.jnlp >>>>>>> All possible urls for >>>>>>> location=http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp >>>>>>> state=CONNECTING DOWNLOAD STARTED : >>>>>>> [http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp, >>>>>>> http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp] >>>>>>> Selecting proxy for: >>>>>>> http://dipbrowser.web.cern.ch/dipbrowser/launch.jnlp >>>>>>> Browser proxy option "4" (Automatic) not supported yet. >>>>>>> Browser selected proxies: [DIRECT] >>>>>>> Selected proxies: [DIRECT] >>>>>>> Selecting proxy for: socket://dipbrowser.web.cern.ch:80 >>>>>>> Browser proxy option "4" (Automatic) not supported yet. >>>>>>> Browser selected proxies: [DIRECT] >>>>>>> Selected proxies: [DIRECT] >>>>>>>> >>>>>>>>>> 1.4.1 is outdated. If you need for some reason to stay with 1.4, >>>>>>>>>> please update to 1.4.2, >>>>>>>>>> however - please swap to 1.5. It was released few month ago, is >>>>>>>>>> stable, and a a lot of fixes >>>>>>>>>> was fixed here. >>>>>>>>> >>>>>>>>> This installation is for the ATLAS experiment at CERN. For security >>>>>>>>> reason, we are usually >>>>>>>>> compelled to use what is available in the SLC repos, which >>>>>>>>> unfortunately for me right now is 1.4.1 >>>>>>>> >>>>>>>> If security is key to you, you shouldn't probably be using IcedTea-Web >>>>>>>> yet. Instead, resort to >>>>>>>> Oracle's Java Web Start implementation. This product is feature and >>>>>>>> specification complete, in >>>>>>>> contrast to IcedTea-Web. Java Web Start has most probably received far >>>>>>>> more security fixes and >>>>>>>> screening than IcedTea-Web. Personally, at the current stage of >>>>>>>> IcedTea-Web I would advise any >>>>>>>> enterprise or security aware user not to use IcedTea-Web. >>>>>>> I believe we had a number of issues with the Oracles Javaws. somethings >>>>>>> like the latest updates >>>>>>> forced us to keep things current all the time, and while we are in >>>>>>> production runs, things can be >>>>>>> locked down for months at a time or we could lose data taking at our >>>>>>> experiment. >>>>>>> Right now this is me testing to see if I can get this to work >>>>>>> >>>>>> Chris, Just to completeness, may you try the -Xnofork together with your >>>>>> Experiments? >>>>>> >>>>>> Anyway it sounds like bug. I will look into it. >>>>>> >>>>> >>>>> Well this is bug. As it is done in ITW, the proxy* settings are loaded >>>>> from configurations before >>>>> the value of -property is merged. >>>>> >>>>> But it do not explain why even the -J-Ddeployment.blah is not working. >>>>> //me >>>>> must find what >>>>> specification says >>>>> >>>>> Looking inisde >>>>> >>>>> as it was: >>>>> the ITW properties are loaded form file >>>>> + they are mixed into system properties >>>>> proxy is selected >>>>> launcher object is created >>>>> "-property" argument's values are merged into JNLPresources >>>>> and later ... I'mnot sure if they are even later merged into >>>>> properties >>>>> >>>>> It is clear that original NETX wanted to keep the -property's params as >>>>> isolated per jnlpfile >>>>> >>>>> >>>>> After attached patch >>>>> the ITW properties are loaded form file >>>>> + they are mixed into system properties >>>>> "-property" argument's values are merged into ITW properties (so not >>>>> into >>>>> system properties) >>>>> proxy is selected >>>>> launcher object is created >>>>> "-property" argument's values are still merged into JNLPresources >>>>> >>>>> So now the config singleton have the -property(s) shared. Also set on >>>>> jnlpconfig value will not >>>>> change the value in per-jnlpresource >>>>> >>>>> >>>>> I believe that this can be correct as >>>>> - javaws have always isolated JVM >>>>> - applets, with shared JVM, have always same -property(s) set via >>>>> itwsettings (command-line args) >>>>> >>>>> Well my fix can probably go into 1.4 and 1.5, but for head the properties >>>>> should be revisited one >>>>> more times. Maybe also -D and -J-D should be handled differently. >>>>> Are actually -J working with forked JVM? By check on code.. not >>>>> >>>>> The patch contains small refactoring to not duplicate code. The test is >>>>> attached likewise. >>>>> >>>>> >>>>> Chis, are you able to build patched RPMs? >>>>> >>>>> J. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> ping? Security thoughts? >>> >>> Hello, >>> >>> >>> Looking at the code, it seems reasonable. Only nit would be to fix the >>> typos;; >>> >>> In terms of security: >>> >>> What this patch does is take user-supplied properties: >>> >>> ./javaws -property name=value -jnlp jnlpFile.jnlp >>> >>> property: name, value: value and apply them into JNLPRuntime's >>> configuration, yes? From this view, I don't know if there is a security >>> issue since it's the user setting the property and not the applet. As long >>> as applets can't set these properties, it should be okay... >> >> Thats quite good and nice point :)) >>> >>> What kind of things are you worried about? I am no expert here :\ >> >> I dont know. Unluckily the world of various merged properties is so.. strange >> that I doubt there is any expert arround :(( Escpecially not me. >> >> I have somehow strange feelings about htis changeset. Maybe better palce >> where to put it? Maybe some security check? > > Hello, > > I don't have any major issues with this patch. Is there a reproducer/test-case to make sure this fixes the issue that Chris is experiencing? > > Ok. I will push then. No reprodcuer yet, but should be simple to add. I will work on it... soon. Once the reproducer is doen, I would like to backpor this also to 1.5. Actually *this* is 1.5 version patch. For head it have to use new parser... J. From jvanek at redhat.com Fri Nov 14 15:41:54 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 14 Nov 2014 16:41:54 +0100 Subject: [rfc][icedtea-web] 1.5.2 release? In-Reply-To: <5460CF83.2080509@redhat.com> References: <544A4C3A.6010507@redhat.com> <544BBF23.5010307@redhat.com> <5458FCF0.3060504@redhat.com> <545A5C12.1000408@redhat.com> <545A5CD2.70707@redhat.com> <545A5D97.803@redhat.com> <1599683181.4258978.1415222751770.JavaMail.zimbra@redhat.com> <545B3A67.9020509@redhat.com> <5460CF83.2080509@redhat.com> Message-ID: <546622C2.5050305@redhat.com> On 11/10/2014 03:45 PM, Jiri Vanek wrote: > On 11/06/2014 10:07 AM, Jiri Vanek wrote: >> On 11/05/2014 10:25 PM, Lukasz Dracz wrote: >>> Hello, >>> >>> I don't think there is a point to backporting >>> http://icedtea.classpath.org/hg/icedtea-web/rev/d8e057783109 >>> since I would probably need to backport also: >>> http://icedtea.classpath.org/hg/icedtea-web/rev/e30d71ab91c6 which was the refactor of the cache >>> panel. >>> I can do that if you still think it would be worthwhile to be backported. >>> All it adds was a tooltip for the spinner, and 1.5 still uses the slider. I could add a tooltip >>> for the slider I guess but they are somewhat different so the Messages would be different. >>> >> >> Fair enough. Then do not backport it. ty fir check! >> >>> Sorry for missing the IRC chat I was in a thermostat scrum, then went to lunch without noticing. >>> I can do the PL translations, my PL should be good enough if needed. I speak it regularly at >>> home, and attended Polish Saturday School here in Canada from elementary to high school. I do >>> have a good understanding of Polish though I must admit my writing is a little bit rusty with all >>> the Polish grammar rules but I can look stuff up if I am unsure :) >>> What do we want translated specifically ? >>> >>> I translated the two parts from Andrew's patch in the messages.properties >>> >>> CertWarnHTTPSAcceptTip=Zaakceptuj ten certyfikat i zaufaj po??czenie przez HTTPS >>> (Accept this certificate and trust a connection via HTTPS) >>> >>> CertWarnHTTPSRejectTip=Nie akceptuj ten certyfikat i nie buduj po??czenie HTTPS >>> (Do not Accept this certificate and do not build a HTTPS connection) >>> Establish looked/sounded odd to me so I thought build was more natural. >>> >> >> Great! ty! This is all :) >> >> Once Andrew pushes his backport, please push thsoe two lines. >> (ps: go on wiht transaltor :) >>> I have attached the translation, is there anywhere else that needs editing or translating ? >>> >>> Thank you, >>> Lukasz Dracz >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Andrew Azores" <aazores at redhat.com> >>>> To: "Jiri Vanek" <jvanek at redhat.com>, "IcedTea Distro List" <distro-pkg-dev at openjdk.java.net>, >>>> "Lukasz Dracz" >>>> <ldracz at redhat.com> >>>> Sent: Wednesday, November 5, 2014 12:25:43 PM >>>> Subject: Re: [rfc][icedtea-web] 1.5.2 release? >>>> >>>> On 11/05/2014 12:22 PM, Jiri Vanek wrote: >>>>> On 11/05/2014 06:19 PM, Andrew Azores wrote: >>>>>> On 11/04/2014 11:21 AM, Jiri Vanek wrote: >>>>>>> On 10/25/2014 05:17 PM, Andrew Azores wrote: >>>>>>>> On 10/24/2014 08:55 AM, Jiri Vanek wrote: >>>>>>>>> Hi! >>>>>>>>> >>>>>>>>> There appeared few fixes in head which are maybe worthy to go to >>>>>>>>> 1.5 and >>>>>>>>> afterward calling for release: >>>>>>>>> >>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/99d5407fab4a >>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/dd6be5e03667 >>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/df05d1de5af4 >>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/c6af2f50a95e >>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/6d62f68fb037 >>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/d8e057783109 >>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/90faf53bb981 >>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/2979fa371add >>>>>>>>> >>>>>>>>> >>>>>>>>> Thoughts? >>>>>>>>> >>>>>>>>> J. >>>>>>>> >>>>>>>> Sounds like a good plan to me. >>>>>>>> >>>>>>>> Thanks, >>>>>>> Hi! I have backported most of them today, except two. >>>>>>> "2" is Andrew's and "3" Lukas' >>>>>>> >>>>>>> "4" is mine, but it is(?) already backported. >>>>>>> >>>>>>> Guys, please decide whether yours 2 and/or 3 should go to 1.5. If so, >>>>>>> please backport. After doing so, and once i got confirmed RH115417 >>>>>>> 7, I will try to do a release. >>>>>>> >>>>>>> >>>>>>> TY! >>>>>>> >>>>>>> J. >>>>>> >>>>>> Attached is the fixed backport for #2. >>>>>> >>>>>> Thanks, >>>>>> -- >>>>>> Andrew Azores >>>>>> >>>>>> temporary-permissions-button-npe-fix-backport.patch >>>>>> >>>>>> >>>>>> diff --git a/ChangeLog b/ChangeLog >>>>>> --- a/ChangeLog >>>>>> +++ b/ChangeLog >>>>>> @@ -1,3 +1,18 @@ >>>>>> +2014-11-05 Andrew Azores<aazores at redhat.com> >>>>>> + >>>>>> + * netx/net/sourceforge/jnlp/resources/Messages.properties >>>>>> + (CertWarnHTTPSAcceptTip, CertWarnHTTPSRejectTip): new messages more >>>>>> + applicable for HTTPS cert warning dialogs >>>>>> + * netx/net/sourceforge/jnlp/security/dialogs/CertWarningPane.java: >>>>>> + distinguish between HTTPS cert warnings and signed applet cert >>>>>> warnings. >>>>>> + Display appropriate text labels and buttons corresponding to >>>>>> either case. >>>>>> + * >>>>>> netx/net/sourceforge/jnlp/security/dialogs/TemporaryPermissionsButton.java: >>>>>> >>>>>> + If any of file, securityDelegate, or linkedButton are null, simply >>>>>> + disable this component and do not add component listeners >>>>>> dependent upon >>>>>> + these fields. Also, do not add multiple groups of permissions, >>>>>> and do not >>>>>> + add the permissions to the securityDelegate until the >>>>>> linkedButton is >>>>>> + actually clicked (rather than when the menu item is clicked) >>>>>> + >>>>>> 2014-10-21 Jiri Vanek<jvanek at redhat.com> >>>>>> >>>>>> Fixed case when already decoded file is wonted from cache >>>>>> (RH1154177) >>>>>> diff --git a/netx/net/sourceforge/jnlp/resources/Messages.properties >>>>>> b/netx/net/sourceforge/jnlp/resources/Messages.properties >>>>>> --- a/netx/net/sourceforge/jnlp/resources/Messages.properties >>>>>> +++ b/netx/net/sourceforge/jnlp/resources/Messages.properties >>>>>> @@ -25,6 +25,8 @@ >>>>>> CertWarnCancelTip=Do not run this applet >>>>>> CertWarnPolicyTip=Advanced sandbox settings >>>>>> CertWarnPolicyEditorItem=Launch PolicyEditor >>>>>> +CertWarnHTTPSAcceptTip=Accept this certificate and trust the HTTPS >>>>>> connection >>>>>> +CertWarnHTTPSRejectTip=Do not accept this certificate and do not >>>>>> establish the HTTPS connection >>>>>> >>>>> >>>>> >>>>> Hmm. What to do with those two messages? I can supply CZ trasnaltion, >>>>> maybe also DE (with help of Severin, Roman or similar :) ) How about >>>>> PL? I rembere There was somebody in your surrounding. Wasnt? >>>>> >>>>> By otherwise - you agree it is ok for 1.5 thsi backport oook? >>>>> >>>>> Ty! >>>>> >>>>> J. >>>>> >>>> >>>> Yup, otherwise the backport looks/sounds fine to me. >>>> >>>> I do know someone from school who might be able to provide PL >>>> translations still. But... what about ldracz? ;) probably easier than >>>> pulling in some other "volunteer". >>>> >>>> Thanks, >>>> -- >>>> Andrew Azores >>>> >> > > > So on my side ITW 1.5.2 loosk good. I'm still a bit hesitating with waiting to two more fixes: > - the [rfc][icedtea-web] merge property arguments into config singleton - pushed to head. Once reproducer done, will be backported to 1.5 > - and Re: [rfc][icedtea-web] Fix to PluginMessage dates for PR2063 - afaik work in progress. > > Especially the second one should be harmless and is bit nasty to be presented. > > > thoughts? From jvanek at redhat.com Fri Nov 14 15:43:05 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 14 Nov 2014 16:43:05 +0100 Subject: [rfc][icedtea-web] log jnlp file to console In-Reply-To: <1973528863.7458224.1415830170907.JavaMail.zimbra@redhat.com> References: <544663B9.4020000@redhat.com> <545CCEC8.3090907@redhat.com> <1973528863.7458224.1415830170907.JavaMail.zimbra@redhat.com> Message-ID: <54662309.4020308@redhat.com> On 11/12/2014 11:09 PM, Jie Kang wrote: > > > ----- Original Message ----- >> On 10/21/2014 03:46 PM, Jiri Vanek wrote: >>> hi! >>> >>> This is not just rfc, but RFC :) as I'm not sure which way to go. The >>> only one I found suitbale - >>> this oen - is not nice. >>> >>> Curently all the logs are going to logger, which determine if debug is on >>> and what channels are >>> enabled (stdout/err, file, console) >>> >>> According to those, it consume the message. This workflow had one >>> exception, the reprinting of >>> jnlpfiel, which went only to console, if debug was online. >>> Most of the bugreports now contains whole console - and it is very good - >>> but that measn the jnlp >>> file is missing. >>> >>> >>> The jnlpfile reprint was excluded, becasue console is using html >>> formatting, to higlight outputs - >>> for palintext the reprint is and willbe working fine, but it is not working >>> with syntax higlighting >>> from obvious reasons. >>> >>> I wont to avoid escaping of inpout - the message object is sahred between >>> stdou/file/html >>> console/plain console so to make special decoding for html console do need >>> copy of it (and in case >>> of console solid rework of console itself) and then proces via esapcping. >>> Another issue is that html in java is terribly old, and hard to say what >>> specification it supports >>> (if any). >>> >>> To my surpise it support <plaintext> (yes nothing else do so...) So I have >>> tryed to include the jnlp >>> reprint wrapped by this tags. And it seems to be working fine wiht all >>> supported outputs without any >>> encodings or copying. >>> >>> There is drawback - eg firefox now have issues to show everything behind >>> </plaintext> :( (note - >>> <pre> do not work for jeeditorpane:( )) >>> >>> J. >> ping, thoughts? I amde an attmept with <pre><plaintext></paintext></pre> and >> it did not helped. >> Still the jnlp fiel should appear inconsole :( > > Hello, > > In user-testing, the JavaConsole now displays the entire jnlp file in one line, making it difficult to read. It seems the break tags do not get formatted when displayed in Java Console (at least for me). What java are you running on? It may be differrent im-lementation of pre/plaintex/br or whatever. I do not recall this beaviour. however - if you switch off formating. it is ok. > > However if you copy and paste it into a text file, it becomes multiple lines: > Yes, because newline is presented. Only ignored in html output. in pre - both \n and br are here. Still not working for you :( > e.g. > > <br/> > <?xml version="1.0" standalone="yes"?><br/> > line: 2 <br/> > line: 3 <jnlp spec="1.0" href="SimpleJNLP.jnlp" xmlns="http://www.w3.org/1999/xhtml"><br/> > line: 4 <information><br/> > line: 5 <title>simple application</title><br/> > line: 6 <vendor>IcedTea</vendor><br/> > line: 7 <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"></homepage><br/> > line: 8 <description></description><br/> > line: 9 <offline-allowed></offline-allowed><br/> > line: 10 </information><br/> > line: 11 <resources><br/> > line: 12 <j2se version="1.4+"></j2se><br/> > line: 13 <jar href="SimpleJNLP.jar"></jar><br/> > line: 14 </resources><br/> > line: 15 <applet-desc name="SimpleJNLP Applet" main-class="SimpleJNLP"><br/> > line: 16 </applet-desc><br/> > line: 17 <br/> > line: 18 <br/> > line: 19 <br/> > line: 20 </jnlp><br/> > line: 21 <br/> > line: 22 > > Also, I do not think it's useful to display the line numbers (e.g. line: 2, line: 3, ...). Could these be removed? I get used to like them in console output :) > > I feel like sending multiple messages to the Java Console might be okay however I don't fully understand the concerns you have at the moment;; multiple lines - yes. Multiple chars? no :(( So the builder is stil needed - and it will not solve the wrap, nor wrong escaping/not escaping :( > > Personally, it would be most useful if there were no break tags or line numbers so I could copy and paste the output into a file and have it be pretty much the same as the original jnlp file. Is the Java Console limited and unable to do this? Maybe we can modify Java Console to support what we need;; Well I created this console :)) So any fixes welcomed! Issue is that it is using html formating for rich text. See how differently are processed plain/rich outputs from raw messages and how handlers are done... I think, that the fact that the line jnlp is on one line deosnot metter. If you swithc to plaintext console, it is correct. But I cannot survive, that formatting of anything after it is broken :( Maybe adding <> escaping to console inisdes is the only way... J. From jkang at redhat.com Fri Nov 14 17:01:58 2014 From: jkang at redhat.com (Jie Kang) Date: Fri, 14 Nov 2014 12:01:58 -0500 (EST) Subject: [rfc][icedtea-web] Fix to PluginMessage dates for PR2063 In-Reply-To: <545B898A.5070304@redhat.com> References: <1999948458.3078034.1415049438993.JavaMail.zimbra@redhat.com> <5458D016.1020206@redhat.com> <1216621730.3404691.1415111223746.JavaMail.zimbra@redhat.com> <545B898A.5070304@redhat.com> Message-ID: <953157346.8389065.1415984518376.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 11/04/2014 03:27 PM, Jie Kang wrote: > > > > > > ----- Original Message ----- > >> On 11/03/2014 10:17 PM, Jie Kang wrote: > >> > >> I really did no mess? I really would expect console to show invlaid dates > >> header now... (aka = ar eyou sure??) > > > > Hmm. You are right, the headers don't get localized. I have attached two > > new patches with two different versions of fixes. I am not sure which is > > better: > > > > The most important difference is: > > > > Version 1: p.date = main[4]; > > Yes , I vote for v1 deffinitely. > > However - the sorting in consoel could not work for you - have youtried!?!?!? > > Tehre is: > case 4: > Collections.sort(sortedData, new > CatchedMessageWithHeaderComparator() { > @Override > public int body(MessageWithHeader o1, > MessageWithHeader o2) { > return > o1.getHeader().date.compareTo(o2.getHeader().date); > } > }); > > You had to got compley insane results.... > > > > I think the fix must go deeper. > > What I consider as best fix is: > in console ouput (in header is on) to have the most correct "result of > main[4]" //rfc > However, the sorting operation must be done against originalTimeStamp . hmm. > I would like to test, > if there canbe case when the originalTimeStamp and p.date may have really > different (eg by hours or > more) values.... Hello, Hmm. Well I did a patch that covers the sorting (attached), but I noticed that itw-applet messages don't get localized: [jkang][ITW-APPLET][MESSAGE_DEBUG][Fri Nov 14 17:49:28 CET 2014] [jkang][ITW-C-PLUGIN][MESSAGE_DEBUG][Fr Nov 14 17:49:08 CET 2014] Should we also localize the java dates too? I think then version 2 will be better, since the java date localization != strftime localization: e.g: cs_CZ ?t lis 04 09:02:52 EST 2014 : strftime format ?t XI 04 09:02:52 EST 2014 : java date format I think it will be much harder to convert java date -> strftime date, as opposed to strftime date/timestamp -> java date. Ugh.. Or can we leave as is... Regards, > > J. > > > > > versus > > > > Version 2: p.date = > > FileLog.getPluginSharedFormatter().format(p.originalTimeStamp); > > > > > > I tried it with LANG=en_CA, en_US, cs_CZ, de_CZ, pl_PL and the console > > seems to show valid dates. Below are the dates shown: > > > > Version 1: > > > > en_CA: > > Tue Nov 04 08:44:59 EST 2014 > > en_US: > > Tue Nov 04 08:45:35 EST 2014 > > de_DE > > Di Nov 04 09:01:04 EST 2014 > > cs_CZ > > ?t lis 04 09:02:52 EST 2014 > > pl_PL > > wto lis 04 09:21:56 EST 2014 > > > > > > Version 2: > > > > en_CA: > > Tue Nov 04 08:44:59 EST 2014 > > en_US: > > Tue Nov 04 08:45:35 EST 2014 > > de_DE > > Di Nov 04 09:01:04 EST 2014 > > cs_CZ > > ?t XI 04 09:02:52 EST 2014 > > pl_PL > > wto lis 04 09:21:04 EST 2014 > > > > > > Between the two versions, the only difference (so far) is the output in > > cs_CZ locale. > > > > > > Which do you prefer? > > > >> > >> Also I would keep the comments ffom my original pastebin here. > > > > > > Sure, I will add them. I meant to but I forgot, sorry;; > > > > > > Regards, > > > >> > >> If you disagree with the comments, then maybe remove the duplicated date > >> at > >> all? > >> > >> Ty! > >> J. > >>> Hello, > >>> > >>> > >>> The attached patch is a small fix to PluginMessage addressing PR2063. > >>> > >>> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2063 > >>> > >>> > >>> Thoughts? > >>> > >>> > >>> Regards, > >>> > >> > >> > > > > -- Jie Kang -------------- next part -------------- A non-text attachment was scrubbed... Name: itw-pr2063-2.patch Type: text/x-patch Size: 4841 bytes Desc: not available URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141114/933e63c4/itw-pr2063-2-0001.patch> From jkang at redhat.com Tue Nov 18 14:46:58 2014 From: jkang at redhat.com (Jie Kang) Date: Tue, 18 Nov 2014 09:46:58 -0500 (EST) Subject: [rfc][icedtea-web] Added reproducer for pack-gz applets In-Reply-To: <54660B7D.2040004@redhat.com> References: <1322607003.4907449.1415304269808.JavaMail.zimbra@redhat.com> <545CC4E1.1070902@redhat.com> <455075320.7235939.1415810051444.JavaMail.zimbra@redhat.com> <54660B7D.2040004@redhat.com> Message-ID: <1590548975.537797.1416322018451.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 11/12/2014 05:34 PM, Jie Kang wrote: > > > > > > ----- Original Message ----- > >> On 11/06/2014 09:04 PM, Jie Kang wrote: > >>> Hello, > >>> > >>> This patch adds a reproducer to test for pack-gz applets in the three > >>> scenarios: > >>> > >>> Browser - JNLP href (file) > >>> Browser - Applet tags > >>> Javaws - JNLP file > >>> > >>> > >>> In order to pass these tests, modifications have been made to: > >>> > >>> 1. The test server implementation (TinyHttpdImpl) to take into account > >>> Accept-Encoding requests and serve the correct jar files. > >>> > >>> 2. The PluginBridge to take into account the jnlp parameters for using > >>> packaging or versioning in order to allow the Browser - JNLP situation to > >>> work. > >>> > >>> All of this is in respect to the guidelines found here: > >>> > >>> http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/tools/pack200.html > >>> > >>> Thoughts? > >>> > >>> > >>> Cheers, > >>> > >> > >> This is moreover excelent work, ty! > >> > >> few nits > >> - "doNotRunInOpera" Whyyyyyy? > > > > Hello, > > > > > > Removed. Was from the reproducer I copied off of and edited. > > > >> - acceptEncoding again -why? > > > > Removed (from discussion on IRC). > > > >> - +PACKER=pack200 > >> you should nto be lazy and use (BOOT_DIR)/bin/pack200 > >> - is it onot in boot dir? Configure check? ..checking for pack200 > >> ...found > >> and then > >> PACKER=(PACK200).Not fund - warn that "reproducer blah balh will fail" - > >> because if build of > >> reproducer fail, the suite continu > >> - I know that this is abit stric but may save hours later. > > > > Added. > > > >> > >> > >> One though - looking to the changes in server and why it is cusotm one > >> - why not to move th elogic to serverimpl ? If (pack).gz is the > >> requested > >> file, then return result > >> of runtome compression of this resource ? > > > > Changes to tinyhttpdimpl removed. > > > > > > How does it look now? > > > Looks great! Ty! > > > I have not tested. Assuming reproducers works and: > - configure/make run fine (aka build dont fail, only reproducer fail) > > I like the idea with substituting script :)) Really nice! > > Assuming it works on jdk without pack200 (please really test) ok to head. Hello, When you say it works on jdk without pack200, what do you mean? The test suite will work but the packgz test will fail. Is that okay? Regards, > > J. > > -- Jie Kang From jvanek at redhat.com Tue Nov 18 14:48:30 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 18 Nov 2014 15:48:30 +0100 Subject: [rfc][icedtea-web] log jnlp file to console In-Reply-To: <1973528863.7458224.1415830170907.JavaMail.zimbra@redhat.com> References: <544663B9.4020000@redhat.com> <545CCEC8.3090907@redhat.com> <1973528863.7458224.1415830170907.JavaMail.zimbra@redhat.com> Message-ID: <546B5C3E.5030007@redhat.com> On 11/12/2014 11:09 PM, Jie Kang wrote: > > > ----- Original Message ----- >> On 10/21/2014 03:46 PM, Jiri Vanek wrote: >>> hi! >>> >>> This is not just rfc, but RFC :) as I'm not sure which way to go. The >>> only one I found suitbale - >>> this oen - is not nice. >>> >>> Curently all the logs are going to logger, which determine if debug is on >>> and what channels are >>> enabled (stdout/err, file, console) >>> >>> According to those, it consume the message. This workflow had one >>> exception, the reprinting of >>> jnlpfiel, which went only to console, if debug was online. >>> Most of the bugreports now contains whole console - and it is very good - >>> but that measn the jnlp >>> file is missing. >>> >>> >>> The jnlpfile reprint was excluded, becasue console is using html >>> formatting, to higlight outputs - >>> for palintext the reprint is and willbe working fine, but it is not working >>> with syntax higlighting >>> from obvious reasons. >>> >>> I wont to avoid escaping of inpout - the message object is sahred between >>> stdou/file/html >>> console/plain console so to make special decoding for html console do need >>> copy of it (and in case >>> of console solid rework of console itself) and then proces via esapcping. >>> Another issue is that html in java is terribly old, and hard to say what >>> specification it supports >>> (if any). >>> >>> To my surpise it support <plaintext> (yes nothing else do so...) So I have >>> tryed to include the jnlp >>> reprint wrapped by this tags. And it seems to be working fine wiht all >>> supported outputs without any >>> encodings or copying. >>> >>> There is drawback - eg firefox now have issues to show everything behind >>> </plaintext> :( (note - >>> <pre> do not work for jeeditorpane:( )) >>> >>> J. >> ping, thoughts? I amde an attmept with <pre><plaintext></paintext></pre> and >> it did not helped. >> Still the jnlp fiel should appear inconsole :( > > Hello, > > In user-testing, the JavaConsole now displays the entire jnlp file in one line, making it difficult to read. It seems the break tags do not get formatted when displayed in Java Console (at least for me). > > However if you copy and paste it into a text file, it becomes multiple lines: > > e.g. > > <br/> > <?xml version="1.0" standalone="yes"?><br/> > line: 2 <br/> > line: 3 <jnlp spec="1.0" href="SimpleJNLP.jnlp" xmlns="http://www.w3.org/1999/xhtml"><br/> > line: 4 <information><br/> > line: 5 <title>simple application</title><br/> > line: 6 <vendor>IcedTea</vendor><br/> > line: 7 <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"></homepage><br/> > line: 8 <description></description><br/> > line: 9 <offline-allowed></offline-allowed><br/> > line: 10 </information><br/> > line: 11 <resources><br/> > line: 12 <j2se version="1.4+"></j2se><br/> > line: 13 <jar href="SimpleJNLP.jar"></jar><br/> > line: 14 </resources><br/> > line: 15 <applet-desc name="SimpleJNLP Applet" main-class="SimpleJNLP"><br/> > line: 16 </applet-desc><br/> > line: 17 <br/> > line: 18 <br/> > line: 19 <br/> > line: 20 </jnlp><br/> > line: 21 <br/> > line: 22 > > Also, I do not think it's useful to display the line numbers (e.g. line: 2, line: 3, ...). Could these be removed? > > I feel like sending multiple messages to the Java Console might be okay however I don't fully understand the concerns you have at the moment;; > > Personally, it would be most useful if there were no break tags or line numbers so I could copy and paste the output into a file and have it be pretty much the same as the original jnlp file. Is the Java Console limited and unable to do this? Maybe we can modify Java Console to support what we need;; Yes. It is deffinitly the right way. See new patch with your approach :) Thoughts? J. -------------- next part -------------- diff -r 72694a41898c netx/net/sourceforge/jnlp/util/logging/ConsoleOutputPaneModel.java --- a/netx/net/sourceforge/jnlp/util/logging/ConsoleOutputPaneModel.java Fri Nov 14 16:25:56 2014 +0100 +++ b/netx/net/sourceforge/jnlp/util/logging/ConsoleOutputPaneModel.java Tue Nov 18 15:44:47 2014 +0100 @@ -205,6 +205,8 @@ } String line = (createLine(messageWithHeader)); if (mark) { + line = line.replaceAll("<", "&lt;"); + line = line.replaceAll(">", "&gt;"); line = line.replaceAll("\n", "<br/>\n"); line = line.replaceAll(" ", "&nbsp; ");//small trick, html is reducting row of spaces to single space. This handles it and stimm allow line wrap line = line.replaceAll("\t", "&nbsp;&nbsp;&nbsp;&nbsp;"); diff -r 72694a41898c netx/net/sourceforge/nanoxml/XMLElement.java --- a/netx/net/sourceforge/nanoxml/XMLElement.java Fri Nov 14 16:25:56 2014 +0100 +++ b/netx/net/sourceforge/nanoxml/XMLElement.java Tue Nov 18 15:44:47 2014 +0100 @@ -1165,9 +1165,9 @@ * filtered xml file. */ public void sanitizeInput(Reader isr, OutputStream pout) { + StringBuilder line = new StringBuilder(); try { PrintStream out = new PrintStream(pout); - this.sanitizeCharReadTooMuch = '\0'; this.reader = isr; this.parserLineNr = 0; @@ -1200,14 +1200,12 @@ // what's in the buffer out.print(ch); out.flush(); - if (JNLPRuntime.isDebug()) { - if (ch == 10) { - OutputController.getLogger().printOutLn(""); - OutputController.getLogger().printOut("line: " + newline + " "); - newline++; - } else { - OutputController.getLogger().printOut(ch+""); - } + if (ch == 10) { + OutputController.getLogger().log(line.toString()); + line = new StringBuilder("line: " + newline + " "); + newline++; + } else { + line.append(ch); } break; } else if (i == 10) { @@ -1232,44 +1230,41 @@ out.print('!'); out.print('-'); this.sanitizeCharReadTooMuch = ch; - if (JNLPRuntime.isDebug()) { - OutputController.getLogger().printOut("<"); - OutputController.getLogger().printOut("!"); - OutputController.getLogger().printOut("-"); - } + line.append("<"); + line.append("!"); + line.append("-"); } } else { out.print('<'); out.print('!'); this.sanitizeCharReadTooMuch = ch; - if (JNLPRuntime.isDebug()) { - OutputController.getLogger().printOut("<"); - OutputController.getLogger().printOut("!"); - } + line.append("<"); + line.append("!"); } } // Otherwise we haven't hit a comment, and we should write ch. else { out.print(ch); - if (JNLPRuntime.isDebug()) { - if (ch == 10) { - OutputController.getLogger().printOutLn(""); - OutputController.getLogger().printOut("line: " + newline + " "); - newline++; - } else { - OutputController.getLogger().printOut(ch+""); - } + if (ch == 10) { + OutputController.getLogger().log(line.toString()); + line = new StringBuilder("line: " + newline + " "); + newline++; + } else { + line.append(ch); } } prev = next; } - out.close(); isr.close(); } catch (Exception e) { // Print the stack trace here -- xml.parseFromReader() will // throw the ParseException if something goes wrong. OutputController.getLogger().log(OutputController.Level.ERROR_ALL, e); + } finally { + OutputController.getLogger().log("");//force new line in all cases + OutputController.getLogger().log(line.toString()); //flush remaining line + } } } From jvanek at redhat.com Tue Nov 18 15:13:27 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 18 Nov 2014 16:13:27 +0100 Subject: [rfc][icedtea-web] Added reproducer for pack-gz applets In-Reply-To: <1590548975.537797.1416322018451.JavaMail.zimbra@redhat.com> References: <1322607003.4907449.1415304269808.JavaMail.zimbra@redhat.com> <545CC4E1.1070902@redhat.com> <455075320.7235939.1415810051444.JavaMail.zimbra@redhat.com> <54660B7D.2040004@redhat.com> <1590548975.537797.1416322018451.JavaMail.zimbra@redhat.com> Message-ID: <546B6217.8010902@redhat.com> On 11/18/2014 03:46 PM, Jie Kang wrote: > > > ----- Original Message ----- >> On 11/12/2014 05:34 PM, Jie Kang wrote: >>> >>> >>> ----- Original Message ----- >>>> On 11/06/2014 09:04 PM, Jie Kang wrote: >>>>> Hello, >>>>> >>>>> This patch adds a reproducer to test for pack-gz applets in the three >>>>> scenarios: >>>>> >>>>> Browser - JNLP href (file) >>>>> Browser - Applet tags >>>>> Javaws - JNLP file >>>>> >>>>> >>>>> In order to pass these tests, modifications have been made to: >>>>> >>>>> 1. The test server implementation (TinyHttpdImpl) to take into account >>>>> Accept-Encoding requests and serve the correct jar files. >>>>> >>>>> 2. The PluginBridge to take into account the jnlp parameters for using >>>>> packaging or versioning in order to allow the Browser - JNLP situation to >>>>> work. >>>>> >>>>> All of this is in respect to the guidelines found here: >>>>> >>>>> http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/tools/pack200.html >>>>> >>>>> Thoughts? >>>>> >>>>> >>>>> Cheers, >>>>> >>>> >>>> This is moreover excelent work, ty! >>>> >>>> few nits >>>> - "doNotRunInOpera" Whyyyyyy? >>> >>> Hello, >>> >>> >>> Removed. Was from the reproducer I copied off of and edited. >>> >>>> - acceptEncoding again -why? >>> >>> Removed (from discussion on IRC). >>> >>>> - +PACKER=pack200 >>>> you should nto be lazy and use (BOOT_DIR)/bin/pack200 >>>> - is it onot in boot dir? Configure check? ..checking for pack200 >>>> ...found >>>> and then >>>> PACKER=(PACK200).Not fund - warn that "reproducer blah balh will fail" - >>>> because if build of >>>> reproducer fail, the suite continu >>>> - I know that this is abit stric but may save hours later. >>> >>> Added. >>> >>>> >>>> >>>> One though - looking to the changes in server and why it is cusotm one >>>> - why not to move th elogic to serverimpl ? If (pack).gz is the >>>> requested >>>> file, then return result >>>> of runtome compression of this resource ? >>> >>> Changes to tinyhttpdimpl removed. >>> >>> >>> How does it look now? >> >> >> Looks great! Ty! >> >> >> I have not tested. Assuming reproducers works and: >> - configure/make run fine (aka build dont fail, only reproducer fail) >> >> I like the idea with substituting script :)) Really nice! >> >> Assuming it works on jdk without pack200 (please really test) ok to head. > > Hello, > > When you say it works on jdk without pack200, what do you mean? > > The test suite will work but the packgz test will fail. Is that okay? yes > > > Regards, > >> >> J. >> >> > From jvanek at redhat.com Tue Nov 18 15:29:55 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 18 Nov 2014 16:29:55 +0100 Subject: [rfc][icedtea-web] Fix to PluginMessage dates for PR2063 In-Reply-To: <953157346.8389065.1415984518376.JavaMail.zimbra@redhat.com> References: <1999948458.3078034.1415049438993.JavaMail.zimbra@redhat.com> <5458D016.1020206@redhat.com> <1216621730.3404691.1415111223746.JavaMail.zimbra@redhat.com> <545B898A.5070304@redhat.com> <953157346.8389065.1415984518376.JavaMail.zimbra@redhat.com> Message-ID: <546B65F3.9010008@redhat.com> >> >> Yes , I vote for v1 deffinitely. >> >> However - the sorting in consoel could not work for you - have youtried!?!?!? >> >> Tehre is: >> case 4: >> Collections.sort(sortedData, new >> CatchedMessageWithHeaderComparator() { >> @Override >> public int body(MessageWithHeader o1, >> MessageWithHeader o2) { >> return >> o1.getHeader().date.compareTo(o2.getHeader().date); >> } >> }); >> >> You had to got compley insane results.... >> >> >> >> I think the fix must go deeper. >> >> What I consider as best fix is: >> in console ouput (in header is on) to have the most correct "result of >> main[4]" //rfc >> However, the sorting operation must be done against originalTimeStamp . hmm. >> I would like to test, >> if there canbe case when the originalTimeStamp and p.date may have really >> different (eg by hours or >> more) values.... > > Hello, > > > Hmm. Well I did a patch that covers the sorting (attached), but I noticed that itw-applet messages don't get localized: > > [jkang][ITW-APPLET][MESSAGE_DEBUG][Fri Nov 14 17:49:28 CET 2014] > [jkang][ITW-C-PLUGIN][MESSAGE_DEBUG][Fr Nov 14 17:49:08 CET 2014] > > > Should we also localize the java dates too? I think then version 2 will be better, since the java date localization != strftime localization: > > e.g: > cs_CZ > ?t lis 04 09:02:52 EST 2014 : strftime format > ?t XI 04 09:02:52 EST 2014 : java date format > > I think it will be much harder to convert java date -> strftime date, as opposed to strftime date/timestamp -> java date. > > > Ugh.. Or can we leave as is... > > > > Regards, > > > >> Hi! The patch looks almost good - *almost* :) I really do not understand : + p.timestamp = new Date(Long.parseLong(init[1]) / 1000).getTime(); Why to long to date and then to long again??? Anyway - I think we should stay with date Instead of: - public Date date = new Date(); + public String date; + public Long timestamp; I would go with - public Date date = new Date(); + public String date; + public Date timestamp; NIt: + p.date = main[4]; + + imho one \n is enough :) After the long->date->long is fixed and - return o1.getHeader().date.compareTo(o2.getHeader().date); + return o1.getHeader().timestamp.compareTo(o2.getHeader().timestamp); } you are sure returns correct order, it seems to be ok for head. But please send one more times. J. From jvanek at redhat.com Tue Nov 18 15:32:43 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 18 Nov 2014 16:32:43 +0100 Subject: [rfc][icedtea-web] log jnlp file to console In-Reply-To: <546B5C3E.5030007@redhat.com> References: <546B5C3E.5030007@redhat.com> Message-ID: <546B669B.2070605@redhat.com> > > > ----- Original Message ----- >> On 10/21/2014 03:46 PM, Jiri Vanek wrote: >>> hi! >>> >>> This is not just rfc, but RFC :) as I'm not sure which way to go. The >>> only one I found suitbale - >>> this oen - is not nice. >>> >>> Curently all the logs are going to logger, which determine if debug is on >>> and what channels are >>> enabled (stdout/err, file, console) >>> >>> According to those, it consume the message. This workflow had one >>> exception, the reprinting of >>> jnlpfiel, which went only to console, if debug was online. >>> Most of the bugreports now contains whole console - and it is very good - >>> but that measn the jnlp >>> file is missing. >>> >>> >>> The jnlpfile reprint was excluded, becasue console is using html >>> formatting, to higlight outputs - >>> for palintext the reprint is and willbe working fine, but it is not working >>> with syntax higlighting >>> from obvious reasons. >>> >>> I wont to avoid escaping of inpout - the message object is sahred between >>> stdou/file/html >>> console/plain console so to make special decoding for html console do need >>> copy of it (and in case >>> of console solid rework of console itself) and then proces via esapcping. >>> Another issue is that html in java is terribly old, and hard to say what >>> specification it supports >>> (if any). >>> >>> To my surpise it support <plaintext> (yes nothing else do so...) So I have >>> tryed to include the jnlp >>> reprint wrapped by this tags. And it seems to be working fine wiht all >>> supported outputs without any >>> encodings or copying. >>> >>> There is drawback - eg firefox now have issues to show everything behind >>> </plaintext> :( (note - >>> <pre> do not work for jeeditorpane:( )) >>> >>> J. >> ping, thoughts? I amde an attmept with <pre><plaintext></paintext></pre> and >> it did not helped. >> Still the jnlp fiel should appear inconsole :( > > Hello, > > In user-testing, the JavaConsole now displays the entire jnlp file in one line, making it difficult to read. It seems the break tags do not get formatted when displayed in Java Console (at least for me). > > However if you copy and paste it into a text file, it becomes multiple lines: > > e.g. > > <br/> > <?xml version="1.0" standalone="yes"?><br/> > line: 2 <br/> > line: 3 <jnlp spec="1.0" href="SimpleJNLP.jnlp" xmlns="http://www.w3.org/1999/xhtml"><br/> > line: 4 <information><br/> > line: 5 <title>simple application</title><br/> > line: 6 <vendor>IcedTea</vendor><br/> > line: 7 <homepage href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"></homepage><br/> > line: 8 <description></description><br/> > line: 9 <offline-allowed></offline-allowed><br/> > line: 10 </information><br/> > line: 11 <resources><br/> > line: 12 <j2se version="1.4+"></j2se><br/> > line: 13 <jar href="SimpleJNLP.jar"></jar><br/> > line: 14 </resources><br/> > line: 15 <applet-desc name="SimpleJNLP Applet" main-class="SimpleJNLP"><br/> > line: 16 </applet-desc><br/> > line: 17 <br/> > line: 18 <br/> > line: 19 <br/> > line: 20 </jnlp><br/> > line: 21 <br/> > line: 22 > > Also, I do not think it's useful to display the line numbers (e.g. line: 2, line: 3, ...). Could these be removed? > > I feel like sending multiple messages to the Java Console might be okay however I don't fully understand the concerns you have at the moment;; > > Personally, it would be most useful if there were no break tags or line numbers so I could copy and paste the output into a file and have it be pretty much the same as the original jnlp file. Is the Java Console limited and unable to do this? Maybe we can modify Java Console to support what we need;; Yes. It is deffinitly the right way. See new patch with your approach :) Thoughts? J. -------------- next part -------------- diff -r 72694a41898c netx/net/sourceforge/jnlp/util/logging/ConsoleOutputPaneModel.java --- a/netx/net/sourceforge/jnlp/util/logging/ConsoleOutputPaneModel.java Fri Nov 14 16:25:56 2014 +0100 +++ b/netx/net/sourceforge/jnlp/util/logging/ConsoleOutputPaneModel.java Tue Nov 18 15:44:47 2014 +0100 @@ -205,6 +205,8 @@ } String line = (createLine(messageWithHeader)); if (mark) { + line = line.replaceAll("<", "&lt;"); + line = line.replaceAll(">", "&gt;"); line = line.replaceAll("\n", "<br/>\n"); line = line.replaceAll(" ", "&nbsp; ");//small trick, html is reducting row of spaces to single space. This handles it and stimm allow line wrap line = line.replaceAll("\t", "&nbsp;&nbsp;&nbsp;&nbsp;"); diff -r 72694a41898c netx/net/sourceforge/nanoxml/XMLElement.java --- a/netx/net/sourceforge/nanoxml/XMLElement.java Fri Nov 14 16:25:56 2014 +0100 +++ b/netx/net/sourceforge/nanoxml/XMLElement.java Tue Nov 18 15:44:47 2014 +0100 @@ -1165,9 +1165,9 @@ * filtered xml file. */ public void sanitizeInput(Reader isr, OutputStream pout) { + StringBuilder line = new StringBuilder(); try { PrintStream out = new PrintStream(pout); - this.sanitizeCharReadTooMuch = '\0'; this.reader = isr; this.parserLineNr = 0; @@ -1200,14 +1200,12 @@ // what's in the buffer out.print(ch); out.flush(); - if (JNLPRuntime.isDebug()) { - if (ch == 10) { - OutputController.getLogger().printOutLn(""); - OutputController.getLogger().printOut("line: " + newline + " "); - newline++; - } else { - OutputController.getLogger().printOut(ch+""); - } + if (ch == 10) { + OutputController.getLogger().log(line.toString()); + line = new StringBuilder("line: " + newline + " "); + newline++; + } else { + line.append(ch); } break; } else if (i == 10) { @@ -1232,44 +1230,41 @@ out.print('!'); out.print('-'); this.sanitizeCharReadTooMuch = ch; - if (JNLPRuntime.isDebug()) { - OutputController.getLogger().printOut("<"); - OutputController.getLogger().printOut("!"); - OutputController.getLogger().printOut("-"); - } + line.append("<"); + line.append("!"); + line.append("-"); } } else { out.print('<'); out.print('!'); this.sanitizeCharReadTooMuch = ch; - if (JNLPRuntime.isDebug()) { - OutputController.getLogger().printOut("<"); - OutputController.getLogger().printOut("!"); - } + line.append("<"); + line.append("!"); } } // Otherwise we haven't hit a comment, and we should write ch. else { out.print(ch); - if (JNLPRuntime.isDebug()) { - if (ch == 10) { - OutputController.getLogger().printOutLn(""); - OutputController.getLogger().printOut("line: " + newline + " "); - newline++; - } else { - OutputController.getLogger().printOut(ch+""); - } + if (ch == 10) { + OutputController.getLogger().log(line.toString()); + line = new StringBuilder("line: " + newline + " "); + newline++; + } else { + line.append(ch); } } prev = next; } - out.close(); isr.close(); } catch (Exception e) { // Print the stack trace here -- xml.parseFromReader() will // throw the ParseException if something goes wrong. OutputController.getLogger().log(OutputController.Level.ERROR_ALL, e); + } finally { + OutputController.getLogger().log("");//force new line in all cases + OutputController.getLogger().log(line.toString()); //flush remaining line + } } } From jkang at redhat.com Tue Nov 18 17:46:18 2014 From: jkang at redhat.com (Jie Kang) Date: Tue, 18 Nov 2014 12:46:18 -0500 (EST) Subject: [rfc][icedtea-web] Fix to PluginMessage dates for PR2063 In-Reply-To: <546B65F3.9010008@redhat.com> References: <1999948458.3078034.1415049438993.JavaMail.zimbra@redhat.com> <5458D016.1020206@redhat.com> <1216621730.3404691.1415111223746.JavaMail.zimbra@redhat.com> <545B898A.5070304@redhat.com> <953157346.8389065.1415984518376.JavaMail.zimbra@redhat.com> <546B65F3.9010008@redhat.com> Message-ID: <2013629678.665876.1416332778549.JavaMail.zimbra@redhat.com> ----- Original Message ----- > >> > >> Yes , I vote for v1 deffinitely. > >> > >> However - the sorting in consoel could not work for you - have > >> youtried!?!?!? > >> > >> Tehre is: > >> case 4: > >> Collections.sort(sortedData, new > >> CatchedMessageWithHeaderComparator() { > >> @Override > >> public int body(MessageWithHeader o1, > >> MessageWithHeader o2) { > >> return > >> o1.getHeader().date.compareTo(o2.getHeader().date); > >> } > >> }); > >> > >> You had to got compley insane results.... > >> > >> > >> > >> I think the fix must go deeper. > >> > >> What I consider as best fix is: > >> in console ouput (in header is on) to have the most correct "result of > >> main[4]" //rfc > >> However, the sorting operation must be done against originalTimeStamp . > >> hmm. > >> I would like to test, > >> if there canbe case when the originalTimeStamp and p.date may have really > >> different (eg by hours or > >> more) values.... > > > > Hello, > > > > > > Hmm. Well I did a patch that covers the sorting (attached), but I noticed > > that itw-applet messages don't get localized: > > > > [jkang][ITW-APPLET][MESSAGE_DEBUG][Fri Nov 14 17:49:28 CET 2014] > > [jkang][ITW-C-PLUGIN][MESSAGE_DEBUG][Fr Nov 14 17:49:08 CET 2014] > > > > > > Should we also localize the java dates too? I think then version 2 will be > > better, since the java date localization != strftime localization: > > > > e.g: > > cs_CZ > > ?t lis 04 09:02:52 EST 2014 : strftime format > > ?t XI 04 09:02:52 EST 2014 : java date format > > > > I think it will be much harder to convert java date -> strftime date, as > > opposed to strftime date/timestamp -> java date. > > > > > > Ugh.. Or can we leave as is... > > > > > > > > Regards, > > > > > > > >> > > Hi! > > The patch looks almost good - *almost* :) > > I really do not understand : > + p.timestamp = new Date(Long.parseLong(init[1]) / > 1000).getTime(); > > Why to long to date and then to long again??? > > Anyway - I think we should stay with date Instead of: > > > - public Date date = new Date(); > + public String date; > + public Long timestamp; > > I would go with > > > - public Date date = new Date(); > + public String date; > + public Date timestamp; > > > NIt: > > + p.date = main[4]; > + > + > imho one \n is enough :) > > > > After the long->date->long is fixed and > - return > o1.getHeader().date.compareTo(o2.getHeader().date); > + return > o1.getHeader().timestamp.compareTo(o2.getHeader().timestamp); > } > you are sure returns correct order, it seems to be ok for head. But please > send one more times. Hello, I've added all the fixes you suggested. Thanks for the review! How does it look? Cheers, > > > J. > > > -- Jie Kang -------------- next part -------------- A non-text attachment was scrubbed... Name: itw-pr2063-3.patch Type: text/x-patch Size: 3654 bytes Desc: not available URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141118/c71faec9/itw-pr2063-3.patch> From jvanek at redhat.com Tue Nov 18 18:01:52 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 18 Nov 2014 19:01:52 +0100 Subject: [rfc][icedtea-web] Fix to PluginMessage dates for PR2063 In-Reply-To: <2013629678.665876.1416332778549.JavaMail.zimbra@redhat.com> References: <1999948458.3078034.1415049438993.JavaMail.zimbra@redhat.com> <5458D016.1020206@redhat.com> <1216621730.3404691.1415111223746.JavaMail.zimbra@redhat.com> <545B898A.5070304@redhat.com> <953157346.8389065.1415984518376.JavaMail.zimbra@redhat.com> <546B65F3.9010008@redhat.com> <2013629678.665876.1416332778549.JavaMail.zimbra@redhat.com> Message-ID: <546B8990.7000009@redhat.com> On 11/18/2014 06:46 PM, Jie Kang wrote: > > > ----- Original Message ----- >>>> >>>> Yes , I vote for v1 deffinitely. >>>> >>>> However - the sorting in consoel could not work for you - have >>>> youtried!?!?!? >>>> >>>> Tehre is: >>>> case 4: >>>> Collections.sort(sortedData, new >>>> CatchedMessageWithHeaderComparator() { >>>> @Override >>>> public int body(MessageWithHeader o1, >>>> MessageWithHeader o2) { >>>> return >>>> o1.getHeader().date.compareTo(o2.getHeader().date); >>>> } >>>> }); >>>> >>>> You had to got compley insane results.... >>>> >>>> >>>> >>>> I think the fix must go deeper. >>>> >>>> What I consider as best fix is: >>>> in console ouput (in header is on) to have the most correct "result of >>>> main[4]" //rfc >>>> However, the sorting operation must be done against originalTimeStamp . >>>> hmm. >>>> I would like to test, >>>> if there canbe case when the originalTimeStamp and p.date may have really >>>> different (eg by hours or >>>> more) values.... >>> >>> Hello, >>> >>> >>> Hmm. Well I did a patch that covers the sorting (attached), but I noticed >>> that itw-applet messages don't get localized: >>> >>> [jkang][ITW-APPLET][MESSAGE_DEBUG][Fri Nov 14 17:49:28 CET 2014] >>> [jkang][ITW-C-PLUGIN][MESSAGE_DEBUG][Fr Nov 14 17:49:08 CET 2014] >>> >>> >>> Should we also localize the java dates too? I think then version 2 will be >>> better, since the java date localization != strftime localization: >>> >>> e.g: >>> cs_CZ >>> ?t lis 04 09:02:52 EST 2014 : strftime format >>> ?t XI 04 09:02:52 EST 2014 : java date format >>> >>> I think it will be much harder to convert java date -> strftime date, as >>> opposed to strftime date/timestamp -> java date. >>> >>> >>> Ugh.. Or can we leave as is... >>> >>> >>> >>> Regards, >>> >>> >>> >>>> >> >> Hi! >> >> The patch looks almost good - *almost* :) >> >> I really do not understand : >> + p.timestamp = new Date(Long.parseLong(init[1]) / >> 1000).getTime(); >> >> Why to long to date and then to long again??? >> >> Anyway - I think we should stay with date Instead of: >> >> >> - public Date date = new Date(); >> + public String date; >> + public Long timestamp; >> >> I would go with >> >> >> - public Date date = new Date(); >> + public String date; >> + public Date timestamp; >> >> >> NIt: >> >> + p.date = main[4]; >> + >> + >> imho one \n is enough :) >> >> >> >> After the long->date->long is fixed and >> - return >> o1.getHeader().date.compareTo(o2.getHeader().date); >> + return >> o1.getHeader().timestamp.compareTo(o2.getHeader().timestamp); >> } >> you are sure returns correct order, it seems to be ok for head. But please >> send one more times. > > Hello, > > I've added all the fixes you suggested. Thanks for the review! How does it look? > > Yup. Looks ok for head. I will play with it tomorrow and if better then ok, then I will backport to 1.5 and prepare 1.5.2 release candidate for testing. Thank you VM! J. From jvanek at redhat.com Wed Nov 19 15:05:13 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Wed, 19 Nov 2014 16:05:13 +0100 Subject: [rfc][icedtea-web-1.5]escape < and > in console (was Re: [rfc][icedtea-web] log jnlp file to console ) In-Reply-To: <546B669B.2070605@redhat.com> References: <546B5C3E.5030007@redhat.com> <546B669B.2070605@redhat.com> Message-ID: <546CB1A9.8010000@redhat.com> I have just spotted interesting behavior for both 1.5 and head. When javaws appl forks (the behaviour which can be canceled by -Xnofork) and printing to streams is enabled then forked jvm is writing into stdout/err, which is then recognized by upper jvm as "custom input" and so is reprinted again also to old console. As it do not deadloc, then I would call it feature, not a bug :) However, - as jnlp is reprinted to stdout by foorked jvm in 1.5 the --- a/netx/net/sourceforge/jnlp/util/logging/ConsoleOutputPaneModel.java Fri Nov 14 16:25:56 2014 +0100 +++ b/netx/net/sourceforge/jnlp/util/logging/ConsoleOutputPaneModel.java Tue Nov 18 15:44:47 2014 +0100 @@ -205,6 +205,8 @@ } String line = (createLine(messageWithHeader)); if (mark) { + line = line.replaceAll("<", "&lt;"); + line = line.replaceAll(">", "&gt;"); line = line.replaceAll("\n", "<br/>\n"); line = line.replaceAll(" ", "&nbsp; ");//small trick, html is reducting row of spaces to single space. This handles it and stimm allow line wrap line = line.replaceAll("\t", "&nbsp;&nbsp;&nbsp;&nbsp;"); hunk is very valid also for 1.5 and if head is approved, then I would like to push this hunk to 1.5 Well.. maybe more escaping is needed. But not sure how urgent those are... J. On 11/18/2014 04:32 PM, Jiri Vanek wrote: > > >> >> ----- Original Message ----- >>> On 10/21/2014 03:46 PM, Jiri Vanek wrote: >>>> hi! >>>> >>>> This is not just rfc, but RFC :) as I'm not sure which way to go. The >>>> only one I found suitbale - >>>> this oen - is not nice. >>>> >>>> Curently all the logs are going to logger, which determine if debug is on >>>> and what channels are >>>> enabled (stdout/err, file, console) >>>> >>>> According to those, it consume the message. This workflow had one >>>> exception, the reprinting of >>>> jnlpfiel, which went only to console, if debug was online. >>>> Most of the bugreports now contains whole console - and it is very good - >>>> but that measn the jnlp >>>> file is missing. >>>> >>>> >>>> The jnlpfile reprint was excluded, becasue console is using html >>>> formatting, to higlight outputs - >>>> for palintext the reprint is and willbe working fine, but it is not working >>>> with syntax higlighting >>>> from obvious reasons. >>>> >>>> I wont to avoid escaping of inpout - the message object is sahred between >>>> stdou/file/html >>>> console/plain console so to make special decoding for html console do need >>>> copy of it (and in case >>>> of console solid rework of console itself) and then proces via esapcping. >>>> Another issue is that html in java is terribly old, and hard to say what >>>> specification it supports >>>> (if any). >>>> >>>> To my surpise it support <plaintext> (yes nothing else do so...) So I have >>>> tryed to include the jnlp >>>> reprint wrapped by this tags. And it seems to be working fine wiht all >>>> supported outputs without any >>>> encodings or copying. >>>> >>>> There is drawback - eg firefox now have issues to show everything behind >>>> </plaintext> :( (note - >>>> <pre> do not work for jeeditorpane:( )) >>>> >>>> J. >>> ping, thoughts? I amde an attmept with <pre><plaintext></paintext></pre> and >>> it did not helped. >>> Still the jnlp fiel should appear inconsole :( >> >> Hello, >> >> In user-testing, the JavaConsole now displays the entire jnlp file in one line, making it >> difficult to read. It seems the break tags do not get formatted when displayed in Java Console (at >> least for me). >> >> However if you copy and paste it into a text file, it becomes multiple lines: >> >> e.g. >> >> <br/> >> <?xml version="1.0" standalone="yes"?><br/> >> line: 2 <br/> >> line: 3 <jnlp spec="1.0" href="SimpleJNLP.jnlp" xmlns="http://www.w3.org/1999/xhtml"><br/> >> line: 4 <information><br/> >> line: 5 <title>simple application</title><br/> >> line: 6 <vendor>IcedTea</vendor><br/> >> line: 7 <homepage >> href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"></homepage><br/> >> line: 8 <description></description><br/> >> line: 9 <offline-allowed></offline-allowed><br/> >> line: 10 </information><br/> >> line: 11 <resources><br/> >> line: 12 <j2se version="1.4+"></j2se><br/> >> line: 13 <jar href="SimpleJNLP.jar"></jar><br/> >> line: 14 </resources><br/> >> line: 15 <applet-desc name="SimpleJNLP Applet" main-class="SimpleJNLP"><br/> >> line: 16 </applet-desc><br/> >> line: 17 <br/> >> line: 18 <br/> >> line: 19 <br/> >> line: 20 </jnlp><br/> >> line: 21 <br/> >> line: 22 >> >> Also, I do not think it's useful to display the line numbers (e.g. line: 2, line: 3, ...). Could >> these be removed? >> >> I feel like sending multiple messages to the Java Console might be okay however I don't fully >> understand the concerns you have at the moment;; >> >> Personally, it would be most useful if there were no break tags or line numbers so I could copy >> and paste the output into a file and have it be pretty much the same as the original jnlp file. Is >> the Java Console limited and unable to do this? Maybe we can modify Java Console to support what >> we need;; > > Yes. It is deffinitly the right way. See new patch with your approach :) > > Thoughts? > > > J. > > > From jkang at redhat.com Wed Nov 19 15:10:50 2014 From: jkang at redhat.com (Jie Kang) Date: Wed, 19 Nov 2014 10:10:50 -0500 (EST) Subject: [rfc][icedtea-web] log jnlp file to console In-Reply-To: <546B669B.2070605@redhat.com> References: <546B5C3E.5030007@redhat.com> <546B669B.2070605@redhat.com> Message-ID: <1760884538.1255141.1416409850296.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > > > > > ----- Original Message ----- > >> On 10/21/2014 03:46 PM, Jiri Vanek wrote: > >>> hi! > >>> > >>> This is not just rfc, but RFC :) as I'm not sure which way to go. The > >>> only one I found suitbale - > >>> this oen - is not nice. > >>> > >>> Curently all the logs are going to logger, which determine if debug is on > >>> and what channels are > >>> enabled (stdout/err, file, console) > >>> > >>> According to those, it consume the message. This workflow had one > >>> exception, the reprinting of > >>> jnlpfiel, which went only to console, if debug was online. > >>> Most of the bugreports now contains whole console - and it is very good - > >>> but that measn the jnlp > >>> file is missing. > >>> > >>> > >>> The jnlpfile reprint was excluded, becasue console is using html > >>> formatting, to higlight outputs - > >>> for palintext the reprint is and willbe working fine, but it is not > >>> working > >>> with syntax higlighting > >>> from obvious reasons. > >>> > >>> I wont to avoid escaping of inpout - the message object is sahred between > >>> stdou/file/html > >>> console/plain console so to make special decoding for html console do > >>> need > >>> copy of it (and in case > >>> of console solid rework of console itself) and then proces via esapcping. > >>> Another issue is that html in java is terribly old, and hard to say what > >>> specification it supports > >>> (if any). > >>> > >>> To my surpise it support <plaintext> (yes nothing else do so...) So I > >>> have > >>> tryed to include the jnlp > >>> reprint wrapped by this tags. And it seems to be working fine wiht all > >>> supported outputs without any > >>> encodings or copying. > >>> > >>> There is drawback - eg firefox now have issues to show everything behind > >>> </plaintext> :( (note - > >>> <pre> do not work for jeeditorpane:( )) > >>> > >>> J. > >> ping, thoughts? I amde an attmept with <pre><plaintext></paintext></pre> > >> and > >> it did not helped. > >> Still the jnlp fiel should appear inconsole :( > > > > Hello, > > > > In user-testing, the JavaConsole now displays the entire jnlp file in one > > line, making it difficult to read. It seems the break tags do not get > > formatted when displayed in Java Console (at least for me). > > > > However if you copy and paste it into a text file, it becomes multiple > > lines: > > > > e.g. > > > > <br/> > > <?xml version="1.0" standalone="yes"?><br/> > > line: 2 <br/> > > line: 3 <jnlp spec="1.0" href="SimpleJNLP.jnlp" > > xmlns="http://www.w3.org/1999/xhtml"><br/> > > line: 4 <information><br/> > > line: 5 <title>simple application</title><br/> > > line: 6 <vendor>IcedTea</vendor><br/> > > line: 7 <homepage > > href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"></homepage><br/> > > line: 8 <description></description><br/> > > line: 9 <offline-allowed></offline-allowed><br/> > > line: 10 </information><br/> > > line: 11 <resources><br/> > > line: 12 <j2se version="1.4+"></j2se><br/> > > line: 13 <jar href="SimpleJNLP.jar"></jar><br/> > > line: 14 </resources><br/> > > line: 15 <applet-desc name="SimpleJNLP Applet" > > main-class="SimpleJNLP"><br/> > > line: 16 </applet-desc><br/> > > line: 17 <br/> > > line: 18 <br/> > > line: 19 <br/> > > line: 20 </jnlp><br/> > > line: 21 <br/> > > line: 22 > > > > Also, I do not think it's useful to display the line numbers (e.g. line: 2, > > line: 3, ...). Could these be removed? > > > > I feel like sending multiple messages to the Java Console might be okay > > however I don't fully understand the concerns you have at the moment;; > > > > Personally, it would be most useful if there were no break tags or line > > numbers so I could copy and paste the output into a file and have it be > > pretty much the same as the original jnlp file. Is the Java Console > > limited and unable to do this? Maybe we can modify Java Console to support > > what we need;; > > Yes. It is deffinitly the right way. See new patch with your approach :) > > Thoughts? Hello, It seems to work better than before for me :) Sample output: <?xml version="1.0" standalone="yes"?> line: 2 line: 3 line: 4 line: 5 <jnlp spec="1.0+" codebase="" href="" xmlns="http://www.w3.org/1999/xhtml"> line: 6? ? <information> line: 7? ? ? ? <title>Dynamic Tree Demo</title> line: 8? ? ? ? <vendor>Dynamic Team</vendor> line: 9? ? </information> line: 10? ? <resources> line: 11? ? ? ? line: 12? ? ? ? <j2se version="1.7+" href="http://java.sun.com/products/autodl/j2se"></j2se> line: 13? ? ? ? <jar href="DynamicTreeDemo.jar" main="true"></jar> line: 14 line: 15? ? </resources> line: 16? ? <applet-desc name="Dynamic Tree Demo Applet" main-class="appletComponentArch.DynamicTreeApplet" width="300" height="300"> line: 17? ? ? </applet-desc> line: 18? ? ? <update check="background"></update> line: 19 line: 20 </jnlp> line: 21 line: 22 I still prefer no line numbers hahah :\ <?xml version="1.0" standalone="yes"?> line: 2 line: 3 line: 4 line: 5 <jnlp spec="1.0+" codebase="" href="" xmlns="http://www.w3.org/1999/xhtml"> line: 6? ? <information> line: 7? ? ? ? <title>Dynamic Tree Demo</title> line: 8? ? ? ? <vendor>Dynamic Team</vendor> line: 9? ? </information> line: 10? ? <resources> line: 11? ? ? ? line: 12? ? ? ? <j2se version="1.7+" href="http://java.sun.com/products/autodl/j2se"></j2se> line: 13? ? ? ? <jar href="DynamicTreeDemo.jar" main="true"></jar> line: 14 line: 15? ? </resources> line: 16? ? <applet-desc name="Dynamic Tree Demo Applet" main-class="appletComponentArch.DynamicTreeApplet" width="300" height="300"> line: 17? ? ? </applet-desc> line: 18? ? ? <update check="background"></update> line: 19 line: 20 </jnlp> line: 21 line: 22 Maybe we can add a button to copy jnlp file with no line numbers? Anyways seems good now! Regards, > > > J. > > > > -- Jie Kang From jvanek at redhat.com Thu Nov 20 09:36:55 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 20 Nov 2014 10:36:55 +0100 Subject: [rfc][icedtea-web] AccessClassInPackage Reproducer Failure In-Reply-To: <54647121.9090003@redhat.com> References: <718500686.7415092.1415827545074.JavaMail.zimbra@redhat.com> <54647121.9090003@redhat.com> Message-ID: <546DB637.9@redhat.com> On 11/13/2014 09:51 AM, Jiri Vanek wrote: > On 11/12/2014 10:25 PM, Jie Kang wrote: >> Hello, >> >> >> I have been running a lot of reproducers lately and some consistent failures caught my eye today. >> In the AccessClassInPackage reproducers, a number of asserts are made including the following two: >> >> Assert.assertFalse("AccessClassInPackageTestLunch1 should not be terminated, but was", >> pr.wasTerminated); >> Assert.assertEquals((Integer) 0, pr.returnValue); >> >> >> The tests all fail due to these two asserts (wasTerminated is always true, not false, and return >> value is always 130 (exit due to control-C? [1]), not 0). When removing these lines and checking >> the tests, they all work and pass. The Class.forName call succeeds and is printed to stdout. >> >> So I am wondering, what are these two lines for? Is there some regression causing these failures? >> >> >> P.S. patch attached is for easy reference to code I am talking about above; not an actual patch >> (though we may want to apply a similar patch) >> >> [1] http://tldp.org/LDP/abs/html/exitcodes.html >> >> >> Regards, >> >> > hi! > > I will look into it later, but general hint is - those are javaws tests. Javaws should print it > out and clsoe itself. Tahts the "Assert.assertEquals((Integer) 0, pr.returnValue);" Fact that it do > not close itself and is timouted - and so killed - is wrong. Probablyjavaws hangs. > > So this really is serious regression. Our apps in head are keeping hanging much moire then in case of 1.5. J. From jvanek at redhat.com Thu Nov 20 10:30:42 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 20 Nov 2014 11:30:42 +0100 Subject: [icedta-web] Question about new parser Message-ID: <546DC2D2.60301@redhat.com> at first - thank you for it. Various playing with it were really cool and everything is working better then expected! Second - I have just noted this behavior: javaws about prints out : JNLP file location: about call privileged method: getCodeBase result: null java.net.MalformedURLException: no protocol: about Afaik it is incorrect as about isknown switch javaws -about *works* surprisingly as expected on contrary, eg: javaws Xoffline JNLP file location: Xoffline call privileged method: getCodeBase result: null java.net.MalformedURLException: no protocol: Xoffline Ahve same wrong result *but* javaws -Xoffline result into: JNLP file location: -Xoffline call privileged method: getCodeBase result: null java.net.MalformedURLException: no protocol: -Xoffline at java.net.URL.<init>(URL.java:586) at java.net.URL.<init>(URL.java:483) Again. So I think there is somewhere hidden bug.... J. From jvanek at redhat.com Thu Nov 20 10:49:59 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 20 Nov 2014 11:49:59 +0100 Subject: [icedta-web] Question about new parser In-Reply-To: <546DC2D2.60301@redhat.com> References: <546DC2D2.60301@redhat.com> Message-ID: <546DC757.8000407@redhat.com> Sorry for spam - I was accidentaly using 1.5 J. On 11/20/2014 11:30 AM, Jiri Vanek wrote: > at first - thank you for it. Various playing with it were really cool and everything is working > better then expected! > > Second - I have just noted this behavior: > > javaws about > prints out : > JNLP file location: about > call privileged method: getCodeBase > result: null > java.net.MalformedURLException: no protocol: about > > Afaik it is incorrect as about isknown switch > > > javaws -about > *works* surprisingly as expected > > on contrary, eg: > javaws Xoffline > JNLP file location: Xoffline > call privileged method: getCodeBase > result: null > java.net.MalformedURLException: no protocol: Xoffline > > Ahve same wrong result > > *but* > javaws -Xoffline > result into: > JNLP file location: -Xoffline > call privileged method: getCodeBase > result: null > java.net.MalformedURLException: no protocol: -Xoffline > at java.net.URL.<init>(URL.java:586) > at java.net.URL.<init>(URL.java:483) > > Again. > > > So I think there is somewhere hidden bug.... > > > J. From jvanek at redhat.com Thu Nov 20 15:27:25 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 20 Nov 2014 16:27:25 +0100 Subject: [rfc][icedtea-web] 1.5.2 release? In-Reply-To: <546622C2.5050305@redhat.com> References: <544A4C3A.6010507@redhat.com> <544BBF23.5010307@redhat.com> <5458FCF0.3060504@redhat.com> <545A5C12.1000408@redhat.com> <545A5CD2.70707@redhat.com> <545A5D97.803@redhat.com> <1599683181.4258978.1415222751770.JavaMail.zimbra@redhat.com> <545B3A67.9020509@redhat.com> <5460CF83.2080509@redhat.com> <546622C2.5050305@redhat.com> Message-ID: <546E085D.9070903@redhat.com> Hi All, please consider 1.5 branch of ITW as frozen. Lukas, Andrew and Jie. Here pre tarball of 1.5.2 http://icedtea.wildebeest.org/download/source/icedtea-web-1.5.2.tar.gz 7b82fd7138d14c002b69898a873be0cf icedtea-web-1.5.2.tar.gz I have tested it on jdk 7 and 8 and looks good. 6 is remianing on my side. Please try to test it as heavily as usually - especially all reproducers on firefox. You can use my deaily testing for comparsion - all manual testcases on firefox/javaws - all should work with jdk 6,7,8, feel free to split work among yourselves. - unittests, cpp tests whatever you think is reasonable I would like to release this really minor release at wednesday. Thank you in advance! J. On 11/14/2014 04:41 PM, Jiri Vanek wrote: > On 11/10/2014 03:45 PM, Jiri Vanek wrote: >> On 11/06/2014 10:07 AM, Jiri Vanek wrote: >>> On 11/05/2014 10:25 PM, Lukasz Dracz wrote: >>>> Hello, >>>> >>>> I don't think there is a point to backporting >>>> http://icedtea.classpath.org/hg/icedtea-web/rev/d8e057783109 >>>> since I would probably need to backport also: >>>> http://icedtea.classpath.org/hg/icedtea-web/rev/e30d71ab91c6 which was the refactor of the cache >>>> panel. >>>> I can do that if you still think it would be worthwhile to be backported. >>>> All it adds was a tooltip for the spinner, and 1.5 still uses the slider. I could add a tooltip >>>> for the slider I guess but they are somewhat different so the Messages would be different. >>>> >>> >>> Fair enough. Then do not backport it. ty fir check! >>> >>>> Sorry for missing the IRC chat I was in a thermostat scrum, then went to lunch without noticing. >>>> I can do the PL translations, my PL should be good enough if needed. I speak it regularly at >>>> home, and attended Polish Saturday School here in Canada from elementary to high school. I do >>>> have a good understanding of Polish though I must admit my writing is a little bit rusty with all >>>> the Polish grammar rules but I can look stuff up if I am unsure :) >>>> What do we want translated specifically ? >>>> >>>> I translated the two parts from Andrew's patch in the messages.properties >>>> >>>> CertWarnHTTPSAcceptTip=Zaakceptuj ten certyfikat i zaufaj po??czenie przez HTTPS >>>> (Accept this certificate and trust a connection via HTTPS) >>>> >>>> CertWarnHTTPSRejectTip=Nie akceptuj ten certyfikat i nie buduj po??czenie HTTPS >>>> (Do not Accept this certificate and do not build a HTTPS connection) >>>> Establish looked/sounded odd to me so I thought build was more natural. >>>> >>> >>> Great! ty! This is all :) >>> >>> Once Andrew pushes his backport, please push thsoe two lines. >>> (ps: go on wiht transaltor :) >>>> I have attached the translation, is there anywhere else that needs editing or translating ? >>>> >>>> Thank you, >>>> Lukasz Dracz >>>> >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Andrew Azores" <aazores at redhat.com> >>>>> To: "Jiri Vanek" <jvanek at redhat.com>, "IcedTea Distro List" <distro-pkg-dev at openjdk.java.net>, >>>>> "Lukasz Dracz" >>>>> <ldracz at redhat.com> >>>>> Sent: Wednesday, November 5, 2014 12:25:43 PM >>>>> Subject: Re: [rfc][icedtea-web] 1.5.2 release? >>>>> >>>>> On 11/05/2014 12:22 PM, Jiri Vanek wrote: >>>>>> On 11/05/2014 06:19 PM, Andrew Azores wrote: >>>>>>> On 11/04/2014 11:21 AM, Jiri Vanek wrote: >>>>>>>> On 10/25/2014 05:17 PM, Andrew Azores wrote: >>>>>>>>> On 10/24/2014 08:55 AM, Jiri Vanek wrote: >>>>>>>>>> Hi! >>>>>>>>>> >>>>>>>>>> There appeared few fixes in head which are maybe worthy to go to >>>>>>>>>> 1.5 and >>>>>>>>>> afterward calling for release: >>>>>>>>>> >>>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/99d5407fab4a >>>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/dd6be5e03667 >>>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/df05d1de5af4 >>>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/c6af2f50a95e >>>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/6d62f68fb037 >>>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/d8e057783109 >>>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/90faf53bb981 >>>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/2979fa371add >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thoughts? >>>>>>>>>> >>>>>>>>>> J. >>>>>>>>> >>>>>>>>> Sounds like a good plan to me. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>> Hi! I have backported most of them today, except two. >>>>>>>> "2" is Andrew's and "3" Lukas' >>>>>>>> >>>>>>>> "4" is mine, but it is(?) already backported. >>>>>>>> >>>>>>>> Guys, please decide whether yours 2 and/or 3 should go to 1.5. If so, >>>>>>>> please backport. After doing so, and once i got confirmed RH115417 >>>>>>>> 7, I will try to do a release. >>>>>>>> >>>>>>>> >>>>>>>> TY! >>>>>>>> >>>>>>>> J. >>>>>>> >>>>>>> Attached is the fixed backport for #2. >>>>>>> >>>>>>> Thanks, >>>>>>> -- >>>>>>> Andrew Azores >>>>>>> >>>>>>> temporary-permissions-button-npe-fix-backport.patch >>>>>>> >>>>>>> >>>>>>> diff --git a/ChangeLog b/ChangeLog >>>>>>> --- a/ChangeLog >>>>>>> +++ b/ChangeLog >>>>>>> @@ -1,3 +1,18 @@ >>>>>>> +2014-11-05 Andrew Azores<aazores at redhat.com> >>>>>>> + >>>>>>> + * netx/net/sourceforge/jnlp/resources/Messages.properties >>>>>>> + (CertWarnHTTPSAcceptTip, CertWarnHTTPSRejectTip): new messages more >>>>>>> + applicable for HTTPS cert warning dialogs >>>>>>> + * netx/net/sourceforge/jnlp/security/dialogs/CertWarningPane.java: >>>>>>> + distinguish between HTTPS cert warnings and signed applet cert >>>>>>> warnings. >>>>>>> + Display appropriate text labels and buttons corresponding to >>>>>>> either case. >>>>>>> + * >>>>>>> netx/net/sourceforge/jnlp/security/dialogs/TemporaryPermissionsButton.java: >>>>>>> >>>>>>> + If any of file, securityDelegate, or linkedButton are null, simply >>>>>>> + disable this component and do not add component listeners >>>>>>> dependent upon >>>>>>> + these fields. Also, do not add multiple groups of permissions, >>>>>>> and do not >>>>>>> + add the permissions to the securityDelegate until the >>>>>>> linkedButton is >>>>>>> + actually clicked (rather than when the menu item is clicked) >>>>>>> + >>>>>>> 2014-10-21 Jiri Vanek<jvanek at redhat.com> >>>>>>> >>>>>>> Fixed case when already decoded file is wonted from cache >>>>>>> (RH1154177) >>>>>>> diff --git a/netx/net/sourceforge/jnlp/resources/Messages.properties >>>>>>> b/netx/net/sourceforge/jnlp/resources/Messages.properties >>>>>>> --- a/netx/net/sourceforge/jnlp/resources/Messages.properties >>>>>>> +++ b/netx/net/sourceforge/jnlp/resources/Messages.properties >>>>>>> @@ -25,6 +25,8 @@ >>>>>>> CertWarnCancelTip=Do not run this applet >>>>>>> CertWarnPolicyTip=Advanced sandbox settings >>>>>>> CertWarnPolicyEditorItem=Launch PolicyEditor >>>>>>> +CertWarnHTTPSAcceptTip=Accept this certificate and trust the HTTPS >>>>>>> connection >>>>>>> +CertWarnHTTPSRejectTip=Do not accept this certificate and do not >>>>>>> establish the HTTPS connection >>>>>>> >>>>>> >>>>>> >>>>>> Hmm. What to do with those two messages? I can supply CZ trasnaltion, >>>>>> maybe also DE (with help of Severin, Roman or similar :) ) How about >>>>>> PL? I rembere There was somebody in your surrounding. Wasnt? >>>>>> >>>>>> By otherwise - you agree it is ok for 1.5 thsi backport oook? >>>>>> >>>>>> Ty! >>>>>> >>>>>> J. >>>>>> >>>>> >>>>> Yup, otherwise the backport looks/sounds fine to me. >>>>> >>>>> I do know someone from school who might be able to provide PL >>>>> translations still. But... what about ldracz? ;) probably easier than >>>>> pulling in some other "volunteer". >>>>> >>>>> Thanks, >>>>> -- >>>>> Andrew Azores >>>>> >>> >> >> >> So on my side ITW 1.5.2 loosk good. I'm still a bit hesitating with waiting to two more fixes: >> - the [rfc][icedtea-web] merge property arguments into config singleton > - pushed to head. Once reproducer done, will be backported to 1.5 > >> - and Re: [rfc][icedtea-web] Fix to PluginMessage dates for PR2063 > - afaik work in progress. >> >> Especially the second one should be harmless and is bit nasty to be presented. >> >> >> thoughts? > From gitne at gmx.de Thu Nov 20 17:34:11 2014 From: gitne at gmx.de (Jacob Wisor) Date: Thu, 20 Nov 2014 18:34:11 +0100 Subject: [rfc][icedtea-web] 1.5.2 release? In-Reply-To: <546622C2.5050305@redhat.com> References: <544A4C3A.6010507@redhat.com> <544BBF23.5010307@redhat.com> <5458FCF0.3060504@redhat.com> <545A5C12.1000408@redhat.com> <545A5CD2.70707@redhat.com> <545A5D97.803@redhat.com> <1599683181.4258978.1415222751770.JavaMail.zimbra@redhat.com> <545B3A67.9020509@redhat.com> <5460CF83.2080509@redhat.com> <546622C2.5050305@redhat.com> Message-ID: <1416504851.4070.52.camel@ubuntu> On Fri, 2014-11-14 at 16:41 +0100, Jiri Vanek wrote: > On 11/10/2014 03:45 PM, Jiri Vanek wrote: > > On 11/06/2014 10:07 AM, Jiri Vanek wrote: > >> On 11/05/2014 10:25 PM, Lukasz Dracz wrote: > >>> [...] > >>> Sorry for missing the IRC chat I was in a thermostat scrum, then went to lunch without noticing. > >>> I can do the PL translations, my PL should be good enough if needed. I speak it regularly at > >>> home, and attended Polish Saturday School here in Canada from elementary to high school. I do > >>> have a good understanding of Polish though I must admit my writing is a little bit rusty with all > >>> the Polish grammar rules but I can look stuff up if I am unsure :) > >>> What do we want translated specifically ? > >>> > >>> I translated the two parts from Andrew's patch in the messages.properties > >>> > >>> CertWarnHTTPSAcceptTip=Zaakceptuj ten certyfikat i zaufaj po??czenie przez HTTPS > >>> (Accept this certificate and trust a connection via HTTPS) I just wanted to share some notes on this translation. The message bears text for a tooltip which according to UI style guidelines has the purpose to describe a control's function or effect, not convey a command. Hence, neither the source nor the translation should not use the imperative mode. I don't blame Lukasz because the English source is actually grammatically wrong either. It should read "Accepts this certificate and trusts a connection via HTTPS". So, the translation should read "Akceptuje ten certyfikat i ufa po??czeniu HTTPS." > >>> CertWarnHTTPSRejectTip=Nie akceptuj ten certyfikat i nie buduj po??czenie HTTPS > >>> (Do not Accept this certificate and do not build a HTTPS connection) > >>> Establish looked/sounded odd to me so I thought build was more natural. Same goes here, it should read "Rejects this certificate and does not establish a HTTPS connection" in English. The proper translation for this would be "Porzuca ten certyfikat i nie nawi?zuje po??czenia HTTPS". In Polish, connections are only "built" when physical objects are built too. ;-) Immaterial connections are just linked. However, they can always be created (tworzy?). And finally, style; no one ever talks nor writes like this "Nie akceptuj ten certyfikat...". Although it is grammatically correct, it's ugly and confusing in this context. The best thing to do here is to use the opposite term for accepting (akceptowa?), hence to reject something (odrzuca?/porzuca?/odmawia?). Regards, Jacob From jkang at redhat.com Fri Nov 21 20:31:38 2014 From: jkang at redhat.com (Jie Kang) Date: Fri, 21 Nov 2014 15:31:38 -0500 (EST) Subject: [rfc][icedtea-web] Remove use of clear cache in PackGZip Tests In-Reply-To: <403812564.2731033.1416601798078.JavaMail.zimbra@redhat.com> Message-ID: <2007629369.2731433.1416601898090.JavaMail.zimbra@redhat.com> Hello, I just noticed that my push for the PackGZip tests included a mistake where the test would clear cache in @Setup. This patch removes the method call. Okay to push? Regards, -- Jie Kang -------------- next part -------------- A non-text attachment was scrubbed... Name: itw-packgzip-clearcache-fix-1.patch Type: text/x-patch Size: 473 bytes Desc: not available URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141121/f4414248/itw-packgzip-clearcache-fix-1.patch> From jvanek at redhat.com Fri Nov 21 20:35:08 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 21 Nov 2014 21:35:08 +0100 Subject: [rfc][icedtea-web] Remove use of clear cache in PackGZip Tests In-Reply-To: <2007629369.2731433.1416601898090.JavaMail.zimbra@redhat.com> References: <2007629369.2731433.1416601898090.JavaMail.zimbra@redhat.com> Message-ID: <546FA1FC.9020209@redhat.com> On 11/21/2014 09:31 PM, Jie Kang wrote: > Hello, > > > I just noticed that my push for the PackGZip tests included a mistake where the test would clear cache in @Setup. > > This patch removes the method call. > > Okay to push? > > > Regards, > Well, why to not clean in @before? It gave sense to me to clear.... J. From jkang at redhat.com Fri Nov 21 20:41:47 2014 From: jkang at redhat.com (Jie Kang) Date: Fri, 21 Nov 2014 15:41:47 -0500 (EST) Subject: [rfc][icedtea-web] Remove use of clear cache in PackGZip Tests In-Reply-To: <546FA1FC.9020209@redhat.com> References: <2007629369.2731433.1416601898090.JavaMail.zimbra@redhat.com> <546FA1FC.9020209@redhat.com> Message-ID: <1922203767.2737468.1416602507384.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 11/21/2014 09:31 PM, Jie Kang wrote: > > Hello, > > > > > > I just noticed that my push for the PackGZip tests included a mistake where > > the test would clear cache in @Setup. > > > > This patch removes the method call. > > > > Okay to push? > > > > > > Regards, > > > Well, why to not clean in @before? It gave sense to me to clear.... Main reason for me is that I don't remember any other reproducer that deletes the whole cache before running. I don't think it's dangerous. Note that 'CacheUtil.clearCache' deletes the entire cache. So when you run all the reproducers and it hits the PackGZip reproducer, the cache will be reset to empty... Regards, > > J. > -- Jie Kang From jvanek at redhat.com Fri Nov 21 20:57:59 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 21 Nov 2014 21:57:59 +0100 Subject: [rfc][icedtea-web] Remove use of clear cache in PackGZip Tests In-Reply-To: <1922203767.2737468.1416602507384.JavaMail.zimbra@redhat.com> References: <2007629369.2731433.1416601898090.JavaMail.zimbra@redhat.com> <546FA1FC.9020209@redhat.com> <1922203767.2737468.1416602507384.JavaMail.zimbra@redhat.com> Message-ID: <546FA757.1030802@redhat.com> On 11/21/2014 09:41 PM, Jie Kang wrote: > > > ----- Original Message ----- >> On 11/21/2014 09:31 PM, Jie Kang wrote: >>> Hello, >>> >>> >>> I just noticed that my push for the PackGZip tests included a mistake where >>> the test would clear cache in @Setup. >>> >>> This patch removes the method call. >>> >>> Okay to push? >>> >>> >>> Regards, >>> >> Well, why to not clean in @before? It gave sense to me to clear.... > > Main reason for me is that I don't remember any other reproducer that deletes the whole cache before running. I don't think it's dangerous. Yes, but no other reproducer is verifying cache content. See eg clear cache reproducer :) It is clearing and filing it all around manytimes... > > Note that 'CacheUtil.clearCache' deletes the entire cache. So when you run all the reproducers and it hits the PackGZip reproducer, the cache will be reset to empty... And it do not hurt. Better to have cache clean, then have it unpredictable. I'm +1 for keeping those lines in. Btw, are you able to reproduce the issue aph hitted? I'm not.... Thanx, J. > > > Regards, > > >> >> J. >> > From jvanek at redhat.com Fri Nov 21 21:05:46 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 21 Nov 2014 22:05:46 +0100 Subject: [rfc][icedtea-web] 1.5.2 release? In-Reply-To: <1416504851.4070.52.camel@ubuntu> References: <544A4C3A.6010507@redhat.com> <544BBF23.5010307@redhat.com> <5458FCF0.3060504@redhat.com> <545A5C12.1000408@redhat.com> <545A5CD2.70707@redhat.com> <545A5D97.803@redhat.com> <1599683181.4258978.1415222751770.JavaMail.zimbra@redhat.com> <545B3A67.9020509@redhat.com> <5460CF83.2080509@redhat.com> <546622C2.5050305@redhat.com> <1416504851.4070.52.camel@ubuntu> Message-ID: <546FA92A.10708@redhat.com> On 11/20/2014 06:34 PM, Jacob Wisor wrote: > On Fri, 2014-11-14 at 16:41 +0100, Jiri Vanek wrote: >> On 11/10/2014 03:45 PM, Jiri Vanek wrote: >>> On 11/06/2014 10:07 AM, Jiri Vanek wrote: >>>> On 11/05/2014 10:25 PM, Lukasz Dracz wrote: >>>>> [...] >>>>> Sorry for missing the IRC chat I was in a thermostat scrum, then went to lunch without noticing. >>>>> I can do the PL translations, my PL should be good enough if needed. I speak it regularly at >>>>> home, and attended Polish Saturday School here in Canada from elementary to high school. I do >>>>> have a good understanding of Polish though I must admit my writing is a little bit rusty with all >>>>> the Polish grammar rules but I can look stuff up if I am unsure :) >>>>> What do we want translated specifically ? >>>>> >>>>> I translated the two parts from Andrew's patch in the messages.properties >>>>> >>>>> CertWarnHTTPSAcceptTip=Zaakceptuj ten certyfikat i zaufaj po??czenie przez HTTPS >>>>> (Accept this certificate and trust a connection via HTTPS) > > I just wanted to share some notes on this translation. > The message bears text for a tooltip which according to UI style > guidelines has the purpose to describe a control's function or effect, > not convey a command. Hence, neither the source nor the translation > should not use the imperative mode. I don't blame Lukasz because the > English source is actually grammatically wrong either. It should read > "Accepts this certificate and trusts a connection via HTTPS". So, the > translation should read "Akceptuje ten certyfikat i ufa po??czeniu > HTTPS." > >>>>> CertWarnHTTPSRejectTip=Nie akceptuj ten certyfikat i nie buduj po??czenie HTTPS >>>>> (Do not Accept this certificate and do not build a HTTPS connection) >>>>> Establish looked/sounded odd to me so I thought build was more natural. > > Same goes here, it should read "Rejects this certificate and does not > establish a HTTPS connection" in English. The proper translation for > this would be "Porzuca ten certyfikat i nie nawi?zuje po??czenia HTTPS". > In Polish, connections are only "built" when physical objects are built > too. ;-) Immaterial connections are just linked. However, they can > always be created (tworzy?). > And finally, style; no one ever talks nor writes like this "Nie akceptuj > ten certyfikat...". Although it is grammatically correct, it's ugly and > confusing in this context. The best thing to do here is to use the > opposite term for accepting (akceptowa?), hence to reject something > (odrzuca?/porzuca?/odmawia?). > Hi Jacob! And welcome bac:) if back is the word here. After the issue with docs I got afraid you are entirely and forever gone :( Well - those lines were included only in 1.5 - as addition to the backport - I guess You noted - to keep translations complete. I'm ok with fix those two strings both in head and in 1.5 for english. And translations in 1.5. . Those sentences are not translated in head as I wonted to touch the i18n area as few as possible. As you have strongest language skills around, feel free to fix without any other review. The 1.5 is not yet tagged. thank you very much! j. From jkang at redhat.com Fri Nov 21 21:30:29 2014 From: jkang at redhat.com (Jie Kang) Date: Fri, 21 Nov 2014 16:30:29 -0500 (EST) Subject: [rfc][icedtea-web] Remove use of clear cache in PackGZip Tests In-Reply-To: <546FA757.1030802@redhat.com> References: <2007629369.2731433.1416601898090.JavaMail.zimbra@redhat.com> <546FA1FC.9020209@redhat.com> <1922203767.2737468.1416602507384.JavaMail.zimbra@redhat.com> <546FA757.1030802@redhat.com> Message-ID: <1342570403.2761515.1416605429661.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 11/21/2014 09:41 PM, Jie Kang wrote: > > > > > > ----- Original Message ----- > >> On 11/21/2014 09:31 PM, Jie Kang wrote: > >>> Hello, > >>> > >>> > >>> I just noticed that my push for the PackGZip tests included a mistake > >>> where > >>> the test would clear cache in @Setup. > >>> > >>> This patch removes the method call. > >>> > >>> Okay to push? > >>> > >>> > >>> Regards, > >>> > >> Well, why to not clean in @before? It gave sense to me to clear.... > > > > Main reason for me is that I don't remember any other reproducer that > > deletes the whole cache before running. I don't think it's dangerous. > > Yes, but no other reproducer is verifying cache content. See eg clear cache > reproducer :) It is clearing and filing it all around manytimes... > > > > Note that 'CacheUtil.clearCache' deletes the entire cache. So when you run > > all the reproducers and it hits the PackGZip reproducer, the cache will be > > reset to empty... > > And it do not hurt. Better to have cache clean, then have it unpredictable. > > I'm +1 for keeping those lines in. Okay then. I thought a un-clean cache would be more useful so we can possibly find problems in cache hahah... I don't really have an issue with keeping it in. > > > Btw, are you able to reproduce the issue aph hitted? I'm not.... It is a very specific situation that occurred to cause the StringOutOfBoundsException, with 14to15 transfer messing up somewhere, invalid content in 'recently_used' file, and you could say 'bad luck' :\ I believe could create a 'reproducer' but it would involve creating dummy files on the file system. private static String pathToURLPath(String path) { int len = cacheDir.length(); int index = path.indexOf(File.separatorChar, len + 1); return path.substring(index); } The SOOB-Exception was because int index = path.indexOf(File.separatorChar, len + 1) = -1 .indexOf(..) only returns -1 if File.separatorChar is not found in 'path' from index 'len+1' to the end of the string. and len+1 is from cacheDir.length() >From looking at how 'cacheDir' is constructed, I would say most probable that String: 'path' was not valid. This 'path' comes from the LRU 'recently_used' file. So to reproduce, we need to create a situation where LRU 'recently_used' is corrupted. The simplest way is to write a bad entry into the file. Something like: 1416601158426,1=/home/jkang/.cache/icedtea-web/cache/thiswillprobablyfail(i-hope) I think for a long-term fix, we should look at improving the cache system to not blindly assume LRU file is correct. And of course, figure out what to do when it is corrupted. ie. redownload into non-corrupt location, remove corrupt entries, etc. etc. Also:: CacheLRUWrapper::checkData() This function is supposed to check LRU for corrupt entries, but the 'path' checking portion only has code: // 2. check path format - does the path look correct? if (path != null) { if (path.indexOf(cacheDir) < 0) { it.remove(); modified = true; } } else { it.remove(); modified = true; } This only checks that there is a path and that it contains the cacheDir at the front. This should be improved. (file should probably exist, be a valid directory format... etc etc) I hope this helps! If you'd like, I can try to write a reproducer on Monday. Regards, > > Thanx, J. > > > > > > Regards, > > > > > >> > >> J. > >> > > > > -- Jie Kang From gitne at gmx.de Fri Nov 21 23:04:29 2014 From: gitne at gmx.de (Jakob Wisor) Date: Sat, 22 Nov 2014 00:04:29 +0100 Subject: [rfc][icedtea-web] 1.5.2 release? In-Reply-To: <546FA92A.10708@redhat.com> References: <544A4C3A.6010507@redhat.com> <544BBF23.5010307@redhat.com> <5458FCF0.3060504@redhat.com> <545A5C12.1000408@redhat.com> <545A5CD2.70707@redhat.com> <545A5D97.803@redhat.com> <1599683181.4258978.1415222751770.JavaMail.zimbra@redhat.com> <545B3A67.9020509@redhat.com> <5460CF83.2080509@redhat.com> <546622C2.5050305@redhat.com> <1416504851.4070.52.camel@ubuntu> <546FA92A.10708@redhat.com> Message-ID: <1416611069.6374.64.camel@gitne> On Fri, 2014-11-21 at 22:05 +0100, Jiri Vanek wrote: > On 11/20/2014 06:34 PM, Jacob Wisor wrote: > > On Fri, 2014-11-14 at 16:41 +0100, Jiri Vanek wrote: > >> On 11/10/2014 03:45 PM, Jiri Vanek wrote: > >>> On 11/06/2014 10:07 AM, Jiri Vanek wrote: > >>>> On 11/05/2014 10:25 PM, Lukasz Dracz wrote: > >>>>> [...] > >>>>> Sorry for missing the IRC chat I was in a thermostat scrum, then went to lunch without noticing. > >>>>> I can do the PL translations, my PL should be good enough if needed. I speak it regularly at > >>>>> home, and attended Polish Saturday School here in Canada from elementary to high school. I do > >>>>> have a good understanding of Polish though I must admit my writing is a little bit rusty with all > >>>>> the Polish grammar rules but I can look stuff up if I am unsure :) > >>>>> What do we want translated specifically ? > >>>>> > >>>>> I translated the two parts from Andrew's patch in the messages.properties > >>>>> > >>>>> CertWarnHTTPSAcceptTip=Zaakceptuj ten certyfikat i zaufaj po??czenie przez HTTPS > >>>>> (Accept this certificate and trust a connection via HTTPS) > > > > I just wanted to share some notes on this translation. > > The message bears text for a tooltip which according to UI style > > guidelines has the purpose to describe a control's function or effect, > > not convey a command. Hence, neither the source nor the translation > > should not use the imperative mode. I don't blame Lukasz because the > > English source is actually grammatically wrong either. It should read > > "Accepts this certificate and trusts a connection via HTTPS". So, the > > translation should read "Akceptuje ten certyfikat i ufa po??czeniu > > HTTPS." > > > >>>>> CertWarnHTTPSRejectTip=Nie akceptuj ten certyfikat i nie buduj po??czenie HTTPS > >>>>> (Do not Accept this certificate and do not build a HTTPS connection) > >>>>> Establish looked/sounded odd to me so I thought build was more natural. > > > > Same goes here, it should read "Rejects this certificate and does not > > establish a HTTPS connection" in English. The proper translation for > > this would be "Porzuca ten certyfikat i nie nawi?zuje po??czenia HTTPS". > > In Polish, connections are only "built" when physical objects are built > > too. ;-) Immaterial connections are just linked. However, they can > > always be created (tworzy?). > > And finally, style; no one ever talks nor writes like this "Nie akceptuj > > ten certyfikat...". Although it is grammatically correct, it's ugly and > > confusing in this context. The best thing to do here is to use the > > opposite term for accepting (akceptowa?), hence to reject something > > (odrzuca?/porzuca?/odmawia?). > > > > Hi Jacob! > > And welcome bac:) if back is the word here. After the issue with docs I got afraid you are entirely and forever gone :( No, I just went on vacation, and when I came back my hdd broke (don't worry, I have a full backup). S.M.A.R.T. was not of any real help either. :-( Instead of issuing some helpful warning some time before the hdd crashed it just diagnosed bad sectors after the fact... well, kind of useless technology I guess :-D On the bright side, I am going to get a shiny brand new machine. Anyways, I have to postpone my work until my new machine comes in. > Well - those lines were included only in 1.5 - as addition to the backport - I guess You noted - to keep translations complete. > > I'm ok with fix those two strings both in head and in 1.5 for english. And translations in 1.5. . Those sentences are not translated in head as I wonted to touch the i18n area as few as possible. > > As you have strongest language skills around, feel free to fix without any other review. The 1.5 is not yet tagged. Yeah, I'll have a look at this as soon as I get setup up again and ready to go. For now, I am operating in "emergency mode" only, so nothing much besides emails and browsing. :-\ Regards Jacob From jvanek at redhat.com Sat Nov 22 14:45:40 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Sat, 22 Nov 2014 15:45:40 +0100 Subject: [rfc][icedtea-web] Remove use of clear cache in PackGZip Tests In-Reply-To: <1342570403.2761515.1416605429661.JavaMail.zimbra@redhat.com> References: <2007629369.2731433.1416601898090.JavaMail.zimbra@redhat.com> <546FA1FC.9020209@redhat.com> <1922203767.2737468.1416602507384.JavaMail.zimbra@redhat.com> <546FA757.1030802@redhat.com> <1342570403.2761515.1416605429661.JavaMail.zimbra@redhat.com> Message-ID: <5470A194.6070904@redhat.com> On 11/21/2014 10:30 PM, Jie Kang wrote: > > > ----- Original Message ----- >> On 11/21/2014 09:41 PM, Jie Kang wrote: >>> >>> >>> ----- Original Message ----- >>>> On 11/21/2014 09:31 PM, Jie Kang wrote: >>>>> Hello, >>>>> >>>>> >>>>> I just noticed that my push for the PackGZip tests included a mistake >>>>> where >>>>> the test would clear cache in @Setup. >>>>> >>>>> This patch removes the method call. >>>>> >>>>> Okay to push? >>>>> >>>>> >>>>> Regards, >>>>> >>>> Well, why to not clean in @before? It gave sense to me to clear.... >>> >>> Main reason for me is that I don't remember any other reproducer that >>> deletes the whole cache before running. I don't think it's dangerous. >> >> Yes, but no other reproducer is verifying cache content. See eg clear cache >> reproducer :) It is clearing and filing it all around manytimes... >>> >>> Note that 'CacheUtil.clearCache' deletes the entire cache. So when you run >>> all the reproducers and it hits the PackGZip reproducer, the cache will be >>> reset to empty... >> >> And it do not hurt. Better to have cache clean, then have it unpredictable. >> >> I'm +1 for keeping those lines in. > > Okay then. I thought a un-clean cache would be more useful so we can possibly find problems in cache hahah... I don't really have an issue with keeping it in. > >> >> >> Btw, are you able to reproduce the issue aph hitted? I'm not.... > > It is a very specific situation that occurred to cause the StringOutOfBoundsException, with 14to15 transfer messing up somewhere, invalid content in 'recently_used' file, and you could say 'bad luck' :\ > > I believe could create a 'reproducer' but it would involve creating dummy files on the file system. > > > private static String pathToURLPath(String path) { > int len = cacheDir.length(); > int index = path.indexOf(File.separatorChar, len + 1); > return path.substring(index); > } > > > The SOOB-Exception was because > int index = path.indexOf(File.separatorChar, len + 1) > = -1 > > .indexOf(..) only returns -1 if File.separatorChar is not found in 'path' from index 'len+1' to the end of the string. > > and len+1 is from cacheDir.length() > > > From looking at how 'cacheDir' is constructed, I would say most probable that String: 'path' was not valid. > > This 'path' comes from the LRU 'recently_used' file. > > So to reproduce, we need to create a situation where LRU 'recently_used' is corrupted. The simplest way is to write a bad entry into the file. > > Something like: > > 1416601158426,1=/home/jkang/.cache/icedtea-web/cache/thiswillprobablyfail(i-hope) > > > > I think for a long-term fix, we should look at improving the cache system to not blindly assume LRU file is correct. And of course, figure out what to do when it is corrupted. ie. redownload into non-corrupt location, remove corrupt entries, etc. etc. > > > > Also:: > > CacheLRUWrapper::checkData() > This function is supposed to check LRU for corrupt entries, but the 'path' checking portion only has code: > > // 2. check path format - does the path look correct? > if (path != null) { > if (path.indexOf(cacheDir) < 0) { > it.remove(); > modified = true; > } > } else { > it.remove(); > modified = true; > } > > > This only checks that there is a path and that it contains the cacheDir at the front. This should be improved. (file should probably exist, be a valid directory format... etc etc) > > > > I hope this helps! > > If you'd like, I can try to write a reproducer on Monday. > > Regards, > > >> Long story short - the issue was broken cache. Then the dialog "lunch error" apeard. On this dialog is big button "clean cache" and even somebody so skilled as aph did not click it.... I must b missing something,... J. From jvanek at redhat.com Sat Nov 22 15:03:26 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Sat, 22 Nov 2014 16:03:26 +0100 Subject: [rfc][icedtea-web][icedtea-web-1.5.2] allow also skip of permissions attribute check in case of disabled attributes check Message-ID: <5470A5BE.8040504@redhat.com> Hi! The permission attribute is still incompletely implemented and mixed signatures apps are suffering not working with itw. by specifing it. The implementation troubles ate in ITW two: - it can happen that application is loaded by various jnlpfiles => one jnlp file is signed, secondnot : however whole application is signed- so check in second jnlp file on sandbox attribute will finish by error. - fix it to have two kinds of attribute checkers - one jnlp file specific, and one global for whole app. Some attibutes are then checked globaly, some only on iven jnlpfile - the applictaion can be loaded by several classloaders each of them with differet permissions. This is real cause of issues with ^ and I do not know cure on it. The reproducers are all jogam or joglor .... applets on http://icedtea.classpath.org/wiki/IcedTea-Web-Tests . As for head - I'm working on oflfine integration of applets, and it is quite blocker. As for 1.5 jog* people have already reported this (got lost...) and we should make thi swork for them at least by this workarround. J. ok to head and 1.5? diff -r f1586e8af6b9 netx/net/sourceforge/jnlp/runtime/ManifestAttributesChecker.java --- a/netx/net/sourceforge/jnlp/runtime/ManifestAttributesChecker.java Wed Nov 19 18:33:56 2014 +0100 +++ b/netx/net/sourceforge/jnlp/runtime/ManifestAttributesChecker.java Sat Nov 22 15:53:38 2014 +0100 @@ -75,15 +75,14 @@ } void checkAll() throws LaunchException { - checkPermissionsAttribute(); if (isCheckEnabled()) { + checkPermissionsAttribute(); checkTrustedOnlyAttribute(); checkCodebaseAttribute(); checkPermissionsAttribute(); checkApplicationLibraryAllowableCodebaseAttribute(); } else { - OutputController.getLogger().log(OutputController.Level.WARNING_ALL, "Manifest attribute checks are disabled." - + " The Permissions attribute will be enforced but other manifest attributes will be ignored."); + OutputController.getLogger().log(OutputController.Level.WARNING_ALL, "Manifest attribute checks are disabled."); } } From aph at redhat.com Sun Nov 23 08:16:29 2014 From: aph at redhat.com (Andrew Haley) Date: Sun, 23 Nov 2014 08:16:29 +0000 Subject: [rfc][icedtea-web] Remove use of clear cache in PackGZip Tests In-Reply-To: <5470A194.6070904@redhat.com> References: <2007629369.2731433.1416601898090.JavaMail.zimbra@redhat.com> <546FA1FC.9020209@redhat.com> <1922203767.2737468.1416602507384.JavaMail.zimbra@redhat.com> <546FA757.1030802@redhat.com> <1342570403.2761515.1416605429661.JavaMail.zimbra@redhat.com> <5470A194.6070904@redhat.com> Message-ID: <547197DD.1080405@redhat.com> On 11/22/2014 02:45 PM, Jiri Vanek wrote: > Long story short - the issue was broken cache. Then the dialog "lunch error" apeard. On this dialog is big button "clean cache" and even somebody so skilled as aph did not click it.... I must b missing something,... I never got a dialog box: the browser just hung. Andrew. From jvanek at redhat.com Mon Nov 24 10:57:28 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 24 Nov 2014 11:57:28 +0100 Subject: [rfc][icedtea-web] Remove use of clear cache in PackGZip Tests In-Reply-To: <547197DD.1080405@redhat.com> References: <2007629369.2731433.1416601898090.JavaMail.zimbra@redhat.com> <546FA1FC.9020209@redhat.com> <1922203767.2737468.1416602507384.JavaMail.zimbra@redhat.com> <546FA757.1030802@redhat.com> <1342570403.2761515.1416605429661.JavaMail.zimbra@redhat.com> <5470A194.6070904@redhat.com> <547197DD.1080405@redhat.com> Message-ID: <54730F18.20809@redhat.com> On 11/23/2014 09:16 AM, Andrew Haley wrote: > On 11/22/2014 02:45 PM, Jiri Vanek wrote: >> Long story short - the issue was broken cache. Then the dialog "lunch error" apeard. On this dialog is big button "clean cache" and even somebody so skilled as aph did not click it.... I must b missing something,... > > I never got a dialog box: the browser just hung. > Hm:( I'm still not able to reproduce. In all cases I got the error dialogue, not frozen browser. Andrew, do you recall which directories/files were causing it to happen? J. From jvanek at redhat.com Mon Nov 24 11:13:54 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 24 Nov 2014 12:13:54 +0100 Subject: [rfc][icedtea-web] do not re-download href if environment is offline Message-ID: <547312F2.8000409@redhat.com> The whole offline environment is already in 1.5. Ok for head nd 1.5 too? J. -------------- next part -------------- A non-text attachment was scrubbed... Name: offlineInJnlpHref.patch Type: text/x-patch Size: 498 bytes Desc: not available URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141124/aaa76c5b/offlineInJnlpHref.patch> From aph at redhat.com Mon Nov 24 12:12:41 2014 From: aph at redhat.com (Andrew Haley) Date: Mon, 24 Nov 2014 12:12:41 +0000 Subject: [rfc][icedtea-web] Remove use of clear cache in PackGZip Tests In-Reply-To: <54730F18.20809@redhat.com> References: <2007629369.2731433.1416601898090.JavaMail.zimbra@redhat.com> <546FA1FC.9020209@redhat.com> <1922203767.2737468.1416602507384.JavaMail.zimbra@redhat.com> <546FA757.1030802@redhat.com> <1342570403.2761515.1416605429661.JavaMail.zimbra@redhat.com> <5470A194.6070904@redhat.com> <547197DD.1080405@redhat.com> <54730F18.20809@redhat.com> Message-ID: <547320B9.5080603@redhat.com> On 11/24/2014 10:57 AM, Jiri Vanek wrote: > On 11/23/2014 09:16 AM, Andrew Haley wrote: >> On 11/22/2014 02:45 PM, Jiri Vanek wrote: >>> Long story short - the issue was broken cache. Then the dialog "lunch error" apeard. On this dialog is big button "clean cache" and even somebody so skilled as aph did not click it.... I must b missing something,... >> >> I never got a dialog box: the browser just hung. > > Hm:( I'm still not able to reproduce. In all cases I got the error dialogue, not frozen browser. > > Andrew, do you recall which directories/files were causing it to happen? Sorry, no. And you rather did tell me to delete the cache. But I still don't understand this problem: if the cache is suspect, why do you bother the user with a dialogue? It's just a cache, isn't it? Why do you not simply throw it away? Andrew. From jvanek at redhat.com Mon Nov 24 12:23:30 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 24 Nov 2014 13:23:30 +0100 Subject: [rfc][icedtea-web] Remove use of clear cache in PackGZip Tests In-Reply-To: <547320B9.5080603@redhat.com> References: <2007629369.2731433.1416601898090.JavaMail.zimbra@redhat.com> <546FA1FC.9020209@redhat.com> <1922203767.2737468.1416602507384.JavaMail.zimbra@redhat.com> <546FA757.1030802@redhat.com> <1342570403.2761515.1416605429661.JavaMail.zimbra@redhat.com> <5470A194.6070904@redhat.com> <547197DD.1080405@redhat.com> <54730F18.20809@redhat.com> <547320B9.5080603@redhat.com> Message-ID: <54732342.5050609@redhat.com> On 11/24/2014 01:12 PM, Andrew Haley wrote: > On 11/24/2014 10:57 AM, Jiri Vanek wrote: >> On 11/23/2014 09:16 AM, Andrew Haley wrote: >>> On 11/22/2014 02:45 PM, Jiri Vanek wrote: >>>> Long story short - the issue was broken cache. Then the dialog "lunch error" apeard. On this dialog is big button "clean cache" and even somebody so skilled as aph did not click it.... I must b missing something,... >>> >>> I never got a dialog box: the browser just hung. >> >> Hm:( I'm still not able to reproduce. In all cases I got the error dialogue, not frozen browser. >> >> Andrew, do you recall which directories/files were causing it to happen? > > Sorry, no. And you rather did tell me to delete the cache. In your case I'm not sure if cache was the reason. It seems moreover like some file conflict or I don't know. Non of my attempts to reproduce ended by hanging - all by ended by correct error dialog. > > But I still don't understand this problem: if the cache is suspect, If more instances of netx are running then cleaning of cache will not succeed, and user will be bothered anyway. > why do you bother the user with a dialogue? It's just a cache, isn't > it? Why do you not simply throw it away? The reason why not to clear cache automatically are offline stored jnlp apps. But I admit itw is not correctly informing about those anyway. So yes, some thinking in this direction will need to be done.. J. From jkang at redhat.com Mon Nov 24 15:40:42 2014 From: jkang at redhat.com (Jie Kang) Date: Mon, 24 Nov 2014 10:40:42 -0500 (EST) Subject: [rfc][icedtea-web] do not re-download href if environment is offline In-Reply-To: <547312F2.8000409@redhat.com> References: <547312F2.8000409@redhat.com> Message-ID: <2104557688.3213704.1416843642647.JavaMail.zimbra@redhat.com> ----- Original Message ----- > The whole offline environment is already in 1.5. Ok for head nd 1.5 too? Hello, I am not sure what the intentions of this change are. This changes the behaviour of the function. Is this intended? fromUrl(...): [...] if (!isLocal && haveHref){ //this is case when remote file have href to different file if (!location.equals(file.getSourceLocation())){ //mark local true, so the folowing condition will be true and //new jnlp file will be downlaoded isLocal = true; //maybe this check is to strict, and will force redownlaod to often //another check can be just on jnlp name. But it will not work //if the href will be the file of same name, but on diferent path (or even domain) } } if (isLocal && haveHref) { file = new JNLPFile(file.getSourceLocation(), parserSettings); } [...] For the case: (!isLocal && haveHref) : it checks for (!location.equals(file.getSourceLocation()), which if true (not equal), sets isLocal to true, in order to use the JNLP file located at file.getSourceLocation() by taking advantage of the next if-statement (isLocal && haveHref). If you add JNLPRuntime.isOnline() check to the second if-statement, then the above code will have new behaviour when offline: itt will not try to load the JNLP file located at file.getSourceLocation() anymore. I think a more correct fix would be: fromUrl(...): [...] if (!isLocal && haveHref && !location.equals(file.getSourceLocation()){ file = new JNLPFile(file.getSourceLocation(), parserSettings); } if (isLocal && haveHref && JNLPRuntime.isOnline()) { file = new JNLPFile(file.getSourceLocation(), parserSettings); } [...] Also, if you look at the constructor for JNLPFile: new JNLPFile(url, parsersettings), the code: if (file.getSourceLocation() != null) { haveHref = true; } is redundant, as file.getSourceLocation is never null. This isn't as big of an issue though. Regards, > > J. > -- Jie Kang From jvanek at redhat.com Mon Nov 24 15:48:32 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 24 Nov 2014 16:48:32 +0100 Subject: [rfc][icedtea-web] do not re-download href if environment is offline In-Reply-To: <2104557688.3213704.1416843642647.JavaMail.zimbra@redhat.com> References: <547312F2.8000409@redhat.com> <2104557688.3213704.1416843642647.JavaMail.zimbra@redhat.com> Message-ID: <54735350.5080905@redhat.com> On 11/24/2014 04:40 PM, Jie Kang wrote: > > > ----- Original Message ----- >> The whole offline environment is already in 1.5. Ok for head nd 1.5 too? > > Hello, > > I am not sure what the intentions of this change are. > > This changes the behaviour of the function. Is this intended? > > fromUrl(...): > [...] > if (!isLocal && haveHref){ > //this is case when remote file have href to different file > if (!location.equals(file.getSourceLocation())){ > //mark local true, so the folowing condition will be true and > //new jnlp file will be downlaoded > isLocal = true; > //maybe this check is to strict, and will force redownlaod to often > //another check can be just on jnlp name. But it will not work > //if the href will be the file of same name, but on diferent path (or even domain) > } > } > if (isLocal && haveHref) { > file = new JNLPFile(file.getSourceLocation(), parserSettings); > } > [...] > > For the case: (!isLocal && haveHref) : it checks for (!location.equals(file.getSourceLocation()), which if true (not equal), sets isLocal to true, in order to use the JNLP file located at file.getSourceLocation() by taking advantage of the next if-statement (isLocal && haveHref). > > > If you add JNLPRuntime.isOnline() check to the second if-statement, then the above code will have new behaviour when offline: itt will not try to load the JNLP file located at file.getSourceLocation() anymore. > > > I think a more correct fix would be: > > fromUrl(...): > [...] > if (!isLocal && haveHref && !location.equals(file.getSourceLocation()){ > file = new JNLPFile(file.getSourceLocation(), parserSettings); > } > if (isLocal && haveHref && JNLPRuntime.isOnline()) { > file = new JNLPFile(file.getSourceLocation(), parserSettings); > } > [...] > > > > > Also, if you look at the constructor for JNLPFile: new JNLPFile(url, parsersettings), the code: > > if (file.getSourceLocation() != null) { > haveHref = true; > } > > is redundant, as file.getSourceLocation is never null. This isn't as big of an issue though. > > > > > Regards, > > Well, yes, the issue I'm heving is NPE in SecurityDesc line (+-413 ) : final URI codebase = file.getCodeBase().toURI().normalize(); Issue is that hreffed codebase may be null. It is ok when file is online, but wrong when we are going offline. /me testing this patch2 So yes, my inital patch was bad. The file should be "downloaded" (even only from cache) always. J. -------------- next part -------------- A non-text attachment was scrubbed... Name: offlineInJnlpHref2.patch Type: text/x-patch Size: 724 bytes Desc: not available URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141124/c386aa33/offlineInJnlpHref2-0001.patch> From jkang at redhat.com Mon Nov 24 16:06:03 2014 From: jkang at redhat.com (Jie Kang) Date: Mon, 24 Nov 2014 11:06:03 -0500 (EST) Subject: [rfc][icedtea-web][icedtea-web-1.5.2] allow also skip of permissions attribute check in case of disabled attributes check In-Reply-To: <5470A5BE.8040504@redhat.com> References: <5470A5BE.8040504@redhat.com> Message-ID: <1306461714.3234374.1416845163218.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi! > > The permission attribute is still incompletely implemented and mixed > signatures apps are suffering not working with itw. by specifing it. > > The implementation troubles ate in ITW two: > - it can happen that application is loaded by various jnlpfiles > => one jnlp file is signed, secondnot : however whole application is > signed- so check in second jnlp file on sandbox attribute will finish by > error. > - fix it to have two kinds of attribute checkers - one jnlp file > specific, and one global for whole app. Some attibutes are then checked > globaly, some only on iven jnlpfile > - the applictaion can be loaded by several classloaders each of them with > differet permissions. This is real cause of issues with ^ and I do not > know cure on it. > > > The reproducers are all jogam or joglor .... applets on > http://icedtea.classpath.org/wiki/IcedTea-Web-Tests . > > As for head - I'm working on oflfine integration of applets, and it is quite > blocker. As for 1.5 jog* people have already reported this (got lost...) and > we should make thi swork for them at least by this workarround. > > J. > > ok to head and 1.5? > > diff -r f1586e8af6b9 > netx/net/sourceforge/jnlp/runtime/ManifestAttributesChecker.java > --- a/netx/net/sourceforge/jnlp/runtime/ManifestAttributesChecker.java Wed > Nov 19 18:33:56 2014 +0100 > +++ b/netx/net/sourceforge/jnlp/runtime/ManifestAttributesChecker.java Sat > Nov 22 15:53:38 2014 +0100 > @@ -75,15 +75,14 @@ > } > > void checkAll() throws LaunchException { > - checkPermissionsAttribute(); > if (isCheckEnabled()) { > + checkPermissionsAttribute(); > checkTrustedOnlyAttribute(); > checkCodebaseAttribute(); > checkPermissionsAttribute(); > checkApplicationLibraryAllowableCodebaseAttribute(); > } else { > - > OutputController.getLogger().log(OutputController.Level.WARNING_ALL, > "Manifest attribute checks are disabled." > - + " The Permissions attribute will be enforced but other > manifest attributes will be ignored."); > + > OutputController.getLogger().log(OutputController.Level.WARNING_ALL, > "Manifest attribute checks are disabled."); > } > } Hello, It would be great if aazores could review this as I believe his changeset is being modified here. My only concern is that for Very High and High security levels, the permissions attribute is checked. This change makes it so the permissions attribute is now no longer always checked for Low security levels, yes? This seems fine as a workaround given [1]. However, with all of these workarounds, I am worried that we will never actually fix the issues :\ [1] http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html#permissions For the Medium (I think for us this is Low) security level, if the Permissions attribute is not present, then the security prompt contains a yellow warning about the missing attribute, and the permissions level requested by the RIA is used. Regards, > -- Jie Kang From jkang at redhat.com Mon Nov 24 16:30:22 2014 From: jkang at redhat.com (Jie Kang) Date: Mon, 24 Nov 2014 11:30:22 -0500 (EST) Subject: [rfc][icedtea-web][icedtea-web-1.5.2] allow also skip of permissions attribute check in case of disabled attributes check In-Reply-To: <54735BB4.6000507@redhat.com> References: <5470A5BE.8040504@redhat.com> <1306461714.3234374.1416845163218.JavaMail.zimbra@redhat.com> <54735BB4.6000507@redhat.com> Message-ID: <2030749976.3252554.1416846622895.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 11/24/2014 05:06 PM, Jie Kang wrote: > > > > > > ----- Original Message ----- > >> Hi! > >> > >> The permission attribute is still incompletely implemented and mixed > >> signatures apps are suffering not working with itw. by specifing it. > >> > >> The implementation troubles ate in ITW two: > >> - it can happen that application is loaded by various jnlpfiles > >> => one jnlp file is signed, secondnot : however whole application is > >> signed- so check in second jnlp file on sandbox attribute will finish > >> by > >> error. > >> - fix it to have two kinds of attribute checkers - one jnlp file > >> specific, and one global for whole app. Some attibutes are then > >> checked > >> globaly, some only on iven jnlpfile > >> - the applictaion can be loaded by several classloaders each of them > >> with > >> differet permissions. This is real cause of issues with ^ and I do not > >> know cure on it. > >> > >> > >> The reproducers are all jogam or joglor .... applets on > >> http://icedtea.classpath.org/wiki/IcedTea-Web-Tests . > >> > >> As for head - I'm working on oflfine integration of applets, and it is > >> quite > >> blocker. As for 1.5 jog* people have already reported this (got lost...) > >> and > >> we should make thi swork for them at least by this workarround. > >> > >> J. > >> > >> ok to head and 1.5? > >> > >> diff -r f1586e8af6b9 > >> netx/net/sourceforge/jnlp/runtime/ManifestAttributesChecker.java > >> --- a/netx/net/sourceforge/jnlp/runtime/ManifestAttributesChecker.java Wed > >> Nov 19 18:33:56 2014 +0100 > >> +++ b/netx/net/sourceforge/jnlp/runtime/ManifestAttributesChecker.java Sat > >> Nov 22 15:53:38 2014 +0100 > >> @@ -75,15 +75,14 @@ > >> } > >> > >> void checkAll() throws LaunchException { > >> - checkPermissionsAttribute(); > >> if (isCheckEnabled()) { > >> + checkPermissionsAttribute(); > >> checkTrustedOnlyAttribute(); > >> checkCodebaseAttribute(); > >> checkPermissionsAttribute(); > >> checkApplicationLibraryAllowableCodebaseAttribute(); > >> } else { > >> - > >> OutputController.getLogger().log(OutputController.Level.WARNING_ALL, > >> "Manifest attribute checks are disabled." > >> - + " The Permissions attribute will be enforced but > >> other > >> manifest attributes will be ignored."); > >> + > >> OutputController.getLogger().log(OutputController.Level.WARNING_ALL, > >> "Manifest attribute checks are disabled."); > >> } > >> } > > > > > > Hello, > > > > It would be great if aazores could review this as I believe his changeset > > is being modified here. > > yes :( I wrote him At friday when I found the bug even a bit more descriptive > email... Hoping for > answer.. :( > > > > My only concern is that for Very High and High security levels, the > > permissions attribute is checked. > this > > > > > This change makes it so the permissions attribute is now no longer always > > checked for Low security levels, yes? This seems fine as a workaround > > given [1]. However, with all of these workarounds, I am worried that we > > will never actually fix the issues :\ > and this > > > > > are - I hope - both incorrect conclusions. The attributes are checked always, > no meter of > security[1] level. > > They are not checked, only and if and only if [1]: > deployment.manifest.attributes.check=false > > > > [1] > > http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html#permissions > > For the Medium (I think for us this is Low) security level, if the > > Permissions attribute is not present, then the security prompt contains > > a yellow warning about the missing attribute, and the permissions level > > requested by the RIA is used. > > > > > [1] > public static boolean isCheckEnabled() { > final String deploymentProperty = > JNLPRuntime.getConfiguration().getProperty(DeploymentConfiguration.KEY_ENABLE_MANIFEST_ATTRIBUTES_CHECK); > return Boolean.parseBoolean(deploymentProperty); > } > > Hello, Ah I see now. So basically, now it does not check permissions when deployment.manifest.attributes.check=false. Before it would always check it. Interesting... Seems okay, but I feel like aazores did this for a reason... Regards, > Thanx for check! > > > J. > -- Jie Kang From jvanek at redhat.com Mon Nov 24 16:24:20 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 24 Nov 2014 17:24:20 +0100 Subject: [rfc][icedtea-web][icedtea-web-1.5.2] allow also skip of permissions attribute check in case of disabled attributes check In-Reply-To: <1306461714.3234374.1416845163218.JavaMail.zimbra@redhat.com> References: <5470A5BE.8040504@redhat.com> <1306461714.3234374.1416845163218.JavaMail.zimbra@redhat.com> Message-ID: <54735BB4.6000507@redhat.com> On 11/24/2014 05:06 PM, Jie Kang wrote: > > > ----- Original Message ----- >> Hi! >> >> The permission attribute is still incompletely implemented and mixed >> signatures apps are suffering not working with itw. by specifing it. >> >> The implementation troubles ate in ITW two: >> - it can happen that application is loaded by various jnlpfiles >> => one jnlp file is signed, secondnot : however whole application is >> signed- so check in second jnlp file on sandbox attribute will finish by >> error. >> - fix it to have two kinds of attribute checkers - one jnlp file >> specific, and one global for whole app. Some attibutes are then checked >> globaly, some only on iven jnlpfile >> - the applictaion can be loaded by several classloaders each of them with >> differet permissions. This is real cause of issues with ^ and I do not >> know cure on it. >> >> >> The reproducers are all jogam or joglor .... applets on >> http://icedtea.classpath.org/wiki/IcedTea-Web-Tests . >> >> As for head - I'm working on oflfine integration of applets, and it is quite >> blocker. As for 1.5 jog* people have already reported this (got lost...) and >> we should make thi swork for them at least by this workarround. >> >> J. >> >> ok to head and 1.5? >> >> diff -r f1586e8af6b9 >> netx/net/sourceforge/jnlp/runtime/ManifestAttributesChecker.java >> --- a/netx/net/sourceforge/jnlp/runtime/ManifestAttributesChecker.java Wed >> Nov 19 18:33:56 2014 +0100 >> +++ b/netx/net/sourceforge/jnlp/runtime/ManifestAttributesChecker.java Sat >> Nov 22 15:53:38 2014 +0100 >> @@ -75,15 +75,14 @@ >> } >> >> void checkAll() throws LaunchException { >> - checkPermissionsAttribute(); >> if (isCheckEnabled()) { >> + checkPermissionsAttribute(); >> checkTrustedOnlyAttribute(); >> checkCodebaseAttribute(); >> checkPermissionsAttribute(); >> checkApplicationLibraryAllowableCodebaseAttribute(); >> } else { >> - >> OutputController.getLogger().log(OutputController.Level.WARNING_ALL, >> "Manifest attribute checks are disabled." >> - + " The Permissions attribute will be enforced but other >> manifest attributes will be ignored."); >> + >> OutputController.getLogger().log(OutputController.Level.WARNING_ALL, >> "Manifest attribute checks are disabled."); >> } >> } > > > Hello, > > It would be great if aazores could review this as I believe his changeset is being modified here. yes :( I wrote him At friday when I found the bug even a bit more descriptive email... Hoping for answer.. :( > > My only concern is that for Very High and High security levels, the permissions attribute is checked. this > > This change makes it so the permissions attribute is now no longer always checked for Low security levels, yes? This seems fine as a workaround given [1]. However, with all of these workarounds, I am worried that we will never actually fix the issues :\ and this > are - I hope - both incorrect conclusions. The attributes are checked always, no meter of security[1] level. They are not checked, only and if and only if [1]: deployment.manifest.attributes.check=false > > [1] http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/security/manifest.html#permissions > For the Medium (I think for us this is Low) security level, if the Permissions attribute is not present, then the security prompt contains a yellow warning about the missing attribute, and the permissions level requested by the RIA is used. > > [1] public static boolean isCheckEnabled() { final String deploymentProperty = JNLPRuntime.getConfiguration().getProperty(DeploymentConfiguration.KEY_ENABLE_MANIFEST_ATTRIBUTES_CHECK); return Boolean.parseBoolean(deploymentProperty); } Thanx for check! J. From jvanek at redhat.com Mon Nov 24 16:51:31 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 24 Nov 2014 17:51:31 +0100 Subject: [rfc][icedtea-web][icedtea-web-1.5.2] allow also skip of permissions attribute check in case of disabled attributes check In-Reply-To: <2030749976.3252554.1416846622895.JavaMail.zimbra@redhat.com> References: <5470A5BE.8040504@redhat.com> <1306461714.3234374.1416845163218.JavaMail.zimbra@redhat.com> <54735BB4.6000507@redhat.com> <2030749976.3252554.1416846622895.JavaMail.zimbra@redhat.com> Message-ID: <54736213.5060703@redhat.com> > > Hello, > > > Ah I see now. So basically, now it does not check permissions when deployment.manifest.attributes.check=false. Before it would always check it. Interesting... > > Seems okay, but I feel like aazores did this for a reason... > > Originally it was excluded : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-April/027165.html But later moved out during signed appelts support for sandbox attribute... I hope that the reason is only one - that sanbox in attribute is forcing sandbox no metter of outside signatures. Well by disbaling attributes check this is disabled and you can get hurt. If this is the only issue, then I'm ok with that. but: http://icedtea.classpath.org/hg/icedtea-web/rev/d1584d50c1e9 says: (checkAll): Extended Applet Security on Low disables all manifest checks except for Permissions Looking into http://icedtea.classpath.org/hg/icedtea-web/rev/d1584d50c1e9#l4.1 the changelog statement seems wrong to me... so...Where is truth now? J. From jkang at redhat.com Mon Nov 24 16:53:14 2014 From: jkang at redhat.com (Jie Kang) Date: Mon, 24 Nov 2014 11:53:14 -0500 (EST) Subject: [rfc][icedtea-web-1.5]escape < and > in console (was Re: [rfc][icedtea-web] log jnlp file to console ) In-Reply-To: <546CB1A9.8010000@redhat.com> References: <546B5C3E.5030007@redhat.com> <546B669B.2070605@redhat.com> <546CB1A9.8010000@redhat.com> Message-ID: <1752555914.3271086.1416847994059.JavaMail.zimbra@redhat.com> ----- Original Message ----- > I have just spotted interesting behavior for both 1.5 and head. > > When javaws appl forks (the behaviour which can be canceled by -Xnofork) and > printing to streams is > enabled then forked jvm is writing into stdout/err, which is then recognized > by upper jvm as > "custom input" and so is reprinted again also to old console. > > As it do not deadloc, then I would call it feature, not a bug :) > > However, - as jnlp is reprinted to stdout by foorked jvm in 1.5 > > the > > --- a/netx/net/sourceforge/jnlp/util/logging/ConsoleOutputPaneModel.java Fri > Nov 14 16:25:56 2014 +0100 > +++ b/netx/net/sourceforge/jnlp/util/logging/ConsoleOutputPaneModel.java Tue > Nov 18 15:44:47 2014 +0100 > @@ -205,6 +205,8 @@ > } > String line = (createLine(messageWithHeader)); > if (mark) { > + line = line.replaceAll("<", "&lt;"); > + line = line.replaceAll(">", "&gt;"); > line = line.replaceAll("\n", "<br/>\n"); > line = line.replaceAll(" ", "&nbsp; ");//small trick, html > is reducting row of > spaces to single space. This handles it and stimm allow line wrap > line = line.replaceAll("\t", "&nbsp;&nbsp;&nbsp;&nbsp;"); > > > hunk is very valid also for 1.5 and if head is approved, then I would like to > push this hunk to 1.5 > Well.. maybe more escaping is needed. But not sure how urgent those are... > Hello, Okay. Regards, > > J. > > On 11/18/2014 04:32 PM, Jiri Vanek wrote: > > > > >> > >> ----- Original Message ----- > >>> On 10/21/2014 03:46 PM, Jiri Vanek wrote: > >>>> hi! > >>>> > >>>> This is not just rfc, but RFC :) as I'm not sure which way to go. The > >>>> only one I found suitbale - > >>>> this oen - is not nice. > >>>> > >>>> Curently all the logs are going to logger, which determine if debug is > >>>> on > >>>> and what channels are > >>>> enabled (stdout/err, file, console) > >>>> > >>>> According to those, it consume the message. This workflow had one > >>>> exception, the reprinting of > >>>> jnlpfiel, which went only to console, if debug was online. > >>>> Most of the bugreports now contains whole console - and it is very good > >>>> - > >>>> but that measn the jnlp > >>>> file is missing. > >>>> > >>>> > >>>> The jnlpfile reprint was excluded, becasue console is using html > >>>> formatting, to higlight outputs - > >>>> for palintext the reprint is and willbe working fine, but it is not > >>>> working > >>>> with syntax higlighting > >>>> from obvious reasons. > >>>> > >>>> I wont to avoid escaping of inpout - the message object is sahred > >>>> between > >>>> stdou/file/html > >>>> console/plain console so to make special decoding for html console do > >>>> need > >>>> copy of it (and in case > >>>> of console solid rework of console itself) and then proces via > >>>> esapcping. > >>>> Another issue is that html in java is terribly old, and hard to say what > >>>> specification it supports > >>>> (if any). > >>>> > >>>> To my surpise it support <plaintext> (yes nothing else do so...) So I > >>>> have > >>>> tryed to include the jnlp > >>>> reprint wrapped by this tags. And it seems to be working fine wiht all > >>>> supported outputs without any > >>>> encodings or copying. > >>>> > >>>> There is drawback - eg firefox now have issues to show everything behind > >>>> </plaintext> :( (note - > >>>> <pre> do not work for jeeditorpane:( )) > >>>> > >>>> J. > >>> ping, thoughts? I amde an attmept with <pre><plaintext></paintext></pre> > >>> and > >>> it did not helped. > >>> Still the jnlp fiel should appear inconsole :( > >> > >> Hello, > >> > >> In user-testing, the JavaConsole now displays the entire jnlp file in one > >> line, making it > >> difficult to read. It seems the break tags do not get formatted when > >> displayed in Java Console (at > >> least for me). > >> > >> However if you copy and paste it into a text file, it becomes multiple > >> lines: > >> > >> e.g. > >> > >> <br/> > >> <?xml version="1.0" standalone="yes"?><br/> > >> line: 2 <br/> > >> line: 3 <jnlp spec="1.0" href="SimpleJNLP.jnlp" > >> xmlns="http://www.w3.org/1999/xhtml"><br/> > >> line: 4 <information><br/> > >> line: 5 <title>simple application</title><br/> > >> line: 6 <vendor>IcedTea</vendor><br/> > >> line: 7 <homepage > >> href="http://icedtea.classpath.org/wiki/IcedTea-Web#Testing_IcedTea-Web"></homepage><br/> > >> line: 8 <description></description><br/> > >> line: 9 <offline-allowed></offline-allowed><br/> > >> line: 10 </information><br/> > >> line: 11 <resources><br/> > >> line: 12 <j2se version="1.4+"></j2se><br/> > >> line: 13 <jar href="SimpleJNLP.jar"></jar><br/> > >> line: 14 </resources><br/> > >> line: 15 <applet-desc name="SimpleJNLP Applet" > >> main-class="SimpleJNLP"><br/> > >> line: 16 </applet-desc><br/> > >> line: 17 <br/> > >> line: 18 <br/> > >> line: 19 <br/> > >> line: 20 </jnlp><br/> > >> line: 21 <br/> > >> line: 22 > >> > >> Also, I do not think it's useful to display the line numbers (e.g. line: > >> 2, line: 3, ...). Could > >> these be removed? > >> > >> I feel like sending multiple messages to the Java Console might be okay > >> however I don't fully > >> understand the concerns you have at the moment;; > >> > >> Personally, it would be most useful if there were no break tags or line > >> numbers so I could copy > >> and paste the output into a file and have it be pretty much the same as > >> the original jnlp file. Is > >> the Java Console limited and unable to do this? Maybe we can modify Java > >> Console to support what > >> we need;; > > > > Yes. It is deffinitly the right way. See new patch with your approach :) > > > > Thoughts? > > > > > > J. > > > > > > > > -- Jie Kang From jkang at redhat.com Tue Nov 25 14:24:55 2014 From: jkang at redhat.com (Jie Kang) Date: Tue, 25 Nov 2014 09:24:55 -0500 (EST) Subject: [rfc][icedtea-web][icedtea-web-1.5.2] allow also skip of permissions attribute check in case of disabled attributes check In-Reply-To: <54736213.5060703@redhat.com> References: <5470A5BE.8040504@redhat.com> <1306461714.3234374.1416845163218.JavaMail.zimbra@redhat.com> <54735BB4.6000507@redhat.com> <2030749976.3252554.1416846622895.JavaMail.zimbra@redhat.com> <54736213.5060703@redhat.com> Message-ID: <2138745312.3802287.1416925495282.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > > > > Hello, > > > > > > Ah I see now. So basically, now it does not check permissions when > > deployment.manifest.attributes.check=false. Before it would always check > > it. Interesting... > > > > Seems okay, but I feel like aazores did this for a reason... > > > > > > Originally it was excluded : > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-April/027165.html > > But later moved out during signed appelts support for sandbox attribute... > > I hope that the reason is only one - that sanbox in attribute is forcing > sandbox no metter of > outside signatures. Well by disbaling attributes check this is disabled and > you can get hurt. > > If this is the only issue, then I'm ok with that. > > but: > > http://icedtea.classpath.org/hg/icedtea-web/rev/d1584d50c1e9 says: > > (checkAll): Extended Applet Security on Low disables all manifest checks > except for Permissions > Looking into > http://icedtea.classpath.org/hg/icedtea-web/rev/d1584d50c1e9#l4.1 > the changelog statement seems wrong to me... > so...Where is truth now? Hello, The patch is fine with me. Regards, > > > J. > -- Jie Kang From jkang at redhat.com Tue Nov 25 14:31:26 2014 From: jkang at redhat.com (Jie Kang) Date: Tue, 25 Nov 2014 09:31:26 -0500 (EST) Subject: [rfc][icedtea-web] do not re-download href if environment is offline In-Reply-To: <54735350.5080905@redhat.com> References: <547312F2.8000409@redhat.com> <2104557688.3213704.1416843642647.JavaMail.zimbra@redhat.com> <54735350.5080905@redhat.com> Message-ID: <1758667809.3806416.1416925886255.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 11/24/2014 04:40 PM, Jie Kang wrote: > > > > > > ----- Original Message ----- > >> The whole offline environment is already in 1.5. Ok for head nd 1.5 too? > > > > Hello, > > > > I am not sure what the intentions of this change are. > > > > This changes the behaviour of the function. Is this intended? > > > > fromUrl(...): > > [...] > > if (!isLocal && haveHref){ > > //this is case when remote file have href to different > > file > > if (!location.equals(file.getSourceLocation())){ > > //mark local true, so the folowing condition will be > > true and > > //new jnlp file will be downlaoded > > isLocal = true; > > //maybe this check is to strict, and will force > > redownlaod to often > > //another check can be just on jnlp name. But it will > > not work > > //if the href will be the file of same name, but on > > diferent path (or even domain) > > } > > } > > if (isLocal && haveHref) { > > file = new JNLPFile(file.getSourceLocation(), > > parserSettings); > > } > > [...] > > > > For the case: (!isLocal && haveHref) : it checks for > > (!location.equals(file.getSourceLocation()), which if true (not equal), > > sets isLocal to true, in order to use the JNLP file located at > > file.getSourceLocation() by taking advantage of the next if-statement > > (isLocal && haveHref). > > > > > > If you add JNLPRuntime.isOnline() check to the second if-statement, then > > the above code will have new behaviour when offline: itt will not try to > > load the JNLP file located at file.getSourceLocation() anymore. > > > > > > I think a more correct fix would be: > > > > fromUrl(...): > > [...] > > if (!isLocal && haveHref && > > !location.equals(file.getSourceLocation()){ > > file = new JNLPFile(file.getSourceLocation(), > > parserSettings); > > } > > if (isLocal && haveHref && JNLPRuntime.isOnline()) { > > file = new JNLPFile(file.getSourceLocation(), > > parserSettings); > > } > > [...] > > > > > > > > > > Also, if you look at the constructor for JNLPFile: new JNLPFile(url, > > parsersettings), the code: > > > > if (file.getSourceLocation() != null) { > > haveHref = true; > > } > > > > is redundant, as file.getSourceLocation is never null. This isn't as big of > > an issue though. > > > > > > > > > > Regards, > > > > > > Well, yes, the issue I'm heving is NPE in SecurityDesc line (+-413 ) : > final URI codebase = file.getCodeBase().toURI().normalize(); > > Issue is that hreffed codebase may be null. It is ok when file is online, > but wrong when we are > going offline. > > /me testing this patch2 > > > So yes, my inital patch was bad. The file should be "downloaded" (even only > from cache) always. Hello, I think the patch is okay with just one minor nits: + JNLPFile hreffedFile = new JNLPFile(file.getSourceLocation(), parserSettings); I would rename hreffedFile to fileFromHref. You could also rename getSourceLocation() to getHrefAttribute() or something more obvious (what is source location?), but this is not 100% necessary, esp. for backport to 1.5.2. Regards, > > J. > > > > -- Jie Kang From jkang at redhat.com Tue Nov 25 14:41:42 2014 From: jkang at redhat.com (Jie Kang) Date: Tue, 25 Nov 2014 09:41:42 -0500 (EST) Subject: [rfc][icedtea-web] Fix for JavaConsoleTest In-Reply-To: <1991374808.3816782.1416926341480.JavaMail.zimbra@redhat.com> Message-ID: <621475145.3818905.1416926502684.JavaMail.zimbra@redhat.com> Hello, This patch fixes a newly failing unit test in JavaConsoleTest related to PR2063 [1]. The test 'CreatePluginHeaderTestNotOK' fails due to the changes to PluginMessage, PluginHeader and Header. The test has been fixed in accordance with the changes and now passes. How does it look? [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2063 Regards, -- Jie Kang -------------- next part -------------- A non-text attachment was scrubbed... Name: itw-java-console-test.patch Type: text/x-patch Size: 2660 bytes Desc: not available URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141125/732d09c5/itw-java-console-test.patch> From jvanek at redhat.com Tue Nov 25 14:44:14 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 25 Nov 2014 15:44:14 +0100 Subject: [rfc][icedtea-web] Fix for JavaConsoleTest In-Reply-To: <621475145.3818905.1416926502684.JavaMail.zimbra@redhat.com> References: <621475145.3818905.1416926502684.JavaMail.zimbra@redhat.com> Message-ID: <547495BE.7090208@redhat.com> On 11/25/2014 03:41 PM, Jie Kang wrote: > Hello, > > > This patch fixes a newly failing unit test in JavaConsoleTest related to PR2063 [1]. > > The test 'CreatePluginHeaderTestNotOK' fails due to the changes to PluginMessage, PluginHeader and Header. The test has been fixed in accordance with the changes and now passes. > > How does it look? > > > [1]http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2063 > > > Regards, > > -- Jie Kang > > > itw-java-console-test.patch > > > diff --git a/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java b/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java > --- a/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java > +++ b/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java > @@ -15,7 +15,7 @@ > > > String s1 = "plugindebug 1384850630162925 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 CET 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1204] ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: PIPE: plugin read: plugin PluginProxyInfo reference 1http://www.walter-fendt.de:80"; > - String s2 = "plugindebugX 1384850630162954 [jvanek][ITW-Cplugindebug 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 CET 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: parts[0]=plugin, parts[1]=PluginProxyInfo, reference, parts[3]=1, parts[4]=http://www.walter-fendt.de:80 -- decoded_url=http://www.walter-fendt.de:80"; > + String s2 = "plugindebugX blob [jvanek][ITW-Cplugindebug 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 CET 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: parts[0]=plugin, parts[1]=PluginProxyInfo, reference, parts[3]=1, parts[4]=http://www.walter-fendt.de:80 -- decoded_url=http://www.walter-fendt.de:80"; > String s3 = "preinit_pluginerror 1384850630163298 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 CET 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1134] ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: Proxy info: plugin PluginProxyInfo reference 1 DIRECT"; > > @Test > @@ -47,12 +47,9 @@ > PluginMessage p2 = new PluginMessage(s2); > Assert.assertTrue(p2.wasError); > Assert.assertTrue(p2.header.isC); > - Assert.assertEquals(OutputController.Level.WARNING_ALL,p2.header.level); > - Assert.assertTrue(p2.header.date.toString().contains(new Date().toString().substring(0,16))); //means no Tue Nov 19 09:43:50 :) > - Assert.assertTrue(p2.header.user.equals("jvanek")); > + Assert.assertEquals(OutputController.Level.WARNING_ALL, p2.header.level); > + Assert.assertTrue(p2.header.date.toString().contains(new Date().toString().substring(0, 16))); //means no Tue Nov 19 09:43:50 :) > Assert.assertTrue(p2.header.thread1.equals("unknown")); > Assert.assertTrue(p2.header.thread2.equals("unknown")); > - > - > } > } > This is ok. What else to do? Just one nit - may you please add separate test for original String s2? J. From jkang at redhat.com Tue Nov 25 14:55:01 2014 From: jkang at redhat.com (Jie Kang) Date: Tue, 25 Nov 2014 09:55:01 -0500 (EST) Subject: [rfc][icedtea-web] Fix for JavaConsoleTest In-Reply-To: <547495BE.7090208@redhat.com> References: <621475145.3818905.1416926502684.JavaMail.zimbra@redhat.com> <547495BE.7090208@redhat.com> Message-ID: <1736692535.3827410.1416927301406.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 11/25/2014 03:41 PM, Jie Kang wrote: > > Hello, > > > > > > This patch fixes a newly failing unit test in JavaConsoleTest related to > > PR2063 [1]. > > > > The test 'CreatePluginHeaderTestNotOK' fails due to the changes to > > PluginMessage, PluginHeader and Header. The test has been fixed in > > accordance with the changes and now passes. > > > > How does it look? > > > > > > [1]http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2063 > > > > > > Regards, > > > > -- Jie Kang > > > > > > itw-java-console-test.patch > > > > > > diff --git > > a/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java > > b/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java > > --- > > a/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java > > +++ > > b/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java > > @@ -15,7 +15,7 @@ > > > > > > String s1 = "plugindebug 1384850630162925 > > [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 CET > > 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1204] > > ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: PIPE: > > plugin read: plugin PluginProxyInfo reference > > 1http://www.walter-fendt.de:80"; > > - String s2 = "plugindebugX 1384850630162954 [jvanek][ITW-Cplugindebug > > 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 > > CET > > 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] > > ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: parts[0]=plugin, > > parts[1]=PluginProxyInfo, reference, parts[3]=1, > > parts[4]=http://www.walter-fendt.de:80 -- > > decoded_url=http://www.walter-fendt.de:80"; > > + String s2 = "plugindebugX blob [jvanek][ITW-Cplugindebug > > 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 > > CET > > 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] > > ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: parts[0]=plugin, > > parts[1]=PluginProxyInfo, reference, parts[3]=1, > > parts[4]=http://www.walter-fendt.de:80 -- > > decoded_url=http://www.walter-fendt.de:80"; > > String s3 = "preinit_pluginerror 1384850630163298 > > [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 CET > > 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1134] > > ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: Proxy info: > > plugin PluginProxyInfo reference 1 DIRECT"; > > > > @Test > > @@ -47,12 +47,9 @@ > > PluginMessage p2 = new PluginMessage(s2); > > Assert.assertTrue(p2.wasError); > > Assert.assertTrue(p2.header.isC); > > - > > Assert.assertEquals(OutputController.Level.WARNING_ALL,p2.header.level); > > - Assert.assertTrue(p2.header.date.toString().contains(new > > Date().toString().substring(0,16))); //means no Tue Nov 19 09:43:50 :) > > - Assert.assertTrue(p2.header.user.equals("jvanek")); > > + Assert.assertEquals(OutputController.Level.WARNING_ALL, > > p2.header.level); > > + Assert.assertTrue(p2.header.date.toString().contains(new > > Date().toString().substring(0, 16))); //means no Tue Nov 19 09:43:50 :) > > Assert.assertTrue(p2.header.thread1.equals("unknown")); > > Assert.assertTrue(p2.header.thread2.equals("unknown")); > > - > > - > > } > > } > > > > > This is ok. What else to do? > > Just one nit - may you please add separate test for original String s2? Hello, The issue I found causing the old test to fail was that the PluginMessage for s2 had new behaviour: String s2 = "plugindebugX 1384850630162954 [jvanek][ITW-Cplugindebug 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 CET 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: parts[0]=plugin, parts[1]=PluginProxyInfo, reference, parts[3]=1, parts[4]=http://www.walter-fendt.de:80 -- decoded_url=http://www.walter-fendt.de:80"; Before: message.header.date = 'ITW-C-PLUGIN' : this causes an exception to occur when we attempt to convert this to 'java.util.Date' After: message.header.date is now a String : there is no exception occurring and 'ITW-C-PLUGIN' is accepted. This means that PluginMessage for s2 has 'wasError == false', since no exception occurs when parsing. I feel like a test for this string is not very helpful anymore. Thoughts? Thanks, > > J. > -- Jie Kang From jvanek at redhat.com Tue Nov 25 15:06:21 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 25 Nov 2014 16:06:21 +0100 Subject: [rfc][icedtea-web] Fix for JavaConsoleTest In-Reply-To: <1736692535.3827410.1416927301406.JavaMail.zimbra@redhat.com> References: <621475145.3818905.1416926502684.JavaMail.zimbra@redhat.com> <547495BE.7090208@redhat.com> <1736692535.3827410.1416927301406.JavaMail.zimbra@redhat.com> Message-ID: <54749AED.6000700@redhat.com> On 11/25/2014 03:55 PM, Jie Kang wrote: > > > ----- Original Message ----- >> On 11/25/2014 03:41 PM, Jie Kang wrote: >>> Hello, >>> >>> >>> This patch fixes a newly failing unit test in JavaConsoleTest related to >>> PR2063 [1]. >>> >>> The test 'CreatePluginHeaderTestNotOK' fails due to the changes to >>> PluginMessage, PluginHeader and Header. The test has been fixed in >>> accordance with the changes and now passes. >>> >>> How does it look? >>> >>> >>> [1]http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2063 >>> >>> >>> Regards, >>> >>> -- Jie Kang >>> >>> >>> itw-java-console-test.patch >>> >>> >>> diff --git >>> a/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java >>> b/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java >>> --- >>> a/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java >>> +++ >>> b/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java >>> @@ -15,7 +15,7 @@ >>> >>> >>> String s1 = "plugindebug 1384850630162925 >>> [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 CET >>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1204] >>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: PIPE: >>> plugin read: plugin PluginProxyInfo reference >>> 1http://www.walter-fendt.de:80"; >>> - String s2 = "plugindebugX 1384850630162954 [jvanek][ITW-Cplugindebug >>> 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 >>> CET >>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] >>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: parts[0]=plugin, >>> parts[1]=PluginProxyInfo, reference, parts[3]=1, >>> parts[4]=http://www.walter-fendt.de:80 -- >>> decoded_url=http://www.walter-fendt.de:80"; >>> + String s2 = "plugindebugX blob [jvanek][ITW-Cplugindebug >>> 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 >>> CET >>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] >>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: parts[0]=plugin, >>> parts[1]=PluginProxyInfo, reference, parts[3]=1, >>> parts[4]=http://www.walter-fendt.de:80 -- >>> decoded_url=http://www.walter-fendt.de:80"; >>> String s3 = "preinit_pluginerror 1384850630163298 >>> [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 CET >>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1134] >>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: Proxy info: >>> plugin PluginProxyInfo reference 1 DIRECT"; >>> >>> @Test >>> @@ -47,12 +47,9 @@ >>> PluginMessage p2 = new PluginMessage(s2); >>> Assert.assertTrue(p2.wasError); >>> Assert.assertTrue(p2.header.isC); >>> - >>> Assert.assertEquals(OutputController.Level.WARNING_ALL,p2.header.level); >>> - Assert.assertTrue(p2.header.date.toString().contains(new >>> Date().toString().substring(0,16))); //means no Tue Nov 19 09:43:50 :) >>> - Assert.assertTrue(p2.header.user.equals("jvanek")); >>> + Assert.assertEquals(OutputController.Level.WARNING_ALL, >>> p2.header.level); >>> + Assert.assertTrue(p2.header.date.toString().contains(new >>> Date().toString().substring(0, 16))); //means no Tue Nov 19 09:43:50 :) >>> Assert.assertTrue(p2.header.thread1.equals("unknown")); >>> Assert.assertTrue(p2.header.thread2.equals("unknown")); >>> - >>> - >>> } >>> } >>> >> >> >> This is ok. What else to do? >> >> Just one nit - may you please add separate test for original String s2? > > Hello, > > > The issue I found causing the old test to fail was that the PluginMessage for s2 had new behaviour: > > String s2 = "plugindebugX 1384850630162954 [jvanek][ITW-Cplugindebug 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 CET 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: parts[0]=plugin, parts[1]=PluginProxyInfo, reference, parts[3]=1, parts[4]=http://www.walter-fendt.de:80 -- decoded_url=http://www.walter-fendt.de:80"; > > > Before: > > message.header.date = 'ITW-C-PLUGIN' : this causes an exception to occur when we attempt to convert this to 'java.util.Date' > > After: > > message.header.date is now a String : there is no exception occurring and 'ITW-C-PLUGIN' is accepted. > > This means that PluginMessage for s2 has 'wasError == false', since no exception occurs when parsing. > > I feel like a test for this string is not very helpful anymore. > Oposite here. It is testing some beaviour. So it deserves specvial test. assert waserror==true and some other fields for it ... J. From jkang at redhat.com Tue Nov 25 15:09:28 2014 From: jkang at redhat.com (Jie Kang) Date: Tue, 25 Nov 2014 10:09:28 -0500 (EST) Subject: [rfc][icedtea-web] Fix for JavaConsoleTest In-Reply-To: <54749AED.6000700@redhat.com> References: <621475145.3818905.1416926502684.JavaMail.zimbra@redhat.com> <547495BE.7090208@redhat.com> <1736692535.3827410.1416927301406.JavaMail.zimbra@redhat.com> <54749AED.6000700@redhat.com> Message-ID: <1409966998.3836203.1416928168140.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 11/25/2014 03:55 PM, Jie Kang wrote: > > > > > > ----- Original Message ----- > >> On 11/25/2014 03:41 PM, Jie Kang wrote: > >>> Hello, > >>> > >>> > >>> This patch fixes a newly failing unit test in JavaConsoleTest related to > >>> PR2063 [1]. > >>> > >>> The test 'CreatePluginHeaderTestNotOK' fails due to the changes to > >>> PluginMessage, PluginHeader and Header. The test has been fixed in > >>> accordance with the changes and now passes. > >>> > >>> How does it look? > >>> > >>> > >>> [1]http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2063 > >>> > >>> > >>> Regards, > >>> > >>> -- Jie Kang > >>> > >>> > >>> itw-java-console-test.patch > >>> > >>> > >>> diff --git > >>> a/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java > >>> b/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java > >>> --- > >>> a/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java > >>> +++ > >>> b/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java > >>> @@ -15,7 +15,7 @@ > >>> > >>> > >>> String s1 = "plugindebug 1384850630162925 > >>> [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 CET > >>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1204] > >>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: PIPE: > >>> plugin read: plugin PluginProxyInfo reference > >>> 1http://www.walter-fendt.de:80"; > >>> - String s2 = "plugindebugX 1384850630162954 > >>> [jvanek][ITW-Cplugindebug > >>> 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 > >>> 09:43:50 > >>> CET > >>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] > >>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: parts[0]=plugin, > >>> parts[1]=PluginProxyInfo, reference, parts[3]=1, > >>> parts[4]=http://www.walter-fendt.de:80 -- > >>> decoded_url=http://www.walter-fendt.de:80"; > >>> + String s2 = "plugindebugX blob [jvanek][ITW-Cplugindebug > >>> 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 > >>> 09:43:50 > >>> CET > >>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] > >>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: parts[0]=plugin, > >>> parts[1]=PluginProxyInfo, reference, parts[3]=1, > >>> parts[4]=http://www.walter-fendt.de:80 -- > >>> decoded_url=http://www.walter-fendt.de:80"; > >>> String s3 = "preinit_pluginerror 1384850630163298 > >>> [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 CET > >>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1134] > >>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: Proxy > >>> info: > >>> plugin PluginProxyInfo reference 1 DIRECT"; > >>> > >>> @Test > >>> @@ -47,12 +47,9 @@ > >>> PluginMessage p2 = new PluginMessage(s2); > >>> Assert.assertTrue(p2.wasError); > >>> Assert.assertTrue(p2.header.isC); > >>> - > >>> Assert.assertEquals(OutputController.Level.WARNING_ALL,p2.header.level); > >>> - Assert.assertTrue(p2.header.date.toString().contains(new > >>> Date().toString().substring(0,16))); //means no Tue Nov 19 09:43:50 :) > >>> - Assert.assertTrue(p2.header.user.equals("jvanek")); > >>> + Assert.assertEquals(OutputController.Level.WARNING_ALL, > >>> p2.header.level); > >>> + Assert.assertTrue(p2.header.date.toString().contains(new > >>> Date().toString().substring(0, 16))); //means no Tue Nov 19 09:43:50 :) > >>> Assert.assertTrue(p2.header.thread1.equals("unknown")); > >>> Assert.assertTrue(p2.header.thread2.equals("unknown")); > >>> - > >>> - > >>> } > >>> } > >>> > >> > >> > >> This is ok. What else to do? > >> > >> Just one nit - may you please add separate test for original String s2? > > > > Hello, > > > > > > The issue I found causing the old test to fail was that the PluginMessage > > for s2 had new behaviour: > > > > String s2 = "plugindebugX 1384850630162954 [jvanek][ITW-Cplugindebug > > 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 > > 09:43:50 CET > > 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] > > ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: > > parts[0]=plugin, parts[1]=PluginProxyInfo, reference, parts[3]=1, > > parts[4]=http://www.walter-fendt.de:80 -- > > decoded_url=http://www.walter-fendt.de:80"; > > > > > > Before: > > > > message.header.date = 'ITW-C-PLUGIN' : this causes an exception to occur > > when we attempt to convert this to 'java.util.Date' > > > > After: > > > > message.header.date is now a String : there is no exception occurring and > > 'ITW-C-PLUGIN' is accepted. > > > > This means that PluginMessage for s2 has 'wasError == false', since no > > exception occurs when parsing. > > > > I feel like a test for this string is not very helpful anymore. > > > Oposite here. It is testing some beaviour. > > So it deserves specvial test. > assert waserror==true and some other fields for it ... For s2: wasError == false So assertTrue(wasError) will fail :\ Suggestions?;; > > J. > > -- Jie Kang From jvanek at redhat.com Tue Nov 25 15:22:22 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 25 Nov 2014 16:22:22 +0100 Subject: [rfc][icedtea-web] Fix for JavaConsoleTest In-Reply-To: <1409966998.3836203.1416928168140.JavaMail.zimbra@redhat.com> References: <621475145.3818905.1416926502684.JavaMail.zimbra@redhat.com> <547495BE.7090208@redhat.com> <1736692535.3827410.1416927301406.JavaMail.zimbra@redhat.com> <54749AED.6000700@redhat.com> <1409966998.3836203.1416928168140.JavaMail.zimbra@redhat.com> Message-ID: <54749EAE.2050704@redhat.com> On 11/25/2014 04:09 PM, Jie Kang wrote: > > > ----- Original Message ----- >> On 11/25/2014 03:55 PM, Jie Kang wrote: >>> >>> >>> ----- Original Message ----- >>>> On 11/25/2014 03:41 PM, Jie Kang wrote: >>>>> Hello, >>>>> >>>>> >>>>> This patch fixes a newly failing unit test in JavaConsoleTest related to >>>>> PR2063 [1]. >>>>> >>>>> The test 'CreatePluginHeaderTestNotOK' fails due to the changes to >>>>> PluginMessage, PluginHeader and Header. The test has been fixed in >>>>> accordance with the changes and now passes. >>>>> >>>>> How does it look? >>>>> >>>>> >>>>> [1]http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2063 >>>>> >>>>> >>>>> Regards, >>>>> >>>>> -- Jie Kang >>>>> >>>>> >>>>> itw-java-console-test.patch >>>>> >>>>> >>>>> diff --git >>>>> a/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java >>>>> b/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java >>>>> --- >>>>> a/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java >>>>> +++ >>>>> b/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java >>>>> @@ -15,7 +15,7 @@ >>>>> >>>>> >>>>> String s1 = "plugindebug 1384850630162925 >>>>> [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 CET >>>>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1204] >>>>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: PIPE: >>>>> plugin read: plugin PluginProxyInfo reference >>>>> 1http://www.walter-fendt.de:80"; >>>>> - String s2 = "plugindebugX 1384850630162954 >>>>> [jvanek][ITW-Cplugindebug >>>>> 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 >>>>> 09:43:50 >>>>> CET >>>>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] >>>>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: parts[0]=plugin, >>>>> parts[1]=PluginProxyInfo, reference, parts[3]=1, >>>>> parts[4]=http://www.walter-fendt.de:80 -- >>>>> decoded_url=http://www.walter-fendt.de:80"; >>>>> + String s2 = "plugindebugX blob [jvanek][ITW-Cplugindebug >>>>> 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 >>>>> 09:43:50 >>>>> CET >>>>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] >>>>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: parts[0]=plugin, >>>>> parts[1]=PluginProxyInfo, reference, parts[3]=1, >>>>> parts[4]=http://www.walter-fendt.de:80 -- >>>>> decoded_url=http://www.walter-fendt.de:80"; >>>>> String s3 = "preinit_pluginerror 1384850630163298 >>>>> [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 CET >>>>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1134] >>>>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: Proxy >>>>> info: >>>>> plugin PluginProxyInfo reference 1 DIRECT"; >>>>> >>>>> @Test >>>>> @@ -47,12 +47,9 @@ >>>>> PluginMessage p2 = new PluginMessage(s2); >>>>> Assert.assertTrue(p2.wasError); >>>>> Assert.assertTrue(p2.header.isC); >>>>> - >>>>> Assert.assertEquals(OutputController.Level.WARNING_ALL,p2.header.level); >>>>> - Assert.assertTrue(p2.header.date.toString().contains(new >>>>> Date().toString().substring(0,16))); //means no Tue Nov 19 09:43:50 :) >>>>> - Assert.assertTrue(p2.header.user.equals("jvanek")); >>>>> + Assert.assertEquals(OutputController.Level.WARNING_ALL, >>>>> p2.header.level); >>>>> + Assert.assertTrue(p2.header.date.toString().contains(new >>>>> Date().toString().substring(0, 16))); //means no Tue Nov 19 09:43:50 :) >>>>> Assert.assertTrue(p2.header.thread1.equals("unknown")); >>>>> Assert.assertTrue(p2.header.thread2.equals("unknown")); >>>>> - >>>>> - >>>>> } >>>>> } >>>>> >>>> >>>> >>>> This is ok. What else to do? >>>> >>>> Just one nit - may you please add separate test for original String s2? >>> >>> Hello, >>> >>> >>> The issue I found causing the old test to fail was that the PluginMessage >>> for s2 had new behaviour: >>> >>> String s2 = "plugindebugX 1384850630162954 [jvanek][ITW-Cplugindebug >>> 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 >>> 09:43:50 CET >>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] >>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: >>> parts[0]=plugin, parts[1]=PluginProxyInfo, reference, parts[3]=1, >>> parts[4]=http://www.walter-fendt.de:80 -- >>> decoded_url=http://www.walter-fendt.de:80"; >>> >>> >>> Before: >>> >>> message.header.date = 'ITW-C-PLUGIN' : this causes an exception to occur >>> when we attempt to convert this to 'java.util.Date' >>> >>> After: >>> >>> message.header.date is now a String : there is no exception occurring and >>> 'ITW-C-PLUGIN' is accepted. >>> >>> This means that PluginMessage for s2 has 'wasError == false', since no >>> exception occurs when parsing. >>> >>> I feel like a test for this string is not very helpful anymore. >>> >> Oposite here. It is testing some beaviour. >> >> So it deserves specvial test. >> assert waserror==true and some other fields for it ... > > For s2: wasError == false > > So assertTrue(wasError) will fail :\ > > Suggestions?;; > O lot of.... I think orrigianal s2 now belongs to CreatePluginHeaderTestOK ? From jkang at redhat.com Tue Nov 25 15:34:12 2014 From: jkang at redhat.com (Jie Kang) Date: Tue, 25 Nov 2014 10:34:12 -0500 (EST) Subject: [rfc][icedtea-web] Fix for JavaConsoleTest In-Reply-To: <54749EAE.2050704@redhat.com> References: <621475145.3818905.1416926502684.JavaMail.zimbra@redhat.com> <547495BE.7090208@redhat.com> <1736692535.3827410.1416927301406.JavaMail.zimbra@redhat.com> <54749AED.6000700@redhat.com> <1409966998.3836203.1416928168140.JavaMail.zimbra@redhat.com> <54749EAE.2050704@redhat.com> Message-ID: <1545506389.3849295.1416929652718.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 11/25/2014 04:09 PM, Jie Kang wrote: > > > > > > ----- Original Message ----- > >> On 11/25/2014 03:55 PM, Jie Kang wrote: > >>> > >>> > >>> ----- Original Message ----- > >>>> On 11/25/2014 03:41 PM, Jie Kang wrote: > >>>>> Hello, > >>>>> > >>>>> > >>>>> This patch fixes a newly failing unit test in JavaConsoleTest related > >>>>> to > >>>>> PR2063 [1]. > >>>>> > >>>>> The test 'CreatePluginHeaderTestNotOK' fails due to the changes to > >>>>> PluginMessage, PluginHeader and Header. The test has been fixed in > >>>>> accordance with the changes and now passes. > >>>>> > >>>>> How does it look? > >>>>> > >>>>> > >>>>> [1]http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2063 > >>>>> > >>>>> > >>>>> Regards, > >>>>> > >>>>> -- Jie Kang > >>>>> > >>>>> > >>>>> itw-java-console-test.patch > >>>>> > >>>>> > >>>>> diff --git > >>>>> a/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java > >>>>> b/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java > >>>>> --- > >>>>> a/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java > >>>>> +++ > >>>>> b/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java > >>>>> @@ -15,7 +15,7 @@ > >>>>> > >>>>> > >>>>> String s1 = "plugindebug 1384850630162925 > >>>>> [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 CET > >>>>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1204] > >>>>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: PIPE: > >>>>> plugin read: plugin PluginProxyInfo reference > >>>>> 1http://www.walter-fendt.de:80"; > >>>>> - String s2 = "plugindebugX 1384850630162954 > >>>>> [jvanek][ITW-Cplugindebug > >>>>> 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 > >>>>> 09:43:50 > >>>>> CET > >>>>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] > >>>>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: parts[0]=plugin, > >>>>> parts[1]=PluginProxyInfo, reference, parts[3]=1, > >>>>> parts[4]=http://www.walter-fendt.de:80 -- > >>>>> decoded_url=http://www.walter-fendt.de:80"; > >>>>> + String s2 = "plugindebugX blob [jvanek][ITW-Cplugindebug > >>>>> 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 > >>>>> 09:43:50 > >>>>> CET > >>>>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] > >>>>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: parts[0]=plugin, > >>>>> parts[1]=PluginProxyInfo, reference, parts[3]=1, > >>>>> parts[4]=http://www.walter-fendt.de:80 -- > >>>>> decoded_url=http://www.walter-fendt.de:80"; > >>>>> String s3 = "preinit_pluginerror 1384850630163298 > >>>>> [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 CET > >>>>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1134] > >>>>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: Proxy > >>>>> info: > >>>>> plugin PluginProxyInfo reference 1 DIRECT"; > >>>>> > >>>>> @Test > >>>>> @@ -47,12 +47,9 @@ > >>>>> PluginMessage p2 = new PluginMessage(s2); > >>>>> Assert.assertTrue(p2.wasError); > >>>>> Assert.assertTrue(p2.header.isC); > >>>>> - > >>>>> Assert.assertEquals(OutputController.Level.WARNING_ALL,p2.header.level); > >>>>> - Assert.assertTrue(p2.header.date.toString().contains(new > >>>>> Date().toString().substring(0,16))); //means no Tue Nov 19 09:43:50 :) > >>>>> - Assert.assertTrue(p2.header.user.equals("jvanek")); > >>>>> + Assert.assertEquals(OutputController.Level.WARNING_ALL, > >>>>> p2.header.level); > >>>>> + Assert.assertTrue(p2.header.date.toString().contains(new > >>>>> Date().toString().substring(0, 16))); //means no Tue Nov 19 09:43:50 :) > >>>>> Assert.assertTrue(p2.header.thread1.equals("unknown")); > >>>>> Assert.assertTrue(p2.header.thread2.equals("unknown")); > >>>>> - > >>>>> - > >>>>> } > >>>>> } > >>>>> > >>>> > >>>> > >>>> This is ok. What else to do? > >>>> > >>>> Just one nit - may you please add separate test for original String s2? > >>> > >>> Hello, > >>> > >>> > >>> The issue I found causing the old test to fail was that the PluginMessage > >>> for s2 had new behaviour: > >>> > >>> String s2 = "plugindebugX 1384850630162954 > >>> [jvanek][ITW-Cplugindebug > >>> 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 > >>> 09:43:50 CET > >>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] > >>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: > >>> parts[0]=plugin, parts[1]=PluginProxyInfo, reference, parts[3]=1, > >>> parts[4]=http://www.walter-fendt.de:80 -- > >>> decoded_url=http://www.walter-fendt.de:80"; > >>> > >>> > >>> Before: > >>> > >>> message.header.date = 'ITW-C-PLUGIN' : this causes an exception to > >>> occur > >>> when we attempt to convert this to 'java.util.Date' > >>> > >>> After: > >>> > >>> message.header.date is now a String : there is no exception occurring > >>> and > >>> 'ITW-C-PLUGIN' is accepted. > >>> > >>> This means that PluginMessage for s2 has 'wasError == false', since no > >>> exception occurs when parsing. > >>> > >>> I feel like a test for this string is not very helpful anymore. > >>> > >> Oposite here. It is testing some beaviour. > >> > >> So it deserves specvial test. > >> assert waserror==true and some other fields for it ... > > > > For s2: wasError == false > > > > So assertTrue(wasError) will fail :\ > > > > Suggestions?;; > > > > O lot of.... > > I think orrigianal s2 now belongs to > CreatePluginHeaderTestOK > > ? Okay then. It just feels weird to me to put it there. Patch attached. Thanks! > > -- Jie Kang -------------- next part -------------- A non-text attachment was scrubbed... Name: itw-java-console-test-1.patch Type: text/x-patch Size: 5530 bytes Desc: not available URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141125/d7e007fa/itw-java-console-test-1-0001.patch> From jvanek at redhat.com Tue Nov 25 15:37:09 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 25 Nov 2014 16:37:09 +0100 Subject: [rfc][icedtea-web] Fix for JavaConsoleTest In-Reply-To: <1545506389.3849295.1416929652718.JavaMail.zimbra@redhat.com> References: <621475145.3818905.1416926502684.JavaMail.zimbra@redhat.com> <547495BE.7090208@redhat.com> <1736692535.3827410.1416927301406.JavaMail.zimbra@redhat.com> <54749AED.6000700@redhat.com> <1409966998.3836203.1416928168140.JavaMail.zimbra@redhat.com> <54749EAE.2050704@redhat.com> <1545506389.3849295.1416929652718.JavaMail.zimbra@redhat.com> Message-ID: <5474A225.1070109@redhat.com> Well, this is cosmetic, but why - s2... + s2.. + s3 + s4.. It making one feels like s2 wa chnaged (and not just renamed) sorry for nitpicking, but may you adapt it to s2... + s3.. + s4 ? Ok to push afterwards, J. On 11/25/2014 04:34 PM, Jie Kang wrote: > > > ----- Original Message ----- >> On 11/25/2014 04:09 PM, Jie Kang wrote: >>> >>> >>> ----- Original Message ----- >>>> On 11/25/2014 03:55 PM, Jie Kang wrote: >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> On 11/25/2014 03:41 PM, Jie Kang wrote: >>>>>>> Hello, >>>>>>> >>>>>>> >>>>>>> This patch fixes a newly failing unit test in JavaConsoleTest related >>>>>>> to >>>>>>> PR2063 [1]. >>>>>>> >>>>>>> The test 'CreatePluginHeaderTestNotOK' fails due to the changes to >>>>>>> PluginMessage, PluginHeader and Header. The test has been fixed in >>>>>>> accordance with the changes and now passes. >>>>>>> >>>>>>> How does it look? >>>>>>> >>>>>>> >>>>>>> [1]http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2063 >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> -- Jie Kang >>>>>>> >>>>>>> >>>>>>> itw-java-console-test.patch >>>>>>> >>>>>>> >>>>>>> diff --git >>>>>>> a/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java >>>>>>> b/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java >>>>>>> --- >>>>>>> a/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java >>>>>>> +++ >>>>>>> b/tests/netx/unit/net/sourceforge/jnlp/util/logging/JavaConsoleTest.java >>>>>>> @@ -15,7 +15,7 @@ >>>>>>> >>>>>>> >>>>>>> String s1 = "plugindebug 1384850630162925 >>>>>>> [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 CET >>>>>>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1204] >>>>>>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: PIPE: >>>>>>> plugin read: plugin PluginProxyInfo reference >>>>>>> 1http://www.walter-fendt.de:80"; >>>>>>> - String s2 = "plugindebugX 1384850630162954 >>>>>>> [jvanek][ITW-Cplugindebug >>>>>>> 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 >>>>>>> 09:43:50 >>>>>>> CET >>>>>>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] >>>>>>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: parts[0]=plugin, >>>>>>> parts[1]=PluginProxyInfo, reference, parts[3]=1, >>>>>>> parts[4]=http://www.walter-fendt.de:80 -- >>>>>>> decoded_url=http://www.walter-fendt.de:80"; >>>>>>> + String s2 = "plugindebugX blob [jvanek][ITW-Cplugindebug >>>>>>> 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 >>>>>>> 09:43:50 >>>>>>> CET >>>>>>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] >>>>>>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: parts[0]=plugin, >>>>>>> parts[1]=PluginProxyInfo, reference, parts[3]=1, >>>>>>> parts[4]=http://www.walter-fendt.de:80 -- >>>>>>> decoded_url=http://www.walter-fendt.de:80"; >>>>>>> String s3 = "preinit_pluginerror 1384850630163298 >>>>>>> [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 09:43:50 CET >>>>>>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1134] >>>>>>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: Proxy >>>>>>> info: >>>>>>> plugin PluginProxyInfo reference 1 DIRECT"; >>>>>>> >>>>>>> @Test >>>>>>> @@ -47,12 +47,9 @@ >>>>>>> PluginMessage p2 = new PluginMessage(s2); >>>>>>> Assert.assertTrue(p2.wasError); >>>>>>> Assert.assertTrue(p2.header.isC); >>>>>>> - >>>>>>> Assert.assertEquals(OutputController.Level.WARNING_ALL,p2.header.level); >>>>>>> - Assert.assertTrue(p2.header.date.toString().contains(new >>>>>>> Date().toString().substring(0,16))); //means no Tue Nov 19 09:43:50 :) >>>>>>> - Assert.assertTrue(p2.header.user.equals("jvanek")); >>>>>>> + Assert.assertEquals(OutputController.Level.WARNING_ALL, >>>>>>> p2.header.level); >>>>>>> + Assert.assertTrue(p2.header.date.toString().contains(new >>>>>>> Date().toString().substring(0, 16))); //means no Tue Nov 19 09:43:50 :) >>>>>>> Assert.assertTrue(p2.header.thread1.equals("unknown")); >>>>>>> Assert.assertTrue(p2.header.thread2.equals("unknown")); >>>>>>> - >>>>>>> - >>>>>>> } >>>>>>> } >>>>>>> >>>>>> >>>>>> >>>>>> This is ok. What else to do? >>>>>> >>>>>> Just one nit - may you please add separate test for original String s2? >>>>> >>>>> Hello, >>>>> >>>>> >>>>> The issue I found causing the old test to fail was that the PluginMessage >>>>> for s2 had new behaviour: >>>>> >>>>> String s2 = "plugindebugX 1384850630162954 >>>>> [jvanek][ITW-Cplugindebug >>>>> 1384850630163008 [jvanek][ITW-C-PLUGIN][MESSAGE_DEBUG][Tue Nov 19 >>>>> 09:43:50 CET >>>>> 2013][/home/jvanek/Desktop/icedtea-web/plugin/icedteanp/IcedTeaNPPlugin.cc:1124] >>>>> ITNPP Thread# 140513434003264, gthread 0x7fcbd531f8c0: >>>>> parts[0]=plugin, parts[1]=PluginProxyInfo, reference, parts[3]=1, >>>>> parts[4]=http://www.walter-fendt.de:80 -- >>>>> decoded_url=http://www.walter-fendt.de:80"; >>>>> >>>>> >>>>> Before: >>>>> >>>>> message.header.date = 'ITW-C-PLUGIN' : this causes an exception to >>>>> occur >>>>> when we attempt to convert this to 'java.util.Date' >>>>> >>>>> After: >>>>> >>>>> message.header.date is now a String : there is no exception occurring >>>>> and >>>>> 'ITW-C-PLUGIN' is accepted. >>>>> >>>>> This means that PluginMessage for s2 has 'wasError == false', since no >>>>> exception occurs when parsing. >>>>> >>>>> I feel like a test for this string is not very helpful anymore. >>>>> >>>> Oposite here. It is testing some beaviour. >>>> >>>> So it deserves specvial test. >>>> assert waserror==true and some other fields for it ... >>> >>> For s2: wasError == false >>> >>> So assertTrue(wasError) will fail :\ >>> >>> Suggestions?;; >>> >> >> O lot of.... >> >> I think orrigianal s2 now belongs to >> CreatePluginHeaderTestOK >> >> ? > > > Okay then. It just feels weird to me to put it there. > > > Patch attached. > > > Thanks! >> >> > From jvanek at redhat.com Wed Nov 26 16:46:01 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Wed, 26 Nov 2014 17:46:01 +0100 Subject: [rfc][icedtea-web] 1.5.2 release? In-Reply-To: <546E085D.9070903@redhat.com> References: <544A4C3A.6010507@redhat.com> <544BBF23.5010307@redhat.com> <5458FCF0.3060504@redhat.com> <545A5C12.1000408@redhat.com> <545A5CD2.70707@redhat.com> <545A5D97.803@redhat.com> <1599683181.4258978.1415222751770.JavaMail.zimbra@redhat.com> <545B3A67.9020509@redhat.com> <5460CF83.2080509@redhat.com> <546622C2.5050305@redhat.com> <546E085D.9070903@redhat.com> Message-ID: <547603C9.1060705@redhat.com> On 11/20/2014 04:27 PM, Jiri Vanek wrote: > Hi All, please consider 1.5 branch of ITW as frozen. > > Lukas, Andrew and Jie. > > Here pre tarball of 1.5.2 > http://icedtea.wildebeest.org/download/source/icedtea-web-1.5.2.tar.gz updated f8656d18345a7d1e2eb20e076abcc3ca icedtea-web-1.5.2.tar.gz tarball available. > 7b82fd7138d14c002b69898a873be0cf icedtea-web-1.5.2.tar.gz > > I have tested it on jdk 7 and 8 and looks good. 6 is remianing on my side. > Please try to test it as heavily as usually > - especially all reproducers on firefox. You can use my deaily testing for comparsion > - all manual testcases on firefox/javaws > - all should work with jdk 6,7,8, feel free to split work among yourselves. > - unittests, cpp tests whatever you think is reasonable > > I would like to release this really minor release at wednesday. > > Thank you in advance! > J. > > > On 11/14/2014 04:41 PM, Jiri Vanek wrote: >> On 11/10/2014 03:45 PM, Jiri Vanek wrote: >>> On 11/06/2014 10:07 AM, Jiri Vanek wrote: >>>> On 11/05/2014 10:25 PM, Lukasz Dracz wrote: >>>>> Hello, >>>>> >>>>> I don't think there is a point to backporting >>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/d8e057783109 >>>>> since I would probably need to backport also: >>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/e30d71ab91c6 which was the refactor of the cache >>>>> panel. >>>>> I can do that if you still think it would be worthwhile to be backported. >>>>> All it adds was a tooltip for the spinner, and 1.5 still uses the slider. I could add a tooltip >>>>> for the slider I guess but they are somewhat different so the Messages would be different. >>>>> >>>> >>>> Fair enough. Then do not backport it. ty fir check! >>>> >>>>> Sorry for missing the IRC chat I was in a thermostat scrum, then went to lunch without noticing. >>>>> I can do the PL translations, my PL should be good enough if needed. I speak it regularly at >>>>> home, and attended Polish Saturday School here in Canada from elementary to high school. I do >>>>> have a good understanding of Polish though I must admit my writing is a little bit rusty with all >>>>> the Polish grammar rules but I can look stuff up if I am unsure :) >>>>> What do we want translated specifically ? >>>>> >>>>> I translated the two parts from Andrew's patch in the messages.properties >>>>> >>>>> CertWarnHTTPSAcceptTip=Zaakceptuj ten certyfikat i zaufaj po??czenie przez HTTPS >>>>> (Accept this certificate and trust a connection via HTTPS) >>>>> >>>>> CertWarnHTTPSRejectTip=Nie akceptuj ten certyfikat i nie buduj po??czenie HTTPS >>>>> (Do not Accept this certificate and do not build a HTTPS connection) >>>>> Establish looked/sounded odd to me so I thought build was more natural. >>>>> >>>> >>>> Great! ty! This is all :) >>>> >>>> Once Andrew pushes his backport, please push thsoe two lines. >>>> (ps: go on wiht transaltor :) >>>>> I have attached the translation, is there anywhere else that needs editing or translating ? >>>>> >>>>> Thank you, >>>>> Lukasz Dracz >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Andrew Azores" <aazores at redhat.com> >>>>>> To: "Jiri Vanek" <jvanek at redhat.com>, "IcedTea Distro List" <distro-pkg-dev at openjdk.java.net>, >>>>>> "Lukasz Dracz" >>>>>> <ldracz at redhat.com> >>>>>> Sent: Wednesday, November 5, 2014 12:25:43 PM >>>>>> Subject: Re: [rfc][icedtea-web] 1.5.2 release? >>>>>> >>>>>> On 11/05/2014 12:22 PM, Jiri Vanek wrote: >>>>>>> On 11/05/2014 06:19 PM, Andrew Azores wrote: >>>>>>>> On 11/04/2014 11:21 AM, Jiri Vanek wrote: >>>>>>>>> On 10/25/2014 05:17 PM, Andrew Azores wrote: >>>>>>>>>> On 10/24/2014 08:55 AM, Jiri Vanek wrote: >>>>>>>>>>> Hi! >>>>>>>>>>> >>>>>>>>>>> There appeared few fixes in head which are maybe worthy to go to >>>>>>>>>>> 1.5 and >>>>>>>>>>> afterward calling for release: >>>>>>>>>>> >>>>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/99d5407fab4a >>>>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/dd6be5e03667 >>>>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/df05d1de5af4 >>>>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/c6af2f50a95e >>>>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/6d62f68fb037 >>>>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/d8e057783109 >>>>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/90faf53bb981 >>>>>>>>>>> http://icedtea.classpath.org/hg/icedtea-web/rev/2979fa371add >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thoughts? >>>>>>>>>>> >>>>>>>>>>> J. >>>>>>>>>> >>>>>>>>>> Sounds like a good plan to me. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>> Hi! I have backported most of them today, except two. >>>>>>>>> "2" is Andrew's and "3" Lukas' >>>>>>>>> >>>>>>>>> "4" is mine, but it is(?) already backported. >>>>>>>>> >>>>>>>>> Guys, please decide whether yours 2 and/or 3 should go to 1.5. If so, >>>>>>>>> please backport. After doing so, and once i got confirmed RH115417 >>>>>>>>> 7, I will try to do a release. >>>>>>>>> >>>>>>>>> >>>>>>>>> TY! >>>>>>>>> >>>>>>>>> J. >>>>>>>> >>>>>>>> Attached is the fixed backport for #2. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> -- >>>>>>>> Andrew Azores >>>>>>>> >>>>>>>> temporary-permissions-button-npe-fix-backport.patch >>>>>>>> >>>>>>>> >>>>>>>> diff --git a/ChangeLog b/ChangeLog >>>>>>>> --- a/ChangeLog >>>>>>>> +++ b/ChangeLog >>>>>>>> @@ -1,3 +1,18 @@ >>>>>>>> +2014-11-05 Andrew Azores<aazores at redhat.com> >>>>>>>> + >>>>>>>> + * netx/net/sourceforge/jnlp/resources/Messages.properties >>>>>>>> + (CertWarnHTTPSAcceptTip, CertWarnHTTPSRejectTip): new messages more >>>>>>>> + applicable for HTTPS cert warning dialogs >>>>>>>> + * netx/net/sourceforge/jnlp/security/dialogs/CertWarningPane.java: >>>>>>>> + distinguish between HTTPS cert warnings and signed applet cert >>>>>>>> warnings. >>>>>>>> + Display appropriate text labels and buttons corresponding to >>>>>>>> either case. >>>>>>>> + * >>>>>>>> netx/net/sourceforge/jnlp/security/dialogs/TemporaryPermissionsButton.java: >>>>>>>> >>>>>>>> + If any of file, securityDelegate, or linkedButton are null, simply >>>>>>>> + disable this component and do not add component listeners >>>>>>>> dependent upon >>>>>>>> + these fields. Also, do not add multiple groups of permissions, >>>>>>>> and do not >>>>>>>> + add the permissions to the securityDelegate until the >>>>>>>> linkedButton is >>>>>>>> + actually clicked (rather than when the menu item is clicked) >>>>>>>> + >>>>>>>> 2014-10-21 Jiri Vanek<jvanek at redhat.com> >>>>>>>> >>>>>>>> Fixed case when already decoded file is wonted from cache >>>>>>>> (RH1154177) >>>>>>>> diff --git a/netx/net/sourceforge/jnlp/resources/Messages.properties >>>>>>>> b/netx/net/sourceforge/jnlp/resources/Messages.properties >>>>>>>> --- a/netx/net/sourceforge/jnlp/resources/Messages.properties >>>>>>>> +++ b/netx/net/sourceforge/jnlp/resources/Messages.properties >>>>>>>> @@ -25,6 +25,8 @@ >>>>>>>> CertWarnCancelTip=Do not run this applet >>>>>>>> CertWarnPolicyTip=Advanced sandbox settings >>>>>>>> CertWarnPolicyEditorItem=Launch PolicyEditor >>>>>>>> +CertWarnHTTPSAcceptTip=Accept this certificate and trust the HTTPS >>>>>>>> connection >>>>>>>> +CertWarnHTTPSRejectTip=Do not accept this certificate and do not >>>>>>>> establish the HTTPS connection >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Hmm. What to do with those two messages? I can supply CZ trasnaltion, >>>>>>> maybe also DE (with help of Severin, Roman or similar :) ) How about >>>>>>> PL? I rembere There was somebody in your surrounding. Wasnt? >>>>>>> >>>>>>> By otherwise - you agree it is ok for 1.5 thsi backport oook? >>>>>>> >>>>>>> Ty! >>>>>>> >>>>>>> J. >>>>>>> >>>>>> >>>>>> Yup, otherwise the backport looks/sounds fine to me. >>>>>> >>>>>> I do know someone from school who might be able to provide PL >>>>>> translations still. But... what about ldracz? ;) probably easier than >>>>>> pulling in some other "volunteer". >>>>>> >>>>>> Thanks, >>>>>> -- >>>>>> Andrew Azores >>>>>> >>>> >>> >>> >>> So on my side ITW 1.5.2 loosk good. I'm still a bit hesitating with waiting to two more fixes: >>> - the [rfc][icedtea-web] merge property arguments into config singleton >> - pushed to head. Once reproducer done, will be backported to 1.5 >> >>> - and Re: [rfc][icedtea-web] Fix to PluginMessage dates for PR2063 >> - afaik work in progress. >>> >>> Especially the second one should be harmless and is bit nasty to be presented. >>> >>> >>> thoughts? >> > From jvanek at redhat.com Thu Nov 27 10:40:50 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 27 Nov 2014 11:40:50 +0100 Subject: IcedTea-Web 1.5.2 released! Message-ID: <5476FFB2.2050004@redhat.com> wget http://icedtea.wildebeest.org/download/source/icedtea-web-1.5.2.tar.gz sha256sum icedtea-web-1.5.2.tar.gz b29e8ff2533cc6521a6509a002001f4c97c80a004460063156d003898da13bf3 icedtea-web-1.5.2.tar.gz md5sum icedtea-web-1.5.2.tar.gz f8656d18345a7d1e2eb20e076abcc3ca icedtea-web-1.5.2.tar.gz Only small bugfixes and enhancements are include. Looking to the news, New in release 1.5.2 (2014-11-26): * NetX - RH1095311, PR574 - References class sun.misc.Ref removed in OpenJDK 9 - fixed, and so buildable on JDK9 - RH1154177 - decoded file needed from cache - fixed NPE in https dialog - empty codebase behaves as "." They are little bit forgotten this time. But looking to the changelog, some people will be happy to see those fixes in: * Fix for http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2014-June/028399.html (long thread) - merge properties in advance made it in * jnlp file is now logged into console too * fixed bug with localized plugin messages headers * backported fix for NPE in https warning dialogue * RH1154177 - retriving already decoded ifle from cache * *jdk9* *support* - itw 1.5.2 is known to work with current state of jdk9, however, some upcoming changes in JDK9 may stop us work again * backported support for latest jacoco with ours bootclasspath patch * empty codebase now accepted as dot one Special thanx goes to: Lukas Dracz Jie Kang and Fridrich Strba Thank you! J, From guillaume at alaux.net Thu Nov 27 12:50:35 2014 From: guillaume at alaux.net (Guillaume Alaux) Date: Thu, 27 Nov 2014 13:50:35 +0100 Subject: IcedTea-Web and chrome/chromium? Message-ID: <CABAOfS-kYGCqZT4wyRjvepyXLOn=09hzP=ZeaKTJE7o0U3Tu1A@mail.gmail.com> Hi all, So I understand chrome/chromium moved away from NPAPI last year [0] but I still see a lot of references to chrome/chromium in IcedTea-Web sources (the ./configure for one takes these `--with-chrome` and `--with-chromium` params) and also on the wiki page. So just to be sure: IcedTea-Web has nothing to do with **recent** versions of chrome/chromium right? [0] http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html -- Guillaume From jvanek at redhat.com Thu Nov 27 13:11:08 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 27 Nov 2014 14:11:08 +0100 Subject: IcedTea-Web and chrome/chromium? In-Reply-To: <CABAOfS-kYGCqZT4wyRjvepyXLOn=09hzP=ZeaKTJE7o0U3Tu1A@mail.gmail.com> References: <CABAOfS-kYGCqZT4wyRjvepyXLOn=09hzP=ZeaKTJE7o0U3Tu1A@mail.gmail.com> Message-ID: <547722EC.9020501@redhat.com> On 11/27/2014 01:50 PM, Guillaume Alaux wrote: > Hi all, > > So I understand chrome/chromium moved away from NPAPI last year [0] > but I still see a lot of references to chrome/chromium in IcedTea-Web > sources (the ./configure for one takes these `--with-chrome` and > `--with-chromium` params) and also on the wiki page. > > So just to be sure: IcedTea-Web has nothing to do with **recent** > versions of chrome/chromium right? Yes you are right, ITW do not work on chromes now, because of missing npapi. The challenge to write ppapi (or whether to do so at all) plugin is sitll open. The lines about chromium are for testsuite only. I have still some systems with old chrome/chromium, and from time to time I try those. J > > [0] http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html > J. From gitne at gmx.de Thu Nov 27 14:13:22 2014 From: gitne at gmx.de (gitne at gmx.de) Date: Thu, 27 Nov 2014 15:13:22 +0100 Subject: IcedTea-Web and chrome/chromium? Message-ID: <trinity-3f1e8624-0e7d-4b9a-a2f0-53e04b294a1c-1417097602750@msvc031> On Thursday, November 27th 2014 at 02:11:08 PM Jiri Vanek wrote: >> On 11/27/2014 01:50 PM, Guillaume Alaux wrote: >> Hi all, >> >> So I understand chrome/chromium moved away from NPAPI last year [0] >> but I still see a lot of references to chrome/chromium in IcedTea-Web >> sources (the ./configure for one takes these `--with-chrome` and >> `--with-chromium` params) and also on the wiki page. >> >> So just to be sure: IcedTea-Web has nothing to do with **recent** >> versions of chrome/chromium right? >> > Yes you are right, ITW do not work on chromes now, because of missing npapi. The challenge to write > ppapi (or whether to do so at all) plugin is still open. I may get to do this, since I would like to implement IcedTea-Web as an ActiveX control for the Internet Explorer. So, after that, PPAPI might be next, but probably primarily for Windows only, although PPAPI is supposed to be designed platform independent. Nevertheless, most testing will probably happen on Windows first. I cannot give you any time estimate when this going to happen (if only I could get hands on my new machine...). Just on a side-note: Deprecating NPAPI in favor of any new API will not really solve any of the problems users and mostly administrators are currently plauged with. The core problem is, as usual, hastly written and buggy plug-ins, not the API. So, it is a stupid thing to do. Simply introducing a new API and believing that now things are going to be much better is just stupid and naive. I am not saying NPAPI is perfect, and there is sure room for improvement, but is also not that bad. > > The lines about chromium are for testsuite only. I have still some systems with old chrome/chromium, > and from time to time I try those. > > J >> >> [0] http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html >> > > J. From jkang at redhat.com Thu Nov 27 14:25:33 2014 From: jkang at redhat.com (Jie Kang) Date: Thu, 27 Nov 2014 09:25:33 -0500 (EST) Subject: [rfc][icedtea-web] menu support In-Reply-To: <54660EBC.2080704@redhat.com> References: <5464E356.7060506@redhat.com> <5464E7A9.4050704@redhat.com> <546601F4.4030209@redhat.com> <54660EBC.2080704@redhat.com> Message-ID: <917628238.5186075.1417098333498.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 11/14/2014 02:21 PM, Jiri Vanek wrote: > > On 11/13/2014 06:17 PM, Jiri Vanek wrote: > >> On 11/13/2014 05:59 PM, Jiri Vanek wrote: > >>> Hi! > >>> > >>> This is support for XDG menus. > >>> > >>> Work can be divided into two bug parts > >>> 1) additional features to "install desktop icon" dialogue > >>> 2) install the menu item > >>> > >>> 2: > >>> Tested in KDE, Gnome3, mate, xfce. (gnome 2 must-to-do) - see javadoc in > >>> XdesktopEntry.java for some > >>> interesting differences. But works surprisingly well. > >>> > >>> 1) our glorious accessdialogue is returning only int. I had to rape it a > >>> bit:( The only other > >>> workaround is to separate desktops's creation to separate class. > >>> COnsidering the many logic in > >>> AccessWarningPane I had inclined to those few if lines (anyway there is > >>> only small possible > >>> workaroound around this "rape 70,40,30,20,0 codes :-/) > >>> > >>> Happy reading :)) > >>> > >>> > >>> J. > >>> > >>> Pleas enote, that [rfc][icedtea-web] ignore npe in pac,a nd fixing > >>> --Xoffliner are also part of this > >>> patch. I will remove them in next rounds/before push (As the fixxes were > >>> already approved anyway). > >>> > >>> > >>> After this is in/during reviw, I will work on new panel to > >>> itweb-settings, which allows removing of > >>> icons and menu entries added by javaws.itweb. > >>> > >>> > >>> General thoughs? > >>> > >>> J. > >> > >> Jsut realized an NPE - in case of ALWAYS_ASK, the information, and > >> getShortcut may be null... > >> > >> > >> J. > >> > > just adapted to head.. Hei I like this menu +offline support :)) > > > Fixed few messages - thay will go to properties at the end anyway. Also I > have chnaged default icon > from java to javaws. My system dont know javaicon, but knows javaws (wellif > you run jnlp you have to > installe dbooth java, and javaws, but javaws icon is under itw maintainance) > > Actually - I have this line in fedora specfile: > cp javaws.png $RPM_BUILD_ROOT%{_datadir}/pixmaps > > Shouldnt our make install do so? (afaik yes) Hello, First: Pretty awesome work!!! :D User-testing on F20 it seems fine, the shorcuts get created and seem to be coded properly. However, not all applets are able to launched through shortcut so it's kind of iffy there. *shrugs* When testing: http://jogamp.org/deployment/jogamp-next/jogl-applet-version-napplet.html I was able to create a shortcut for it, and it ended up being a shortcut to an html file. However, when I launched it, it was not opened in my default browser, instead it was attempted to be opened in javaws :\ I think this might be a bug. If it opened in firefox, it would've worked perfectly. When testing: http://www.arbores.ca/PresentFuture.jnlp I encountered: java.io.FileNotFoundException: /home/jkang/.local/share/applications/javaws/Present/Future Value Calculator.desktop (No such file or directory) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.<init>(FileOutputStream.java:221) at java.io.FileOutputStream.<init>(FileOutputStream.java:171) at net.sourceforge.jnlp.util.XDesktopEntry.installMenuLauncher(XDesktopEntry.java:247) at net.sourceforge.jnlp.util.XDesktopEntry.createDesktopShortcuts(XDesktopEntry.java:232) at net.sourceforge.jnlp.runtime.ApplicationInstance.addMenuAndDesktopEntries(ApplicationInstance.java:179) at net.sourceforge.jnlp.runtime.ApplicationInstance.initialize(ApplicationInstance.java:144) at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:531) at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:912) Not entirely sure what happened, but the shortcut didn't get created :( There are a few nits for the code: Biggest one for me is: Please add more logging messages to make it easier to debug later on: e.g. where shortcut is being saved, etc. Smallest one is: There are a few typos, please try to fix them Actual code comments: diff -r e57ab037cbd0 netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java --- a/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java Fri Nov 14 14:06:06 2014 +0100 +++ b/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java Fri Nov 14 15:16:15 2014 +0100 [...] - private int[] VALID_ICON_SIZES = new int[] { 16, 22, 32, 48, 64, 128 }; + private final int[] VALID_ICON_SIZES = new int[] { 16, 22, 32, 48, 64, 128 }; Please add a comment saying what unit these sizes are (I'm guessing pixels?) + public Reader getContentsAsReader(boolean menu) { String cacheDir = JNLPRuntime.getConfiguration() .getProperty(DeploymentConfiguration.KEY_USER_CACHE_DIR); File cacheFile = CacheUtil.getCacheFile(file.getSourceLocation(), null); Both cacheDir and cacheFile are now unused, please remove these two lines. + private static class IconsCreationDescriptor{ + [...] + public boolean isMenu() { + return menu; + } + + + + These extra spaces should be removed; diff -r e57ab037cbd0 netx/net/sourceforge/jnlp/util/XDesktopEntry.java --- a/netx/net/sourceforge/jnlp/util/XDesktopEntry.java Fri Nov 14 14:06:06 2014 +0100 +++ b/netx/net/sourceforge/jnlp/util/XDesktopEntry.java Fri Nov 14 15:16:15 2014 +0100 [...] + private void cacheIcon() throws IOException { [...] + String origLocation = location.substring("file:".length()); Spacing here needs to be fixed + private static String findAndVerifyJavawsMenuDir() { + File f = PathsAndFiles.MENUS_DIR.getFile(); + String ff = f.getAbsolutePath(); Please rename String ff to something like 'path' or 'menuDir', something that says what the string is representing; private static String evaluateLinuxVariables(String orig, Map<String, String> variables) { Set<Entry<String, String>> env = variables.entrySet(); - List<Entry<String, String>> envVariables = new ArrayList<Entry<String, String>>(env); This could be shortened to: - Set<Entry<String, String>> env = variables.entrySet(); + List<Entry<String, String>> envVariables = new ArrayList<>(variables.entrySet()); I don't see 'env' being used anywhere else and I don't think the extra line to be specific is useful. diff -r e57ab037cbd0 netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java --- a/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java Fri Nov 14 14:06:06 2014 +0100 +++ b/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java Fri Nov 14 15:16:15 2014 +0100 @@ -141,11 +141,6 @@ [...] + File possibleMenuFile = entry.getLinuxMenuIconFile(); + //if one of menu or desktop exists, do not bother user + boolean exists = false; If I am reading this right, I think this is a pretty annoying flaw. If a user creates either a menu or desktop shortcut, they can no longer create a shortcut of the other type? That sounds bad to me, can this be reworked? + boolean trullyTrue = (sd != null && (sd.onDesktop() || sd.getMenu() != null)); Please find a better name for this boolean. What does it even check for? diff -r e57ab037cbd0 netx/net/sourceforge/jnlp/config/PathsAndFiles.java --- a/netx/net/sourceforge/jnlp/config/PathsAndFiles.java Fri Nov 14 14:06:06 2014 +0100 +++ b/netx/net/sourceforge/jnlp/config/PathsAndFiles.java Fri Nov 14 15:16:15 2014 +0100 @@ -53,6 +53,7 @@ [...] + private static final String DATA_HOME; I am not sure this is the best name. What is DATA? Atm this name is way too generic, and either needs a comment or renaming. Regards, > > > > J. > -- Jie Kang From jvanek at redhat.com Thu Nov 27 14:38:40 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 27 Nov 2014 15:38:40 +0100 Subject: [rfc][icedtea-web] menu support In-Reply-To: <917628238.5186075.1417098333498.JavaMail.zimbra@redhat.com> References: <5464E356.7060506@redhat.com> <5464E7A9.4050704@redhat.com> <546601F4.4030209@redhat.com> <54660EBC.2080704@redhat.com> <917628238.5186075.1417098333498.JavaMail.zimbra@redhat.com> Message-ID: <54773770.7010408@redhat.com> On 11/27/2014 03:25 PM, Jie Kang wrote: > > > ----- Original Message ----- >> On 11/14/2014 02:21 PM, Jiri Vanek wrote: >>> On 11/13/2014 06:17 PM, Jiri Vanek wrote: >>>> On 11/13/2014 05:59 PM, Jiri Vanek wrote: >>>>> Hi! >>>>> >>>>> This is support for XDG menus. >>>>> >>>>> Work can be divided into two bug parts >>>>> 1) additional features to "install desktop icon" dialogue >>>>> 2) install the menu item >>>>> >>>>> 2: >>>>> Tested in KDE, Gnome3, mate, xfce. (gnome 2 must-to-do) - see javadoc in >>>>> XdesktopEntry.java for some >>>>> interesting differences. But works surprisingly well. >>>>> >>>>> 1) our glorious accessdialogue is returning only int. I had to rape it a >>>>> bit:( The only other >>>>> workaround is to separate desktops's creation to separate class. >>>>> COnsidering the many logic in >>>>> AccessWarningPane I had inclined to those few if lines (anyway there is >>>>> only small possible >>>>> workaroound around this "rape 70,40,30,20,0 codes :-/) >>>>> >>>>> Happy reading :)) >>>>> >>>>> >>>>> J. >>>>> >>>>> Pleas enote, that [rfc][icedtea-web] ignore npe in pac,a nd fixing >>>>> --Xoffliner are also part of this >>>>> patch. I will remove them in next rounds/before push (As the fixxes were >>>>> already approved anyway). >>>>> >>>>> >>>>> After this is in/during reviw, I will work on new panel to >>>>> itweb-settings, which allows removing of >>>>> icons and menu entries added by javaws.itweb. >>>>> >>>>> >>>>> General thoughs? >>>>> >>>>> J. >>>> >>>> Jsut realized an NPE - in case of ALWAYS_ASK, the information, and >>>> getShortcut may be null... >>>> >>>> >>>> J. >>>> >>> just adapted to head.. Hei I like this menu +offline support :)) >> >> >> Fixed few messages - thay will go to properties at the end anyway. Also I >> have chnaged default icon >> from java to javaws. My system dont know javaicon, but knows javaws (wellif >> you run jnlp you have to >> installe dbooth java, and javaws, but javaws icon is under itw maintainance) >> >> Actually - I have this line in fedora specfile: >> cp javaws.png $RPM_BUILD_ROOT%{_datadir}/pixmaps >> >> Shouldnt our make install do so? (afaik yes) > > > > Hello, > > > First: Pretty awesome work!!! :D > > > > User-testing on F20 it seems fine, the shorcuts get created and seem to be coded properly. However, not all applets are able to launched through shortcut so it's kind of iffy there. *shrugs* > > When testing: http://jogamp.org/deployment/jogamp-next/jogl-applet-version-napplet.html > > I was able to create a shortcut for it, and it ended up being a shortcut to an html file. However, when I launched it, it was not opened in my default browser, instead it was attempted to be opened in javaws :\ I think this might be a bug. If it opened in firefox, it would've worked perfectly. > > > > When testing: http://www.arbores.ca/PresentFuture.jnlp > > I encountered: > > java.io.FileNotFoundException: /home/jkang/.local/share/applications/javaws/Present/Future Value Calculator.desktop (No such file or directory) > at java.io.FileOutputStream.open(Native Method) > at java.io.FileOutputStream.<init>(FileOutputStream.java:221) > at java.io.FileOutputStream.<init>(FileOutputStream.java:171) > at net.sourceforge.jnlp.util.XDesktopEntry.installMenuLauncher(XDesktopEntry.java:247) > at net.sourceforge.jnlp.util.XDesktopEntry.createDesktopShortcuts(XDesktopEntry.java:232) > at net.sourceforge.jnlp.runtime.ApplicationInstance.addMenuAndDesktopEntries(ApplicationInstance.java:179) > at net.sourceforge.jnlp.runtime.ApplicationInstance.initialize(ApplicationInstance.java:144) > at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:531) > at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:912) > > Not entirely sure what happened, but the shortcut didn't get created :( Those are perfectly known issues to me. On top of this patch I have prety bug patch whih is allowing ahml applets to be working as menu entries. So please keep this disfunctionality out of review now. - basicallky - I'm allowing two and half types of browser-applets shortcuts: 1) - I fpound system browser, and do plain entry llike: firefox html_yuo_are_on - working fine unless your browser is chrome... - the search is simlar as "find on path" approach 2) I generate jnlp <applet-desc> file form html - this iw working surprisngly awesome! And all applets I tested run well without browser! 3) I'm using jnlp_hreff-ed file as target jnlp -this is working surprisngly wrong :(( Some crucial elements are mostly miissing (eg I need to check if codebase , title and vendor are included and add them if they are not. 4) in progress - instead of our -jnlp argument, I wont to intorducece -html argument - and so be able to lunch out of browser applet, bat read from html's applet/object tag. Not sure how sucessfull this willbe:( Thoughts?? For nits in commnets: Thank you for review, I will post updtaed patch tomorrow. As for unclear location - I really wont to include tab in itweb-settings, which will allow to manage those (but after html shortcuts are done) J. > > > There are a few nits for the code: > > Biggest one for me is: Please add more logging messages to make it easier to debug later on: e.g. where shortcut is being saved, etc. > > Smallest one is: There are a few typos, please try to fix them > > > Actual code comments: > > diff -r e57ab037cbd0 netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java > --- a/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java Fri Nov 14 14:06:06 2014 +0100 > +++ b/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java Fri Nov 14 15:16:15 2014 +0100 > [...] > > - private int[] VALID_ICON_SIZES = new int[] { 16, 22, 32, 48, 64, 128 }; > + private final int[] VALID_ICON_SIZES = new int[] { 16, 22, 32, 48, 64, 128 }; > > Please add a comment saying what unit these sizes are (I'm guessing pixels?) > > > + public Reader getContentsAsReader(boolean menu) { > > String cacheDir = JNLPRuntime.getConfiguration() > .getProperty(DeploymentConfiguration.KEY_USER_CACHE_DIR); > File cacheFile = CacheUtil.getCacheFile(file.getSourceLocation(), null); > > Both cacheDir and cacheFile are now unused, please remove these two lines. > > > + private static class IconsCreationDescriptor{ > + > [...] > + public boolean isMenu() { > + return menu; > + } > + > + > + > + > > These extra spaces should be removed; > > > diff -r e57ab037cbd0 netx/net/sourceforge/jnlp/util/XDesktopEntry.java > --- a/netx/net/sourceforge/jnlp/util/XDesktopEntry.java Fri Nov 14 14:06:06 2014 +0100 > +++ b/netx/net/sourceforge/jnlp/util/XDesktopEntry.java Fri Nov 14 15:16:15 2014 +0100 > [...] > + private void cacheIcon() throws IOException { > [...] > + String origLocation = location.substring("file:".length()); > > Spacing here needs to be fixed > > > + private static String findAndVerifyJavawsMenuDir() { > + File f = PathsAndFiles.MENUS_DIR.getFile(); > + String ff = f.getAbsolutePath(); > > Please rename String ff to something like 'path' or 'menuDir', something that says what the string is representing; > > > private static String evaluateLinuxVariables(String orig, Map<String, String> variables) { > Set<Entry<String, String>> env = variables.entrySet(); > - List<Entry<String, String>> envVariables = new ArrayList<Entry<String, String>>(env); > > This could be shortened to: > > - Set<Entry<String, String>> env = variables.entrySet(); > + List<Entry<String, String>> envVariables = new ArrayList<>(variables.entrySet()); > > I don't see 'env' being used anywhere else and I don't think the extra line to be specific is useful. > > > diff -r e57ab037cbd0 netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java > --- a/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java Fri Nov 14 14:06:06 2014 +0100 > +++ b/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java Fri Nov 14 15:16:15 2014 +0100 > @@ -141,11 +141,6 @@ > [...] > + File possibleMenuFile = entry.getLinuxMenuIconFile(); > + //if one of menu or desktop exists, do not bother user > + boolean exists = false; > > If I am reading this right, I think this is a pretty annoying flaw. If a user creates either a menu or desktop shortcut, they can no longer create a shortcut of the other type? That sounds bad to me, can this be reworked? > > + boolean trullyTrue = (sd != null && (sd.onDesktop() || sd.getMenu() != null)); > > Please find a better name for this boolean. What does it even check for? > > > diff -r e57ab037cbd0 netx/net/sourceforge/jnlp/config/PathsAndFiles.java > --- a/netx/net/sourceforge/jnlp/config/PathsAndFiles.java Fri Nov 14 14:06:06 2014 +0100 > +++ b/netx/net/sourceforge/jnlp/config/PathsAndFiles.java Fri Nov 14 15:16:15 2014 +0100 > @@ -53,6 +53,7 @@ > [...] > + private static final String DATA_HOME; > > I am not sure this is the best name. What is DATA? Atm this name is way too generic, and either needs a comment or renaming. > > > > > > Regards, > >> >> >> >> J. >> > From jkang at redhat.com Thu Nov 27 21:07:17 2014 From: jkang at redhat.com (Jie Kang) Date: Thu, 27 Nov 2014 16:07:17 -0500 (EST) Subject: [rfc][icedtea-web] Add last-modified information to TinyHttpdImpl In-Reply-To: <209310647.5279659.1417122367340.JavaMail.zimbra@redhat.com> Message-ID: <705513521.5279844.1417122437231.JavaMail.zimbra@redhat.com> Hello, This patch adds the Last-Modified field to responses from our reproducer server TinyHttpdImpl. This allows for reproducers to also test the re-download system that we currently have in Icedtea-Web, which uses the last-modified field to determine whether or not to download things again. Thoughts? Regards, -- Jie Kang -------------- next part -------------- A non-text attachment was scrubbed... Name: itw-tinyhttpdimpl-lastmodified.patch Type: text/x-patch Size: 1144 bytes Desc: not available URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141127/bb6c6f15/itw-tinyhttpdimpl-lastmodified.patch> From jkang at redhat.com Thu Nov 27 21:12:49 2014 From: jkang at redhat.com (Jie Kang) Date: Thu, 27 Nov 2014 16:12:49 -0500 (EST) Subject: [rfc][icedtea-web] Download Resource Unit Test for ResourceTracker In-Reply-To: <546608DB.2060102@redhat.com> References: <1431325567.6214144.1415650163295.JavaMail.zimbra@redhat.com> <546608DB.2060102@redhat.com> Message-ID: <368773657.5280296.1417122769203.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 11/10/2014 09:09 PM, Jie Kang wrote: > > Hello, > > > > This patch adds a simple test to cover ResourceTracker's ability to > > download a file into the cache system. > > > > How does it look? > > > > > > Regards, > > > > > Well - this is ok, but I got little bit more in mind. > > > Please no unrelated changes like import reordering, static import and so > on... unless necesary. > > Afaik cache management allows you to clean only one downloaded resource - so > you may think about > this instead of clearcache. Also I think you need to clean cache in > @beforeclass. Otherwise > rt.getCacheFile will return cached file (if any) and so not verifing that the > new one actually was > downlaoded. > > > Also you are testing only downloading of simple resource.. well I guess it is > ok. but what I had in > mind, were atomic tests also for > > > + private URLConnection getDownloadConnection(URL location) throws > IOException { > + private void downloadGZipFile(Resource resource, URLConnection > connection, URL downloadFrom, > + private void downloadFile(Resource resource, URLConnection connection, > URL downloadFrom) > + private void storeEntryFields(CacheEntry entry, long contentLength, long > lastModified) { > + private void writeDownloadToFile(Resource resource, URL > downloadLocation, InputStream in) > + private void uncompressGzip(URL compressedLocation, URL > uncompressedLocation) > + private void uncompressPackGz(URL compressedLocation, URL > uncompressedLocation) throws > > > new methods. Hello, I'm not sure how you want me to test these as they are all private methods. Do you want them to be 'protected' so I can write unit tests for them? Regards, > > > J. > > > Note - in patch as it is now, I would not allow the unrelated chnages. > However, if you will test all > the new methods, then they may become really handy and it will be ok from my > side. > -- Jie Kang From jkang at redhat.com Thu Nov 27 21:16:13 2014 From: jkang at redhat.com (Jie Kang) Date: Thu, 27 Nov 2014 16:16:13 -0500 (EST) Subject: [rfc][icedtea-web] Download Resource Unit Test for ResourceTracker In-Reply-To: <54660BF0.8040506@redhat.com> References: <1431325567.6214144.1415650163295.JavaMail.zimbra@redhat.com> <54660BF0.8040506@redhat.com> Message-ID: <647853976.5280521.1417122973535.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 11/10/2014 09:09 PM, Jie Kang wrote: > > Hello, > > > > This patch adds a simple test to cover ResourceTracker's ability to > > download a file into the cache system. > > > > How does it look? > > > > > > Regards, > > > > oh - without the unrelated changes, with cleanCache before testrun, and > (maybe) wit clean of the > only downlaoded file - this sounds good (as it is now) to me also fo 1.5. > Hello, The current test uses a temporary directory for cache and clears the temporary directory afterwards [1]. It does not mess with the user's cache or anything. I think this should be enough, no? [1] + @BeforeClass + public static void setupDownloadServer() throws IOException { + File dir = new File(System.getProperty("java.io.tmpdir"), "itw-down"); + dir.mkdirs(); + dir.deleteOnExit(); + redirectErr(); + downloadServer = ServerAccess.getIndependentInstance(dir.getAbsolutePath(), ServerAccess.findFreePort()); + redirectErrBack(); + + JNLPRuntime.getConfiguration().setProperty(DeploymentConfiguration.KEY_USER_CACHE_DIR, System.getProperty("java.io.tmpdir") + File.separator + "tempcache"); Uses temporary directory as cache + } + + @AfterClass + public static void teardownDownloadServer() { + downloadServer.stop(); + + CacheUtil.clearCache(); Clears it afterwards. + } > > J. > -- Jie Kang From jvanek at redhat.com Fri Nov 28 09:51:11 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 28 Nov 2014 10:51:11 +0100 Subject: [rfc][icedtea-web] Download Resource Unit Test for ResourceTracker In-Reply-To: <368773657.5280296.1417122769203.JavaMail.zimbra@redhat.com> References: <1431325567.6214144.1415650163295.JavaMail.zimbra@redhat.com> <546608DB.2060102@redhat.com> <368773657.5280296.1417122769203.JavaMail.zimbra@redhat.com> Message-ID: <5478458F.8030202@redhat.com> On 11/27/2014 10:12 PM, Jie Kang wrote: > > > ----- Original Message ----- >> On 11/10/2014 09:09 PM, Jie Kang wrote: >>> Hello, >>> >>> This patch adds a simple test to cover ResourceTracker's ability to >>> download a file into the cache system. >>> >>> How does it look? >>> >>> >>> Regards, >>> >> >> >> Well - this is ok, but I got little bit more in mind. >> >> >> Please no unrelated changes like import reordering, static import and so >> on... unless necesary. >> >> Afaik cache management allows you to clean only one downloaded resource - so >> you may think about >> this instead of clearcache. Also I think you need to clean cache in >> @beforeclass. Otherwise >> rt.getCacheFile will return cached file (if any) and so not verifing that the >> new one actually was >> downlaoded. >> >> >> Also you are testing only downloading of simple resource.. well I guess it is >> ok. but what I had in >> mind, were atomic tests also for >> >> >> + private URLConnection getDownloadConnection(URL location) throws >> IOException { >> + private void downloadGZipFile(Resource resource, URLConnection >> connection, URL downloadFrom, >> + private void downloadFile(Resource resource, URLConnection connection, >> URL downloadFrom) >> + private void storeEntryFields(CacheEntry entry, long contentLength, long >> lastModified) { >> + private void writeDownloadToFile(Resource resource, URL >> downloadLocation, InputStream in) >> + private void uncompressGzip(URL compressedLocation, URL >> uncompressedLocation) >> + private void uncompressPackGz(URL compressedLocation, URL >> uncompressedLocation) throws >> >> >> new methods. > > > Hello, > > > I'm not sure how you want me to test these as they are all private methods. > > Do you want them to be 'protected' so I can write unit tests for them? > rather package private but yes.... Because of people do not like testing private methods, I think we should extend our testsuite to be able to do so;) > > Regards, > >> >> >> J. >> >> >> Note - in patch as it is now, I would not allow the unrelated chnages. >> However, if you will test all >> the new methods, then they may become really handy and it will be ok from my >> side. >> > From jvanek at redhat.com Fri Nov 28 09:52:09 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 28 Nov 2014 10:52:09 +0100 Subject: [rfc][icedtea-web] Download Resource Unit Test for ResourceTracker In-Reply-To: <647853976.5280521.1417122973535.JavaMail.zimbra@redhat.com> References: <1431325567.6214144.1415650163295.JavaMail.zimbra@redhat.com> <54660BF0.8040506@redhat.com> <647853976.5280521.1417122973535.JavaMail.zimbra@redhat.com> Message-ID: <547845C9.9070601@redhat.com> On 11/27/2014 10:16 PM, Jie Kang wrote: > > > ----- Original Message ----- >> On 11/10/2014 09:09 PM, Jie Kang wrote: >>> Hello, >>> >>> This patch adds a simple test to cover ResourceTracker's ability to >>> download a file into the cache system. >>> >>> How does it look? >>> >>> >>> Regards, >>> >> >> oh - without the unrelated changes, with cleanCache before testrun, and >> (maybe) wit clean of the >> only downlaoded file - this sounds good (as it is now) to me also fo 1.5. >> > > > Hello, > > > The current test uses a temporary directory for cache and clears the temporary directory afterwards [1]. It does not mess with the user's cache or anything. I think this should be enough, no? > > > [1] > > + @BeforeClass > + public static void setupDownloadServer() throws IOException { > + File dir = new File(System.getProperty("java.io.tmpdir"), "itw-down"); > + dir.mkdirs(); > + dir.deleteOnExit(); > + redirectErr(); > + downloadServer = ServerAccess.getIndependentInstance(dir.getAbsolutePath(), ServerAccess.findFreePort()); > + redirectErrBack(); > + > + JNLPRuntime.getConfiguration().setProperty(DeploymentConfiguration.KEY_USER_CACHE_DIR, System.getProperty("java.io.tmpdir") + File.separator + "tempcache"); > > Uses temporary directory as cache ok. I have overlooked this. Fair enough then. But please, be sure you restore DeploymentConfiguration.KEY_USER_CACHE_DIR back to previous value after run. J. > > + } > + > + @AfterClass > + public static void teardownDownloadServer() { > + downloadServer.stop(); > + > + CacheUtil.clearCache(); > > Clears it afterwards. > > + } > >> >> J. >> > From arun.gupta at gmail.com Fri Nov 28 17:55:42 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Fri, 28 Nov 2014 09:55:42 -0800 Subject: OpenJDK 8 on CentOS 7 Message-ID: <CAGBoHQU5a8at3o7m+d5N2v+_TK+dDz7bRT_5+LVHCZks=vMDOQ@mail.gmail.com> How do I install OpenJDK 8 on CentOS ? It seems like its not available there yet: http://stackoverflow.com/questions/23916812/openjdk-1-8-package-for-centos-6-5/26919146?noredirect=1#comment42823587_26919146 Any suggestions ? Arun -- http://blog.arungupta.me http://twitter.com/arungupta From dbhole at redhat.com Fri Nov 28 18:06:34 2014 From: dbhole at redhat.com (Deepak Bhole) Date: Fri, 28 Nov 2014 13:06:34 -0500 Subject: OpenJDK 8 on CentOS 7 In-Reply-To: <CAGBoHQU5a8at3o7m+d5N2v+_TK+dDz7bRT_5+LVHCZks=vMDOQ@mail.gmail.com> References: <CAGBoHQU5a8at3o7m+d5N2v+_TK+dDz7bRT_5+LVHCZks=vMDOQ@mail.gmail.com> Message-ID: <20141128180633.GG22689@redhat.com> * Arun Gupta <arun.gupta at gmail.com> [2014-11-28 12:58]: > How do I install OpenJDK 8 on CentOS ? > > It seems like its not available there yet: > http://stackoverflow.com/questions/23916812/openjdk-1-8-package-for-centos-6-5/26919146?noredirect=1#comment42823587_26919146 > > Any suggestions ? > OpenJDK8 is not part of RHEL 7.0 and consequently not in CentOS 7.0. AFAIK it will have to be built manually if it is wanted there. If RPM is needed, you can try building the 6.6 SRPM on 7, though some changes may be needed. Deepak > Arun > > -- > http://blog.arungupta.me > http://twitter.com/arungupta From jvanek at redhat.com Sat Nov 29 11:10:32 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Sat, 29 Nov 2014 12:10:32 +0100 Subject: [rfc][icedtea-web] Add last-modified information to TinyHttpdImpl In-Reply-To: <705513521.5279844.1417122437231.JavaMail.zimbra@redhat.com> References: <705513521.5279844.1417122437231.JavaMail.zimbra@redhat.com> Message-ID: <5479A9A8.7090807@redhat.com> On 11/27/2014 10:07 PM, Jie Kang wrote: > Hello, > > This patch adds the Last-Modified field to responses from our reproducer server TinyHttpdImpl. This allows for reproducers to also test the re-download system that we currently have in Icedtea-Web, which uses the last-modified field to determine whether or not to download things again. > > Thoughts? > > > Regards, > hi! This is good idea. However I would like to add getter/setter for flag, which will allow to enable/disable adding of this header param. And by default have it off, and enable it on demand, when some test is testing redownloading. What do you think? J. From arun.gupta at gmail.com Sat Nov 29 15:11:24 2014 From: arun.gupta at gmail.com (Arun Gupta) Date: Sat, 29 Nov 2014 07:11:24 -0800 Subject: OpenJDK 8 on CentOS 7 In-Reply-To: <20141128180633.GG22689@redhat.com> References: <CAGBoHQU5a8at3o7m+d5N2v+_TK+dDz7bRT_5+LVHCZks=vMDOQ@mail.gmail.com> <20141128180633.GG22689@redhat.com> Message-ID: <CAGBoHQWLm9=jK--K48WAbNXT8JO8XayqQcAUaaC3Z-ZFz9pRjA@mail.gmail.com> Do you know the timelines by which it will be included in CentOS 7.0 ? Any place where a binary build can be downloaded ? Arun On Fri, Nov 28, 2014 at 10:06 AM, Deepak Bhole <dbhole at redhat.com> wrote: > * Arun Gupta <arun.gupta at gmail.com> [2014-11-28 12:58]: >> How do I install OpenJDK 8 on CentOS ? >> >> It seems like its not available there yet: >> http://stackoverflow.com/questions/23916812/openjdk-1-8-package-for-centos-6-5/26919146?noredirect=1#comment42823587_26919146 >> >> Any suggestions ? >> > > OpenJDK8 is not part of RHEL 7.0 and consequently not in CentOS 7.0. > > AFAIK it will have to be built manually if it is wanted there. If RPM is > needed, you can try building the 6.6 SRPM on 7, though some changes may > be needed. > > Deepak > >> Arun >> >> -- >> http://blog.arungupta.me >> http://twitter.com/arungupta -- http://blog.arungupta.me http://twitter.com/arungupta From jvanek at redhat.com Sat Nov 29 17:31:00 2014 From: jvanek at redhat.com (Jiri Vanek) Date: Sat, 29 Nov 2014 18:31:00 +0100 Subject: [rfc][icedtea-web] menu support In-Reply-To: <917628238.5186075.1417098333498.JavaMail.zimbra@redhat.com> References: <5464E356.7060506@redhat.com> <5464E7A9.4050704@redhat.com> <546601F4.4030209@redhat.com> <54660EBC.2080704@redhat.com> <917628238.5186075.1417098333498.JavaMail.zimbra@redhat.com> Message-ID: <547A02D4.7010602@redhat.com> On 11/27/2014 03:25 PM, Jie Kang wrote: > > ----- Original Message ----- >> >On 11/14/2014 02:21 PM, Jiri Vanek wrote: >>> > >On 11/13/2014 06:17 PM, Jiri Vanek wrote: >>>> > >>On 11/13/2014 05:59 PM, Jiri Vanek wrote: >>>>> > >>>Hi! >>>>> > >>> >>>>> > >>>This is support for XDG menus. >>>>> > >>> >>>>> > >>>Work can be divided into two bug parts >>>>> > >>> 1) additional features to "install desktop icon" dialogue >>>>> > >>> 2) install the menu item >>>>> > >>> >>>>> > >>>2: >>>>> > >>>Tested in KDE, Gnome3, mate, xfce. (gnome 2 must-to-do) - see javadoc in >>>>> > >>>XdesktopEntry.java for some >>>>> > >>>interesting differences. But works surprisingly well. >>>>> > >>> >>>>> > >>>1) our glorious accessdialogue is returning only int. I had to rape it a >>>>> > >>>bit:( The only other >>>>> > >>>workaround is to separate desktops's creation to separate class. >>>>> > >>>COnsidering the many logic in >>>>> > >>>AccessWarningPane I had inclined to those few if lines (anyway there is >>>>> > >>>only small possible >>>>> > >>>workaroound around this "rape 70,40,30,20,0 codes :-/) >>>>> > >>> >>>>> > >>>Happy reading :)) >>>>> > >>> >>>>> > >>> >>>>> > >>>J. >>>>> > >>> >>>>> > >>>Pleas enote, that [rfc][icedtea-web] ignore npe in pac,a nd fixing >>>>> > >>>--Xoffliner are also part of this >>>>> > >>>patch. I will remove them in next rounds/before push (As the fixxes were >>>>> > >>>already approved anyway). >>>>> > >>> >>>>> > >>> >>>>> > >>>After this is in/during reviw, I will work on new panel to >>>>> > >>>itweb-settings, which allows removing of >>>>> > >>>icons and menu entries added by javaws.itweb. >>>>> > >>> >>>>> > >>> >>>>> > >>>General thoughs? >>>>> > >>> >>>>> > >>>J. >>>> > >> >>>> > >>Jsut realized an NPE - in case of ALWAYS_ASK, the information, and >>>> > >>getShortcut may be null... >>>> > >> >>>> > >> >>>> > >>J. >>>> > >> >>> > >just adapted to head.. Hei I like this menu +offline support :)) >> > >> > >> >Fixed few messages - thay will go to properties at the end anyway. Also I >> >have chnaged default icon >> >from java to javaws. My system dont know javaicon, but knows javaws (wellif >> >you run jnlp you have to >> >installe dbooth java, and javaws, but javaws icon is under itw maintainance) >> > >> >Actually - I have this line in fedora specfile: >> > cp javaws.png $RPM_BUILD_ROOT%{_datadir}/pixmaps >> > >> >Shouldnt our make install do so? (afaik yes) > > > Hello, > > > First: Pretty awesome work!!! :D > > > > User-testing on F20 it seems fine, the shorcuts get created and seem to be coded properly. However, not all applets are able to launched through shortcut so it's kind of iffy there.*shrugs* > > When testing:http://jogamp.org/deployment/jogamp-next/jogl-applet-version-napplet.html > > I was able to create a shortcut for it, and it ended up being a shortcut to an html file. However, when I launched it, it was not opened in my default browser, instead it was attempted to be opened in javaws :\ I think this might be a bug. If it opened in firefox, it would've worked perfectly. I think I have explained this in previous emial, but I have now included the main logic to this pathc - if it is htmled-applet what is shortcuted, then it opens in browser. > > > > When testing:http://www.arbores.ca/PresentFuture.jnlp > > I encountered: > > java.io.FileNotFoundException:/home/jkang/.local/share/applications/javaws/Present/Future Value Calculator.desktop (No such file or directory) > at java.io.FileOutputStream.open(Native Method) > at java.io.FileOutputStream.<init>(FileOutputStream.java:221) > at java.io.FileOutputStream.<init>(FileOutputStream.java:171) > at net.sourceforge.jnlp.util.XDesktopEntry.installMenuLauncher(XDesktopEntry.java:247) > at net.sourceforge.jnlp.util.XDesktopEntry.createDesktopShortcuts(XDesktopEntry.java:232) > at net.sourceforge.jnlp.runtime.ApplicationInstance.addMenuAndDesktopEntries(ApplicationInstance.java:179) > at net.sourceforge.jnlp.runtime.ApplicationInstance.initialize(ApplicationInstance.java:144) > at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:531) > at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:912) > > Not entirely sure what happened, but the shortcut didn't get created :( > > I think it is quite obvious :)) the title is blah1/blah2 blah3, so instead of file "blah1/blah2 blah3" it was searching fo file "blah2 blah3" in directory blah1 :)) Good catch, fixed. > > > There are a few nits for the code: > > Biggest one for me is: Please add more logging messages to make it easier to debug later on: e.g. where shortcut is being saved, etc. > done > Smallest one is: There are a few typos, please try to fix them I ahve fixe dwhat I found. Not much actually:(( Feel free to name them. > > > Actual code comments: > > diff -r e57ab037cbd0 netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java > --- a/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java Fri Nov 14 14:06:06 2014 +0100 > +++ b/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java Fri Nov 14 15:16:15 2014 +0100 > [...] > > - private int[] VALID_ICON_SIZES = new int[] { 16, 22, 32, 48, 64, 128 }; > + private final int[] VALID_ICON_SIZES = new int[] { 16, 22, 32, 48, 64, 128 }; > > Please add a comment saying what unit these sizes are (I'm guessing pixels?) added. > > > + public Reader getContentsAsReader(boolean menu) { > > String cacheDir = JNLPRuntime.getConfiguration() > .getProperty(DeploymentConfiguration.KEY_USER_CACHE_DIR); > File cacheFile = CacheUtil.getCacheFile(file.getSourceLocation(), null); > > Both cacheDir and cacheFile are now unused, please remove these two lines. Grate! Thanx for this. Removed. > > > + private static class IconsCreationDescriptor{ > + > [...] > + public boolean isMenu() { > + return menu; > + } > + > + > + > + > > These extra spaces should be removed; done > > > diff -r e57ab037cbd0 netx/net/sourceforge/jnlp/util/XDesktopEntry.java > --- a/netx/net/sourceforge/jnlp/util/XDesktopEntry.java Fri Nov 14 14:06:06 2014 +0100 > +++ b/netx/net/sourceforge/jnlp/util/XDesktopEntry.java Fri Nov 14 15:16:15 2014 +0100 > [...] > + private void cacheIcon() throws IOException { > [...] > + String origLocation = location.substring("file:".length()); > > Spacing here needs to be fixed done. > > > + private static String findAndVerifyJavawsMenuDir() { > + File f = PathsAndFiles.MENUS_DIR.getFile(); > + String ff = f.getAbsolutePath(); > > Please rename String ff to something like 'path' or 'menuDir', something that says what the string is representing; > done > > private static String evaluateLinuxVariables(String orig, Map<String, String> variables) { > Set<Entry<String, String>> env = variables.entrySet(); > - List<Entry<String, String>> envVariables = new ArrayList<Entry<String, String>>(env); > > This could be shortened to: > > - Set<Entry<String, String>> env = variables.entrySet(); > + List<Entry<String, String>> envVariables = new ArrayList<>(variables.entrySet()); > > I don't see 'env' being used anywhere else and I don't think the extra line to be specific is useful. > sure, done. > > diff -r e57ab037cbd0 netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java > --- a/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java Fri Nov 14 14:06:06 2014 +0100 > +++ b/netx/net/sourceforge/jnlp/runtime/ApplicationInstance.java Fri Nov 14 15:16:15 2014 +0100 > @@ -141,11 +141,6 @@ > [...] > + File possibleMenuFile = entry.getLinuxMenuIconFile(); > + //if one of menu or desktop exists, do not bother user > + boolean exists = false; > > If I am reading this right, I think this is a pretty annoying flaw. If a user creates either a menu or desktop shortcut, they can no longer create a shortcut of the other type? That sounds bad to me, can this be reworked? Nope - this is intedet exactly to be like this. Can you imagine, dialog with two options "create 1 or/and 2" you select only one of it, and it will keep you bothering untill you select both of tehm.\ Right nwow I would really like to keep it as it is. Once the itweb-support will be done,. may this will give more sense to you. > > + boolean trullyTrue = (sd != null && (sd.onDesktop() || sd.getMenu() != null)); > > Please find a better name for this boolean. What does it even check for? Actually it appeared it was wrong. See new impl. Lucky catch :) > > > diff -r e57ab037cbd0 netx/net/sourceforge/jnlp/config/PathsAndFiles.java > --- a/netx/net/sourceforge/jnlp/config/PathsAndFiles.java Fri Nov 14 14:06:06 2014 +0100 > +++ b/netx/net/sourceforge/jnlp/config/PathsAndFiles.java Fri Nov 14 15:16:15 2014 +0100 > @@ -53,6 +53,7 @@ > [...] > + private static final String DATA_HOME; > > I am not sure this is the best name. What is DATA? Atm this name is way too generic, and either needs a comment or renaming. I'm afraid it is the best neame - it is exact conversion of XDG_DATA_HOME. And as we do everywhere we fill SOMETHING by value of XDG_SOMETHING or default if XDG_* is null. ok with this explanation? Thank you for review! J. -------------- next part -------------- A non-text attachment was scrubbed... Name: menus_5.patch Type: text/x-patch Size: 46495 bytes Desc: not available URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20141129/ff7766d3/menus_5-0001.patch>