[wildfly-dev] Service assumptions and the web profile

[Brian Stansberry]

On 6/3/14, 2:51 PM, Jason Greene wrote:
> 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.
>

To expand a bit on what you said, the way parallel boot works is all the 
MODEL stage stuff is done in parallel. All of it completes before the 
RUNTIME stuff starts. So this data can (and logically should) be 
populated during the MODEL stage. The service assembly work that needs 
it is done in RUNTIME, and can count the data being available.

> On Jun 3, 2014, at 2:23 PM, Richard Achmatowicz <rachmato at 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 at 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
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat