I'm wanting to automate some setup of a karaf based product. I want to create a 
docker image that is pre-configured for internal testing.

In order to do this I need to run some karaf shell commands.
What I was naively hoping to do is do something like:

/opt/karaf/bin/start && /opt/karaf/bin/client -u admin -p admin -f commands.txt 
&& /opt/karaf/bin/stop

or perhaps:

/opt/karaf/bin/karaf < commands.txt

However my problem is that the shell comes up before the commands I need are 
available to run. 

Any suggestions on how to deal with this?
- I can't find any documentation on shell variables that might give me a return 
code I could check and loop on with a sleep. This would probably work, but 
feels crude.
- A "does this command exist" command might be useful if I can then loop on its 
result. I can probably create such a command and put it in a bundle that I 
specify with a low start order to ensure it's available.
- Crudely sleeping for a long period of time would work (most of the time) but 
is inefficient. 
Fiddle with the start level of the shell bundle so that it comes up last (I'm 
not even totally sure that would work -- since component activation happens 
asynchronously I suspect that things from earlier bundles are still happening 
while later bundles are then being started).

Or is what I'm trying to do just not very sensible? Even if I created REST API 
endpoints do to it I'd have essentially the same issue, I could just write the 
logic in an external program of some kind, java, shell, whatever (repeatedly 
"ping" an endpoint until it doesn't return 404, then I know the endpoints are 
available). I'm guessing JMX would have essentially the same problem, in that I 
would have to start karaf then loop until the JMX beans become available.

Note that I found what appears to be some old karaf documentation 
(https://svn.apache.org/repos/asf/karaf/site/production/manual/latest-3.0.x/scripting.html)
 that includes a script for waiting for a command to become available. Perfect! 
However that a) doesn't work and b) would appear be based on standard OSGI gogo 
shell commands by the looks of it, rather than karaf shell commands, which 
aren't registered as services. 

Thanks.

Reply via email to