Bean identifier index inconsistency after Hot re-deployment from NetBeans

ratcashdev commented 9 years ago

Editing a CDI bean in netBeans and hitting save redeploys the application in GF. After visiting a JAX-RS resoruce using the CDI bean we get the error below:

<pre>org.jboss.weld.exceptions.IllegalStateException: WELD-000227: Bean identifier index inconsistency detected - the distributed container probably does not work with identical applications
Expected hash: 813144575
Current index: BeanIdentifierIndex [hash=2099704167, indexed=12]:
   0: WELD&#37;AbstractSyntheticBean&#37;JSR196OAuthLogin-1.0-SNAPSHOT&#37;HttpSession
   1: WELD&#37;AbstractSyntheticBean&#37;com.ibm.jbatch.container.cdi.BatchCDIInjectionExtension&#37;HttpSession
   2: WELD&#37;AbstractSyntheticBean&#37;com.sun.faces.flow.FlowCDIExtension&#37;HttpSession
   3: WELD&#37;AbstractSyntheticBean&#37;fish.payara.cdi.jsr107.PayaraHazelcastCDIExtension&#37;HttpSession
   4: WELD&#37;AbstractSyntheticBean&#37;org.glassfish.cdi.transaction.TransactionalExtension&#37;HttpSession

ratcashdev commented 9 years ago

Likely cause of the error is the following code:

BeanManager beanManager = getBeanManager();
        Bean<MyBean> bean = (Bean<MyBean>) beanManager.resolve(beanManager.getBeans(MyBean.class));
        CreationalContext ctx = beanManager.createCreationalContext(bean);
        MyBean mBean= (MyBean) beanManager.getReference(bean, MyBean.class, ctx);

This snippet is used inside a ServerAuthModule. I am trying to release the bean using ctx.release(); as well as bean.destroy(mBean,ctx); but it does not help. If I stop trying to use CDI in the ServerAuthModule alltogether, then WELD is not complaining after hot-redeploy. However, I need to get this working.

smillidge commented 9 years ago

How are you registering/deregistering the JASPIC SAM in your code?

ratcashdev commented 9 years ago

The JASPIC code/jar is copied to the glassfish/lib folder and registered as a MessageSecurity through the admin console. Instructions taken from here: https://www.ibm.com/developerworks/java/library/j-authenticroast/ (see section container configuration).

The actual JASPIC code that is deployed deployed is here: https://github.com/ratcashdev/authenticroast You'll have to compile it yourself. Make sure to copy both the API and the IMPL jars. The app through which I test: https://github.com/ratcashdev/JSR196OAuthLogin (has a dependency on the API)

Try to change the SampleOAuth.java class while it's deployed 2-3 times, and do GET /api/test/secure/oauth with the header: Authorization: BEARER mytoken

BTW: Is there a more straightforward way to register the JASPIC code without messing inside the admin console?

smillidge commented 9 years ago

Take a look here for an example of how to register a SAM programmatically

https://github.com/javaee-samples/javaee7-samples/blob/master/jaspic/custom-principal/src/main/java/org/javaee7/jaspic/customprincipal/sam/SamAutoRegistrationListener.java

ratcashdev commented 9 years ago

Tried with the code from the sample (JaspicUtils). Thank you for pointing me to this solution. Simplifies it a lot. However, it did not help with the exception I was getting in the OP.

I have even tried to register a bean (as a JASPIC ServerAuthModule) that was injected by CDI into my @WebListener but after some edit of SampleOAuth.java and redeploy I got the same result: Bean identifier index inconsistency

smillidge commented 9 years ago

Can you try removing the registration of the SAM module on undeploy?

ratcashdev commented 9 years ago

Unfortunately, even after a successful deregistration of the SAM module and redeploy the exception remains. BTW: all sample codes with programmatic registration completely ignore the request policy (which in this case is 'null'). Is it really so, that this is completely useless data (even if I found a way to set it)?

Edit: I think I got closer: Severe: The web application [/JSR196OAuthLogin] created a ThreadLocal with key of type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@298e8b71]) and a value of type [name.aikesommer.authenticator.DefaultPrincipalStore] (value [name.aikesommer.authenticator.DefaultPrincipalStore@2dffca54]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.

Edit2: eliminated all the ThreadLocals in the old code. The exception still remains.

ratcashdev commented 9 years ago

Tried replaced the weld-osgi-bundle jar with a newer version (2.2.10-2.2.12 Final), but it did not help.

ratcashdev commented 9 years ago

Hi Steve, is there anything else I can do to help replicate/solve this issue?

smillidge commented 9 years ago

We just need to try and replicate the issue. We haven't had a chance to replicate with your test application yet. I'll let you know.

smillidge commented 9 years ago

Hi I've tried to reproduce this but can't can you provide me step by step instructions? I have compiled the AuthenticRoast jars and copied them into the GlassFish lib directory. I have compiled your war and opened it in NetBeans I have ran your war from NetBeans so it fires up Payara and deploys the application. I have then used curl curl -G -H "Authorization: BEARER mytoken" http://127.0.0.1:8080/JSR196OAuthLogin/api/test/secure/oauth

To access the application and I get a 401 UnAuthorized error and the server log is; Info: Retrieving main CDI bean. Info: Retrieved: com.ratcash.multilogin.authenticators.SampleOAuth@f4dfa38 Severe: No valid EE environment for injection of name.aikesommer.authenticator.DefaultPrincipalStore

I have then edited SampleOAuth and the application redeploys with server log

payara / Payara

Bean identifier index inconsistency after Hot re-deployment from NetBeans #300