|Re: [config-dev] Config questions|
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 ASuppose 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 BSuppose 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
Back to the top