For OSGi we will need to revisit the functionality to work across bundle boundaries. Supposedly users starting with the OSGi-fied distribution will have a clean slate, so don't need to worry about renamed classes, at least for the first version. I can suggest another alternative for the standard (non-osgi) distribution - using classloader.getResources() will return all resources with the same name so no need to worry about overriding the files from downstream projects.
But even with the current approach we can have a predefined place to put those files, not necessarily in a brooklyn prefixed folder. After all ServiceLoader does exactly the same in a predefined location (META-INF/services). Svet. On 19.05.2016 г., at 13:52, Richard Downer <[email protected]> wrote: > > I'm not sure I'm happy with the idea of many 3rd-party jars adding stuff > into a Brooklyn-owned package. It doesn't rule out a couple of 3rd-party > packages happening to choose the same name. I also think there might be > issues with OSGi, as OSGi requires explicit declaration of packages, but I > don't know enough about OSGi to know for sure. > > Are there any other options for doing this? I'd suggest Java's > ServiceLoader facility, but that requires 3rd party packages writing a Java > class. Any other ideas? > > Richard. > > > On 19 May 2016 at 11:32, Martin Harris <[email protected]> > wrote: > >> Hi Folks, >> >> Just a quick heads-up about a PR I raised yesterday >> <https://github.com/apache/brooklyn-server/pull/144> >> >> When Brooklyn is rebinding from persisted state, it instantiates classes >> (such as entities) based on the persisted fully-qualified classname. This >> causes a problem if the name of the class, or its package changes, >> resulting in a ClassNotFoundException >> >> To resolve this issue, Brooklyn maintains a list of classes that have been >> renamed >> < >> https://github.com/apache/brooklyn-server/blob/6efc98a6ac79ef009468f231c8a93814ff63c5d2/core/src/main/resources/org/apache/brooklyn/core/mgmt/persist/deserializingClassRenames.properties >>> . >> The problem is that there is no way for downstream projects to extend this >> list without simply copying the list and ensuring the copy is closer to the >> head of the classpath - which risks divergence of the files >> >> PR 144 <https://github.com/apache/brooklyn-server/pull/144> resolves this >> issue by moving the file into a specific package, then during >> deserialisation it checks for any files in that package that end with >> .properties. It’s assumed that downstream projects will use a >> project-specific filename to prevent collisions >> >> Cheers >> >> -- >> Martin Harris >> Lead Software Engineer >> Cloudsoft Corporation Ltd >> www.cloudsoftcorp.com >> Mobile: +44 (0)7989 047-855 >>
