On 10/19/11 13:38 , Sam Spycher wrote:
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
Makes sense, you renamed the cache on the command line. :-)
-> richard
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: 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
---------------------------------------------------------------------
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
