Glassfish / Payara javax.ejb.AccessLocalException: Client not authorized for this invocation in server.log

Question

I was trying figure out the cause of another exception for my dynamic web app here - https://github.com/double-whammy/affablebean I made a small change and I got a new exception - javax.ejb.AccessLocalException: Client not authorized for this invocation

An online answer says that I do the following - http://ask.ozar.net/11/javax-accesslocalexception-client-authorized-invocation

Try deleting the generated policy file(s). You should be able to locate them under C:\glassfish-3\glassfish\domains\domain1\generated\policy. substitute your domain name with domain1

Another says more - http://glassfish.10926.n7.nabble.com/Persisting-Entity-javax-ejb-AccessLocalException-Client-not-authorized-for-this-invocation-td11197.html

you can find the policy file under domains/domainx/generated/policy///{granted.policy,excluded.poliy} positive grants are in granted.policy, negative grants are in excluded.policy (if any). (In domaninx, x =1,2,3 etc...)

look in granted.policy for an "unqualified grant of an EJBMethodPermission, with name = the EJbName of your session bean; which I think may be JpaPersonDao. and with a method spec that applies to the save method.

---

I tried the second one and I see many folders under my glassfish folder: C:\glassfish4\glassfish\domains\domain1\generated\policy

C:.
├───AffableBean
│   ├───AffableBean
│   │       granted.policy
│   │
│   └───AffableBean_internal
│           granted.policy
│
├───__admingui
│   └───__admingui
│           excluded.policy
│           granted.policy
│
└───__default-web-module
└───__default-web-module
        granted.policy

As you can see, there are so many granted.policy files. Which one should I fix ? Is it the one under first folder ?

Answer 1

I think the root problem is because of cache of glassfish server because you make some modification in the existing EJB class.

To solve this problem you just need to clear folder/directory "generated" in domain folder, and restart your glassfish server to refresh.

Answer 2

I resolved this by redeploying the application. In NetBeans, right-click the project and select Clean and Build. Run your application and voila!

Answer 3

I have also seen the same error after:

1. making security changes to the http-listener-2 of the server config: namely, disabling the older TLS protocols and some older Cipher suites, and then
2. restarting glassfish.

I'm running Payara 4.1.2.174. I likewise found a way to fix the problem was to:

1. stop the server
2. delete the contents of the domains/DOMAIN_NAME/generated folder, then
3. start the server again

Some documentation for glassfish 3.1.2.2 still seems relevant: according to the Glassfish Server High Availability Administration Guide, section Default Synchronization for files and directories, the folders application and generated follow these rules:

application

By default, only a change to an application's top-level directory within the application directory causes the DAS to synchronize that application's directory. When the DAS resynchronizes the applications directory, all the application's files and all generated content that is related to the application are copied to the instance.

If a file below a top-level subdirectory is changed without a change to a file in the top-level subdirectory, full synchronization is required. In normal operation, files below the top-level subdirectories of these directories are not changed and such files should not be changed by users. If an application is deployed and undeployed, full synchronization is not necessary to update the instance with the change.

generated

This directory contains generated files for Java EE applications and modules, for example, EJB stubs, compiled JSP classes, and security policy files. Do not modify the contents of this directory.

This directory is resynchronized when the applications directory is resynchronized. Therefore, only directories for applications that are deployed to the instance are resynchronized.

By which I understand that the generated directory will only be re-generated if the application directory is.

Answer 4

I met same issue. And fixed by deleting folder domains/domainx/generated/policy/{appName}/ and restart.

Answer 5

To redeploy the application or to restart the server/domain is working but might be the steamroller approach which causes an outage of all deployed applications.

To avoid an outage of the whole server/domain you can simply reload the affected application.

You can recognize the affected application by the warning message in the server.log which shows the concrete EJB and inaccessible method.

[#|2009-12-18T20:03:38.788+0100|WARNING|glassfishv3.0|javax.enterprise.system.container.ejb.com.sun.ejb.containers|_ThreadID=25;_ThreadName=http-thread-pool-8080-(2);|A system exception occurred during an invocation on EJB ExampleEJB method public void com.example.ExampleEJB.method(java.lang.String) javax.ejb.AccessLocalException: Client not authorized for this invocation.

It’s possible to reload an application the admin console (default accessible through <server-ip>:4848) or via the asadmin command by

asadmin disable <application-name>
asadmin enable <application-name>

If the reload alone doesn’t work you have to delete the granted.policy file of the affected application under <domain-root-dir>/<domain-name>/generated/policy/<application-name> first an then reload the application.

Please note, sometimes this is not an error. In case you have setup EJB security and your client has insufficient rights respective an insufficient role to access the EJB method this warning message could be raised as well. If this is the case then you need to ensure that your client has the appropriate role assigned to execute the method.

Answer 6

llario Junior solution worked for me but I have also deleted all files in the glassfish applications directory. The path is glassfish\domains{domainname}\applications