[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Equinox Aspects and OSGi Weaving Hook Service Specification (56)
|
Hi Alexander!
Ok, everything clear. I will start with the re-implementation of
o.e.e.weaving.aspectj as soon as possible.
This is great!!! Looking forward to it!!!
Cheers,
-Martin
On Thu, May 12, 2011 at 4:23 PM, Thomas Watson <tjwatson@xxxxxxxxxx
<mailto:tjwatson@xxxxxxxxxx>> wrote:
Hi, Martin and Alexander.
Martin is correct. The caching aspect of weaving.hook has to be
implemented as an equinox framework extension. I think it would be
great to get the o.e.e.weaving.aspectj to be implemented on top of
the standard OSGi weaving hooks and then provide the performance
improvements (caching etc.) as special extensions to Equinox.
Thanks.
Tom
Inactive hide details for Martin Lippert ---05/12/2011 01:41:59
AM---Hey Alexander!Martin Lippert ---05/12/2011 01:41:59 AM---Hey
Alexander!
From:
Martin Lippert <lippert@xxxxxxx <mailto:lippert@xxxxxxx>>
To:
Equinox development mailing list <equinox-dev@xxxxxxxxxxx
<mailto:equinox-dev@xxxxxxxxxxx>>
Date:
05/12/2011 01:41 AM
Subject:
Re: [equinox-dev] Equinox Aspects and OSGi Weaving Hook Service
Specification (56)
------------------------------------------------------------------------
Hey Alexander!
> Ok, I now have a much more clearer view on all of the existing logic.
> I agree that going the short way is just a workaround and not a
> upgrade so I will take the long road and will reimplement all bundles
> to use OSGi spec interfaces. Do I correctly understand that
> o.e.e.weaving.hook bundle will therefore be obsoleted completely or
> does it have any extra functions?
I don't think that you can implement the caching part on top of
existing
pure OSGi specifications, but I am not sure.
What I think would be great is:
- having o.e.e.weaving.aspectj to work purely on the OSGi Weaving
hook API.
So people who wanna use aspect weaving can use that on any OSGi runtime
that implements that spec.
- having o.e.e.weaving.hook and o.e.e.weaving.caching to work on
Equinox
only and provide caching for woven bundles, so that people can use that
together with o.e.e.weaving.aspectj, if they wanna have caching for
woven stuff.
I have no idea what that would mean for the implementation of the hook
and the caching, but I would start with adapting o.e.e.weaving.aspectj
to the new OSGi Weaving spec and then would try to reduce the hook
to do
caching only.
Just my thoughts...
Tom, what do you think?
Cheers,
-Martin
>
> On Wed, May 11, 2011 at 11:36 PM, Martin Lippert<lippert@xxxxxxx
<mailto:lippert@xxxxxxx>> wrote:
>> Hey Alexander!
>>
>> It wasn't clear to me if you would like to "just" change the
existing
>> implementation to use the new hook or if you would like to
implement a
>> completely new aspect weaving mechanism.
>>
>> So the existing structure of Equinox Weaving is:
>>
>> - org.eclipse.equinox.weaving.hook
>> This uses the basic Equinox hooks to inject a general bytecode
weaving and
>> caching mechanism. There is nothing special here for aspect
weaving. This
>> hook provides a service interface that other bundles can
implement to
>> provide concrete bytecode modifications and a service hook for
caching
>> services.
>>
>> - org.eclipse.equinox.weaving.aspectj
>> This implements the service interface from the hook mentioned
above and uses
>> the AspectJ weaver to weave aspects into bytecode.
>>
>> - org.eclipse.equinox.weaving.caching
>> This implements the caching service from the hook mentioned
above and
>> implements an asynchronous cache storing on the hard drive.
>>
>> My understanding of the OSGi Weaving specification is that it partly
>> implements what the weaving hook mentioned above implemented (so
that
>> another bundle can implement a service interface in order to
inject the real
>> bytecode modification). So in an ideal world, the
>> org.eclipse.equinox.weaving.aspectj bundle would use that
interface in the
>> future to realize bytecode weaving instead of the old one from
>> o.e.e.weaving.hook. But doing this would also mean that the
caching would no
>> longer work for that weaving (because the old o.e.e.weaving.hook
is the glue
>> between weaving and caching).
>>
>> The other way would be to re-implement the o.e.e.weaving.hook
bundle to use
>> the new OSGi Weaving spec hook instead of the old
Equinox-specific ones
>> while providing the same interface to the outside world as
before (the one
>> that the aspectj component uses). That would allow the caching
to work with
>> this. But from an design point of view, this wouldn't provide a
big step
>> forward, I think.
>>
>> Just some thoughts...
>>
>> Cheers,
>> -Martin
>>
>>
>>
>>
>>> I thought that the only thing this reimplementation would
affect would
>>> be how (using osgi weaving hook vs equinox internal mechanisms) the
>>> aspects are woven, and would not affect other things such as which
>>> aspects to weave, caching etc. But given your question it seems I
>>> thought wrong.. Could you please clarify? Also I'm not quite
sure what
>>> is opt-in and opt-out.. Is this about which side initiates the
weaving
>>> (Eclipse-SupplementBundle vs Require-Bundle)?
>>>
>>> On Wed, May 11, 2011 at 10:49 AM, Martin
Lippert<lippert@xxxxxxx <mailto:lippert@xxxxxxx>> wrote:
>>>>
>>>> Hey Alexander!
>>>>
>>>>> Thanks for your answer, Martin.
>>>>>
>>>>> I will indeed try to re-implement aspect weaving to comply to the
>>>>> specification. If I succeed I'll send you my result so you
could maybe
>>>>> just review it and give it a go saving some of your
development time..
>>>>
>>>> Any contributions are of course highly welcome. Please let me
know when
>>>> you
>>>> have something working here. Would be glad to take a look.
>>>>
>>>> The CVS resources are at the RT repository:
>>>>
>>>>
>>>>
http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.equinox/weaving/bundles/?root=RT_Project
>>>>
>>>>
>>>>
http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.equinox/weaving/features/?root=RT_Project
>>>>
>>>> Hope that helps!
>>>>
>>>> Are you planning on implementing just pure aspect weaving for
AspectJ, or
>>>> are you also looking at the different aspect resolving
mechanisms (opt-in
>>>> vs. opt-out) and the caching for woven classes?
>>>>
>>>> Cheers,
>>>> -Martin
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Therefore could you confirm that these are correct links for
latest
>>>>> source of Equinox Aspects (I got them from the same web site
which as
>>>>> you said is a little outdated):
>>>>>
>>>>>
>>>>>
>>>>>
http://dev.eclipse.org/viewcvs/viewvc.cgi/equinox-incubator/aspects/org.eclipse.equinox.weaving.hook/
>>>>>
>>>>>
>>>>>
http://dev.eclipse.org/viewcvs/viewvc.cgi/equinox-incubator/aspects/org.eclipse.equinox.weaving.aspectj/
>>>>>
>>>>>
>>>>>
http://dev.eclipse.org/viewcvs/viewvc.cgi/equinox-incubator/aspects/org.eclipse.equinox.weaving.caching/
>>>>>
>>>>>
>>>>>
http://dev.eclipse.org/viewcvs/viewvc.cgi/equinox-incubator/aspects/org.eclipse.equinox.weaving.caching.j9/
>>>>>
>>>>> I was confused by 'equinox-incubator' part. You told me that the
>>>>> project has graduated to the main SDK so maybe it now resides
>>>>> somewhere else?
>>>>>
>>>>> On Tue, May 10, 2011 at 8:28 PM, Martin
Lippert<lippert@xxxxxxx <mailto:lippert@xxxxxxx>>
>>>>> wrote:
>>>>>>
>>>>>> Hi Alexander!
>>>>>>
>>>>>> Equinox Aspects is not the implementation of the OSGi
Weaving Hook
>>>>>> Service
>>>>>> Specification. That specification is implemented as part of
Equinox
>>>>>> 3.7,
>>>>>> I
>>>>>> think. So if you use Equinox 3.7, you already have that
specification
>>>>>> implementation at hand.
>>>>>>
>>>>>> Equinox Aspects (now called Equinox Weaving) has graduated
and ins now
>>>>>> part
>>>>>> of the Equinox SDK, so regularily updated by nightly builds,
etc.
>>>>>> Nevertheless there isn't much activity in this area over the
past
>>>>>> month,
>>>>>> but
>>>>>> its pretty stable and usable.
>>>>>>
>>>>>> The relationship between these two things are:
>>>>>> - Equinox Weaving was implemented before the weaving spec
came out, to
>>>>>> it
>>>>>> is
>>>>>> still based on some Equinox-specific hooks deep inside of
Equinox and
>>>>>> is
>>>>>> currently build mostly to weave aspects into OSGi bundles.
>>>>>> - The OSGi Weaving spec was done to allow all kinds of
bytecode weaving
>>>>>> on a
>>>>>> general level, so you should be able to re-implement the
aspect-weaving
>>>>>> part
>>>>>> of Equinox Weaving on top of the new OSGi spec right now. I
haven't
>>>>>> done
>>>>>> that (haven't found the time), but its on my list.
>>>>>>
>>>>>> The web will be updated soon to reflect all this...
>>>>>>
>>>>>> Hope this answers your questions!
>>>>>> -Martin
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Could you please clarify for me whether the Equinox Aspects
is the
>>>>>>> implementation of OSGi Weaving Hook Service Specification?
The thing
>>>>>>> that confuses me is that Equinox Aspects was last update
May 1 2009
>>>>>>> (according to it's home page
>>>>>>> http://www.eclipse.org/equinox/incubator/aspects/index.php)
and is
>>>>>>> still in incubator state with Milestone 7 as the latest
version while
>>>>>>> OSGi Weaving Hook Service Specification (56) was added to the
>>>>>>> specification starting with version 4.3 which was released
about a
>>>>>>> month ago.
>>>>>>>
>>>>>>> If the Equinox Aspects really is the implementation of this
>>>>>>> specification then what is the current status of this
project, what is
>>>>>>> it's latest version and is it stable?
>>>>>>>
>>>>>>> If the Equinox Aspects is NOT the implementation of the
specification
>>>>>>> mentioned then what are the differences between the two and
what can
>>>>>>> help me in choosing between them.
>>>>>>>
>>>>>>> Thanks in advance...
>>>>>>> _______________________________________________
>>>>>>> equinox-dev mailing list
>>>>>>> equinox-dev@xxxxxxxxxxx <mailto:equinox-dev@xxxxxxxxxxx>
>>>>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> equinox-dev mailing list
>>>>>> equinox-dev@xxxxxxxxxxx <mailto:equinox-dev@xxxxxxxxxxx>
>>>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>>>>
>>>>> _______________________________________________
>>>>> equinox-dev mailing list
>>>>> equinox-dev@xxxxxxxxxxx <mailto:equinox-dev@xxxxxxxxxxx>
>>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>>
>>>> _______________________________________________
>>>> equinox-dev mailing list
>>>> equinox-dev@xxxxxxxxxxx <mailto:equinox-dev@xxxxxxxxxxx>
>>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>>>
>>> _______________________________________________
>>> equinox-dev mailing list
>>> equinox-dev@xxxxxxxxxxx <mailto:equinox-dev@xxxxxxxxxxx>
>>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>
>> _______________________________________________
>> equinox-dev mailing list
>> equinox-dev@xxxxxxxxxxx <mailto:equinox-dev@xxxxxxxxxxx>
>> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx <mailto:equinox-dev@xxxxxxxxxxx>
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx <mailto:equinox-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx <mailto:equinox-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
