This page serves as additional release notes about 2.6.0 GA. It is intended as a supplement to the releaseNotes.html accompanying the release.
| Panel | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
| Anchor | ||||
|---|---|---|---|---|
|
uPortal 2.6.0 requires Xalan 2.7.0. (This isn't actually a particularly strong requirement – you could retrofit it to use a different Xalan relatively easily, at the cost of no longer being on the default and preferred Xalan.) Apparently it is difficult to get NetBeans to cope with Xalan 2.7.0.
Netbeans 5.5(.1) comes with a bundled version of Tomcat (5.5.17). This is convenient as it offers developers an easy out-of-the-box solution for developing web applications. However it is problematic with uPortal 2.6.0 GA. Netbeans includes 2 additional jars in the common/endorsed directory in the bundled Tomcat (xml-apis.jar and xercesImpl.jar) that are not included with Tomcat as it is downloaded from Apache.
...
Work-Around #1: Installing a Tomcat and registering it with Netbeans
You can use Netbeans 5.5.1 with uPortal 2.6.0 on JDK 1.5 by following these steps:
...
From here, you can start using uPortal as usual.
Work-Around #2: Modify Netbeans Bundled Tomcat Files.
This option is a little riskier as the bundled Tomcat has been set up for maximum possible backward compatibility with previous JDKs. The changes described here should be made so that they can be rolled back easily if you run in to trouble with other development projects.
...
From here, you can start using uPortal as usual.
Netbeans
...
Updates
An issue was filed with the Netbeans development team regarding this. As it turns out, the extra jar files are in the common/endorsed directory for backward compatibility with JDK 1.4 and below. When Netbeans is used with a JDK newer than 1.4, the endorsed directory is not being read, hence the error message that Xalan 2.7.0 can't be found. Netbeans 6.0 comes with an unmodified Tomcat 6 meaning that there is no undocumented or unexpected behavior like this to maintain any kind of backward compatibility. You will need to follow the work-around steps if you want to use Netbeans with uPortal.
| Anchor | ||||
|---|---|---|---|---|
|
from uportal-user@lists.ja-sig.org :
Cris J Holdorph wrote:
<snip/>
To sum up, I believe the issues with deployPortletApp (and drew gives
the latest version below) are with people trying to do "ant
initportal" from machines without general internet connectivity.
The current "ant initportal" will still not run without internet
connectivity. Just pull out your internet connection and try it.
Drew Wills wrote:
<snip/>
It turns out he wasn't able to deploy any portletApp that contains a
web.xml file with a <!DOCTYPE> declaration like the following:
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application
2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">
It looks as though the XML parser will always try to load the DTD
from java.sun.com, even if validation is turned off. I suppose it
makes sense, since the DTD may contain entities (or default
attributes?) used in the document.
This means that the 'deployPortletApp' target requires an Internet
connection, or (alternately) someone must manually remove the DTD
references or entire <!DOCTYPE> declarations (it works without them)
from the web.xml files of any portletApps that will be deployed.
For comparison, the previous deployer used the WebAppDtdResolver
class to intercept the XML parser's attempt to load a DTD and supply
a local copy. The DTD to use was hard-coded (the 'systemId'
parameter was not even referenced), such that all web.xml files
essentially referenced the servlet spec 2.3 DTD... which is of course
the major problem the new deployer fixes.