Community
Participate
Working Groups
Build Identifier: 1.0.0.RELEASE If a bundle has Spring XML configuration located in META-INF/spring and blueprint configuration in OSGI-INF/blueprint (or the location specified by the Bundle-Blueprint manifest header) both the BlueprintLoaderListener and the ContextLoaderListener will proceed in the creation of an ApplicationContext for the bundle, and two ApplicationContexts will be created. This seems like unusual behavior. I would expect either one of the two listeners to "win". Reproducible: Always Steps to Reproduce: 1. Create a minimal blueprint bundle with configuration in META-INF/spring and OSGI-INF/blueprint 2. Set org.eclipse.gemini log level to INFO 3. Add the bundle to an OSGi container with the Gemini extender 4. Monitor the logs for output like the following: INFO ivator.support.BlueprintContainerCreator - Discovered configurations {bundle://74.6:0/OSGI-INF/blueprint/blueprint.xml, bundle://74.6:0/OSGI-INF/blueprint/spring-config.xml} in bundle [Minimal Blueprint Bundle (com.elasticpath.minimal-blueprint-bundle)] INFO ort.DefaultOsgiApplicationContextCreator - Discovered configurations {osgibundle:/META-INF/spring/*.xml} in bundle [Minimal Blueprint Bundle (com.elasticpath.minimal-blueprint-bundle)] 5. Inspect the OSGi services registered by the bundle. There will be two org.eclipse.gemini.blueprint.context.DelegatedExecutionOsgiBundleApplicationContexts
Created attachment 218355 [details] Minimal blueprint bundle exhibiting the problem The attached tar.gz file containing a simple maven bundle project will suffice for step one of the repro steps.
+1
This is a duplicate of https://bugs.eclipse.org/bugs/show_bug.cgi?id=356683 - marking it as closed *** This bug has been marked as a duplicate of bug 356683 ***
Oups, two fast - my mistake, sorry. Its _almost_ the same issue - in this case it affects regular bundles, not the extender fragments. Reopening.
The assumption behind this bug report is that such a scenario is always a mistake. But Spring DM and Blueprint and pretty much orthogonal and I'd say this was working as designed. In some cases it could be precisely what the user intends, e.g. if they are trying to migrate from Spring DM to Blueprint in stages and need to leave a small piece of Spring DM behind because, for example, it uses a custom namespace that Blueprint doesn't support. I guess the difficulty comes when both the Spring DM and Blueprint definitions overlap and construct the same beans and/or publish the same services. We could consider logging a warning in such situations, but who'd notice that more than the symptoms of duplicate construction or service publication. In fact, diagnostics are tricky for extenders since we can't fail the start of the bundle - we can only whine that the bundle isn't the way we'd like it. The draconian alternative of failing to honour such bundles might at least draw the issue to the user's attention, but that wouldn't be acceptable in the odd case where it is intentional. Any other ideas for how to handle this?
In the absence of feedback, closing as working as designed.
Apologies for the late response. I do hope that it is still possible to reopen/discuss this issue. Thanks for the feedback. I recognize that backwards compatibility is important, and that it is also possible that people are relying on this behavior. Is the approach you suggested the currently recommended way to transition from Spring DM to Blueprint? It is already possible to use Spring namespaces inside the Blueprint container (ie. the one started from OSGI-INF/blueprint) without relying on the behavior described in the original bug, and that would seem preferable to having two isolated Spring Application Contexts. As for a solution: I think that logging a warning is an improvement on the current behavior as it is easy to miss the fact that your bundles have been initialized twice when no warning is published. The only way to know that this has happened is to scan the INFO level logs, or do an inspection on the services exported by your bundle. Warnings tend to stand out better. Additionally if this behavior is desirable in some circumstances, maybe this should be something that you can turn on if you need it, but is disabled by default. So I think I would suggest that a deprecation warning be emitted to the logs when this circumstance is discovered, followed by removal of the behavior in a subsequent major release or leaving the capability in, but changing the default behavior.
I had overlooked the possibility of using the Spring DM namespace in the Blueprint container, so the recommended migration technique would be to move XML files from META-INF/spring to OSGI-INF/blueprint and then, more or less gradually, switch to the Blueprint namespace. So I'm sympathetic to the change you suggest as an enhancement. I cannot personally commit resources to implementing it, but perhaps someone else will. Please note that we are discussing the possibility of a 2.0 release in relation to bug 356683, so if anyone watching this bug wants to submit a patch, that would be helpful.
There has not been much activity on this ticket for a while and there seems to be not enough interest to support a patch - I'll treat this as won't fix unless a requirement arises.
