I personally get annoyed when new features are added to products like Struts 2 that require annotations (and hence JDK 1.5). The vast majority of applications deployed in the wild today run on JDK 1.4 since the major App Server vendors are just now stabilizing their line of JDK 1.5 supported products (for example WebLogic 9.x and WebSphere 6.x). So if you want to make using annotations an option, I am all for it... just don't force users' to be running JDK 1.5 in order to use the product.
-----Original Message----- From: Ian Roughley [mailto:[EMAIL PROTECTED] Sent: Friday, September 29, 2006 10:11 AM To: Struts Developers List Subject: Re: Struts plugins Do you see plug-in's being used for enhancing the framework features, for adding "modules" to web apps or both? I ask this because the list of possible plug-ins so far see to be framework related. The ordering that Toby suggested seems to make more sense from a web-app perspective (as features of one web-app may depend on another module being loaded), or both? We should also consider annotations. Using annotations would we need the xml file at all? Or should it be included so that we are declaratively specifying what we want to be running, rather than what's in the classpath. /Ian Don Brown 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, 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] ********************************************************************** This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. ********************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
