Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/718
BTW there was a lot of refactoring / clean-up I did, split into commits for
some ease of reviewing, and a lot of comments and tests.
The only functional change should be the shift
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/718
Should be good for now. I went with the quite-simple of always writing the
osgi bundle prefix (part of step 2 in the long term solution). Lots of
comments about how it works and moving
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/718
Also the `SpecConverter` is obnoxiously hard to overwrite to make it ignore
the `type` field, so that "quick" suggestion is also out. Thinking the
original fix is actually the best.
---
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/718
scratch the `ClassLoadingContext` suggestion: it's hard, and I've come to
the conclusion it's misguided. it serves a different, narrower purpose than a
resulting instance's search path
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/718
we also need a way to fix existing deployments that suffer this problem.
any of the above fixes should suffice, but i wonder whether there is a
workaround that doesn't involve upgrading
Github user ahgittin commented on the issue:
https://github.com/apache/brooklyn-server/pull/718
in `SpecConverter`, if the catalog item ID is set i think that implies the
java type so we _could_ skip writing and _should_ ignore it (just use the
catalog item ID) when reading. that
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
