# Elastic Common Schema Java Implementation
**URL:** https://discuss.elastic.co/t/elastic-common-schema-java-implementation/188391
**Category:** Elasticsearch
**Created:** [July 1, 2019, 6:54pm UTC](https://discuss.elastic.co/t/elastic-common-schema-java-implementation/188391 "2019-07-01T18:54:57Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@cpmoore](https://discuss.elastic.co/u/cpmoore)
#### Post date: [July 1, 2019, 6:54pm UTC](https://discuss.elastic.co/t/elastic-common-schema-java-implementation/188391/1 "2019-07-01T18:54:57Z")
I'm just looking for some general ideas of mapping java log fields to the elastic common schema.
A couple fields are already taken care of, such as `log.level` and `process.thread.id`, but there's a couple fields that I feel like are missing from ECS. Such as transaction id, class name, and class method.
I was just hoping to get some general ideas from the community as to what everyone thinks these fields should be mapped to.
---
### Author:  [@chandra2037](https://discuss.elastic.co/u/chandra2037)
#### Post date: [July 1, 2019, 8:19pm UTC](https://discuss.elastic.co/t/elastic-common-schema-java-implementation/188391/2 "2019-07-01T20:19:55Z")
I would say
1. transaction id
`transaction.id`
Default Elastic APM transactions/span field.
1. class name and class method
`log.customobjname.class_name`
`log.customobjname.class_method`
In general, we are following the below approach,
whenever we need to map any field which is missing in ECS then mapping that under a custom object, under the corresponding major section. If ECS includes these fields in future ECS versions, there will be no conflict, and we can migrate from our custom object.
Eg: for class name, if we can map as log.class\_name then in future ECS version if the same field get mapped log.class.name then we will be having a conflict (field vs object or vice versa)
---
### Author:  [@cpmoore](https://discuss.elastic.co/u/cpmoore)
#### Post date: [July 1, 2019, 8:36pm UTC](https://discuss.elastic.co/t/elastic-common-schema-java-implementation/188391/3 "2019-07-01T20:36:33Z")
I didn't think about looking at the apm fields. None of those are documented in the reference. Thanks, we're going to use `transaction.id` for that part.
As for the classes and methods, is there a reason you made it a custom object under `log` or just to avoid possible future conflicts?
It would be nice if the schema implemented a `class` field, then we could have `class.name`, `class.method`, and `class.instance`
---
### Author:  [@chandra2037](https://discuss.elastic.co/u/chandra2037)
#### Post date: [July 2, 2019, 2:00pm UTC](https://discuss.elastic.co/t/elastic-common-schema-java-implementation/188391/4 "2019-07-02T14:00:50Z")
Usually, I think like, which major section this field will fit. I thought classes and methods are some information about log data. So, if you think it will fit better under `process.thread`, then I would say create custom obj under `process.thread.customobj.class_name`. This way we will not have any impact with ECS updates in the future.
If there are multiple class fields then it might be better to have a class obj.
`xxx.customobj.class.name`
`xxx.customobj.class.method`
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 30, 2019, 2:00pm UTC](https://discuss.elastic.co/t/elastic-common-schema-java-implementation/188391/5 "2019-07-30T14:00:53Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.