[rfc][icedtea-web] Preparing PolicyEditor for future full policyfile featureset
Jiri Vanek
jvanek at redhat.com
Fri Nov 7 14:12:16 UTC 2014
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.
More information about the distro-pkg-dev
mailing list