Revision: 927
http://stripes.svn.sourceforge.net/stripes/?rev=927&view=rev
Author: bengunter
Date: 2008-05-23 04:48:51 -0700 (Fri, 23 May 2008)
Log Message:
-----------
Fixed some formatting issues. Content has not changed.
Modified Paths:
--------------
trunk/upgrading.txt
Modified: trunk/upgrading.txt
===================================================================
--- trunk/upgrading.txt 2008-05-22 19:20:22 UTC (rev 926)
+++ trunk/upgrading.txt 2008-05-23 11:48:51 UTC (rev 927)
@@ -26,23 +26,23 @@
One significant new feature in Stripes 1.5 that you may wish to leverage at
upgrade
time is the concept of "Extension Packages". Using this feature you can
inform Stripes
of one or more extension packages, e.g.:
- <init-param>
- <param-name>Extension.Packages</param-name>
- <param-value>com.myco.myapp.web.stripesext</param-value>
- </init-param>
-
+ <init-param>
+ <param-name>Extension.Packages</param-name>
+ <param-value>com.myco.myapp.web.stripesext</param-value>
+ </init-param>
+
If one or more packages are specified Stripes will search these packages
for classes
that implement various interfaces and wire them up without requiring you to
configure
them manually in web.xml. This includes custom:
- -> ActionBeanContext classes
- -> Interceptor classes
- -> ConfigurableComponent classes (e.g. ActionResolvers, LocalePickers)
- -> Formatter classes
- -> TypeConverter classes
-
+ -> ActionBeanContext classes
+ -> Interceptor classes
+ -> ConfigurableComponent classes (e.g. ActionResolvers, LocalePickers)
+ -> Formatter classes
+ -> TypeConverter classes
+
To reduce your configuration it is recommended that you move any and all
such
custom classes into a single package hierarchy and specify the root
package. Once
- done you can remove all web.xml configuration for these custom classes.
+ done you can remove all web.xml configuration for these custom classes.
3. Backwards Incompatibilities
---------------------------
@@ -56,69 +56,69 @@
which is now a required configuration property. Changes in class
scanning to
make it more efficient and robust across containers have changed the
meaning
of this property and we have therefore changed the name to reflect this.
If you
- already specified ActionResolver.PackageFilters simply renaming it will
do.
- Otherwise you must specify ActionResolver.Packages to be the list of
root
+ already specified ActionResolver.PackageFilters simply renaming it will
do.
+ Otherwise you must specify ActionResolver.Packages to be the list of root
packages to scan for ActionBeans in your application
- -> Attribute name change in @Before and @After annotations. Previously the
- lifecycle changes were specified using the 'value' attribute which
+ -> Attribute name change in @Before and @After annotations. Previously the
+ lifecycle changes were specified using the 'value' attribute which
allowed the abbreviated form of
'@Before(LifecycleStage.BindingAndValidation)'.
Due to the addition of the 'on' attribute to support selective execution
this
is no longer desirable and the 'value' attribute has been renamed to
'stages'.
In most cases replacing '@Before(' with '@Before(stages=' (and the same
for
@After) will be enough to ix this problem.
- -> The Validatable interface has been removed. Where it was used remove the
+ -> The Validatable interface has been removed. Where it was used remove the
implemented clause from your ActionBean and annotate your validate()
method
with the @ValidationMethod annotation
- -> The link-param tag has been removed in preference to the param tag.
A search
- and replace of 'link-param' to 'param' is sufficient to fix this.
+ -> The link-param tag has been removed in preference to the param tag. A
search
+ and replace of 'link-param' to 'param' is sufficient to fix this.
- -> SpringAwareActionResolver has been removed. Please instead use the
- SpringInterceptor introduced in Stripes 1.3.
-
- -> Stripes now performs stricter checking of various annotations. If you
have
- multiple methods annotated with @DefaultHandler or if you have
@Validate
- annotations in multiple locations (e.g. getter and setter) for a single
- property Stripes will throw an exception instead of producing
non-deterministic
- behaviour.
+ -> SpringAwareActionResolver has been removed. Please instead use the
+ SpringInterceptor introduced in Stripes 1.3.
- -> The _sourcePage parameter is no longer inserted into links (using
the link and
- url tags) by default (it is still submitted in forms). If the
_sourcePage parameter
- is relied on in certain places you can request Stripes insert it
using the new
- attribute addSourcePage="true".
+ -> Stripes now performs stricter checking of various annotations. If you
have
+ multiple methods annotated with @DefaultHandler or if you have @Validate
+ annotations in multiple locations (e.g. getter and setter) for a single
+ property Stripes will throw an exception instead of producing
non-deterministic
+ behaviour.
- -> The _sourcePage parameter is always encrypted to avoid revealing
potentially
- sensitive information. The plaintext value can be easily accessed by
calling
- the new method ActionBeanContext.getSourcePage().
-
- -> The way Interceptor classes are configured has changed. Two
configuration
- properties are supported: 'Interceptor.Classes' and
'CoreInterceptor.Classes'.
- The first has the same name as before but the behaviour has changed.
Now specifying
- this property does NOT require you to specify the interceptors that
Stripes
- executes by default, only additional interceptors you would like to
use. To
- override the set of core interceptors used by Stripes you may now
separately
- specify the 'CoreInterceptor.Classes' property. When upgrading you
should
- remove referenced to the BeforeAfterMethodInterceptor from the
- 'Interceptor.Classes' property.
-
- -> Behaviour of file uploads when using commons-fileupload has changed
to match
- the behaviour when using the cos implementation. When the user does
not provide
- a file a null FileBean will be produced instead of one containing a
zero-length
- file. In addition the filenames returned will never have path
information
- (previously path information would be included if the user was using
IE).
+ -> The _sourcePage parameter is no longer inserted into links (using the
link and
+ url tags) by default (it is still submitted in forms). If the
_sourcePage parameter
+ is relied on in certain places you can request Stripes insert it using
the new
+ attribute addSourcePage="true".
- -> ActionClassCache has been removed. If you require a list of all
ActionBeans
- configured use ActionResolver.getActionBeanClasses() instead.
+ -> The _sourcePage parameter is always encrypted to avoid revealing
potentially
+ sensitive information. The plaintext value can be easily accessed by
calling
+ the new method ActionBeanContext.getSourcePage().
- In addition to the above changes there have also been changes to several
core classes.
- In most cases these changes will be invisible to application developers,
but where you
- have implemented your own ConfigurableComponents from scratch (as opposed
to extending
- the default implementations) you may notice additional interface methods
and changes
- to signatures. Please refer to the javadoc for the 1.5 release in these
cases. The
- following is a non-exhaustive list of core classes with interface changes
in 1.5:
- -> Configuration (and implementations thereof)
- -> ActionResolver (and implementations thereof)
- -> BootstrapPropertyResolver
- -> UrlBuilder
+ -> The way Interceptor classes are configured has changed. Two configuration
+ properties are supported: 'Interceptor.Classes' and
'CoreInterceptor.Classes'.
+ The first has the same name as before but the behaviour has changed. Now
specifying
+ this property does NOT require you to specify the interceptors that
Stripes
+ executes by default, only additional interceptors you would like to use.
To
+ override the set of core interceptors used by Stripes you may now
separately
+ specify the 'CoreInterceptor.Classes' property. When upgrading you should
+ remove referenced to the BeforeAfterMethodInterceptor from the
+ 'Interceptor.Classes' property.
+
+ -> Behaviour of file uploads when using commons-fileupload has changed to
match
+ the behaviour when using the cos implementation. When the user does not
provide
+ a file a null FileBean will be produced instead of one containing a
zero-length
+ file. In addition the filenames returned will never have path
information
+ (previously path information would be included if the user was using IE).
+
+ -> ActionClassCache has been removed. If you require a list of all
ActionBeans
+ configured use ActionResolver.getActionBeanClasses() instead.
+
+ In addition to the above changes there have also been changes to several
core classes.
+ In most cases these changes will be invisible to application developers,
but where you
+ have implemented your own ConfigurableComponents from scratch (as opposed
to extending
+ the default implementations) you may notice additional interface methods
and changes
+ to signatures. Please refer to the javadoc for the 1.5 release in these
cases. The
+ following is a non-exhaustive list of core classes with interface changes
in 1.5:
+ -> Configuration (and implementations thereof)
+ -> ActionResolver (and implementations thereof)
+ -> BootstrapPropertyResolver
+ -> UrlBuilder
This was sent by the SourceForge.net collaborative development platform, the
world's largest Open Source development site.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
