Looks like a great resolution Drew and should provided options going forward for better offline DTD handling in other parts of the framework.
I'm heading out for a long weekend tomorrow afternoon so I'll resume the 2.6.1 RC1 push when I get back. -Eric Drew Wills wrote: > I created JIRA UP-1800 (http://www.ja-sig.org/issues/browse/UP-1800) > to track this effort, then I created a solution based on Alex's > suggestion. > > The enhancement is checked into 2-6-patches & trunk, and the JIRA is > resolved. > > As it stands, the only DTD that the EntityResolver can load locally is > the servlet 2.3 DTD, located in webpages/dtd/ -- but of course, that's > the only one that was preventing disconnected michines from deploying. > > If you want to provide local support for any other DTDs, place them in > the same folder and create an entry for each of them in the > webpages/dtd/xml-catalog.xml file. > > > drew wills > > > Eric Dalquist wrote: >> 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
