Support for Externalizable objectsYou may want to be able to use your own objects in your WebLogic application to store and fetch your own objects to and from WebLogic Workspaces. In order to pass objects -- which may be complex structures, and may be made up of other objects, even graphs of objects -- between T3Client and WebLogic Server, you must serialize them. Serialization is necessary whenever you want to pass a Java object from one VM to another. An object must be serialized before it is shipped over the wire, and must be reconstituted at the other end of the wire for use in another VM. WebLogic supports the handling of Externalizable objects within its serialization, without implementing WLSerializable. You can implement Externalizable instead of WLSerializable and still take advantage of WebLogic's serialization. Here is an example: public class Example implements Externalizable { private Date[] dates; public Example() { dates = new Date[30]; } public void writeObject(ObjectOutput out) throw IOException, ClassNotFoundException { if (out instanceof WLObjectOutput) { // Use special serialization interface when possible ((WLObjectOutput)out).writeArrayOfConsistentObjects(dates); } else { // Use standard interface out.writeObject(dates); } } public void readObject(ObjectInput in) throw IOException { if (out instanceof WLObjectInput) { // Use special serialization interface when possible dates = (Date[])((WLObjectInput)in).readArrayOfConsistentObjects(); } else { // Use standard interface dates = (Date[])in.readObject(); } } } Serializing objects in WebLogic
In addition to using Externalizable, there are two more ways to serialize objects. You can use the java.io.Serializable interface or you can use WebLogic's serialization by implementing the weblogic.common.WLSerializable interface, which extends the standard java.io.Serializable interface. There are advantages and disadvantages to using either approach:
The WLSerializable interface contains two methods that you must implement:
In addition, note that your WLSerializable class must have a default constructor, which is defined as a constructor that takes no arguments. Here is an example: public MySerializableObject() { super(); } The default constructor provides a means of constructing the object on the other side of the wire, after your object has been serialized and shipped across. You use the methods in the weblogic.common interfaces WLObjectOutput and WLObjectInput to read and write the attributes for the object. Here is an example of serializing a very simple SalesRep object that has two attributes, name and address: public void readObject(WLObjectInput in) throws IOException, ClassNotFoundException { this.name = in.readString(); this.address = in.readString(); } public void writeObject(WLObjectOutput out) throws IOException { out.writeString(this.name); out.writeString(this.address); } Let's examine a more complex example. Suppose we have a SalesOffice object that is made up of a graph of SalesRep objects, plus some general information about the SalesOffice. Here is how we would serialize the SalesOffice object. public void readObject(WLObjectInput in) throws IOException, ClassNotFoundException { this.managerName = in.readString(); this.salesOfficeAddress = in.readString(); Object[] objs = in.readArrayOfObjects(); if (objs != null) { int numberOfElements = objs.length; this.salesReps = new SalesRep[numberOfElements]; for (int i = 0; i < numberOfElements; i++) { this.salesReps[i] = (SalesRep)objs[i]; } } else { this.salesReps = null; } } public void writeObject(WLObjectOutput out) throws IOException { out.writeString(this.managerName); out.writeString(this.salesOfficeAddress); out.writeArrayOfObjects(this.salesReps); } |
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|