Thanks Tim,
The strings are URL's for configuration files, from the client.
I'll go with the additional level of indirection.
It's interesting that you're from Paremus, this was the last part of the
codebase that needed to be converted to OSGi, everything has now been
converted to bundles and all ServiceFactory's converted to OSGi services.
So here's why I thought it interesting; the codebase is a fork of Apache
River, most of it will make its way back to River. Of course, there
have been a lot of changes since when Paremus was using it in the Jini
days, many, many, many bug fixes, no need for codebase annotations in
streams, proxy bundles are identical at both endpoints, the service
depends on the proxy bundle, the client and the proxy bundle both depend
on the service interface. No more proxy verification after
deserialization, authentication first, followed by hardened atomic
deserialization (using constructors), then constraints. Supports the
latest TLS protocols. There's also a lookup service that returns results
without causing service proxy downloads, that now happens after
authentication and local filtering. It also has an extremely fast and
parallel policy provider,it avoids unnecessary DNS calls, has a RFC3986
compliant Uri class that also normalizes IPv6 addresses following
RFC5952 recommendations. It has an RFC3986URLClassLoader, so
SecureClassLoader doesn't make unnessary DNS calls. Oh it also has IPv6
muticast discovery. Built with Maven now, no more ClassDepandJar.
That's just a summary of course. Never really did get why many Jini
people didn't recognise the benefit OSGi would have provided way back.
Thanks for your help, perhaps if you're interest you might cast an eye
over it for me. :)
Cheers,
Peter.
On 22/08/2019 7:40 PM, Tim Ward wrote:
Hello,
When you say that each client needs a different service instance, would a
bundle need more than one instance (i.e. would a ServiceFactory be sufficient
or does it need to be a PrototypeServiceFactory)?
Also, where are the Strings in the String array coming from? If those are
passed in by the client then you may need an intermediate “factory service”
from which the bundles request instances of the provider.
Otherwise, it sounds as though this would be pretty simple to achieve. The
ServiceFactory gives you access to the requesting bundle, which in turn gives
you the class loader that you need.
All the best,
Tim
On 22 Aug 2019, at 05:58, Peter Firmstone via osgi-dev
wrote:
Hello,
I'm trying to migrate a custom provider interface to register OSGi services.
This is a pre existing implementation, functionally similar to Java's SPI, with
one caveat; it doesn't use a zero arg constructor.
The constructor has two arguments an array of strings, and a ClassLoader.
Otherwise for all intents and purposes, it's an SPI, implementing services use
a META-INF services file.
The interface for the service exists and has implementations.
The ClassLoader passed in is used to resolve classes from the service client.
It doesn't use the Java SPI mechanism, so we have access to the code that
creates the service.
Each client will require a different Service instance.
I was thinking something like a Service Factory might do the job, any thoughts
or advice?
Thanks in adv,
Peter.
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
