I'm having issues when trying to deploy a somewhat legacy application to Websphere Liberty to facilitate development.
The application runs fine in regular Websphere Server 8.5.5 but won't start in Websphere Liberty. We have another legacy application based on mostly the same technologies/frameworks that runs ok. Unfortunatelöy we won't move to a newer platform anytime soon.
I have the following features configured for my server:
<featureManager>
<feature>localConnector-1.0</feature>
<feature>jpa-2.0</feature>
<feature>jsf-2.0</feature>
<feature>jdbc-4.0</feature>
<feature>servlet-3.0</feature>
<feature>ejbLite-3.1</feature>
<feature>cdi-1.0</feature>
<feature>appSecurity-1.0</feature>
</featureManager>
When I try to start it I get an exception during annotation processing:
[VARNING ] CWNEN0047W: Resource annotations on the fields of the xxx.xxx.EditCardGroupBacking class will be ignored. The annotations could not be obtained because of the exception : java.lang.NoClassDefFoundError: javax.resource.spi.IllegalStateException
whiich seems strange since this would be a part of the JRE?
I have searched various forums/pages for an answer but can't faind the answer. Hopefully someone here can be of assistance.
I'm happy to provide more details of configuration and setup if needed.
javax.resource.spi.IllegalStateException is part of the JCA (Java EE Connector Architecture) specification (see JavaDoc here). You do not get it automatically from Java. Try enabling the jca-1.6 feature,
<feature>jca-1.6</feature>
FYI - if anyone else hits this who has newer level Java EE features, they would instead need:
<feature>jca-1.7</feature>
Related
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.
I was using STS3 and decided to move to STS4. I got it set up and I imported my projects from the STS3 workspace. These mostly made the transition OK, as I am just learning some basic things, mostly what I have is STS "getting started guides" sorts of projects.
However, I didn't see the default Pivotal tc server in the servers tab, and when I opened the "Define Servers" dialog, "Pivotal tc server" is not available.
Did I miss a step in setting up STS4 or is tc Server no longer the default?
The default Spring Tools 4 distribution doesn't include the Pivotal tc Server Developer Edition anymore (as we did with STS3). This doesn't mean at all that the Pivotal tc Server project is deprecated or anything like that. The reason why we don't include that by default anymore is that the Spring Tools 4 are focused on Spring app development using Spring Boot, which usually happens via running the boot apps via the embedded Tomcat option. As a side effect of this, the distribution got smaller and purely open-source... :-)
But those are the only reasons. We still support running Spring Boot applications in locally installed servers like Tomcat or Pivotal tc Server.
Same question asked differently was answered here
Pivotal server is not included in STS 4
Apparently it is no longer bundled by default, but you can install it. I don't think there was any mention of this change in the Pivotal articles about differences between STS3 and 4.
I am developing an app with JAX-RS. The app is running fine on my local Liberty 8.5 Server. It fails when I package and push the server to bluemix. When I try to access my method I get the error:
"NetworkError: 415 Unsupported Media Type"
The system cannot find any method in the class that consumes null media type.
My web.xml looks like the following:
<!-- Enable features -->
<featureManager>
<feature>jsp-2.2</feature>
<feature>localConnector-1.0</feature>
<feature>jdbc-4.0</feature>
<feature>cdi-1.0</feature>
<feature>json-1.0</feature>
<feature>jaxrs-1.1</feature>
<feature>jpa-2.0</feature>
</featureManager>
I searched a lot. Somebody had the same question said it's problem about jaxrs-1.1 which should be updated to jaxrs-2.0, but I don't know how to update it. It's default in Liberty 8.5 Server.
Can anybody help me? It's the first time I ask in stackover
Sorry, I'm not good at English.
Somebody had the same question said it's problem about jaxrs-1.1 which should be updated to jaxrs-2.0, but I don't know how to update it. It's default in Liberty 8.5 Server.
I hope this will be useful for you.
Using JAX-RS 2 Client API in Liberty and Bluemix
Removing JAX-RS feature from Websphere Application Server 8.5
I'm trying to deploy a Java EE web application with RESTful web services and an EJB connexion to another Java EE application.
I'm experiencing several problems and I fail to write down every specific question, so I have no choice but tell you all in a row.
1) First, I am using Tomcat to run the app and I cannot get EJB connexion to work. No matter what, I get a JNDI error : NamingContextFactory class not found. Why ?
My JNDI connexion is as follows :
String hostname = "localhost";
String port = "1099";
String url = "jnp://" + hostname + ":" + port + "/";
Properties h = new Properties();
h.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
h.put(Context.PROVIDER_URL, url);
h.put(Context.URL_PKG_PREFIXES, "org.jboss.naming.client");
initialContext = new InitialContext(h);
2) Therefore, as the server used is not relevant, and as the app I'm trying to connect to is using JBoss (4.4.2.GA), I tried to deploy my app under the same JBoss. I cannot get it to deploy, I have a REST problem: ClassNotFoundException: javax.ws.rs.core.ApplicationConfig at deploy time.
2.1) I am compiling with Netbeans and the ApplicationConfig.class is not part of the 1.1 version of the JAX-RS api jsr311-api-1.1.jar I'm using at compile time. The implementation of the library was changed since 0.8 version, which I was using before, but I had to upgrade the jar because it didn't include #FormParam. Until now, I had found a workaround using com.sun.jersey.api.representation.FormParam instead but Jersey is not compatible with JBoss as far as I understand.
Why is the server looking for ApplicationConfig while it's not used in the war?
2.2) I understood I had to use RESTEasy, and JBoss 4 does not include it, so have to install it manually. But the RESTEasy doc suggest that I thoroughly modify my project my adding a lot of jars, servlets etc. From my point of view, I simply need a RESTful implementation on the server libs to which my JAX-RS API, which is only an interface, will refer once the app is deployed. I may have some serious misconceptions about how Java EE libraries linking work. Please help.
So I know there are several different problems here but I couldn't manage to separate them. I have lost so much time on this that I'm worried for my project. Thanks in advance.
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.