On Fri, Feb 18, 2011 at 11:45 AM, Igor Drobiazko <[email protected]> wrote: > Using the component class loader might be an issue in OSGi. Wouldn't it be > better to use the thread context ClassLoader?
Context ClassLoader won't work for the component classes though. (Maybe I should dwell into the code first but..) does the component classloader delegate to the context classloader for classes in non-component packages or just throw exceptions in that case? If the latter, would it be reasonable to first try the component classloader, and then the context class loader? Does OSGi have an issue with it because it uses it own classloader? If this gets too complex, probably not worth doing but at the moment, it still doesn't sound too obscure. Kalle > On Fri, Feb 18, 2011 at 8:27 PM, Kalle Korhonen > <[email protected]>wrote: > >> On Fri, Feb 18, 2011 at 11:05 AM, Thiago H. de Paula Figueiredo >> <[email protected]> wrote: >> > On Fri, 18 Feb 2011 16:39:15 -0200, Kalle Korhonen >> > <[email protected]> wrote: >> >> The immediate use case is for tynamo-federatedaccounts though I saw >> >> some threads on the list about the same coercion. Oauth works with >> >> callback urls which is why the library includes whole pages. It'd be >> >> nice to allow users to override the default behavior. >> > Why not have a fixed callback url which returns in ints onActivate() >> method >> > an object determined by a service (which can and should be overriden in >> this >> > case)? >> >> Perhaps but a) I started the thread about string to class coercion and >> b) in that example, it's likely the page itself they want to >> customize, not the oauth logic. >> >> Kalle >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Best regards, > > Igor Drobiazko > http://tapestry5.de > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
