Remove the concept of context properties that are specified in the application code. Most context properties will be vendor-specific, and using a model where applications hard code vendor specific context properties will lead to applications that are not portable. Instead, any properties that are needed can be handled in the configuration that the application server provides for a ContextService. If an application requires specific contexts, a ContextService instance should be created for it, and referred to via resource-refs deployment descriptor elements or annotations. This implies removal of the method declarations:
Object createContextObject(Object instance,
void setProperties(Object contextObject,
Properties getProperties(Object contextObject)
the class javadoc comments:
Context properties can be stored with the proxy instance. Custom property keys must not begin with "ctxsvc.".
Context properties are to be used for controlling how various contextual information is retreived and applied to the thread. Although application components can store arbitrary property keys and values, it is not recommended. Java EE product providers may impose limits to the size of the keys and values.
Context property keys and values must all be of type java.lang.String. Use of the put and putAll methods on the java.util.Hashtable superclass are discouraged.
and the field:
static String USE_PARENT_TRANSACTION