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. :-)
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?
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.
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]
