On Sat, Sep 17, 2016 at 1:27 PM, David Jencks
<david_jen...@yahoo.com.invalid> wrote:
>
>> 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.

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Reply via email to