Re: Prop expansion via fileinstall but not configuration admin

[Benson Margulies]

On Sat, Sep 17, 2016 at 1:27 PM, David Jencks
 wrote:
>
>> On Sep 17, 2016, at 10:16 AM, Benson Margulies  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
>>  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  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  
 wrote:
> On Sat, Sep 17, 2016 at 12:45 PM, David Jencks
>  wrote:
>>
>>> On Sep 17, 2016, at 9:40 AM, Benson Margulies  
>>> wrote:
>>>
>>> On Sat, Sep 17, 2016 at 3:21 AM, Carsten Ziegeler >> > 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 ${x} 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 

Re: Prop expansion via fileinstall but not configuration admin

[Benson Margulies]

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  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
>  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  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  
>>> wrote:
 On Sat, Sep 17, 2016 at 12:45 PM, David Jencks
  wrote:
>
>> On Sep 17, 2016, at 9:40 AM, Benson Margulies  
>> wrote:
>>
>> On Sat, Sep 17, 2016 at 3:21 AM, Carsten Ziegeler > > 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 ${x} 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  
> 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
>


 -
 

Re: Prop expansion via fileinstall but not configuration admin

[David Jencks]

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  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  
> wrote:
>> On Sat, Sep 17, 2016 at 12:45 PM, David Jencks
>>  wrote:
>>> 
 On Sep 17, 2016, at 9:40 AM, Benson Margulies  wrote:
 
 On Sat, Sep 17, 2016 at 3:21 AM, Carsten Ziegeler > 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 ${x} 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  
>>> 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 
 
 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

Re: Prop expansion via fileinstall but not configuration admin

[Benson Margulies]

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  wrote:
> On Sat, Sep 17, 2016 at 12:45 PM, David Jencks
>  wrote:
>>
>>> On Sep 17, 2016, at 9:40 AM, Benson Margulies  wrote:
>>>
>>> On Sat, Sep 17, 2016 at 3:21 AM, Carsten Ziegeler >> > 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 ${x} 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  
>> 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 
>>> 
>>> 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

Re: Prop expansion via fileinstall but not configuration admin

[Benson Margulies]

On Sat, Sep 17, 2016 at 12:45 PM, David Jencks
 wrote:
>
>> On Sep 17, 2016, at 9:40 AM, Benson Margulies  wrote:
>>
>> On Sat, Sep 17, 2016 at 3:21 AM, Carsten Ziegeler > > 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 ${x} 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  
> 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 
>> 
>> 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

Re: Prop expansion via fileinstall but not configuration admin

[David Jencks]

> On Sep 17, 2016, at 9:40 AM, Benson Margulies  wrote:
> 
> On Sat, Sep 17, 2016 at 3:21 AM, Carsten Ziegeler  > 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 ${x} 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)?

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  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 
> 
> For additional commands, e-mail: users-h...@felix.apache.org 
> 

Re: Prop expansion via fileinstall but not configuration admin

[Benson Margulies]

On Sat, Sep 17, 2016 at 3:21 AM, Carsten Ziegeler  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 ${x} syntax long before a plugin would get a
chance to modify the dictionary contents, or so I thought.

>>
>
> 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  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
For additional commands, e-mail: users-h...@felix.apache.org

Re: Prop expansion via fileinstall but not configuration admin

[Carsten Ziegeler]

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

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

Re: Prop expansion via fileinstall but not configuration admin

[David Jencks]

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.

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

Prop expansion via fileinstall but not configuration admin

[Benson Margulies]

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