JCE Policy checking at runtime

Question

I would like to check what the JCE policy allows at runtime. The basic idea here is to check what is allowed, and let the user know if there is a problem before getting into things farther. It appears that javax.crypto.CryptoPermission should be an object (I can find source for it floating around) but its not accessible at the runtime for java 1.5/1.6 . So how do I check what permissions are allowed?

Answer 1

Actually that was just for testing purposes. On my remotely running JBoss AS under linux, I'm using some already implemented jndi technique *(DataSource)ctx.lookup* to connect to the db, there are some db specific (and in general other) configurations already done on the JBoss AS, where as on my locally running tomcat i have just kept the db settign very simple (basic jdbd/odbc connectivity)
  //JBOSS
        try
          ctx = new InitialContext();
        catch (NamingException e)
          System.err.println("Context Lookup Failed");
        ds = null;
        try
          ds = (DataSource)ctx.lookup("java:/IntegraDS");
        catch (Exception e)
          e.printStackTrace();
          System.err.println("Context Lookup Failed");
        conn = ds.getConnection();
        //TOMCAT
          String userName = "admin";
          String password = "xxx";
          String url = "jdbc:mysql://hh-linux1:3306/IntegraDB";
          Class.forName ("com.mysql.jdbc.Driver").newInstance ();
          conn = DriverManager.getConnection (url, userName, password);
          As i'm doing development locally so each time i had to comment the latter section before i deploy the application on jboss. hence i asked to put some check for the AS.
With the latter part of the code, Jboss DB connectivity does not work, i hope u still remember the previous thread. That problem is still unclear to me, I tried to even give full rights to that user but still it didn't work. And with the JNDi settings used by some other project for the JBoss/DB connectivity now i'm accessing the db.
I know it's not a good idea to have such kidn fo workarounds, but will look into that problem later when i have some time.
thanks.