I see. > Now, since the names of what configuration files are configurable, you > could change it to load "struts-default.xml, struts-plugin.xml, > struts-plugin-ext.xml, struts.xml" or whatever other files you'd like.
I guess the overall effect is that, struts.xml will be the first to be loaded and then struts-plugin.xml will be loaded in an non-deterministic manner, but we could change the name from "struts-plugin.xml" to something else through an entry in struts.properties. Is this correct? I guess without the ordering is fine, just that I think we should make it clear in the docs that its not really a "plugin" but a convenient way for Struts2 to organize its features. rgds ----- Original Message ---- From: Don Brown <[EMAIL PROTECTED]> To: Struts Developers List <dev@struts.apache.org> Sent: Friday, 29 September, 2006 1:30:11 PM Subject: Re: Struts plugins While I appreciate the idea, I don't particularly think that plugins should be deterministic. Perhaps plugin is the wrong word as it brings to mind descriptors, versioning, dependencies, etc. for some people. In this case, I see it as simply a way to organize code and provide default configuration for that code. Anything that is common to multiple plugins should be pushed into the core. Now, since the names of what configuration files are configurable, you could change it to load "struts-default.xml, struts-plugin.xml, struts-plugin-ext.xml, struts.xml" or whatever other files you'd like. From a core framework POV, I think simply loading struts-plugin.xml in a non-deterministic order is fine for our needs. Don tm jee wrote: > Hi guys, > > Just some thoughts, maybe we could have an order parameter introduced eg > > struts-plugin.xml > <struts> > <param name="order">10</param> > <package ....> > > </package> > </struts> > > So we could have control of which plugin gets the priority when loading and > we could defined order 1-100 is for struts, custom plugin starts from 101 > etc. Ordering for plugins with same ordering would be undefined. The ordering > could maybe applied only to plugin (struts-plugin.xml) as we have just one > bootstrap configuration (struts.xml) > > Thoughts? > > rgds > > > ----- Original Message ---- > From: David H. DeWolf <[EMAIL PROTECTED]> > To: Struts Developers List <dev@struts.apache.org> > Sent: Thursday, 28 September, 2006 12:15:12 AM > Subject: Re: Struts plugins > > Not sure if this is exactly what you're looking for, but the patch to > upgrade from 0.2 to 2.0 exists: > > https://issues.apache.org/struts/browse/WW-1418 > > > > Also, while you're looking at this, here's another patch related to > tiles that I'd be interested in: > > https://issues.apache.org/struts/browse/WW-1450 > > > David > > > Don Brown wrote: > >> Is there any Tiles 2 migration code I can put into a block or does it >> need to be written yet? I do agree it would be a great candidate. >> >> Don >> >> Antonio Petrelli wrote: >> >>> Don Brown ha scritto: >>> >>>> The first batch of plugins: >>>> 1. Configuration Browser >>>> 2. Jasper Reports >>>> 3. JFreeChart >>>> 4. JSF >>>> 5. Pell Multipart handler >>>> 6. Sitemesh >>>> 7. Struts 1 >>>> >>> You forgot Tiles 2 :-) >>> >>> Ciao >>> Antonio >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]