[id='storing_pojos-{context}']
= Storing Unmarshalled Java Objects
You can store data as deserialized Plain Old Java Objects (POJO) instead of
storing data in a binary format.

Storing POJO instead of binary format is not recommended because it
requires {brandname} to serialize data on client read operations and
deserialize data on write operations. To handle client interoperability with
custom code you should convert data on demand.

.Procedure

. Specify `application/x-java-object` as the MediaType for keys and values as follows:
+
[source,xml,options="nowrap",subs=attributes+]
----
include::config_examples/encoding_java_object.xml[]
----
+
. Put class files for all custom objects on the {brandname} server classpath.
+
Add JAR files that contain custom classes and/or service providers for
marshaller implementations in the `server/lib` directory.
+
----
├── server
│   ├── lib
│   │   ├── UserObjects.jar
│       └── README.txt
----
+
. Configure your clients.

There are no changes required for Hot Rod clients. The only requirement is that the marshaller used in the client is available in the `server/lib` directory so {brandname} can de-serialize the objects.

[NOTE]
====
ProtoStream and Java Serialization marshallers are already available on the
server.
====

REST clients must use either JSON or XML so {brandname} can convert to and from
Java objects.

.Reference

* link:{dev_docs}#mediatype_override[Converting Data on Demand]
* link:{dev_docs}#protostream_cm_config[Using the ProtoStream Marshaller]
* link:{dev_docs}#[Marshalling Custom Java Objects with ProtoStream]
