I had some questions regarding the direction
that Jakarta Config seems to be headed in. I expect I'll
have more.
In what follows, please feel free to substitute your
favorite Jakarta EE component as needed (i.e. if I say
"Servlet" I could have said "JAX-RS resource class" or
"EJB" or "connector" or almost anything else).
In what follows, I'll use MicroProfile-Config-like
syntax since that seems to be familiar to the
committers. In what follows I neither endorse it nor
denigrate it.
Most of the questions are
component-environment-namespace-oriented and
application-assembly-oriented.
The questions are genuine and are not intended to be
confrontational. Maybe they have simple answers; maybe
they do not. Maybe they are insightful. Maybe they are
dumb.
When I use the term "application assembler" I mean it
to be exactly the term that is defined in the Platform
Specification: no more, no less.
Please assume as part of the thought experiment
that the application assembler does not have the
source code for the Jakarta EE components in question
in case it turns out to matter. It may not.
I list two arbitrary but representative scenarios, A
and B, and then list my questions beneath them that
apply to them. Thanks for your time and consideration.
Scenario A
Suppose we have an application assembler taking
delivery of two Servlets and their associated classes in
classic Jakarta EE fashion. She is of course tasked with
assembling them into an application.
Suppose Servlet 1 internally does config.getValue("foo.type",
Integer.class), and is "expecting" a textual
configuration value of something like "3" that will be converted.
Suppose Servlet 1 does not supply its own Converter<Integer>.
Suppose Servlet 2 also internally does config.getValue("foo.type",
FooType.class)—note the different conversion
type—and is "expecting" a textual configuration value of
something like "LARGE".
Suppose it supplies its own Converter<FooType>
that converts "LARGE" into
a FooType. Suppose, in
case it matters (I don't know if it does or not), that FooType is a class defined by
this component.
Scenario B
Suppose we have an application assembler taking
delivery of three Servlets and their associated classes
in classic Jakarta EE fashion. She is again of course
tasked with assembling them into an application.
Suppose Servlet 1 does config.getValue("room.length",
Integer.class) and is expecting a textual
configuration value of something like "8". Suppose it does not
supply its own Converter<Integer>.
Suppose Servlet 2 does config.getValue("room.length",
Integer.class) and is expecting a textual
configuration value of something like "8 feet". Suppose it supplies
its own rigid, strict Converter<Integer>
that converts "8 feet"
into Integer.valueOf(8) by dropping the last word
from the string before attempting an Integer.valueOf(8) operation, failing if there
is no such word.
Suppose Servlet 3 does config.getValue("room.length",
Float.class) and is expecting a textual
configuration value of something like "2.4384 meters". Suppose it
supplies its own Converter<Float>
that converts "2.4384 meters"
into Float.valueOf(2.4384F).
Questions Applicable to All Scenarios Above
- What is the application assembler supposed to do
in general here?
- How does she know what configuration properties
are being requested by the Jakarta EE components?
- How does she know that each component is
expecting a different sort of thing or behavior
under the same name?
- How does she know what Converters
are in the picture? Can she somehow override
them? (Remember, in case it matters, that the
application assembler as defined in the Platform
Specification doesn't write or compile code.)
- How does she reconcile all this? That is, how
does she, or someone playing the configuration
author role, write appropriate configuration for
each scenario that satisfies each component?
- What if component-supplied Converters have
priorities of Integer.MAX_VALUE?
(How would she know?)
(As an arbitrarily chosen alternate system playing in
the same architectural space, JNDI, nobody's favorite
API, provides an answer (clunky, but serviceable) for
each of these questions. I am not endorsing it, merely
pointing out that they had questions like these ones and
had answers for them. We must too.)
I will probably not be on the Thursday, August 26
meeting.
Thanks in advance for your time,
Laird