> On Sep 17, 2016, at 10:16 AM, Benson Margulies <ben...@basistech.com> 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.
> 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.
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
> <david_jen...@yahoo.com.invalid> 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 <ben...@basistech.com> 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 <ben...@basistech.com>
>>> wrote:
>>>> On Sat, Sep 17, 2016 at 12:45 PM, David Jencks
>>>> <david_jen...@yahoo.com.invalid> wrote:
>>>>>
>>>>>> On Sep 17, 2016, at 9:40 AM, Benson Margulies <ben...@basistech.com>
>>>>>> wrote:
>>>>>>
>>>>>> On Sat, Sep 17, 2016 at 3:21 AM, Carsten Ziegeler <cziege...@apache.org
>>>>>> <mailto:cziege...@apache.org>> 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 <ben...@basistech.com>
>>>>>>>>> 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: users-unsubscr...@felix.apache.org
>>>>>>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>>>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Carsten Ziegeler
>>>>>>> Adobe Research Switzerland
>>>>>>> cziege...@apache.org
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>>>>> <mailto:users-unsubscr...@felix.apache.org>
>>>>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>>>> <mailto:users-h...@felix.apache.org>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>>> For additional commands, e-mail: users-h...@felix.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
>> For additional commands, e-mail: users-h...@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
