Hi everybody I'm sorry, this has really been much ado about something very small :(
My mistake was a typo. I oversaw a small dash right in front of the heredoc marker in the script: java -verbose -jar bin/felix.jar - <<-END_GOGO_SCRIPT_STARTUP Thanks to Richard and Karl for bringing up the felix-cache, the weird naming there pointed me in the right direction. Best regards, Sam Am 19.10.11 18:36, schrieb Richard S. Hall: > On 10/19/11 12:09 , Sam Spycher wrote: >> Hmm, that is interesting. >> >> When I deploy felix via script, I can observe the creation of a >> directory called '-' in the working directory while the script is >> executing. >> >> Looking at the contents of '-', I find bundleX subdirectories just as is >> to be expected from the felix cache. Indeed if i cat the bundle.info >> of the bundle with the highest number I can see this corresponds to a >> bundle that I installed with gogo. >> >> However, when I run Felix interactively from the shell after having run >> the script, it creates a new cache directory with the proper default >> name 'felix-cache'. Of course this directory now contains no traces of >> what was installed with gogo, it only has the bundles which were copied >> into the bundle/ subdirectory. >> >> -> Some issue with the cache directory name when running felix >> non-interactively? >> >> Note that I'm running 4.0.1 directly off maven, with no modifications to >> config.properties. > > Not sure if the way you are launching it somehow overrides the default > cache value or not, but if you want to see what is going on, perhaps you > can try to debug it and set a break point at: > > org.apache.felix.framework.cache.BundleCache.determineCacheDir() > > This calculates the cache directory based on the default config and/or > any specified configuration. > > -> richard > >> >> Thanks& Best regards, >> Sam >> >> Am 19.10.11 17:44, schrieb Richard S. Hall: >>> On 10/19/11 11:39 , Sam Spycher wrote: >>>> Hi Richard, >>>> >>>> I am running a bash script which sends some gogo deployment commands to >>>> install some bundles in felix. I then list the bundles I just deployed >>>> with gogo with the command 'lb'. These bundles are all correctly >>>> displayed and have their state set to active. At the end of the script >>>> Felix then terminates (I assume because it is called non-interactively >>>> via a script). >>>> >>>> Now if I startup this exact same deployment and list the installed >>>> bundles via 'lb', all I get is the bundles I previously copied into the >>>> bunde/ subdirectory. The bundles I installed via gogo have disappeared, >>>> although I never undeployed them. >>>> >>>> What am I missing? >>> Well, the framework installs bundles into a cache, which is by default >>> in the current directory called felix-cache. Do you see this directory >>> get created? Is it still there after shutdown? What happens to it after >>> startup? >>> >>> -> richard >>> >>>> >>>> Here is a minimal version of my deployment script: >>>> >>>> #!/bin/bash >>>> java -verbose -jar bin/felix.jar<<-END_GOGO_SCRIPT_STARTUP >>>> obr:repos add file:$HOME/.m2/repository/repository.xml >>>> obr:deploy -s "Some bundle from maven repo" >>>> felix:refresh >>>> felix:lb >>>> END_GOGO_SCRIPT_STARTUP >>>> >>>> Best regards, >>>> Sam >>>> >>>> Am 19.10.11 17:23, schrieb Richard S. Hall: >>>>> On 10/19/11 03:24 , Sam Spycher wrote: >>>>>> Hi >>>>>> >>>>>> I am currently writing a small shell script which is supposed to run >>>>>> felix, install the necessary bundles with gogo, then quit and package >>>>>> felix for deployment on our integration servers. >>>>>> >>>>>> Unfortunately, felix seems to undeploy the deployed bundles when >>>>>> shutting down. If I do this manually, felix retains the bundles >>>>>> across >>>>>> shutdowns and startups. >>>>> I'm not sure what you mean, nor what you are doing exactly, but the >>>>> Felix framework always retains bundles across shutdowns and restarts. >>>>> The framework will never undeploy a bundle unless someone tells it >>>>> to do >>>>> so. >>>>> >>>>> -> richard >>>>> >>>>>> The only difference I can find is on how I exit Felix. From the >>>>>> script, >>>>>> felix exits "normally", and when configuring interactively I exit >>>>>> with >>>>>> Ctrl-C. >>>>>> >>>>>> -> so my question is: how can I persuade Felix to keep the >>>>>> installed >>>>>> bundles (and keep their active state) across shutdowns and startups? >>>>>> >>>>>> -> would the proper way to do this be over config.properties? >>>>>> >>>>>> -> if yes, and if this means that deployment of bundles happens on >>>>>> every >>>>>> startup, then how do I work around the issue of potentially not >>>>>> having >>>>>> access to a repo on the server that felix is to be installed? >>>>>> >>>>>> >>>>>> Here is the part of the script which uses gogo: >>>>>> >>>>>> #!/bin/bash >>>>>> # ... >>>>>> # GOGO deployment script >>>>>> cat> $GOGO_SCRIPT<<-END_GOGO_SCRIPT >>>>>> obr:repos add file:$HOME/.m2/repository/repository.xml >>>>>> obr:deploy -s "Bundle A" >>>>>> obr:deploy -s "Bundle B" >>>>>> obr:deploy -s "Bundle C" >>>>>> # etc. >>>>>> felix:refresh >>>>>> felix:lb >>>>>> END_GOGO_SCRIPT >>>>>> # ... >>>>>> # run felix and GOGO script >>>>>> java -verbose -jar bin/felix.jar -<<-END_GOGO_SCRIPT_STARTUP >>>>>> gosh --nointeractive --login -x $GOGO_SCRIPT >>>>>> END_GOGO_SCRIPT_STARTUP >>>>>> >>>>>> >>>>>> Thanks for any help, >>>>>> Sam >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
