I agree, Eclipse website SUX

I have to completely agree with Anthony, that the Eclipse website SUX! Make 90% of your use cases simple, and this means put the Eclipse IDE download and help screens on your front page! Realize what your breadwinner is and sell it, don't bury it to make it appear on the same level as your other not-so-popular projects! As a first time visitor, weeding through the the projects is mind-boggling and confusing to say the least.

I have spent a lot of time looking for things on their site myself, and more time helping others that I am teaching Eclipse to. The website makes it hard for me to say "Just go to eclipse.org and download it". Especially when you hit the page and all you see is bureaucratic nonsense about the organization. There is a place for this, but not on the front page!

I am not claiming to be a good web designer, but I do claim to recognize good designs, and my site doesn't host one of the most popular Java projects in existence!

Jetspeed Fusion, Struts, and Weblogic

I've finally fixed Jetspeed 1.6 Fusion (JSR-168 enabled Jetspeed) to work with struts on Weblogic. This required a code change in Jetspeed to get around a Weblogic bug, but it works! The details are in this thread on the apache jetspeed mailing list.

Jetspeed 2 on Weblogic - update again

Now I'm attempting to run jetspeed.war alongside my other wars and ears, while not running it in the same ear as everything else. This saves me from having to explode my ear, if I can get it to work.

So far I've seen that the sample apps can be deployed along side the war, with the small addition that all of these wars MUST have this in the web.xml file:

