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

Dr Andrew John Hughes ahughes at redhat.com
Thu Oct 28 09:11:41 PDT 2010


On 10:02 Thu 28 Oct     , Omair Majid wrote:
> 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.
> 

I can't seem to find the particular mail, but it was something to do with
a patch introducing the ~/.netx tree IIRC.

> >>> 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 :/
> 

So steer well clear.

> > 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.
> 
> Thanks,
> Omair

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint = F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8



More information about the distro-pkg-dev mailing list