What are the differences between features vs bundles vs dependencies vs prerequisites vs requirements in Apache Karaf? - apache-karaf

It is unfortunate that the OSGi container implementation, called Karaf, is poorly documented. Concepts are brushed over, and relationships between terminology are not made.
My conclusions after reading the text authored by Karaf developers (I guess?):
"prerequisite" does not allow my "special-server" bundle to be started when other bundles (I would call dependencies) are not available in the OSGi container.
dependencies are the same
both of those don't cause Karaf to automatically fetch and start those dependencies
requirements, according to documentation https://karaf.apache.org/manual/latest/provisioning, will cause Karaf to automatically fetch and start those dependencies/prerequisites/requirements.
repositories are in my features.xml for developers to know where to get dependencies/prerequisites/requirements, but are not automatically added to Karaf.
Please fill me in.
Here is my example of a features.xml that I run through maven-resources-plugin's copy-resources goal so that interpolation of ${var}s occurs.
<?xml version="1.0" encoding="UTF-8"?>
<features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://karaf.apache.org/xmlns/features/v1.0.0 http://karaf.apache.org/xmlns/features/v1.0.0"
name="special-server-features">
<!-- Special Server -->
<feature name="special-server" version="1.0.0" install="auto" resolver="(obr)">
<details>
A feature is just a group of bundles that should all be installed together.
When an OSGi container adds a bundle, it goes through a resolution process
to make sure that the bundle’s dependencies are met (and that it does not
conflict with other installed bundles). However, that resolution process
does not include any ability to obtain any dependencies; it just checks to
see if they are available and delays or prevents the bundle from starting
if a required dependency is missing.
Requirements can tell the feature resolver to
automatically install the bundles to satisfy the requirements.
Dependencies vs. prerequisites:
</details>
<!-- Required feature repositories (containing all bundles) -->
<repository>mvn:org.apache.camel.karaf/apache-camel/${camel.version}/xml/features</repository>
<repository>mvn:org.apache.cxf.karaf/apache-cxf/${camel.version}/xml/features</repository>
<bundle version="${camel.version}" prerequisite="true">camel-core</bundle>
<bundle version="${camel.version}" prerequisite="true">cxf</bundle>
<bundle version="${camel.version}" prerequisite="true">camel-blueprint</bundle>
<bundle version="${camel.version}" prerequisite="true">camel-jackson</bundle>
<bundle version="${camel.version}" prerequisite="true">camel-cxf</bundle>
<bundle version="${camel.version}" prerequisite="true">camel-http</bundle>
<bundle version="${camel.version}" prerequisite="true">camel-jaxb</bundle>
<bundle version="${camel.version}" prerequisite="true">camel-jsch</bundle>
<bundle version="${camel.version}" prerequisite="true">camel-log</bundle>
<bundle version="${camel.version}" prerequisite="true">camel-stream</bundle>
</feature>
</features>

