WebObjects 5.1 Release Notes

The reason is that the JDBC adaptor is trying to pass attribute values where the stored procedure expects a REF CURSOR.

		public WOResponse dispatchRequest(WORequest request) {
		   String cookieHeader = request.headerForKey("cookie");
		   if (cookieHeader!=null) {
		      String betterCookie = fixCookieValues(cookieHeader);
		      request.setHeader(betterCookie, "cookie");
		   } return super.dispatchRequest(request);
		}

1. In your application directory, save it as Java/foo.jar.
2. Add it to your Resources bucket under a Java directory (on Project Builder WO, you may have to add the Java/foo.jar path directly to the PB.project plist file). When you compile the application, foo.jar will appear at the same level as <your-application>.jar under Contents/Resources/Java.
3. Modify the OTHER_CLASSPATH flag (which is normally commented out) in the Makefile.preamble file so it contains both the deployment and development locations:

OTHER_CLASSPATH = APPROOT/Contents/Resources/Java/
foo.jar$(CLASSPATH_DELIMITER)$(SRCROOT)/Java/foo.jar

The APPROOT identifier in the first path component is ignored during development. At launch time, however, the launch scripts replace APPROOT by the actual application path, which ensures the jar file is available when the application is deployed.

Note that the second path component of OTHER_CLASSPATH is the actual build time location of the foo.jar package. It needs to appear after the deployment path because otherwise the jar file may be picked up when testing the application on a networked development environment.

JAVA_VM = java -server

This can also be accomplished by editing the classpath file directly and setting the value on the line beginning with '# JVM ==', for instance:

# JVM == java -server

Note that if your JVM is an absolute path, and that path contains spaces or other special characters in it, then you must explicitly quote the path to the JVM or the launch script might incorrectly parse this value.

1) The organization of the file groups in the file browser in PB will closely mirror that of the original PBWO project, rather than the organization of the WebObjects Application PB template.
2) Information in the Makefile.preamble and Makefile.postamble files in a PBWO project cannot be processed by project import and will not appear in the PB project.
3) JavaClient applications with a subproject whose Java files are compiled for both the server and the client sides (e.g., a Common.subproj) will have their files linked to only the Application Server target in PB, not also to the Web Server target.
4) The project's signature in the PkgInfo file after compilation will be APPL???? or FMWK???? not APPLwebo or FMWKwebo.
5) The default debugger for an imported project will be gdb, not jdb.
6) Aggregate projects may import strangely, or not at all.

1) File groups can be reorganized in a highly flexible manner in PB. In particular, the file groups representing .subproj folders no longer have any functional purpose in compiling a project in PB - since file organization and build product organization are orthogonal in PB - and those files can be reorganized as desired.
2) Data in Makefile.preamble and Makefile.postamble files must be ported manually after import. Build variables will likely have to be set in the Build Settings panel of one or more targets. Additional targets can be implemented as Shell Script or Copy Files Build Phases on one or more targets.
3) After importing a subproject which contains Java files intended for both the server and the client sides, files can be added to any targets which the import process did not automatically add them to. It is valid for files to be attached to multiple targets in PB.
4) The product signature is defined in the Application Settings or Framework Settings tab of the project's main target (the one with the same name as the project). The CFBundleSignature value (labelled just "signature" in the Simple Settings view) can be changed from ???? to webo after import.
5) The debugger used to debug a project is defined in the Executables tab of the project's main target. Go to the Debugger subtab and change the radio button to select "Java Debugger" rather than "Gdb".
6) Aggregate projects are not supported in WebObjects 5. Individual products in an aggregate PBWO project should be identified and imported individually into separate PB projects.

1) DSTROOT was not handled properly during pbxbuild install
2) Permissions were not set corrrecty building with WebServer and Deployment buildstyles
3) pbxbuild would not work properly without a buildstyle

