On 9/29/06, Don Brown <[EMAIL PROTECTED]> wrote:
While Struts 2 requires Java 5 to build, we are using Retrotranslator to
produce a Java 1.4-compatible jar and in addition, all annotations are
and will be optional.
Don
Well, pardon my ignorance, and apologies for going (slightly) off
topic here, but ..
Unless there is a way to easily change annotations without
recompiling, could there be a way to generate the struts.xml file for
a jar - which, once generated, takes precedence over the annotations?
Having to look up some source code and recompile the class just to
change a configuration parameter .. - when it comes to third-party
apps, or maintenance in x years, that's something to keep in mind.
Phil
[EMAIL PROTECTED] wrote:
> 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 <[email protected]>
>>> 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]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Java/XML Programmer
"Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live." - John F. Woods
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
