Mise à jour de la base de données JPA Glassfish
J'ai une application déployée sur Glassfish v3.0.1 qui lit les événements à partir d'une table dans ma base de données. Une fois prêt, il le marque comme traitée. J'obtiens une erreur étrange, je ne peux pas l'expliquer lorsque vous essayez d'appeler la méthode qui effectue la mise à jour.
@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);
}
}Lorsque cela s'appelle dans mon application, j'obtiens l'exception suivante (trace Complète en bas du post):
Caused by: javax.ejb.AccessLocalException: Client not authorized for this invocation.Personne ne sait ce qui peut provoquer cette erreur que j'ai loked sur le Web, mais n'a pas trouvé quelque chose d'utile.
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 moresource d'informationauteur James
Vous devez vous connecter pour publier un commentaire.
GlassFish documentation dispose d'une entrée pour cette erreur:
Je ne sais pas si elle fait sens dans votre contexte.
Si ça ne marche pas, peut-être avoir un coup d'oeil sur le thread suivant La persistance de l'Entité: javax.ejb.AccessLocalException: Client n'est pas autorisé pour cette invocation. L'une des affiches suggéré de définir le niveau de journalisation de la SÉCURITÉ de l'Enregistreur de données d'AMENDE [de sorte que] la Glassfish Politique de sous-système enregistre un message détaillé décrivant la nature de l'échec de la vérification d'autorisation de. Cela peut vous aider. Et je ne peux pas vous dire si vous êtes confrontés au même problème, mais l'OP résolu son problème par le nettoyage de la stratégie générée fichiers:
Cette exception peut également se produire si vous essayez de copier et coller EJB ejb session avec de nouvelles méthodes, comme les fichiers de patch pour corriger des bugs, ou l'intégration de nouvelles fonctionnalités. Redémarrer le serveur ou la désactivation de la & permettant à l'entreprise d'application ne va pas aider, comme les EJB Session des haricots ou des entités doivent être reconditionnés et redéployés, de sorte que le serveur d'Application enregistre les nouvelles méthodes de contrôle et de subventions/exclut les privilèges d'accès pour les nouveaux/modifiés méthodes de l'EJB ejb session.
J'ai eu le même problème lors de l'injection d'un Apatride en SessionBean (TransactionAttribute.REQUIRES_NEW) dans un autre Apatrides SessionBean. Pour moi, en redémarrant le serveur résolu pour moi...
Voulais juste vous faire savoir 😉
J'ai eu le même problème. Je ne suis pas d'utiliser tout type de contrôle d'accès sur le service, mais sur une instance de glassfish tout a bien fonctionné, sur un autre, j'ai eu cette erreur mais seulement sur certaines méthodes. J'ai ajouté @PermitAll et redéployé le service et tout a commencé à travailler.
Sur Glassfish 3.1.2 au moins, parfois d'une précédente version d'un bean qui a changé au risque d'étouffer Glassfish lors du déploiement. L'application va s'exécuter jusqu'à ce que les bits de code qui devrait être appelé, mais ne peut pas être parce que le déjà déployé classe est toujours là. Je pense que Glassfish peut garder la trace de chacun et d'éviter que la nouvelle de code à partir de l'appel de l'ancien code, mais je n'ai pas vraiment été désireux de s'inquiéter à ce sujet que la solution est assez simple:
Arrêter le serveur, allez dans le répertoire du domaine et de supprimer tous les fichiers et sous-répertoires dans le répertoire de l'application. Puis faire de même dans le générés et osgi-répertoires de cache. Redémarrez le serveur et de reconstruction/redéployer.
J'ai eu ce même message d'Erreur, mais le mien était causé par ce:
la fonction:
quand j'ai changé la balise pour cela, il a travaillé: