Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-9164

After changing server profiles application with authentication stops to run

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Critical
    • 7.1.0.DR17
    • 7.1.0.DR12
    • CDI / Weld
    • None
    • Hide
      • add application user 
        jboss-eap-7.1/bin/add-user.sh -a -u user1 -p password1! -r ApplicationRealm -g Admin
      • deploy attached application
      • start server with default profile 
        jboss-eap-7.1/bin/standalone.sh
      • open http://localhost:8080/secured-webapp/user/ in a browser window
        • login as user1 / password1!
      • stop the server
      • start server with full profile 
        jboss-eap-7.1/bin/standalone.sh -c standalone-full.xml
      • reload the brower window

      => Exception in both server.log and browser window

      Reloading the page doesn't help. Closing browser and starting again helps.

      Show
      add application user jboss-eap-7.1/bin/add-user.sh -a -u user1 -p password1! -r ApplicationRealm -g Admin deploy attached application start server with default profile jboss-eap-7.1/bin/standalone.sh open http://localhost:8080/secured-webapp/user/ in a browser window login as user1 / password1! stop the server start server with full profile jboss-eap-7.1/bin/standalone.sh -c standalone-full.xml reload the brower window => Exception in both server.log and browser window Reloading the page doesn't help. Closing browser and starting again helps.

    Description

      My test application stops to run, when I start server with another profile (`standalone.xml -> standalone-full.xml` or vice versa). It throws WELD exception during the first request:

      21:11:34,134 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /secured-webapp/user/index.jsp: org.jboss.weld.exceptions.IllegalStateException: WELD-000227: Bean identifier index inconsistency detected - the distributed container probably does not work with identical applications
Expected hash: -1182150022
Current index: BeanIdentifierIndex [hash=-1731766867, indexed=9] 
     0: WELD%AbstractBuiltInBean%/content/secured-webapp.war%HttpSession
     1: WELD%AbstractBuiltInBean%com.sun.jsf-impl.additionalClasses%HttpSession
     2: WELD%AbstractBuiltInBean%org.hibernate.validator.cdi.additionalClasses%HttpSession
     3: WELD%AbstractBuiltInBean%org.jberet.jberet-core.additionalClasses%HttpSession
     4: WELD%AbstractBuiltInBean%org.jboss.as.jsf.additionalClasses%HttpSession
     5: WELD%AbstractBuiltInBean%org.jboss.jts.additionalClasses%HttpSession
     6: WELD%AbstractBuiltInBean%org.jboss.resteasy.resteasy-cdi.additionalClasses%HttpSession
     7: WELD%AbstractBuiltInBean%org.jboss.weld.core.additionalClasses%HttpSession
     8: WELD%AbstractBuiltInBean%org.wildfly.extension.messaging-activemq.additionalClasses%HttpSession

	at org.jboss.weld.context.http.HttpSessionContextImpl.checkBeanIdentifierIndexConsistency(HttpSessionContextImpl.java:101)
	at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:47)
	at org.jboss.weld.context.http.HttpSessionContextImpl.associate(HttpSessionContextImpl.java:23)
	at org.jboss.weld.servlet.HttpContextLifecycle.requestInitialized(HttpContextLifecycle.java:237)
	at org.jboss.weld.servlet.WeldInitialListener.requestInitialized(WeldInitialListener.java:152)
	at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:246)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:291)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
	at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1700)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1700)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1700)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1700)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:197)
	at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
	at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94)
	at org.wildfly.extension.undertow.Host$OptionsHandler.handleRequest(Host.java:329)
	at io.undertow.server.handlers.HttpContinueReadHandler.handleRequest(HttpContinueReadHandler.java:65)
	at io.undertow.server.handlers.SetHeaderHandler.handleRequest(SetHeaderHandler.java:90)
	at io.undertow.server.handlers.SetHeaderHandler.handleRequest(SetHeaderHandler.java:90)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)

      The same exception is displayed on the result web-page.

      Attachments

        Issue Links

          is blocked by

          Component Upgrade - A task tracking an update to a bundled component or revision of component upstream of the project. JBEAP-10189 Upgrade Weld to 2.4.3.Final

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Verified
          relates to

          Feature Request - Feature requests from customers and/or users WELD-2343 Do not include built-in session and conversation scoped beans in the bean identifier index

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved

          Activity

            People

              mkouba@redhat.com Martin Kouba
              josef.cacek@gmail.com Josef Cacek (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: