[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