| Re: [config-dev] Config questions |
My guess is that Laird is alluding to some kind of meta-data outside the Java code similar to env-entry, etc: https://www.oracle.com/webfolder/technetwork/tutorials/obe/java/env_entry/env_entry.html. Personally, I think this capability has been overkill for some time.
Back in the J2EE days, I well remember the role of application/application server admins. I think these days those roles are very rare and developers actually also do this work themselves especially via Docker, etc (even in case of externalized configuration services such as Azure Key Vault/Azure Configuration Service).
If something similar to a meta data deployment descriptor is
needed, I would suggest doing that in a later release and probably
with ample community input as to the need.
What is the JNDI way of knowing what configuration properties are in use?
On Aug 25, 2021 at 10:10:36 PM, Laird Nelson <ljnelson@xxxxxxxxx> wrote:
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
_______________________________________________
config-dev mailing list
config-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________ config-dev mailing list config-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://accounts.eclipse.org