A) Create a new project and add all of your files and resources to it
B) Apply the following changes to exising projects:
1) DSTROOT was not handled properly during pbxbuild install Change settings in the Deployment buildstyle: - Prepend $(DSTROOT)/ to INSTALL_PATH_FOR_STYLE Change settings in the WebServer buildstyle: - Prepend $(DSTROOT)/ to INSTALL_PATH_FOR_STYLE - Prepend $(DSTROOT) to WEBSERVER_DOCROOT (no slash)
2) Permissions were not set corrrecty building with WebServer and Deployment buildstyles - Remove a-w, from INSTALL_MODE_FLAG in all buildstyles
3) pbxbuild would not work properly without a buildstyle - Copy each setting from the Development buildstyle into the Build Settings of the main target.

In WebObjects, the locking and unlocking of session.defaultEditingContext is performed transparently. However, if your application uses other editing contexts, you need to lock them yourself.

Direct to Web helps you manage the locking of such editing contexts:

- The edit and inspect pages lock the editing context when the setObject method is invoked.

- The edit-relationship page locks the editing context when the setObjectAndMasterRelationshipKey method is invoked.

- The inspect, edit, and edit-relationship pages lock the editing context of the object they manipulate when the awake method is invoked

- The inspect, edit and edit-relationship pages unlock the editing context of the object they manipulate when the sleep method is invoked.

Therefore the following code:

myPage=D2W.factory().inspectPageForEntityNamed("FOO",session());
myPage.setObject(myEO);
return myPage;

requires no extra lock/unlock statements on your part, even when myEO is not in session.defaultEditingContext.

However if you do not render the page right away but store it instead, the editing context remains locked unless you unlock it yourself.

myPage=D2W.factory().inspectPageForEntityNamed("FOO",session());
myPage.setObject(myEO);
myPage.sleep();
thisOtherPage.setNextPage(myPage);

The usage synopsis for javawoservices.sh is:
javawoservice.sh [ -help ] | [ [ -waitTime <seconds> ] [ retries <attempts> ]
[ -scaleTimeouts YES|NO ] [ -scaleFactor <amount> ] ]
-appPath <path> [ <application-specific arguments> ]

Note: javawoservice.sh -help gives you much more information about the arguments themselves.

On Solaris (and UNIX platforms), WOServices is located at $NEXT_ROOT/Library/WebObjects/Executables/WOServices

The usage synopsis for WOServices is:WOServices [ -help ] | [start | stop | enable -altJVMPath <path-to-other-Java-VM> | disable]

Note: WOServices -help gives you much more information about the arguments themselves.

In this case, HOSTNAME will resolve to "localhost", causing lifebeats (from the application to wotaskd) to be sent to "localhost.corp.apple.com", which doesn't resolve properly. This does not happen with MacOS X Server because during the automated setup, a hostname is entered.

		public static void main(String argv[]) {
		   WOApplication.main(argv, Application.class);
	        }

		public YOUR_CLASS_NAME(WOContext aContext) {
		   super(aContext);
	        }

In Project Builder
1. Open the target project.
2. Select the Web Components group from the Groups & Files list.
3. Choose Project > New Group and name the group appropriately.
4. Make sure the the new group is selected and choose Project > Add Files.
5. In the add-files sheet
    a. Select the component's three files from the file list in the sheet (you can click and drag or use the Shift key to select them).
    b. Click Open.
6. In target-selection sheet
    a. Make sure Reference Style is set to Default.
    b. Select "Create Folder References for any added folders."
    c. Select the appropriate target and click Add.

For example, every CMP bean needs an entry like the following inside its <entity-bean> declaration.

		<jndi-enc>
		   <resource-ref>
		      <res-ref-name>jdbc/myDataSource</res-ref-name>
		      <res-type>javax.sql.DataSource</res-type>                            
		      <res-auth>Container</res-auth>                            
		      <res-id>DefaultDatabase</res-id>                        
		   </resource-ref>                    
		</jndi-enc>

