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 <dev@struts.apache.org>
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 <dev@struts.apache.org>
> 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 <dev@struts.apache.org>
>> 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]
