This application is a URL navigator. It allows you to browse through URL hierarchies in a file manager fashion. Typical file manager functions such as copy, paste, find, etc. are available. It currently supports six URL schemes: "file", "ftp", "http", "jar", "jndi" and "jms".
Some distinguishing features are:
These pages offer a tree view of an URL structure. The root of the tree is defined by the "URL" field. It can be edited or used for selection. The entries in the tree view which are not containers are filtered by the pattern specified in the "Filter" field. The pattern is like a file pattern. It is case-sensitive.
With the following popup menu the life cycle of navigator pages [as well as finder pages] can be managed:
Creates a new navigation page, which is placed in front of the selected page.
Deletes the selected page.
The items in the tree view are all selectable. A selection can be manipulated by performing actions on them, which are to be picked from the popup menu. The inferior section of the menu is built-in. Its items are explained in the following table. The sections above are filled with user-defined actions, which are defined on the "Parameters" page.
Copy the selected URLs and everything in them. The effect of the action is delayed until a paste action. If a copy is reissued before a paste only the last copy will produce an effect.
Remove the selected URLs and everything in them. The effect of the action is delayed until a paste action. If a cut is reissued before a paste only the last copy will produce an effect.
Immediately remove the selected URLs and everything in them.
Change the root to the URL specified by the "user.home" system property.
Create a finder page with the root set to the selected URL. There may only be one selected URL and it must be a container.
Toggle the FTP transfer data type between ASCII and IMAGE (binary). The is changed for the complete application, not only the page on which the action is performed.
Create a new page with the root set to the selected URL or its parent if it isn't a container. There may only be one selected URL, except when the scheme is "jndi". See the JNDI scheme for more about this.
Create a new container within the current container.
Create a new non-container within the current container.
Place the result of a copy or a cut operation in the selected URL.
Show or hide the properties table, which contains details about a container which is selected in the tree view. The same kind of actions as in the tree view can be performed on its items, including navigation.
Reload the complete page.
Select all the URLs in the selected container.
Collapse the complete page and open the root.
The default action can be launched on an URL by double clicking on it or by selecting it and hitting the ENTER key (see also section Default Action Patterns). More than one URL may be selected.
At the bottom of a navigation page there are three more items. The value of the "URL" field is the root of the page (see also URLs). The "Filter" field contains a file pattern which causes a subselection of the non-containers to be shown (see also Filter Patterns). Right to the latter there is a toggle button to switch between case-sensitive and case-insensitive mode.
This scheme is an interface to file systems. All navigation page operations can be used.
The "ftp" scheme provides access to FTP servers. All navigation page operations can be used. Combined with URL authentication mechanism this add a new dimension to the FTP client concept. It is possible to move about files while transparently switching between connections with different credentials.
HTTP servers are accessible through this scheme. All navigation page operations can be used, but note that renaming files is not directly supported by the HTTP protocol. Therefore, the operation is implemented with a copy/delete combination, which is quite slow in this case.
With this scheme zip files can be manipulated. All navigation page operations are available for it, meaning you can work with zip files as if they were file systems. Updating zip files does not work on Windows because of bug 4823678 in the Java Bug Parade. In the file scheme archives with the extensions "zip", "jar", "ear", "war" and "rar" are recognised as containers in the jar scheme, providing transparant navigation into such files. You can create a new zip file by creating a new file, renaming it such that it has one the extensions and by copying files to it.
The "jndi" scheme is something proprietary and has the following syntax: jndi:<provider_url>!/<path>. Authentication is tied to the provider URL. The basic and URL authentication mechanisms can be used for it. Note that the system property "java.naming.factory.initial" must be set to a valid JNDI initial context factory class. A JNDI tree cannot be modified in any way.
The provider URL should be a hierarchical URL. Opaque URLs are not supported. For example, use iiop://<authority>[:<port>] instead of corbaname:iiop:<authority>[:<port>].
A special note should be made about the "make root" operation. If exactly two URLs are selected, of which one is a JMS connection factory name and the other a JMS queue name, this operation will generate a "jms" URL.
The "jms" scheme provides manipulation of JMS queues. It is a proprietary scheme with the following syntax: jms:<factory_url>!/<queue_name>[<properties>], where the factory URL is <provider_url>/<connection_factory_name>. The provider URL is a JNDI provider URL, to which authentication is tied. The "jndi" scheme can be used to generate such a URL.
The optional properties are a list of <name>=<value> pairs separated by semicolons. They are case-sensitive. The allowed names are the JMS header names and any other free property. However, there are some restrictions. A message on a queue is addressed by specifying the "JMSMessageID" property only. A queue is addressed by not specifying any property or only the "selector" property, which accepts the JMS selector syntax for its value.
Putting a new message on a queue can be done by addressing the queue and adding any properties except "JMSMessageID" and "selector". The specified properties will be used to create the message. The "JMSExpiration" header is not available for this. Instead the "JMSTimeToLive" property should be used with a period expressed in milliseconds.
In UIVI the latter can be exploited by taking a file and renaming it using the property syntax; for example: "JMSPriority=5;MyProperty=test;JMSTimeToLive=300000". If such a file is copied to a queue the correct URL for putting a message on a queue will be generated. If the filename doesn't follow the property syntax the property "Name=<filename>" will be generated.
It is not possible to rename a message on a queue. New messages can be added and existing ones can be deleted.
A finder page can be created from a container URL in a navigator page. This URL will be the starting point for the search. It can be changed in the "URL" field. The "Conditions" subpage is where the conditions for the search can be specified. It is edited the same way as the parameter tables. So the menu described in section Parameters applies.
The first column presents the list of conditions, which are defined on the Conditions parameter subpage. The second column is available for those conditions which require an additional argument to test against. The third column provides the choice between the logical operators "and" and "or". The value "and" is the default. In the resulting expression the "and" operator takes precedence.
The actual search is started by clicking on the "Execute" button or by hitting the "Ctrl-E" key combination. A running search is stopped by clicking on the "Stop" button or by hitting the "Ctrl+S" key combination.
The results are added to the "Results" subpage. The usual action menu, which is available for the navigation pages, can also be used on the results subpage.
The finder makes no distinction between URL schemes. Whenever a configured condition wants to make a distinction, it must ignore schemes it does not support.
Finder pages inherit their case-sensitivity from the navigation page their created from. Finder pages pass this property on to the new finder pages they spawn.
All modifications done on this page are immediately saved in the
configuration file called
<user.home>/.be/re/app/uivi/Parameters, which is created
with sample parameters during start-up if it isn't present. All tables on
the parameters page can be modified with the popup menu presented in the
following table.
Create a new row in the table after the selected one.
Create a new row in the table in front of the selected one.
Copy the selected rows. They can be pasted somewhere in the table afterwards.
Remove the currently selected rows from the table. They can be pasted somewhere in the table afterwards.
Add earlier copied or cut rows to the table, after the selected one.
Move the currently selected row one place higher.
Move the currently selected row one place lower.
Make the currently selected action the global default action. This is the action used if the selection on a page doesn't match a default action pattern. This menu item is only available for the Actions table.
In this section actions can be defined, which are included in the
popup menu. The "Display Name" column contains the labels for the menu items.
The "Command Line" column describes a Java command line, i.e. a Java class name
followed by options. A useful class is be.re.util.Exec. Its
arguments together form a command line which is sent to the host system. This
way programs can be launched.
The display names define the structure of the popup menu. The order of the rows in the table defines the order of the menu items. A display name "separator" introduces a section line in the popup menu. A display name may be composed of parts separated by a forward slash ("/"). The parts become submenu items in the popup menu. Two menu items reside in the same submenu if they have exactly the same part structure.
Two special symbols can be used in the definition of a command line. The "*" symbol is replaced by all the selected URLs on the navigator page for which the popup menu is activated. The "#" symbol is treated the same way, except that only URLs using the "file" protocol are retained. Everything between single or double quotes is placed in one argument position during command line construction.
In here file patterns can be associated with actions. When the default action is launched on an URL, its name is matched with the patterns in the user-specified order. The display name of the first matching row is used to retrieve the corresponding command line, which is then executed. Therefore the display name must be exactly the same as one in the Actions section. If no match is found the global default action is launched.
The default action pattern mechanism only works for a selection containing one URL. Otherwise the global default action is used.
The rows in this section are put in the "URL" field of every new navigator page. It is a pre-selection of URLs which are often used as the root of a page.
The filter patterns are file patterns which restrict the non-container URLs shown on a navigator page. The "Filter" field of a page is loaded with the rows in this section. It is a pre-selection of often used filter patterns.
This table defines the conditions that are available to the finder
pages. The "Display Name" column contains the items which are shown in the
comboboxes on the finder pages. The method names in the second column must be
static methods returning an int. The value
be.re.app.uivi.Conditions.TRUE
must be returned if an URL matches the condition,
be.re.app.uivi.Conditions.FALSE otherwise. Two other values are
available: be.re.app.uivi.Conditions.TRUE_PRUNE for indicating
that a selected URL should not be searched into and
be.re.app.uivi.Conditions.FALSE_PRUNE for indicating the same for
an URL which is not selected.
A condition method must have two arguments. The first is of type
URL, the second of type String. Whether the second
argument is used or not depends on the nature of the condition. A search for
names, for example, requires a name pattern to match, while testing if
an URL is writable doesn't require a second argument.
There are a number of built-in conditions. They are only pre-configured so they can be easily removed. The following table explains them. They are called by their pre-configured name.
Tests a path segment against the specified file pattern.
Tests a complete path name against the specified file pattern.
Tests a path segment against the specified file pattern in a case-insensitive way.
Tests a complete path name against the specified file pattern in a case-insensitive way.
Tests if a file was modified since and including the specified date/time. Ignores other schemes than "file". The following patterns are allowed:
Tests if a file was modified before the specified date/time. Ignores other schemes than "file". The same patterns are allowed as for the previous condition.
Tests if the URL is a container.
Tests if the URL is not a container.
Tests if a file is readable. Ignores other schemes than "file".
Tests if a file is writable. Ignores other schemes than "file".
Tests if a file is readable but not writable. Ignores other schemes than "file".
Tests if a file is hidden. Ignores other schemes than "file".
Tests if the size of a file is equal to the specified size. Ignores other schemes than "file".
Tests if the size of a file is strictly greater than the specified size. Ignores other schemes than "file".
Tests if the size of a file is strictly less than the specified size. Ignores other schemes than "file".
Executes the specified command line. If the exit code is 0 the
method returns true, otherwise it returns false. Two
special symbols may be used in the command line. The "#" symbol indicates only
files are considered. The "*" causes all URL schemes to be taken into
account.
Some URLs are only accessible through a proxy server. This can be configured in the "Proxies" table. The first column specifies the host for which a proxy must be used. It can be a host name or an IP address. An IP address does not have to be complete, i.e. it may designate a network instead of a host by saying for example "192.168" or "192.168.1". A host name can also be specified partially. For the host "a.b.com" the entry "b.com" is valid. So for all hosts ending with "b.com" the entry is valid. For both host names and IP addresses the most specific entry is always used. If the "Host" field has the value "default", a default proxy will be used for any host having no specific entry.
The second field defines the protocol to which the proxy definition applies. So a different proxy could be specified for "ftp" and "http". The protocol names must correspond to URL schemes.
The third field designates the proxy URL. Only "http" URLs are supported. If the value is "none" for a specific host or network, no proxy should be used.
The proxy data is stored in the file
<user.home>/.be/re/net/ProxyManager. This file is updated
immediately when something is changed in the table.
In this table username/password combinations can be stored for resources in the context of some protocol. The resources are mostly host names, but do not need to be. Interactive authentication can be avoided by inserting a valid entry in this table. If none can be found an authentication dialogue box pops up. A default username/password combination can be defined for a protocol through setting the resource to the value "default".
The basic authentication entries are stored in the file
<user.home>/.be/re/net/BasicAuthentication. This file is
updated immediately when somethings is changed in the table.
In this table username/password combinations can be stored for URLs. Interactive authentication can be avoided by inserting a valid entry in this table. If such an entry could not be found the basic authentications are consulted.
The URL authentications work hierarchically. If, for example, the entry ftp://ftp.a.com/ is present, the username/password combination is also valid for URLs such as ftp://ftp.a.com/home/, ftp://ftp.a.com/usr/local/, etc. If at the same time there is another entry for, say, ftp://ftp.a.com/home/, then the latter is used for all URLs "below" this one. So, the most specific entry is always applied.
The URL authentication entries are stored in the file
<user.home>/.be/re/net/URLAuthentication. This file is
updated immediately when somethings is changed in the table.
The trash bin field must contain a valid writable URL. Otherwise it will be impossible to delete URLs on a navigator page. This is because in fact URLs are moved to the trash bin instead of being actually deleted. The same operation in the trash bin causes the URLs to be really deleted.
It is possible to encrypt the passwords which are in the basic and URL
authentications files (see Basic Authentications and
URL Authentications). This can be done with the
be.re.tools.EncryptResourcePasswords programme (configured by
default for new installations). An interactive authentication dialogue box will
appear in which only a password must be provided. The same password must, of
course, be entered for decryption. Decryption occurs at start-up if encrypted
passwords are detected or can be triggered by running the
be.re.tools.DecryptResourcePassword programme. The latter is a
persistent action, just like its encryption counterpart. The
encryption/decryption password is asked only once during the lifetime of a
JVM.
Note that Sun JCE 1.2.1 or higher must be installed for encryption to work. JRE 1.4 or higher has everything on board.
The task manager lists tasks which are running in the background. In that case the LED will be red. A task can be interrupted by selecting it and activating the popup menu item "Stop" on it or by typing "Ctrl+S".
These are welcome at uivi@re.be.
© 2000-2003 Re BVBA. All rights granted except commercial ones.
This software is free and will remain free.
To use at your own responsibility.