[PATCH] 0036 Use SimpleProperties to handle raw profile format
This patch fixes an issue when handling the "raw" (property-list) profile format.
On 5/19/2015 8:20 AM, Fraser Tweedale wrote:
This patch fixes an issue when handling the "raw" (property-list) profile format.
There seems to be a dependency issue. The SimpleProperties belongs to the server package, and the pki CLI belongs to the tools package which may exist on a client machine without the server packages. Does build work? I think there are two ways to resolve this: 1. Move SimpleProperties into the common package (e.g. com.netscape.certsrv.base) and undo the new dependencies added for cmscore. 2. We keep two profile formats: * SimpleProperties for profile configs stored in instance folder * Properties for profile configs accessed via REST The profile configs stored in LDAP can use either format. The REST service/profile subsystem will act as a translator between the two formats. With option #2 a problem with might happen if we retrieve a profile config via REST then store it directly in the instance folder or in LDAP, or vice versa. If we stick to one mechanism we wouldn't see a problem. Considering we're going to remove the profile configs in the instance folder eventually (and possibly changing the LDAP format to be platform agnostic) there would be less risk of intermixing the two formats. But if it's still considered a risk anyway then we should go with option #1. -- Endi S. Dewata
On Tue, May 19, 2015 at 10:42:28AM -0500, Endi Sukma Dewata wrote:
On 5/19/2015 8:20 AM, Fraser Tweedale wrote:
This patch fixes an issue when handling the "raw" (property-list) profile format.
There seems to be a dependency issue. The SimpleProperties belongs to the server package, and the pki CLI belongs to the tools package which may exist on a client machine without the server packages. Does build work?
I think there are two ways to resolve this:
1. Move SimpleProperties into the common package (e.g. com.netscape.certsrv.base) and undo the new dependencies added for cmscore.
2. We keep two profile formats: * SimpleProperties for profile configs stored in instance folder * Properties for profile configs accessed via REST The profile configs stored in LDAP can use either format. The REST service/profile subsystem will act as a translator between the two formats.
With option #2 a problem with might happen if we retrieve a profile config via REST then store it directly in the instance folder or in LDAP, or vice versa. If we stick to one mechanism we wouldn't see a problem.
Considering we're going to remove the profile configs in the instance folder eventually (and possibly changing the LDAP format to be platform agnostic) there would be less risk of intermixing the two formats. But if it's still considered a risk anyway then we should go with option #1.
-- Endi S. Dewata
Thanks Endi for the review. Updated patch attached - with it I took a different approach: in ProfileService first read the file with Properties then copy the data into a SimpleProperties for writing out to storage. Thus no changes to client needed. Cheers, Fraser
On 5/21/2015 9:37 AM, Fraser Tweedale wrote:
On Tue, May 19, 2015 at 10:42:28AM -0500, Endi Sukma Dewata wrote:
2. We keep two profile formats: * SimpleProperties for profile configs stored in instance folder * Properties for profile configs accessed via REST The profile configs stored in LDAP can use either format. The REST service/profile subsystem will act as a translator between the two formats.
Thanks Endi for the review. Updated patch attached - with it I took a different approach: in ProfileService first read the file with Properties then copy the data into a SimpleProperties for writing out to storage. Thus no changes to client needed.
Cheers, Fraser
Yes, that's what I meant by option #2. I think you need to do the reverse in retrieveProfileRaw(). Everything else is good, ACK. -- Endi S. Dewata
On Thu, May 21, 2015 at 07:34:29PM -0500, Endi Sukma Dewata wrote:
On 5/21/2015 9:37 AM, Fraser Tweedale wrote:
On Tue, May 19, 2015 at 10:42:28AM -0500, Endi Sukma Dewata wrote:
2. We keep two profile formats: * SimpleProperties for profile configs stored in instance folder * Properties for profile configs accessed via REST The profile configs stored in LDAP can use either format. The REST service/profile subsystem will act as a translator between the two formats.
Thanks Endi for the review. Updated patch attached - with it I took a different approach: in ProfileService first read the file with Properties then copy the data into a SimpleProperties for writing out to storage. Thus no changes to client needed.
Cheers, Fraser
Yes, that's what I meant by option #2. I think you need to do the reverse in retrieveProfileRaw(). Everything else is good, ACK.
Thanks for the review Endi; I think retrieveProfileRaw is fine; Properties has no problem reading the unescaped version. Cheers, Fraser
-- Endi S. Dewata
On Fri, May 22, 2015 at 08:28:01PM +1000, Fraser Tweedale wrote:
On Thu, May 21, 2015 at 07:34:29PM -0500, Endi Sukma Dewata wrote:
On 5/21/2015 9:37 AM, Fraser Tweedale wrote:
On Tue, May 19, 2015 at 10:42:28AM -0500, Endi Sukma Dewata wrote:
2. We keep two profile formats: * SimpleProperties for profile configs stored in instance folder * Properties for profile configs accessed via REST The profile configs stored in LDAP can use either format. The REST service/profile subsystem will act as a translator between the two formats.
Thanks Endi for the review. Updated patch attached - with it I took a different approach: in ProfileService first read the file with Properties then copy the data into a SimpleProperties for writing out to storage. Thus no changes to client needed.
Cheers, Fraser
Yes, that's what I meant by option #2. I think you need to do the reverse in retrieveProfileRaw(). Everything else is good, ACK.
Thanks for the review Endi; I think retrieveProfileRaw is fine; Properties has no problem reading the unescaped version.
Cheers, Fraser
Pushed to master (dc6f5768e815f6a8bf4cb971f1603a84945699cc).
-- Endi S. Dewata
_______________________________________________ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
participants (2)
-
Endi Sukma Dewata -
Fraser Tweedale