Hi, Just to start making people aware of this issue, J2EE 1.3 introduces a set of security permissions that require enforcement by J2EE vendors. I have noticed that we have code within Axis that get's affected by this new requirement. Specifically, there are 2 places that I have found so far:
1) org.apache.axis.client.Call 2) org.apache.axis.MessageContext Call.java The failure on Call.java is due to the System.setProperty() call for TRANSPORT_PROPERTY. This is being done in Axis to allow custom URL handlers. Since this is run in client applications, each application would have to enable writing of this property (or the entire app-server's VM would have to change)... but this would violate the J2EE spec. The JDK does provide a mechanism for not using the java.protocol.handler.pkgs System property, by defining your own URLStreamHandlerFactory. However, this too requires authority to set it: (permission java.net.NetPermission "specifyStreamHandler";). It's probably a bad thing to allow system properties to be set by our client code anyway... Therefore, I'm leaning towards suggesting some other mechanism for runtime initialization and removing it out of the mainstream path for all client usages. MessageContext.java The failure on MessageContext is in a static initializer (on first load of the class) which deletes/creates the attachments directory. The JDK only allows read/write of FilePermission, not create/delete. It's probably a bad thing to create this dynamically (and should be something done by the appserver or even SimpleAxisServer vs. some static initializer in MessageContext. I don't have fixes/patches for this yet... but thought I would at least bring this to the attention of folks to (a) avoid further issues w/Java2 Security and (b) allow folks to fix this for me... :-). Regards...Greg
