struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <mr...@twdata.org>
Subject Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels)
Date Tue, 12 Sep 2006 16:58:19 GMT
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 <mrdon@twdata.org>
> 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 <husted@apache.org>
>> 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 <mrdon@twdata.org> 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


Mime
View raw message