Jeremy Whiting

You might find starting over and using the Wildfly 26 quickstart examples [1] will get you on the right path.
There is an example for EJB coding [2] you might find useful. Using current day apis.

Jeremy

[1] https://github.com/wildfly/quickstart/tree/26.1.1.Final
[2] https://github.com/wildfly/quickstart/tree/26.1.1.Final/ejb-in-war

Think what you are looking for are Global Modules

http://docs.wildfly.org/15/Developer_Guide.html#global-modules

Jeremy

You say this is a compile time problem. Share your problem.
What's the error ?
What's the code that's reporting the error ?

Jeremy

I see that with Wildfly that is no longer possible.

Hi Thomas,
As Tim mentioned the JEE api provides a UserPrincipal object. That hasn't changed in Wildfly24.

Yes in EAP6.x your code would rely on SecurityContextAssociation to access above interface.
Wildfly24 it is still possible and relies on Context Dependency Injection (CDI) to expose objects and methods you need.

Take a look at this Wildfly 24 quickstart example that uses the JEE Security api.

https://github.com/wildfly/quickstart/blob/162cf351aecaf0ef0cd4d7d03b40c53df26540da/ee-security/src/main/java/org/jboss/as/quickstarts/ee_security/SecuredServlet.java

Jeremy

How about approaching this from another angle.
Move the old Wildfly to a directory you create for archiving stuff. It lives here for posterity.
Then start with a fresh install of Wildfly 24. Bring across configuration and the applications you want to keep from the archive.
Does that work for you ?

Think I found your answer relying on JAVA_OPTS for configuration.
JAVA_OPTS=" -Dcom.arjuna.ats.arjuna.coordinator.CoordinatorEnvironmentBean.enableStatistics=true "

Looking at the documentation for Narayana (Transaction Manager) sub-system we see the configuration with Wildfly section.
https://www.narayana.io//docs/project/index.html#d0e3536

The docs recommend using the cli to configure the transaction sub-system. Have a read (yes v25 docs but the principles are the same) of the configuration instructions.
https://docs.wildfly.org/25/Admin_Guide.html#transaction-statistics
The section "observing all transaction statistics attributes" is relevant to making the configuration change you want. These changes will survive a server restart.

# connect to a running application server
./bin/jboss-cli.bat -c

# enable transaction statistics
/subsystem=transactions:write-attribute(name=statistics-enabled, value=true)
# list all statistics attributes
/subsystem=transactions:read-attribute-group(name=statistics, include-runtime=true)

Can you switch to using the cli rather than using JAVA_OPTS ?

Without more information it's difficult to diagnose what the server considered missing.
You might be tripping over an incompatibility between the blog post written for Wildfly 10. You are deploying to Wildfly 19. These things do change over time.
I suggest you instead refer to the example applications provided on Github. For the release of Wildfly being used.

examples
https://github.com/wildfly/quickstart/tree/19.1.0.Final

ssl example
https://github.com/wildfly/quickstart/tree/19.1.0.Final/helloworld-ssl

Here you have a more reliable (to succeed) example of setting up SSL. Then try re-deploying your application.

and you should download the free book Quarkus Cookbook

https://developers.redhat.com/e-books/quarkus-cookbook

I don't know if it is compatible. I suggest you try building the project with jdk17 to find out.

I think you should try using the code.quarkus.io site plus the Quarkus quickstart examples to discover oauth or auth integration.

https://code.quarkus.io/?extension-search=origin:platform%20oauth
https://github.com/quarkusio?q=examples&type=all&language=&sort=

https://github.com/Commonjava/gateway Sorry, I should let the book author Davi respond to the question.

Hi Jan,
Did you turn on the deployment scanner ?

See these instructions from a prior release

https://docs.jboss.org/author/display/WFLY10/Deployment%20Scanner%20configuration.html

You can expect the EAR file be deployed.

Jeremy

Christopher Laurenzano wrote:Ok, guys -- I'm trying to get into Linux, and have Elementary OS Odin.  I tried installing Java 17SE.  Came across some web pages, and am confused at this point.

I seemed to have downloaded and installed, if I read these instructions correctly, from the Oracle website.   But when i enter 'java -version' in the terminal it says I have version 1.11 (or java 11).  

