Perhaps I'm mistaken but mabey aspectj would be able to help you here? AJDT works in the Eclipse environment and thus should work in OSGi as well and afaik it would be possible to do delegation without proxying the classes using this approach? I think Spring uses aspectj to inject beans to instances that are not part of the Spring life-cycle (you use the @Configurable annotation). I guess it would be possible to start transactions and all kinds of stuff this way as well?
On 26 Nov, 06:18, "Stuart McCulloch" <[EMAIL PROTECTED]> wrote: > 2008/11/26 Gili Tzabari <[EMAIL PROTECTED]> > > > I guess I agree with you for the most part. Thing is, for all this > > talk > > about how "it's all fixable" no one actually done so... > > yep, I think proxying deserves more attention - especially wrt. annotation > support > (unfortunately at the moment it's easier to workaround it than deal with it > upfront) > > I don't recall hearing of a single project that tried to improve the > > > situation. > > well I haven't looked that closely, but javassist tried (not sure how > successfully) > > I might sound silly saying this... but it really ticks me off. I hate using > > > APIs > > that force no-op constructors and inappropriate method accessibility on > > me. CGLIB acts more like a framework than a library in the sense that it > > forces its bad design on you :( Anyway, end of rant. I'll be happy when > > I can avoid CGLIB altogether in Guice. > > definitely - making this pluggable/optional should make everyone happy > > > > > Gili > > > Stuart McCulloch wrote: > > > 2008/11/26 Gili Tzabari <[EMAIL PROTECTED] > > > <mailto:[EMAIL PROTECTED]>> > > > > Stuart McCulloch wrote: > > > > it's the eager proxying that I'm worried about - could get hairy > > > > > for example: how do I tell Guice about the class that should be > > > proxied > > > > without actually loading that class (as Guice works primarily on > > > types) > > > > Alternatively you could register the Guice classloader > > > eagerly and > > > ensure that any types you refer to beyond that point would go through > > it > > > (by setting it as the Thread context CL for example). Any class > > injected > > > by Guice would automatically use the right CL. The only problem would > > > come from any classes loaded before the registration of the Guice CL. > > > Though, I suspect you should be able to do this very early on in > > > most cases. > > > > so essentially with this technique we'd be limiting how you could use > > Guice? > > > > sorry, but personally it sounds that this introduces problems for 90% of > > > users > > > while (possibly) fixing an issue that affects 10% at most - as Java > > > developers > > > we use sub-classing all over the place, why not use it when proxying? > > > > the issues about serialization and default constructors are solvable > > without > > > redefining the original class - and I suspect you'd also run into > > > serialization > > > issues even when using class redefinition, as any method interception > > could > > > distribute the state to fields in objects unknown to the original class > > > > [FYI, setting the TCCL doesn't work for legacy code that uses > > Class.forName] > > > > > however, two classes of the same name defined by two different > > > loaders > > > > are distinct and incompatible (!A.equals(A')) which is the > > > problem I have > > > > with redefining the class at runtime - as Johan says, it has to > > > go into a > > > > separate classloader, unless you use an instrumentation agent > > > > I believe instrumentation agent wouldn't work in the context > > > of a web > > > container since you don't want to affect classes outside your webapp. > > > > exactly, so you have to use a separate classloader and deal with > > > visibility issues > > > > > there are also visibility limitations - if I have non-public > > > classes A and B > > > > in the same package "foo" then they can only see each other if > > > they're > > > > loaded by the same classloader (delegation doesn't help here) > > > > Agreed, but I assume that if you're going to inject one class > > > in a > > > package you're likely going to use injection for the rest of them too > > > (or load them from classes that *have* been injected). > > > > and what happens if I (as a user of Guice) don't want to inject every > > > class from a > > > package? Even in the general case, how do I pass Guice a module with > > > bindings > > > for a package without loading that package first? > > > > I guess you'd have to ensure Guice was at the top of the classloader > > > chain, and > > > have some way of marking classes you wanted redefined early on - but > > > you'd be > > > limiting how people could use Guice (ie. no use as a bundle, no way to > > > upgrade > > > without restarting the process) - all to fix some issues which can be > > > fixed using > > > normal sub-classing (as I think javassist shows) > > > > Gili > > > > -- > > > Cheers, Stuart > > -- > Cheers, Stuart --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
