Win a copy of Head First Android this week in the Android forum!

Marcos AntonioPS

Greenhorn
+ Follow
since Mar 09, 2009
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Marcos AntonioPS

Jj Roberts wrote:On your question, I don't know if you can. Wildfly's release notes mention this especially

Wildfly 21 release notes wrote:Please note that WildFly runs on Java 11 and later in classpath mode.



Thank you for your answer.

Yes, I read this same note you cited yesterday in the release notes.

But I would like to know if there's some way to have some kind of workaround this fact and make Wildfly runs an application on the modulepath.
9 months ago

Jj Roberts wrote:Hi there! A note: we prefer it if you are Forthright About Cross Posting <-- That's a link. I see you posted this earlier on Stack Overflow



Done. I updated my post. Thank you.
9 months ago
I'm using:

  • Wildfly 21
  • Java 11

  • I've just went through the pain of modularizing (with Java 9 modules) an Jakarta EE EAR application of mine that runs on Wildfly 21. This application has a war jar, ejb jars, utility jars (all have a module-info.java now) and other third party libraries. The whole application compiles well, without errors.

    But I noticed that when I run it in Wildfly, althought it runs without problems as before when it wasn't modular, it seems that the application server is not considering that it is now a modular application and is not using the module path to run the application, but the class path. So, at runtime, the modular nature of the application is being ignored.

    Is there a way to instruct the application server to run the application as a modular one, using the modulepath instead of the classpath?

    It's a pity that we have to be locked by application servers like Wildfly blocking us from using such an important Java feature (modules) at runtime in our applications.

    Cross-posted: https://stackoverflow.com/questions/66178238/instruct-wildfly-to-run-an-application-as-a-modular-application-java-9-modules
    9 months ago
    By the way, I have just cloned this simple application just to make sure I wasn't doing anything wrong

    https://github.com/rieckpil/blog-tutorials/tree/master/jsf-simple-login-with-java-ee-security-api

    that is the same application of this post

    https://rieckpil.de/howto-simple-form-based-authentication-for-jsf-2-3-with-java-ee-8-security-api/

    and it shows the same behaviour of my application. In this method of the class LoginBacking:



    the continueAuthentication() method returns AuthenticationStatus.SEND_CONTINUE, and not AuthenticationStatus.SUCCESS.

    This is the continueAuthentication() method:



    It enforces my feeling that there's a bug in the Wildfly implementation of the Jakarta EE specification. The problem is not only with my application.

    You can also clone this application and test it for yourself. I'm running it in Wildfly 21.

    Tim Holloway wrote:
    The bigger problem is that your processing logic is WAY over-complicated



    With all humility, my processing logic is REALLY NOT complicated. It's resumed to 2 methods in the Login class (only 1 if you inline the executeUserAuthentication() in the authenticateUser() method) and the class UserAuthenticator.

    Also, lots of people use the same code that I'm using. It's even the recommended way to execute authentication nowdays in Jakarta EE, not low level things. After all, what's the use of abstraction if I have to use low level code? I'm not using any proprietary code. I'm using only code from the Jakarta EE APIs, which, as far as I know, is portable.

    https://github.com/Apress/definitive-guide-to-jsf-javaee8 (Chapter 13: Security. First time I saw the code I'm using. It's in this book)
    https://rieckpil.de/howto-simple-form-based-authentication-for-jsf-2-3-with-java-ee-8-security-api/
    https://github.com/Pilpin/mwe-jakartasecurity
    Regarding my login form, Tim, I think it's really a stand-alone one.

    Here's the whole story:

    layout.xhtml:



    login.xhtml:



    errors.xhtml (tag):



    script.xhtml (tag):



    stylesheet.xhtml (tag):



    Login.java (again):



    That's it, there's nothing less, nothing more.
    Hello, Tim.

    Thank you for your answer and advices.

    I can assure you that after the executeUserAuthentication() method, the user is really authenticated.

    That's the code of start.xhtml (the welcome page):



    And that's the code of Start.java (the backing bean):



    I already checked and the variable user is not null, which means a successful authentication. But the AuthenticationStatus.SEND_CONTINUE problem remains.

    I have this little application as a zip file, tried to upload it here for you to test it, but I'm not allowed to upload zip files.
    I decided to give another try to the Custom Form authentication mechanism and made some progress.

    Here are the relevant parts of the relevant files:

    web.xml:


    CustomFormAuthenticationConfig.java:


    UserAuthenticator.java:


    login.xhtml:


    and finally

    Login.java:


    So, as the comments on the authenticateUser() method shows, the problem is that after a successful login (username and password correct), executeUserAuthentication() returns AuthenticationStatus.SEND_CONTINUE, and not AuthenticationStatus.SUCCESS. As a result, the code in the AuthenticationStatus.SUCCESS branch is not executed.

    Hope to get your feedback about this problem as I'm almost sure it's a bug in Wildfly. If not, I'd like to know what I'm doing wrong.

    Thank you in advance.
    I changed from @CustomFormAuthenticationMechanismDefinition to @FormAuthenticationMechanismDefinition and the application worked, the start.xhtml page was finally displayed. Of course, I also had to change the login.xhtml page to use j_security_check. Even thought the application is working now, I'm not on control of the authentication mechanism anymore. But that's ok to me.

    Stephan van Hulst wrote:Welcome to CodeRanch Marcos!

    Can you show us the page that you're trying to redirect to after login?



    Of course. This is the page:

    start.xhtml (it is just a test page)


    Cross-posted: https://stackoverflow.com/questions/62354490/custom-form-authentication-in-jakarta-ee-8-cant-leave-login-page-after-authent

    - Java 11
    - Jakarta EE 8
    - Wildfly 20

    I decided to give a try to the new authentication mechanism called "Custom FORM" authentication from Java EE Security that I saw in BalusC's book The Definitive Guide To JSF in Java EE 8.

    I created a simple application to test it and it's not working. The problem is that after a successful authentication, I'm not redirected to the welcome page, I keep in the login page. It's as if the application didn't recognize that I'm authenticated.

    These are the relevant parts of the relevant files:

    web.xml



    UserAuthenticator.java (performs a simple authentication)



    PagLogin (the CDI bean)



    login.xhtml (the JSF login page)



    But when I click on the Enter button I saw that I really get an AuthenticationStatus.SUCCESS, but I'm not redirected to the start.xhtml page, even if I try to change it in the browser address bar manually. It keeps me redirecting to the login page.

    After if I put this code:



    The variable authenticated is true.

    Maybe there's just a little thing missing, but I don't know what it is.

    Does anyone know what's going on here?

    UPDATE:

    I noticed that I also get this warn in the application server log after login:



    I don't know if this has something to do with the problem.