I entered update-java-alternatives --list, expecting to see two versions of Java, and I could choose 17 and remove/delete/uninstall 11.  But version 11 was the only one that's there.

Not sure why that is, because when I removed it with the parameter jdk-17, it removed fine.  

Yet, when I enter java -version again, it still says I have version 11.  But when I try to remove that with the dpkg -r command, it says it isn't installed.  But if I enter the command 'update-java-alternatives --list' it lists the jvm and its subdirectories in the usr/bin directory.

Has anyone else encountered this problem?  I have to admit it's confusing installing programs/apps and such in Linux.  

Please let me know if you need any more information.   I've done something wrong somewhere.  

How can I remove the version I seem to still have there, and just start over with a clean installation?  Has anyone been to the oracle website and done this installation?  Seems to me to be a bit confusing/unclear/incomplete for Linux.

I've on other sites/forums as well, but I thought I'd ask here since this is specifically for Java.

Others have provided some good suggestions and relevant questions to help narrow down where you are getting stuck.

Though in your case you will still need to use alternatives to display the existing JSE installations. Until JDK17 is available in the repositories for your distribution (Elementary OS Odin) you'll only see JSE11 on offer. Until then if you want it now you'll need to install the rpm from Oracle or, download and install from AdoptOpenJDK. The two JSE are essentially the same.

altenatives --display java

If the Oracle JDK isn't in that list then you'll need to use alternatives to it manually using the install command. This is a bit fiddly. See the man pages for more help and do some searches for more examples.
alternatives --help

Alternatively, if you are looking for something that takes all the pain away take a look at a convenience tool call SDKMan. It is pretty slick. I've been using it for a couple of years now.
https://sdkman.io/

Making life easier. No more trawling download pages, extracting archives, messing with _HOME and PATH environment variables.

Best thing since sliced bread.

Sheldon Dsouza wrote:Thanks Tim for the quick reply.

Do you know if there is an Email Address / Site where we can contact JBoss Support?

Thanks,
Sheldon

There are two options.

Paid support subscription, Red Hat being the main vendor offering support

Community support

 Assuming you are happy to communicate with Wildfly Community the Wildfly About page has a Get Help section. There is a user Forum and a Zulip Chat channel.

https://www.wildfly.org/about/
https://groups.google.com/forum/#!forum/wildfly
https://wildfly.zulipchat.com/

Jignesh Patel wrote:yup, I don't want to deploy quarkus on wildfly, I would rather deploy on kubernetes container on aws, but I need to define a bridge between application deployed in wildfly and kafka application deployment in quarkus.

Ok so you need to re-think a little how Quarkus is different to Wildfly. Let's compare these two for what it's worth.
Wildfly is a general purpose JEE application server. Supporting standardised JEE apis. Two profiles are supported Full profile and Web profile. Apps packaged in all sorts (Jar, War, Rar, blah) of formats can be deployed. The deployment of many Enterprise apps in the server is possible.

Whereas Quarkus is akin to a framework. Like Dropwizard but very different end goals in mind. It's a re-evaluation from the ground up what's really necessary to provide very light weight (small footprint) applications in a container platform. Aka "Microservices". Plus it has build time Maven plugins (dark magic) that analyse your Microservice code and strips out absolutely everything which isn't going to be necessary at runtime. With the build time option to generate a native binary for very efficient memory consumption at the expense of other things. Deployment here will be a distinct container (or pod) on AWS. The native binary option makes Java a viable platform that does achieve equivalent service deployment density to other languages.

I hope you can now see Wildfly and Quarkus are not exactly achieving the same level of sophistication or capabilities.

This isn't to say you cannot deploy your current application with Wildfly. It is certainly possible. You can run more sophisticated applications but the service deployment density will be lower.

To answer your question.
To adapt/bridge an application to run as a containerised Quarkus service will probably involve a re-write. With Quarkus there is a suite of carefully selected APIs that will most likely be used in Microservice type (shape) applications. You are best spending 10 minutes noting down the feature spec apis in your application. Then ticking off each you can find available on the Quarkus https://code.quarkus.io/ website. You might find your current application is not the same "shape" as a Microservice.

Also have a look at the Microprofile forum [1] to see what's made available from the "standardised specification" community for developers. You might find an option there that lowers the necessary transition investment.

[1] https://coderanch.com/f/211/microprofile