[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Integrating AspectJ Load-Time Weaving into OSGi/Eclipse

equinox-dev-bounces@xxxxxxxxxxx wrote on 09/20/2005 05:19:42 PM:

> Some more details on the AJEER implementation:
> - AJEER creates separate weaver instances for each bundle. This is done
> to ensure that the type resolution for the weaver matches exactly the
> class loading of the bundle.

Interesting point.  The view of the world differs from bundle to bundle.  A and B may both see some package P but may see completely different version of it.  From your comment hten I assume that the weaver somehow has a cache or view of the types in a system such that having just one weaver would result in flat namespace?

What are the performance implications of having multiple weavers?  Like say I was to have 2000 of them?  Do they stick around or are the created serially as each bundle is woven?

> - AJEER implements a byte-code caching mechanism to skip the
> time-consuming weaving task if nothing has changed (same bundle version,
> same aspect version, same set of aspects).

Cool.  any idea how this might play with a VM based shared classes mechanism?  On a different point, do you also have to know about changes in supporting classes (e.g., supertypes) and classes from fragments?

> Therefore AJEER is separated into two bundles: the first one enhances
> the OSGi framework adaptor to intercept class loading and takes care of
> the byte-code cache. It provides a hook for other bundles to inject
> bytecode modifier components. The second bundle injects the AspectJ
> weaver as a bytecode modifier component.

So is the adaptor would be one point of overlap between the two approaches?  Would it make sense to try and reconcile/unify that hook as first step?  Seems that such a mechanism should be generic.  Exploring this is interesting as we are wanting to refactor the adpator to make this kind of change independent of, for example, the disk layout, which also happens to be defined by adaptors but is clearly not interesting here.