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
[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 <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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
