uPortal IRC Logs-2010-10-19

[11:25:41 CDT(-0500)] <JoeMoore> Does anyone know why quickstart installation (3.2.4) doesn't render iPad mobile skin for CAS?
[11:26:33 CDT(-0500)] <JoeMoore> I've been working with 3.2 through this release, but this is the first time I've worried about mobile theme for cas. Mobile theme for uPortal is great!
[11:29:18 CDT(-0500)] <JoeMoore> Sorry--I said iPad. I meant iPod touch. I can't believe I did that
[11:30:58 CDT(-0500)] <holdorph> I think Eric Dalquist and Jen Bourey are at the unconference and don't seem to be on IRC much. You might want to ask your question on the list.
[11:31:27 CDT(-0500)] <JoeMoore> Thanks. Will do.
[14:35:28 CDT(-0500)] <Bananobot> Can someone make sense of this stack trace for me? http://pastebin.com/ssB6r6WH
[14:35:40 CDT(-0500)] <Bananobot> The portlet I'm trying to write won't render
[14:38:14 CDT(-0500)] <holdorph> Caused by: java.lang.ClassCastException: org.springframework.web.portlet.DispatcherPortlet cannot be cast to javax.portlet.Portlet
[14:38:27 CDT(-0500)] <holdorph> feels like maybe some missing jars, or jars in wrong places
[14:42:59 CDT(-0500)] <Bananobot> org.springframework.web.portlet seems to be in the right place. Do you think there are missing dependencies?
[14:43:31 CDT(-0500)] <holdorph> class cast exceptions can happen, because class files aren't in the right class loaders.
[14:43:50 CDT(-0500)] <holdorph> so even though the class is "there", because it's in the wrong loader, you can't actually cast to it.
[14:44:25 CDT(-0500)] <holdorph> in this case "javax.portlet.Portlet" should be in the shared class loader
[14:44:54 CDT(-0500)] <holdorph> but if it's ALSO in the web app class loader, then you'll get a problem where it can't cast to the shared version, because it's seeing the webapp version first.
[14:45:24 CDT(-0500)] <holdorph> i'd look at what .jar files you have in your portlet web application, in your deployed tomcat
[14:45:56 CDT(-0500)] <holdorph> and if you have anything like "portlet.jar" or along those lines, it shouldn't be there.
[14:46:11 CDT(-0500)] <holdorph> this is pretty common, if you don't have the right scoping rules on your maven dependencies.
[14:49:10 CDT(-0500)] <Bananobot> I did have a duplicate portlet-api-1.0.jar, but I think I just added that a minute ago in trying to add any dependencies I might have been missing
[14:49:24 CDT(-0500)] <Bananobot> I've removed it and am trying again
[14:49:35 CDT(-0500)] <Bananobot> Still an error
[14:49:49 CDT(-0500)] <holdorph> you shouldn't have ANY portlet api .jars, inside of the webapp
[14:49:57 CDT(-0500)] <holdorph> it should only exist in the tomcat shared loader
[14:57:11 CDT(-0500)] <Bananobot> I've resolved that issue, but now I get the error "Could not retrieve PortletDD for portlet window '79_ctf1_8.ctf1', this usually means the Portlet application is not deployed correctly."
[14:57:31 CDT(-0500)] <Bananobot> I used sudo ant deployPortletApp -DportletApp=/home/dhammond/projects/war/cccexplore-portlet.war
[14:58:21 CDT(-0500)] <holdorph> how did you publish the portlet, did you use an crn-import and .channel file, or did you go through the portlet manager and publish it that way?
[14:58:30 CDT(-0500)] <Bananobot> Gah! It added my portlet-api-1.0.jar back
[14:58:38 CDT(-0500)] <Bananobot> I went through the portlet manager
[14:58:59 CDT(-0500)] <holdorph> make sure your dependency looks something similar to this....
[14:59:01 CDT(-0500)] <Bananobot> But I didn't redo that process later
[14:59:09 CDT(-0500)] <Bananobot> I'm not using maven ATM
[14:59:14 CDT(-0500)] <holdorph> <dependency>
[14:59:14 CDT(-0500)] <holdorph> <groupId>javax.portlet</groupId>
[14:59:14 CDT(-0500)] <holdorph> <artifactId>portlet-api</artifactId>
[14:59:14 CDT(-0500)] <holdorph> <version>1.0</version>
[14:59:14 CDT(-0500)] <holdorph> <type>jar</type>
[14:59:15 CDT(-0500)] <holdorph> <scope>provided</scope>
[14:59:16 CDT(-0500)] <holdorph> </dependency>
[14:59:41 CDT(-0500)] <Bananobot> I'm just including the jars in the WEB-INF/lib directory
[14:59:51 CDT(-0500)] <holdorph> if you're not using maven, then I'm not sure. it's pretty standard for spring portlet projects to use maven.
[15:00:06 CDT(-0500)] <holdorph> yes, but how are you creating the .war file?
[15:00:28 CDT(-0500)] <Bananobot> A deploywar ant task I got from some tutorial.
[15:00:57 CDT(-0500)] <Bananobot> The lib directory is already populated in my project directory
[15:01:14 CDT(-0500)] <Bananobot> Not the best practice, I'm sure. I'm trying to learn this stuff one step at a time
[15:01:21 CDT(-0500)] <holdorph> hmm... I'd convert it to a maven project and get the dependencies with maven.
[15:01:41 CDT(-0500)] <holdorph> otherwise, you'll have to modify your ant task by hand to filter out the files you don't want it to copy
[15:03:32 CDT(-0500)] <Bananobot> But the portlet-api-1.0.jar file isn't in my project directory anymore.
[15:04:34 CDT(-0500)] <Bananobot> And I manually deleted it from the deployed webapp directory. But when I run deploywar and then deploy the portlet app, it's there in the webapp directory again
[15:04:37 CDT(-0500)] <holdorph> i dont know. I have no idea what your ant task to create the war file is doing
[15:05:15 CDT(-0500)]

