struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tm jee <tm_...@yahoo.co.uk>
Subject Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels)
Date Tue, 12 Sep 2006 17:19:42 GMT
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 <mrdon@twdata.org>
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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message