Return-Path: Delivered-To: apmail-struts-dev-archive@www.apache.org Received: (qmail 17210 invoked from network); 12 Sep 2006 16:58:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 Sep 2006 16:58:55 -0000 Received: (qmail 91745 invoked by uid 500); 12 Sep 2006 16:58:48 -0000 Delivered-To: apmail-struts-dev-archive@struts.apache.org Received: (qmail 91708 invoked by uid 500); 12 Sep 2006 16:58:48 -0000 Mailing-List: contact dev-help@struts.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Struts Developers List" Reply-To: "Struts Developers List" Delivered-To: mailing list dev@struts.apache.org Received: (qmail 91697 invoked by uid 99); 12 Sep 2006 16:58:48 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from [64.39.31.158] (HELO zeus.atlassian.com) (64.39.31.158) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Sep 2006 09:58:48 -0700 Received: from [192.168.1.116] (dsl092-186-178.sfo1.dsl.speakeasy.net [66.92.186.178]) (authenticated (0 bits)) by zeus.atlassian.com (8.12.11.20060308/8.11.6) with ESMTP id k8CGwKa6003973 for ; Tue, 12 Sep 2006 11:58:23 -0500 Message-ID: <4506E72B.7000209@twdata.org> Date: Tue, 12 Sep 2006 09:58:19 -0700 From: Don Brown User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: Struts Developers List Subject: Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels) References: <20060912164958.54843.qmail@web25714.mail.ukl.yahoo.com> In-Reply-To: <20060912164958.54843.qmail@web25714.mail.ukl.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Why would we get duplicates? ATM, we are only loading the resource from the first successful classloader, so we shouldn't get the same file multiple times. The FileManager keeps a list of loaded files to ensure we don't load one twice. Don tm jee wrote: > I see, I think I might have misunderstood. Please correct me if I am wrong. With, > > one.jar > pac/test.xml > two.jar > pac/test.xml > three.jar > pac/test.xml > > We would get something like (if we iterate over each iteration) > jar:file:/......./one.jar!/META-INF/test.xml > jar:file:/......./two.jar!/META-INF/test.xml > jar:file:/......./three.jar!/META-INF/test.xml > jar:file:/......./one.jar!/META-INF/test.xml > jar:file:/......./two.jar!/META-INF/test.xml > jar:file:/......./three.jar!/META-INF/test.xml > jar:file:/......./one.jar!/META-INF/test.xml > jar:file:/......./two.jar!/META-INF/test.xml > jar:file:/......./three.jar!/META-INF/test.xml > > It should be sufficient I think if we could just get > jar:file:/......./one.jar!/META-INF/test.xml > jar:file:/......./two.jar!/META-INF/test.xml > jar:file:/......./three.jar!/META-INF/test.xml > > instead of some extra duplicates. What do you think? Should we fix this, or is it a feature? > > Thx in advance. > > > > > ----- Original Message ---- > From: Don Brown > To: Struts Developers List > Sent: Tuesday, 12 September, 2006 10:35:18 AM > Subject: Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels) > > > > tm jee wrote: > >> Sounds cool. >> >> Just some thoughts. Maybe we could make the bootstrap struts xml "struts-default.xml" and the plugins xml "struts-plugin.xml" while those in the webapp "struts.xml". The bootstraping sequence would be >> >> 1] struts-default.xml >> 2] struts-plugins.xml >> 3] struts.xml >> >> This way its easier for us to control which config we are dealing with. If we have the plugins config and the base bootsraping config all called "struts-default.xml", depending on which gets loaded first in the classpath, we might get the plugin's "struts-default.xml" called first before the struts-core's "struts-default.xml" which will cause some problem (with current xwork code) cuase some of the required interceptor, results etc used by the plugin might not be loaded yet. I hope i got the concept correct, if not please correct me. :-) >> >> > Good point, let's do this. > > >> Another thing we might want to considered is the dependency of plugins. If say plugin A needs some stuff declared in plugin B, it might not work, depending on which gets loaded first in the classpath. Or would this make thing unnecessarily complicated? >> >> > Well, the most robust solution for plugins would be to use OSGI like > Eclipse does, however, I'm not sure we need that power yet. I'd like to > keep it simple for now, sticking with a system that is already in > place. It doubles as an example to users on how to plug in > functionality easily. > >> About the new ClassLoaderUtil under xwork2 code, the method "getResources(String, Class, boolean)". I think its better if we could make the Iterator returned not to contains duplicates. Eg. if I jave >> >> one.jar >> pac/test.xml >> two.jar >> pac/test.xml >> three.jar >> pac/test.xml >> >> trying to get "pac/test.xml" will return more than 3 copies. What do you guys think? >> Attached below is a patch attemt to fix this. I could create a jira issue if its agreed that its something to be fix. >> >> > Actually, that's the whole point :) In our case, we are using it to get > all the struts-plugin.xml files in all jars. This allows us to > dynamically discover new plugins without the need to "register" them > somewhere. It also makes it nice for users to deploy new modules by > simply including a struts.xml file in their jar and the module is > automatically discovered and installed. > > Don > >> Tia. >> >> Index: src/java/com/opensymphony/xwork2/util/ClassLoaderUtil.java >> =================================================================== >> --- src/java/com/opensymphony/xwork2/util/ClassLoaderUtil.java (revision 1129) >> +++ src/java/com/opensymphony/xwork2/util/ClassLoaderUtil.java (working copy) >> @@ -13,6 +13,7 @@ >> import java.util.Collections; >> import java.util.Enumeration; >> import java.util.Iterator; >> +import java.util.LinkedHashSet; >> import java.util.LinkedList; >> import java.util.List; >> import java.util.NoSuchElementException; >> @@ -160,7 +161,8 @@ >> /** Aggregates Enumeration instances into one iterator */ >> protected static class AggregateIterator implements Iterator { >> >> - LinkedList> enums = new LinkedList>(); >> + //LinkedList> enums = new LinkedList>(); >> + LinkedHashSet> enums = new LinkedHashSet>(); >> Enumeration cur = null; >> >> public AggregateIterator addEnumeration(Enumeration e) { >> @@ -191,7 +193,9 @@ >> private Enumeration determineCurrentEnumeration() { >> if (cur != null && !cur.hasMoreElements()) { >> if (enums.size() > 0) { >> - cur = enums.removeLast(); >> + Enumeration[] e = enums.toArray(new Enumeration[0]); >> + enums.remove(e[enums.size() - 1]); >> + //cur = enums.removeLast(); >> } else { >> cur = null; >> } >> >> >> >> >> >> >> ----- Original Message ---- >> From: Ted Husted >> To: Struts Developers List >> Sent: Tuesday, 12 September, 2006 6:23:06 AM >> Subject: Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels) >> >> On 9/11/06, Don Brown wrote: >> >> >>> The way I propose to solve this problem is to implement "Framework >>> Plugins". A framework plugin is a jar that contains framework extension >>> classes and configuration, which only need to be dropped into the >>> classpath to be activated. >>> >>> >> +1 >> >> -Ted. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >> For additional commands, e-mail: dev-help@struts.apache.org >> >> >> >> >> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org