Commons Library This provides common API's and frameworks used by most if not all of the other libraries. One of the main apects of this library is the VirtualArtifact framework. This attempts to provide an abstract layer over the normal File framework provided by the JVM. All the other libraries attempt to avoid dealing with File framework, and rather use the virtual one, which allows any type of implementation to be used with the other libraries when dealing with I/O operations or files and directories in general.

Some of the benefits of using this virtual I/O framework are as follows:

• File and directory abstraction allows file system, memory, archives, remote systems among others to be interacted with interchangeably
• The virtual I/O framework allows for adapters to be added to for providing custom output/input, for instance encryption
• Most file and directory related operations are greatly facilitated
• Generally all Virtual Artifact objects are not tied to a static internal directory
• Option to create one or more Virtual Artifact System's in order to allow valid internal URL's
• The VirtualDirectory extension supports the visitor pattern

For example, there is a network library that currently has support for easy SSH based interaction (using the JSCH library) but integrated with the virtual I/O framework thus making any operations with remote files using SFTP a sinch, as the example below shows:

SFTP with Virtual I/O Framework

Toggle Line Numbers

1 package net.sourceforge.javautil.site.example;  2   3 import java.io.IOException;  4 import java.net.URL;  5   6 import net.sourceforge.javautil.common.URLStreamHandlerFactoryComposite;  7 import net.sourceforge.javautil.common.io.VirtualDirectory;  8 import net.sourceforge.javautil.common.io.impl.SystemDirectory;  9 import net.sourceforge.javautil.common.io.remote.RemoteLocation;  10 import net.sourceforge.javautil.common.password.Password;  11 import net.sourceforge.javautil.common.password.impl.UnencryptedPassword;  12 import net.sourceforge.javautil.network.ssh.SecureShell;  13   14 /**  15  * A {@link RemoteLocation} example.  16  *   17  * @author elponderador  18  * @author $Author$  19  * @version $Id$  20  */  21 public class SFTPVirtualIOExample {  22       23     public static void main (String[] args) throws IOException {  24           25         // Here we register the composite factory, which allows multiple and runtime  26         // modifications to URL protocol support. By default it looks up the Sun JVM  27         // protocols and handles the VirtualArtifactSystem "vas://" protocol.  28         //  29         // This is only here for example purposes. The only time you need to have this setup  30         // on boot is when you plan to use the VAS static system and need to support the vas://  31         // protocol which is only used for in memory virtual artifact implementations.  32         //  33         // NOTE: Before the 0.0.6 Commons/Class Loader libraries the URLStreamHandlerFactoryComposite class  34         // was located in a package inside the Class Loader library, but  35         // from 0.0.6 this will now be located in the Commons library.  36         URL.setURLStreamHandlerFactory(new URLStreamHandlerFactoryComposite());  37           38         SecureShell ssh = new SecureShell();  39         Password password = new UnencryptedPassword("password");  40         RemoteLocation remote = ssh.createLocation("some.host", 22, "user", password, "/home/user");  41           42         VirtualDirectory target = new SystemDirectory("target");  43         target.makeDirectories();  44           45         // Now we can simply copy ALL the remote files to a arbitrary virtual directory  46         // which in this case is a real file system directory  47         remote.getRootDirectory().copy(target, true);  48           49     }  50   51 }

Class Loader Library A class loader library was made for two reasons. One to work with the above Virtual I/O framework and another to allow an abstract class package based loader with an extensible API. Also the logic for class loader heiarchy is separated from the class loader implementation, which means that you can easily manipulate the class loader heiarchy logic without the need to write or develop another class loader implementation.

The library comes with two different types of class source API's. One is called ClassSource and the other is called ClassDependencyPool. Both can be used with the ClassLoader implementation called ClassContext.

Along with the same library there is a Maven integration library which allows for using pom.xml's to boot an application without any dependency on the Maven libraries.

Along side the above mentioned ClassLoader API is a Boot strapping API. The main class is called EntryPoint. It comes with a Maven implementation to look for a pom.xml and use it to create an application specific class loader after which a main class can be specified. EntryPoint's can be chained allowing various levels of boot strapping. The only library that this class loader library relies on is the commons library. Which means with both these libraries in your class path you can boot an application with a single application jar and all it's dependencies declared in a pom.xml. If the dependencies are not currently in the local maven repository they are searched for and the user is given the option to authorize their download. On the command line you could do the following (assuming you are using the 0.0.5 versions of these libraries):


The above will look for a pom.xml, which you can place in the same directory, and it will use that to create an application class loader from which it will attempt to load the some.application.Main and invoke the appropriate method, which is normally the static void main (String[] args) {} method.

But what about setting up your own class loader, and integration with the Virtual I/O framework? The following example can illustrate this:

Class Loader Configuration Example

Toggle Line Numbers

1 package net.sourceforge.javautil.site.example;  2   3 import net.sourceforge.javautil.classloader.impl.ClassContext;  4 import net.sourceforge.javautil.classloader.impl.StandardClassLoaderHeiarchy;  5 import net.sourceforge.javautil.classloader.resolver.ClassDependencyPool;  6 import net.sourceforge.javautil.classloader.resolver.ClassPackageResolver;  7 import net.sourceforge.javautil.classloader.resolver.ClassPackageUtil;  8 import net.sourceforge.javautil.classloader.resolver.impl.ClassPackageDependencyReferenceImpl;  9 import net.sourceforge.javautil.classloader.resolver.impl.ClassPackageReferenceImpl;  10 import net.sourceforge.javautil.classloader.resolver.impl.maven.MavenRepositoryUtil;  11 import net.sourceforge.javautil.classloader.source.VirtualDirectoryClassSource;  12 import net.sourceforge.javautil.common.ClassNameUtil;  13 import net.sourceforge.javautil.common.io.VirtualArtifact;  14 import net.sourceforge.javautil.common.io.VirtualArtifactUtil;  15 import net.sourceforge.javautil.common.io.VirtualDirectory;  16 import net.sourceforge.javautil.common.io.impl.Directory;  17 import net.sourceforge.javautil.common.io.impl.DirectoryRoot;  18 import net.sourceforge.javautil.common.io.impl.SimplePath;  19 import net.sourceforge.javautil.common.io.impl.SystemDirectory;  20   21 /**  22  * A custom class loader configuration example.  23  *   24  * @author elponderador  25  * @author $Author$  26  * @version $Id$  27  */  28 public class ClassContextExample {  29       30     public static void main (String[] args) {  31           32         // Here we create a new class package based dependency pool. By using the utility class  33         // we take advantage of the possible case where the EntryPoint framework was used  34         // to boot strap the application, which if is the case we can take advantage of already loaded  35         // dependencies.  36         ClassDependencyPool pool = ClassPackageUtil.createStandardDependencyPool("main", true);  37           38         // Here we create a standard Maven based resolver  39         ClassPackageResolver resolver = MavenRepositoryUtil.createStandardResolver();  40           41         // We now use the resolve to populate the pool with the specified dependency  42         // and this utility append method will take care of possibly downloading remote  43         // libraries when they are not found in the local repository.  44         ClassPackageUtil.append(pool, resolver, true, new ClassPackageDependencyReferenceImpl("some.group.id", "some.artifact.id", "version", null));  45           46         // Here we now create the class loader with standard heiarchy logic and it will use the pool for class resolution  47         ClassContext cl = new ClassContext(new StandardClassLoaderHeiarchy(), pool);  48           49         // We create a VirtualDirectory implementation instance   50         // that allows us to link various directories together as if  51         // they were one  52         Directory linkable = new DirectoryRoot();  53           54         // We link some compiled class directories   55         linkable.link(new SystemDirectory("some/path/to/classes"));  56         linkable.link(new SystemDirectory("some/other/path/to/classes"));  57           58         // We add a single class file, getting the package   59         Directory pkg = (Directory) linkable.getDirectory("net/sourceforge/javautil/site/example");  60           61         // We now add the class file to the internal package directory  62         pkg.link(VirtualArtifactUtil.getResource(ClassContextExample.class, ClassNameUtil.toRelativeClassPath(ClassContextExample.class.getName())));  63           64         // We now create another class loader that uses the dependency pool as well as  65         // a custom class source based of a VirtualDirectory.  66         ClassContext acl = new ClassContext(new StandardClassLoaderHeiarchy(), pool, new VirtualDirectoryClassSource(linkable));  67           68     }  69   70 }