Skip to main content

AccessControlException problem in applet

14 replies [Last post]
rickjones
Offline
Joined: 2006-04-11
Points: 0

I'm migrating some web service client code from 1.x to 2.0, and this code has to run in an applet. The problem is that it throws an ExceptionInInitializerError, caused by an AccessControlException somewhere down in resolver. This happens on the first attempt to create the connection object.

The code runs fine stand-alone, so this seems to be an applet issue. The equivalent functionality written for JWSDP 1.5/1.6 never had this problem. The applet is signed, and the remote connection is under the same URL as the applet.

So 2.0 is doing something that 1.x didn't, and upsetting the security. The questions is what, and why? And more importantly, what's the solution?

Ideas welcome!

TIA
Rick Jones

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
aronolsen
Offline
Joined: 2008-10-31
Points: 0

Take a look at what the Metro .jar install-on-the-fly asumes about your JVM/JDK and what it does to it!!!!

Then think about what NetBeans asumes (I am Eclipse, but need NB for WSIT)!

I don't know what to do, but I would suggest: "Take it from the box and:"

"a) If it works then OK."
"b) If it doesn't: Tell'm!"

Regards.

rickjones
Offline
Joined: 2006-04-11
Points: 0

kohsuke - thanks. I've posted more details of the Class problem in a new thread: http://forums.java.net/jive/thread.jspa?threadID=14841&tstart=15

jemiller1
Offline
Joined: 2005-01-27
Points: 0

Was anyone ever able to get this to work? I'm running into the same problem. I'm using NetBeans 6.5 and JDK 1.6.0_10 with the version of JAX-WS that is bundled with NetBeans 6.5 (2.1). The applet works fine if I run it through appletviewer.

aronolsen
Offline
Joined: 2008-10-31
Points: 0

As we are at it: Which parts of JAX-WS are included in the "upcoming JRE"/"the already there" JRE. Talking about 1.6.10 and 1.6.11.
Are we really in for WEB-clients in Applets?
And, how is it with JNLP, in that context?

Besides from that, I believe I had this exact problem using JRE 1.6.7 NOT executing an Applet.

Thanks,

"May force be with you,"
Aron.

rickjones
Offline
Joined: 2006-04-11
Points: 0

<< Another way around the problem is to grant the required permission. Save this as .java.policy in your home directory (or add it to jre/lib/security/java.policy) >>

Interesting thought - it's not really feasible in practice though. It would require all client users to make this mod. on their machines, and most of them wouldn't have a clue what it meant!

They probably don't even know they're using Java, they just think it's a Web page - which in fact is largely the point.

kohsuke
Offline
Joined: 2003-06-09
Points: 0

I pinged a JAX-WS guy. Hopefully he can chime in on that one.

kohlert
Offline
Joined: 2003-06-16
Points: 0

All of the jar files used to be signed in JWSDP 1.6. I am not sure why they are not doing that anymore. Perhaps you should post the question to users@jwsdp.dev.java.net.

rickjones
Offline
Joined: 2006-04-11
Points: 0

kohlert - that explains much! It hadn't ocurred to me to check the 1.6 jars. As you say, odd that they should have decided not to sign the 2.0 ones. If they're going to be signed, it should really be Sun's cert., after all.

kohsuke
Offline
Joined: 2003-06-09
Points: 0

Can you post the stack trace?

rickjones
Offline
Joined: 2006-04-11
Points: 0

Trace from the console below. Thanks.

Rick

Exception in thread "AWT-EventQueue-2" java.lang.ExceptionInInitializerError
at com.sun.xml.ws.util.xml.XmlUtil.createDefaultCatalogResolver(XmlUtil.java:206)
at com.sun.xml.ws.client.WSServiceDelegate.(WSServiceDelegate.java:117)
at com.sun.xml.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:50)
at javax.xml.ws.Service.(Service.java:58)
at com.sage.training.svc.Service1.(Service1.java:44)
at com.sage.training.FCE1.onFormButton(FCE1.java:67)
at JFCEProxyStub.onFormButton(Unknown Source)
at JCFTextField.actionPerformed(Unknown Source)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
Caused by: java.security.AccessControlException: access denied (java.util.PropertyPermission xml.catalog.ignoreMissing read)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPropertyAccess(Unknown Source)
at java.lang.System.getProperty(Unknown Source)
at com.sun.org.apache.xml.internal.resolver.CatalogManager.(CatalogManager.java:140)
at com.sun.org.apache.xml.internal.resolver.CatalogManager.(CatalogManager.java:134)
... 31 more

rickjones
Offline
Joined: 2006-04-11
Points: 0

A followup:

This exception can be prevented by manually signing all the JWSDP library jars that are loaded by the applet (they are loaded using "cache-archive-ex"). I'm just curious as to why this is required with JWSDP 2, whereas 1.x works fine without doing this.

However, I still get a problem. The connection is established OK, but when attempting a method call it complains that it cannot find the proxy class corresponding to the remote method name, so the call fails. The class is present, and it doesn't complain when running stand-alone.

Have I missed something, or is it a bug?

Thanks
Rick

tackline
Offline
Joined: 2003-06-19
Points: 0

Another way around the problem is to grant the required permission. Save this as .java.policy in your home directory (or add it to jre/lib/security/java.policy)

grant {
permission java.util.PropertyPermission "xml.catalog.*", "read";
};

Of course there might be other problems.

kohsuke
Offline
Joined: 2003-06-09
Points: 0

I'll mention this to the developer of the resolver code.

rickjones
Offline
Joined: 2006-04-11
Points: 0

Thanks for the replies.

Any thoughts on the second problem I mentioned:

"The connection is established OK, but when attempting a method call it complains that it cannot find the proxy class corresponding to the remote method name, so the call fails. The class is present, and it doesn't complain when running stand-alone."

Signing does NOT overcome this one - it seems to be a complete showstopper to calling web services from an applet.

TIA Rick