The Apache Karaf documentation basically extends the terminology of the OSGi specifications, which means it is assumed that you have some knowledge of OSGi.
Speaking of which, the different terms you mentioned can be located clearly in either OSGi or Karaf.
The terms "Bundle", "Dependency" and "Requirement" belong to the OSGi Core specification. Whereas "Feature" and "Prerequisite" are Apache Karaf specific terms.
Now to your list:
Q: "prerequisite" does not allow my "special-server" bundle to be started when other bundles (I would call dependencies) are not available in the OSGi container.
A: First of all, please note that the "prerequisite" does not apply to bundle dependencies, only to feature dependencies (btw. your XSD is outdated, have a look at the current XSD), and yes, it is just a specialization of a dependency. For that, the documentation is quite explicit:
If you will add prerequisite attribute to dependant feature tag then
it will force installation and also activation of bundles in dependant
feature before installation of actual feature.
Q: dependencies are the same
A: Yes and no. As "prerequisite" dependencies are still just dependencies with a different behavior for the installation/activation life-cycle of a feature, they still just describe dependencies but behave slightly differently.
If you refer instead to the special attribute at a bundle dependency, e.g. <bundle dependency="true">..., then it means that if the bundle (respecting the acceptable version if specified) is already available in the system it will not be installed again.
Q: both of those don't cause Karaf to automatically fetch and start those dependencies
A: In both cases, Karaf does install dependent features and bundles as necessary. Starting happens either before (with "prerequisite" features) or at feature installation (unless you have disabled that).
Q: requirements, according to documentation, will cause Karaf to automatically fetch and start those dependencies/prerequisites/requirements.
A: If you are referring to feature "requirements", then yes and no. Yes, because the resolver will try to find some other feature or bundle that provides the requirement (this is called a "Capability") and install it if some is found. If the current state of the system already provides the requirement, nothing happens and the feature can be installed right away. If no bundle or feature can be found for that, the feature installation will fail. No, because they will no immediately be started. Starting happens when the feature itself is started.
Q: repositories are in my features.xml for developers to know where to get dependencies/prerequisites/requirements, but are not automatically added to Karaf.
A: Clearly no. You add repositories to let the Karaf resolver know where to find the definition of dependent features, not bundles. If you don't have dependencies to other features in your definition, there is no reason to add a repository. The documentation provides more details.
TL;DR
You are complaining about the documentation but you are mixing up terminology by yourself and by that you may end up in false assumptions or expectations. But I agree that in some details, the terminology of Karaf could be better and more intuitive.
Regarding your features.xml:
Please update the schema to v1.3.0
<features xmlns="http://karaf.apache.org/xmlns/features/v1.3.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://karaf.apache.org/xmlns/features/v1.3.0
http://karaf.apache.org/xmlns/features/v1.3.0"
name="special-server-features">
If you want to install Apache Camel and CXF, you just install the features, not the bundles, e.g.:
<feature name="special-server" version="1.0.0" install="auto" resolver="(obr)">
<feature>camel-blueprint</feature>
...
</feature>
Your declaration of <bundle> dependencies is simply wrong. You specified features, not bundles.
There is no prerequisite attribute for the <bundle> tag and never has been (please adhere to the XSD)
The <repository> can only be declared at the top-level, not inside a feature (also violates the XSD)
Example Features Repository
Based on your example, I've compiled an example features repository including comments in an attempt to clarify the questions a bit more practical:
<?xml version="1.0" encoding="UTF-8"?>
<features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://karaf.apache.org/xmlns/features/v1.4.0 http://karaf.apache.org/xmlns/features/v1.4.0"
name="special-server-features">
<!-- Required feature repositories -->
<!-- We don't need to define this since Apache Camel already does it
<repository>mvn:org.apache.cxf.karaf/apache-cxf/3.3.1/xml/features</repository>
-->
<repository>mvn:org.apache.camel.karaf/apache-camel/3.0.0.M2/xml/features</repository>
<!-- Special Server -->
<feature name="special-server" version="1.0.0" install="auto">
<!--
Require Java 8 at least.
-->
<requirement>osgi.ee;filter:="(&(osgi.ee=JavaSE)(version>=1.8))"</requirement>
<!--
Every <feature> declares a dependency to another feature declaration
(either available in this <features> repository or an external one.
The dependency is bascially made up by referencing the "name" of
another <feature> declaration.
dependency="true"
the feature will not be installed if already available
prerequisite="true"
the feature will be installed before ours and all bundles will
be started
-->
<feature dependency="true" prerequisite="true">cxf</feature>
<feature prerequisite="true">camel-core</feature>
<feature prerequisite="true">camel-cxf</feature>
<!--
These features will just be installed as part of installing the
current feature.
-->
<feature>camel-blueprint</feature>
<feature>camel-jackson</feature>
<feature>camel-http4</feature>
<feature>camel-jaxb</feature>
<feature>camel-jsch</feature>
<feature>camel-stream</feature>
<!--
Every <bundle> declares a dependency to a standard OSGi Bundle using
a URL including a protocol to uniquely identify the artifact.
For Apache Karaf the most common protocol is to rely on Maven:
https://ops4j1.jira.com/wiki/spaces/paxurl/pages/3833866/Mvn+Protocol
Here, you also need to know that Apache Karaf also provides an
internal Maven repository which is asked first and contains all
Bundles that are already installed. This Maven repository usually
exists at the Karaf installation sub-directory "system".
-->
<!--
This bundle needs to be available, but we certainly don't want to
"wrap" it again if it is already there.
See also: https://ops4j1.jira.com/wiki/spaces/paxurl/pages/3833898/Wrap+Protocol
-->
<bundle dependency="true">wrap:mvn:org.minidns/minidns-core/0.3.3</bundle>
<!--
Now this is our own bundle which requires all of the above to do
it's work properly.
-->
<bundle>mvn:com.mycorp.servers/special-server/1.0.0</bundle>
</feature>
</features>

Related

Not updated module version in Magnolia

What could be a reason for not updated module version in Magnolia 5.7
In Magnolia java project I have submodule with XML descriptor in META-INF/magnolia/mymodule.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module SYSTEM "module.dtd" >
<module>
<name>mymodule</name>
<displayName>mymodule</displayName>
<description>my module</description>
<version>${project.version}</version>
<!-- <version>1.3</version> -->
<dependencies>
<dependency>
<name>core</name>
<version>5.7.4/*</version>
</dependency>
</dependencies>
</module>
When I rebuild the whole project with version changed in project maven pom.xml and deploy on a server I don't see an updated version in Magnolia's Author configuration console. I have to manually remove the old version node in the configuration console (remove JCR node) and then restart the server. After these steps, I can confirm the new version in the configuration console. Which is a pain if you have to deploy to several dev/stage/prod environments needless to say that I have no access to a public instance in a production environment.
The problem with not updated version sounds like not important, but I'm also not seeing new or renamed pages associated with this module. They appear only if I force to reload module by removing version.
One additional detail which may help identify the problem: I can delete version node in JCR, but can NOT delete the whole module node. I receive an error message "Level 1 and 2 nodes in config workspace cannot be unpublished".
What version do you see in the config:/modules/your_module/version before you delete it? Is it lower than version number of version you are trying to install? I would suspect that it's same or higher. Ie you are trying to reinstall same version or downgrade the version. Neither of those is supported hence it doesn't trigger the installation process. Or perhaps you are trying to move up from SNAPSHOT to full version for which there's no install delta either.
As for the warning you get when trying to delete those nodes, it is on purpose. You are not supposed to be deleting those nodes as a normal user since you could cause breakage of dependent (public) instances. Only as admin (via JCR Browser) you are allowed to delete, assuming you know what and why you are doing.

Unable to hot deploy a karaf feature

I am unable to get hot deployment of karaf feature to work in JBoss Fuse. I have the following feature XML descriptor in deploy directory, but it never gets picked up by Fuse and it never gets installed.
<?xml version="1.0" encoding="UTF-8"?>
<features name="IssSysIntRepo">
<feature name="sys-int" install="auto" version="1.0.0">
<bundle>file:/opt/sys-int.jar</bundle>
<feature>camel-jackson</feature>
<feature>camel-restlet</feature>
</feature>
</features>
If I manually add the repository by URL that leads to the file in deploy directory by features:addurl path/feature.xml and then install the feature by features:install sys-int it loads the feature successfully.
Logs on startup do not mention anything about the feature or an error, as I quickly looked over it.
Do you know where might be a problem?
I am using fresh install of jboss-fuse-karaf-full 6.2.0.redhat-099

What Drools JARS are needed in a servet's WEB-INF\lib for jBPM?

I have ported a Tomcat servlet to run with JBoss 7.1 and am now trying to add jBPM support to it. I have run the jbpm-5.4.0.Final-installer-full.zip to get JBoss/jBPM installed with Kepler (I had to patch the installer to install Kepler). I then copied a line of code from the installer's "evaluation" sample and placed it in my servlet. That line of code is:
KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
After adding the necessary imports I got a clean build. I thought that I could then take the Drools run time files I found in the installer's .\runtime\lib and place them in my servlet's .\WEB-INF\lib. However, doing this caused me to get a "Class not found" exception when I tried to execute the KnowledgeBuilder line of code. It turns out that if I replace the JARs from the installer's .\runtime\lib with the JARS in drools-distribution-5.5.0.Final.zip (from http://www.jboss.org/drools/downloads) in my .\WEB-INF\lib I am able to execute KnowledgeBuilder line of code.
My questions are:
1) Why don't the JARs from the installer's .\runtime\lib work in the above?
2) Where can I find documentation on what all of these Drools JARs do and which ones are needed?
Thank you.
Al
If I were to list specific Jars here, the answer would only apply to a specific version of Drools. The best way to get the correct JARs is to use Maven to build your project. That will automatically import all of the JARs that are needed.
You will usually need dependencies for drools-core and drools-compiler. Those have their own transitive dependencies.
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-core</artifactId>
<version>${drools.version}</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-compiler</artifactId>
<version>${drools.version}</version>
</dependency>
If you use Eclipse, then you can just create a pom.xml with those dependencies in it. Open it in the Maven pom editor and the "Effective POM" tab will show you all of the required dependencies.

Adobe Flex/AIR Maven integration

I am writing an Adobe AIR application that needs to build in a CI using maven and nexus. I tried to follow this article which is the most up to date article from the source, but I still don't understand these things:
Are the first and second pom.xml examples in the article in the same pom.xml file?
How do I get the Flex SDK dependencies on my CI?
It would be awesome if someone had a complete project setup and went through the whole thing.
This blog has some useful information on building Air applications with Maven 2.
As far as your numbered questions are concerned
Part 1: The two POMs in the tutorial are different. The first creates the swf package containing your application components. The second POM has a dependency on the swf package (note the dependency in the second POM for the artifactId Air in the first). The second POM defines processing to unpack the swf package (using the dependency plugin), then uses the exec plugin to invoke adt on the unpacked package contents.
The process described is therefore in two parts. The first POM packages the swf files so they are available in the repository. The second POM will retrieve any packages required from the Maven repository and invoke adt to compile them. So if you have multiple Air packages, the second POM can be modified to download the extra packages and compile them.
Part 2: Most of the dependencies you need are hosted in the Sonatype public repository, one notable exception seems to be the adt.jar. You can deploy the adt.jar to a Maven repository manager such as Nexus using the deploy plugin's deploy-file goal.
This would deploy the adt.jar to the repository with credentials matching the tutorial:
mvn deploy:deploy-file -Durl=http://path/to/repository -DrepositoryId=[some.id]
-Dfile=adt.jar -DgroupId=com.adobe.flex.compiler -DartifactId=adt
-Dversion=3.3.0.4852 -DgeneratePom=true -DgeneratePom.description="Flex ADT"
To reference the Nexus public repository, add a repository declaration to your settings.xml or pom.xml like this:
<repositories>
<repository>
<id>nexus-public</id>
<url>http://repository.sonatype.org/content/groups/public</url>
</repository>
</repositories>

Wix - ComPlusAssembly - Could not install type library

I'm new to Wix and I have ran into a problem that I'm obviously not able to solve on my own, so any help will be very much appreciated.
Quick background:
I'm representing a software vendor building a comprehensive suite of SOA based applications for deployment in large enterprises. Our architecture consists of many layers which may be installed/upgraded independently, so I'm building several installers, composing from the ground up (like: platform, core framework components, service layer, business layer, application layer, etc.).
Software versions:
-Wix 3.5.1309.0 (wix.dll)
- Visual Studio 2008, .Net 3.5
- Build OS: Windows 2008 R2 Standard 64 bit
- Deploy OS: Windows 2008 Standard 32 bit
My problem is in regards to installing .Net assemblies in COM+ applications. I keep on getting the error "Could not install type library". I have been reading all the documentation that I can find, and I have been google'ing for several days now. I find quite a few posts on the topic, but I'm still not able to resolve the issue.
To isolate the problem I have extracted the issue into a separate installer. First I run the main installer:
1. Installs all assemblies into GAC, including the one to be installed in COM+.
2. Create local users and groups.
3. Create the target COM+ application, including roles etc.
4. Installs the target assembly, and the companion typelib, in a folder (to remove any GAC lookup issues)
This installer I can install/repair/uninstall, everything works fine.
Then I run the minimum installer containing only the issue, which tries to:
1. Install the assembly in an existing COM+ application (server), referencing the pre-installed .dll and .tlb.
The install fails, and the log is showing:
MSI (s) (AC:64) [19:16:01:127]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI1BAB.tmp, Entrypoint: ComPlusInstallExecute
ComPlusInstallExecute: ExceptionInfo: Code='0', Source='System.EnterpriseServices', Description='Could not install type library 'c:\Program Files\MyManufacturer\ComPlus\WDA.ServiceProviders.Update.11.tlb' into application 'WDA.ServiceProviders.Update.11'.', HelpFile='', HelpContext='0'
ComPlusInstallExecute: Error 0x80020009: Failed to invoke RegistrationHelper.InstallAssembly() method
ComPlusInstallExecute: Error 0x80020009: Failed to register .NET assembly
ComPlusInstallExecute: Error 0x80020009: Failed to register assembly, key: MyAssembly
ComPlusInstallExecute: Error 0x80020009: Failed to register assemblies
Action ended 19:16:02: InstallFinalize. Return value 3.
I also notice that the rollback removes the COM+ application, even though it was not created by this installer.
I can install the assembly manually, using the Server Manager, from the same physical file that the installer is referencing. After manually removing the component from the COM+ application, then the installer works!
Also, why do I have to supply a typelib in the first place? The EnterpriseServices.RegistrationHelper is generating the typelib on the fly anyway.
This is the minimum test installer that is failing:
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:complus="http://schemas.microsoft.com/wix/ComPlusExtension"
>
<Product Id="48EDB258-BD84-47EF-94A2-B4950EE48139"
UpgradeCode="F29B8EBD-DFD1-4B7E-96FF-86842CAAE4A4"
Name="ComPlusInstalls"
Language="1033"
Version="1.0.0"
Manufacturer="MyManufacturer">
<Package Id="ABA41719-BC28-4A57-BA9A-58F4F3B2194F" InstallerVersion="200" Compressed="yes" />
<Media Id="1" Cabinet="WixTest.cab" EmbedCab="yes" />
<complus:ComPlusApplication Id="MyApplication" ApplicationId="1FCF220A-A1FE-44FE-BE91-B37341BA6D4A" />
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="MyManufacturer" Name="MyManufacturer">
<Directory Id="INSTALLLOCATION" Name="ComPlus">
<Component Id="MyComponent" Guid="6D46A007-6669-487B-BAA0-DFA7314C141D" KeyPath="yes">
<complus:ComPlusAssembly Id="MyAssembly" Type=".net" Application="MyApplication"
RegisterInCommit="no" DllPathFromGAC="no"
DllPath="[INSTALLLOCATION]WDA.ServiceProviders.Update.11.dll"
TlbPath="[INSTALLLOCATION]WDA.ServiceProviders.Update.11.tlb"/>
</Component>
</Directory>
</Directory>
</Directory>
</Directory>
<Feature Id="MainFeature" Title="WixTest" Level="1" Absent="disallow" InstallDefault="local">
<ComponentRef Id="MyComponent" />
</Feature>
</Product>
</Wix>
Cheers,
-Nils
I have the same problem. Ive tried Wix 3.5 and 3.6.2012.0 and it hasnt worked with either. It works if
I use regsvcs first
Delete the component
Run the msi and click on Ignore when a message comes up about the application already existing
Did you manage to find a solution?
First, you might try upgrading to the latest version of WiX v3.5. There were some bug fixes in COM+ at the end. If that doesn't work, take a look at the open bugs around COM+. There are a couple known issues with the installation code due to complexities in COM+.
If any of those bugs sound applicable maybe you can help fix them with the community?

Resources