p.s. It's always possible that I'm _wrong_, and CA is logging, but I didn't have the log service set up soon enough. That's another reason for me to be the one to spend time trying to make a test case.
On Sat, Sep 17, 2016 at 1:16 PM, 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. 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". > > 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]
