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]