where "jdbc/myDataSource" would be defined in GlobalTransactionConfiguration.xml as follows:

		<database name="Global_TX_Database" engine="oracle">
		   <jndi name="java:comp/env/jdbc/myDataSource" />   
		   ......<
		/database>

		EOEditingContext editingContext = new EOEditingContext();
		// Creates a new EOEditingContext object with the default parent object
		//store as its parent object store.

		SELECT  t0.AIRPORT_ID
		FROM PLANE t1, FIGHTER t2, TRAINER t3, AIRPORT t0
		WHERE
		   (t1.LENGTH <= 1000 AND t0.AIRPORT_ID  = t1.AIRPORT_FK) OR
		   (t2.LENGTH <= 1000 AND t0.AIRPORT_ID  = t1.AIRPORT_FK) OR    
		   (t3.LENGTH <= 1000 AND t0.AIRPORT_ID  = t1.AIRPORT_FK) 
		

		SELECT  t0.AIRPORT_ID
		FROM PLANE t1, AIRPORT t0
		WHERE  
		   (t1.LENGTH <= 1000) AND
		   t0.AIRPORT_ID = t1.AIRPORT_FK


		   In other words, only the table for the root of the hierarchy is queried.

1. Adding relationships in the source entity to all the tables in the inheritance hierarchy. For example, to the Airport entity, you'd add the relationships toFighters and toTrainers to the destination entities FighterPlane and TrainerPlane, respectively. Mark the relationships so they aren't class properties.

2. When building your query, explicitly list these extra relationships. In the Planes example, you'd fetch from Airport where "planes.length < 1000 OR toFigtherPlanes.length < 1000 OR toTrainerPlanes.length < 1000"
Alternatively, you might be able to solve this problem more generally by writing a post processor for EOQualifiers that splits up clauses that perform inheritance tests. The post processor could even programmatically generate the additional relationships on demand and register them with the model using names like "plane_Subclass_Fighter".
A generic EOQualifier post processor could be wired into Enterprise Objects Framework so that application writers don't have to know it exists. The right place for such a mechanism is probably in EOKeyValueQualifier's schemaBasedQualifierWithRootEntity: method (see EOSQLQualifier.h). You could put the post processor code in a subclass of EOKeyValueQualifier (with an appropriate call to super after the transformation, if any, is performed) and have your subclass pose as EOKeyValueQualifier.

WHERE (ENTITY.ATTR1 = v1 or REL.ATTR2 = v2) AND REL.PK = ENTITY.PK

For a mandatory relationship 'rel', there will always be a match in the REL table and the above SQL WHERE clause will end up giving the correct result. However, for an optional relationship with a NULL value, the WHERE clause fails to return any rows even if there were rows in the ENTITY table that matched the value v1.

The appropriate SQL would be

WHERE ENTITY.ATTR1 = v1 or (REL.ATTR2 = v2 AND REL.PK = ENTITY.PK)

which would give the correct results for all cases.

In order to maintain consistency for applications that use database persistence, it was necessary to ensure that all timezones are internally represented in UTC, rather than a local timezone. NSTimestamp objects returned by the no-argument constructor used to be located in the timezone local to the application; now such objects are located in UTC (also known as Greenwich Mean Time or GMT).

This will cause some methods that have been deprecated to behave differently. These methods include:

dayOfCommonEra
dayOfMonth
dayOfWeek
dayOfYear
gregorianUnitsSinceTimestamp
hourOfDay
minuteOfHour
monthOfYear
secondOfMinute
setDate
setHours
setMinutes
setMonth
setSeconds
setTime
setYear
timestampByAddingGregorianUnits
timeZone
yearOfCommonEra

It is possible to continue to use these methods, but it is important to understand that the NSTimestamp object, even if created using a timezone parameter, is located in UTC. Gregorian units for such an object are thus relative to UTC and not the timezone local to the application.

Deprecated methods that should be unaffected by this change are:

currentTimeIntervalSinceReferenceDate
distantFuture
distantPast
earlierTimestamp
laterTimestamp
microsecondOfSecond
millisecondsToTimeInterval
setNanos
timeIntervalSinceNow
timeIntervalSinceReferenceDate
timeIntervalSinceTimestamp
timeIntervalToMilliseconds
timestampByAddingTimeInterval

