One could always define a custom system class loader using -Djava.system.class.loader, and specify special behavior for the problematic classes (possibly dynamically redefining api and uses). The class names and API changes should be specified using regular expressions.
An alternative to bytecode rewriting would be to handle the changes using a custom JVM compiler, using the JVMCI. Note: As of JDK 9 JVMCI is not complete and stable, and is thus for some unknown reason marked as experimental. One advantage of these approaches is that they use regular expressions. They also avoid the use of TCCL. Or what BJ/Timothy said. ;-) Simon On Sep 18, 2017 11:17 AM, "Timothy Ward" <tim.w...@paremus.com> wrote: I would not recommend any solution which involves the use of DynamicImport-Package: *. This is roughly equivalent to saying “I give up and want to switch off OSGi”. You lose any ability to validate a that a set of bundles is complete, and you have no guarantee that things will work at runtime. You also introduce ordering issues into As BJ says the correct thing to do is to pass sufficient context for the runtime to actually use the plugin. This means that you could: - Provide your own ComponentFactory which returns a fully configured instance - this is possible with the existing API - Pass a Class object rather than a String. This would need a minor change to the existing user interface - Have OSGi clients obtain an OSGi service from the Vaadin runtime. This service can be specialised to each client bundle, at which point the service has sufficient context to load the plugin class from a String class name. There are probably other ways to skin this particular cat, but resorting to TCCL and/or DynamicImport-Package: * should be a very long way down the list. Regards, Tim Ward On 17 Sep 2017, at 07:56, Karel Haeck <karel.ha...@telenet.be> wrote: If you cannot change the vaadin clients to use the TCCL, nor want to modify the vaadin component registration API, you could try the following: - create a bundle with a ComponentFactory that uses a plain Class.forName without classloader argument to resolve components (it will use its own bundle class loader) - add DynamicImport-Package: * to the bundle's manifest - activate your ComponentFactory in Vaadin with Design.setComponentFactory - make sure all clients put their component classes in an exported package to make them visible to your componentFactory's classloader. Karel Haeck On 15/09/2017 22:17, BJ Hargrave wrote: Better would also be for the API to not take a String class name but a Class object. The caller likely has access to the named class (or can easily be configured to have access), while the library code which has to load the class from the String class name generally does not which is why we have the "magic" of TCCLs... (sigh) -- BJ Hargrave Senior Technical Staff Member, IBM // office: +1 386 848 1781 <(386)%20848-1781> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788 hargr...@us.ibm.com ----- Original message ----- From: Justin Edelson <jus...@justinedelson.com> <jus...@justinedelson.com> Sent by: osgi-dev-boun...@mail.osgi.org To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> <osgi-dev@mail.osgi.org> Cc: Subject: Re: [osgi-dev] Class.forName Hell Date: Fri, Sep 15, 2017 2:55 PM Given that the Thread Context Classloader is used, can you just set this to the correct value before invoking DefaultComponentFactory.createComponent()? I don't know the fully calling context, so perhaps that won't work. If the TCCL is the wrong choice but happens to work in a non-OSGi environment, the right solution generally is to allow for an alternate classloader to be passed in. On Thu, Sep 14, 2017 at 11:24 PM Paul F Fraser <pa...@a2zliving.com> wrote: Hi, I do not have the slightest idea if this situation can be handled, but perhaps some kind person can assist. Vaadin uses forName in the following situation and the classes are not found when used in OSGi project. https://github.com/vaadin/framework/blob/master/server/src/ main/java/com/vaadin/ui/declarative/Design.java <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_vaadin_framework_blob_master_server_src_main_java_com_vaadin_ui_declarative_Design.java&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-HkGsKTJWWSiO-pz0kKXl8ALzmlqvUGeFfgHUZX8ms&m=N8OjKyRzJAJe44A7oippEH9juVLJn7KZyY8lmjoFD9M&s=EyomOMZG094tkV7aytIm-A9lh1WZgk4iO3qX3ocBgxc&e=> (~ line 200) https://github.com/vaadin/framework/blob/master/server/src/ main/java/com/vaadin/server/VaadinServiceClassLoaderUtil.java <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_vaadin_framework_blob_master_server_src_main_java_com_vaadin_server_VaadinServiceClassLoaderUtil.java&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-HkGsKTJWWSiO-pz0kKXl8ALzmlqvUGeFfgHUZX8ms&m=N8OjKyRzJAJe44A7oippEH9juVLJn7KZyY8lmjoFD9M&s=VmtdWQHEflUU7-lnZW3eTMw8HfweYKHjRz7-VhGPk-g&e=> If possible it would be a good contribution if we could suggest a way to Vaadin as to how this should/could be handled. Paul Fraser _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev <https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.osgi.org_mailman_listinfo_osgi-2Ddev&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p-HkGsKTJWWSiO-pz0kKXl8ALzmlqvUGeFfgHUZX8ms&m=N8OjKyRzJAJe44A7oippEH9juVLJn7KZyY8lmjoFD9M&s=qcB76DBWcTRiLkhXJSdPT2wzPLAMBsxGOb4RxlmTjyI&e=> _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.os gi.org_mailman_listinfo_osgi-2Ddev&d=DwICAg&c=jf_iaSHvJObTb x-siA1ZOg&r=p-HkGsKTJWWSiO-pz0kKXl8ALzmlqvUGeFfgHUZX8ms&m=N8 OjKyRzJAJe44A7oippEH9juVLJn7KZyY8lmjoFD9M&s=qcB76DBWcTRiLkhX JSdPT2wzPLAMBsxGOb4RxlmTjyI&e= _______________________________________________ OSGi Developer Mail listosgi-...@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
