2:51 p.m.
Yes just to be clear:
OPTIONAL SHOULD NEVER BE USED FOR CROSS SUBSYSTEM DEPENDENCIES!
It’s very hard to use OPTIONAL correctly, so avoid it like the plague (this is why it’s
deprecated).
There are other strategies that work in many cases. For example you can use PASSIVE
services.
However, the thing we are really missing is cross-subsystem negotiation (capabilities).
This is actually a trivial thing to implement, Kabir had a prototype at one point, and we
should introduce it in 9.
The classic problem example is jacorb and tx. They require circular configuration.
The general notion is that you have a set of detyped flags that convey various
configuration relevant info like:
tx subsystem: SUPPORTS_TRANSACTIONS
SUPPORTS_JTS
corba subsytem: SUPPORTS_CORBA
These can be assembled in quickly after parsing but before services are assembled. Then
subsystem service assembly can begin in parallel, as today. So for example, corba can see
that JTS is enabled, and install the proper interceptors. TX can see Corba and create the
proper service dependency.
On Jun 3, 2014, at 2:23 PM, Richard Achmatowicz <rachmato(a)redhat.com> wrote:
Hi
A general question on which services we can assume are available in a
sever configuration and which we cannot.
When installing services, we often need to add in service dependencies.
If a dependency is marked as required and it does not exist, the service
will not start correctly. So, when setting up a service and its
dependencies, if possible, I would like to know which dependencies are
guaranteed to be available and which I may need to optionally check for.
The OPTIONAL flag for dependencies was meant to address this but it now
deprecated as it doesn't work so well when you are unlucky enough to
have your dependency start after your dependent service.
The web profile is intended to be a slimmed down version of the full
profile, and in the case of the EJB subsystem, the spec says that it
need not implement certain EJB feature subsets, among which are
asynchronous method invocations, timer service and remote invocations.
However, our web profile EJB subsystem includes all of these. It is
conceivable that an admin would want to create a slimmed down version of
the EJB subsystem and remove some of these services. All three of these
can be easily removed by deleting configuration elements.
What to do here?
- assume that all subsystems and services defined in the shipped web
profile will be present and no dependency checking is required?
- assume that a certain minimal subset of subsystems and services
defined in the shipped web profile will be present and that an admin may
"turn off" some services, for example the features not part of EJB Lite
and so some form of dependency checking is required? And which services
can we assume are present?
In the case of the EJB subsystem, I would expect that dependencies like
the Remoting system endpoint can be assumed to be present, but the
optional features above and beyond EJB Lite may not be. But this is all
pretty much ad hoc.
Any thoughts?
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat