Stuart McCulloch wrote:
2008/5/8 Richard S. Hall <[EMAIL PROTECTED]>:
Stuart McCulloch wrote:
2008/5/8 Clement Escoffier <[EMAIL PROTECTED]>:
Hi,
Creating instances like this have an inherent problem. You can't
assert
that
you're the only user of the created instances.
that's not necessarily a problem - you may actually want global access
:)
but it's cool that iPOJO lets you scope the service visibility while
allowing
you to also open it up to the global service registry, if that's what
you
need
Well, if the service is available for anyone to use, then the notion of
"having" your instance is essentially meaningless...particularly in the case
of a stateful service, as mentioned in the original message...
but it's not necessarily an "inherent problem" if you're creating instances
that don't have
per-client state (there are other types of state) or you want multiple
configurations that
could be shared with other clients...
Agreed. It is only an issue if you want your own instance that no one
else can use...
certainly you should be aware that the service is going into the global
service registry
and as I already said the scoping in iPOJO is neat - but I prefer people to
know there
are these other options (and their pros/cons)
Yep. This is just one potential con.
-> richard
-> richard
Any consumers have access to
the service exposed by the new component instances (despite they don't
have
create the instance).
In iPOJO, we provide a composition model doing this instantiation for
you
but asserting that only instances from the same composite have access
to
the
created instance.
For example, the following composition will create two instances from
the
specified factories. Services provided by these instances are only
available
for instances living in the composite. You could see composite as
another
service registry (in fact, it is exactly another service registry)
isolated
from the global (i.e. OSGi) service registry.
<composite name="mycomposite">
<instance component="your-factory-name"/>
<instance component="your-second-factory-name"/>
</composite>
<instance component="mycomposite"/> <!-- just to create an instance of
the
composition -->
The specified factories (component attribute) can be in any other
bundles.
In fact, composites goes further and you can create composites like
this :
<composite name="mysecondcomposite">
<subservice action="instantiate"
specification="your_service_interface"/>
<subservice action="instantiate"
specification="your_second_service_interface"/>
</composite>
<instance component="mysecondcomposite"/> <!-- just to create an
instance
of
the composition -->
In this case, the composite tracks service implementation (i.e.
component
factories) able to create instances providing the specified service
interfaces.
If these service implementations disappears or appears, the composite
will
deal with this dynamism by looking for new service implementation,
replace
the disposed instance...
Of course, composites can import services from the global service
registry,
or can export services from the composite to OSGi.
Clement
-----Message d'origine-----
De : jaredmac [mailto:[EMAIL PROTECTED]
Envoyé : mardi 6 mai 2008 16:49
À : [email protected]
Objet : Re: Are service implementors inherently singletons?
Felix Meschberger-2 wrote:
Not as per the OSGi framework specification. You might of course -
as I
said above - create a FooFactory and register that factory as a
service.
Your application would then get the FooFactory service and ask that
FooFactory for Foo instances.
Hope this helps.
Great, thank you - that does help. A FooFactory is exactly where I was
headed, and I wanted to make sure that I wasn't creating extra work
for
myself if there were some factory-like capabilities built in to OSGi.
Thanks again,
Jared
--
View this message in context:
http://www.nabble.com/Are-service-implementors-inherently-singletons--tp1709
0261p17092093.html<
http://www.nabble.com/Are-service-implementors-inherently-singletons--tp17090261p17092093.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
