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 16:49:58 GMT
Thx for the reply Don.

> Good point, let's do this.
Cool. 

> 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.

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






Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message