No methods that have not been deprecated should be affected by this change.

		public WOSession createSessionForRequest(WORequest aRequest) {
		   Session session = (Session)super.createSessionForRequest(aRequest);    
		   // put your custom initialization that needs the request object here.    
		   return session;
		}
		

		public class Key implements WOXMLCoding, NSKeyValueCoding {   
		   ...   
		   protected int rank;   
		   protected NSTimestamp requestDate;   
		   protected String message;   
		   ...   
		   // Retrieves the value of a property of the object.   
		   public Object valueForKey(String key) {       
		      return NSKeyValueCoding.DefaultImplementation.valueForKey(this, key);   
		   }
		   // Sets the value of a property of the object.   
		   public void takeValueForKey(Object value, String key) {       
		      if (key.equals("rank")) {           
		         value = Integer.decode((String)value);       
		      }       
		      else if (key.equals("requestDate")) {           
		         NSTimestampFormatter formatter = new NSTimestampFormatter("%Y-%m-%d %H:%M:%S %z");           
		         try {               
		            value = formatter.parseObject((String)value);           
		         }           
		         catch (java.text.ParseException e) {             
		           // do something.           
		         }       
		      }       
		      NSKeyValueCoding.DefaultImplementation.takeValueForKey(this, value, key);   
		   } 
		   ...
		}
		

In the example above, type coercion was required for 2 member variables: rank and requestDate since they are not java.lang.String.

The Value Type of an attribute in an EOModel controls how the JDBC adaptor handles important details in its negotiations with the database. A Value Type is typically a single character.

For attributes with a Value Class of java.lang.Number the following value types are defined:
b = Byte
s = Short
i = Integer
l = Long
f = Float
d = Double
B = java.math.BigDecimal
c = Boolean

Since java.lang.Number is an abstract superclass, the Value Type controls which concrete class the JDBC adaptor should instantiate based on the raw data provided from the database.

It also controls which JDBC methods are used to send and retrieve the data to and from the database. For attributes with a Value Class of java.lang.String the following value types are defined:
<none>
c
S
C
E

These Value Types affect which method on the java.sql.PreparedStatement are used to transfer text data between the database and the JDBC adaptor. An empty Value Type is backward compatible behavior with WebObjects v4.5 and uses the setString() method if the text is less than the database's advertised maximum varchar length, and setCharacterStream(), if it is too large. If the database fails to advertise a maximum length, the default is 256 characters. A Value Type of 'S' uses setString() regardless of the text's length. A Value Type of 'C' uses setCharacterStream() regardless of the text's length. A Value Type of 'E' converts the text into raw UTF-8 bytes, and then uses setBinaryStream() to save them in a binary typed column in the database. The Value Type of 'c' tells the adaptor to generate SQL using RTRIM to strip off all trailing spaces, such as those found in CHAR columns.

'S' is appropriate for most text columns. 'C' is good for columns which usually contain large amounts of data. 'c' should be used when trailing spaces are not significant in a CHAR column. (It's better to use a VARCHAR column if possible.) We recommend against using 'E', except in extreme cases. It is the database's responsibility to handle text encoding issues, and using 'E' is usually an indication the database is not correctly configured.

For attributes with a Value Class of NSTimestamp the following value types are defined:
<none>
D
t
T
M

These value types affect how the data is transfer between the JDBC adaptor and the database. An empty Value Type uses get/setObject() on the ResultSet and PreparedStatement. It assumes the database can provide a value compatible with a java.sql.Timestamp. A 'D' indicates WebObject's JDBC adaptor should use get/setDate. A 't' indicates get/setTime(), and a 'T' uses get/setTimestamp(). The 'M' value type is a workaround for a bug in some MS SQLServer JDBC drivers. It only support java.sql.Date.

BLOB and CLOB columns are handled specially by the adaptor to support Oracle. The Value Type has no influence.