[rfc][icedtea-web] Preparing PolicyEditor for future full policyfile featureset

[Jiri Vanek]

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.