<servlet>
<servlet-name>JetspeedContainer</servlet-name>
<display-name>Jetspeed Container</display-name>
<description>MVC Servlet for Jetspeed Portlet Applications</description>
<servlet-class>org.apache.jetspeed.container.JetspeedContainerServlet</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>
JetspeedContainer
</servlet-name>
<url-pattern>
/container/*
</url-pattern>
</servlet-mapping>

Some of the sample apps were missing this, and it caused problems. But now I'm a bit farther. Next I need to see if wars inside an ear can be brought up by this external jetspeed.war. Very cool stuff so far! I love it!

Jetspeed 2 on Weblogic - Finally

Wow, it works!

To get past the issue in my last post, I had to add each of the demo wars into my application.xml. This is a side effect of creating the ear to put my wars into.

Also, I found this page that answered my next error, by telling me to put the 5 jetspeed jars into a shared lib, and add this shared lib to my CLASSPATH in the startWebLogic script. I now have most of the portlets working, but I might move my portal outside the ear and give it a try. It seems like the portal should run alongside my ear, but I'm not sure if that will work...

Jetspeed 2 on Weblogic - part 2

Well I have gotten a little farther since my last post. First I found this thread explaining how to get past the "cannot find OJB.properties" issue.

Then I started getting this:
java.lang.RuntimeException: Failed to initialize prefs api. java.lang.InternalError: Can't instantiate Preferences factory java.lang.ClassNotFoundException: org.apache.jetspeed.prefs.impl.PreferencesFactoryImpl
and found this related post which links to a bug report on the sun website detailing the issue. This told me to stop using the jdk that is bundled with weblogic and use the j2sdk1.4.2_03 that is already on my machine.

Well after I pointed to this jdk, I started getting this issue:
Cannot load Implicit TLDs java.lang.ClassNotFoundException: weblogic/apache/xerces/parsers/SAXParser
which I have seen before. But this time I figured out a fix. In the endorsed directory of j2sdk1.4.2_03 I found some sax, xalan, and xerces jars. I deleted those and the sax parser problem went away.

Now I have to figure out why my portlets show this:
javax.portlet.PortletException: Failed to find Servlet context for Portlet Application: /localeselector at org.apache.jetspeed.container.invoker.ServletPortletInvoker.invoke(ServletPortletInvoker.java:184) at org.apache.jetspeed.container.invoker.ServletPortletInvoker.render(ServletPortletInvoker.java:124) at org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:103) at org.apache.jetspeed.container.JetspeedPortletContainerWrapper.renderPortlet(JetspeedPortletContainerWrapper.java:88) at org.apache.jetspeed.aggregator.impl.RenderingJob.run(RenderingJob.java:109) at org.apache.jetspeed.aggregator.impl.Worker.run(Worker.java:142)

Problem Deploying Jetspeed 2 on Weblogic

Here's a quick fix for deploying Jetspeed 2 on Weblogic. First I had to fix a java.net.MalformedURLException. Here's the post on the BEA dev2dev Forums. I just needed to add this to the JAVA_OPTIONS of my startWebLogic script:
-Djava.naming.provider.url=t3://localhost:nnnn
where nnnn is the port configured for this particular WL server.

Next I made a jetspeed.ear folder under applications and exploded jetspeed.war into this. I also added a small application.xml file under jetspeed.ear/META-INF to setup the war module.

Then I copied in these 5 jar files from jetspeed into the root of my ear:
jetspeed-api-2.0-a1-dev.jar
jetspeed-commons-2.0-a1-dev.jar
portals-bridges-common-0.1.jar
portlet-api-1.0.jar
pluto-1.0.1-rc1.jar

Then I added this line to the MANIFEST.MF file under jetspeed.ear/jetspeed.war/META-INF:
Class-Path: jetspeed-api-2.0-a1-dev.jar jetspeed-commons-2.0-a1-dev.jar portals-bridges-common-0.1.jar portlet-api-1.0.jar pluto-1.0.1-rc1.jar

Now I'm stuck on a "cannot find OJB.properties". Hope to find it soon!

Edited: Mar 3, 2005 to add the following:

Hey, I've been linked from the Jetspeed Wiki, cool!

Please see my follow-up posts to this issue:
Jetspeed 2 on Weblogic - part 2
Jetspeed 2 on Weblogic - Finally
Jetspeed 2 on Weblogic - update again
Jetspeed Fusion, Struts, and Weblogic

Also, it appears the commenting system on blogspot has been having some issues, so I cleaned out a few duplicate comments...

Issue: Precompiling with Struts-EL for Weblogic

Edit 10/13/2005: Apparently BEA has a workaround, and it is fixed in Service Pack 4!

For some reason the wlappc task of weblogic blows up when trying to precompile an war that uses the Struts-EL jar. This works fine with only the struts.jar so something is up with the struts-el.jar. Has anyone else seen this problem?

I've found a post about this in the BEA dev2dev Forums. As well as a post on the struts mailing list. So it would appear that this is a global issue between the struts-el.jar and the wlappc weblogic precompiling ant task.

Here is the exception that is received, that seems to point to a MessageResources issue:
java.lang.ExceptionInInitializerError
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:141)
at org.apache.strutsel.taglib.html.ELBaseTagBeanInfo.class$(ELBaseTagBea
nInfo.java:81)
at org.apache.strutsel.taglib.html.ELBaseTagBeanInfo.getPropertyDescript
ors(ELBaseTagBeanInfo.java:81)
at java.beans.Introspector.getTargetPropertyInfo(Introspector.java:459)
at java.beans.Introspector.getBeanInfo(Introspector.java:372)
at java.beans.Introspector.getBeanInfo(Introspector.java:207)
at java.beans.Introspector.getBeanInfo(Introspector.java:193)
at weblogic.servlet.jsp.StandardTagLib.parseTagDD(StandardTagLib.java:13
23)
at weblogic.servlet.jsp.StandardTagLib.parseDD(StandardTagLib.java:1261)

at weblogic.servlet.jsp.StandardTagLib.(StandardTagLib.java:292)
at weblogic.servlet.jsp.TagLibHelper.loadTagLib(TagLibHelper.java:314)
at weblogic.servlet.jsp.JspLexer.loadTagLib(JspLexer.java:145)
at weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE_BODY(JspLexer.java:50
15)
at weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE(JspLexer.java:4853)
at weblogic.servlet.jsp.JspLexer.mDIRECTIVE(JspLexer.java:4699)
at weblogic.servlet.jsp.JspLexer.mSTANDARD_THING(JspLexer.java:2094)
at weblogic.servlet.jsp.JspLexer.mTOKEN(JspLexer.java:1880)
at weblogic.servlet.jsp.JspLexer.nextToken(JspLexer.java:1753)
at weblogic.servlet.jsp.JspLexer.parse(JspLexer.java:963)
at weblogic.servlet.jsp.JspParser.doit(JspParser.java:106)
at weblogic.servlet.jsp.JspParser.parse(JspParser.java:230)
at weblogic.servlet.jsp.Jsp2Java.outputs(Jsp2Java.java:125)
at weblogic.utils.compiler.CodeGenerator.generate(CodeGenerator.java:258
)
at weblogic.jspc.runJspc(jspc.java:550)
at weblogic.jspc.runJspc(jspc.java:437)
at weblogic.servlet.jsp.JspcInvoker.compile(JspcInvoker.java:163)
at weblogic.appc.compileWAR(appc.java:859)
at weblogic.appc.compileModules(appc.java:650)
at weblogic.appc.compileEAR(appc.java:733)
at weblogic.appc.compileInput(appc.java:458)
at weblogic.appc.runBody(appc.java:184)
at weblogic.utils.compiler.Tool.run(Tool.java:146)
at weblogic.utils.compiler.Tool.run(Tool.java:103)
at weblogic.appc.main(appc.java:1028)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at weblogic.ant.taskdefs.j2ee.CompilerTask.invokeMain(CompilerTask.java:
278)
at weblogic.ant.taskdefs.j2ee.Appc.execute(Appc.java:179)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:193)
at org.apache.tools.ant.Task.perform(Task.java:341)
at org.apache.tools.ant.Target.execute(Target.java:309)
at org.apache.tools.ant.Target.performTasks(Target.java:336)
at org.apache.tools.ant.Project.executeTarget(Project.java:1339)
at org.apache.tools.ant.Project.executeTargets(Project.java:1255)
at org.apache.tools.ant.Main.runBuild(Main.java:609)
at org.apache.tools.ant.Main.start(Main.java:196)
at org.apache.tools.ant.Main.main(Main.java:235)
Caused by: java.lang.NullPointerException
at org.apache.struts.util.MessageResources.getMessageResources(MessageRe
sources.java:577)
at org.apache.struts.taglib.html.BaseTag.(BaseTag.java:94)
... 50 more
- with nested exception:
[java.lang.ExceptionInInitializerError]

Refactoring with Appfuse

Appfuse is starting a small revolution on the projects that I work with. Through Appfuse [article] I have been able to easily brief co-developers and architect types on the latest open source ideas in J2EE. You see, the projects I have worked on are "big enterprise" J2EE - Weblogic types, and it is hard to sell these people on new ideas. So, slowly we can implement Agile ideas and methods into the archaic processes and development that exists. Xdoclet was one of the first to make it in.

Lately it has been simple things like showing CVS can replace much more expensive CM repositories. Then throwing in ideas like CVSSpam. I'm also trying a JSPWiki and Roller Weblogger, but that seems to be catching on much slower than I had hoped (although using Matt's professional looking redman theme has helped!).

My next step is Cruise Control. After a brief comparison with Anthill, it looks like CC will be our Continuous Integration approach. (Of course both with help from appfuse - CC - anthill).

All of this because of Appfuse! A big thanks to Matt Raible for being open with his experiences and sharing the code behind his project. This has made new concepts easier to integrate with our old project, through the clean organization of his ideas.

After Continuous Integration comes an even harder sell, which may seem easy to many of you agile veterans. The sell of test-driven coding and writing unit tests for all of our code (as I have mentioned before). JUnit, DBUnit, Cactus, StrutsTestCase, JwebUnit, Canoo Webtest, here we come!

(This leaves Hibernate and iBatis to conquer CMP on another day...)

Java Coding Standards

... on one page? I like it!