TSSS Day 2 pluggable webapps
Next up is pluggable web apps by jiramike. This is pimping atlassian’s latest foray into open source, this time in the form of a plugin manager thingy for webapps.
This plugin system basically allows you to load in arbitrary jars as plugins. The jar is driven by a descriptor (in the jar), that specifies some versioning info and the main entry point to the module. Interesting for me personally is that internally for epix development, we have come up with pretty much exactly the same mechanism, so I’d say there’s definitely a use for this sort of functionality.
Jiramike then talks through some practical examples. One interesting usage I noted that I hadn’t thought of is the idea of deploying servlets in a module, which would be simple enough to implement via a proxy servlet runner that simply delegates to the plugin’s servlet for a specified url-pattern.
While the premise and functionality all seems very neat and all, there are some rather disturbing issues that show up if you dig a bit deeper. The real issue is that ultimately, the whole thing is a hack. The servlet spec sadly does not really cater for this sort of runtime extensibility. For example, using a custom classloader is highly suspect in webapps, and quite discouraged. Similarly, these modules can’t contain resources like jsp pages, because the spec does not allow for an easy programmatic way of serving up a jsp as a resource. Thus, you’re forced to use moronfodder like velocity for any visual plugins.
Another interesting usecase (well, interesting from a cool hack perspective) is the ability to basically fuck with IoC containers and swap out components with ones more to your liking. While there’s something very disturbing about this, it’s actually a nice implementation of one of the premises of IoC, that nobody cares about the implementations of components, and that as long the contractual obligations are met, you can pretty much slot in any old junk.
I definitely like the premise of having dynamic components within webapps. Any vendor providing a pluggable open system will find a lot of use for this sort of functionality. It’s just a shame that the spec manages to do just enough to make any working form of this nothing more than a clever hack that is crippled in some very critical ways.
Of course, no jiramike talk is complete without pointless selfpimpage. This comes in the form of the last slide, where not only are we told to buy jira and confluence, we’re also told that they’re looking to hire people and that it’s a cool software company to work for.
Still, on the bright side, no other vendor has self promoted in this way so far, so I’ll just chalk this one up to a freak accident. It’s certainly not like Atlassian to pimp themselves in any venue they can now…is it?
In conclusion, mike jirajirajira, jiramike jirajira, confluence jirajira. jira? jira jira, jiraarse! jirajirajiraajijiaaaaaaarfgrfrfira
March 4th, 2005 at 2:03 pm
First post.
Ha ha ha
March 4th, 2005 at 2:14 pm
I’m obviously missing something. Aren’t .WAR files pluggable webapps?
Last time I checked, I could put servlets, .jsp’s, and IOC containers/configurations in a WAR file.
March 4th, 2005 at 2:20 pm
Not too much bile in this post.
March 4th, 2005 at 2:22 pm
The pluggability here is runtime pluggability. E.g. add a new servlet at runtime to your application.
March 4th, 2005 at 2:37 pm
“E.g. add a new servlet at runtime to your application.”
Uh, sure. They could even call it “hot deploy”.
March 5th, 2005 at 4:40 am
Guessing wildly here, but I think the pluggability stuff has to do with having one reasonably complex webapp (i.e. not your average toy webapp) which has support for pluggable functionality. Like, for example, Jira. In such cases it’s bloody difficult to plug stuff in, since there is no way to create WAR’s which depends on one another (e.g: PlugIn A depends on Jira classes, and yet also provides classes for Jira to use). In our stuff, S****n, we had the same need, and I finally broke down and wrote a Tomcat hack that uses the thing in context.xml to do custom classloader hacks. Obviously, it’s a hack. But it works. It allows me to Plug Stuff In without having to have customers put theirs jars into my /lib, which would be a (even more) horribly broken thing to do, not to mention highly unethical and dirty.
But maybe I guessed wrong and Hani’s talking about something completely different. Whenever there’s talk about “plugs” you never know if there’s a triple irony hiding in there.
March 5th, 2005 at 1:03 pm
Thanks, that makes sense. Although it seems to me, if you are supporting that many customers with such diverse needs, you are probably operating in a multi-server environment where you can get away with a reboot without losing availability. Not so with SiteVision?
March 5th, 2005 at 5:42 pm
Sure, some are in a multi-server env. but the majority are not. But that is not really relevant. What you would call “diverse needs” is more or less necessary for all types of customers, not only the “big ones” with clustered setups. In order to cover all cases the hack works wonders, even if it is just that: a hack.