Hi Gary,
thanks for the explanations. Gladly the issue with camel 2.18 did not
require to remove the dynamic import.
I still would like to remove the Dynamic Import but it would require a
lot of work on activemq. I did a similar thing for artemis already. I am
not sure though how well this time would be spent as it seems the
community rather intends to switch to artemis soon.
Christan
On 14.02.2017 11:54, Gary Tully wrote:
my understanding is that it is related to embedding a broker and using
something like the jdbc store that uses a third party driver. The required
package import cannot be known in-advance.
Another scenario would be a custom broker plugin.
In essence, because there are extension points exposed by the broker that
are not osgi services or do not play by the osgi rules.
It is a tradeoff between limiting what is possible with activemq in osgi or
leaving it open to this sort of problem but allowing existing extensions to
work.
With dynamic-import * removed, the embedded broker becomes constrained.
On Mon, 13 Feb 2017 at 10:57 Christian Schneider <[email protected]>
wrote:
I have a problem with the acticemq camel component.
See https://issues.apache.org/jira/browse/AMQ-6597
I think it is related to the use of DynamicImport-Package: * in activemq
osgi.
We had a similar issue before. In the former case activemq or artemis
was searching for extensions and was trying to find them by loading some
interface class using the bundles classloader. The problem is when doing
this in a bundle that has Dynamic Import it will bind to that package at
runtime. So it will be linked to the bundle offering the package which
casues problems when refreshing bundles.
In any case I found at that time that DynamicImport-Package causes big
problems. So do we really need this? What is it used for?
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
