Return-Path: Delivered-To: apmail-jakarta-jetspeed-dev-archive@www.apache.org Received: (qmail 18114 invoked from network); 11 Jun 2004 21:56:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 11 Jun 2004 21:56:18 -0000 Received: (qmail 26726 invoked by uid 500); 11 Jun 2004 21:56:35 -0000 Delivered-To: apmail-jakarta-jetspeed-dev-archive@jakarta.apache.org Received: (qmail 26485 invoked by uid 500); 11 Jun 2004 21:56:33 -0000 Mailing-List: contact jetspeed-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jetspeed Developers List" Reply-To: "Jetspeed Developers List" Delivered-To: mailing list jetspeed-dev@jakarta.apache.org Received: (qmail 26471 invoked by uid 99); 11 Jun 2004 21:56:33 -0000 Received: from [192.18.33.10] (HELO exchange.sun.com) (192.18.33.10) by apache.org (qpsmtpd/0.27.1) with SMTP; Fri, 11 Jun 2004 14:56:33 -0700 Received: (qmail 1837 invoked from network); 11 Jun 2004 21:57:10 -0000 Received: from localhost (HELO nagoya) (127.0.0.1) by nagoya.betaversion.org with SMTP; 11 Jun 2004 21:57:10 -0000 Message-ID: <892984541.1086991030211.JavaMail.apache@nagoya> Date: Fri, 11 Jun 2004 14:57:10 -0700 (PDT) From: jira@apache.org To: jetspeed-dev@jakarta.apache.org Subject: [jira] Commented: (JS2-74) Refactor PAM and Descriptor Utilities In-Reply-To: <1390748211.1086791170010.JavaMail.apache@nagoya> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N The following comment has been added to this issue: Author: Ate Douma Created: Fri, 11 Jun 2004 2:56 PM Body: The plugin problem can be solved by at least once do: /maven-plugin/maven plugin:install After that, plugin:deploy will update the plugin definition but without the install first it won't be found (without a dependency definition that is). --------------------------------------------------------------------- View this comment: http://issues.apache.org/jira/browse/JS2-74?page=comments#action_36055 --------------------------------------------------------------------- View the issue: http://issues.apache.org/jira/browse/JS2-74 Here is an overview of the issue: --------------------------------------------------------------------- Key: JS2-74 Summary: Refactor PAM and Descriptor Utilities Type: Improvement Status: Closed Priority: Major Resolution: FIXED Project: Jetspeed 2 Components: Deployment Fix Fors: 2.0-dev/cvs 2.0-a1 Versions: 2.0-dev/cvs 2.0-a1 Assignee: Scott T Weaver Reporter: Scott T Weaver Created: Wed, 9 Jun 2004 7:25 AM Updated: Fri, 11 Jun 2004 2:56 PM Environment: Mandrake Linux 10, Tomcat 4.1.30, HSQL Description: I am refactoring all of the Jetspeed desccriptor utility classes from static, utility classes into objects. PortletDescriptorUtilities has been renamed to PortletApplicationDescriptor. WebDescriptorUtilities has been refactored into WebApplicationDescriptor. JetspeedDescriptorUtilities has been refactored into ExtendedPortletMetadata. Besides the rename, the static methods have been converted into instance methods. I have created a composite object, PortletApplicationWar, that uses these three metadata classes to build up registry objects from a war file, which is either an actual war file itself OR a war-like structure on the file system. I am using commons-vfs to manipulate the WAR as this allows me to work on the war as a FileObject, regardless if it is a file system directory or a WAR file. All these descriptor classes have been moved to the org.apache.jetspeed.util.descriptor package. FileSystemPAM uses the PortletApplicationWar class exclusively instead of directly using the metadata classes themselves. This makes the FSPAM code much more readable and easier to debug. Looking over the logic for processWebXML, it does not appear to be adding the JetspeedContainer servlet nor its mapping. Also logic used to decide where to put the new elements could possibly cause the elements to be placed in the wrong spot relative to the DTD definition. I rewrote this logic using JDom and XPath expressions. I am using an XPath query to check for a specific servelet and servlet-mapping with the servlet-name "JetspeedContainer". If these elements do not exist, I use JDom to walk the top-level of elements until it finds the correct location, per the DTD, to insert both the servlet and servlet-mapping elements. I have added an additional test, testInfuseWebXML, to TestPortletDescriptor to verify that the infusing works correctly. --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org