On Sat, Sep 17, 2016 at 1:27 PM, David Jencks <[email protected]> wrote: > >> On Sep 17, 2016, at 10:16 AM, Benson Margulies <[email protected]> wrote: >> >> David, the only case I was concerned with is when there is a >> pre-existing file with the syntax of my test case, which is the syntax >> supported by fileinstall. I think that the confusion results because >> there is some escaping convention that permits persisting a value like >> ${foo} and reading it back, but I was not using that syntax, because I >> was trying to move some files that were used with fileinstall in karaf >> and use them with straight CA with plain Felix. > > I can’t imagine why you think that ought to work. The persistence format for > a ca implementation is an entirely internal detail. If you want a ca > implementation to be able to read a persisted configuration from a file, that > file has to have been created by that same ca implementation.
Well, for what it's worth, I can explain how my imagination got started here. I didn't know, at first, that Karaf was using fileinstall to read these files. I thought that CA itself was reading them from the sort of obvious 'name=value' format. When I did enough debugging to find the role of fileinstall in Karaf, I didn't rethink CA. > >> In practical terms, >> I've dropped in fileinstall to make progress. >> >> I think that my JIRA amounts to, "If you start with a file with >> invalid syntax, CA throws the entire file away and does not log an >> error”. > > Unless the file was created by the ca implementation itself, throwing it away > seems reasonable to me. It does seem like an error would be appropriate > though. > > So, there might be a bug (beyond possible desirable logging), but I don’t > think you’ve demonstrated that yet. I don't make any claim for any bug except a possible 'feature request' for logging at this point. > > thanks > david jencks > >> >> The test class I sent along is pretty much useless except as the >> nucleus of a test that would demand error logging from the overall CA; >> the low level file persistence manager is working correctly, I realize >> now, in rejecting that syntax. >> >> I will try to make the time to add the relevant test case (and >> probably the fix to log the error) later in the weekend. >> >> >> >> On Sat, Sep 17, 2016 at 1:05 PM, David Jencks >> <[email protected]> wrote: >>> Along with Carsten, I’m confused by your jira report. What happens when >>> you create a configuration in code and try to update it with your property? >>> Can you get it back? There might be a problem with persisting such a >>> property, but your test doesn’t demonstrate it because perhaps the >>> persistence is encoding the value somehow. >>> >>> thanks >>> david jencks >>> >>>> On Sep 17, 2016, at 9:59 AM, Benson Margulies <[email protected]> wrote: >>>> >>>> I could commit this test, which fails, if you like, with an @Ignore. >>>> >>>> >>>> public class InvalidFileSyntaxTest { >>>> private static final String CONFIG = "rootPath=${bt.root}\n"; >>>> >>>> @Test >>>> public void testPropSyntax() throws IOException >>>> { >>>> final Dictionary dict = ConfigurationHandler.read(new >>>> ByteArrayInputStream(CONFIG.getBytes("UTF-8"))); >>>> assertEquals(1, dict.size()); >>>> assertEquals("${bt.root}", dict.get("rootPath")); >>>> } >>>> } >>>> >>>> On Sat, Sep 17, 2016 at 12:49 PM, Benson Margulies <[email protected]> >>>> wrote: >>>>> On Sat, Sep 17, 2016 at 12:45 PM, David Jencks >>>>> <[email protected]> wrote: >>>>>> >>>>>>> On Sep 17, 2016, at 9:40 AM, Benson Margulies <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> On Sat, Sep 17, 2016 at 3:21 AM, Carsten Ziegeler <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>> I don’t think this belongs in ca. You could use a >>>>>>>>> ConfigurationPlugin. Unfortunately you’ll have to wait till R7 until >>>>>>>>> this works with DS. Maybe Carsten already implemented the CA part, >>>>>>>>> but I didn’t do the DS part yet. >>>>>>> >>>>>>> Interesting. When I tried to use such a file with CA, the low-level >>>>>>> parser rejected the ${xxxxx} syntax long before a plugin would get a >>>>>>> chance to modify the dictionary contents, or so I thought. >>>>>> >>>>>> I’ve been assuming you only want to put the ${xxx} in values, where I’d >>>>>> expect it to be a fine persistable value…. you weren’t using it as a key >>>>>> were you (where it won’t work AFAIK)? >>>>> >>>>> Nope, just as a value (${bt.foo.bar}). I opened a JIRA about the fact >>>>> that CA discarded the entire file without even a log message. I >>>>> assumed that it had to do with the syntax for arrays and such that the >>>>> parser supports. >>>>> >>>>> >>>>>> >>>>>> david jencks >>>>>> >>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> I've implemented both parts, the CA part is in trunk, the DS part is in >>>>>>>> the sandbox branch, but I plan to move it to trunk soon. >>>>>>>> >>>>>>>> Carsten >>>>>>>> >>>>>>>>> Alternatively you can code it into whatever management agent you are >>>>>>>>> using instead of fileinstall. >>>>>>>>> >>>>>>>>> Maybe others have other opinions…. >>>>>>>>> >>>>>>>>> david jencks >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Sep 16, 2016, at 5:47 PM, Benson Margulies <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> The system property expansion feature of the configuration-admin >>>>>>>>>> behavior of fileinstall is quite convenient. I could code it, >>>>>>>>>> optionally, into confadmin. I wish I could have it without all the >>>>>>>>>> other mechanism of fileinstall that I don't need. Acceptable? >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Carsten Ziegeler >>>>>>>> Adobe Research Switzerland >>>>>>>> [email protected] >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> <mailto:[email protected]> >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> <mailto:[email protected]> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
