Dealing with non-backward compatible code changes

If a developer changes the name of a method of a bean used in a Pod. Then curnits which were created with the old version of the java class, will no longer be loaded.

How to identify this problem

Here is an example exception from that. The key part to focus on is the end.

java.lang.RuntimeException: stop the show
        at net.sf.sail.core.curnit.SAILXMLEncoder$1.exceptionThrown(SAILXMLEncoder.java:63)
        at com.sun.beans.ObjectHandler.getValue(ObjectHandler.java:110)
        at com.sun.beans.ObjectHandler.eval(ObjectHandler.java:128)
        at com.sun.beans.ObjectHandler.startElement(ObjectHandler.java:230)
        at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:491)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:878)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1693)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368)
        at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834)
        at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
        at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
        at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
        at javax.xml.parsers.SAXParser.parse(SAXParser.java:344)
        at javax.xml.parsers.SAXParser.parse(SAXParser.java:120)
        at java.beans.XMLDecoder.readObject(XMLDecoder.java:205)
        at net.sf.sail.core.curnit.CurnitFile.loadPod(CurnitFile.java:152)
        at net.sf.sail.core.curnit.CurnitFile.loadPods(CurnitFile.java:140)
        at net.sf.sail.core.curnit.CurnitFile.getCurnit(CurnitFile.java:102)
        at net.sf.sail.core.session.UrlCurnitProvider.<init>(UrlCurnitProvider.java:56)
        at net.sf.sail.core.service.impl.CurnitUrlProviderImpl.initializeBundle(CurnitUrlProviderImpl.java:60)
        at net.sf.sail.core.bundle.BundleManager.initializeBundles(BundleManager.java:90)
        at net.sf.sail.common.apps.preview.BundleLauncher.launch(BundleLauncher.java:110)
        at net.sf.sail.common.apps.preview.BundleLauncher.launch(BundleLauncher.java:79)
        at net.sf.sail.emf.launch.EMFLauncher2.main(EMFLauncher2.java:27)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at com.sun.javaws.Launcher.executeApplication(Launcher.java:1154)
        at com.sun.javaws.Launcher.executeMainClass(Launcher.java:1101)
        at com.sun.javaws.Launcher.continueLaunch(Launcher.java:944)
        at com.sun.javaws.Launcher.handleApplicationDesc(Launcher.java:515)
        at com.sun.javaws.Launcher.handleLaunchFile(Launcher.java:218)
        at com.sun.javaws.Launcher.run(Launcher.java:165)
        at java.lang.Thread.run(Thread.java:613)
Caused by: java.lang.NoSuchMethodException: <unbound>=AssessmentItem.getReponseDeclarations();
        at java.beans.Statement.invoke(Statement.java:236)
        at java.beans.Expression.getValue(Expression.java:98)
        at com.sun.beans.MutableExpression.getValue(ObjectHandler.java:400)
        at com.sun.beans.ObjectHandler.getValue(ObjectHandler.java:106)
        ... 33 more

Look at the:
java.lang.NoSuchMethodException: <unbound>=AssessmentItem.getReponseDeclarations();

That tells you exactly what the problem is.

How to fix it

Currently, because most curnits are created by converting from wise projects, the solution is make sure the conversion was done with the same version of the code that is being used at runtime.

Background

The conversions have been done using the code in a developers eclipse enviroment.

The runtime code in tels is based on the jnlp used to run the offering. In the current deployment setup there are two main jnlps and their jar files. On the tels-develop these sets of code are managed in the /var/local/maven-jnlp-staging folder:

pas-jnlp
tels-jnlp.

Each of these folders deploys jars to a tomcat server one set of jars is:

On the sds there are different jnlps for these two sets of code.
In portal 1 they are called:

12 PLR Everything (tels-jnlp: Purman release)
8 PLR Everything JDIC Snapshot

In portal 3 they are called:
11 PLR everything JDIC snapshot Richard Purman release
10 plr everything snapshot

Solution 1: Use the snapshot code for the runtime

How to

do a new conversion of the curnit
make sure the snapshot jars are up-to-date by redeploying them: JNLP Deployment
check the offering used by who ever is testing this and make sure it is using the new curnit and the newly released snapshot jars.
Problems
if this is to support a real classroom run, it is dangerous to use the snapshot jars. These jars can be updated at anytime a by multiple developers

Solution 2: Use the tels-jnlp code for the runtime

do everything for solution 1 first and make sure that it works
then go into the tels-jnlp folder on tels-develop and look at update.sh and deploy.sh. It is best to understand these before running them.
run those two script:
```
> ./update.sh
> ./deploy.sh
```
make sure the offering being used by the person testing this is using the tels-jnlp jnlp. This is referred to in portal 1 and 3 as the richard purman release.

Page Operations

Browse Space