Hey Eric (and everybody),
Just a tip since I've dealt with this problem a few times before,
first with HyperContent. You just need to configure a SAX
EntityResolver that will look up local copies of resources that are
normally found online. This way you can leave doctypes intact and
still work offline. The standard way to do this is with a "catalog
file" that maps system or public identifiers to local file paths.
The catalog file is based on an Oasis standard. Here's an open-
source catalog resolver implementation:
http://xml.apache.org/commons/components/resolver/
You can set the EntityResolver on the XMLReader used for parsing.
-Alex
On Aug 20, 2007, at 7:13 PM, Eric Dalquist wrote:
Moving this to the dev list.
After further consideration I would also like to put of the 2.6.1
release until more time can be spent on this issue. I'll be doing some
more digging tomorrow to see what the options are for a resolution to
this problem. Any ideas and suggestions are welcome.
-Eric
Cris J Holdorph wrote:
Just to bring this issue back to the foreground. I believe the state
of affairs that Drew describes below, means that one of the primary
goals stated by Eric Dalquist, for a 2.6.1 release, has not been met.
"It looks like this deployPortletApp issue is causing quite a few
people
problems. I'd like to get http://www.ja-sig.org/issues/browse/UP-1792
fixed and a 2.6.1 release out ASAP to address the problem so
people can
actually use 2.6."
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.
Previously, Eric had said he would tag up 2.6.1RC1 tomorrow morning.
Does this mean we should hold off tagging that RC, until we have a
solution for "ant initportal" with no internet?
---- Cris J H
ps. fwiw, the 'logging' issue is at least fixed ;)
Drew Wills wrote:
For anyone who remembers and wondered about the issues with
deployPortletApp that Sherwin of BYU was having last week...
I worked with Sherwin off-list to get to the heart of the matter.
At first, you'll remember, Sherwin wasn't able to connect to
svn.apache.org to pull the portlet.tld because the server he was
using wasn't able to see the outside Internet. We all agreed that
the deployer should be reworked to pull that tld file from somewhere
local. Additionally, Eric Dalquist pointed out that the version of
the tld was incorrect: the script was pointing to the pluto 1.1
version where we needed 1.0.1.
Eric created 2 JIRA issues (one to pull locally, one to fix the
version) and I made the changes -- 2.6.1 will have both fixes. But
Sherwin was still having problems.
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.
Does anyone have a problem with *not* intercepting these DTD
references? Does anyone have any other really cool suggestions?
drew wills
--- You are currently subscribed to [EMAIL PROTECTED] as:
[EMAIL PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-user
--
You are currently subscribed to [email protected] as: [EMAIL
PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
