Hello Todor,
thank you for the helpful answer!
Todor Boev schrieb:
There are many ambiguities here. At least to me :) Some notes:
1) So every Function implementation represents some "formula" like this?
FunctionA() = call "B" + call "C"
2) And you want to set "B" and "C" before you call "A"?
No, the functions should be some kind of business methods or services
like a stateless sessionbean. I named it function to avoid wrong
associations.
They have an Object[] parameter and an Object[] return. They can do some
java operations on these parameters and could call some other functions.
The content, which other functions are called, is static. But there can
be some different implementations of one named functionA. For example:
- functionA in version 1 is registered with the pair name="functionA"
version="1" and just calls functionB without any version
- functionB in version 1 is registered with the pair name="functionB"
version="1"
- functionB in version 2 is registered with the pair name="functionB"
version="2"
I want this behavior:
- With context set to "B1", calling functionA results in a call of
functionB version 1
- A changed context set to "B2" results in a call of functionB version 2.
- Context could be some kind of threadlocal variable or something else
as you stated later. It depends not on the function itself and can not
be changed by a function.
3) You have multiple instances identified with the same (name, version)
pair? Isn't this problematic? How do you distinguish between them :)
No, each pair has only one function instance. Name and version are only
examples. The pair could also contain a field "scope". This is only an
example.
4) You essentially want to configure an environment of (Name->Function)
pairs and than do a call to a FunctionX. Within the current thread you
want this environment to hold while in another thread the environment
can differ? I.e. you need a thread-local environment rather than a
thread-safe functions? If this is the case you solve this in a "library"
way by storing a ThreadLocal in some well known static field. Or
alternatively thread the environment as a parameter to work() (same deal).
Yes, I have something like this in mind. Thank you for confirming my
thoughts.
6) Is the RetrieverService an OSGi service? If so it will be the one
using the FunctionX instances and it has to track them to make sure they
are released if the FunctionX bundle goes away. The users of
RetrieverService must never cache the FunctionX instances returned to
them.
Alternatively RetrieverService can be a is a utility that wraps a
the BundleContext of the bundle owning a FunctionX service. In this case
consider using a ServiceTracker instead. Or better still use iPojo,
Peaberry or Spring DM to handle service binding, unbinding for you.
iPojo and Peaberry in particular cache service references and release
them when not used for a while (I am not sure for iPojo but Peaberry
does it in this way).
This is what I'm asking for. I have not used OSGi before, so I have no
experiences how to implement the dynamic retrieving of functions in a
good way and how to get the system stable.
If the retriever is an OSGi service and it uses the
BundleContext#getService(ServiceReference) method. This means that the
retriever has to release service? In a multithreaded environment, where
I can have multiple calls to the same function instance, this could be
problematic.
On the other hand with a retrieverUtil, then I could bind the retrieved
services also to a threadlocal and have to release them on the end. This
looks good for me. Can this be the solution?
Maybe I use an AbstractFunction which can do the boilerplate and store
all needed things in a threadlocal. Then every function instance has to
hold the bundlecontext. Is this a good way?
Let me say, that the number of functions and the instances for all pairs
could increase heavily during runtime. I would like to deploy new
versions and new functions during runtime keeping all others alive.
Is it possible to dynamically react on new versions instances with a
servicetracker or iPojo? Does this mean that I will have one
serviceTracker for each function instance? Then I have to do the same
work as the servieregistry for the services in the serviceretriever for
the servicetrackers: manage all available.
I thought I can use the serviceregistry as manager for the functions and
the retriever handles only how the functions can reach other ones.
Maybe for each call again. Could this result in a bad performance?
Thanks for reading the long text :)
Regards,
Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
