So, https://sling.apache.org/documentation/bundles/configuration-installer-factory.html tells us that the currently recommended way to configure OSGi components is to use .cfg.json files. However, it notes that those are only supported “[…] since Installer Configuration Factory 1.2.0”.
So now I’d like to know:
How do I figure out which version of “Installer Configuration Factory” my AEM uses?
Which version of AEM comes preinstalled with Installer Configuration Factory ≥ 1.2.0?
If I’m on an older version of AEM, how do I upgrade Installer Configuration Factory?
I couldn’t find definite answers on any of these. But Adobe does sometimes also recommend using .cfg.json config files but only in articles about AaaCS. Is this only supported on AaaCS?
Sorry for my snarky tone but the lack of reliable, concise documentation is infuriating…
How do I figure out which version of “Installer Configuration Factory” my AEM uses?
goto /system/console/bundles
search for Apache Sling Installer Configuration Admin Support
This gives you the bundle you are looking for
The number as marked in screenshot is the version used by your AEM.
Which version of AEM comes preinstalled with Installer Configuration Factory ≥ 1.2.0?
I am on AEM 6.5.6 and the screenshot above is from the same instance. It exports out 1.1.2. The only version above this is 6.5.7, not sure if it has been upgraded to 1.2.0 as you need
If I’m on an older version of AEM, how do I upgrade Installer Configuration Factory?
You can build the bundle or download the already available one and install. However if there is any hard dependency on the existing version, your instance may corrupt. In order to avoid that, you may need to evaluate what all bundles are dependent on the existing version of configuration bundle and see if you can upgrade them all.
Short cut is to create a vanilla instance and deploy the configuration bundle exporting 1.2.0 version of configuration and test if instance comes up and number of active bundles is same and the ones before you upgraded configurations bundle.
Related
And I have installed AEM 6.2 my local setup Then Created a new project using maven archetype. When I try to edit the site content of my page It gives This error.
Then I found the issue was not installed com.adobe.cq.core.wcm.components.core bundle in AEM.
When I open the bundle it shows description as A set of standardized components for AEM 6.3+ that can be used to speed up development of websites. And it contains a couple of issues.
Then I try to start that bundle It didn't work. I need to know what should be the issue with setup
Newer maven archetypes support the latest versions. If you do not have a requirement for core components and really want to use the maven archetype for AEM 6.2, then you can try to generate your project in batch mode using archetypeVersion as 11 and set the aemVersion to 6.2.0
Our project is planning to upgrade storm from 0.10.0 to 1.0.2.
Between these versions, storm has changed all package-names from backtype to org.apache
Now we use a couple of 3rd party storm dependencies like storm-jms, https://github.com/HolmesNL/kafka-spout etc.
Some of these projects have plans to upgrade soon to 1.0.2 but some do not have it on their roadmap.
So when we upgrade the storm-version in pom.xml, all those 3rd party dependencies begin to cause compilation errors as they do not find backtype.* packages anymore.
What is the best strategy to proceed in such a case?
Is there a maven-trick published somewhere to change the package names automatically?
In your pom, you can add class relocation (https://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html)
The patterns, that you have to use, are in following class -
https://github.com/apache/storm/blob/master/storm-rename-hack/src/main/java/org/apache/storm/hack/StormShadeRequest.java
From Storm web page (https://storm.apache.org/releases/1.0.0/index.html):
NOTE
In the latest version, the class packages have been changed from "backtype.storm" to "org.apache.storm" so the topology code compiled with older version won't run on the Storm 1.0.0 just like that. Backward compatibility is available through following configuration
client.jartransformer.class: "org.apache.storm.hack.StormShadeTransformer"
You need to add the above config in storm installation if you want to run the code compiled with older versions of storm. The config should be added in the machine you use to submit your topologies.
Refer to https://issues.apache.org/jira/browse/STORM-1202 for more details.
I am looking for a way to ensure that all the features I deploy in Karaf require dependencies that are of the same version. The project is composed of more than 40 bundles which makes it difficult to verify manually.
I am thinking of developping a Maven plug-in that would make the check, but before I would like to be sure that such a solution do not exist yet.
If you want to be sure you use the same versions then create a parent project and define versions of dependencies only there. So you can be sure all your modules have the same dependencies. Of course this only makes sense if all these modules are very closely related (e.g. belong to the same application / release unit).
Why would you even want to do this? Each bundle should depend on the versions of the package it needs, and that dependency should be a range. So if you compile against and API package version 1.0.0, and you are a consumer of that API, then you should import with the range [1.0.0, 2.0.0). Refer to the OSGi Core Release 5 specification, section 3.7.3 ("Semantic Versioning") for details.
At runtime the OSGi Framework will ensure that your bundle is wired to a package version that is within its permitted range. Obviously if you have non-overlapping version ranges from different importers then the Framework will not be able to satisfy them with a single exporter.
I have a bundle (jersey-server) that imports a package (org.objectweb.asm) with a resolution of optional and no version specified:
org.objectweb.asm;resolution:=optional
Currently, our application is deployed to Apache Karaf (using the Equinox framework), which exports a new version of this package (org.objectweb.asm), namely version 4.0. The problem I am attempting to solve is that since the jersey-server bundle does not specify a version for the package it is wiring to 4.0. However, the version of jersey-server I am using (1.12) is incompatible with this version. I have a 3.1 version of the package available in the container that I need the jersey-server bundle to wire to.
I have attempted to use a fragment to suit my needs, but it does not appear to be working. I don't fully understand how fragment import-package conflict resolution works in Equinox (or Felix) to know if what I'm trying to do is even possible. Perhaps there is another way?
No, fragments are additive only. I.e. they can add extra imports to their host bundles, but they cannot replace or remove the imports of the host.
The jersey-server bundle is simply broken and must be fixed.
I had a similar issue with pax-web, I created a "workaround" for it:
https://github.com/ops4j/org.ops4j.pax.web/tree/master/pax-web-features/xbean-fragment
it's available also through maven:
http://search.maven.org/#artifactdetails%7Corg.ops4j.pax.web%7Cxbean-fragment%7C3.0.0.M2%7Cbundle
I have tried to use the lastest version of magento connector on mule 3.2. However I keep getting this error:
SAXParseException: cos-all-limited.1.2: An all model group must appear in a particle with {min occurs} = {max occurs} = 1, and that particle must be part of a pair which constitutes the {content type} of a complex type definition.
I have googled it and I think the problem is a bug in mule's devkit. And I am getting it because the magento connector is built using the devkit. The bug apparently has been fixed according to this link:
https://github.com/mulesoft/mule-devkit/issues/10
Where can I download the fixed version of the devkit? and how do I install it in mule 3.2?
Cheers
Leo
This bug have been fixed indeed. If the Magento connector you're using has been compiled with a recent DevKit, things should be fine. Where did you get the Magento connector you're using? Have you tried building a fresh one from source?
DevKit can be found in MuleSoft Maven releases repository: https://repository.mulesoft.org/nexus/content/repositories/releases/org/mule/tools/devkit
This said, you do not need to install DevKit it in Mule per se. DevKit is primarily used at compile time as a code generator for modules (like the Magento one). It may bring runtime dependencies but they'll be packaged with the module distribution archive (alongside the module Jar itself).