Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    James Carman
    @jwcarman
    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.
    Andy McCright
    @andymc12
    it's all relative. :) but the more parameters in the constructor, the uglier it gets.
    James Carman
    @jwcarman
    I'm okay with the 1 I have 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 :(
    Andy McCright
    @andymc12
    I think it is a requirement for CDI - I'm not a CDI expert, but I think RequestScoped beans need to have a public, no-arg constructor. I wonder if you could change the scope (try @ApplicationScoped or maybe @Dependent) if it would work without the no-arg constructor
    James Carman
    @jwcarman
    @ApplicationScoped didn't work...
    but, for some reason, @Dependent does
    I really need to get better with CDI. I've been in "Spring Boot Land" for so long.
    Andy McCright
    @andymc12
    @Azquelt or @tevans78 might know more, but I think @Dependent doesn't produce a Java proxy, so it doesn't need the no-arg constructor. That might explain the requirement.
    James Carman
    @jwcarman
    Yeah, this is where things start to get really fuzzy for me with CDI.
    They seem a bit overzealous with the proxies
    I get why they're needed in certain cases, but CDI seems to have gone overboard.
    Andy McCright
    @andymc12
    yeah, as a user, I really like CDI - for the most part it simplifies code and "just works", but (like many things) there are a few "gotchas" that don't seem to make a lot of sense.
    James Carman
    @jwcarman
    I'm sure it's just growing pains for me and I'll get used to it eventually, after I bump my head against the wall enough times.
    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
    James Carman
    @jwcarman
    Thanks, as usual, for the convo, @andymc12. If we ever get to have conferences again, it'd be good to meet you face-to-face and buy you a beer for how helpful you've been to me.
    Andy McCright
    @andymc12
    no problem - until then, virtual cheers! :)
    Andrew Rouse
    @Azquelt
    @andymc12 is right, if it's not @Dependent then CDI needs to be able to proxy it, so it must have a non-private no-arg constructor
    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
    Benjamin Marwell
    @bmarwell
    @Inject public PersonResource(Bean bean) -- JAX-RS does not support constructor injection (sadly). :( @jwcarman
    Benjamin Marwell
    @bmarwell
    @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?
    Bjørn-Willy Arntzen
    @bwa
    Trying to find a golden solution for liberty-maven-plugin, but have issues ... OpenLiberty/ci.maven#943
    mdagit
    @mdagit
    I have a JAX-RS ContainerRequestFilter which does some checks and then if it doesn't like the smell it will do:
    requestContext.abortWith(Response.status(Status.FORBIDDEN).entity(Map.of("error", err)).build());
    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: /
    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> ?
    Andy McCright
    @andymc12

    @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());
    or
    requestContext.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.

    mdagit
    @mdagit
    @andymc12 oh good idea let me try that. For some reason i had it in my head that text/plain was a default implicit content type but maybe i just made that up.
    Andy McCright
    @andymc12
    yeah, I can't find any mention of a default MediaType - but I did find that there is a 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());
    mdagit
    @mdagit
    @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?
    Andy McCright
    @andymc12
    I'm not sure. Did you switch from jaxrs-2.0 to jaxrs-2.1? You would get different behavior in that case.
    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
    @mdagit
    @andymc12 thanks again!
    Scott Kurz
    @scottkurz
    @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
    Benjamin Marwell
    @bmarwell
    @scottkurz do you think disabling file serving will do any good (for security)?
    Scott Kurz
    @scottkurz
    Hi @bmhm .... I don't have much of an expert opinion there. Perhaps someone else will chime in (though it's the end of the week, so maybe not today)
    mdagit
    @mdagit
    @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?
    mdagit
    @mdagit
    @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.
    Scott Kurz
    @scottkurz
    Thanks @mdagit for that feedback. I will pass it along to our security development team.
    mdagit
    @mdagit
    regarding httpEndpoint host in server.xml is there a way to give a list of names? I like the convenience of the "*" wildcard but it seems to have the consequence of using "localhost" for the self-signed certificate. So i'd like to give a list where presumably the first would be used for the self-signed certificate. Unless there is another config for that.
    Spas Poptchev
    @spoptchev
    Hi, we have an issue when activating the wsSecurity-1.1 feature: Unable to load class net.sf.ehcache.store.DefaultElementValueComparator. Initial cause was net.sf.ehcache.store.DefaultElementValueComparator.<init>(net.sf.ehcache.config.CacheConfiguration). We also tried to disable the cache with <wsSecurityProvider id="default" ws-security.enable.nonce.cache="false">. But the error still appears. Did anyone one of you had the same issue and can help us out?
    1 reply
    John Redwood
    @VeenarM_gitlab
    Hi All, quick one as I havne't been able to find anything in the docs / notes... In migrating from tWAS to OpenLiberty we used to have IBM MQ JMS failovers configured at the tWAS level. Does OpenLiberty support this feature somehow as well? or do we need to configure two MQ's and do it manually in code as a fallback?
    4 replies
    mdagit
    @mdagit
    it seems my ticket OpenLiberty/open-liberty#12915 has been moved to the "Icebox" which seems ominous and i'm guessing means that it'll never be addressed. Which is too bad, because it is a very real use case. I mean, there is even a rfc for it now: https://tools.ietf.org/html/rfc8693 . But the openliberty JWT implementation seems to basically make it impossible to do.
    2 replies
    Benjamin Marwell
    @bmarwell
    Hi, hope this is the right place to ask. The JDK's readme from (Open)Liberty points to
    https://www.ibm.com/support/pages/java-sdk-fixes-version-80. But that page does not exist anymore. Oliver already asked in the slack channel but just got the answer that those pages and links are outdated.
    10 replies