That is a great link Alex, I was thinking there had to be a common EntityResolver impl that could look at the local file system first before going to the net. We'll look at using this for the portlet deployer for 2.6.1
-Eric Alex Vigdor wrote: > 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 > >
smime.p7s
Description: S/MIME Cryptographic Signature
