Speaking as a frustrated user, and not a vendor, I would strongly push for ironing out
the many holes and infelicities in the initial core specs before adding any others.
I'm sure I'm getting some of the details wrong below, but here are some of the things
I've been battering my head against the past few weeks:
- Implementations differ, and apparently experts disagree, about what default scope JAX-RS
resources have without CDI. So since I do need to control that, I *have* to explicitly
have CDI2 annotations on all my resources, and @Path isn't enough. For example,
suppose I have an injected JsonWebToken or other member variable that is not application
scoped. Or suppose I don't want something instantiated on every request.
- Then suppose I want to get my actual application object injected, thank you very much,
and not some crippled proxy. So now I have to learn about the subtle difference
between @Singleton and @ApplicationScoped that somebody thought was a good idea, and
I have to use @Singleton in some places, or resort to vendor-specific unwrapping apis.
- So now I'm using 3 different DI annotations sets (@Context, CDI2, and CDI1) for
a basic REST service -- what is "Micro" about this?
- And I also have to experiment with how implementing or not implementing
getClasses() in my Application interacts with any CDI scanning, not to mention
some janky jandex incantations that might be done at build time, not run time.
- Oh and I have to be cognizant of the vital distinction between having no beans.xml
file and having an *empty* beans.xml file. Because even though there is a "Configuration" spec,
it doesn't include a clean way to configure Microprofile itself; instead I have to
engage in epimestological inquiries concerning the existence of "beans.xml".
In general, there is little consistency among MP implementations in how to control which MP services
I get. Some implementations use an external xml file.
Some do it based on feature "esa" dependencies. Some just control it based
solely on adding the provider dependency jars themselves.
MP itself does not articulate a standard way for me to configure which MP services I want,
let alone doing it using MP Configure.
- Now suppose I do want to get "health" and "metrics'. Where are those endpoint urls
going to be? Is it /health or /contextroot/health or /contextroot/app-path/health ?
Who knows; each implementation seemingly does their own thing.
And if my contextroot is "" are those services still going to get routed?
What about access control? Are those MP services subject to the same filters (CORS etc)
and access control (including MP JWT Auth) as the main app?
Again, implementations vary. So now my monitoring and test scripts have to change
according to MP implementation.
- Speaking of JWT Auth, of course there is no standards-based way to supply the mandatory
configuration. Nor is there a clear standards-based way to express that a method requires
no authentication at all (vs @PermitAll which means authenticated but with no role requirement).
Nor is there clarity on what happens if a client still provides a bearer token to a method
not requiring one. Not to mention the fact that the "groups" claim may or may not correspond
to my @RolesAllowed annotations -- it says that a container must support a 1:1 group to role
mapping, but of course there is no articulation on how such policies are configured, nor
an API for how I might supply an alternative mapping.
- And is it too much to ask that the /openapi yaml/json content
has a "servers" section that represents where my app actually exists in that
very same container, including any contextroot?
So that consuming tools actually work out of the box?
- What if I might like to run multiple apps (microservices) in a single container?
Is that even supposed to work? Because J2EE and servlets each obviously support it.
But I wouldn't dream of trying that with MP.
Oh but maybe JDK 9+ modules might be part of the answer for multiple apps in a container?
Nice idea, but MP says nothing about that, and at the moment it seems that nearly every MP
implementation requires JDK8 to function reliably -- even though realistically anyone
adopting MP is going to want it to work with JDK11.
- Despite the increased interest in cloud/docker/k8 deployments, MP does not articulate
a golden path for deployable artifacts, akin to the "war" for servlet containers.
Most implementations have some kind of support for the abominable executable uber jars.
Some support thin jars. Some support thin wars.
Some use nothing at all, and we are expected to copy the whole build tree over somewhere.
But even though MP has a notion of a container, there is no expressed notion of what
file format it must support for the things it can contain.
In summary: despite the many "starter" projects, and intro tutorials out on the internet, I have
yet to manage to make my basic app work the same way across two implementations -- even
working at all has been a big challenge.
-mda
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
.
