Okay, I've managed to get Roller running okay in Websphere 6 (hurrah!), so I thought I'd post to the list about it so it's in the archives next time someone needs to do it.
Firstly, forget about running it in Websphere 5.x. The application refuses to start; it starts okay if you remove the roller-web.jar, but that's not a very good workaround ;-) Based on Jeff Chilton's experiences with Roller 0.9.9.2 on Websphere 5 back in October 2004 (described in some articles in WebSpherePower magazine) my suspicions are that it's something to do with the listeners, but I haven't verified that. Actually, to be fair to IBM, I haven't been able to try it in a fully patched and latest 5.x installation either, only in out-of-the-box 5.0 and 5.1.0, so I suppose there's always a chance it was a Websphere issue that's been fixed in a later fix pack. But by the time I got that far, I'd got myself a 6.0 to play around with so I just started over with that. I'll skip over the actual installation of the app into WebSphere and setting up the database server resource; if you've deployed any other app into WebSphere before you should be able to manage this. The first problem I hit once it was installed was VerifyError messages telling me that the HibernatePersistenceStrategy(String, String) constructor was being passed an incompatile argument; tracing in the debugger confirmed it was being passed two strings, however. I'm still not entirely sure what the problem was here, but switching the classloader order from PARENT_FIRST to PARENT_LAST fixed it. Next the RollerContext failed to initialize due to a ClassCastException on com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource. This was due to jdbc2_0-stdext.jar being present in WEB-INF/lib, conflicting with the app server's own copy of the javax.sql.* classes; it no longer thought the database resource was a DataSource... So I deleted that jar. Along with those messages, I was seeing a LinkageError in Struts' ActionServlet.initServlet() method: "Class org/xml/sax/SAXParseException violates loader constraints: definition mismatch between parent and child loaders" This was because xmlrpc-1.2-b1.jar includes the SAX 1.0 API classes, and JDK 1.4 includes SAX 2.0. So I extracted the contents of that jar, deleted the org/xml/sax directory and rebuilt the jar without it. Why they didn't keep them in a separate jar, I don't know. Sheesh. The application then started up okay, but trying to access http://localhost:9080/blogs produced the error SRVE0232E: Internal Server Error. Exception Message: [Filter [RequestMappingFilter]: filter is unavailable.] due to a "StringIndexOutOfBoundsException: String index out of range: -1" in org.apache.roller.ui.rendering.WeblogRequestMapper.handleRequest (WeblogRequestMapper.java line 115) Since the line mentioned in the stack trace was // strip off the leading slash servlet = servlet.substring(1); I tried adding a slash to the URL, but http://localhost:9080/roller/ just returned Roller's 404 page. http://localhost:9080/roller/index.jsp did give the initial "Welcome to Roller!" page, but with only the bare text and no styling. At this point I realised that at some point while messing with various settings I must have unticked the "File serving" checkbox in the web app deployment descriptor editor; after ticking that, it all started working as expected. Doh! After that, everything went more or less okay (well, asides from the odd application bug that I've raised in JIRA) until I tried to edit the server settings; then I got a NoClassDefFoundError for org/w3c/dom/TypeInfo thrown by /WEB-INF/jsps/admin/rollerProperties.jsp This is because TypeInfo is new to DOM3/JAXP 1.3, and JDK 1.4 only includes JAXP 1.2. That brings me back to a question I asked previously as to whether or not Roller really needs to be using Xalan 2.7.0 (which is JAXP 1.3) or if an earlier version would do, however, with no answer from the developers (yet?) on that one I assumed it did, and fixed it another way. I noticed that only the xalan.jar from its 2.7.0 distribution was included in Roller, so I added the rest of the jars from xalan's binaries download (serializer.jar, xercesImpl.jar and xml-apis.jar). Those include a bundled copy of xerces 2.7.1 and JAXP 1.3, and after restarting again the TypeInfo errors went away. Since then I've been using it without any further errors showing up, so hopefully that's it (though I haven't tried out every feature yet, so I'll keep my fingers crossed for luck). :-) To finish, a couple of questions/suggestions for the developers: What JDK is the minimum requirement for the current version of Roller? I haven't noticed anything definitive on the web site; the closest I've found is that the Installation Guide says it "describes how to install Roller in the following environment ... Java 2 SE 1.4 SDK (or later)". While that could be interpreted as saying that's the minimum supported version, it doesn't exactly state that to be the case. However, assuming that JDK 1.4 or later is now a requirement, why are the SAX 1 and JDBC 2 extension classes then included in the web application when they are included in the JDK? That's just asking for classloader-related problems on any app server, not just Websphere. Arguably, the SAX 1 classes are the xmlrpc developers' fault, but perhaps you could take that up with them? Similarly, what version of Xalan do you actually require? If it is 2.7.0 (say, because you use the new XPath or DOM3 stuff), then the fact that it ships with Xerces 2.7.1 suggests to me that they need that version or later (and certainly not crimson, 1.4.2's default parser). Granted Tomcat 5.5.17 includes a later version, but you can't rely on that - 5.5.9 only included Xerces 2.6.2, for example, and other app servers could include anything (WAS has some IBM fork!) Safest option IMO is to include the whole set of jars, or at least mention the dependency in the installation guide so people can make sure it's met. Also, something Denis said prompted me to check the Roller jars. Both roller-web.jar and roller-business.jar contain a copy of the classes from the org.apache.roller.util.rome package, and org.apache.roller.ui.core.plugins.WeblogEntryEditor. To avoid the possibility of any other classloader "funnies", it would probably be better to only have one copy of those classes in the classpath. Andrew. -- http://pseudoq.sourceforge.net/ Open source java Sudoku application --Forwarded Message Attachment-- Date: Fri, 13 Jul 2007 18:41:22 -0400 From: [EMAIL PROTECTED] >> java.lang.VerifyError: arguments are not type compatible (class: >>org/apache/roller/business/hibernate/HibernatePersistenceStrategy method: (Ljava/lang/String;Ljava/lang/String;)V) >>at pc: 223 I've already seen this happen using Tomcat a while ago while working on the Spring version. It's not related to WAS, but it's definitely a classloading order problem. However I'm surprised it shows in Roller 3.1, so the following may not be relevant: The problem happened because I had multiple versions of the *Impl classes in various roller JAR on my classpath (in Planet and in Roller JARs), using both Planet and Roller in the same app. Basically, there was 2 HibernatePersistenceStrategy on the same package with different constructors, in the classpath. However, this came while code was moved around in the 4.0 trunk and a lot of classes got duplicated and slightly modified (last version I worked with was 54893 so it's quite old if you're looking at today's trunk) so that's why I'm surprised it'd show in previous versions (can't be sure about this). The way I got the problem nailed down was to deploy a flat build (with classes in WEB-INF/classes), without any Roller/Planet JAR files in WEB-INF/lib. Also deleting the org.apache.*.planet related classes to chase down the offending one. If this does fix it, there's definitely a mismatch between the planet source and the one in the roller source and the planet one maybe looked up before the roller one is by the classloader. Note that this cannot be worked around by changing the classloading policy on WAS (PARENT_FIRST / PARENT_LAST) since all the involved classes belong to the same webapp. I don't remember what part of my build I had to fix, however I do know that I had to totally remove /tools//roller*.jar before doing a clean build because they were used in the classpath to build either planet or roller. I modified the build so it doesn't build those files as it was creating unseen cyclic dependencies with old code. But again, that was a relatively old build I was tinkering with so that may not solve the problem. Still hope this helps. As for this: > [11/07/07 19:23:34:448 BST] 000000b9 RollerContext E org.apache.roller.ui.core.RollerContext contextInitialized > RollerContext initialization failed > java.lang.ClassCastException: com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource > at org.apache.roller.ui.core.RollerContext.upgradeDatabaseIfNeeded(RollerContext.java:374) > at org.apache.roller.ui.core.RollerContext.contextInitialized(RollerContext.java:168) > at com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1434) > at com.ibm.ws.webcontainer.webapp.WebApp.initialize(WebApp.java:411) > . Make sure you don't have any JDBC driver JAR in Roller's WEB-INF/lib such as "classes12.zip" from Oracle (see http://www.ibm.com/developerworks/forums/dw_thread.jsp?message=13756392&cat=9&thread=95695&treeDisplayType=threadmode1&forum=267#13756392). And about adding drivers to the WAS server classpath, and more generally to share JAR among applications in WAS, I recommend using a shared library reference with your EAR and strongly discourage from adding custom JAR files to the server's internal LIB directory, which is also probably unsupported by IBM in case you have support contracts with them. 2 more cents (in CAD) Andrew Stevens wrote: >> From: [EMAIL PROTECTED] >> Date: Fri, 13 Jul 2007 02:55:03 +0000 >> >> I assume you installed the required hibernate jars as well and placed them >> into the lib directory. > > Yes. > >> I got Roller 3.1 to work however its on Tomcat. I >> had to install Hibernate 3.2 Jar and supporting jars. Be sure to install >> the required database connector libraries inside your Websphere application >> server directory. For example you would need to install a >> mysqlJConnector.jar into your application server's directory if you were >> using Mysql as your database server. > > You mean the driver jar, right? I copied the mysql.jar from another database > app (the java-based DB admin tool I used to run in the database setup > script), set up a new JDBC provider for > com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDatasource using it, and > configured a data source for the roller database. The > roller-custom.properties contains > hibernate.dialect=org.hibernate.dialect.MySQL5Dialect > and I'm pretty sure the database side of things is set up okay, as at one > point while I've been messing with the app settings I saw a banner message > giving the MySQL version etc. > >> I cannot help you with websphere, >> however Roller 3.1 uses Hibernate compatable with all application servers. >> We know that its nothing really wrong with the code. You may also try using >> the roller.properties original file as a start instead of overriding this >> file until you get started. Unless you're using a different database >> dialect then you'll have to change it in order for Hibernate to work >> properly. The original should get you started until you get comfortable >> changing these settings. I didn't have to change these properties. > > The only properties in my custom file are the database dialect and various > *.dir settings for uploads, search index and planet cache. Also I edited the > log4j.properties to have it write the log file in a different location, as I > didn't think "${catalina.base}/logs/roller.log" would be much use in anything > other than Tomcat ;-) > >> Anyway, my 2 cents on it. >> >> Anyway, you'll have to refer to Matt from here on. I only know how to >> install the application. Good luck bud. Roll on... >> >>> From: "Matt Raible" >>> Date: Thu, 12 Jul 2007 14:25:12 -0700 >>> >>> Can you please repost as plain/text - this is difficult to read. > > Yeah, I know. Sorry about that - it's been that way ever since Hotmail > "upgraded" me to their new interface. I don't like HTML mail either, but I > haven't (yet) found a setting to switch it off :-( Stuart, I see you're also > using hotmail - do you know where the setting is? > > Interestingly, on this laptop (which is using an older version of Firefox) it > doesn't display the formatting toolbar, so if I'm lucky that means this > message will be in plain text... Is the text below any more readable, Matt? > >>> On 7/12/07, Andrew Stevens wrote: > > Can anyone help me get Roller 3.1 running on Websphere 6.0?I downloaded > the binary release zip and the extra required jars from java.net, and > unzipped them. I created the database, ran the script to create the > tables and configured the datasource to be mapped to the jdbc/rollerdb > resource > ref. I created an appropriate custom-roller.properties file in > /WEB-INF/classes (specifying log file paths) and re-packaged the web app > as a .war file, which I've deployed into Websphere 6.0. However, when I > start the server/app I get a bunch of exceptions in the log: > > [12/07/07 14:52:26:545 BST] 0000000a HibernateRoll E > org.apache.roller.business.hibernate.HibernateRollerImpl Error initializing > Hibernate > java.lang.VerifyError: (class: > org/apache/roller/business/hibernate/HibernatePersistenceStrategy, method: > signature: > (Ljava/lang/String;Ljava/lang/String;)V) Incompatible argument to method > at > org.apache.roller.business.hibernate.HibernateRollerImpl.(HibernateRollerImpl.java:83) > at > org.apache.roller.business.hibernate.HibernateRollerImpl.instantiate(HibernateRollerImpl.java:101) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) > > atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) > at java.lang.reflect.Method.invoke(Method.java:391) > at > org.apache.roller.business.RollerFactory.getRoller(RollerFactory.java:66) > at > org.apache.roller.ui.core.RollerContext.contextInitialized(RollerContext.java:170) > at > com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1434) > ... > [12/07/07 14:52:26:560 BST] 0000000a RollerFactory E > org.apache.roller.business.RollerFactory getRoller Error instantiating > org.apache.roller.business.hibernate.HibernateRollerImpl > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) > at java.lang.reflect.Method.invoke(Method.java:391) > at > org.apache.roller.business.RollerFactory.getRoller(RollerFactory.java:66) > at > org.apache.roller.ui.core.RollerContext.contextInitialized(RollerContext.java:170) > at > com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1434) > ... > Caused by: org.apache.roller.RollerException > at > org.apache.roller.business.hibernate.HibernateRollerImpl.(HibernateRollerImpl.java:90) > at > org.apache.roller.business.hibernate.HibernateRollerImpl.instantiate(HibernateRollerImpl.java:101) > ... 41 more > [12/07/07 14:52:26:623 BST] 0000000a RollerFactory E > org.apache.roller.business.RollerFactory getRoller > Failed to instantiate fallback roller impl java.lang.Exception: Doh! Couldn't > instantiate a roller class > at > org.apache.roller.business.RollerFactory.getRoller(RollerFactory.java:89) > at > org.apache.roller.ui.core.RollerContext.contextInitialized(RollerContext.java:170) > at > com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1434) > > So I tried stepping through line by line in RAD7's debugger - sure enough, in > the > HibernateRollerImpl constructor it catches the Throwable > > java.lang.VerifyError: arguments are not type compatible (class: > org/apache/roller/business/hibernate/HibernatePersistenceStrategy method: > (Ljava/lang/String;Ljava/lang/String;)V) at pc: 223 > > However, watch expressions for the RollerConfig.getProperty values certainly > look to be > returning strings to me (and at least it confirmed the roller-custom > properties file was being used). So two Strings aren't type compatible > with two Strings... Huh? No wonder the comment in the source says > "// if this happens then we are screwed" :-( > Next I tried changing the classloader > behaviour to "parent last" rather than the default "parent first", in case > it's picking up the wrong version of something from the JRE. But that > just produced a different set of errors: > > [11/07/07 19:23:34:448 BST] 000000b9 RollerContext E > org.apache.roller.ui.core.RollerContext contextInitialized > RollerContext initialization failed > java.lang.ClassCastException: com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource > at > org.apache.roller.ui.core.RollerContext.upgradeDatabaseIfNeeded(RollerContext.java:374) > at > org.apache.roller.ui.core.RollerContext.contextInitialized(RollerContext.java:168) > at > com.ibm.ws.webcontainer.webapp.WebApp.notifyServletContextCreated(WebApp.java:1434) > at com.ibm.ws.webcontainer.webapp.WebApp.initialize(WebApp.java:411) > ... > [11/07/07 19:23:34:526 BST] 000000b9 ServletWrappe E > SRVE0100E: Did not realize init() exception thrown by servlet action: > java.lang.LinkageError: Class org/xml/sax/SAXParseException violates loader > constraints: definition mismatch between parent and child loaders > at > org.apache.struts.action.ActionServlet.initServlet(ActionServlet.java:1079) > at org.apache.struts.action.ActionServlet.init(ActionServlet.java:324) > at javax.servlet.GenericServlet.init(GenericServlet.java:256) > at > com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:310) > > I'm guessing the LinkageError on SAXParseException is due to the > org.xml.sax.*class files being found both in WEB-INF/lib/xmlrpc-1.2-b1.jar > and also in Websphere's $JRE/lib/xml.jar ? Given they're > standard JAXP interfaces and have been included in the JDK since 1.4, > should they really be in the xmlrpc jar anyway? I also noticed the xalan > jar bundled with Roller is version 2.7.0 (according to > org.apache.xalan.Version), while the one included in Websphere's > xml.jar(which I believe is the one it would use for "Parent First" > classloading mode) is "XSLT4J Java 2.6.9". Assuming that's just their own > build of > xalan 2.6.9, is there anything specific to 2.7.0 that Roller requires, or > should it be okay with the earlier version?I had hoped it wouldn't be too > hard to get this working, as they said in Covalent's recent Roller webcast > that "IBM use Roller for their developerWorks blogs, and they run it on > Websphere". However, although the HTTP response headers suggest they're > also using Websphere 6.0 ("Server: IBM_HTTP_Server/6.0.2.13 Apache/2.0.47 > (Unix)"), I notice the roller.js script > (http://www-03.ibm.com/developerworks/blogs/theme/scripts/roller.js) doesn't > include the isblank function > near the end; looking through the different tags in Subversion, that > suggests they may only be running Roller 2.0.2 or earlier, as that's the > latest version of that file which didn't contain that function. I'd > prefer to use the current version than one that's nearly a year and a half > old. Does anybody have any suggestions how I can get 3.1 working? Has > anyone successfully got it installed into Websphere 6? > > > Andrew. > -- > http://pseudoq.sourceforge.net/ Open source java Sudoku application _________________________________________________________________ The next generation of MSN Hotmail has arrived - Windows Live Hotmail http://www.newhotmail.co.uk
