Vraag PPPA Glassfish Database Update Issue


Ik heb een applicatie geïmplementeerd op Glassfish v3.0.1 die gebeurtenissen leest uit een tabel in mijn database. Eenmaal klaar markeert deze als verwerkt. Ik krijg een vreemde fout die ik niet kan uitleggen wanneer ik de methode probeer te noemen die de update doet.

@Override
@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
public void markEventAsProcessed(Long eventId) {
    try {
       AtlasEventQueueUpdateAsProcessedQuery setEventAsProcessed = new  AtlasEventQueueUpdateAsProcessedQuery(entityManager, eventId);
       int updateCount = setEventAsProcessed.execute();
       logger.debug("Mark Event [" + eventId + "] processed");
       return updateCount;
    } catch (QueryException ex) {
        logger.error("Event [" + eventId + "has not been marked as processed", ex);
    }
}

Wanneer dit wordt aangeroepen in mijn toepassing, ontvang ik de volgende uitzondering (Volledig traceren onderaan het bericht):

Caused by: javax.ejb.AccessLocalException: Client not authorized for this invocation.

Weet iemand wat deze fout zou kunnen veroorzaken, die ik op internet heb gevonden, maar niets nuttigs vond.

2010-08-27 09:44:37,380 ERROR [Ejb-Timer-Thread-1  :EventProvider       ] Unhandled exception in event processing - javax.ejb.EJBAccessException
javax.ejb.EJBAccessException
        at com.sun.ejb.containers.BaseContainer.mapLocal3xException(BaseContainer.java:2262)
        at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:2053)
        at com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1955)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:198)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:84)
        at $Proxy190.markEventAsProcessed(Unknown Source)
        at com.company.atlas.eventprocessor.provider.EventProvider.processNewEvents(EventProvider.java:170)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1056)
        at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1128)
        at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:5292)
        at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:615)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:797)
        at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:567)
        at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:157)
        at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundTimeout(SystemInterceptorProxy.java:144)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:858)
        at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:797)
        at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:367)
        at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:5264)
        at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:5252)
        at com.sun.ejb.containers.BaseContainer.callEJBTimeout(BaseContainer.java:3965)
        at com.sun.ejb.containers.EJBTimerService.deliverTimeout(EJBTimerService.java:1667)
        at com.sun.ejb.containers.EJBTimerService.access$100(EJBTimerService.java:98)
        at com.sun.ejb.containers.EJBTimerService$TaskExpiredWork.run(EJBTimerService.java:2485)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: javax.ejb.AccessLocalException: Client not authorized for this invocation.
        at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1850)
        at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:188)
        ... 34 more

12
2017-08-27 09:00


oorsprong


antwoorden:


Ik heb de map verwijderd domains/domainx/generated/policy/<appname>/   en volledig opnieuw geimplementeerd (niet alleen opnieuw opgestart) de app .. het werkt nu zoals verwacht.

De GlassFish-documentatie heeft een invoer voor deze fout:

javax.ejb.AccessLocalException: Client niet geautoriseerde fout

Beschrijving

Informatie over de rolverdeling is beschikbaar   in Sun-specifieke XML (bijvoorbeeld    sun-ejb-jar.xml) en verificatie   is oke, maar de volgende fout   bericht wordt weergegeven:

[...INFO|sun-appserver-pe8.0|javax.enterprise.system.container.ejb|...|
javax.ejb.AccessLocalException: Client not authorized for this invocation.
at com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:...
at com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(...)

Oplossing

Controleer of de EJB-module (.jar)   of webmodule (.war) is ingepakt   een applicatie (.ear) en doet dat niet   hebben rol-kaartinformatie in   toepassingsniveau, zon-specifiek,    sun-application.xml. Voor enige   toepassing (.ear), veiligheid   rol-mapping informatie moet zijn   gespecificeerd in sun-application.xml. Het   is acceptabel om beide te hebben   op moduleniveau op XML- en applicatieniveau   XML.

Ik weet niet of het zinvol is in jouw context.

Als dat niet het geval is, bekijk dan de volgende thread Persisting Entity: javax.ejb.AccessLocalException: client niet geautoriseerd voor deze aanroep. Een van de voorgestelde posters stel het loggeniveau van de SECURITY Logger in op FINE [zodat dat] het Glassfish Policy-subsysteem een ​​gedetailleerd bericht zal loggen dat de aard van de mislukte machtigingscontrole beschrijft. Dit kan helpen. En ik kan u niet vertellen of u met hetzelfde probleem wordt geconfronteerd, maar de OP heeft zijn probleem opgelost door de gegenereerde beleidsbestanden op te schonen:


29
2017-08-28 02:19



Deze uitzondering kan ook optreden als u EJB-sessiebonen met nieuwe methoden kopieert en plakt, als patchbestanden voor het oplossen van fouten of het opnemen van nieuwe functies. Het opnieuw opstarten van de server of het uitschakelen en inschakelen van de enterprise-app zal niet helpen, omdat de EJB Session-bonen of -entiteiten moeten worden herverpakt en opnieuw moeten worden geïmplementeerd, zodat de app-server de nieuwe methoden registreert en de toegangsrechten voor de nieuwe controleert / verleent / uitsluit veranderde methoden in EJB sessiebonen.


5
2017-12-01 11:15



Ik had hier hetzelfde probleem bij het injecteren van een Stateless SessionBean (TransactionAttribute.REQUIRES_NEW) in een andere Stateless SessionBean. Voor mij herstartte het herstarten van de server het voor mij ...

Ik wilde je dit laten weten ;-)


0
2017-12-21 14:09



Ik had hetzelfde probleem. Ik gebruik geen enkele vorm van toegangscontrole op de service, maar op één exemplaar van glassfish werkte alles goed, op de andere, ik kreeg deze fout maar alleen op sommige methoden. Ik heb @PermitAll toegevoegd en de service opnieuw geïmplementeerd en alles is begonnen met werken.


0
2018-05-14 09:41



Op Glassfish 3.1.2 tenminste, soms zal een eerdere iteratie van een boon die is veranderd Glassfish tijdens de inzet verstikken. De app wordt uitgevoerd totdat deze bij een willekeurig stukje code komt dat moet worden aangeroepen, maar dat kan niet omdat de eerder ingezette klasse er nog steeds is. Ik denk dat Glassfish ze allemaal bijhoudt en voorkomt dat de nieuwe code de oude code aanroept, maar ik ben niet echt zo bezorgd geweest omdat de oplossing eenvoudig genoeg is:

Stop de server, ga naar de domeindirectory en verwijder alle bestanden en submappen in de applicatiemap. Doe hetzelfde in de gegenereerde en osgi-cache-directory's. Start de server opnieuw en opnieuw samenstellen / opnieuw implementeren.


0
2017-11-21 00:13



Ik had dezelfde fout maar de mijne werd veroorzaakt door dit:

<c:set var="speciesList" value="#{timberSaleController.distinctSaleSpecies}"   />

de functie:

public List<Species> getDistinctSaleSpecies()
    {
        return ejbFacade.getDistinctSpeciesForAllSales();
    }

toen ik de set-tag veranderde, werkte het:

<c:set var="speciesList" value="#{timberSaleController.getDistinctSaleSpecies()}"   />

0
2018-05-04 22:51