> Now if this is the case, may I read this is another configuration XML > file needed? IMO we should try to allow an application to work with > less and less configuration needed, and not the other way around. Or I > am looking at this from the wrong perspective?
I think (if not mistaken) is that the struts-plugin.xml would have the same definition as struts_x_x.dtd (the same definition as the current struts.xml uses). The aim is such that when a jar is added to the classpath, if it has such a struts-plugin.xml, will get its interceptor, packages etc registered just like a normal struts.xml would. The benifit is that we don't need a <include file="..../struts-plugin.xml" /> being defined in struts.xml. I guess thats the main motivation behind this idea. What do you think Alex? rgds ----- Original Message ---- From: Alexandru Popescu <[EMAIL PROTECTED]> To: Struts Developers List <dev@struts.apache.org> Sent: Friday, 29 September, 2006 3:13:19 AM Subject: Re: Struts plugins On 9/29/06, Don Brown <[EMAIL PROTECTED]> wrote: > 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 if this is the case, may I read this is another configuration XML file needed? IMO we should try to allow an application to work with less and less configuration needed, and not the other way around. Or I am looking at this from the wrong perspective? ./alex -- .w( the_mindstorm )p. > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
