access denied (java.lang.RuntimePermission accessClassInPackage

In your java.policy file add the following to the permissions for your applets codebase:

permission java.lang.RuntimePermission "accessClassInPackage.sun.jdbc.rowset";

> In your java.policy file add the following

I did that, still no go.

i've pretty much scoured the web looking for a solution and though many ppl have had this exact same problem, none of their posts had a working solution...

Did you check that you changed the correct java.policy file? If you have the JDK installed then you probably have two. Change both to be sure. You'll also need to restart your browser as I believe the policy file is only read at startup.

Can you post your java.policy entry pls.

Also what is your environment?

// Standard extensions get all permissions by default

grant codeBase "file:${java.home}/lib/ext/*" {
        permission java.security.AllPermission;
};

// default permissions granted to all domains

grant {
        // just grant to everyone for now
        permission java.lang.RuntimePermission "accessClassInPackage.sun.jdbc.rowset";

        // Allows any thread to stop itself using the java.lang.Thread.stop()
        // method that takes no argument.
        // Note that this permission is granted by default only to remain
        // backwards compatible.
        // It is strongly recommended that you either remove this permission
        // from this policy file or further restrict it to code sources
        // that you specify, because Thread.stop() is potentially unsafe.
        // See "http://java.sun.com/notes" for more information.
        permission java.lang.RuntimePermission "stopThread";

        // allows anyone to listen on un-privileged ports
        permission java.net.SocketPermission "localhost:1024-", "listen";

        // "standard" properies that can be read by anyone

        permission java.util.PropertyPermission "java.version", "read";
        permission java.util.PropertyPermission "java.vendor", "read";
        permission java.util.PropertyPermission "java.vendor.url", "read";
        permission java.util.PropertyPermission "java.class.version", "read";
        permission java.util.PropertyPermission "os.name", "read";
        permission java.util.PropertyPermission "os.version", "read";
        permission java.util.PropertyPermission "os.arch", "read";
        permission java.util.PropertyPermission "file.separator", "read";
        permission java.util.PropertyPermission "path.separator", "read";
        permission java.util.PropertyPermission "line.separator", "read";

        permission java.util.PropertyPermission "java.specification.version", "read";
        permission java.util.PropertyPermission "java.specification.vendor", "read";
        permission java.util.PropertyPermission "java.specification.name", "read";

        permission java.util.PropertyPermission "java.vm.specification.version", "read";
        permission java.util.PropertyPermission "java.vm.specification.vendor", "read";
        permission java.util.PropertyPermission "java.vm.specification.name", "read";
        permission java.util.PropertyPermission "java.vm.version", "read";
        permission java.util.PropertyPermission "java.vm.vendor", "read";
        permission java.util.PropertyPermission "java.vm.name", "read";
};


JRE:
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

OS:
Linux

btw: i don't want every client to have to change their policy file.

> btw: i don't want every client to have to change their policy file.

Then you'll have to sign your applet, and request the user grant the necessary permissions.

Did your check for the existence of other policy files?

ok, then is there a better solution to pass my data from the servlet to the applet?

I don't want to pass a new list (ie. a vector generated from ResultSet).

I was thinking of using RMI.

Another possible solution would be to include the required classes in your jar, though I'm not sure how many that would involve.

> Did your check for the existence of other policy files?

yes, i was in the wrong one :(

> Another possible solution would be to include the required classes in your jar, though I'm not sure
how many that would involve.

i tried that too, but i still get the accessClassInPath Error

> I don't want to pass a new list

Can I ask why?

b/c if i have a lot of records, i have to loop through the resultset and populate the vector.  It's an efficiency issue. (though it's not necessarily a problem now, i want this to be scalable)

actually, would i be able to populate a JTable from the resultset in the servlet and pass that to the applet?

i think that would work since JTable is serializable.

Then why not make the JDBC call directly from the applet.

Or setup your servlet to return results in chunks.

Or have your servlet 'stream' the results one row at a time.

> would i be able to populate a JTable

What is difference between populating a JTable and populating a Vector?
I wouldn't recommend using a JTable for this purpose.

> Then why not make the JDBC call directly from the applet.
Yeah, i was thinking about doing that, but i like the idea of having the backend do all the work so as to maintain MVC architecture.

> Or setup your servlet to return results in chunks.
I may end up doing that.

> What's wrong w/ RMI?

> What is difference between populating a JTable and populating a Vector?

b/c the applet will show this JTable and i won't have to run through the vector at the applet to populate the JTable

> What's wrong w/ RMI?

It seems unnecessary compication for required task.

> b/c the applet will show this JTable and i won't have to
> run through the vector at the applet to populate
> the JTable

Previously you stated you didn't want to loop thru the rs on the servlet to populate the vector. You'd have to do that to populate the table.
And you wouldn't send the JTable you'd simply send the model.

Personally it sounds like the best solution would be to try and have your servlet stream the results back as as they are read from the rs.

How big is the size(in KO) of a ResultSet ? You should build a specific string on the servlet and let the aplet to parse'it and rebuild the data. Should be not so time consuming this transfer and I expect not to have more that 20KO at maximum size.

Why construct a String and have the applet parse it?? A lot easier to just return data as an array or Vector.
bobbit31 also stated in an earlier comment that they aren't keen to load the entire result set for scaleability reasons.

array/Vector = objects colection = RMI transfer/serialized object transfer = inconsistent data over variuos connections = applet crashes = ...

"keep things simple" said someone ...

The parsing should not be a problem since you only need to add special separators between "table rows"&"table cells".

I don't get your point, whats complicated about passing an array/Vector from a servlet to an applet??
And why do u need RMI to do it, when a simple URLConnection will do the job?

Vector = java.util.Vector ?

Vector = java.util.Vector ?

ok, looking for a good data structure to use:

let's say i have 20 cols and 2000 rows... i was thinking a hashtable w/ the colname as key and a vector of col data as object.  but to populate this vector would be time consuming... unless of course i chunk it into smaller bits.  

Do you guys know of a more efficient way to do this?
I'm not too keen on the string idea b/c passing the hashtable would be just as easy and i wouldn't have to parse anything.

I'm not sure I agree with your efficiency concern. A CachedRowSet and a vector or list is in essence the same thing. When the CachedRowSet is created, it still loops through the entire resultset since it caches all the data. Arguably, a HashMap could actually propose less overhead since it's a simpler class than the CachedRowSet and contains less meta data.

thanks everyone, but this is the way i decided to go...

Thanks for the points :)

http://www.objects.com.au
Brainbench MVP for Java 1
http://www.brainbench.com