Overview

To upgrade your application from one version of the Java Stack to another you simply need to:

  • Change your stack-master parent pom version to the desired stack version.
  • Review any explicitly set Stack module dependency versions as well as any Maven properties that may be forcing a specific version of a Stack module. Determine if that explicitly set version or property is still needed. If not, then removing that explicitly set version or Maven property will return control of version management for any affected module dependencies to stack-master.

Occasionally the Java Stack team must introduce potential compatibility breaking changes to one or more of the modules in a Stack release. For a list of these changes review the version upgrade notes below.

Upgrading from Stack Master 3.4.1 to 3.4.2

This release primarily supports Cloud Foundry deployment and addresses several bug fixes. Due to a bug that was not discovered until after the release of 3.4.2, it is necessary for all projects that use Stack ALM Promotion to make the following change (in your project's root pom.xml):

<project>
    ...
    <properties>
        <!-- Remove the following property when you upgrade to any stack version > 3.4.2 -->
        <stackTcatVersion>1.2.2</stackTcatVersion>
        ...
    </properties>
    ...
</project>
                

Upgrading from Stack Master 3.4.0 to 3.4.1

Maven 3.1.x is supported as of Java Stack 3.4.1. The Java Stack remains compatible with Maven 3.0.x.

The cglib changes for Spring 3.2 were back ported to work with the ICS Legacy Stack (2.0 and prior). Older projects looking to update or upgrade to the latest stack can now successfully migrate.

Possible Ehcache collisions exist for projects that may contain direct or indirect transitive dependencies. Projects need to insure that the final result of Ehcache in their artifacts are set at 2.6.6 and not 2.7.x for best results.

Upgrading from Stack Master 3.3.1 to 3.4.0

The Stack Starter now requires the Java 7 runtime environment to start up. All Java Stack modules are still compiled to Java 1.6 and the option to choose 1.6 as the target Java version is still available but will be removed in a future release. While we will continue to support JDK 1.6, Oracle has announced that JDK 1.6 is at the end of its life and it will not receive any additional security or bug fixes. We are encouraging teams with projects under active development or maintenance to upgrade to JDK 1.7 as soon as possible. JDK 1.7 can be downloaded for Windows, Mac, and Linux from the following site:

http://www.oracle.com/technetwork/java/javase/downloads/index.html.

This Java Stack release also contains significant upgrades to bring it up to date with the latest CXF release as well as to provide support for the latest Java REST API, JAX-RS 2.0. This update provides many additional features to simplify defining and easily consuming REST web services. Accordingly, the Stack RS (REST) and Stack WS (SOAP) integration libraries have also been upgraded to leverage the latest CXF APIs and to remove deprecated features. There is a known issue with Soap + WAM integration in Java 6 runtime environments. This issue is not present when the Soap+WAM is running in a Java 7 runtime environment. If you experience issues, please contact a member of the Java Stack Team.

IMPORTANT NOTE: If you are using our stack-legacy module in your project, you should not upgrade to version 3.4.0 of the Stack at this time. Due to the upgrade of Spring to version 3.2.4, there will be conflicting CGLib libraries found on the classpath, which cause incompatibilities with many of our modules. We will resolve this in our next maintenance release.

This release has also changed the name of the "stack-test-unit" testing utilities library to "stack-test-api" in order to keep test utility APIs confined to a single dependency. If you are using this library in your project, you will need to modify the "stack-test-unit" artifactId to "stack-test-api" and change the package name in your source code from org.lds.stack.test.unit to org.lds.stack.test.

Stack QA has been deprecated and removed from Stack Master version management. The recommended way to manage test environment profiles is using the Spring profiles feature. You can learn more about Spring environment profiles in the following article:

Spring blog.

Projects still wishing to use the Stack QA module to manage test environment properties will need to specify the dependency version manually in web/pom.xml and qa/pom.xml as in the following example:

<dependency>
    <groupId>org.lds.stack.qa</groupId>
    <artifactId>stack-qa</artifactId>
    <version>3.1.4</version>
</dependency>
			

Another way to learn about Spring Environment Profiles is to create a new Stack Starter project, copy the TestEnvConfiguration class from the QA module into your project, and then review the examples for injecting environment properties into your tests. See a member of the Java Stack team if you require assistance.

For projects that use AspectJ, there is an issue with the maven-compiler-plugin that causes it to re-compile Java sources after the aspectj-maven-plugin has already compiled, resulting in the instrumented classfiles being obliterated. The current workaround is to prevent the maven-compile-plugin from running:

<properties>
    <maven.main.skip>true</maven.main.skip>
</properties> 

Be assured, the aspectj-maven-plugin is compiling your .java sources, so the maven-compiler-plugin is entirely superfluous when the ajc is used.

Upgrading from Stack Master 3.3.0 to 3.3.1

This release contains significant modifications to the Stack Security Web module. Most of the changes are either internal functional changes or additional API methods, so code written against earlier versions should work without change. The only exception to this is if you use the EncodingUtils.getEncoder() method in your application code. If that's the case, then simply use the EncodingUtils.getDecoder() method (if you are using the decoding functionality) or use the applicable encoding function in the org.owasp.encoder.Encode class.

Upgrading from Stack Master 3.2.8 to 3.3.0

Breaking change: We have updated the version of WAM Emulator that is used by the Java Stack from 5.54 to 7.0.1. This version of the WAM Emulator leverages Policy Exposee files, which is the format that is used by the WAM servers. As such, your current WAM Emulator configuration will need to be modified to match the new format. There are three ways to assist you in correctly converting your files:

  1. WAM Emulator 7.0.x documentation: https://tech.lds.org/wiki/7.x_Config_File_Syntax
  2. Check out the source code for the Pet Store example application.
  3. Create a sample Stack application using the Stack Starter application. Instructions are provided in the Getting Started section.

This release includes a minor update to DB Migrator. We added a feature coined credential fallback. It allows you to specify credential properties without the schema prefix. This is especially useful if you have more than one schema folder that each share the same database credentials since you can provide them once instead of once per schema folder. See the reference docs for more information.

Upgrading from Stack Master 3.2.7 to 3.2.8

This release includes a significant update to DB Migrator. The SQL Parser has been almost completely rewritten. It therefore (hopefully) has fewer weaknesses and behaves more like other SQL tools.

  • The "custom migration" functionality, where you specify via property which scripts should be run, has changed. Those db.scriptsToMigrate and db.scriptsToReverse properties are obsolete. Please review the reference documentation before attempting a custom migration.
  • Single quotes in comments are no longer problematic.
  • Comments are now acceptable after a terminating semi-colon.
  • Create or replace package... or other pl/sql type object can now span multiple lines and the type will be detected properly.
  • The version prefix of the script name can now have a decimal and/or multiple under scores. Please see the reference documentation for more details.
  • Please check your scripts for the --@unparsed_statement annotation (and the end tag) to determine if it is still required considering the new parser functionality.
  • The docs have always incorrectly indicated that variable substitution was not performed on unparsed statements. Now DB Migrator will not perform variable substitution unless you indicate otherwise (see reference doc.)
  • Terminating a regular SQL statement with a forward slash was previously allowed. Consistent with other tools it is no longer allowed. A forward slash can only terminate a PL/SQL type statement.
  • Exec statements are now ignored instead of causing an error. Use the call statement or an anonymous block if you need this functionality.
  • The drop script is now more complete and includes materialized views, scheduled jobs, operators, java objects, dimensions, clusters, and indextype
  • The drop script can be configured to ignore materialized views, queues, scheduled jobs, and java objects. Please see the reference documentation for more information.
  • A whitelist feature was added to prevent the drop or remigrate goals from being executed in production environments. This feature is off by default.

Upgrading from Stack Master 3.2.6 to 3.2.7

This is a non required upgrade step. In Stack 3.2.6 we released a new Tcat/Mulesoft deployment process that is faster and more stable than the previous. If you wish to move to this new deployment tools do the following:

  • Warn our ASE that you are making this change
  • Open your alm/pom.xml
  • Change any references to goal=deploy in your "stack-tcat-maven-plugin" definition to goal=file-deploy
  • After deployment to a Tcat server you should be able to delete the "Deployment" from the tcat console for that environment.
  • If you have any problems please consult a member of the Java Stack team.

Upgrading from Stack Master 3.2.5 to 3.2.6

Nothing.

Upgrading from Stack Master 3.2.4 to 3.2.5

The version of DB Migrator that ships with 3.2.5 has a bug in substitution variables. This bug has been fixed in DB Migrator 4.0.11. Please add the following lines to the properties section of your top-level pom.xml if you are upgrading to version 3.2.5 of the java stack.

<!-- Remove this version override to DB Migrator 4.0.11 when stack-master is version 3.2.6 or greater -->
<stackDBMigratorVersion>4.0.11</stackDBMigratorVersion>
			

TestNG suite XML files can now be included in your QA project's src/test/resources folder, and can be referenced in your ALM module's profile properties using suiteXmlResources, which accepts a comma-delimited list of suite XML resource names. Supplying one or more TestNG suite XML files will cause those suites to be run instead of the default suite that runs all annotated test classes starting or ending in "FT".

Upgrading from Stack Master 3.2.3 to 3.2.4

Atomikos was upgraded to 3.8.0. In this upgrade atomikos changed their logging identifier. Unless you like tons of Atomikos Spam in your logs find your deploy/src/main/resources/*.logging.properties files and replace:

atomikos.level=WARNING
			

With:

com.atomikos.level=WARNING
			

If you don't have any atomikos logging property in the file do nothing.

Due to changes in LdsAccount - GDIR and the directory team consolidating ou=int/ou=ext into ou=people, if you were using <user-search-template type="internal" /> then you will be broken as this option has been removed and is no longer available. Please use type="people" (the default) instead. Also note that this is no longer searching only internal (or workforce / Church employees), which was probably the originally intended use. The correct way to differentiate between an employee and a non-employee is to look at the employeestatus attribute of a user. This attribute must have a value of TRUE or A to be an employee. If this attribute has a value of I or is nonexistent on a user, then the user is not an employee.

Also note that if you are doing something like this <user-search user-search-base="ou=int|ou=ext ..." ... /> you should change the search base for this as well.

In your web.xml remove all dispatcher entries for the springSecurityFilterChain mapping, or the Seam Filter mapping (depending on which one you have defined - most likely determined by whether you upgraded from a 2.x application or not). For instance,

<filter-mapping>
	<filter-name>springSecurityFilterChain</filter-name>
	<url-pattern>/*</url-pattern>
	<dispatcher>REQUEST</dispatcher>
	<dispatcher>FORWARD</dispatcher>
	<dispatcher>INCLUDE</dispatcher>
	<dispatcher>ERROR</dispatcher>
</filter-mapping>
				
would become
<filter-mapping>
	<filter-name>springSecurityFilterChain</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>
				
and
<filter-mapping>
	<filter-name>Seam Filter</filter-name>
	<url-pattern>/*</url-pattern>
	<dispatcher>REQUEST</dispatcher>
	<dispatcher>FORWARD</dispatcher>
	<dispatcher>INCLUDE</dispatcher>
	<dispatcher>ERROR</dispatcher>
</filter-mapping>
				
would become
<filter-mapping>
	<filter-name>Seam Filter</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>
				

You may need to make the following changes to ensure that redirects still work properly, depending on when your project was originally created. In server.xml, make sure that the RemoteIpValve has variables for clientHttpPort and clientHttpsPorts as shown below. You will additionally need to provide values for these variables in your catalina.properties files for each environment. So anyway, if it does not already, your RemoteIpValve should be modified to look as follows:

<Valve className="org.apache.catalina.valves.RemoteIpValve"
	 protocolHeader="X-Forwarded-Scheme"
	 httpServerPort="${clientHttpPort}"
	 httpsServerPort="${clientHttpsPort}"/>
				
In your local.catalina.properties you will need these properties do not already exist. These values are sent to Tomcat so that URL's are built properly. Specify the port numbers as they would appear in the browser of someone using the application.
clientHttpPort=8080
clientHttpsPort=8443
				
And for the remainder of your *.catalina.properties file(s) such as dev, test, uat, stage, prod, ..., you will need to add something like the following, if they do not already exist:
clientHttpPort=80
clientHttpsPort=443
				

Upgrading from Stack Master 3.2.2 to 3.2.3

Nothing.

Upgrading from Stack Master 3.2.1 to 3.2.2

Nothing.

Upgrading from Stack Master 3.2 to 3.2.1

If you are using the ROLE_WORKFORCE granted authority in your application, the attribute used to determine this has changed. It used to determine if a person was workforce from 'employeeType' or 'workforceID'. Now this is determined based on 'employeeStatus'. Accordingly, if you are using this role, you should verify that your data access agreement will allow that the LDAP attribute 'employeeStatus' is accessible and that it is populated, or sent as a WAM header (policy-employeestatus) in the case of WAM, so that the correct role will be populated. In short, if using WAM, and if you were previously sending the policy-workforceid, you should instead (or additionally) send the policy-employeestatus header.

Upgrading from Stack Master 3.2-rc2 to 3.2

  • The @TestConfigProperty annotation is now only applicable to static fields in a test constants class. It is no longer applicable to the test constants class itself. In previous versions of the Java Stack, this annotation was used by the Stack QA module to scan for test constant classes so that test environment properties could be injected into the static fields of those classes. In Java Stack 3.2, scanning the classpath for test constants classes is no longer necessary because the Stack QA module now provides a TestConfig operation that will perform test property injection during static initialization of the class as soon as the class is first accessed by your functional/integration tests.

    In consequence of this change, test constants classes previously annotated with the @TestConfigProperty will need the simple modifications described below:

    1. Remove the @TestConfigProperty annotation from test constants class. (You may continue to use this optional annotation on the static fields of the test constants class.)
    2. Modify the static initializer that invokes the TestConfig constructor so that the new TestConfig instance invokes the applyConfiguration method. Supply this method the test constants class instance whose static fields are to be configured from the test environment properties.
    3. Finally, you may remove the testEnv.constants.package property from your test environment properties files as it this property is no longer used.

    When you are finished, your test constants class should look something like the following:

    import org.lds.stack.qa.TestConfig;
    
    public final class Constants {
    
    	static {
    		new TestConfig().applyConfiguration(Constants.class);
    	}
    
    	// ... optionally annotated fields to be assigned from test
    	// environment properties ...
    }
    					

Upgrading from Stack Master 3.2-rc1 to 3.2-rc2

  • If you were using the <lds-account:ldap-server ... > element, which you most likely were if utilizing ldap authentication, i.e. something like <lds-account:global-directory-authentication-provider ... > in 3.1.x, or <lds-account:ldap ... > in 3.2-beta-x, we modified the namespace handler to validate TLS certificates by default, where they were not validated before. Accordingly you will probably get a cert error after upgrading. Instructions for fixing this can be found here - https://tech.lds.org/wiki/LDS_Certs_and_Java, and background information and reasoning behind this decision can be found here - http://code.lds.org/maven-sites/stack/modules/lds-account/4.0.1-SNAPSHOT/stack-lds-account-spring/index.html#LDAP_%28Global_Directory%29_Authentication.

Upgrading from Stack Master 3.1.x to 3.2-rc1

  • The maven-failsafe-plugin has been removed from the parent stack-thirdparty POM in order to prevent it from being executed for projects that don't need it. As a result, you will need to add the maven-failsafe-plugin to the POMs of your web and qa projects if it is not already defined.
    <plugin>
    	<groupId>org.apache.maven.plugins</groupId>
    	<artifactId>maven-failsafe-plugin</artifactId>
    </plugin>
    					
  • Test Runner is now integrated into the Java Stack. All new QA projects built with the Stack Starter will automatically be packaged and executed as a Test Runner bundle. To upgrade an existing QA project to be packaged and executed as a test bundle, simply change the packaging type within your qa/pom.xml file to test-bundle
  • A few of our maven version properties have been renamed:
    • aqapiVersion is now oracleAqapiVersion
    • ucpVersion is now oracleUcpVersion
  • The artifactIds of some maven dependencies have changed:
    • servlet-api is now javax.servlet-api
    • jsp-api is now javax.servlet.jsp-api
  • To upgrade to Tomcat 7 make the following changes:
    • Make the following changes to your deploy/src/main/resources/server.xml.
      • Remove the className attribute from <Server> element.
      • Remove the following listener from deploy/src/main/resources/server.xml
        <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" />
        									
      • Add the follwoing listeners to your server.xml:
        <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
        <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
        <Listener className="org.lds.stack.tomcat.decrypt.DecryptingListener"/>
        									
    • Your web/src/main/webapp/WEB-INF/web.xml should be upgraded to the Servlet 3.0 schema by changing the root element of your web.xml file to:
      <web-app xmlns="http://java.sun.com/xml/ns/javaee"
      	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
      	version="3.0" metadata-complete="true">
      							
    • Remove the className attribute from <Conext> element of web/src/main/webapp/META-INF/context.xml.
    • In all of your deploy/src/main/resources/*.catalina.properties files add the following property:
      tomcat.util.scan.DefaultJarScanner.jarsToSkip=${tomcatJarsToSkip}
    • In deploy/src/main/resources/*.web.xml make the following changes:
      • Change the root element to:
        <web-app xmlns="http://java.sun.com/xml/ns/javaee"
        	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
        	version="3.0" metadata-complete="true">
        									
      • Change the param-value of the compilerSourceVM param-name element's param-value to the following:
        <param-name>compilerSourceVM</param-name>
        <param-value>${jdkVersion}</param-value>
        									
      • Change the param-value of the compilerTargetVM param-name element's param-value to the following:
        <param-name>compilerTargetVM</param-name>
        <param-value>${jdkVersion}</param-value>
        									
  • The Apache CXF web services integration has been upgraded to use CXF 2.4. In web services projects, this will require the following changes:
    • In the folder web/src/main/webapp/WEB-INF/ , rename ws-servlet.xml to cxf-servlet.xml .
    • Edit cxf-servlet.xml to remove the spring import of classpath:META-INF/cxf/cxf-extension-jaxrs-binding.xml
    • Edit web/src/main/webapp/WEB-INF/web.xml to change the ws servlet class to org.apache.cxf.transport.servlet.CXFServlet .
  • The stack-qa-selenium and stack-qa-webdriver modules have been combined into stack-qa-selenium v4. The following backwards compatible effecting changes may need to take place in your project:
    • The ${webdriverVersion} and ${stackQAWebdriverVersion} and ${stackQASeleniumVersion} maven properties has been replaced with ${seleniumVersion} and ${stackSeleniumVersion} .
    • References in pom.xml to the artifactIds stack-qa-webdriver and stack-qa-selenium will need to be changed to stack-selenium .
    • Currently stack-qa-selenium doesn't come with a default browser driver so you need to add the following dependency to support firefox:
      <dependency>
      	<groupId>org.seleniumhq.selenium</groupId>
      	<artifactId>selenium-firefox-driver</artifactId>
      </dependency>
      							
    • The WebdriverHelper has been removed. Most of what it did has been replaced with org.lds.stack.selenium.utils.ExpectedConditions . Consult a member of the Stack team if you cannot find an equivalent method.
    • Otherwise all things using the old selenium api have been removed. If you need help reproducing any of this code or wish to upgrade while keeping your old selenium tests consult a member of the Stack team for help in preserving backwards compatibility.
  • LDS Account has been significantly refactored.
    • If you had a dependency on stack-lds-account-spring you will need to add the following dependency
      <dependency>
      	<groupId>org.lds.stack.security</groupId>
      	<artifactId>stack-lds-account-spring-config</artifactId>
      </dependency>
      							
      you will need to remove the following dependency
      <dependency>
      	<groupId>org.lds.stack.security</groupId>
      	<artifactId>stack-lds-account-spring</artifactId>
      </dependency>
      							
      you will now need to also add a dependency for wam or ldap depending on which you are using.
      <dependency>
      	<groupId>org.lds.stack.security</groupId>
      	<artifactId>stack-lds-account-wam-spring</artifactId>
      </dependency>
      							
      <dependency>
      	<groupId>org.lds.stack.security</groupId>
      	<artifactId>stack-lds-account-ldap-spring</artifactId>
      </dependency>
      							
    • Any dependencies on org.lds.stack.wam:stack-wam will need to be changed to org.lds.stack.security:stack-lds-account-wam , or it can be removed if you have a dependency on org.lds.stack.security:stack-lds-account-wam-spring
      • References to http://code.lds.org/schema/spring/lds-account/stack-lds-account-3.0.xsd will need to be changed to http://code.lds.org/schema/spring/lds-account/stack-lds-account-4.0.xsd
      • lds-account:global-directory-authentication-provider and lds-account:account-details-authentication-provider becomes lds-account:ldap. For example:
        <lds-account:global-directory-authentication-provider id="ldapAuthenticationProvider">
        	...
        </lds-account:global-directory-authentication-provider>
        <lds-account:account-details-authentication-provider use-positions-v2-populator="true" delegating-authentication-provider-ref="ldapAuthenticationProvider" />
        									
        would become:
        <lds-account:ldap />
        									
        If you had an authorities populator internal to this element:
        • The authorities-populators element has been moved external to the authentication provider. If you have configuration something like the following previously:
          <lds-account:account-details-authentication-provider use-positions-v2-populator="true" delegating-authentication-provider-ref="ssoAuthenticationProvider">
          	<lds-account:authorities-populators include-defaults="true">
          		...
          	</lds-account:authorities-populators>
          </lds-account:account-details-authentication-provider>
          											
          it would become:
          <lds-account:authorities-populators id="authoritiesPopulators" include-defaults="true">
          	...
          </lds-account:authorities-populators>
          <lds-account:wam authorities-populators-ref="authoritiesPopulators">
          	...
          </lds-account:wam>
          or
          <lds-account:ldap>
          	...
          </lds-account:ldap>
          											
      • DefaultLdsAccountDetailsFactory has been removed, so, if you have configuration like the following:
        <lds-account:ldap-server ... />
        
        <bean id="ldsAccountDetailsFactory" class="org.lds.stack.ldsaccount.DefaultLdsAccountDetailsFactory"/>
        <bean id="ldapSearch" class="org.lds.stack.ldsaccount.spring.ldap.LdapSearch">
        	<property name="ldsAccountDetailsFactory" ref="ldsAccountDetailsFactory" />
        	<property name="searchBase" value="ou=people,o=lds" />
        	<property name="contextSource" ref="contextSource"/>
        </bean>
        									
        you could change it to.
        <lds-account:ldap-server ... />
        
        <bean id="ldsAccountDetailsFactory" class="org.lds.stack.ldsaccount.LdsAccountAttributesDetailsFactoryImpl"/>
        <bean id="ldapSearch" class="org.lds.stack.ldsaccount.spring.ldap.LdapSearch">
        	<property name="ldsAccountDetailsFactory" ref="ldsAccountDetailsFactory" />
        	<property name="searchBase" value="ou=people,o=lds" />
        	<property name="contextSource" ref="contextSource"/>
        </bean>
        									
        Or, even better, we have added an ldap search namespace handler, so this could all become:
        <lds-account:ldap-server ... />
        <lds-account:ldap-search />
        									
    • org.lds.stack.ldsaccount.PositionType has been removed and replaced with org.lds.cdol.constants.PositionType . They were largely duplicates of each other, but if you were using the stack PositionType directly you will need to change the import and possibly fix any differing types.
    • PositionV2AuthoritiesPopulator is now default instead of PositionAuthoritiesPopulator
      • Remove use-positions-v2-populator="true" if you have specified it (this is now the default)
      • If you want to use the old populator, specify use-positions-v2-populator="false"
    • Any references to the LdsAccountDetails object in your view page, being accessed through Spring Security will need to be modified. The LdsAccountDetails object is no longer replacing the Spring Security Authentication details, but is instead in the Spring Security principal. That is to say, any references, such as the following:
      <sec:authentication property="details.displayName" />
      							
      will need to be changed to the pattern below, to access the same data:
      <sec:authentication property="principal.ldsAccountDetails.displayName" />
      							
      i.e. 'details.' now becomes 'principal.ldsAccountDetails.'
    • In addition any code looking like SecurityContextHolder.getContext().getAuthentication().getDetails() will need to change to something more like:
      ((LdsAccountUser) SecurityContextHolder.getContext().getAuthentication().getPrincipal()).getLdsAccountDetails();
      							
    • If you have implemented your own *LdsAccountDetailsFactory (relatively rare), and using WAM authentication, ensure that for accessing properties in your factory implementation, that you are using SsoAttribute constants instead of LdsAccountAttributes constants. In previous versions LdsAccountAttributes was used for both LDAP and WAM projects.
  • Spring Security upgraded from 3.0.5 to 3.1.0. The following changes will be necessary.
    • Any references to http://www.springframework.org/schema/security/spring-security-3.0.xsd will need to be changed to http://www.springframework.org/schema/security/spring-security-3.1.xsd
    • The details-class attribute of the wam element has been removed. The attribute web-authentication-details-source-ref replaces it, but they are not direct equivalents, and the new attribute requires that you create a class that implements org.springframework.security.authentication.AuthenticationDetailsSource<C, T>
    • Any <sec:intercept-url filters="none" /> or <lds-account:intercept-url filters="none" /> should be removed from within the <sec:http ... /> or <lds-account:wam ... /> tags and moved to their own sec:http or lds-account:wam tags with something like the following: <sec:http security="none" pattern="/..." /> or <lds-account:wam security="none" pattern="/..." /> respectively.
  • The Stack Logging module has merged with Stack Utils. Any dependency references to org.lds.stack.logging:stack-logging should be changed to org.lds.stack:stack-utils.
  • We've updated our *LdsAccountContextListeners to support the LDS Account 4 apis. In your applicationContext.xml file you will need to change the BasicLdsAccountContextListener to BasicLdsAccount4ContextListener unless you're using the old lds account apis.
  • The DB Migrator plugin has been upgraded to 4.0. DB Migrator 4.0 has a new format for the DB Migration table. You may consider coordinating this upgrade with your DBE. If you cannot upgrade at this time consult a member of the Java Stack team for steps to continue using the old migrator version. Otherwise the DB Migrator will automatically upgrade your schema migrations table for you by adding the following property to all of your *-db.properties files
    • db.autoUpdateMigrationTables = true

Upgrading from Stack Master 3.1.4 to 3.1.5

  • The Wam emulator has had a default property change. If you are deploying your WAM emulator to a continuous/test environment you will need to add the following inside of the "config" element of your wam-config.xml file.
<port-access local-traffic-only="false"/>
			
  • Spring fixed a bug that makes it so that using injection annotations (@Autowired, @Inject, @PersistenceContext) do not work on methods of @ServiceProxy classes. If you are doing this you will need to move your injection annotation to your Field.

Upgrading from Stack Master 3.1.3 to 3.1.4

  • Upgraded to Selenium 2.0 RC3. Selenium removed the org.openqa.selenium.RenderedWebElement class. Change references to org.openqa.selenium.RenderedWebElement to org.openqa.selenium.WebElement.

Upgrading from Stack Master 3.1.1 to 3.1.2

  • The LdsAccountDetailsFactory interface added an addition method. Accordingly, if you are implementing this interface directly you will have to add an implementation for this method.
  • In this release we upgraded from GWT 2.2 to 2.3. There is a bug in GWT 2.3 regarding inclusion of javax.validation sources that may require you to add the following dependency to your -web pom.xml file.
<dependency>
	<groupId>javax.validation</groupId>
	<artifactId>validation-api</artifactId>
	<version>1.0.0.GA</version>
	<classifier>sources</classifier>
	<scope>provided</scope>
</dependency>
			
  • If you find other problems with GWT 2.3 you can downgrade back to GWT 2.2 by adding the following property to your root pom. 'gwtVersion=2.2.0'

Upgrading from Stack Master 3.1 to 3.1.1

  • The GAV for the "org.owasp:antisamy" dependency has changed to "org.owasp.antisamy:antisamy". You will need to update this dependency in your poms.

Upgrading from Stack Master 3.1-rc1 to 3.1

  • If you have QA or integration tests relying on the qa-webdriver module the helper class was renamed to WebDriverHelper.
  • GWT was upgraded from 2.1 to 2.2. GWT 2.2 is supposed to be backwards compatible but it might be wise to do a retest of the application after the upgrade. If GWT 2.2 doesn't work then you can downgrade by setting the Maven Property 'gwtVersion=2.1.1'

Maven Plugin Changes

Upgrading to Maven 3 allowed us to fix some of tha hacks we had to put into our Maven plugins because of bugs in Maven 2.x. Previously it was necessary to place our "deployable" our packaging goal in a plugin all by itself. With Maven 3 we are now able to combine our packaging goals with other goals. Combining deployable and other goals into a single plugin effects the following plugins:

  • Tomcat Plugins
  • Websphere Plugins
  • DB Migration Plguins

To upgrade the Tomcat Plugins you must:

  • Delete the stack-tomcat-deployable-maven-plugin plugin definition in your deploy project.
  • Rename your stack-tomcat-deploy-maven-plugin plugin artifactId in your deploy and qa projects to stack-tomcat-maven-plugin

To upgrade the Websphere Plugins you must:

  • Delete the stack-was-deloyable-maven-plugin plugin definition in your deploy project
  • Rename your stack-was-deploy-maven-plugin plugin artifactId in your deploy and qa projects to stack-was-maven-plugin

To upgrade the DB Migrator Plugin you must:

  • Delete the stack-db-deployable-maven-plugin definition in your db project
  • We removed a plugin execution for the stack-db-maven-plugin from stack-master. You must add configuration to the stack-db-maven-plugin entry in your db project. To maintain the same "migrate" on build functionality your plugin definition should look like the following:
<build>
	<plugins>
		<plugin>
			<groupId>org.lds.stack.db</groupId>
			<artifactId>stack-db-maven-plugin</artifactId>
			<executions>
				<execution>
					<id>default</id>
					<phase>pre-integration-test</phase>
					<goals>
						<goal>migrate</goal>
					</goals>
				</execution>
			</executions>
		</plugin>
	</plugins>
</build>
				

Upgrading from Stack Master 3.0.1 to 3.1-rc1

  • Maven has been upgraded to Maven 3. To use this version of the Stack you must upgrade the version of Maven on your developer machine and your build boxes to Maven 3.
  • The Pseudo Internationalization Plugin has been entirely re-written. For information on how to configure the new plugin, please see the Pseudo Internationalization Plugin documentation, or contact a member of the Stack team.

Upgrading from Stack Master 3.0 to 3.0.1

  • Streams AQ Users: If your projects is a Websphere project you must upgrade to Websphere 7.0.0.13