Using Spring MVC in a plugin?

[Jason Levine]

Has anyone had success creating a Spring MVC-based plugin for the embedded Atlassian Plugin Framework? (Note that this is specific to the embedded framework in your own app; I'm not asking about creating a plugin for Confluence or Jira or any other specific Atlassian product.) I've been struggling to get this done for about three days now, without luck; here's what I've encountered.

(As a note, my current setup is that I have three separate projects: a library project that contains a bunch of domain-related classes, a container project that depends on the library project, embeds the plugin framework, and constructs and starts the plugin container, and then the plugin that also depends on the library project and hopefully builds the Spring MVC-based functionality. The container project is using v2.12.0 of the plugin framework.)

Issues that I've encountered:

1. As soon as I put in my plugin's atlassian-plugin.xml file that the plugin's servlet class is Spring's DispatcherServlet (org.springframework.web.servlet.DispatcherServlet), I get a bunch of class-not-found errors that lead to me having to include two strange dependencies into the plugin container app: Apache Velocity and FreeMarker. I'm definitely not using Velocity or FreeMarker in my views -- note that I haven't done *anything* to even construct my view resolver -- but I can't deploy the plugin without the plugin container depending on these two libraries. (It's also strange to me that the dependencies are introduced at the plugin container level, rather than in the plugin itself, but I've tested this to death -- adding the dependencies to the plugin's project doesn't solve the issue, it's only solved when they're added to the plugin container.)
2. Similarly, three strange dependencies end up being required in the plugin project due to OsgiContainerException missing-requirement errors -- spring-instrument, spring-jdbc, and spring-oxm. I've developed dozens of Spring MVC-based apps over the past half-decade, and haven't ever needed any of these packages; I don't know what's triggering their requirement as dependencies in the plugin in this case. (I assume it's some class-scanning process that happens when the plugin framework starts to try to deploy the plugin, but obviously don't know, and don't know why.)
3. Once I get all of these dependencies taken care of, using the appropriate Spring 3.1.1 libraries as dependencies, I get a whole new kind of error -- an OsgiContainerException complaining about a constraint violation:
   

   Constraint violation for package 'org.springframework.core.io' when resolving module 11.0 between existing import 0.org.springframework.core.io BLAMED ON [[11.0] package; (&(package=org.springframework.core.io)(version>=0.0.0)(version<=0.0.0))] and uses constraint 4.0.org.springframework.core.io BLAMED ON [[11.0] package; (package=com.atlassian.plugin.osgi.bridge.external), [1.0] package; (package=org.springframework.osgi.context), [6.0] package; (&(package=org.springframework.context)(version>=2.5.6)(!(version>=4.0.0)))].  This error usually occurs when your plugin imports a package from another bundle with a specific version constraint and either the bundle providing that package doesn't meet those version constraints, or there is no bundle available that provides the specified package. For more details on how to fix this, see http://confluence.atlassian.com/x/1xy6D

   For the life of me, I can't wrap my head around what that's trying to tell me other than that there are two OSGi instructions with conflicting version constraints, but I can't find where that might be occurring. In my plugin's POM, the only OSGi instruction I include is:

   <instructions>
   	<Import-Package>
   		org.springframework*;version="[3.1.1,3.2)"
   	</Import-Package>
   </instructions>

   I've tried to change that in a million different ways to deconflict, but haven't found anything that succeeds. Likewise, I've tried to turn logging up in a bunch of places to see if I can figure this out, but can't get any real information about where the conflict is originating, or how I might resolve it.

Overall, this has been super-frustrating, so I'm hoping that someone else has crossed this river and has some advice! Specifically, I'd love to know if this is a fool's errand to begin with, whether there's logic to what I see about where the dependencies are needed and why I'm required to include packages I'm definitely not using, and how to perhaps increase logging in a way that helps me debug this moving forward.

Thanks a ton in advance!

[Sebastian Audet]

Just saying, things haven't gotten much better in the latest version of JIRA, there are weird dependency issues which sound very similar - with the exception that I haven't seen any Velocity warnings, only Freemarker ones.

And it sounds like things have gotten worse, not better, since then - I had many problems even getting the entire thing to install, as OSGI dependencies weren't even being brought in (I had to manually install them via felix's web console). Add to that I'm not sure even that all dependencies are being handled properly - I have it half working to the point that I can hit the endpoint, and then it complains about a invalid context support for an xml namespace - and this is with the Spring Framework being split into OSGI and non-OSGI packages.

Unfortunately the truth of the matter is that there are multiple parties making this sort of integration a nightmare - the non-open source, box-in-a-box-in-a-box Atlassian on one hand, with its weird concept of a 'servlet' subsuming the entire Tomcat instance, and the frankenstein mess that SpringSource produced when it broke itself and turned into a fancy website that doesn't do anything and is just a nice front end for the horrible documentation to missing fucntionality.

Its a miracle that the whole thing doesn't just self-immolate and runs at all.

Maybe the folks at Alassian could take a hint and make their stuff more transparent, if not at the code level, then at least at the component level, rather than simply trying to hide it all behind an 'sdk' which is half broken anyways.

[Andrey Larionov]

If you have JIRA source, you could look in sources of embedded-crowd-admin-plugin and use it as a reference. It also build with Spring MVC

[Jason Levine]

I just grabbed the source and took a look, and it's completely inapparent to me what's different. Well, I take that back a little bit: it uses Spring 2.5.6, whereas I was trying with Spring 3.1, but I moved entirely to Spring 2.5.6 and got the exact same results -- all the way down to needing the Velocity and FreeMarker libraries on the plugin container project and the three other Spring libraries on the plugin project itself without any apparent reason.

[Vengeteswaran]

Hi,

Did anyone find the solution for this problem? I also face this problem while changing my project to Spring framework..

[Sachin Jadhav]

Hey Jason,

Did you found any solution to it ? Spring MVC in as JIRA plugin ? Can you help with steps ? Its hard to find solution for the above said problem.

[Joe Clark]

Hey Jason, sorry it took me so long to get to this!

1) Can you post the output of your plugin's {{mvn dependency:tree}}? Perhaps Spring or another dependency is bringing in velocity and freemarker as transitive depdencies or something?

2) going a bit beyond my expertise :) I know the plugin framework does indeed do some package scanning of installed plugins in order to produce a valid OSGi bundle that can be loaded into the running plugin framework. It should produce this dynamically-generated bundle somewhere on disk in the app's temp or data directory. try having a look at this package to see if your plugin's generated bundle is exporting some weird or un-necessary packages?

3) Have you tried removing the version requirement on org.springframework* entirely? Welcome to OSGi Hell :)

The plugin framework should have heaps of debug logging available - if your app has some log4j configuration, try turning com.atlassian.plugins/plugin up to DEBUG.