[wildfly-dev] Service assumptions and the web profile
Richard Achmatowicz
rachmato at redhat.com
Tue Jun 3 15:23:05 EDT 2014
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?
More information about the wildfly-dev
mailing list