Hi all, interesting discussion so far; it seems we're not the only ones trying to combine Wicket and OSGi.
Related to the Wicketstuff wicket-osgi project, I would like to share some comments: - This implementation assumes the web bundle knows about all bundles providing services; in our case (the case attached to WICKET-3737 is a stripped down version), we have one 'web bundle', which hosts the Wicket application; individual bundles provide pages and their mount points (in the example case, bundles provide some panels). In cases like that, there is no single class loader which knows all classes, so you need one bundle with a DynamicImport-Package: *. To reduce the number of bundle refreshes we delegate this job to a tiny 'class resolver bundle', which exposes an IClassResolver instance as OSGi service. While generating JDK / CGLib proxies, you need a class loader which can access all proxied classes, one way to solve this is a minor change to the IClassResolver interface to get access to the almightly class loader. I have added a method getClassLoader(), which is used in the DefaultClassResolver to load classes. This simple change will save some code duplication in OSGi compatible classResolvers. - Another difference is how OSGi services are used; we are using Spring DM, which creates one applicationContext per bundle. Fields annotated with @SpringBean will be injected with beans (imported OSGi reference is also a bean) from the applicationContext of the bundle in which the component is created. In my opinion, the advantage of this is that each bundle has to be explicit about the services it depends on, spring beans do not have to be unique, not all beans have to be exported as OSGi service and there is need to register ServiceTracker instances (Spring DM solves this problem). - Is it an idea to extend the wicket-osgi project with some classes which support this pattern? So wicket-osgi will become the toolkit you need when combining OSGi and Wicket? I think it would be nice when it has injectors for services from the OSGi service registry, as well as the pattern in which spring beans from the bundle application context are used (more similar to wicket-spring, the only difference is you have multiple, small application contexts). One attachment to WICKET-3737 contains the injector stack required for wiring spring beans from the bundle application context into wicket components (not completely finished). To achieve this, I think the change to the IClassResolver API is required, some patches have to be applied in wicket-ioc code and the DynamicImport-Package header needs to be dropped from the wicket bundles. What do you think? grtz, Daniël ** <http://www.educator.eu> On Mon, Jun 27, 2011 at 10:36 PM, Harald Wellmann <[email protected]>wrote: > Am 27.06.2011 22:13, schrieb Martin Grigorov: > > I also reviewed the code - good job! >> >> > Thanks :-) > > > I saw that you basically copy/pasted DefaultClassResolver to >> OsgiClassResolver with minor modifications. >> I think it will be better if we make DCR easier to extend so there is >> no need to copy/paste its code. >> >> > Actually, I'm no longer sure it is needed at all... The OsgiClassResolver > uses the bundle class loader of the WAB, accessed via the current > Application class. > > The DefaultClassResolver uses the ThreadContextClassLoader, or its own > classloader as a fallback. > > I'd noticed before that my sample works on Jetty even without the > OsgiClassResolver, and the same is true on GlassFish 3.1. > > Sahoo from the GlassFish team pointed out to me that any Servlet container > is required to set the TCCL to the application classloader (see Servlet Spec > 3.0, section 10.7.2) for loading resources and for any application > callbacks. > > If everyone agrees that this covers all use cases where Wicket needs to > load stuff from user bundles, then I think it's safe to scrap the > OsgiClassResolver and let the unmodified DefaultClassResolver do the job. > > >>> Could you also document the new module on wicketstuff wiki? >>> https://github.com/**wicketstuff/core/wiki<https://github.com/wicketstuff/core/wiki> >>> >> > Sure - that's the next thing on my list... > > I'm also planning to add some Surefire tests based on Pax Exam. > > Cheers, > > Harald > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@wicket.**apache.org<[email protected]> > For additional commands, e-mail: [email protected] > >
