[icedtea-web] Why use a separate basedir for plugin?
Deepak Bhole
dbhole at redhat.com
Thu Oct 28 11:27:07 PDT 2010
* Dr Andrew John Hughes <ahughes at redhat.com> [2010-10-28 12:39]:
> 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.
>
Well, the deployment.properties file is what I was referring to and it
is the only thing I think we should share. It is supposed to be a simple
<name>=<value> file.
Cheers,
Deepak
> > > 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