Exception when serializing extensibleTypes to JSON

[sschuberth]

In ORT, we're using extensibleTypes to record the "origin" of a license or the "type" of a dependency. While serializing such a BOM to XML works fine, serializing the same BOM to JSON fails with:

com.fasterxml.jackson.databind.JsonMappingException:
class com.fasterxml.jackson.core.json.WriterBasedJsonGenerator cannot be cast to class com.fasterxml.jackson.dataformat.xml.ser.ToXmlGenerator (com.fasterxml.jackson.core.json.WriterBasedJsonGenerator and com.fasterxml.jackson.dataformat.xml.ser.ToXmlGenerator are in unnamed module of loader 'app')
(through reference chain: org.cyclonedx.model.Bom["components"]->java.util.ArrayList[0]->org.cyclonedx.model.Component["licenses"]->org.cyclonedx.model.License["extensibleTypes"])

From a quick glance, it seems to me that extensibleTypes serialization currently is XML-specific. If that's the case, is there a chance to get JSON support for extensibleTypes?

[stevespringett]

Considering JSON Schema is not extensible, it's likely not possible. It's one of the reasons why the vulnerability extension only exists for XML.

One of the approaches that has been discussed is to merge JSON schemas together to form a single one. So you could have the base schema and if you want to include vulnerability, formulation, or some other extension, you could add them and get returned a merged JSON Schema containing all that functionality. Its a bit sad that JSON Schema is so limited, but its one of the better options currently being discussed.

With that said, I think you'll be better off using properties in CycloneDX v1.3. This is essentially a key/value store. Many orgs are doing this today using their own extension. We're bringing this capability to the core specification so it can handle other types of data not natively supported.

CycloneDX v1.3 will be out "soon"...

I briefly looked at dependencyType. Am I correct in dependencyType is either "direct" or "transitive"? If so, then my question is why this is necessary in the first place? This can already be described in the core spec.

[stevespringett]

@DarthHater whats your thought on extensible types and serializing/deserializing to JSON - ignoring the JSON Schema limitations. Possible?

[sschuberth]

Considering JSON Schema is not extensible, it's likely not possible. It's one of the reasons why the vulnerability extension only exists for XML.

Isn't there a (somewhat hacky) way to use special field names that start with an underscore or so? I thought I've seen something like that before somewhere.

With that said, I think you'll be better off using properties in CycloneDX v1.3.

Sounds good.

Am I correct in dependencyType is either "direct" or "transitive"?

Yes.

If so, then my question is why this is necessary in the first place? This can already be described in the core spec.

You mean via the dependency graph extension? Our implementation predates that IIRC, so this was the easiest way for us to add that information without significant changes.

But in any case, I believe the JSON exported should not silently generate an empty string for the whole BOM due to this internal exception being thrown. Can't it simply ignore the extensibleTypes then?

[stevespringett]

The dependency graph extension is only applicable to CycloneDX v1.1.

With the release of CycloneDX v1.2 in May 2020, the spec includes native support for dependency graphs and has the ability to specify direct/transitive relationships which CycloneDX 1.1 with the extension was not capable of doing.

See: https://cyclonedx.org/use-cases/#dependency-graph

With CycloneDX v1.2 and Dependency-Track v4.2, its possible to describe and visualize complete dependency graphs.
DependencyTrack/dependency-track#280 (comment)

Perhaps @DarthHater can address this:

But in any case, I believe the JSON exported should not silently generate an empty string for the whole BOM due to this internal exception being thrown. Can't it simply ignore the extensibleTypes then?

[sschuberth]

The dependency graph extension is only applicable to CycloneDX v1.1.

Which is the version of the spec ORT is using right now. I'm in the process of doing the upgrade, but then ran into this issue.

With CycloneDX v1.2 and Dependency-Track v4.2, its possible to describe and visualize complete dependency graphs.

Good to know, thanks. But even if we'd get rid of the need of extensibleTypes for the dependency type, we'd still need it for the license origin; so I'm still interested in the JSON exporter to ignore them and successfully export the majority of the BOM.

[DarthHater]

@stevespringett I'm taking a look at this for the #102 , since it's applicable there!

[sschuberth]

Any updates to this? I'd like to record where a particular license entry comes from, i.e. from package metadata, or from a license scanner. As said, in XML we can use a custom ExtensibleType named "origin" for this, but this does not get serialized in JSON.

The mentioned properties do not seem to be a good fit as they're associated to the component, not to the license.