On the Weld.org page, it says for WildFly 12.0.0.Final:
WildFly 12.0.0.Final Weld 3.0.3.Final CDI 1.2 and CDI 2.0 (opt-in
via property)
I can't see how to "opt-in via property"?
What you need to do is look at WildFly site, because you need to run WildFly in so called "EE8 preview" mode in order to have certain EE 8 techs (CDI 2.0 including) enabled.
Namely this article says it all:
By default WildFly 12 launches in EE7 mode. In order to use these new capabilities you have to enable EE8 preview mode. This can be accomplished by passing the ee8.preview.mode property during startup:
./standalone.sh -Dee8.preview.mode=true
There are other options, such as CLI config or modifying the standalone config file. Take a glance at the article to see how that is achieved.
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'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>
we've an application, running in JBOSS EAP 6.4, generating a lot of logs. So we decided to give the application its own log, rotating each hour.
The application uses SFL4J, which is compatible with JBOSS Logging.
As we can't change parameters on JBOSS config we decided to use the logging per deployment feature and added, following the developers manual, a file logging.properties in the classpath, with the File Handler set up as below
handler.FILE=org.jboss.logmanager.handlers.PeriodicRotatingFileHandler
handler.FILE.level=ALL
handler.FILE.formatter=PATTERN
handler.FILE.properties=append,autoFlush,enabled,suffix,fileName
handler.FILE.constructorProperties=fileName,append
handler.FILE.append=true
handler.FILE.autoFlush=true
handler.FILE.enabled=true
handler.FILE.suffix=.yyyy-MM-dd-HH
handler.FILE.fileName=${jboss.server.log.dir}\\pfl.log
While in DEV station everything works as expected (JBOSS Developer Studio 7.1.1 with JBOSS EAP 6.1), in production and test JBOSS generates correctly the pfl.log file and the hourly backups, BUT the pfl.log is never made empty. So it's growing indefinitely (and so the hourly files). Also we noted that the same behavior happens using dayly rotating logs
handler.FILE.suffix=.yyyy-MM-dd
This is getting us crazy.. How can we solve this ? Where can be the problem ? Did we make any config mistakes ?
I'm trying to find the best way to grammatically determine if my program is running on Jboss 5 or Jboss 7 (eap-6.1). The ways I've been finding so far are jboss 5 or jboss 7 specific, which doesn't work because the code has to work in both. Tried both solutions from here: How do I programmatically obtain the version in JBoss AS 5.1? and they didn't work. One complained about org.jboss.Main not existing in jboss 7, the other complained aobut not finidng "jmx/rmi/RMIAdaptor".
The only way I can see is to do Class.forName to look for "org.jboss.Version" (should be found if jboss 5) and if that fails, do Class.forName "org.jboss.util.xml.catalog.Version" (jboss 7). But that seems like a terrible idea.
The reason I need to know if the war is running on jboss 5 or 7 is because there are some custom files that are located in different places in both. So it's like "if jboss 5, execute this piece of code, if jboss 7 execute the other.
Ok i just saw what the problem is.
I would suggest you to think about design issues/refactoring of your software.
If you want to provide your software within different environments, seperate your logic from
technology dependencies.
Build facedes and interfaces to meet environmental requironments.
In my oppionen thats much better as to think we must support all integration platforms and support all there versions. This is completely impossible.
So decouple your business logic and offer specific interfaces. These interfaces (adapters) are much simplier to implement and to maintain.
Hope it helps.
UPDATE DUE TO COMMENT.
I think a solution is for servers 4 to 6 is to use
the MBean Server of JBoss to lookup the registered web application
which is associated to the deployed WarFile.
I suggest first to lookup the registered MBean of the web application manually using the JBoss jmx-console. The name of the WebApplication should be found under the capital "web" or "web-deployment" within the jmx-console.
If you found that name you can implement an own jmx based lookup mechanism
to check for that name.
Here is an Tutorial: pretty old but i think it gives you an idea how to do.
There must be more tutorials for this problem:
http://www.theserverside.com/news/1364648/Using-JMX-to-Manage-Web-Applications
Within JBoss 7 i just can give you the hint that its architecture is based on OSGI. So to lookup for other services you should have a look to this mechanism.
In any case you don't have direct access to the file system and the deployment directory
from an application which is deployed within a JEE container, except of
using the mechanisms provided by the container. JNDI Lookup, JMX ManagedBean mechanism, Java Connector Archicture (JCA) (makes no sense in your case)
It's not an answer just an suggestions since the implementations are completely different
One way could be to use the "interceptors" which are executed during bootstrap and before any ejb invocation and there you have access to the invocation context in other words ejb container.
I can't give you any example but this would be an access point to start.
Another accesspoint is to check for system wide JMX Beans by looking through the
Adminstratore console of the JBoss Server.
You can inject JMX Bean state into your application through the Context Mechansim.
Take a look from Version 4 to 6 at the JMX Managed Bean mechanism. The JMX Achitecture is the main concept of JBoss 3 to 6, so at this point you can influence and maintain the JBoss behaviour.
Aditionally i think you have differences from 4 to 6.x version and 7.0 because since
7 it's a completely new architecture. Since 7.0 the JMX architecture doens't exists anymore.
I've been going through several examples on how to add MBeans to JBoss 5.0 so they can be configured though the JMX Console, but none of these examples have ever shown up in the JMX view. I've now tried to get ehCache's JMX integration to work to no avail.
I'm trying (as in the ehCache documentation) the following:
CacheManager manager = CacheManager.create("./ehcache.xml");
MBeanServer mBeanServer = ManagementFactory.getPlatformMBeanServer();
ManagementService.registerMBeans(manager, mBeanServer, false, false, false, true);
I never see any errors with my own or now with the ehCache version, but it never shows up in the JMX view. I'm wondering - is there a setting I need to make to to the JBoss configuration to get it to pick up these additions? Am I missing something fundamental? Any hints?
Thanks for any help. I'm pulling my hair out here.
If you're running JBoss on Java 5 or above, then you'll likely have 2 MBean servers running: the "platform" mbean server, which is hosted by the JVM, and the JBoss MBean server, which is hosted by the JBoss code. The two have nothing to do with each other.
Your posted code will register ehcache's mbean in the JVM platform server, which is no use to you.
The easiest way to get a programmatic reference to the JBoss MBean server is
org.jboss.mx.util.MBeanServerLocator.locateJBoss()
Try using that instead of
ManagementFactory.getPlatformMBeanServer();