Puzzle - 'client not authorised for this invocation'

[Tony]

OK, help.

NB6.9.1, Glassfish 3.0, Windows environment, EclipseLink (JPA 2.0) using Java Transaction APIs persistence.

I have an EAR which includes both a WAR and a EAR.

The EAR contains (among others) two ejb’s, called userBean and companyBean, both annotated @LocalBean, @Stateful, @SessionScoped. Both have identical import statements, and both make use of the same injected persistence context. (The database is a remote MySQL database, accessed via JNDI through a connection pool. There are NO problems apart from the one below. So far, anyway...!)

The war contains a source file which has a method to delete an entity after being triggered by a call from a displayed web page

The web page is a standard JSF page (I’m using IceFaces) with an included xhtml <f:view> which handles all the display/actions for Companies, including creating new companies, editing an existing company or deleting an existing company. Both the editing (I reuse the same component for both editing and creating companies) and deleting are handled from dialog boxes that pop up over the page. The problem lays in deleting an existing company. The page has a displayed list of existing companies with ...

A ‘Delete’ button which pops up a dialog that asks the user to confirm the deletion, and the ‘Confirm’ button is
A commandButton with the action doConfirmDeleteCompany()
And doConfirmDeleteCompany() hides the dialog box and then calls an ejb method which actually does the deletion from the persistence context.

There are no problems with calling the action method itself .. in both cases below, the method is reached without any problems.

EJB userBean was NOT originally intended to be used for this (it handles user entities, as you’d expect from the name!), but ...

Trying to sort this problem out, I have put the same method in BOTH ebj’s ...

public void delete(Company company) {
Company c=em.find(Company.class, company.getId());//id is the primary key for the object
if(c!=null) em.remove(c);
em.flush();
}

(Depending on the circumstances, the Company entity may be detached, so this is the most efficient way I’ve found to make sure the call will succeed, whatever.)

If I call the delete method in the companyBean ejb, it always fails with “javax.ejb.AccessLocalException: Client not authorized for this invocation”.

If I call the identical method in userBean, it succeeds, every time.

NB the call fails when using companyBean ejb even before attempting the delete .. It won’t even debug through to the delete method - just attempting to access the companyBean.delete(Company c) method produces an exception. I’ve even tried the @PermitAll annotation on the companyBean.delete(Company c) method, even though I’m not using any security context.

It doesn’t matter whether I trigger a delete first, or after I’ve already used the companyBean for other calls, such as creating or editing a Company entity. The same WAR source file includes methods that allow me to create or edit Company objects, calling methods in the companyBean ejb .. and those methods succeed without any problem (I originally thought it must be some sort of JTA security exception, but if I can write to the persistence context I should be able to delete, right? – and besides, any security problem would affect both EJB’s, right?)

Googling the error message produces lots of results for environments where there is a security manager in place, but I’m not using one in the test environment....

What am I missing?

I’m sure I’m missing something obvious, but my brain just won’t see the solution .... as far as I can tell, there is no substantive difference between the two EJB’s that should affect this call. (The remaining methods in both EJB’s are basic data queries for the relevant entities. Ie, to retrieve data or merge/persist data .. all these work perfectly.)

Its not urgent, I can work around it by calling the userBean method, but I’d prefer to keep all the code in the relevant EBJ.. its annoying me a lot that I can’t see the reason behind the failures!


Tony Dietrich