What is meaning of (https://www.keycloak.org/archive/downloads-17.0.1.html)
Keycloak: Distribution powered by Quarkus
Keycloak WildFly (deprecated): Distribution powered by WildFly
When i see documentation it says:
The default distribution of Keycloak is now powered by Quarkus, which brings a number
of breaking changes to you configure Keycloak and deploy custom providers.
For more information check out the Quarkus Migration Guide.
The WildFly distribution of Keycloak is now deprecated, with support ending June 2022.
We recommend migrating to the Quarkus distribution as soon as possible.
However, if you need to remain on the legacy WildFly distribution for some time,
there are some changes to consider
I am using Wildfly as application Server where projects are deployed.
Shall this means i use Wildfly distribution of Keycloak only whose support is ending June 2022.
or
Does this mean that Keycloak use Wildfly underneath and not use that anymore and quarkus is used? (now here can quarkus distribution work fine with wildfly settings we currently have)
Unfortunately, it has nothing to do with WildFly anymore. Until recent versions, the Keycloak was being packaged as a Java EE archive file (or as WildFly module) that you could deploy into WildFly application server.
Quarkus on the other hand is a framework to develop cloud native Java applications. It's runtime relies on many open source projects for underlying services (e.g. Vertx, SmallRye projects, etc.) and has a completely different architecture. As part of such a migration, Keycloak is now being packaged as an standalone java application (that is a typical output for an app developed using Quarkus) and contains all its dependencies. So there is no deployment/installation on WildFly anymore.
Quarkus applications are being designed by default to be run on cloud environments like Kubernetes. So you may also require to consider if you can benefit from this if you have such an infrastructure in your organization (however it's not mandatory and you can just run it as a normal java app on your server). But you can definitely not use your WildFly specific configurations (e.g. the Keycloak subsystem or OpenID subsystem) anymore.
You can find more details here.
Quarkus is a variation of Wildfly that is packaged in such a way as to make containerization (i.e. Docker, Kubernetes, etc.) much easier. Applications written for Wildfly (and JEE in general) can be made to run in Quarkus quickly.
Wildfy 25 and above include OIDC functionality internally. Therefore, you don't need to install the Keycloak extensions like you used to. And Keycloak, as of version 15, is based on Quarkus too. Because of this there is a build phase of the installation that lets you set many of the options before the run phase. For example, I used to setup a data source in the standalone.xml for my database. Now, I use the resources.properties to setup my database for Keycloak. The concepts are similar.
If you're using a version of Wildfly less than 25 then you'll still want the Keycloak adapter.
Related
we want to deploy keycloak.X to cloudfoundry. I found older approaches (How to deploy keycloak to cloudfoundry) with two options:
wrapping it as a Spring application (the corresponding stuff on github seems abandoned, guess this is because keycloak switched to quarkus?)
using the docker image (diego_dockeris disabled in my target environment)
So I am stuck with the Quarkus distribution.
Ideally, I dont want to change too much on the application itself (risk assessment ...) but only wrap it for cloud foundry.
The start script targets a class named QuarkusEntryPoint, but I don't know how to put it into a buildpack.
We are a Java shop and use maven. Our app is on wildfly 18. Does anyone have any experiences on migrating a wildfly app to OIDC? We were given a security library that we can use to make OIDC calls to, but it requires a config file co-located with this library. Do we need to use a module for this? If so, do we need a particular section filled out in our standalone.xml?
You asked about Wildfly 18. This one for sure needs add-on modules, such as those provided by the keycloak project (https://www.keycloak.org/downloads).
Since Wildfly 25 the OpenID Connect functionality was added to the Wildfly releases, and since then the addon modules are no longer required. In fact, they should no longer get installed as they seem to break Wildfly.
See also
Secure WebApp in Wildfly 25 using OpenID Connect (OIDC) without installing a Keycloak client adapter
https://docs.wildfly.org/25/WildFly_Elytron_Security.html#validating-jwt-tokens
https://www.youtube.com/watch?v=2gQO4_7Z5CI
I want to use an embedded http server in my enterprise apps (and move away from standalone containers) and was expecting Tomcat to provide an implementation. I was assuming Sun, Jetty and Jersey's implementations cannot support enterprise load.
But looking at Tomcat, I see no way to run REST apps that use JAX-RS, only servlets. So my questions are:
Will use of com.sun.net.httpserver.HttpServer work in a production environment, or do I need another library?
Am I understanding correctly the boundary between JAX-RS embedded servers and servlet containers (maybe that will explain why Tomcat doesn't provide such a server)
Other notes:
I do not want to use Spring unless that's the only choice
We have an old JBoss 3.2.3 server which hosted an application and exposed EJBs for remote access.
This application has only received minor maintenance in years, and we did not put some effort to migrate it to newer releases of the app server.
Now, we are integrating it with another application, and we have a requirement to also expose SOAP Web Services.
At first, I wasn't worried, since JBoss 3.2.3 announces compliance with the J2EE 1.4 spec (JSR151), which specifies the APIs for web services: web services (JSR109) and JAXRPC (JSR101).
However, my first deploy using the JAX-RPC api failed, because JBoss did not find the JAX-RPC classes.
So my questions are:
Is JBoss 3.2.3 really a J2EE 1.4 app server ? The lack of JAX-RPC classes seem to indicate otherwise.
What are the APIs for exposing a web services in JBoss 3.2.3 ?
What are the APIs for consuming a web services from an EJB deployed in JBoss 3.2.3 ?
In the end, I can always deploy additional APIs and libraries with my application, but I'd like to avoid overlapping existing libraries.
JBoss 3.2.3.GA is not a fully compliant J2EE 1.4 server. For instance, it does not implement the EJB 2.1 interface, only EJB 2.0 [1].
Also, JBoss 4.0 announces being the first J2EE 1.4 compliant server; I conclude that JBoss.org did not certify JBoss 3.2.3 as compliant.
Even though not-compliant, JBoss 3.2.3 has some features for consuming SOAP Web-Services. For instance, it ships with Apache Axis 1.1 and JAX-RPC apis, so one can easily generate java classes for a WS client outside the server and have them run in an enterprise app.
Exposing web services is a more difficult task. One way of exposing web services is to create a Stateless EJB and expose it as a webservice endpoint. However, that's part of the EJB2.1 spec, which is not available in 3.2.3.
Too bad ! In the end, we will look for other alternatives in exposing our web services.
The newer JavaEE specs and servers are so much easier to develop for. It's the old specs and servers that gave JavaEE a bad rep.
We could see JBI in Glassfish V2 but it is not in V3, what's happening? Which application server is useful for SOA development?
can I deploy WSO2 on Glassfish or JBoss?
RGDS
I'm not sure this answer is definitive, just based on my own experience with these systems.
JBI isn't a Glassfish feature (if it ever was its news to me). Its a (kinda/sorta) Sun community standard which has many implementations (ServiceMix to name one of several) that can be installed on any J2EE container (such as Glassfish to name one). Although it was once very popular it seems to have fallen on hard times of late, perhaps simply because ESB hype got swamped by the new wave of cloud hype.
WSO2 is much larger and includes JBI as one of its many options. By default its based on its own embedded Tomcat, but WSO2 claims its possible to run it on an external Tomcat (I never managed to make this work). To my knowledge no one has tried or succeeded to make it work on Glassfish.