[icedtea-web] Why use a separate basedir for plugin?

Omair Majid omajid at redhat.com
Thu Oct 28 07:02:56 PDT 2010

On 10/28/2010 09:38 AM, Dr Andrew John Hughes wrote:
> On 18:31 Tue 26 Oct     , Omair Majid wrote:
>> On 10/26/2010 06:18 PM, Deepak Bhole wrote:
>>> * Omair Majid<omajid at redhat.com>   [2010-10-26 11:03]:
>>>> Hi,
>>>> 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
>>>> this?
>>> Well, for one, they are 2 different things. We use the netx component
>>> for embedding, but the plugin is still separate in terms of
>>> functionality.
>> 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.
> I thought we'd already decided to do this? :-)

Really? I was not aware of that. As far as I know the plugin keeps its 
files under ~/.icedteaplugin/ and netx keeps its files under ~/.netx/ 
and we never decided to unify it.

>>> 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
>>> IcedTea/NetX.
>> 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.
> Unless this .java/deployment directory is openly specified, and that same specification
> adhered to by the proprietary plugin, I would steer well clear.

The only "specification" related to the ~/.java/deployment directory 
that I can find is that it contains the deployment.properties file :/

> If the plugin was open source, then I wouldn't be so wary. But then, we probably wouldn't
> even be writing our own then, would we?

Heh. Good point.


More information about the distro-pkg-dev mailing list