Support persistent-id of blueprint-cm

[GoogleCodeExporter]

I am not sure if this is possible with pojosr.

But given you have a blueprint XML file and use property-placeholder's, and you 
define this in the XML file

  <cm:property-placeholder id="myProperties" persistent-id="foo"/>

Then with Aries Blueprint, then because the pid is foo, then it will load the 
etc/foo.cfg file from the file path that has the .properties.

I wonder if pojosr could support this convention. Then it allows you to keep 
the XML as is, and still use pojosr to test it.

Any thoughts?

PS: Only by changing the XML and for example use default properties
  <cm:property-placeholder id="blue" persistent-id="foo.cfg">
    <cm:default-properties>
      <cm:property name="bar" value="hello2"/>
    </cm:default-properties>
  </cm:property-placeholder>

Then I can properties works. But this is not desireable, as I want to maintain 
the .cfg file and load the properties from that. Just as the real OSGi 
container does.

Original issue reported on code.google.com by claus.ib...@gmail.com on 24 Nov 2012 at 3:47

[GoogleCodeExporter]

I guess I'm not sure what component of the stack is responsible for the 
behavior you describe. I can tell you that it is not the core framework. 
Neither pojosr nor felix will do anything in this area. It must be either 
something aries blueprint is doing or something else in your stack. 

Personally, it sounds to me that what is happening is that there is something 
like fileinstall around that is monitoring the etc directory and if it finds a 
foo.cfg it will go ahead and create a configuration with a pid of foo. 
Respectively, aries blueprint just registers a managed service (factory) for 
that pid when it finds a cm:property-placeholder and hence, gets configured 
with that configuration. But I don't know for sure. 

Should this be the case, then it should work exactly the same with pojosr 
provided you also put fileinstall and a configadmin implementation on the 
classpath as well as configure fileinstall to monitor the etc directory. 

However, if that is not it and there is indeed some magic that pojosr is 
missing to make this work then I'm not against trying to make it work on pojosr 
as well but I would need some pointers as to what is missing exactly or at 
least a working test example I can play around with (atm, I don't have the time 
to figure all that out myself - again, I'm willing to look into but somebody 
else has to do the legwork :-).

Original comment by karlpauls on 26 Nov 2012 at 7:40

[GoogleCodeExporter]

Karl.

Your observations makes sense to me. I am pretty sure this is the case with the 
fileinstall monitoring etc. As well there is another one for monitoring deploy 
for hot-deployment by copying jars to this directory.

When I get some time I will try to see if I can get this working by adding 
fileinstall and configadmin (I got this already) to the classpath, and have it 
monitor the etc directory.

Original comment by claus.ib...@gmail.com on 3 Dec 2012 at 9:39

[GoogleCodeExporter]

ok - cool. just let me know whether it works out or not so that i can close the 
issue or try to make it work, respectively :-)

Original comment by karlpauls on 3 Dec 2012 at 11:19

[GoogleCodeExporter]

Unfortunately I haven't yet hat free cycles to look into this. Have not 
forgotten about this ticket.

Original comment by claus.ib...@gmail.com on 9 Jan 2013 at 9:08