See: Description
| Package | Description |
|---|---|
| org.netbeans.core.network.proxy.pac |
Proxy Auto-Config (PAC) script related.
|
| org.netbeans.core.network.proxy.pac.datetime |
Proxy Auto-Config (PAC) script related, specifically around
Java support for the JavaScript helper functions
dateRange(),
timeRange() and weekdayRange(). |
| org.netbeans.core.network.proxy.pac.impl |
NetBeans default implementation of a PAC script evaluation
environment.
|
| org.netbeans.core.network.utils |
Utilities related to network.
|
The Core Network module provide ProxySelector as well as utilities related to network connections.
ProxySelector
The role of a ProxySelector is to tell to the rest of Java which
proxy to use for a given URL. There's only one ProxySelector in a given
JVM. Most notably the ProxySelector is used by the URLConnection
classes and even the new HTTP client in JDK9 is using it, although it allows
more control over this than does the URLConnection classes.
Also, the Apache HttpClient is also using the default ProxySelector if you have instructed
it to use what is known in Apache HttpClient as SystemDefaultRoutePlanner.
This module provides an implementation of a ProxySelector which finds out which proxy to use by looking at preferences the user has stored. This is trivial for the case where the user has provided explicit proxy information. It is more complex for the case where the user has said "just use my system's proxy configuration" which is by the way the default in NetBeans. This requires us to go the underlying OS and try to figure out what the user's settings are. In many case case the user will not have explicit proxy setting in the OS either but will simply have "Automatically detect settings" or whatever. This makes it even more complex (see WPAD section below).
The ProxySelector is instantiated by the Startup module, but only if module Core also exists. Thus, for a minimal Platform application which only use the modules from the "Runtime Container", there will be no ProxySelector installed because module Core is not part of the Runtime Container. In this case, the standard ProxySelector in Java will then be used. This makes sense because a headless application will not have stored Preferences about proxy, etc, and will be much better off by just using the standard ProxySelector (which can be controlled by properties).
Module Core uses the Global Lookup to search for a ProxySelector, so you can register your own ProxySelector if you don't like the one provided by the Platform (i.e. this module). This will be somewhat difficult though, because in order to implement your own ProxySelector, you would need read access to the stored ProxySettings. This class is currently only exposed to friends.
Proxy Auto-Config (PAC)
Very often the proxy configuration on a corporate network is not given explictly. Instead it is given in a little JavaScript file which clients are supposed to download and execute in order to find out which proxy to use. This is known as Proxy Auto-Config (or PAC). This module provides a pluggable PAC evaluation environment based on available JavaScript engine installed in the JVM. Execution of the downloaded JavaScript code is sandboxed.
org.netbeans.core.network.proxy.pac.impl.ALLOWED_PAC_ENGINES To further secure execution of downloaded scripts, it is possible to restrict the set of allowed ScriptEngines to evaluate the PAC scripts. Provide a branding of bundleorg.netbeans.core.network.proxy.pac.impl.Bundle
in your own application
and change the value of ALLOWED_PAC_ENGINES key.
The default is GraalVM:js,Graal.js,Nashorn - e.g. the engines
currently considered secure.
If you don't like the PAC evaluation environment provided
by this module then you can plug in your own by registering
your own PacScriptEvaluatorFactory class in the Global Lookup.
If you want to build your own PAC evaluation environment then you can
still make use of all the utility classes provided by this module.
Locating the PAC script (WPAD)
Normally, a Web Browser (in comparison) can locate the PAC script either explicitly, meaning the URL is directly available from the settings in the OS, or it can be located via WPAD This module currently only supports the case where URL is directly available from the settings. There's no support for WPAD.
The PAC Script Evaluation environment (as part of ProxySelector)
has been completely rewritten and is now pluggable. (albeit for now only for friends)
ProxySelector
in the Global Lookup. However, make sure you understand that
the instantiation of the ProxySelector (i.e. executing its constructor)
is part of the main startup path of a NetBeans application. For this
reason the constructor better be fast. Defer as much work as possible to
later.
default one
provided in this module. You do this by registering your
own PacScriptEvaluatorFactory
in the Global Lookup. This factory must then in turn return an
instance of your custom PacScriptEvaluator.
default PAC evaluator
you can replace only its implementation of the PAC Helper Functions.
However, you have to play by rules set by the default PacScriptEvaluator,
namely that all the Helper Functions are implemented in Java (as opposed to JavaScript).
Simply register your sub-class of PacHelperMethods
in the Global Lookup and your implementation will automatically be picked
up. When creating your own PacHelperMethods you may
take benefit from the PAC utility functions provided by PacUtils
and PacUtilsDateTime,
as well as the more general ones provided by network utils package.
|
|
The sources for the module are in the Apache Git repositories or in the GitHub repositories.
XXX no answer for deploy-dependencies
Read more about the implementation in the answers to architecture questions.