why dont you guys hash all this out. since no one uses osgi from the core team we are mostly unaware of these issues but do want to support the platform. once you settle down on the changes you want to see create jira issues and we will take it from there.
-igor On Thu, Jul 3, 2008 at 5:53 AM, Edward Yakop <[EMAIL PROTECTED]> wrote: > On Thu, Jul 3, 2008 at 8:24 PM, Daniel Stoch <[EMAIL PROTECTED]> wrote: >> But there is a one assumption, that bundle with Wicket classes (you >> probably have a Wicket bundled somehow in your app, don't you? :)), >> should have a dynamic import for all classes which can be located in >> many different bundles: >> DynamicImport-Package: *" > > I don't think you should use DynamicImport-Package. > In pax wicket, we creates a delegating class resolver that tracks > IClassResolver services. > >> Proposal 1 (change actual method behavior): >> Modify resolveClass() method in DefaultClassResolver as I wrote above > > -1. This can be easily work around by setting the class resolver. > >> Proposal 2 (do not change actual method behavior): >> Make DefaultClassResolver extensible (remove final modifier in class >> declaration) and define a new method (invent a better name for it ;)): > +1 > >> 2. LazyInitProxyFactory - Spring integration >> The first minor thing is a call "Class.forName(type);" in >> ProxyReplacement. Why not use IClassResolver here (and maybe in other >> places in Wicket)? > +1 > >> Proposal 2 (do not change actual method behavior): >> Make LazyInitProxyFactory customizable to allows using a different >> method to create proxy inside OSGi. > +1 > > Regards, > Edward Yakop > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
