I am facing the following issue: I am developing an OSGi bundle with Spring and I would like to allow the developers who will use my bundle to add a Spring context file through a fragment.
These files will be use to configure my Spring beans (a similar existing example without Spring: configuration file in a fragment for org.apache.log4j).
I have to use the Spring framework for several reasons that are out of the scope of this question, but I can't use the following directive
<import resource="..."/>
because I am not even sure that some fragment will be available at run time (it being optional configuration), and I know that Spring will complain if it is unable to find the resource. Ideally, I would like to have something like this:
<import resource="my_default_configuration.xml"/>
<import resource="my_extended_configuration.xml"
doesNotComplainIfAbsent="true"
override="true"/>
Do you have any ideas to help me?
Thanks in advance.
I think using OSGi properly would be a better way of doing it. Spring DM (AKA Gemini Blueprint) allows you to import and export Spring beans via OSGi. So your bundle could attempt to import all beans matching a specific interface, which developers using your bundle would export from their own bundle. It would still be optional, because you would end up with an empty list in your bundle if the developer chose not to provide any.
Related
I am creating a library using spring-boot (v2.1.6.RELEASE) as a starter project that will facilitate as base extension jar responsible for configuring and starting up some of the components based on client project properties file.
The issue I am facing is that if the client project's SpringBoot Application class contains the same package path as library everything works like charm! but when client project contains different package path and includes ComponentScan, it is not able to load or start components from the library.
Did anyone encounter this issue? how to make client application to auto-configure some of the components from library jar?
Note: I am following the library creation example from here: https://www.baeldung.com/spring-boot-custom-starter
There are many things that can go wrong here, without seeing relevant parts of actual code its hard to tell something concrete. Out of my head, here are a couple of points for consideration that can hopefully lead to the solution:
Since we use starters in our applications (and sometimes people use explicit component scanning in there spring applications) and this obviously works, probably the issue is with the starter module itself. Don't think that the fact that the component scan is used alone prevents the starter from being loaded ;)
Make sure the starter is a: regular library and not packaged as a spring boot application (read you don't use spring boot plugin) and have <packaging>jar</packaging> in your pom.xml or whatever you use to build.
Make sure you have: src/main/resources/META-INF/spring.factories file
(case sensitive and everything)
Make sure that this spring.factories file indeed contains a valid reference on your configuration (java class annotated with #Configuration). If you use component scanning in the same package, it will find and load this configuration even without spring factories, in this case, its just kind of another portion of your code just packaged as a separate jar. So this looks especially "suspicious" to me.
Make sure that #Configuration doesn't have #Conditional-something - maybe this condition is not obeyed and the configuration doesn't start. For debugging purposes maybe you even should remove these #Conditional annotations just to ensure that the Configuration starts. You can also provide some logging inside the #Configuration class, like: "loading my cool library".
It looks, from the source code, that Katharsis-spring module will only work with spring boot.
My question then, is it possible to configure a spring project in xml and load Katharsis without spring boot?
If so, how would you need to configure katharsis in spring xml?
Has anyone done this before and willing to share an example?
Thanks.
Only work with Spring boot? That doesn't seem possible. Just #Import(KatharsisConfigV2.class) on any configuration in your code and it should work.
As for xml config: By design, if it can be done in code it can be done in config.
Try that and let me know how you make out
With version 2.8.1 of katharsis, it is quite a challege to get this configured just in xml. So I looked at the master branch of the project and found that there are going to be some new features which will make it easier to configure with spring xml. I have created a sample project here you can use as reference for configuration:
Sample Spring/Katharsis Project with XML configuration
In the sample project I added the SpringServiceDiscovery class, and modified the KatharsisBoot class to make the configuration easier. With the next release of this project, I should be able to remove these 2 classes completely, and use the classes that come with katharsis.
The beans I needed to add to my root-context.xml file were the following:
io.katharsis.spring.KatharsisFilterV2
io.katharsis.spring.ErrorHandlerFilter
com.springkatharsisxml.katharsis.boot.KatharsisBoot
io.katharsis.queryParams.QueryParamsBuilder
io.katharsis.resource.registry.ConstantServiceUrlProvider
io.katharsis.queryParams.DefaultQueryParamsParser
io.katharsis.module.CoreModule
io.katharsis.resource.field.ResourceFieldNameTransformer
io.katharsis.spring.boot.KatharsisSpringBootProperties
I also needed to expose the jackson objectMapper bean, as it's not done so by default in xml.
I also used the org.springframework.web.filter.DelegatingFilterProxy for the katharsisFilter and errorHandlerFilter.
We run Restlet 2.1 in an OSGi environment (Equinox) as bundle (ie. not as library within a bundle). The problem is that the Restlet Engine does not detect helpers (like converters) that are provided by Restlet extensions. Specifically, the EngineClassLoader#getResources() call does not return any result. The extensions are also deployed as OSGi bundles in the target platform.
Is automatic converter registration actually supposed to work within OSGi environments?
In fact, Restlet supports such feature thanks to a dedicated activator (see the Activator class in the package org.restlet.engine.internal).
This activator introspects bundles to find out the following things:
servers corresponding to registered servers
servers corresponding to registered clients
authenticators corresponding to registered clients
converters
Be aware that to use this feature, we must use the OSGi edition of Restlet since it's the only that has the MANIFEST file of the org.restlet bundle with the activator class specified. Otherwise you don't have to care about the bundle loading order...
Hope it helps you.
Thierry
Unless the Restlet-bundle explicitly imports the packages that contain the extensions (and I doubt it does, and it shouldn't), it wouldn't be able to load them, because bundles have isolated class-spaces.
A possible solution would be to provide the extensions as fragments attached to the Restlet-bundle. Thus, if you make it use the bundle-classloader (the documentation says this can be done by setting the Engines classloader), it would be able to load classes from the fragments.
Indeed it doesn't quite work for OSGi, as it depends on the ability to see the entire class space.
The way to do this in OSGi would be to use the service registry for the extensions, but that only works for OSGi aware libraries.
There is some help on the way: In the recently released OSGi 5 (Service Loader Mediator) there will be support to 'bridge' META-INF/services (I don't know if Restlet uses those, though) onto OSGi services, so 'legacy' libraries should work well within OSGi.
There is an implementation in Apache Aries called Spi-Fly. I looked at it briefly a while back. It might do the trick for you, it might not.
I have an OSGi bundle (deployed into Karaf 2.2.4) that starts a Camel (2.10.0) context. The Camel context's routebuilder has some xquery endpoint URIs such as
"xquery:classpath:Dir1/Dir2/example.xq"
When the context tried to resolve that URI, it failed since the Camel bundle is not in the same classpath as where the .xq file resides. So, I created a url expand function that turns
"xquery:classpath:..."
into
"xquery:bundle://42.0:6/..."
since I had dealt with bundle URIs and the OsgiBundleResourcePatternResolver earlier in my project when dealing with a ClassPathScanningCandidateComponentProvider (Spring 3.1.1). Unfortunately, I can't seem to find a way to make Camel's XQueryComponent use my OsgiBundleResourcePatternResolver.
Am I going about this the right way? Is there an easier way to do this?
If I am, how can I make sure the XQueryComponent can understand a bundle: URI?
Also, is it possible for me to make sure any camel component can understand a bundle: URI?
You application that has the Camel route with the above xquery endpoint, would need to import the package where the xq file is located, eg the package that represents "Dir1.Dir2".
So in the META-INF/MANIFEST.MF which has the OSGi imports|exports. You should have an import for that given package.
And to answer your 3 bullets
No, see above
You would need to extend this component and add your own logic for the "bundle"
No, not really, as you would need to add logic to camel-core/camel-core-osgi.
Also the bundle id of an application can change, so its not advised to refer to a bundle by its id. And you cannot assign the bundle id, that is self assigned by the osgi container.
Thanks to Claus' answer, I was able to realize that my .xq file was not in the right directory in its .jar.
Dir1 resided in root of its .jar file. While running the application in a non-OSGi web container worked fine, Karaf appears to be more strict regarding where resources should be in my .war file. I moved the .xq files to WEB-INF/classes/Dir1/... and now am no longer receiving FileNotFoundExceptions when the code uses xquery:classpath:Dir1/Dir2/example.xq
pros! Looks like basic question, but I just can't find what I am looking for.
I have Equinox and want to run Spring in it (bootstraped in Servlet).
I can't use dm-server, nor can I use the http-bridge, just plain standalone Equinox.
On the other side, using plugin.xml http registry servlet extension is not good enough, since I need the fully-blown web.xml in order to bootstrap Spring.
Where should I dig?
Thanks!
Baruch.
To support "traditional" (aka legacy) web.xml file for webapp deployment you need an implementation of the OSGi Web Applications spec, part of the OSGi R4.2 Enterprise spec. This will allow you to deploy "Web Application Bundles" (WABs) or even plain old WAR files.
There are implementations of this container in both the Eclipse Gemini and Apache Aries projects. Note that the one found in Eclipse Gemini is also found in Eclipse Virgo (the new name for dm Server). You may find that using Virgo will give you a cleaner out-of-the-box experience rather than having to assemble components yourself. Then again I fully understand if it also provides an awful lot more than you really want!
An alternative to this is to move away from web.xml and to register servlets programmatically with the OSGi HttpService. This should be a lot more lightweight, but I don't know whether it will work for "bootstrapping Spring" — quite a vague requirement.
Or you can use the tomcat OSGi bundle that will make you to be able to load bundles as war files. The problem there is that your web bundle's name must end with ".war" and all that stands before that suffix is the application name. So if your bundle's name is myapp.war you connect to it with http://your.server.cc/myapp (and as far as i know there's no way to change that)