<commit_before>Upgrading Stripes
http://www.stripesframework.org/

This file documents the steps involved in upgrading an application from Stripes
1.4.x to Stripes 1.5. Since Stripes 1.0-1.4.3 have been backwards compatible it
should be possible to apple these steps to upgrade to Stripes 1.5 from earlier
versions also.

Contents
--------
1. Required Steps
2. Suggested Steps
3. Backwards Incompatibilities

1. Required Steps
   --------------
   -> Replace your existing stripes.jar with the new copy from the lib/ directory
      of the distribution.
   -> Replace your existing commons-logging.jar with the new copy from the lib/
      directory of the distribution
   -> If you are using commons-fileupload download the latest version from the
      apache website http://commons.apache.org/downloads/download_fileupload.cgi

2. Suggested Steps
   --------------
   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>
       
   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
     
   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.           

3. Backwards Incompatibilities
   ---------------------------
   Stripes 1.5 is the first major release of Stripes that is not completely
   backwards compatible with earlier versions of Stripes. However most of the
   incompatible change are quite small and require only minor edits to your
   application (often achievable with search & replace functionality). This
   section documents these incompatibilities.

   -> ActionResolver.PackageFilters has been replaced by ActionResolver.Packages
      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 
      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 
      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 
      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.

	-> 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.

	-> 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 sourcePage="true".
	
	-> 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)<commit_msg>Fixed STS-533. Added a note about how _sourcePage is encrypted and you can access the plaintext value through ActionBeanContext. Also corrected the addSourcePage attribute name.<commit_after>Upgrading Stripes
http://www.stripesframework.org/

This file documents the steps involved in upgrading an application from Stripes
1.4.x to Stripes 1.5. Since Stripes 1.0-1.4.3 have been backwards compatible it
should be possible to apple these steps to upgrade to Stripes 1.5 from earlier
versions also.

Contents
--------
1. Required Steps
2. Suggested Steps
3. Backwards Incompatibilities

1. Required Steps
   --------------
   -> Replace your existing stripes.jar with the new copy from the lib/ directory
      of the distribution.
   -> Replace your existing commons-logging.jar with the new copy from the lib/
      directory of the distribution
   -> If you are using commons-fileupload download the latest version from the
      apache website http://commons.apache.org/downloads/download_fileupload.cgi

2. Suggested Steps
   --------------
   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>
       
   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
     
   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.           

3. Backwards Incompatibilities
   ---------------------------
   Stripes 1.5 is the first major release of Stripes that is not completely
   backwards compatible with earlier versions of Stripes. However most of the
   incompatible change are quite small and require only minor edits to your
   application (often achievable with search & replace functionality). This
   section documents these incompatibilities.

   -> ActionResolver.PackageFilters has been replaced by ActionResolver.Packages
      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 
      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 
      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 
      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.

	-> 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.

	-> 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".

	-> 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).

    -> 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)
{'fraction_non_alphanumeric': 0.047615442846328536, 'fraction_numerical': 0.004314912944738835, 'mean_word_length': 3.375952302086784, 'pattern_counts': {'":': 0, '<': 15, '<?xml version=': 0, '>': 54, 'https://': 0, 'lorem ipsum': 0, 'www.': 2, 'xml': 4}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 6, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1917290', 'n_tokens_mistral': 3161, 'n_tokens_neox': 2949, 'n_words': 1682}