FWIW, I just fixed the duplicates issue so aggregation over multiple classloaders works better now.
Don On 9/12/06, Don Brown <[EMAIL PROTECTED]> wrote:
The ClassloaderUtils is set up to possibly aggregate over all classloaders, however, as you found, it needs some work, which is why aggregation is disabled. Besides the duplicate problem, it could have an adverse affect on performance, and its ultimate value is questionable. Still, I like working with Iterators instead of Enumerations so I left it in. Don tm jee wrote: > Ah... i got it now. I am having aggregate=true, that's why its having duplicates. With aggregate=false, its working ok. > > > > ----- Original Message ---- > From: Don Brown <[EMAIL PROTECTED]> > To: Struts Developers List <[email protected]> > Sent: Tuesday, 12 September, 2006 10:58:19 AM > Subject: Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels) > > 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 <[EMAIL PROTECTED]> >> To: Struts Developers List <[email protected]> >> 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<URL> 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<E> implements Iterator<E> { >>> >>> - LinkedList<Enumeration<E>> enums = new LinkedList<Enumeration<E>>(); >>> + //LinkedList<Enumeration<E>> enums = new LinkedList<Enumeration<E>>(); >>> + LinkedHashSet<Enumeration<E>> enums = new LinkedHashSet<Enumeration<E>>(); >>> Enumeration<E> cur = null; >>> >>> public AggregateIterator addEnumeration(Enumeration<E> e) { >>> @@ -191,7 +193,9 @@ >>> private Enumeration<E> determineCurrentEnumeration() { >>> if (cur != null && !cur.hasMoreElements()) { >>> if (enums.size() > 0) { >>> - cur = enums.removeLast(); >>> + Enumeration<E>[] e = enums.toArray(new Enumeration[0]); >>> + enums.remove(e[enums.size() - 1]); >>> + //cur = enums.removeLast(); >>> } else { >>> cur = null; >>> } >>> >>> >>> >>> >>> >>> >>> ----- Original Message ---- >>> From: Ted Husted <[EMAIL PROTECTED]> >>> To: Struts Developers List <[email protected]> >>> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >>> >>> >>> >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >> >> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