[15:05:21 CDT(-0500)] <Bananobot> Pretty straightforward.
[15:06:00 CDT(-0500)] <holdorph> jar tf yourwarfilename.war | grep -i portlet
[15:06:08 CDT(-0500)] <holdorph> is the portlet api inside of your .war file ?
[15:06:19 CDT(-0500)] <Bananobot> Yeah, it is
[15:06:23 CDT(-0500)] <holdorph> because I'm pretty sure it's not the deployPortletApp that's adding it
[15:06:39 CDT(-0500)] <Bananobot> So I guess the jar is just being updated rather than recreated from scratch
[15:06:42 CDT(-0500)] <Bananobot> Er, the war
[15:06:49 CDT(-0500)] <holdorph> so you need to make sure it doesn't make it into your .war file.
[15:08:10 CDT(-0500)] <Bananobot> Deleting the war and rerunning deploywar worked
[15:16:46 CDT(-0500)] <Bananobot> Apparently, Tomcat's portlet-api-1.0.jar doesn't contain javax.portlet.MimeResponse. That's present in com.springsource.javax.portlet-2.0.0.jar, which is not in Tomcat's shared directory. Should I replace Tomcat's jar with this one, or what?
[15:17:33 CDT(-0500)] <holdorph> portlet 2.0? uportal doesn't yet support the portlet 2.0 (jsr 286) spec
[15:17:47 CDT(-0500)] <holdorph> which version of spring are you using? which version of uPortal are you running against?
[15:18:09 CDT(-0500)] <Bananobot> I grabbed the latest versions of uPortal and Spring at the time. I'm now on uPortal 3.2.4.
[15:18:44 CDT(-0500)] <Bananobot> com.springsource.javax.portlet-2.0.0.jar was included in Spring's dependencies
[15:18:56 CDT(-0500)] <holdorph> which version of spring?
[15:19:10 CDT(-0500)] <Bananobot> 3.0.2
[15:19:17 CDT(-0500)] <holdorph> spring 3.0.x will not work with uPortal 3.2.x
[15:19:24 CDT(-0500)] <Bananobot> :/
[15:19:40 CDT(-0500)] <holdorph> spring 3 portlet support, requires jsr 286 support
[15:19:54 CDT(-0500)] <holdorph> they (spring) did a poor job with backward compatability there
[15:26:17 CDT(-0500)] <Bananobot> "ERROR [http-8080-4] Oct/19 20:25:35,438 portal.ExceptionHelper.[] - Programming error"
[15:26:30 CDT(-0500)] <Bananobot> It's a much shorter stack trace than before
[15:26:52 CDT(-0500)] <Bananobot> http://pastebin.com/ML9mSReu
[15:27:48 CDT(-0500)] <Bananobot> This is using Spring 2.5.6.SEC02.
[15:29:51 CDT(-0500)] <holdorph> there's not enough there to go on. at least from that little bit, I have no ideas.
[15:30:41 CDT(-0500)] <Bananobot> When I try to add it to the page (as opposed to just viewing it directly), I get a bigger stack trace
[15:31:16 CDT(-0500)] <Bananobot> http://pastebin.com/HAu612cB
[15:31:57 CDT(-0500)] <holdorph> #
[15:31:57 CDT(-0500)] <holdorph> Caused by: java.lang.NoClassDefFoundError: javax/servlet/jsp/jstl/core/Config
[15:32:14 CDT(-0500)] <Bananobot> Crap, is that another duplicate definition thing?
[15:32:16 CDT(-0500)] <holdorph> sounds like you're missing the jstl.jar and/or standard.jar
[15:40:43 CDT(-0500)] <Bananobot> OMG!!
[15:40:51 CDT(-0500)] <Bananobot> "This is a test. Falalala." It works!
[15:43:47 CDT(-0500)] <holdorph>