Re: JNI, classloaders, framework shutdown

[Benson Margulies]

On Sat, Sep 17, 2016 at 7:39 PM, David Jencks
 wrote:
> Ah, I didn’t read your first post closely enough….. IIUC your code is loading 
> the native library, you are not using OSGI native code support?
>
> Can you modify things to use OSGI native code support?

To do that, I'd need to make about the same set of arrangements. The
code has to remain deliverable as a non-OSGi SDK. One way or the
other, I'd have to change the plumbing that calls System.load.

>
> david jencks
>
>> On Sep 17, 2016, at 4:16 PM, Benson Margulies  wrote:
>>
>> On Sat, Sep 17, 2016 at 7:05 PM, David Jencks
>> > 
>> wrote:
>>> I have no idea what I’m talking about, but I had the vague idea that osgi 
>>> frameworks get around this by copying the native library to a new, unique, 
>>> location each time the bundle[revision] starts. The link into your local 
>>> maven repo doesn’t seem like it’s native code that’s actually in a bundle.  
>>> Do you have any idea how this path relates to your bundle containing the 
>>> native code?
>>
>> That makes a great deal of sense. In our case, the native code is not
>> in Maven at all; it's sitting in an outboard product installation
>> directory along with 100 tons of NLP models and dictionaries.
>>
>> However, I'm trying to build something that someone else embeds into
>> an arbitrary Java application (and I launch the OSGi framework for
>> them). So, getting the temporary directory into java.library.path is
>> not going to be straightforward. Options I see include simply changing
>> the filename but using the same directory, or changing the Java code
>> to know how to call System.load (which takes a pathname) instead of
>> System.loadLibrary (which looks in java.library.path).
>>
>>>
>>> david jencks
>>>
 On Sep 17, 2016, at 3:57 PM, Benson Margulies  wrote:

 Has anyone out there succeeded shutting down the Felix container and
 having the classloaders GC to the point where native classes are no
 longer loaded, so that the same JVM can then start a new framework and
 again load the same native classes?

 To be a bit more precise, I have a bundle that includes some native
 classes. I start the framework, load and start this bundle, and it
 does the System.loadLibrary to load up these classes.

 I shut down the framework, and try again, and get:

 18:51:39.140 [Thread-4] ERROR r.1.4.0.201609171300 -
 [com.basistech.ws.worker.core.Worker(8)] The activate method has
 thrown an exception
 java.lang.UnsatisfiedLinkError: Native Library
 /Users/benson/.m2/repository/bt/rosapi/roots/native/7.14.100.0/rlp/lib/amd64-darwin11-xcode4/libbtnamesutiljni.dylib
 already loaded in another classloader

 My vague sense is that it's somewhere between difficult and impossible
 to get native code cleaned up enough to make this work, but I wondered
 if anyone else had succeeded using Felix.

 -
 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: JNI, classloaders, framework shutdown

[David Jencks]

Ah, I didn’t read your first post closely enough….. IIUC your code is loading 
the native library, you are not using OSGI native code support?

Can you modify things to use OSGI native code support?

david jencks

> On Sep 17, 2016, at 4:16 PM, Benson Margulies  wrote:
> 
> On Sat, Sep 17, 2016 at 7:05 PM, David Jencks
> > 
> wrote:
>> I have no idea what I’m talking about, but I had the vague idea that osgi 
>> frameworks get around this by copying the native library to a new, unique, 
>> location each time the bundle[revision] starts. The link into your local 
>> maven repo doesn’t seem like it’s native code that’s actually in a bundle.  
>> Do you have any idea how this path relates to your bundle containing the 
>> native code?
> 
> That makes a great deal of sense. In our case, the native code is not
> in Maven at all; it's sitting in an outboard product installation
> directory along with 100 tons of NLP models and dictionaries.
> 
> However, I'm trying to build something that someone else embeds into
> an arbitrary Java application (and I launch the OSGi framework for
> them). So, getting the temporary directory into java.library.path is
> not going to be straightforward. Options I see include simply changing
> the filename but using the same directory, or changing the Java code
> to know how to call System.load (which takes a pathname) instead of
> System.loadLibrary (which looks in java.library.path).
> 
>> 
>> david jencks
>> 
>>> On Sep 17, 2016, at 3:57 PM, Benson Margulies  wrote:
>>> 
>>> Has anyone out there succeeded shutting down the Felix container and
>>> having the classloaders GC to the point where native classes are no
>>> longer loaded, so that the same JVM can then start a new framework and
>>> again load the same native classes?
>>> 
>>> To be a bit more precise, I have a bundle that includes some native
>>> classes. I start the framework, load and start this bundle, and it
>>> does the System.loadLibrary to load up these classes.
>>> 
>>> I shut down the framework, and try again, and get:
>>> 
>>> 18:51:39.140 [Thread-4] ERROR r.1.4.0.201609171300 -
>>> [com.basistech.ws.worker.core.Worker(8)] The activate method has
>>> thrown an exception
>>> java.lang.UnsatisfiedLinkError: Native Library
>>> /Users/benson/.m2/repository/bt/rosapi/roots/native/7.14.100.0/rlp/lib/amd64-darwin11-xcode4/libbtnamesutiljni.dylib
>>> already loaded in another classloader
>>> 
>>> My vague sense is that it's somewhere between difficult and impossible
>>> to get native code cleaned up enough to make this work, but I wondered
>>> if anyone else had succeeded using Felix.
>>> 
>>> -
>>> 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 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