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 >> OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788 >> hargr...@us.ibm.com <mailto:hargr...@us.ibm.com> >> >> >> ----- Original message ----- >> From: Justin Edelson <jus...@justinedelson.com> >> <mailto:jus...@justinedelson.com> >> Sent by: osgi-dev-boun...@mail.osgi.org >> <mailto:osgi-dev-boun...@mail.osgi.org> >> To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> >> <mailto: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 >> <mailto: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 <mailto: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 <mailto:osgi-dev@mail.osgi.org> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.osgi.org_mailman_listinfo_osgi-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=p-HkGsKTJWWSiO-pz0kKXl8ALzmlqvUGeFfgHUZX8ms&m=N8OjKyRzJAJe44A7oippEH9juVLJn7KZyY8lmjoFD9M&s=qcB76DBWcTRiLkhXJSdPT2wzPLAMBsxGOb4RxlmTjyI&e= >> >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.osgi.org_mailman_listinfo_osgi-2Ddev&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=p-HkGsKTJWWSiO-pz0kKXl8ALzmlqvUGeFfgHUZX8ms&m=N8OjKyRzJAJe44A7oippEH9juVLJn7KZyY8lmjoFD9M&s=qcB76DBWcTRiLkhXJSdPT2wzPLAMBsxGOb4RxlmTjyI&e=> >> >> >> >> >> >> _______________________________________________ >> OSGi Developer Mail List >> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org> >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> <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
