The OSGi specification defines appropriate bundle manifest headers and mechanisms for the deployment of servlet-based WAR packaged applications into an OSGi container. As with most APIs, programming a modern application using the Servlet specification requires copious amounts of boilerplate code that any number of Web application frameworks can reduce. The Spring MVC framework is among these Web application frameworks. As with many of the capabilities of an OSGi container, the hooks for integrating the WAR with the capabilities of the container, such as OSGi services; modularity; configuration; and class loading, requires programming copious amounts of boilerplate code to OSGi APIs. Unlike the world of Web applications, there are far fewer frameworks for simplifying deployment in an OSGi container. The Spring DM framework is among this small group. This article discusses how to leverage the Spring MVC framework together with the capabilities of Spring DM in order to take full advantage of the value added features of both frameworks. This article uses Apache ServiceMix as the target platform.
The Project and Build Structure
One of the easiest ways to assemble an OSGi ready WAR is to use Maven in conjunction with the WAR and Felix Bundle Plug-ins. The WAR Plug-in allows the build to produce a WAR artifact while the Bundle Plug-in simplifies the creation of the OSGi manifest. The following Maven POM snippet illustrates the key points of the Maven build. The complete POM can be found in the source code repository.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
|
< project xmlns = "http://maven.apache.org/POM/4.0.0" ...>
...
< packaging >war ...
< build >
< plugins >
< plugin >
< groupId >org.apache.maven.plugins < artifactId >maven-war-plugin < configuration >
< packagingExcludes >WEB-INF/lib/*.jar < archive >
< manifestFile >${basedir}/target/bnd/MANIFEST.MF < plugin >
< groupId >org.apache.felix < artifactId >maven-bundle-plugin < version >2.3.5 < executions >
< execution >
< id >bundle-manifest < phase >process-classes < goals >
< goal >manifest < configuration >
< supportedProjectTypes >
< supportedProjectType >war < manifestLocation >target/bnd < instructions >
< Webapp-Context >spring-mvc-smx < Web-ContextPath >spring-mvc-smx < Export-Package >!* < Import-Package >
javax.servlet; version="[2.4.0, 4.0.0)",
javax.servlet.http; version="[2.4.0, 4.0.0)",
javax.servlet.jsp.jstl.core; version="[1.2,2.0)",
javax.servlet.resources; version="[2.4.0, 4.0.0)",
org.apache.taglibs.standard; version="[1.2.0,2)",
org.apache.taglibs.standard.extra.spath; version="[1.2.0,2)",
org.apache.taglibs.standard.functions; version="[1.2.0,2)",
org.apache.taglibs.standard.lang.jstl; version="[1.2.0,2)",
org.apache.taglibs.standard.lang.jstl.parser; version="[1.2.0,2)",
org.apache.taglibs.standard.lang.jstl.test; version="[1.2.0,2)",
org.apache.taglibs.standard.lang.jstl.test.beans; version="[1.2.0,2)",
org.apache.taglibs.standard.lang.support; version="[1.2.0,2)",
org.apache.taglibs.standard.resources; version="[1.2.0,2)",
org.apache.taglibs.standard.tag.common.core; version="[1.2.0,2)",
org.apache.taglibs.standard.tag.common.fmt; version="[1.2.0,2)",
org.apache.taglibs.standard.tag.common.sql; version="[1.2.0,2)",
org.apache.taglibs.standard.tag.common.xml; version="[1.2.0,2)",
org.apache.taglibs.standard.tag.el.core; version="[1.2.0,2)",
org.apache.taglibs.standard.tag.el.fmt; version="[1.2.0,2)",
org.apache.taglibs.standard.tag.el.sql; version="[1.2.0,2)",
org.apache.taglibs.standard.tag.el.xml; version="[1.2.0,2)",
org.apache.taglibs.standard.tag.rt.core; version="[1.2.0,2)",
org.apache.taglibs.standard.tag.rt.fmt; version="[1.2.0,2)",
org.apache.taglibs.standard.tag.rt.sql; version="[1.2.0,2)",
org.apache.taglibs.standard.tag.rt.xml; version="[1.2.0,2)",
org.apache.taglibs.standard.tei; version="[1.2.0,2)",
org.apache.taglibs.standard.tlv; version="[1.2.0,2)",
org.springframework.beans.factory.config,
org.springframework.osgi.web.context.support; version="[1.2,2.0)",
org.springframework.stereotype,
org.springframework.web.bind.annotation,
org.springframework.web.servlet,
org.springframework.web.servlet.view,
*
< Bundle-ClassPath >
WEB-INF/classes,
.
...
|
- Line 4 – This line is the standard way in which you instruct Maven to construct a WAR artifact instead of the default JAR packaging.
- Line 13 – This line instructs the WAR Plug-in to exclude all dependencies from the WAR. The resulting WAR imports all of its dependencies from the OSGi class loader and is therefore significantly smaller than a traditional WAR.
- Line 15 – This line instructs the WAR Plug-in to use an externally generated manifest file instead of the one that is automatically generated by default.
- Line 28 – This line instructs the Felix Bundle Plug-in to generate a manifest file on the file system when the plug-in is executed. Normally, the plug-in injects the manifest directly into the artifact; however, this behavior conflicts with that of the WAR plug-in so we configure this plug-in to write the file to disk and we configure the WAR Plug-in to use the manifest file from the file system.
- Line 34 – This line instructs the Felix Bundle Plug-in to execute for projects with the WAR packaging type. The plug-in will not execute for this type of packaging by default.
- Line 36 – This line indicates where the Felix Bundle Plug-in should write the manifest file. Note that this location aligns with the location that the WAR Plug-in reads the manifest file from.
- Lines 38-39 – These lines provide the context path for the Web application when it is deployed. The context path is the portion of the path preceding the application specific path. In this case, all application URLs will start with http://HOST:PORT/spring-mvc-smx. This property is specified twice in order to support a wider range of PAX Web Extender versions. Web-ContextPath is the official OSGi header while Webapp-Context is the PAX Web Extender specific header supported in earlier versions of PAX Web. PAX Web is the implementation of the WAR related OSGi capabilities that is used in ServiceMix. This library is responsible or connecting the WAR to the underlying OSGi framework as well as publishing the WAR to the OSGi HTTP Service.
- Lines 42-45 – These lines indicate that the OSGi container, through its class loading mechanism, should provide the standard Servlet API classes. Much like standard WAR deployments, the container frequently provides these API classes to the class path.
- Lines 46-69 – These lines indicate that the OSGi container should provide the Apache implementation of the JSTL to the WAR. In this case, we simply import all of the packages that the Apache “standard” JSTL implementation library exports. These package imports are required if your application includes JSPs that leverage the JSTL tags, but may vary if you choose to use a different implementation. Providing these packages from the container instead of WEB-INF/lib means that your WAR size can be reduced and the implementation library can be shared across multiple WARs. As these packages are not directly referenced from compiled code, they are not automatically detected by the plug-in and therefore must be manually specified.
- Line 70-75 – These lines indicate that the OSGi container should provide the necessary Spring MVC classes from the OSGi class loader and not from WEB-INF/lib. As with the Apache JSTL implementation, these packages are not directly referenced from compiled code and are therefore not detected by the Felix Bundle Plug-in. These packages must be imported from the OSGi container to ensure a consistent class space with the Spring DM OsgiBundleXmlWebApplicationContext class.
- Lines 79-81 – These lines indicate that the bundle/WAR class path should also include the contents of specific locations within the WAR. The WEB-INF/classes folder provides the implementation classes for the WAR while the “.” entry is required to enable the PAX Web Extender to locate JSPs within the WAR. Some versions of the PAX Web Extender search for the JSP path using the WAR/bundle class path in lieu of searching the actual bundle/WAR contents. As such, including the root folder of the bundle/WAR on the class path ensures that JSPs can be resolved over a broader range of PAX Web versions.
The project folder structure is as follows:
- /src/main/java – This folder contains the source code for the WAR.
- /src/main/features – This folder contains the source file for the project Karaf Feature Descriptor.
- /src/main/webapp – This folder contains the contents that are copied into the root of the WAR. This folder contains JSPs, web.xml, and the Spring MVC application context file.
Spring MVC In an OSGi World
Spring MVC typically uses an XmlWebApplicationContext instance with the DispatcherServlet. Together, these two classes provide a means to bootstrap a Servlet container aware application context and to wire the Servlet container to the Spring MVC controllers. XmlWebApplicationContext is however, unaware of the OSGi container. For this reason, Spring DM provides an OsgiBundleXmlWebApplicationContext that can be substituted for XmlWebApplicationContext when deploying the WAR in an OSGi container. OsgiBundleXmlWebApplicationContext makes the application context in the WAR aware of the OSGi container and provides access to the capabilities provided by the container as well as the BundleContext of the deployed bundle/WAR. One specifies that the DispatcherServlet should use the OSGi aware version of the application context in the web.xml file of the bundle/WAR. The following web.xml snippet illustrates the relevant configuration. After this small change, the standard features of Spring and Spring MVC, including annotation based controllers and component scanning, are available within the OSGi deployed WAR. The complete web.xml can be found in the source code repository.
|
1
2
3
4
5
6
7
8
9
10
|
…
< servlet >
< servlet-name >spring-mvc-smx < servlet-class >org.springframework.web.servlet.DispatcherServlet < init-param >
< param-name >contextClass < param-value >org.springframework.osgi.web.context.support.OsgiBundleXmlWebApplicationContext …
|
- Lines 5-8 – Illustrate using an init-param for the DispatcherServlet to override the implementation class for the application context used by the servlet.
Tag Libraries in an OSGi World
Normally, tag libraries can be auto-detected from the WEB-INF/lib folder or specified in the web.xml file. As this example does not specify any JAR files from WEB-INF/lib in the Bundle-Classpath manifest header, the tag library implementation must be provided by the OSGi container class loader through a package import. While this approach does not require the tag library implementation to be included in the WAR itself, it does create a small issue with auto-discovery of the .tld files for the tag library. Tag library descriptor files reside in the META-INF folder of the JAR. When this JAR is not in the WEB-INF/lib folder and its packages are instead supplied by OSGi package imports, these files are not detected. The workaround for this limitation is to include the tag library descriptor files directly in the WAR and to reference them from web.xml. The following web.xml snippet illustrates the relevant configuration settings for including the JSTL .tld files from withing the WAR itself. The complete web.xml can be found in the source code repository.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
…
< jsp-config >
< taglib >
< taglib-uri >http://java.sun.com/jstl/core < taglib-location >/WEB-INF/tld/c.tld < taglib >
< taglib-uri >http://java.sun.com/jsp/jstl/fmt < taglib-location >/WEB-INF/tld/fmt.tld < taglib >
< taglib-uri >http://java.sun.com/jsp/jstl/fmt < taglib-location >/WEB-INF/tld/fmt.tld < taglib >
< taglib-uri >http://java.sun.com/jsp/jstl/functions < taglib-location >/WEB-INF/tld/fn.tld < taglib >
< taglib-uri >http://java.sun.com/jsp/jstl/xml < taglib-location >/WEB-INF/tld/x.tld …
|
- Lines 2-23 – These lines provide the location for the TLD files of the JSTL. The files were copied from the implementation JAR that the bundle/WAR imports the JSTL implementation packages from. Alternatively, the JSTL implementation JAR can be included in the WAR and added to the Bundle-Classpath manifest header; however, the bundle/WAR will then need to import the package dependencies from the implementation JAR or also add those dependencies to the Bundle-Classpath manifest header.
Bridging the OSGi WAR Gap
So far this article has discussed how to get Spring MVC to act like Spring MVC in an OSGi deployed WAR. If there were nothing more, the keener reader’s out there would be asking, “why would I go through all this trouble when Servlet container XXX will do just fine?” Don’t worry if you didn’t ask this question, you are already researching this topic and reading a blog. That makes you more keen than not. Because the WAR is using OsgiBundleXmlWebApplicationContext from Spring DM, all of the OSGi goodness that Spring DM brings to Spring is also available to the Spring MVC based applications. Service implementations for Spring MVC controllers can be looked up in the OSGi service registry, configuration options can be managed and updated through the OSGi Configuration Admin service, and previously insurmountable class space collisions can be overcome. The following Spring application context snippet illustrates one of the many convenient integration points that Spring DM can provide to the Web application. More examples of the Spring DM capabilities are available in the Spring DM documentation. The complete context file can be found in the source code repository.
|
1
2
3
4
|
...
< osgi:reference id = "configurationAdmin"
interface = "org.osgi.service.cm.ConfigurationAdmin" />
...
|
- Lines 2-3 – This line illustrates how to retrieve a service from the OSGi registry. In this case, the service is the Configuration Admin service. The controller in the example application uses this service to list all of the configurations available in the OSGi container.
Once available in the application context, the bean can be used just as any other locally defined bean. The following Java snippet illustrates how the bean is injected into a controller and used to render the view. The complete controller source is available in the source repository.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
...
@Controller
@RequestMapping (value = "/")
public class HomeController {
@Autowired
BundleContext bundleContext;
@Autowired
ConfigurationAdmin configurationAdmin;
RequestMapping(method = {RequestMethod.GET})
public ModelAndView home() throws Exception {
ModelAndView mav = new ModelAndView("home");
Bundle[] bundles = bundleContext.getBundles();
mav.addObject("bundles", bundles);
Configuration[] configurations = configurationAdmin.listConfigurations( null );
mav.addObject("configurations", configurations);
return mav;
}
public BundleContext getBundleContext() {
return bundleContext;
}
public void setBundleContext(BundleContext bundleContext) {
this .bundleContext = bundleContext;
}
public ConfigurationAdmin getConfigurationAdmin() {
return configurationAdmin;
}
public void setConfigurationAdmin(ConfigurationAdmin configurationAdmin) {
this .configurationAdmin = configurationAdmin;
}
}
|
- Line 11 – This line declares an instance of the Configuration Admin interface as an instance variable that is set using Spring’s auto-wiring.
- Lines 14-23 – These lines query the Configuration Admin service and add the results to the model for rendering.
Deploying in Apache ServiceMix
In order to deploy a WAR using Spring MVC and the Apache JSTL implementation, several additional OSGi bundles must be provisioned in an out-of-the-box ServiceMix instance. The easiest and most repeatable way to provision these bundles is to use a Karaf feature descriptor to describe the bundles to be provisioned. The following feature descriptor snippet illustrates the additional provisioning activities that are needed. The complete feature descriptor can be found in the source code repository.
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
< features name = "spring-mvc-smx-${project.version}" >
< feature name = "spring-mvc-smx" version = "${project.version}" >
< feature >spring < feature >spring-dm < feature >war < bundle >mvn:${project.groupId}/spring-mvc-smx/${project.version}/war < bundle >mvn:org.springframework.osgi/spring-osgi-web/1.2.0 < bundle >mvn:org.springframework/spring-web/3.0.5.RELEASE < bundle >mvn:org.springframework/spring-webmvc/3.0.5.RELEASE < bundle >mvn:javax.servlet/com.springsource.javax.servlet.jsp.jstl/1.2.0.v20110728 |
- Lines 4-6 – These lines ensure that the core Spring bundles, the core Spring DM bundles, and the PAX Web bundles are provisioned in the container.
- Lines 10-12 – These lines provision the additional Spring DM and Spring MVC bundles required to deploy a WAR using Spring MVC.
- Line 14 – These lines provision the bundle related to the Apache implementation of the JSTL.
Building and Deploying the Example Code
Build Pre-requisites
- Java 1.5+
- Maven 3.0+
- Subversion
Deploy Pre-requisites
- Apache ServiceMix 4.3.0
Building
- Checkout the source code from https://davidvaleri.googlecode.com/svn/projects/examples/spring-mvc-smx/tags/spring-mvc-smx-1.0 using your Subversion client.
- Build the source code by executing the following command from the checkout folder:
mvn clean install
Deploying
- Start Apache ServiceMix 4.3.0
- In the ServiceMix shell, add the feature descriptor for the example application by executing the following command:
features:addurl mvn:valeri.blog.examples/spring-mvc-smx/1.0/xml/features
NOTE: If you did not build the example locally, you will need to add the Maven repository for this blog to the ServiceMix configuration. Edit SERVICEMIX_HOME/etc/org.ops4j.pax.url.mvn.cfg and add http://davidvaleri.googlecode.com/svn/repo/ to the org.ops4j.pax.url.mvn.repositories property.
- Provision the example WAR by executing the following command in the ServiceMix shell:
features:install spring-mvc-smx - Confirm the installation by executing the following command in the ServiceMix shell:
osgi:list - The output should resemble the following:
[ 202] [Active ] [ ] [ ] [ 60] David Valeri's Blog :: Examples :: Spring MVC In ServiceMix (1.0.0) [ 203] [Active ] [ ] [ ] [ 60] spring-osgi-web (1.2.0) [ 204] [Active ] [ ] [ ] [ 60] Spring Web (3.0.5.RELEASE) [ 205] [Active ] [ ] [ ] [ 60] Spring Web Servlet (3.0.5.RELEASE) [ 206] [Active ] [ ] [ ] [ 60] JavaServer Pages (TM) TagLib API and Implementation (1.2.0.v20110728)
- Navigate to http://localhost:8181/spring-mvc-smx/ using the browser of your choice.
- The displayed page contains information retrieved from the OSGi bundle context as well as from an OSGi service retrieved from the OSGi service registry. If you receive an error message or no page is displayed, try refreshing the WAR bundle as it may have loaded before the other newly provisioned bundles. Execute the refresh in the ServiceMix shell using the ID of the bundle with the name “David Valeri’s Blog :: Examples :: Spring MVC In ServiceMix (1.0.0)”. If you still receive an error message, refer to the ServiceMix log files and feel free to post a comment below.
Nice tutorial…. thanks !!!
Hi,
Nice but I’ve somme problems
first I’m using eclipse indigo and M2e plugin
mvn compile dose not run on eclipse :
Warnings :
Description Resource Path Location Type
maven-enforcer-plugin (goal “enforce”) is ignored by m2e. pom.xml/spring-mvc-smx line 5 Maven Project Build Lifecycle Mapping Problem
maven-remote-resources-plugin (goal “process”) is ignored by m2e.pom.xml /spring-mvc-smx line 5 Maven Project Build Lifecycle Mapping Problem
[ERROR] Failed to execute goal org.apache.felix:maven-bundle-plugin:2.3.5:manifest (bundle-manifest) on project spring-mvc-smx: Execution bundle-manifest of goal org.apache.felix:maven-bundle-plugin:2.3.5:manifest failed: An API incompatibility was encountered while executing org.apache.felix:maven-bundle-plugin:2.3.5:manifest: java.lang.NoSuchMethodError: java.lang.String.getBytes(Ljava/nio/charset/Charset;)[B
[ERROR] —————————————————–
[ERROR] realm = plugin>org.apache.felix:maven-bundle-plugin:2.3.5
[ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
no problem in command line for compile and package.
I’m using Servicemix 4.3.0 on MacOS
no pb for deplyng the war.
but blank page on http://localhost:8181/spring-mvc-smx/
I’ve trying telnet localost 8181
GET /spring-mvc-smx/
Problem accessing /spring-mvc-smx/. Reason:
org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.springframework.org/schema/mvc]
Offending resource: URL [bundle://207.0:0/WEB-INF/spring-mvc-smx-servlet.xml]
Caused by:
javax.servlet.UnavailableException: org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.springframework.org/schema/mvc]
Offending resource: URL [bundle://207.0:0/WEB-INF/spring-mvc-smx-servlet.xml]
.. stacktrace ..
Powered by Jetty://
Bye
PS: sorry for my approximative english
Hi
features:install spring-dm
simply load spring feature before installing the war
Bye
Hi
I tried to uninstall and reinstall the war
I found a problem.
during the first install ServiceMix start the war and then the Spring bundles. hence the message “Unable to locate Spring for XML schema namespace NamespaceHandler …”
if I stop and restart the war, no problems.
I’ll try to make two packages. one with only spring. the other with the war.
for the blank page the pb comes from jetty http 413 error on some browsers (no pb with chrome or safari)
thank you A + JYT
The issue with m2e is expected as the example was developed before m2e, or at least before I was using Indigo and m2e, so the required configuration in the POM to make it play well with m2e is missing. It will work with m2Eclipse or you can use the information at http://wiki.eclipse.org/M2E_plugin_execution_not_covered to add the configuration needed to fix the first two issues with m2e. Eclipse should also highlight those plug-ins in the POM and have a quick-fix action to add the configuration to the POM for you. As for the third issue with the bundle plug-in, is Eclipse trying to use Java 1.5?
For the issue with the missing NamespaceHandler, step 7 in the deploy instructions resolves the issue with the bundle loading like you said. It is indeed a bundle loading order. Unfortunately, the Spring NamespaceHandler stuff is outside the scope of OSGi’s usual dependency resolution mechanisms and the container doesn’t know that the WAR bundle can’t be started until after the spring-osgi-web bundle is loaded. Possible solutions are to 1) use two features, one with the Spring bundle in it and the other with the WAR bundle in it, 2) deal with the failure and realize that you may have to restart/refresh the WAR bundle, or 3) (mis)use OSGi start-levels to force the WAR bundle startup to happen after the spring-osgi-web bundle start-up.
For the 413 issue, what is a “pb” and is there any information provided in the logs? It may be an issue in Jetty, pax-web, or your browser may be doing something weird. Have you checked what the browser is actually sending to the server when the 413 occurs?
Hi,
I adapted to work with the POM M2e.
For the error “HTTP 413″ This is a request too large.
on my usual browser I test another development that uses large cookies. the request to the server are as big and cookies are associated with the host are also sent even if it is not the same port. (localhost:80 and localhost:8181)
I have discoveries that a problem with jetty in ServiceMix 4.3.0.
I usually work with version apache-servicemix-4.4.1-fuse-01-06
I adaped to run this tutorial on ServiceMix 4.4.0
I just changed mvn:org.springframework.osgi/spring-osgi-web/1.2.1 with version 1.2.1
for the namespace problem I found a simple solution
I put mvn:${project.groupId}/spring-mvc-smx/${project.version}/war at last position in the file features.xml
now in my dev platform spring-mvc-smx start after all others.
but I think that OSGi Start level is the best solution
Thank for all
A+JYT
PS: sorry “pb” = problem
Nice work and thanks for providing the feedback. I have also noticed that the order of the bundles in the feature descriptor dictates installation order; however, I am not sure if this is an intentional design feature or if it is just a result of how it is currently implemented. Like you said, start level will always work while the behavior of Karaf Features may change in the future.
Good luck with your project!
Hi
the solution to resolve HTTP 413 error (header too large) in jetty comme from
Freeman Fang of FuseSource
1) add org.ops4j.pax.web.config.file=etc/jetty.xml
in etc/org.ops4j.pax.web.cfg file.
2) edit jettty.xml file (create it)
8192
Bye
Is it possible to run ServiceMix 4.x in an app server like JBoss?
My problem is that I am stuck using JBoss 5 and would like to deploy a spring dm app to it.
I’m hoping that I can host servicemix on jboss and take your documented approach from there.
thanks
You will likely need to wait until ServiceMix 5 [1] for additional deployment options.
[1] http://comments.gmane.org/gmane.comp.java.servicemix.user/28794
Do you happen to know of any other relatively painless ways to deploy a spring dm or gemini blueprint app to jboss?
Painless… no.
JBoss does have some support for OSGi these days. You could, in theory, add the Spring DM bundles in there and then they would start your OSGi application when you deploy your application bundles. This is of course pure conjecture since I have never tried it.
If you are stuck on an older JBoss version, you could try starting an OSGi framework inside of a Web application and then configure that framework with Spring DM and your application bundles. Atlassian’s plug-in framework runs as an embedded OSGi framework inside of a Web application so this approach is definitely possible.
Third, if the application is not heavily tied to some OSGi feature, you could port it back to a flat classloader and deploy it using traditional app server packaging.
I got the below error while http://localhost:8181/spring-mvc-smx/
Problem accessing /spring-mvc-smx/. Reason:
org.springframework.beans.PropertyBatchUpdateException; nested PropertyAccessExceptions (1) are:
PropertyAccessException 1: org.springframework.beans.TypeMismatchException: Failed to convert property value of type ‘java.lang.String’ to required type ‘java.lang.Class’ for property ‘contextClass’; nested exception is java.lang.IllegalArgumentException: Cannot find class [org.springframework.osgi.web.context.support.OsgiBundleXmlWebApplicationContext]
Are you using the same version of SMX as the article? If so, do you have the package imports from lines 70-75 in the example POM in your POM? If so, is the bundle from mvn:org.springframework.osgi/spring-osgi-web/1.2.0 installed and resolved correctly in the container?
Check your bundle imports to make sure that the package containing the missing class is imported. If it is, make sure that it is not optional and that it is being resolved.
iam able to run this by using same version of smx as the article says,but when iam trying to run it on another version(4.4.0)iam getting the error as i said
I would guess that it has to do with the version of Spring DM or some other dependency in the mix. I’ll try to take a look some time in the next week to see if anything pops out at me.
See the comment below from David Ovington. Perhaps his solution for 4.4.1 will solve your issue as well.
now iam able to run .
thanks a lot
David Ovington says:
March 16, 2012 at 7:15 pm
Thanks for a great article, saved me a lot of time.
I’ve deployed in the FuseSource build of ServiceMix 4.4.1 (apache-servicemix-4.4.1-fuse-01-13).
There were some extra lines required in the features xml:
<feature>spring-dm-webfeature><bundle>mvn:org.springframework.osgi/spring-osgi-core/1.2.0bundle><bundle>mvn:org.springframework.osgi/spring-osgi-io/1.2.0bundle>So I now have what should be simple request, but I cannot find the answer to… how to load a simple static image in home.jsp ?
A standard tag of:
<imgsrc="image.jpg"alt="some_text"/>fails to load the image, i’ve tried putting it at just about every level in the war with no luck ?
At first I thought the servlet mapping was the problem, so tied the HomeController down to a specific html, and ensured that *.jpg were handled by the default (as below), but with no luck ! any ideas ?
Thanks.
<servlet-mapping><servlet-name>spring-mvc-smx<servlet-name><url-pattern>*.htmlurl-pattern>servlet-mapping><servlet-mapping><servlet-name>default<servlet-name><url-pattern>*.jpgurl-pattern>servlet-mapping>In my case, i receive: org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘configurationAdmin’: Invocation of init method failed; nested exception is java.lang.IllegalArgumentException: Required ‘bundleContext’ property was not set.
I guess it’s a sort of NPE, autowiring doesnt work. I tryed a lot of such examples, results the same. Could anyone give a hand.
Thanks
Great job. Tested on on Karaf 2.3.0.