You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2006/09/11 23:01:25 UTC
[s2] Logging levels
I'm bringing this up because we've closed WW-1424 and I'm not sure
what we did. The referenced commits did a lot of other things, and I
can't see the trees for the forest.
With devmode=false, we are emitting 16 INFO lines on startup, mainly
dealing with partially loaded interceptors and result.
With devmode=true, we are 58 logging lines on startup, some of which
seem to be redundant INFO reports regarding partially-loaded
interceptors and results.
We are issuign these loggging statements because the default framework
configuration includes support for interceptors and results that
include JARs not provided in the framework distribution.
The thought is that by pre-configuring these members, people who want
to use features like JSF and JasperReports need only to add the JAR.
They do not need to take the extra step of adding a configuration
stanza to their struts.xml. Hence, the framework is simpler for people
who want to use such things.
IMHO, true simplicity is elegant. I continue to think
partially-loading interceptors is an inelegant solution. A truly
simple solution doesn't make other things harder. In my mind, foisting
apologetic logging statements on every developer every time we launch
an application is making everyday life harder.
The current approach is trying to simulate technology that we don't
have. If we want drop-and-play plugins, then let's implement the
technology.
Until then, let's live with the fact that people who want to use JSF
or JasperReports will have to add an XML stanza to their configuration
file, just like we do for Maven plugins.
But, out-of-the-box, with devmode turned off, we should not issue
logging statements about conditions that are nominal, when using the
framework in a default, nothing-added configuration.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels)
Posted by faisal abdallah <ju...@yahoo.co.uk>.
Has anybody managed to unsubscribe from this list. I've tried hundred of times with no luck
Rainer Hermanns <he...@aixcept.de> wrote: Really good idea, +1
> 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.
>
> A plugin would consist of:
> - struts-default.xml: A Struts config file defining the interceptors,
> interceptor stacks, results, packages, and/or actions
> - The Java classes and resources
>
> On startup, Struts would search for and load all the struts-default.xml
> files first, then load the application-specific struts.xml files. This
> would allow you to easily install and use a plugin as easily as copying
> a jar file into your application.
>
> Each plugin's would define its own package that contains its results,
> interceptors, and actions. Then, for an application to use the plugin,
> simply have its packages extend the plugin's package(s):
>
>
....
>
> Initial candidates for plugins would be:
> - JSF support
> - Jasper Reports support
> - Pell support
>
> To implement this proposal, we would need to split out the jasper, pell,
> and jsf code into their own artifacts and give them their own
> struts-default.xml file. We could extend the framework idea to extract
> any code that uses an optional jar, including support for things like
> Spring or Velocity. This would make a nice one-to-one mapping between
> optional jars and their Struts plugin, and would simplify core to boot.
>
> Of course, this would be targeted for 2.0.1 :)
>
> Don
>
> Ted Husted wrote:
>> On 9/11/06, Don Brown wrote:
>>> Make sure you get the latest xwork, as a lot of the changes where in
>>> there.
>>
>> I updated XWork, but now there are even more logging statements than
>> before :(
>>
>> Sep 11, 2006 5:21:05 PM org.apache.catalina.startup.Catalina start
>> INFO: Server startup in 2546 ms
>> Sep 11, 2006 5:21:06 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.FacesSetupInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:57:97
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfSetup interceptor
>> Sep 11, 2006 5:21:06 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.RestoreViewInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:58:100
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfRestore interceptor
>> Sep 11, 2006 5:21:06 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.ApplyRequestValuesInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:59:105
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfApply interceptor
>> Sep 11, 2006 5:21:06 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.ProcessValidationsInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:60:108
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfValidate interceptor
>> Sep 11, 2006 5:21:06 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.UpdateModelValuesInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:61:105
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfUpdate interceptor
>> Sep 11, 2006 5:21:06 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.InvokeApplicationInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:62:105
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfInvoke interceptor
>> Sep 11, 2006 5:21:09 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.FacesSetupInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:57:97
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfSetup interceptor
>> Sep 11, 2006 5:21:09 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.RestoreViewInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:58:100
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfRestore interceptor
>> Sep 11, 2006 5:21:09 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.ApplyRequestValuesInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:59:105
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfApply interceptor
>> Sep 11, 2006 5:21:09 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.ProcessValidationsInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:60:108
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfValidate interceptor
>> Sep 11, 2006 5:21:09 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.UpdateModelValuesInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:61:105
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfUpdate interceptor
>> Sep 11, 2006 5:21:09 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.InvokeApplicationInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:62:105
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfInvoke interceptor
>>
>> ---------------------------------------------------------------------
>> 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
---------------------------------
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging
levels)
Posted by Rainer Hermanns <he...@aixcept.de>.
Really good idea, +1
> 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.
>
> A plugin would consist of:
> - struts-default.xml: A Struts config file defining the interceptors,
> interceptor stacks, results, packages, and/or actions
> - The Java classes and resources
>
> On startup, Struts would search for and load all the struts-default.xml
> files first, then load the application-specific struts.xml files. This
> would allow you to easily install and use a plugin as easily as copying
> a jar file into your application.
>
> Each plugin's would define its own package that contains its results,
> interceptors, and actions. Then, for an application to use the plugin,
> simply have its packages extend the plugin's package(s):
>
> <package name="myApp" extends="default,jsf,jasper">....</package>
>
> Initial candidates for plugins would be:
> - JSF support
> - Jasper Reports support
> - Pell support
>
> To implement this proposal, we would need to split out the jasper, pell,
> and jsf code into their own artifacts and give them their own
> struts-default.xml file. We could extend the framework idea to extract
> any code that uses an optional jar, including support for things like
> Spring or Velocity. This would make a nice one-to-one mapping between
> optional jars and their Struts plugin, and would simplify core to boot.
>
> Of course, this would be targeted for 2.0.1 :)
>
> Don
>
> Ted Husted wrote:
>> On 9/11/06, Don Brown <mr...@twdata.org> wrote:
>>> Make sure you get the latest xwork, as a lot of the changes where in
>>> there.
>>
>> I updated XWork, but now there are even more logging statements than
>> before :(
>>
>> Sep 11, 2006 5:21:05 PM org.apache.catalina.startup.Catalina start
>> INFO: Server startup in 2546 ms
>> Sep 11, 2006 5:21:06 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.FacesSetupInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:57:97
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfSetup interceptor
>> Sep 11, 2006 5:21:06 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.RestoreViewInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:58:100
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfRestore interceptor
>> Sep 11, 2006 5:21:06 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.ApplyRequestValuesInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:59:105
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfApply interceptor
>> Sep 11, 2006 5:21:06 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.ProcessValidationsInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:60:108
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfValidate interceptor
>> Sep 11, 2006 5:21:06 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.UpdateModelValuesInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:61:105
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfUpdate interceptor
>> Sep 11, 2006 5:21:06 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.InvokeApplicationInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:62:105
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfInvoke interceptor
>> Sep 11, 2006 5:21:09 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.FacesSetupInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:57:97
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfSetup interceptor
>> Sep 11, 2006 5:21:09 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.RestoreViewInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:58:100
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfRestore interceptor
>> Sep 11, 2006 5:21:09 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.ApplyRequestValuesInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:59:105
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfApply interceptor
>> Sep 11, 2006 5:21:09 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.ProcessValidationsInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:60:108
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfValidate interceptor
>> Sep 11, 2006 5:21:09 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.UpdateModelValuesInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:61:105
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfUpdate interceptor
>> Sep 11, 2006 5:21:09 PM
>> com.opensymphony.xwork2.config.providers.InterceptorBuilder
>> constructInterceptorReference
>> WARNING: Unable to load config class
>> org.apache.struts2.jsf.InvokeApplicationInterceptor at interceptor -
>> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:62:105
>>
>> probably due to a missing jar, which might be fine if you never plan
>> to use the jsfInvoke interceptor
>>
>> ---------------------------------------------------------------------
>> 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
Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging
levels)
Posted by Don Brown <mr...@twdata.org>.
Yep, agreed.
Ted Husted wrote:
> On 9/12/06, tm jee <tm...@yahoo.co.uk> wrote:
>> 2] struts-plugins.xml
>
> /s/plugins/plugin
>
> Each xml would be dealing with a single plugin, n'est pas?
>
> -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
Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels)
Posted by Ted Husted <hu...@apache.org>.
On 9/12/06, tm jee <tm...@yahoo.co.uk> wrote:
> 2] struts-plugins.xml
/s/plugins/plugin
Each xml would be dealing with a single plugin, n'est pas?
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels)
Posted by Don Brown <do...@gmail.com>.
FWIW, I just fixed the duplicates issue so aggregation over multiple
classloaders works better now.
Don
On 9/12/06, Don Brown <mr...@twdata.org> wrote:
> The ClassloaderUtils is set up to possibly aggregate over all
> classloaders, however, as you found, it needs some work, which is why
> aggregation is disabled. Besides the duplicate problem, it could have
> an adverse affect on performance, and its ultimate value is
> questionable. Still, I like working with Iterators instead of
> Enumerations so I left it in.
>
> Don
>
> tm jee wrote:
> > 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 <mr...@twdata.org>
> > To: Struts Developers List <de...@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 <mr...@twdata.org>
> >> To: Struts Developers List <de...@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 <hu...@apache.org>
> >>> To: Struts Developers List <de...@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 <mr...@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
> >
> >
> >
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging
levels)
Posted by Don Brown <mr...@twdata.org>.
The ClassloaderUtils is set up to possibly aggregate over all
classloaders, however, as you found, it needs some work, which is why
aggregation is disabled. Besides the duplicate problem, it could have
an adverse affect on performance, and its ultimate value is
questionable. Still, I like working with Iterators instead of
Enumerations so I left it in.
Don
tm jee wrote:
> 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 <mr...@twdata.org>
> To: Struts Developers List <de...@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 <mr...@twdata.org>
>> To: Struts Developers List <de...@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 <hu...@apache.org>
>>> To: Struts Developers List <de...@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 <mr...@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
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels)
Posted by tm jee <tm...@yahoo.co.uk>.
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 <mr...@twdata.org>
To: Struts Developers List <de...@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 <mr...@twdata.org>
> To: Struts Developers List <de...@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 <hu...@apache.org>
>> To: Struts Developers List <de...@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 <mr...@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
Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging
levels)
Posted by Don Brown <mr...@twdata.org>.
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 <mr...@twdata.org>
> To: Struts Developers List <de...@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 <hu...@apache.org>
>> To: Struts Developers List <de...@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 <mr...@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
Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels)
Posted by tm jee <tm...@yahoo.co.uk>.
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 <mr...@twdata.org>
To: Struts Developers List <de...@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 <hu...@apache.org>
> To: Struts Developers List <de...@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 <mr...@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
Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging
levels)
Posted by Don Brown <mr...@twdata.org>.
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 <hu...@apache.org>
> To: Struts Developers List <de...@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 <mr...@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
Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels)
Posted by tm jee <tm...@yahoo.co.uk>.
Thx for the tips Antonio. Looks interesting. :-)
I guess we might want to keep it simple for the time being as Don mentioned in the replying email.
----- Original Message ----
From: Antonio Petrelli <br...@tariffenet.it>
To: Struts Developers List <de...@struts.apache.org>
Sent: Tuesday, 12 September, 2006 10:29:23 AM
Subject: Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels)
tm jee ha scritto:
> 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?
>
It seems that this problem has been addressed by Eclipse team, and one
day I found this blog entry:
http://www.eclipsezone.com/eclipse/forums/t64085.html
And it uses Struts as an example.
I don't know if it could help, but it's worth a look.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging
levels)
Posted by Antonio Petrelli <br...@tariffenet.it>.
tm jee ha scritto:
> 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?
>
It seems that this problem has been addressed by Eclipse team, and one
day I found this blog entry:
http://www.eclipsezone.com/eclipse/forums/t64085.html
And it uses Struts as an example.
I don't know if it could help, but it's worth a look.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels)
Posted by tm jee <tm...@yahoo.co.uk>.
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 <hu...@apache.org>
To: Struts Developers List <de...@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 <mr...@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
Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels)
Posted by Ted Husted <hu...@apache.org>.
On 9/11/06, Don Brown <mr...@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
Re: [Proposal] Framework plugin architecture (was Re: [s2] Logging levels)
Posted by Bob Lee <cr...@crazybob.org>.
Great idea. +1
On 9/11/06, Don Brown <mr...@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.
>
> A plugin would consist of:
> - struts-default.xml: A Struts config file defining the interceptors,
> interceptor stacks, results, packages, and/or actions
> - The Java classes and resources
>
> On startup, Struts would search for and load all the struts-default.xml
> files first, then load the application-specific struts.xml files. This
> would allow you to easily install and use a plugin as easily as copying
> a jar file into your application.
>
> Each plugin's would define its own package that contains its results,
> interceptors, and actions. Then, for an application to use the plugin,
> simply have its packages extend the plugin's package(s):
>
> <package name="myApp" extends="default,jsf,jasper">....</package>
>
> Initial candidates for plugins would be:
> - JSF support
> - Jasper Reports support
> - Pell support
>
> To implement this proposal, we would need to split out the jasper, pell,
> and jsf code into their own artifacts and give them their own
> struts-default.xml file. We could extend the framework idea to extract
> any code that uses an optional jar, including support for things like
> Spring or Velocity. This would make a nice one-to-one mapping between
> optional jars and their Struts plugin, and would simplify core to boot.
>
> Of course, this would be targeted for 2.0.1 :)
>
> Don
>
> Ted Husted wrote:
> > On 9/11/06, Don Brown <mr...@twdata.org> wrote:
> >> Make sure you get the latest xwork, as a lot of the changes where in
> >> there.
> >
> > I updated XWork, but now there are even more logging statements than
> > before :(
> >
> > Sep 11, 2006 5:21:05 PM org.apache.catalina.startup.Catalina start
> > INFO: Server startup in 2546 ms
> > Sep 11, 2006 5:21:06 PM
> > com.opensymphony.xwork2.config.providers.InterceptorBuilder
> > constructInterceptorReference
> > WARNING: Unable to load config class
> > org.apache.struts2.jsf.FacesSetupInterceptor at interceptor -
> > jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:57:97
> >
> > probably due to a missing jar, which might be fine if you never plan
> > to use the jsfSetup interceptor
> > Sep 11, 2006 5:21:06 PM
> > com.opensymphony.xwork2.config.providers.InterceptorBuilder
> > constructInterceptorReference
> > WARNING: Unable to load config class
> > org.apache.struts2.jsf.RestoreViewInterceptor at interceptor -
> > jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:58:100
> >
> > probably due to a missing jar, which might be fine if you never plan
> > to use the jsfRestore interceptor
> > Sep 11, 2006 5:21:06 PM
> > com.opensymphony.xwork2.config.providers.InterceptorBuilder
> > constructInterceptorReference
> > WARNING: Unable to load config class
> > org.apache.struts2.jsf.ApplyRequestValuesInterceptor at interceptor -
> > jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:59:105
> >
> > probably due to a missing jar, which might be fine if you never plan
> > to use the jsfApply interceptor
> > Sep 11, 2006 5:21:06 PM
> > com.opensymphony.xwork2.config.providers.InterceptorBuilder
> > constructInterceptorReference
> > WARNING: Unable to load config class
> > org.apache.struts2.jsf.ProcessValidationsInterceptor at interceptor -
> > jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:60:108
> >
> > probably due to a missing jar, which might be fine if you never plan
> > to use the jsfValidate interceptor
> > Sep 11, 2006 5:21:06 PM
> > com.opensymphony.xwork2.config.providers.InterceptorBuilder
> > constructInterceptorReference
> > WARNING: Unable to load config class
> > org.apache.struts2.jsf.UpdateModelValuesInterceptor at interceptor -
> > jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:61:105
> >
> > probably due to a missing jar, which might be fine if you never plan
> > to use the jsfUpdate interceptor
> > Sep 11, 2006 5:21:06 PM
> > com.opensymphony.xwork2.config.providers.InterceptorBuilder
> > constructInterceptorReference
> > WARNING: Unable to load config class
> > org.apache.struts2.jsf.InvokeApplicationInterceptor at interceptor -
> > jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:62:105
> >
> > probably due to a missing jar, which might be fine if you never plan
> > to use the jsfInvoke interceptor
> > Sep 11, 2006 5:21:09 PM
> > com.opensymphony.xwork2.config.providers.InterceptorBuilder
> > constructInterceptorReference
> > WARNING: Unable to load config class
> > org.apache.struts2.jsf.FacesSetupInterceptor at interceptor -
> > jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:57:97
> >
> > probably due to a missing jar, which might be fine if you never plan
> > to use the jsfSetup interceptor
> > Sep 11, 2006 5:21:09 PM
> > com.opensymphony.xwork2.config.providers.InterceptorBuilder
> > constructInterceptorReference
> > WARNING: Unable to load config class
> > org.apache.struts2.jsf.RestoreViewInterceptor at interceptor -
> > jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:58:100
> >
> > probably due to a missing jar, which might be fine if you never plan
> > to use the jsfRestore interceptor
> > Sep 11, 2006 5:21:09 PM
> > com.opensymphony.xwork2.config.providers.InterceptorBuilder
> > constructInterceptorReference
> > WARNING: Unable to load config class
> > org.apache.struts2.jsf.ApplyRequestValuesInterceptor at interceptor -
> > jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:59:105
> >
> > probably due to a missing jar, which might be fine if you never plan
> > to use the jsfApply interceptor
> > Sep 11, 2006 5:21:09 PM
> > com.opensymphony.xwork2.config.providers.InterceptorBuilder
> > constructInterceptorReference
> > WARNING: Unable to load config class
> > org.apache.struts2.jsf.ProcessValidationsInterceptor at interceptor -
> > jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:60:108
> >
> > probably due to a missing jar, which might be fine if you never plan
> > to use the jsfValidate interceptor
> > Sep 11, 2006 5:21:09 PM
> > com.opensymphony.xwork2.config.providers.InterceptorBuilder
> > constructInterceptorReference
> > WARNING: Unable to load config class
> > org.apache.struts2.jsf.UpdateModelValuesInterceptor at interceptor -
> > jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:61:105
> >
> > probably due to a missing jar, which might be fine if you never plan
> > to use the jsfUpdate interceptor
> > Sep 11, 2006 5:21:09 PM
> > com.opensymphony.xwork2.config.providers.InterceptorBuilder
> > constructInterceptorReference
> > WARNING: Unable to load config class
> > org.apache.struts2.jsf.InvokeApplicationInterceptor at interceptor -
> > jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:62:105
> >
> > probably due to a missing jar, which might be fine if you never plan
> > to use the jsfInvoke interceptor
> >
> > ---------------------------------------------------------------------
> > 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
[Proposal] Framework plugin architecture (was Re: [s2] Logging levels)
Posted by Don Brown <mr...@twdata.org>.
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.
A plugin would consist of:
- struts-default.xml: A Struts config file defining the interceptors,
interceptor stacks, results, packages, and/or actions
- The Java classes and resources
On startup, Struts would search for and load all the struts-default.xml
files first, then load the application-specific struts.xml files. This
would allow you to easily install and use a plugin as easily as copying
a jar file into your application.
Each plugin's would define its own package that contains its results,
interceptors, and actions. Then, for an application to use the plugin,
simply have its packages extend the plugin's package(s):
<package name="myApp" extends="default,jsf,jasper">....</package>
Initial candidates for plugins would be:
- JSF support
- Jasper Reports support
- Pell support
To implement this proposal, we would need to split out the jasper, pell,
and jsf code into their own artifacts and give them their own
struts-default.xml file. We could extend the framework idea to extract
any code that uses an optional jar, including support for things like
Spring or Velocity. This would make a nice one-to-one mapping between
optional jars and their Struts plugin, and would simplify core to boot.
Of course, this would be targeted for 2.0.1 :)
Don
Ted Husted wrote:
> On 9/11/06, Don Brown <mr...@twdata.org> wrote:
>> Make sure you get the latest xwork, as a lot of the changes where in
>> there.
>
> I updated XWork, but now there are even more logging statements than
> before :(
>
> Sep 11, 2006 5:21:05 PM org.apache.catalina.startup.Catalina start
> INFO: Server startup in 2546 ms
> Sep 11, 2006 5:21:06 PM
> com.opensymphony.xwork2.config.providers.InterceptorBuilder
> constructInterceptorReference
> WARNING: Unable to load config class
> org.apache.struts2.jsf.FacesSetupInterceptor at interceptor -
> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:57:97
>
> probably due to a missing jar, which might be fine if you never plan
> to use the jsfSetup interceptor
> Sep 11, 2006 5:21:06 PM
> com.opensymphony.xwork2.config.providers.InterceptorBuilder
> constructInterceptorReference
> WARNING: Unable to load config class
> org.apache.struts2.jsf.RestoreViewInterceptor at interceptor -
> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:58:100
>
> probably due to a missing jar, which might be fine if you never plan
> to use the jsfRestore interceptor
> Sep 11, 2006 5:21:06 PM
> com.opensymphony.xwork2.config.providers.InterceptorBuilder
> constructInterceptorReference
> WARNING: Unable to load config class
> org.apache.struts2.jsf.ApplyRequestValuesInterceptor at interceptor -
> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:59:105
>
> probably due to a missing jar, which might be fine if you never plan
> to use the jsfApply interceptor
> Sep 11, 2006 5:21:06 PM
> com.opensymphony.xwork2.config.providers.InterceptorBuilder
> constructInterceptorReference
> WARNING: Unable to load config class
> org.apache.struts2.jsf.ProcessValidationsInterceptor at interceptor -
> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:60:108
>
> probably due to a missing jar, which might be fine if you never plan
> to use the jsfValidate interceptor
> Sep 11, 2006 5:21:06 PM
> com.opensymphony.xwork2.config.providers.InterceptorBuilder
> constructInterceptorReference
> WARNING: Unable to load config class
> org.apache.struts2.jsf.UpdateModelValuesInterceptor at interceptor -
> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:61:105
>
> probably due to a missing jar, which might be fine if you never plan
> to use the jsfUpdate interceptor
> Sep 11, 2006 5:21:06 PM
> com.opensymphony.xwork2.config.providers.InterceptorBuilder
> constructInterceptorReference
> WARNING: Unable to load config class
> org.apache.struts2.jsf.InvokeApplicationInterceptor at interceptor -
> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:62:105
>
> probably due to a missing jar, which might be fine if you never plan
> to use the jsfInvoke interceptor
> Sep 11, 2006 5:21:09 PM
> com.opensymphony.xwork2.config.providers.InterceptorBuilder
> constructInterceptorReference
> WARNING: Unable to load config class
> org.apache.struts2.jsf.FacesSetupInterceptor at interceptor -
> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:57:97
>
> probably due to a missing jar, which might be fine if you never plan
> to use the jsfSetup interceptor
> Sep 11, 2006 5:21:09 PM
> com.opensymphony.xwork2.config.providers.InterceptorBuilder
> constructInterceptorReference
> WARNING: Unable to load config class
> org.apache.struts2.jsf.RestoreViewInterceptor at interceptor -
> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:58:100
>
> probably due to a missing jar, which might be fine if you never plan
> to use the jsfRestore interceptor
> Sep 11, 2006 5:21:09 PM
> com.opensymphony.xwork2.config.providers.InterceptorBuilder
> constructInterceptorReference
> WARNING: Unable to load config class
> org.apache.struts2.jsf.ApplyRequestValuesInterceptor at interceptor -
> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:59:105
>
> probably due to a missing jar, which might be fine if you never plan
> to use the jsfApply interceptor
> Sep 11, 2006 5:21:09 PM
> com.opensymphony.xwork2.config.providers.InterceptorBuilder
> constructInterceptorReference
> WARNING: Unable to load config class
> org.apache.struts2.jsf.ProcessValidationsInterceptor at interceptor -
> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:60:108
>
> probably due to a missing jar, which might be fine if you never plan
> to use the jsfValidate interceptor
> Sep 11, 2006 5:21:09 PM
> com.opensymphony.xwork2.config.providers.InterceptorBuilder
> constructInterceptorReference
> WARNING: Unable to load config class
> org.apache.struts2.jsf.UpdateModelValuesInterceptor at interceptor -
> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:61:105
>
> probably due to a missing jar, which might be fine if you never plan
> to use the jsfUpdate interceptor
> Sep 11, 2006 5:21:09 PM
> com.opensymphony.xwork2.config.providers.InterceptorBuilder
> constructInterceptorReference
> WARNING: Unable to load config class
> org.apache.struts2.jsf.InvokeApplicationInterceptor at interceptor -
> jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:62:105
>
> probably due to a missing jar, which might be fine if you never plan
> to use the jsfInvoke interceptor
>
> ---------------------------------------------------------------------
> 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
Re: [s2] Logging levels
Posted by Ted Husted <hu...@apache.org>.
On 9/11/06, Don Brown <mr...@twdata.org> wrote:
> Make sure you get the latest xwork, as a lot of the changes where in there.
I updated XWork, but now there are even more logging statements than before :(
Sep 11, 2006 5:21:05 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 2546 ms
Sep 11, 2006 5:21:06 PM
com.opensymphony.xwork2.config.providers.InterceptorBuilder
constructInterceptorReference
WARNING: Unable to load config class
org.apache.struts2.jsf.FacesSetupInterceptor at interceptor -
jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:57:97
probably due to a missing jar, which might be fine if you never plan
to use the jsfSetup interceptor
Sep 11, 2006 5:21:06 PM
com.opensymphony.xwork2.config.providers.InterceptorBuilder
constructInterceptorReference
WARNING: Unable to load config class
org.apache.struts2.jsf.RestoreViewInterceptor at interceptor -
jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:58:100
probably due to a missing jar, which might be fine if you never plan
to use the jsfRestore interceptor
Sep 11, 2006 5:21:06 PM
com.opensymphony.xwork2.config.providers.InterceptorBuilder
constructInterceptorReference
WARNING: Unable to load config class
org.apache.struts2.jsf.ApplyRequestValuesInterceptor at interceptor -
jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:59:105
probably due to a missing jar, which might be fine if you never plan
to use the jsfApply interceptor
Sep 11, 2006 5:21:06 PM
com.opensymphony.xwork2.config.providers.InterceptorBuilder
constructInterceptorReference
WARNING: Unable to load config class
org.apache.struts2.jsf.ProcessValidationsInterceptor at interceptor -
jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:60:108
probably due to a missing jar, which might be fine if you never plan
to use the jsfValidate interceptor
Sep 11, 2006 5:21:06 PM
com.opensymphony.xwork2.config.providers.InterceptorBuilder
constructInterceptorReference
WARNING: Unable to load config class
org.apache.struts2.jsf.UpdateModelValuesInterceptor at interceptor -
jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:61:105
probably due to a missing jar, which might be fine if you never plan
to use the jsfUpdate interceptor
Sep 11, 2006 5:21:06 PM
com.opensymphony.xwork2.config.providers.InterceptorBuilder
constructInterceptorReference
WARNING: Unable to load config class
org.apache.struts2.jsf.InvokeApplicationInterceptor at interceptor -
jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:62:105
probably due to a missing jar, which might be fine if you never plan
to use the jsfInvoke interceptor
Sep 11, 2006 5:21:09 PM
com.opensymphony.xwork2.config.providers.InterceptorBuilder
constructInterceptorReference
WARNING: Unable to load config class
org.apache.struts2.jsf.FacesSetupInterceptor at interceptor -
jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:57:97
probably due to a missing jar, which might be fine if you never plan
to use the jsfSetup interceptor
Sep 11, 2006 5:21:09 PM
com.opensymphony.xwork2.config.providers.InterceptorBuilder
constructInterceptorReference
WARNING: Unable to load config class
org.apache.struts2.jsf.RestoreViewInterceptor at interceptor -
jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:58:100
probably due to a missing jar, which might be fine if you never plan
to use the jsfRestore interceptor
Sep 11, 2006 5:21:09 PM
com.opensymphony.xwork2.config.providers.InterceptorBuilder
constructInterceptorReference
WARNING: Unable to load config class
org.apache.struts2.jsf.ApplyRequestValuesInterceptor at interceptor -
jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:59:105
probably due to a missing jar, which might be fine if you never plan
to use the jsfApply interceptor
Sep 11, 2006 5:21:09 PM
com.opensymphony.xwork2.config.providers.InterceptorBuilder
constructInterceptorReference
WARNING: Unable to load config class
org.apache.struts2.jsf.ProcessValidationsInterceptor at interceptor -
jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:60:108
probably due to a missing jar, which might be fine if you never plan
to use the jsfValidate interceptor
Sep 11, 2006 5:21:09 PM
com.opensymphony.xwork2.config.providers.InterceptorBuilder
constructInterceptorReference
WARNING: Unable to load config class
org.apache.struts2.jsf.UpdateModelValuesInterceptor at interceptor -
jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:61:105
probably due to a missing jar, which might be fine if you never plan
to use the jsfUpdate interceptor
Sep 11, 2006 5:21:09 PM
com.opensymphony.xwork2.config.providers.InterceptorBuilder
constructInterceptorReference
WARNING: Unable to load config class
org.apache.struts2.jsf.InvokeApplicationInterceptor at interceptor -
jar:file:/C:/opt/Apache/Tomcat-5.5/webapps/struts2-mailreader/WEB-INF/lib/struts2-core-2.0.0.jar!/struts-default.xml:62:105
probably due to a missing jar, which might be fine if you never plan
to use the jsfInvoke interceptor
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Logging levels
Posted by Don Brown <mr...@twdata.org>.
Make sure you get the latest xwork, as a lot of the changes where in there.
In a nutshell, here is how it works:
- If the results or interceptors throw any exceptions, fail fast as
possible
- Therefore, if a result or interceptor wants to be "optional", meaning
initialize fine even if its dependencies are missing, then it should do
so, but complain loudly when it is actually used.
So, it is all up to the specific interceptor/result if it wants to be
"optional" or not. The framework takes any exceptions thrown seriously
and by default, treats everything as required.
Therefore, I modified the JSF stuff to not complain during
initialization, only during first use. In the case of Jasper where the
interceptor class itself might not be available, I think we should
distribute an "extras"-specific struts-default.xml in the extras jar.
Now that XWork can load multiple instances of a given file name, we
should take advantage of it when defining extras components.
Don
Ted Husted wrote:
> I'm bringing this up because we've closed WW-1424 and I'm not sure
> what we did. The referenced commits did a lot of other things, and I
> can't see the trees for the forest.
>
> With devmode=false, we are emitting 16 INFO lines on startup, mainly
> dealing with partially loaded interceptors and result.
>
> With devmode=true, we are 58 logging lines on startup, some of which
> seem to be redundant INFO reports regarding partially-loaded
> interceptors and results.
>
> We are issuign these loggging statements because the default framework
> configuration includes support for interceptors and results that
> include JARs not provided in the framework distribution.
>
> The thought is that by pre-configuring these members, people who want
> to use features like JSF and JasperReports need only to add the JAR.
> They do not need to take the extra step of adding a configuration
> stanza to their struts.xml. Hence, the framework is simpler for people
> who want to use such things.
>
> IMHO, true simplicity is elegant. I continue to think
> partially-loading interceptors is an inelegant solution. A truly
> simple solution doesn't make other things harder. In my mind, foisting
> apologetic logging statements on every developer every time we launch
> an application is making everyday life harder.
>
> The current approach is trying to simulate technology that we don't
> have. If we want drop-and-play plugins, then let's implement the
> technology.
>
> Until then, let's live with the fact that people who want to use JSF
> or JasperReports will have to add an XML stanza to their configuration
> file, just like we do for Maven plugins.
>
> But, out-of-the-box, with devmode turned off, we should not issue
> logging statements about conditions that are nominal, when using the
> framework in a default, nothing-added configuration.
>
> -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