JPA Glassfish Database Update Issue

后端 未结 6 1092
半阙折子戏
半阙折子戏 2020-12-28 20:29

I have an application deployed on Glassfish v3.0.1 which reads events from a table in my database. Once ready it marks them as processed. I am getting a strange error I can\

相关标签:
6条回答
  • 2020-12-28 20:49

    On Glassfish 3.1.2 at least, sometimes a previous iteration of a bean that has changed will choke Glassfish at deployment. The app will run until it gets to whatever bit of code that should be called but can't be because the previously deployed class is still there. I think Glassfish might keep track of each and prevent the new code from calling the old code, but I haven't really been that keen to worry about it as the solution is simple enough:

    Stop the server, go to the domain directory and delete all the files and sub-directories in the application directory. Then do the same in the generated and osgi-cache directories. Restart the server and rebuild/redeploy.

    0 讨论(0)
  • 2020-12-28 20:50

    I had the same problem here when injecting a Stateless SessionBean (TransactionAttribute.REQUIRES_NEW) into an other Stateless SessionBean. For me restarting the server solved it for me...

    Just wanted to let you know ;-)

    0 讨论(0)
  • 2020-12-28 20:55

    I had the same issue. I'm not using any kind of access control on the service but on one instance of glassfish everything worked fine, on another, I got this error but only on some methods. I added @PermitAll and redeployed the service and everything started working.

    0 讨论(0)
  • 2020-12-28 21:03

    This exception can also occur, if you try to copy and paste EJB session beans with new methods, as patch files for fixing bugs or incorporating new features. Restarting the server or disabling & enabling the enterprise app will not help, as the EJB Session beans or entities have to be repackaged and redeployed, so that the App server registers the new methods and checks and grants/excludes the access privileges to the new/altered methods in EJB session beans.

    0 讨论(0)
  • 2020-12-28 21:05

    I had this same Error but mine was caused from this:

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

    the function:

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

    when i changed the set tag to this it worked:

    <c:set var="speciesList" value="#{timberSaleController.getDistinctSaleSpecies()}"   />
    
    0 讨论(0)
  • 2020-12-28 21:15

    I've deleted the directory domains/domainx/generated/policy/<appname>/ and completly redeployed (not just restarted) the app.. its working now as expected.

    The GlassFish documentation has an entry for this error:

    javax.ejb.AccessLocalException: Client Not Authorized Error

    Description

    Role-mapping information is available in Sun-specific XML (for example, sun-ejb-jar.xml), and authentication is okay, but the following error message is displayed:

    [...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(...)
    

    Solution

    Check whether the EJB module (.jar) or web module (.war) is packaged in an application (.ear) and does not have role-mapping information in application level, Sun-specific, sun-application.xml. For any application (.ear), security role-mapping information must be specified in sun-application.xml. It is acceptable to have both module-level XML and application-level XML.

    I don't know if it makes sense in your context.

    If it doesn't, maybe have a look at the following thread Persisting Entity: javax.ejb.AccessLocalException: Client not authorized for this invocation. One of the poster suggested to set the logging level of the SECURITY Logger to FINE [so that] the Glassfish Policy subsystem will log a detailed message describing the nature of the failed permission check. This might help. And I can't tell you if you're facing the same problem but the OP solved his issue by cleaning the generated policy files:

    0 讨论(0)
提交回复
热议问题