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 <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. 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
> <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

Reply via email to