The old OpenQuote JIRA is dead. Long live the OpenQuote JIRA.
I'd been putting off migrating our old JIRA to Atlassian's OneDemand service (which I blogged about a while ago). But now it is done, and it turned out to be a lot simpler than expected.
In principal migrating between instances of JIRA is easy. You simply use the admin functions to export content from one server, and the import it into another. If you have a complex setup there can be more to it, but our setup is simple so that should be all that's necessary. However, our old server was very old. We were running version 3 of JIRA and the OnDemand server is running version 5. You can't import version 3 format exports into version 5.
Thankfully, Atlassian provide very detailed docs on how upgrade between version. Very detailed and very copious docs which rather put me off. But a couple of days ago I found myself with a spare hour or two so I took a punt at it. And in that couple of hours the job was done.
All I needed to do was to create an export from the old server. Install a standalone JIRA 4.0 and import into it. Then immediately export again from that server. This gave me a version 4 export which imported without issues into the OnDemand system.
The URL remains the same: http://openquotecommunity.org/jira, it now redirects to OnDemand. All users have also been migrated. In fact even the site logo and look and feel customisations came across too. Can't be bad.
OpenUnderwriter is an open source, web based, insurance solution created with the intention of removing the barriers traditionally associated with insurance software adoption, including high cost of ownership and slow time to market. This blog covers its ongoing development.
Thursday, 10 January 2013
Wednesday, 2 January 2013
Protocol handlers and JBoss
The last of the fixes necessary to support the quotation portlet are now committed to the 2.0 branch. It'll be nice to be doing some UI again after such a long spell in the darkness, but more on that later.
The two last updates that were needed were support for the product: protocol, and web service access to the configuration methods - to reset configuration, clear the cache etc. Both had the wrinkles wrt the new 2.0 liferay/jboss stack.
The "product:" protocol handler is pretty well essential for any of OpenQuote's product functionality. The system uses it to access all of the product content held in CMS. The old 1.4 product protocol handler left a little to be desired in terms of configurability, so that has also been addressed for 2.0. But the first problem was how to make a protocol handler visible to JBoss.
This turns out to be simple. Kinda. The first thing you need is the protocol handler class itself. In this case that class is com.ail.core.urlhandler.product.Handler. This has to follow the normal standard for protocol handler's in Java - it has to be in a package named after the handler (product in this case), and it must be called Handler, and it must extend URLStreamHandler.
For JBoss to recognise the hander, you have to do three things.
Job done. Product registries can now refer to "product:~/PageFlow/Quotaiton.xml" or whatever, and they will get the content direct from the product tree in CMS.
The other change made to the protocol handler was to paramatise it's configuration. As the location and of the product tree may be moved in CMS (I can't think why anyone would move it, but I don't see why they shouldn't be able to either), and the credentials used to access CMS certainly need to be configurable. These are now configured in the Core's configuration in the ProductURLHandler group.
As before, all of this has been committed into SVN. There is no binary distribution of 2.0 yet, so you will need to build form the source if you want to play.
We'll come back to the addition of web service access to the configuration server next time.
The two last updates that were needed were support for the product: protocol, and web service access to the configuration methods - to reset configuration, clear the cache etc. Both had the wrinkles wrt the new 2.0 liferay/jboss stack.
The "product:" protocol handler is pretty well essential for any of OpenQuote's product functionality. The system uses it to access all of the product content held in CMS. The old 1.4 product protocol handler left a little to be desired in terms of configurability, so that has also been addressed for 2.0. But the first problem was how to make a protocol handler visible to JBoss.
This turns out to be simple. Kinda. The first thing you need is the protocol handler class itself. In this case that class is com.ail.core.urlhandler.product.Handler. This has to follow the normal standard for protocol handler's in Java - it has to be in a package named after the handler (product in this case), and it must be called Handler, and it must extend URLStreamHandler.
For JBoss to recognise the hander, you have to do three things.
- Create a URLFactoryHandler. JBoss will use this class to create instances of your new handler as it needs them. The (very simple) class can be found in com.ail.core.urlhandler.URLFactorHandler, it isn't much more than a switch statement.
- Both the URLFactoryHandler and the product Handler itself are packaged up into the com.ail.core JBoss module, but JBoss won't find them itself. It needs to be told where to look. To that end, add the file META-INF/services/java.net.URLStreamHandlerFactory (no file extension), to the same module. The file just contains one line naming the URLFactoryHandler class.
- Tell JBoss that the module contains URL handlers on the JVM command line. In our case I added the following to <jboss>/bin/standalone.conf (and standalone.conf.bat to accommodate our Windows friends): -Djboss.protocol.handler.modules=com.ail.core
Job done. Product registries can now refer to "product:~/PageFlow/Quotaiton.xml" or whatever, and they will get the content direct from the product tree in CMS.
The other change made to the protocol handler was to paramatise it's configuration. As the location and of the product tree may be moved in CMS (I can't think why anyone would move it, but I don't see why they shouldn't be able to either), and the credentials used to access CMS certainly need to be configurable. These are now configured in the Core's configuration in the ProductURLHandler group.
As before, all of this has been committed into SVN. There is no binary distribution of 2.0 yet, so you will need to build form the source if you want to play.
We'll come back to the addition of web service access to the configuration server next time.
Subscribe to:
Comments (Atom)