[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] [prov] p2 mixing extensions and services?
|
I see. Somehow I lost Pascal's Email (maybe got stuck in some overambitious spam-filter), but here goes anyway. I don't really have a problem with the whole OSGi Services - Eclipse Extensions struggle, it just wasn't clear to me. Somehow I just assumed, with p2 being part of Equinox which in turn is an OSGi framework, it would perhaps be heading more in the direction of being 'pure' OSGi (in lack of a better word, not implying anything stupid...). :) But anyway, thanks for sorting it out.
Regarding the singleton, I don't have a specific use-case up my sleeve, just a gut feeling that singletons, while convenient in a small scale, along with all (or at least most) global data should be avoided. I know, I know, in Java there's no such thing as global data, it's all tied to the classloader at some point, but there's a similar discussion on the osgi-dev mailing list right now concerning multiple OSGi-framework instances coexisting within the same JVM.
As a hypothetical use-case you could probably also take remote invocation, if you have it as an OSGi service (for example) instead, there's nothing keeping the framework from giving you a proxy-implemenation doing RMI calls, which might be interesting in a distributed system, where the touchpoints are actually remote. Hypothetically. :) I can't think of a situation where this would be the case, but distributed systems are undeniably cool... ;)
Fredrik.
On Mon, Jun 16, 2008 at 02:14, Jeff McAffer <
jeff@xxxxxxxxx> wrote:
Just to add a bit to this. The actual structure of the p2 code is far
from optimal. We made a number of trade-offs in the interest of
getting things done rather than proper component programming style.
Expect these to be revisited soon.
Jeff
Pascal Rapicault wrote:
Hi Fredrik
Extensions and services are complementary. In p2 we chose to use
services to interconnect the logical components of the system (and in
the future help with their replaceability) and extensions when we
needed pluggability (e.g. repository types, touchpoints, GC root sets,
etc.). This is very much in line with how we've done things in the past
in Eclipse.
I don't want to go down the path of extensions vs services, as this has
been covered by various articles, but I would like to emphasize that
"extension/extension points" are as OSGi-y as anything else and the
extension registry is usable in other OSGi frameworks. They are just
another way to compose your system.
As for the singleton nature of the TouchpointManager, it is just
lazynsess, convenience. Could you elaborate on the use-case requiring
it to be non-singleton?
HTH,
PaScaL
"Fredrik
Alströmer" ---06/13/2008 05:27:52 AM---Hi people, I've been digging
through the source code of p2 a bit, and I'm a little bit
Hi people,
I've been digging through the source code of p2 a bit, and I'm a little
bit confused by the inhomogeneous use of extensions (touchpoints) and
services (pretty much everything else as far as I can tell). Why can't
the touchpoints simply be OSGi services? The reason I'm asking is that
I'm trying to figure out if it would be possible to use equinox p2 in a
more OSGi-y environment (perhaps with a different OSGi framework).
I'm also a little bit confused by the TouchpointManager singleton, is
that really necessary (the singleton, I mean)? or is that somehow a
logical consequence when using extensions?
Does that make sense at all? :)
Thanks,
Fredrik.
equinox-dev mailing list
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
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
