A new Struts confirguration file has been added to the application to support various Email features requests.
The name of the file must be added to the /WEB-INF/web.xml file.
Since that file is not distributed with upgrades, it must be manually upgraded prior to the upgrade.
To execute the change, open the /WEB-INF/web.xml file and update the "config/administrator"
parameter with the following value (adding the reference to ,/WEB-INF/conf/administrator/email/struts-config-email.xml):
<init-param>
<param-name>config/administrator</param-name>
<param-value>/WEB-INF/conf/administrator/core/struts-config.xml,/WEB-INF/conf/administrator/product/struts-config-product.xml,/WEB-INF/conf/administrator/order/struts-config-order.xml,/WEB-INF/conf/administrator/customer/struts-config-customer.xml,/WEB-INF/conf/administrator/importexport/struts-config-importexport.xml,/WEB-INF/conf/administrator/tax/struts-config-tax.xml,/WEB-INF/conf/administrator/shipping/struts-config-shipping.xml,/WEB-INF/conf/administrator/payment/struts-config-payment.xml,/WEB-INF/conf/administrator/administrator/struts-config-administrator.xml,/WEB-INF/conf/administrator/ajax/struts-config-ajax.xml,/WEB-INF/conf/administrator/email/struts-config-email.xml,/WEB-INF/conf/administrator/core/struts-config-custom.xml</param-value>
</init-param>
With the upgrade to 3.3.1, you must remove compiled JSP servlets that the application server has compiled.
With Tomcat this is done by cleaning out the work directory where the JSP files are compiled to.
With the upgrade to 3.3.1, this is a requirement because of a change made to the method signature of Settings.getValue.
Two new custom configuration files should be added to the application manually if you are upgrading to 3.3.1, if you plan to use them. Custom configuration files are designed to allow you to override default configurations, and they are not distributed with upgrades so that your customizations can be preserved. The new features related to Quartz (Enterprise Edition only) and Emails (all editions) have the ability for you to use the below custom configuration files. If you're upgrading from a release prior to 3.3.1 these files have to be added manually since they are not included in the upgrade distribution. Please note, if you have no need to customize Email queries or the Quartz job configurations, the application will run fine without these files. It will place a warning in the application log but continue to run with just the default configurations.
Add /WEB-INF/classes/quartz-jobs-custom.xml with these contents (Enterprise Edition only):
<?xml version='1.0' encoding='utf-8'?>
<job-scheduling-data xmlns="http://www.quartz-scheduler.org/xml/JobSchedulingData"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.quartz-scheduler.org/xml/JobSchedulingData http://www.quartz-scheduler.org/xml/job_scheduling_data_2_0.xsd"
version="2.0">
<processing-directives>
<!-- if there are any jobs/trigger in scheduler of same name (as in this file), overwrite them -->
<overwrite-existing-data>true</overwrite-existing-data>
<!-- if there are any jobs/trigger in scheduler of same name (as in this file), and over-write is false, ignore them rather then generating an error -->
<ignore-duplicates>false</ignore-duplicates>
</processing-directives>
<schedule>
<!-- Insert custom jobs here -->
</schedule>
</job-scheduling-data>
Add /WEB-INF/classes/resources/email/queries-custom.hbm.xml with these contents:
<?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> <hibernate-mapping> <!-- Place custom HQL queries here. To override an existing query in the queries.hbm.xml file, append "-custom" to the query name. The application will look for the "-custom" query first and execute it if it exists. --> </hibernate-mapping>
This upgrade adds new fields to the sscAdministrator database table.
When the first Administrator attempts to log in after the upgrade, the system will automatically attempt to add the new fields.
This must be done separately from the rest of the upgrade SQL scripts because it is necessary in order to log in, and you
must be logged in to run the upgrade scripts. Assuming it is successful, you will be able to log in and run the rest of the
upgrade without doing anything special.
For your reference and if you need to perform the upgrade manually for any reason, you can find the script that adds the new fields in the upgrade distribution at this location:
/WEB-INF/src/resources/upgrades/pre-upgrade_3.3.0_3.3.1_*.sql
If you have subclassed one of the core business object or DAO classes - and specifically if you have overridden the
editDelete* method of any business object or DAO -
you will need to update your subclass's method signature upon upgrading to 3.3.1.
The method signatures for methods beginning with editDelete (such as editDeleteOrders
in BasicOrderProcessor or OrderGatewayDAOHibernate) were modified to add a return type of Map. The
method signatures had been of the form:
public void editDeleteOrders(Map parameters, BusinessObjectFactory bof) throws Exception;
The method signatures are now of the form:
public Map editDeleteOrders(Map parameters, BusinessObjectFactory bof) throws Exception;
In your subclass, you'll now need to return a type of Map for those methods or your customization will not compile after
the upgrade. The simplest way to do this is to simply return null in your subclass. (You need not populate the return value.)
The change was made to support allowing the application to send messages back to the controller layer based on processing that occurs in the business object or DAO layers.
Copyright © 2009-2017 SoftSlate, LLC. All Rights Reserved.
Powered by SoftSlate Commerce