Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/718
currently when xstream writes a reference to a java type it checks whether
that class comes from a bundle and if so it prefixes the reference with the
bundle name. in the past some things have been white-listed but we are
white-listing fewer and fewer of these. the code does this for most "normal"
references (though I'm still a bit unclear in `XmlSerializer` what "normal
usage" is, as contrasted to "low-level mentions").
normal usage seems to exclude the `SpecConverter.{,un}marshal` so specs
always write the unadorned java name, and can't understand a prefix.
normal usage _does_ include things like miscellaneous classes being
written, like a `ConfigKey<Object>` whose value is a type
`com.custom.bundle.MyEnum`.
i think most people are agreed that in an ideal world we'd serialize only
registered types, and json primitives, not arbitrary java. but given what's
out there already, and the work needed on supporting arbitrary types in the
registry (mainly in API/UI, the backend is pretty good) we have to be able to
read/write many java items, and increasingly these are from osgi.
so the suggested solution is:
1) if there is a registered type which is a simple wrapper for a java type,
refer to that type name when reading and writing; that contains all the bundle
info to create the type, and our update strategies for registered types can
apply to them. attend to search paths when reading so we prefer things in a
local bundle.
2) if not, WARN, then-
* on write: prefix with the bundle name
* on read: try loading it ignoring the bundle but using the search path
(bundles, and for legacy readings also catalog item(s)); if that doesn't work,
then look in the declared bundle
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
