CDV ❯ Improve error message for non-portable class reference
-
New Feature
-
Status: Closed
-
3 Minor
-
Resolution: Fixed
-
-
-
hhuynh
-
Reporter: gbevin
-
April 30, 2007
-
0
-
Watchers: 0
-
January 23, 2008
-
June 22, 2007
Description
I just had this idea for making people’s life easier when dealing with non-portable class references. Currently, they get something like this:
******************************************************************************* Attempt to share an instance of a non-portable class referenced by a portable class. This unshareable class must be in the DSO boot jar. It also has superclasses which must be in the DSO boot jar. Please add all of these classes to the boot jar configuration and re-create the DSO boot jar.
Referring class : [Ljava.lang.Object; Thread : http-29972-Processor24 JVM ID : VM(0) Classses to add to boot jar: java.lang.AbstractStringBuilder, java.lang.StringBuffer *******************************************************************************
Any non veteran Terracotta user will now be scratching his head, wondering what all this is about and once he understands that the classes need to be added to the bootjar, they have to start searching for the exact syntax. I thought that expanding this message to something like this might maybe be useful for those people:
******************************************************************************* Attempt to share an instance of a non-portable class referenced by a portable class. This unshareable class must be in the DSO boot jar. It also has superclasses which must be in the DSO boot jar. Please add all of these classes to the boot jar configuration and re-create the DSO boot jar.
Referring class : [Ljava.lang.Object; Thread : http-29972-Processor24 JVM ID : VM(0) Classes to add to boot jar : java.lang.AbstractStringBuilder, java.lang.StringBuffer
Typical steps to resolve this:
* edit your tc-config.xml file
* locate the
* if there’s already a additional-boot-jar-classes> tag present, simply add the new includes to the existing one *******************************************************************************
Additional comment from Taylor: Also I believe that the whole object graph can be printed, or is printed, to the logs, so it would be good to reference this feature.
Additional comment from Kunal: It gets a little tricky if the Class is “truly non-portable” - in which case the fix would be to mark the Referring Field as transient. Maybe we could intercept if the Class is one of the classes we know we do not support OR already exists in the boot-jar and give some useful message about marking it transient also?
verify fixed in 2.4 branch