Hi,
I'm discovering some interesting implications of dynamic services.
In hibernate-core, building dynamic services causes at least two services to
be realized.
Let us assume that dynamic services are created based upon a contribution to
a service.
For example, dynamic services of hibernate-core are created based upon
contributions to the service HibernateMarkerConfiguration. This service is
injected into the dynamic contributor method (parameter injection)
The use of a HibernateMarkerConfiguration service could be considered
bending the semantics of a "service" a bit, since the service doesn't do
anything apart from providing the markers.
However, there really is only one way right now to contribute the markers,
and that's by contributing them to a service.
The real "problem", however, is not that I'm using a service.
The real problem is that in order to realize the
HibernateMarkerConfiguration service, other services have to be realized as
well, in particular the MasterObjectProvider and ServiceOverride. This means
that after the collectDynamicServices() and collectDynamicContributions()
steps, no dynamic contributions can be done to MasterObjectProvider and
ServiceOverride. Worse, if your contributions to ServiceOverride depend on
HibernateMarkerConfiguration or something like that, there is a recursion
error. Obviously, there's addInstance() to deal with this, but this will not
solve the problem that no new contributions can be done by dynamic services.
In our case it's even worse, since we have a static contribution to
ServiceOverride which depends on HibernateMarkerConfiguration to figure out
whether there are any markers. Voila, recursion. (See appendix below)
The idea is that dynamic service contributors could use injected parameters
for their building, to increase expressivity.
The implication of this is that a combination of modules can cause errors,
while each individual module works fine. Maybe module X depends on service S
to dynamically create classes, and module Y wants to add (dynamic)
contributions to service S. Independently, these modules can be in the
registry, but their combination will fail, because the service is realized
before the dynamic contribution is done. ((Note: in my current
implementation, this won't even be noticed by the Registry, because there is
no checking whether dynamic contributions are done to realized services))
Fill in for X, Hibernate-core, for Y, Hibernate, and for S the
ServiceOverride service (Where ServiceOverride elementOf dependencies(X),
due to the injection of HibernateMarkerConfiguration depending on
MasterObjectProvider to be realized which depends on ServiceOverride to be
realized) and we nearly have our case**. It would even be a problem if X and
Y are equal.
There are several ways to cope with the issue.
POSSIBLE SOLUTION 1
A. Allow updating the configuration of services. Several possible strategies
include: rebuilding the service when the configuration is updated; calling
an updateConfiguration() method in the implementation class. Note that
updating the configuration always means adding a new configuration entry.
B. Generate an error when there is a dynamic contribution to a service that
has already been realized and that is not update-able according to A.
C. Allow injection of objects into Dynamic Service Contributors and Dynamic
Contribution Contributors.
This does not mean every service must be modified to allow
rebuilding/updateConfiguration() calls. By default, services can be "not
update-able". Then, whenever users have clashes, we could modify services to
be update-able. For example, MasterObjectProvider and ServiceOverride could
possibly be made update-able. We need to design the syntax for this update
idea, possibly defining a new annotation to services or service
implementations ("@Updateable", with an enum Updating.PROHIBIT,
Updating.REBUILD, Updating.METHOD; in the last case exactly one public
method in the implementation must have the @ConfigurationUpdate annotation
OR be named updateConfiguration)
POSSIBLE SOLUTION 2
No injection of objects into Dynamic Service Contributors and Dynamic
Contribution Contributors. A different mechanic must be found to contribute
to dynamic services/contributions. Perhaps Dynamic Services/Contributions
could be identified using a "Dynamic id" (which can be shared by different
dynamic contributors) and which other classes can contribute to.
This will severly limit the options for dynamic service/contribution
contributions, as they may not have injected services (or something like the
ObjectLocator) as parameters.
This means no services will be realized during the dynamic part.
This will not mean that a HibernateMarkerConfiguration service will not
exist; it will still exist because there could be static services that may
want to know which database configurations there are (e.g. HibernateUtil in
my solution).
With solution 1, this might mean more work and maintenance of existing
services, although good test cases for every modified service will make this
process much smoother.
With solution 2, this might severely limit the options for dynamic services.
The use case of our multiple database problem can be generalized to the
problem of services with multiple configurations. Essentially that's what we
have here: 6 services (hibernate-core) that have N configurations (e.g. Red
and Blue in the appendix).
Perhaps there are other use cases that need to be considered in the context
of dynamic services/contributions. An example of this is Spring integration,
which I have not looked into yet. (One problem there is that discovery of
spring objects relies on the ServletContext object, which set in the
application globals by tapestry-core during startup... but perhaps core
could be modified to contribute the ServletContext object in some other way,
so it can be discovered by a dynamic solution - until that is solved,
tapestry-spring has to use a TapestyFilter subclass).
POSSIBLE SOLUTION 3
Alternatively, instead of this dynamic service jungle, we could consider
only solving the "services with multiple configurations" problem by using a
@MultipleConfigurations("MCid") annotation.
Modules could statically contribute to a MCid using some syntax.
(@ContributeMultipleConfiguration("MCid") Class[] contributeMarkers() {
return new Class[] {Red.class, Blue.class} })
If placed on a builder, this means "for every contributed marker, generate a
service with additional marker; if no markers contributed, generate a
service without additional markers;" and the marker (or null if no markers
defined anywhere) would be injected into the build method.
If placed on a contributor, this means exactly the same.
Alternatively, contributors may also have the parameter
("MultipleConfiguration") (with subclasses MultipleMappedConfiguration,
MultipleOrderedConfiguration....) which exposes the Class[] array of
markers.
We would have to consider what to do with the case where no markers are
contributed to a MultipleConfiguration. In the solution I just described, it
would fall back to generating a single service. However, maybe one would
always want to create the "no markers" service, using ServiceOverride to set
the default service implementation to the "null" service.... e.g. with
multiple database, if {Red,Blue} are contributed, create Session, @Red
SessionRed and @Blue SessionBlue; if no markers are defined, use Session.
(My current implementation is: if {} is contributed, create Session; if
{A,B,C...} is contributed, create @A SessionA, @B SessionB, @C SessionC,
...)
TLDR;
collecting dynamic services/contributions cause services to be realized,
causing problems with contributions, as well as causing recursion.
solution 1: allow services to be updated when there are new contributions
solution 2: use a different mechanism to contribute configuration to dynamic
service contributors and do not allow services to be realized during
collection
solution 3: do not allow dynamic services, instead create a syntax for the
"services with multiple configurations" concept
I would love feedback. Can't make all the decisions on my own, I'm too
inexperienced for that.
Also, there may be even more things I've overlooked. Please let me know if
there are more issues.
Tom.
** I say nearly, because my current implementation has
HibernateMarkerConfiguration injected into contributeServiceOverride, which
obviously won't work. I could modify this to create a dynamiccontribution,
contributing to Service Override. In this case, the contribution will be
lost.
Appendix:
Registry changes by dynamics
AspectDecorator : DEFINED => VIRTUAL
HibernateMarkerConfiguration : DEFINED => REAL
MasterObjectProvider : DEFINED => REAL
ServiceOverride : DEFINED => REAL
SymbolSource : DEFINED => VIRTUAL
TypeCoercer : DEFINED => VIRTUAL
DefaultHibernateConfigurerBlue : => DEFINED
DefaultHibernateConfigurerRed : => DEFINED
HibernateEntityPackageManagerBlue : => DEFINED
HibernateEntityPackageManagerRed : => DEFINED
HibernateSessionManagerBlue : => DEFINED
HibernateSessionManagerRed : => DEFINED
HibernateSessionSourceBlue : => DEFINED
HibernateSessionSourceRed : => DEFINED
PackageNameHibernateConfigurerBlue : => DEFINED
PackageNameHibernateConfigurerRed : => DEFINED
SessionBlue : => DEFINED
SessionRed : => DEFINED
Op 27-10-2010 2:15, Tom van Dijk schreef:
For your pleasure, I implemented the "abstract class" alternative, as a
different branch.
There are now a number of branches on my git
trunk
|
fix1326 (fixes TAP5-1326)
|
[2 commits without a branch] (fixes TAP5-1321 and TAP5-1320)
/ \
/ \
iocmod2 iocmod3 (fixes TAP5-1313, dynamic services)
| |
[commit] [commit]
| |
hibmod2 hibmod3 (fixes TAP5-48, multiple databases)
the "2" branch uses annotated services
the "3" branch uses the abstract class
Maybe I should learn to "tag" instead of making a load of branches :)
Tom.
---------------------------------------------------------------------
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]
