[icedtea-web] Why use a separate basedir for plugin?
omajid at redhat.com
Tue Oct 26 15:31:35 PDT 2010
On 10/26/2010 06:18 PM, Deepak Bhole wrote:
> * Omair Majid<omajid at redhat.com> [2010-10-26 11:03]:
>> I noticed that the plugin uses a different basedir (see
>> JNLPRuntime.setBaseDir) from javaws. Is there a reason why?
>> Since committing the deployment configuration patch, I have been
>> working on integrating it into icedtea-web (I believe that ~/.netxrc
>> is deprecated as of now). The deployment settings however, do not
>> distinguish between plugin and javaws - whether in terms of the
>> cache they use or which certificates are considered trusted. Hence I
>> would like to make them both use the same certificates and cache
>> (and possibly other things). Are there any reasons against doing
> Well, for one, they are 2 different things. We use the netx component
> for embedding, but the plugin is still separate in terms of
Right, but there is no reason they should not use the same
proxy/cache/certificates, is there? Oracle JDK goes out of its ways to
make them appear behave the same (including reading/parsing the mozilla
configuration containing proxy settings in Java Web Start to get the
same set of proxies the plugin would - I have not personally confirmed
this, but the documentation says so).
> How about putting everything in ~/.icedtea?
Sure, makes sense to me. My only question was about issues in having the
plugin and netx share files.
> Speaking of deployement configuration, perhaps we should use
> .java/deployement for that? If a user has previous deployment settings
> from the Oracle JDK, they shouldn't have to re-do it just for
That's the first thing I thought of, but I see a few potential issues
with this. For one, the user can set values in this file which may cause
Netx to and Web Start to clash. For example the cache hierarchy is quite
different and one of them may overwrite/delete files the other creates.
For another, the user may set values which may make sense in one and not
another - for example setting a custom user.security.trusted.cacerts
(which netx does not support) and then not allowing any security prompts
for applications which appear untrusted. Such an application would work
under Java Web Start but fail under netx.
I am sure these issues can be ironed out, but for now we shouldnt ignore it.
More information about the distro-pkg-dev