Re: Using Spring with Karaf 3.x
I come from a Spring-centric background and found Blueprint to be similar enough from a dependency-injection standpoint that I was able to get up and running extremely quickly. Additionally, its support for services is quite nifty and does a great job of abstracting (or "softening") some of the service dynamism that can sometimes be problematic (especially for new developers). While there are several good options, as others have noted, you really can't go wrong with Blueprint. -Steve On Thu, Dec 4, 2014 at 5:29 PM, asookazian2 wrote: > We have some legacy J2EE apps that we've ported (finally) to Karaf 3.0.x > which use Spring. Mainly for dependency injection and possibly some > templates (e.g. JdbcTemplate, etc.) and AOP. > > Anyways, looks like there are no Spring (or Spring dm?) examples here: > https://github.com/cschneider/Karaf-Tutorial and there are no Spring > examples in the Apache Karaf Cookbook. > > Is Spring usage with OSGi/Karaf recommended or not? If yes, where can I > find some examples? > > "I stopped using spring on OSGi a long time ago." > > http://stackoverflow.com/questions/24595900/invalid-bundle-when-starting-apache-karaf > > > > -- > View this message in context: > http://karaf.922171.n3.nabble.com/Using-Spring-with-Karaf-3-x-tp4036977.html > Sent from the Karaf - User mailing list archive at Nabble.com.
Re: Recommended OSGi dependency version for use with Karaf 2.3.0
JB, No worries; I actually use them both interchangeably. That being said, I wouldn't have been offended anyway :-) Best regards, Steve On Thu, Dec 11, 2014 at 10:13 AM, Jean-Baptiste Onofré wrote: > You're welcome. > > And by the way, sorry about my mistake on your name (Steve instead of > Steven). > > Regards > JB > > > On 12/11/2014 04:11 PM, Steve wrote: >> >> JB, >> >> I very much appreciate you taking the time to respond to my inquiry. >> The link you provided was most helpful and clarified the specification >> version support without ambiguity; I'll proceed with using 4.3.0 >> without reservations. >> >> >> Many thanks, >> >> Steven >> >> On Thu, Dec 11, 2014 at 10:02 AM, Jean-Baptiste Onofré >> wrote: >>> >>> Hi Steve, >>> >>> the release schedule page contains the OSGi version support for each >>> major >>> branches: >>> >>> http://karaf.apache.org/index/community/releases-schedule.html >>> >>> So, for Karaf 2.3.x, OSGi version is 4.3 (compatible with 4.2), and Java >>> 7. >>> >>> Regards >>> JB >>> >>> >>> On 12/11/2014 03:52 PM, Steve wrote: >>>> >>>> >>>> Karaf developers, >>>> >>>> I’m currently working on a management-agent for JBoss Fuse 6.0 (which >>>> leverages Karaf 2.3.0.redhat-60024). Up until this point I’ve been >>>> leveraging version 4.2.0 of the org.osgi/org.osgi.core artifact which >>>> has worked without issue but lacks support for generics. My usage of >>>> version 4.2.0 of the aforementioned artifact was based on the fact >>>> that Felix 3.x was certified as R4.2 compliant. Yesterday I happened >>>> to be looking at the Karaf dependencies matrix and noticed that the >>>> “osgi” dependency for Karaf 2.3.0 was actually at 4.3.0 (something I >>>> had been previously unaware of). I contacted RedHat commercial >>>> support for a clarification and they stated that while the version of >>>> Felix used by Karaf 2.3.0 had passed the R4.3 compliance tests, it had >>>> yet to be certified. This makes sense as I can imagine becoming >>>> certified by the OSGi alliance is non-trivial and may be an effort >>>> only done once per major specification release. >>>> >>>> That being said, I was hoping to get Karaf developers to weigh in >>>> regarding their opinion in regards to which version of the >>>> org.osgi/org.osgi.core artifact is recommended for use within Karaf >>>> 2.3.0; version 4.2.0 or 4.3.0? >>>> >>>> >>>> Thanks, >>>> >>>> Steven >>>> >>> >>> -- >>> Jean-Baptiste Onofré >>> jbono...@apache.org >>> http://blog.nanthrax.net >>> Talend - http://www.talend.com > > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com
Re: Recommended OSGi dependency version for use with Karaf 2.3.0
JB, I very much appreciate you taking the time to respond to my inquiry. The link you provided was most helpful and clarified the specification version support without ambiguity; I'll proceed with using 4.3.0 without reservations. Many thanks, Steven On Thu, Dec 11, 2014 at 10:02 AM, Jean-Baptiste Onofré wrote: > Hi Steve, > > the release schedule page contains the OSGi version support for each major > branches: > > http://karaf.apache.org/index/community/releases-schedule.html > > So, for Karaf 2.3.x, OSGi version is 4.3 (compatible with 4.2), and Java 7. > > Regards > JB > > > On 12/11/2014 03:52 PM, Steve wrote: >> >> Karaf developers, >> >> I’m currently working on a management-agent for JBoss Fuse 6.0 (which >> leverages Karaf 2.3.0.redhat-60024). Up until this point I’ve been >> leveraging version 4.2.0 of the org.osgi/org.osgi.core artifact which >> has worked without issue but lacks support for generics. My usage of >> version 4.2.0 of the aforementioned artifact was based on the fact >> that Felix 3.x was certified as R4.2 compliant. Yesterday I happened >> to be looking at the Karaf dependencies matrix and noticed that the >> “osgi” dependency for Karaf 2.3.0 was actually at 4.3.0 (something I >> had been previously unaware of). I contacted RedHat commercial >> support for a clarification and they stated that while the version of >> Felix used by Karaf 2.3.0 had passed the R4.3 compliance tests, it had >> yet to be certified. This makes sense as I can imagine becoming >> certified by the OSGi alliance is non-trivial and may be an effort >> only done once per major specification release. >> >> That being said, I was hoping to get Karaf developers to weigh in >> regarding their opinion in regards to which version of the >> org.osgi/org.osgi.core artifact is recommended for use within Karaf >> 2.3.0; version 4.2.0 or 4.3.0? >> >> >> Thanks, >> >> Steven >> > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com
Recommended OSGi dependency version for use with Karaf 2.3.0
Karaf developers, I’m currently working on a management-agent for JBoss Fuse 6.0 (which leverages Karaf 2.3.0.redhat-60024). Up until this point I’ve been leveraging version 4.2.0 of the org.osgi/org.osgi.core artifact which has worked without issue but lacks support for generics. My usage of version 4.2.0 of the aforementioned artifact was based on the fact that Felix 3.x was certified as R4.2 compliant. Yesterday I happened to be looking at the Karaf dependencies matrix and noticed that the “osgi” dependency for Karaf 2.3.0 was actually at 4.3.0 (something I had been previously unaware of). I contacted RedHat commercial support for a clarification and they stated that while the version of Felix used by Karaf 2.3.0 had passed the R4.3 compliance tests, it had yet to be certified. This makes sense as I can imagine becoming certified by the OSGi alliance is non-trivial and may be an effort only done once per major specification release. That being said, I was hoping to get Karaf developers to weigh in regarding their opinion in regards to which version of the org.osgi/org.osgi.core artifact is recommended for use within Karaf 2.3.0; version 4.2.0 or 4.3.0? Thanks, Steven
Re: Spring vs Blueprint
Richard, If you're merely wanting to use Karaf as a container to run an application without really being "container aware" than Spring DM is a viable choice due to its familiarity for most developers. I've seen this used successfully for many Camel based applications that didn't explicitly use any container-provided services but merely needed basic life-cycle management. That being said, if you want to leverage services or interact with the underlying container than I strongly recommend sticking with Blueprint. It does a nice job of hiding the dynamism of container-provided services (via proxies) and allows one to wire them using dependency injection. It is this "softening" of the underlying service dynamism that makes Blueprint a great asset, especially for new developers. Additionally, it's worth noting that Blueprint is comparable to Spring's dependency injection, not the entire Spring ecosystem which encompasses far more than DI. This may seem like a silly point to make, but I have known people to get confused. Best Regards, Steve On Thu, Sep 18, 2014 at 5:04 PM, wrote: > I have used JPA with DS. It was OK so long as you didn't try to do > anything too fancy - in my case it went adrift when I tried to embed an > enum which was declared in another bundle, spent some time trying to debug > this one but ran into a morass of proxy class loaders holding references > to lists of BundleClassLoaders. To preserve my sanity, I changed my > design. > > Good luck, Chris > >> Richard, these links don't explain the differences between Spring DM and >> Blueprint but may help make up your mind, although note that since some of >> the statements were made things may have changed. In summary it doesn't >> appear clear (to me at least) where Spring-OSGI is heading, certainly some >> concerns over support for Spring 4 and OSGI. Our application is based on >> Spring DM (decision made a few years ago) however given the landscape as >> it >> is today I doubt whether we would have made the same decision. >> >> >> -- Peter Kriens pro Declarative services - DS is much better in working >> with services than Blueprint/Spring DM since they tend to to want to >> "hide" >> the dynamicity >> http://stackoverflow.com/questions/10008786/osgi-blueprint-vs-spring-dm >> >> -- Spring and OSGI >> http://karaf.922171.n3.nabble.com/OSGI-and-Spring-td4033211.html#a4033254 >> >> -- Spring and OSGI >> http://karaf.922171.n3.nabble.com/Re-The-future-of-the-Spring-with-Fabric8-td4033455.html >> >> -- We should also make clear that Spring DM is dead. And that in general >> Spring on OSGi is not a good idea >> https://github.com/fabric8io/fabric8/issues/1634 >> >> -- Spring stops creating OSGI bundles >> http://stackoverflow.com/questions/21181154/where-can-i-find-spring-4-osgi-bundles >> http://www.eclipse.org/forums/index.php/t/513222/ >> >> -- Spring 4 + Gemini incompatibility >> https://www.eclipse.org/forums/index.php/t/642416/ >> >> -- I would be really careful with Gemini blueprint. Springsource seems to >> have completely abondoned OSGi. >> -- So I fear that Gemini blueprint will go the same way as spring dm which >> is not maintained at all >> http://stackoverflow.com/questions/20993870/most-suitable-osgi-platform/21013910#21013910 >> >> -- I somehow doubt that gemini blueprint is still active. See >> git.eclipse.org/c/gemini.blueprint/… >> -- Not sure how active aries blueprint is. >> http://stackoverflow.com/questions/22381205/osgi-declarative-services-and-spring >> >> >> >> >> -- >> View this message in context: >> http://karaf.922171.n3.nabble.com/Spring-vs-Blueprint-tp4035374p4035389.html >> Sent from the Karaf - User mailing list archive at Nabble.com. >> > >
Re: loading config file from bundle
Mark, If you're new to OSGi, you might find "OSGi in Action" from Manning Publications to be a great resource. It provides a solid introduction to OSGi in general and the usage of container-provided services (such as ConfigurationAdmin). Additionally, the OSGi specification itself is quite readable and offers good insight in regards to expected behavior and the motivation behind both core and compendium services. Best Regards, Steve On Thu, Sep 25, 2014 at 5:22 PM, Achim Nierbeck wrote: > Hi Mark, > > yes that's the one :) > > regards, Achim > > 2014-09-25 23:03 GMT+02:00 Mark Webb : >> >> Achim, >> >> Thank you. I was going through the cookbook, just couldn't find good >> examples on the loading of configuration files. I think chapter 2 recipe 6 >> is what I'm looking for. >> >> >> >> On Thu, Sep 25, 2014 at 4:29 PM, Achim Nierbeck >> wrote: >>> >>> Hi Mark, >>> >>> first of all there is a reasonable amount of samples available. Take a >>> look at the manual, and a bit of googling should show you some blogs etc. >>> Besides there are already two books covering Apache Karaf available. >>> [1][2] >>> >>> In OSGi you usually use the Configuration Admin service for >>> configurations. For this you place your configuration file consisting of >>> properties in the etc folder, where the name of the file represents the id >>> of the service to configure (filename = service.pid.id.cfg). >>> So every time you change the configuration your service is re-configured >>> automatically for you. >>> >>> regards, Achim >>> >>> [1] - >>> https://www.packtpub.com/big-data-and-business-intelligence/learning-apache-karaf >>> [2] - >>> https://www.packtpub.com/application-development/apache-karaf-cookbook >>> >>> 2014-09-25 22:14 GMT+02:00 Mark Webb : >>>> >>>> >>>> I'm just getting into Karaf bundle development. I've had a hard time >>>> finding code examples to get going, so I am using maven to create skeleton >>>> projects. In my bundle, I want to load configuration information which I >>>> think I can from a file in the /etc folder. Where can I find a source code >>>> example on how to do this. >>>> >>> >>> >>> >>> -- >>> >>> Apache Member >>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & >>> Project Lead >>> blog <http://notizblog.nierbeck.de/> >>> >>> Software Architect / Project Manager / Scrum Master >>> >> > > > > -- > > Apache Member > Apache Karaf <http://karaf.apache.org/> Committer & PMC > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & > Project Lead > blog <http://notizblog.nierbeck.de/> > > Software Architect / Project Manager / Scrum Master >
Re: Strange behavior of the org.apache.karaf.features.FeaturesService in Apache Karaf 2.3.0
I started with a fresh container and created a very basic bundle that
simply prints the number of BundleInfo objects that are associated
with all installed Features. When the start(BundleContext) method is
called on its BundleActivator it simply prints this information to the
log:
public class Activator implements BundleActivator {
private final Logger logger = LoggerFactory.getLogger(getClass());
@Override
public void start(BundleContext context) throws Exception {
ServiceReference[] references =
context.getServiceReferences(FeaturesService.class.getName(), null);
if(references != null && references.length > 0){
logger.info("Located " + references.length + "
FeatureService instances available");
FeaturesService service = (FeaturesService)
context.getService(references[0]);
int bundleCount = getBundleInfoCount(service);
logger.info("Startup bundle feature/bundle mapping count:
" + bundleCount);
service = null;
for(ServiceReference servRef : references){
context.ungetService(servRef);
}
}
}
@Override
public void stop(BundleContext context) throws Exception {
}
private int getBundleInfoCount(FeaturesService service) {
int bundleCount = 0;
Feature[] installedFeatures = service.listInstalledFeatures();
if(installedFeatures != null && installedFeatures.length > 0){
for(Feature installedFeature : installedFeatures){
List bundles = installedFeature.getBundles();
if(bundles != null && !bundles.isEmpty())
bundleCount += bundles.size();
}
}
return bundleCount;
}
}
This works fine the first time; on a vanilla JBoss Fuse 6.0 (full)
container it locates 254 BundleInfo objects associated with the OOTB
Features. After the container is shutdown and started up again this
count drops down to 0. The second test I tried was to start a vanilla
container for the first time, shut it down, then start it back up and
install the test bundle. Again, zero BundleInfo objects were
associated with the installed Feature objects returned by
FeaturesService.listInstalledFeatures().
The workaround I have employed is to not rely on
FeaturesService.listInstalledFeatures(); rather, I query for all
available Features and then check their installation status
explicitly. The aforementioned method only seems to work correctly
the very first time the container is started (or after a "clean"). So
while the previous code doesn't work, the following does the trick:
private int getBundleInfoCount(FeaturesService service) {
int bundleCount = 0;
try {
Feature[] availableFeatures = service.listFeatures();
if(availableFeatures != null && availableFeatures.length > 0){
logger.info("Located " + availableFeatures.length + "
available Features");
for(Feature availableFeature : availableFeatures){
if(service.isInstalled(availableFeature)){
List bundles = availableFeature.getBundles();
if(bundles != null && !bundles.isEmpty())
bundleCount += bundles.size();
}
}
}
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return bundleCount;
}
When I get a chance I will see if this issue appears in version of
Karaf newer than 2.3.0.
Thanks,
-Steve
On Thu, Feb 13, 2014 at 9:20 AM, Steve wrote:
> Guillaume,
>
> The application in question leverages Blueprint Component and imports
> the FeaturesService as a container-provided service. Even when the
> application is not updated, the mere act of adding a Feature XML
> fragment to an existing Features repository XML document and
> refreshing via the service triggers the FeaturesService to lose track
> of all bundles on the next container restart (even those originating
> from different Feature repository XML documents). That leads me to
> believe something deeper might be going on.
>
>
> Thanks,
>
> -Steve
>
> On Wed, Feb 12, 2014 at 3:40 PM, Guillaume Nodet wrote:
>> Not sure if that's what you see, but the state of the FeaturesService is
>> saved in the bundle associated data directory.
>> So if you install a new bundle and remove the old one, the state would be
>> lost.
>> A workaround would be to *update* the bundle instead of install new /
>> uninstall old.
>>
>>
>> 2014-02-12 21:33 GMT+01:00 Steve :
>>
>>> Karaf users,
>>>
>>> I realized the scenario I described in my original message might be a
>>> bit complex, possibly obfuscating the
Re: Strange behavior of the org.apache.karaf.features.FeaturesService in Apache Karaf 2.3.0
Guillaume,
The application in question leverages Blueprint Component and imports
the FeaturesService as a container-provided service. Even when the
application is not updated, the mere act of adding a Feature XML
fragment to an existing Features repository XML document and
refreshing via the service triggers the FeaturesService to lose track
of all bundles on the next container restart (even those originating
from different Feature repository XML documents). That leads me to
believe something deeper might be going on.
Thanks,
-Steve
On Wed, Feb 12, 2014 at 3:40 PM, Guillaume Nodet wrote:
> Not sure if that's what you see, but the state of the FeaturesService is
> saved in the bundle associated data directory.
> So if you install a new bundle and remove the old one, the state would be
> lost.
> A workaround would be to *update* the bundle instead of install new /
> uninstall old.
>
>
> 2014-02-12 21:33 GMT+01:00 Steve :
>
>> Karaf users,
>>
>> I realized the scenario I described in my original message might be a
>> bit complex, possibly obfuscating the issue a bit. This one takes the
>> “agent” updating itself out of the picture and presents a simpler
>> scenario that demonstrates the issue. You can think of the "agent" as
>> a Feature-installed bundle that leverages the container-provided
>> FeaturesService service.
>>
>> 1. A Karaf container is run “clean”, and automatically installs
>> the “agent” Feature via the bootstrap mechanism. The Feature
>> repository containing the aforementioned “agent” Feature contains two
>> versions 0.0.1-SNAPSHOT and 0.0.2-SNAPSHOT. The bootstrapping
>> mechanism takes the newest version and installs it as one would
>> expect.
>>
>> 2. The container can be started/stopped and the FeaturesService,
>> as used by the “agent”, works correctly. The BundleInfo objects
>> associated with each installed Feature are available
>> (Feature.getBundles()).
>>
>> 3. A new version of the “agent” Feature, 0.0.3-SNAPSHOT, is
>> added to the Features repository and the “agent” is then instructed to
>> refresh all repositories (via the same process used by the
>> “features:refreshurl” shell command – remove/add).
>>
>> 4. The next time the container is restarted the installed
>> Features returned by the FeaturesService no longer have any BundleInfo
>> objects associated with them; Feature.getBundles() never returns a
>> List that is populated (even when it previously did).
>>
>> It seems odd that the modification to the Features repository XML
>> document would cause the FeaturesService (really the Feature objects
>> it returns) to lose track of the relationship between all Features
>> (regardless of repo) and their associated bundles. Any clue as to
>> what might be the cause of this?
>>
>> Any assistance or advice in this matter is greatly appreciated.
>>
>>
>>
>> Many Thanks,
>>
>> -Steve
>>
>>
>> On Wed, Feb 12, 2014 at 11:01 AM, Steve wrote:
>> > Karaf users,
>> >
>> > I'm experiencing strange behavior of the concrete implementation of
>> > the org.apache.karaf.features.FeaturesService interface in Apache
>> > Karaf 2.3.0 (as part of JBoss Fuse 6) – please take a look at my use
>> > case and see if you might be able to shed some light on what I’m
>> > experiencing:
>> >
>> > I’ve implemented an “agent” that provisions its host Karaf container
>> > using Features (as opposed to bundles or KARs). The agent itself is
>> > also installed/upgraded via the Features mechanism. I’ve recently run
>> > into a strange issue when the agent updates itself; specifically,
>> > after successfully self-updating to a new version (old installs new,
>> > new uninstalls old) and restarting the container the FeaturesService
>> > doesn’t return Features that have BundleInfo objects associated with
>> > them. It’s worth noting that the problem only materializes after a
>> > restart; never before.
>> > As a result, the agent is no longer able to correctly identify its
>> > encapsulating Feature. I use the following code-fragment to identify
>> > the Feature(s) which encapsulate the agent application’s bundle:
>> >
>> > public Set getEncapsulatingFeatureSet() {
>> > Set encapsulatingFeatureSet = new HashSet();
>> > String selfBundleLocation = bundleContext.getBundle().getLocation();
>> >
>> > Feature[] installedFeatureArray =
>> > featuresService.listInstalledFeatures();
>> > for(
Re: Strange behavior of the org.apache.karaf.features.FeaturesService in Apache Karaf 2.3.0
Karaf users,
I realized the scenario I described in my original message might be a
bit complex, possibly obfuscating the issue a bit. This one takes the
“agent” updating itself out of the picture and presents a simpler
scenario that demonstrates the issue. You can think of the "agent" as
a Feature-installed bundle that leverages the container-provided
FeaturesService service.
1. A Karaf container is run “clean”, and automatically installs
the “agent” Feature via the bootstrap mechanism. The Feature
repository containing the aforementioned “agent” Feature contains two
versions 0.0.1-SNAPSHOT and 0.0.2-SNAPSHOT. The bootstrapping
mechanism takes the newest version and installs it as one would
expect.
2. The container can be started/stopped and the FeaturesService,
as used by the “agent”, works correctly. The BundleInfo objects
associated with each installed Feature are available
(Feature.getBundles()).
3. A new version of the “agent” Feature, 0.0.3-SNAPSHOT, is
added to the Features repository and the “agent” is then instructed to
refresh all repositories (via the same process used by the
“features:refreshurl” shell command – remove/add).
4. The next time the container is restarted the installed
Features returned by the FeaturesService no longer have any BundleInfo
objects associated with them; Feature.getBundles() never returns a
List that is populated (even when it previously did).
It seems odd that the modification to the Features repository XML
document would cause the FeaturesService (really the Feature objects
it returns) to lose track of the relationship between all Features
(regardless of repo) and their associated bundles. Any clue as to
what might be the cause of this?
Any assistance or advice in this matter is greatly appreciated.
Many Thanks,
-Steve
On Wed, Feb 12, 2014 at 11:01 AM, Steve wrote:
> Karaf users,
>
> I'm experiencing strange behavior of the concrete implementation of
> the org.apache.karaf.features.FeaturesService interface in Apache
> Karaf 2.3.0 (as part of JBoss Fuse 6) – please take a look at my use
> case and see if you might be able to shed some light on what I’m
> experiencing:
>
> I’ve implemented an “agent” that provisions its host Karaf container
> using Features (as opposed to bundles or KARs). The agent itself is
> also installed/upgraded via the Features mechanism. I’ve recently run
> into a strange issue when the agent updates itself; specifically,
> after successfully self-updating to a new version (old installs new,
> new uninstalls old) and restarting the container the FeaturesService
> doesn’t return Features that have BundleInfo objects associated with
> them. It’s worth noting that the problem only materializes after a
> restart; never before.
> As a result, the agent is no longer able to correctly identify its
> encapsulating Feature. I use the following code-fragment to identify
> the Feature(s) which encapsulate the agent application’s bundle:
>
> public Set getEncapsulatingFeatureSet() {
> Set encapsulatingFeatureSet = new HashSet();
> String selfBundleLocation = bundleContext.getBundle().getLocation();
>
> Feature[] installedFeatureArray = featuresService.listInstalledFeatures();
> for(Feature installedFeature : installedFeatureArray){
> for(BundleInfo bundleInfo : installedFeature.getBundles()){
> if(selfBundleLocation.equals(bundleInfo.getLocation())){
> encapsulatingFeatureSet.add(installedFeature);
> logger.info("Encapsulating Feature detected --> " +
> installedFeature.getName() + "/" + installedFeature.getVersion());
> break;
> }
> }
> }
>
> return Collections.unmodifiableSet(encapsulatingFeatureSet);
> }
>
> This has always worked very well and I haven’t had any prior issues.
> However, after restarting post-update the List of installed Features
> returned by FeaturesService.listInstalledFeatures() do not show up as
> having any BundleInfo objects associated with them (for both OOTB and
> custom Features) as retrieved by Feature.getBundles().
>
> I admit I’m at a loss to explain why I’m receiving what can only be
> described as invalid data (I know these Features should have
> BundleInfo objects associated with them). I’m hoping someone might be
> able to shed some light on why the FeaturesService is seemingly
> behaving strangely (if its operator-error please let me know), and
> then only after a restart.
>
>
> Thank you for your time,
>
> -Steve
Strange behavior of the org.apache.karaf.features.FeaturesService in Apache Karaf 2.3.0
Karaf users,
I'm experiencing strange behavior of the concrete implementation of
the org.apache.karaf.features.FeaturesService interface in Apache
Karaf 2.3.0 (as part of JBoss Fuse 6) – please take a look at my use
case and see if you might be able to shed some light on what I’m
experiencing:
I’ve implemented an “agent” that provisions its host Karaf container
using Features (as opposed to bundles or KARs). The agent itself is
also installed/upgraded via the Features mechanism. I’ve recently run
into a strange issue when the agent updates itself; specifically,
after successfully self-updating to a new version (old installs new,
new uninstalls old) and restarting the container the FeaturesService
doesn’t return Features that have BundleInfo objects associated with
them. It’s worth noting that the problem only materializes after a
restart; never before.
As a result, the agent is no longer able to correctly identify its
encapsulating Feature. I use the following code-fragment to identify
the Feature(s) which encapsulate the agent application’s bundle:
public Set getEncapsulatingFeatureSet() {
Set encapsulatingFeatureSet = new HashSet();
String selfBundleLocation = bundleContext.getBundle().getLocation();
Feature[] installedFeatureArray = featuresService.listInstalledFeatures();
for(Feature installedFeature : installedFeatureArray){
for(BundleInfo bundleInfo : installedFeature.getBundles()){
if(selfBundleLocation.equals(bundleInfo.getLocation())){
encapsulatingFeatureSet.add(installedFeature);
logger.info("Encapsulating Feature detected --> " +
installedFeature.getName() + "/" + installedFeature.getVersion());
break;
}
}
}
return Collections.unmodifiableSet(encapsulatingFeatureSet);
}
This has always worked very well and I haven’t had any prior issues.
However, after restarting post-update the List of installed Features
returned by FeaturesService.listInstalledFeatures() do not show up as
having any BundleInfo objects associated with them (for both OOTB and
custom Features) as retrieved by Feature.getBundles().
I admit I’m at a loss to explain why I’m receiving what can only be
described as invalid data (I know these Features should have
BundleInfo objects associated with them). I’m hoping someone might be
able to shed some light on why the FeaturesService is seemingly
behaving strangely (if its operator-error please let me know), and
then only after a restart.
Thank you for your time,
-Steve
Re: Programmatically restarting Karaf while using the service wrapper
JB,
Thank you for clarifying that for me. Your quick reply was very much
appreciated!
-Steve
On Tue, Feb 4, 2014 at 9:41 AM, Jean-Baptiste Onofré wrote:
> Hi Steve,
>
> no worries, you can do a restart via the service wrapper.
>
> Basically, it's what you do when you do restart on the service wrapper (on
> Windows with service restart, or on Unix with /etc/init.d/karaf restart).
>
> Regards
> JB
>
>
> On 02/04/2014 03:24 PM, Steve wrote:
>>
>> Karaf users,
>>
>>
>> A little background:
>>
>> I have a bundle that periodically needs to restart its host Karaf
>> container. I accomplish this by setting the “karaf.restart”
>> system-property to “true” and then stopping the system-bundle. This
>> worked perfectly when Karaf was invoked directly via the bat files;
>> however, when using the service wrapper an attempt to restart simply
>> resulted in Karaf shutting down:
>>
>> System.setProperty("karaf.restart", "true");
>> bundleContext.getBundle(0).stop();
>>
>> I checked the mailing list archives and determined that this was
>> likely due to the Java Service Wrapper’s default behavior to shutdown
>>
>> (http://karaf.922171.n3.nabble.com/Ability-to-self-restart-karaf-WAS-Infamous-permgen-leak-tp3589167p3590128.html).
>> The advice mentioned in the previous thread suggested changing the
>> Java Service Wrapper’s default behavior from “SHUTDOWN” to “RESTART”
>> via a wrapper configuration parameter (“wrapper.on_exit.default”).
>> While this works, it does prevent a normal shutdown as the wrapper
>> will restart the application no matter what.
>>
>> After digging through the Java Service Wrapper documentation further I
>> discovered the filter mechanism by which the wrapper monitors the
>> console output of an application for “triggers” upon which it can act.
>> I was able to add a “trigger” to my code, via a System.out statement,
>> and indeed the wrapper initiates a restart while still allowing the
>> application to function correctly when invoked via the normal bat
>> files (sans-wrapper):
>>
>> System.setProperty("karaf.restart", "true");
>> System.out.println("wrapper_restart_requested"); //wrapper restart trigger
>> bundleContext.getBundle(0).stop();
>>
>> Question:
>>
>> Are there any negative implications to the Karaf container by allowing
>> the wrapper to initiate a restart rather than stopping the
>> system-bundle directly? Does this introduce the possibility of
>> leaving the container in an inconsistent/corrupt state. I speculate
>> that the answer to this is “no”; however, I was hoping others
>> (especially core developers) might be able to give me a yes/no in
>> regards to the validity of this approach (or perhaps suggest an
>> alternative).
>>
>> Thanks,
>> Steve
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Programmatically restarting Karaf while using the service wrapper
Karaf users,
A little background:
I have a bundle that periodically needs to restart its host Karaf
container. I accomplish this by setting the “karaf.restart”
system-property to “true” and then stopping the system-bundle. This
worked perfectly when Karaf was invoked directly via the bat files;
however, when using the service wrapper an attempt to restart simply
resulted in Karaf shutting down:
System.setProperty("karaf.restart", "true");
bundleContext.getBundle(0).stop();
I checked the mailing list archives and determined that this was
likely due to the Java Service Wrapper’s default behavior to shutdown
(http://karaf.922171.n3.nabble.com/Ability-to-self-restart-karaf-WAS-Infamous-permgen-leak-tp3589167p3590128.html).
The advice mentioned in the previous thread suggested changing the
Java Service Wrapper’s default behavior from “SHUTDOWN” to “RESTART”
via a wrapper configuration parameter (“wrapper.on_exit.default”).
While this works, it does prevent a normal shutdown as the wrapper
will restart the application no matter what.
After digging through the Java Service Wrapper documentation further I
discovered the filter mechanism by which the wrapper monitors the
console output of an application for “triggers” upon which it can act.
I was able to add a “trigger” to my code, via a System.out statement,
and indeed the wrapper initiates a restart while still allowing the
application to function correctly when invoked via the normal bat
files (sans-wrapper):
System.setProperty("karaf.restart", "true");
System.out.println("wrapper_restart_requested"); //wrapper restart trigger
bundleContext.getBundle(0).stop();
Question:
Are there any negative implications to the Karaf container by allowing
the wrapper to initiate a restart rather than stopping the
system-bundle directly? Does this introduce the possibility of
leaving the container in an inconsistent/corrupt state. I speculate
that the answer to this is “no”; however, I was hoping others
(especially core developers) might be able to give me a yes/no in
regards to the validity of this approach (or perhaps suggest an
alternative).
Thanks,
Steve
Determining status information in a Failover deployment
Hello Karaf users, I was wondering if there was an elegant way for a system-bundle running in a Karaf container that is operating as part of a Failover deployment to determine its status (active, hot, cold)? I know one could check the status of bundles whose start-level values exceed the threshold set by the "karaf.lock.level parameter"; however, I was wondering if there might be a more definitive means of making such a determination via information exposed by the container. Perhaps there is a best practice around this? My thanks to all for taking the time to read this message. -Steve
Re: Best practices around programmatic Feature manipulation (updating/self-updating)
JB, Thank you very much for the quick reply; you definitely answered my questions. I appreciate you taking the time to assist me in this matter. I feel much more confident that I'm proceeding appropriately. Best Regards, -Steve On Fri, Nov 15, 2013 at 12:19 PM, Jean-Baptiste Onofré wrote: > Hi Steve, > > my answer inline: > > >> 1.) A container has a Feature installed, “example-app”, at version >> 1.0. Now let’s say I decide I want to run version 1.1 at some point >> down the road. Would the best practice be to first uninstall the >> Feature at version 1.0 and then install version 1.1, or to just >> install version 1.1 directly (skipping the explicit uninstall step)? >> Currently I use the FeaturesService programmatically to uninstall the >> old version prior to install the new. While this seems to work fine, >> I thought it wise to inquire if there was an existing best practice >> around this or, perhaps, potential pitfalls to be avoided. > > > We don't provide features:update or equivalent mechanism because it's not so > trivial, especially for transitive features. > > Generally speaking, the best practice is to uninstall the "example-app" > feature first, and install using the new feature version. > Actually, it depends of the components shared between the two features. As I > guess that you share most of the components, it's better to > uninstall/install. > > features:update is on my TODO list. > > >> 2.) The provisioning agent itself is installed as part of a Feature. >> I currently let the agent install a new version of its encapsulating >> Feature. With other Features not associated with the agent, as I >> mentioned in question #1, I explicitly uninstall the old version prior >> to installing the new. For the agent I don’t do this to prevent a >> “bundle-suicide” type of situation. When the agent installs a new >> version of its encapsulating Feature this triggers an implicit >> framework restart after which the new version is installed and the >> older version uninstalled. Interestingly enough, if I try to go the >> other direction, say from 1.1 back to 1.0, I get unfulfilled >> dependencies that prevent the older version of the Feature from >> installing (and both features end up uninstalled). The dependency in >> question (commons-lang 3.x) is actually embedded in both version 1.0 >> and 1.1 of the bundle containing the application (both bundles are >> identical except in version number for testing). I suspect the old >> version is attempting to import packages from the new version’s >> bundle, but fails to do so because the latter is then invalid. Should >> I allow my agent to install a new version of its encapsulating Feature >> or is this going down the wrong road? Is there a best practice (or >> any advice) around a Feature self-update scenario? > > > The best way is probably to define a kind of "my-common" feature, with > dependency="true" on their bundles (defining commons-lang, etc). Like this, > even if you update the next agent feature, it won't change the common part > (if I right understood ;)). > > Regards > JB > > >> >> >> I will greatly appreciate any information/advice that can be given >> (even “RTFM” if you can point me to the right manual). >> >> >> Thanks! >> >> -Steve >> > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com
Best practices around programmatic Feature manipulation (updating/self-updating)
Hello Karaf users, I’m in the process of developing a provisioning agent for a Karaf-based ESB (Fuse ESB/ServiceMix). Currently I’m using Features exclusively as my unit of deployment as opposed to working directly with individual bundles when provisioning. The Features mechanism is quite nice and has been pleasant to work with programmatically via the FeaturesService interface. In the course of developing this agent though I’ve come up with a few questions, mostly related to best-practices. I haven’t found answers in existing documentation; if such information does exist, you have my apologies in advance for troubling the mailing-list with something already answered elsewhere. With that being said, here are my questions: 1.) A container has a Feature installed, “example-app”, at version 1.0. Now let’s say I decide I want to run version 1.1 at some point down the road. Would the best practice be to first uninstall the Feature at version 1.0 and then install version 1.1, or to just install version 1.1 directly (skipping the explicit uninstall step)? Currently I use the FeaturesService programmatically to uninstall the old version prior to install the new. While this seems to work fine, I thought it wise to inquire if there was an existing best practice around this or, perhaps, potential pitfalls to be avoided. 2.) The provisioning agent itself is installed as part of a Feature. I currently let the agent install a new version of its encapsulating Feature. With other Features not associated with the agent, as I mentioned in question #1, I explicitly uninstall the old version prior to installing the new. For the agent I don’t do this to prevent a “bundle-suicide” type of situation. When the agent installs a new version of its encapsulating Feature this triggers an implicit framework restart after which the new version is installed and the older version uninstalled. Interestingly enough, if I try to go the other direction, say from 1.1 back to 1.0, I get unfulfilled dependencies that prevent the older version of the Feature from installing (and both features end up uninstalled). The dependency in question (commons-lang 3.x) is actually embedded in both version 1.0 and 1.1 of the bundle containing the application (both bundles are identical except in version number for testing). I suspect the old version is attempting to import packages from the new version’s bundle, but fails to do so because the latter is then invalid. Should I allow my agent to install a new version of its encapsulating Feature or is this going down the wrong road? Is there a best practice (or any advice) around a Feature self-update scenario? I will greatly appreciate any information/advice that can be given (even “RTFM” if you can point me to the right manual). Thanks! -Steve
