hmm... actually, it might work today as long as you have a public no-arg constructor too: OpenLiberty/open-liberty#7010
That seemed to work, but man that's ugly
@Path("persons")
public class PersonResource {
private final PersonRepository repository;
public PersonResource() {
this(null);
}
@Inject
public PersonResource(PersonRepository repository) {
this.repository = repository;
}
@GET
@Produces(MediaType.APPLICATION_JSON)
@Path("{id}")
public Person getPerson(@PathParam("id") String id) {
return repository.findById(id);
}
}
yeah, that's kinda ugly, wouldn't you agree?
JAX-RS is supposed to pick the "longest" constructor, isn't it? I don't know what CDI is supposed to do here.
So, is this just a "work around" for a bug in OL?
or is this per the spec and how things are supposed to work?
Oh, and now I have to test this no-arg constructor or else it jacks up my coverage numbers :(
but, for some reason,
@Dependent does
I really need to get better with CDI. I've been in "Spring Boot Land" for so long.
They seem a bit overzealous with the proxies
I get why they're needed in certain cases, but CDI seems to have gone overboard.
There are gotchas in Spring too, but I have hit them so many times that I just naturally shy away from those approaches to avoid it
https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#unproxyable lists the requirements to allow CDI to proxy a class, and the situations when it needs to do so
@jwcarman @andymc12 this one is related as well: eclipse/microprofile#50
If I am reading this, there will be a CDI dependency in JAX-RS?
If I am reading this, there will be a CDI dependency in JAX-RS?
Trying to find a golden solution for liberty-maven-plugin, but have issues ... OpenLiberty/ci.maven#943
but I'm getting this in OL messages.log when that code is triggered:
[9/25/20, 14:16:47:531 PDT] 0000001e org.apache.cxf.jaxrs.utils.JAXRSUtils E No message body writer has been found for class java.util.ImmutableCollections$Map1, ContentType: /
[9/25/20, 14:16:47:531 PDT] 0000001e org.apache.cxf.jaxrs.utils.JAXRSUtils E No message body writer has been found for class java.util.ImmutableCollections$Map1, ContentType: /
and the client sees a 500 http status instead of a 403 status
not sure what to do about that -- what kind of jax-rs runtime can't serialize a Map<String,String> ?
@mdagit you may need to specify the content type in your response - something like:requestContext.abortWith(Response.status(Status.FORBIDDEN).entity(Entity.entity(Map.of("error", err), MediaType.APPLICATION_JSON)).build());
orrequestContext.abortWith(Response.status(Status.FORBIDDEN).header(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_XML).entity(Map.of("error", err)).build());
I'm just randomly guessing at the content type you want - but ultimately, that's the issue - the runtime doesn't know what to serialize the map to.
yeah, I can't find any mention of a default MediaType - but I did find that there is a
requestContext.abortWith(Response.status(Status.FORBIDDEN).type("text/plain").entity(Map.of("error", err)).build());
type(...) method on the ResponseBuilder class that might be cleaner than the snippets I first suggested. ex:requestContext.abortWith(Response.status(Status.FORBIDDEN).type("text/plain").entity(Map.of("error", err)).build());
@andymc12 - you were right! Things working swimmingly now. Getting a real 403 back. I don't really understand how the server determines its providers; I think what happened is my maven build used to pull in jackson, and i removed that from my war build, and now OL is using apache CXF? Is that a possible explanation of why this used to work? But I thought there is all this class loader separation and whatnot to prevent that sort of side-effect?
actually, now that you mention it, I think the Jackson provider would match any object type and any content type, so removing Jackson might've broken this.
I'm logging out. I'm glad things are working for you now. Have a good weekend!
@mdagit, just wanted to follow-up (as promised) by pointing to the publication of our "security hardening" doc describing best practices regarding configuration, etc. Check it out here: https://openliberty.io/docs/20.0.0.10/security-hardening.html
We also released the ACME support so you can move beyond the simple self-signed certificate in development: https://openliberty.io/blog/2020/09/25/signed-certificate-with-acme-200010.html
@scottkurz very timely because i actually have a question regarding self signed certs. Right now my server.xml has <httpEndpoint host="*" ... but it seems that as a consequence of that, if I don't don't override the default self-signed cert, it is generated for "localhost". If i do want multiple hosts bound, I'm guessing it choose the first to get the cert. So would I do something space separated like host="${env.HOSTNAME} localhost" to get it to bind both ips, but generate a cert for HOSTNAME from env?
@scottkurz regarding the security-hardening.html doc my main feedback would be that the discussion of password management should be deeper. There is discussion there of one approach of using AES symmetric encrypted secrets with encryption key kept in a separate file. This fails the test of having no secrets in data-at-rest because of the bootstrapping key. And to really make it work, one would have to go through and find everything like java keystores too. AFAIK (Open)Liberty has no builtin support for credentials stores such as vaultproject or kurbernetes credentials. Also, the bootstrapping key might be something kept in a startup environment variable, or ready from stdin (if doing a manual start). There are also more sophisticated approaches to avoiding a permanent secret on disk, such as temporary use access tokens (tickets) that will expire if not used. Suffice to say it is a much bigger topic.
@scottkurz regarding ACME - great that you've added it but as i'm sure you are aware there several ways in which domain administration can be verified, and port 80 is just one of them. I'm right now in the odd situation at one client where i have DNS control but am not allowed to bind port 80. Also, the docs will need to say something about how/whether the 90 day refresh is taken care of by OL.