I read somewhere (I think it was in a post to THIS forum rather than the AEM docs) that we can't create an OSGi bundle that exports packages that are already exported by bundles provided as standard with the AEM run-time even if they are different versions.
Now clearly that is not an OSGi constraint since that's one of the key features of OSGi implementations, so I wonder whether it is an AEM specific restriction ?
A while back I created a bundle that exported later version (1.7.5) of SLF4J packages (the one supplied with AEM is 1.6.4). Whilst that bundle did start successfully, thereafter I had a number of problems, which, once I removed that bundle cleared up. It was about that time I came across the statement about AEM only allowing one version of a package to be exported, so since then I haven't attempted to update other packages than those shipped with the product.
Obviously I'd like someone (from Adobe or otherwise) to completely refute that statement (if I come across it again I'll post it here) and confirm that the OSGI implementation is completely standard and not in any way constrained ???
Kind regards
Fraser.
Solved! Go to Solution.
Views
Replies
Total Likes
Hi Fraser,
You'll have to provide a pointer to a specific statement if you want it refuted The statement that you can't create an OSGi bundle which exports packages which are already exported by bundles provided as standard with the AME runtime is demonstratbly not true.
What I suspect you are referring to is that the OSGi Installer as well as the OSGi Web Console will try to update a bundle if one with the same symbolic name is already installed rather than installing the second bundle. This actually has nothing to do with package exports.
There *is* an issue with JSPs (and other scripts) where you cannot control what version of a package is used by JSPs (which is obvious when you think about it as there is no import-package directive for a JSP). This is, however, a generally managable problem.
AEM uses Apache Felix (specific version depends upon the AEM version, but is viewable through the Web Console) which passes the OSGi CTs (see felix.apache.org for specific details on the CTs).
Regards,
Justin
Views
Replies
Total Likes
Hi Fraser,
You'll have to provide a pointer to a specific statement if you want it refuted The statement that you can't create an OSGi bundle which exports packages which are already exported by bundles provided as standard with the AME runtime is demonstratbly not true.
What I suspect you are referring to is that the OSGi Installer as well as the OSGi Web Console will try to update a bundle if one with the same symbolic name is already installed rather than installing the second bundle. This actually has nothing to do with package exports.
There *is* an issue with JSPs (and other scripts) where you cannot control what version of a package is used by JSPs (which is obvious when you think about it as there is no import-package directive for a JSP). This is, however, a generally managable problem.
AEM uses Apache Felix (specific version depends upon the AEM version, but is viewable through the Web Console) which passes the OSGi CTs (see felix.apache.org for specific details on the CTs).
Regards,
Justin
Views
Replies
Total Likes
Fraser-
In your message, you quote Sham as saying:
"The OSGi spec allows it & Our JCR Installer and the Web Console don't support this as we discourage deploying multiple version of same bundle. Hence it is not possible OOB"
To be clear, there are two different things:
Sham's comment is about #1. Your question was about #2.
Sham is referring to the same issue I mentioned - the tools we ship and are commonly used to manage OSGi bundles (i.e. the web console and the JCR/OSGi installer) will always try to do an update if a bundle with the same symbolic name is already installed. When Sham writes "hence it is not possible OOB", I believe he means that you have to write your own installer code (which would use the OSGi API) to install bundles if the behavior of the web console and OSGi installer wasn't appropriate for you.
Views
Replies
Total Likes
Thanks Justin. It is as I had expected and hoped.
I'll return to the work I was doing earlier where this issue cropped up and try again (it wasn't that urgent at the time - still isn't but its been nagging at me for a while so now is a good time to 'put it to bed').
I post again on this thread if I encounter anything unexpected (and if I locate that spurious post) ;-)
Regards
Fraser.
Views
Replies
Total Likes
justin_at_adobe wrote...
Hi Fraser,
You'll have to provide a pointer to a specific statement if you want it refuted The statement that you can't create an OSGi bundle which exports packages which are already exported by bundles provided as standard with the AME runtime is demonstratbly not true.
...
Regards,
Justin
as promised, I said if I found the place where it was suggested that we can't install a bundle which exports a package which is already exported even at a different version ... Well he it is, and it was from another post to this forum ...
Hi,
Does anyone know if it's possible to have two different versions of the same bundle active? Or CQ only allow the last version of the deployed bundle to be active?
For example:
I have 2 bundles: myapp-1.0.0-SNAPSHOT.jar, myapp-1.1.0-SNAPSHOT.jar. Supposing bundle myapp-1.0.0-SNAPSHOT.jar is installed and activated. And i want to install now the last version (myapp-1.1.0-SNAPSHOT.jar). When the last version is installed, the previous version (myapp-1.0.0-SNAPSHOT.jar) is no longer active...so there's my question: its possible to have two different versions of the same bundle active?
Thanks in advance.
David.
Views
Replies
Total Likes
Hi Justin, I am interested to understand the rationale behind the design you have put in place. We were actually looking to use the underlying Felix's capability to manage multiple bundles, but ran into this issue and before we go ahead and write something of our own, i want to understand why it is the way it is? I dont want to code something out there which is against the base principles of the AEM.
Thanks in advance
Kapil
Views
Replies
Total Likes
Hello Justin.
We are working on the same use case where-in we want to have two different bundles of the same code base based on the version information. But AEM always shows just the latest one since we have the same symbolic name. Could you please shed some light why this functionality was taken away since a blank Felix supports this and to that matter osgi specification also mentions this? I would believe that JSP bundle would use Dynamic-Import and so it will get tied to the first bundle which exports the package which is currently being used in my JSP. However If I look at this from Service's perspective, I should be able to get the specific version using getServices method and by applying the filter.
Also can please guide how can we write our own installer and plug this in the framework without breaking anything which CQ supports. we are using 5.6.1 version of CQ.
Views
Replies
Total Likes
Any luck implementing this?
I have tried to update bnd instruction and have a unique symbolic name for the bundle but the install still removes the old bundle.
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Like
Replies
Views
Likes
Replies
The OSGi spec allows it & Our JCR Installer and the Web Console don't support this as we discourage deploying multiple version of same bundle. Hence it is not possible OOB