I didn't mean that they used aspectj for proxying but rather suggesting that aspectj could be used *instead* of proxying to achieve the same results. We discussed earlier that e.g. guice-warp couldn't support final or private methods for starting transacation because it used CGLib, but using a delegating approach *instead *of using a proxy could solve the problem (which you seem to imply as well if I'm not misstaken). But whether this is applicable to Guice is another question.
I think it would be very cool if Guice could support something similar as Springs AOP support for injection. Actually I'd like to create a spike for this if I get some time over, I've been needing this kind of stuff myself. /Johan On Wed, Nov 26, 2008 at 9:22 AM, Stuart McCulloch <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
