2008/11/26 Johan Haleby <[EMAIL PROTECTED]> > > 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
actually if you're using OSGi, I'd suggest looking at Equinox Aspects: http://www.eclipse.org/equinox/incubator/aspects/ they've got AspectJ and OSGi working smoothly together, but I digress... 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? > but Spring afaik does not use AspectJ for proxying - according to their docs on AOP they only use JDK or CGLIB proxies, just like Guice does: http://static.springframework.org/spring/docs/2.5.x/reference/aop.html however, Spring does provide integration support for using injection with AspectJ - but again, this is different from proxying because you're given a _pre-existing_ object (already woven) and asked to inject stuff into it: http://static.springframework.org/spring/docs/2.5.x/reference/aop.html#aop-using-aspectj so it would be possible to write a similar Guice extension to support AspectJ, probably using injectMembers (basically what @Configurable does in Spring) but this would not replace proxying - it's an alternative approach where you don't need to proxy in the first place, because you've already woven your classes in advance so to sum up: adding support for pluggable / optional proxying would be cool writing a Guice extension to fit with AspectJ would also be cool but imho (as a third party) there is no need to use AspectJ inside Guice core HTH 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 > > > -- 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 -~----------~----~----~----~------~----~------~--~---
