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
