Reflection - wie anwenden/benutzen bei folgendem Problem

[y0dA]

Hi!
Also ich habe eine Klasse OfflineProcessor, von jener sind folgende 2 Klassen eine Spezialisierung: FileSystemProcessor und DatabaseProccesor. Die beiden Spezialisierungen wiederum besitzen eine Klassenvariable welche ein Interface (ITrackParser) implementieren sollte.

Also grafisch ungefähr so:

OfflineProcessor
^ ^
| |
FileSystemProcessor DatabaseProcessor
| |
use use
| |
ITrackParser ITrackParser <-------NMEAParser (Beispiel Implementation)


Nun liegt mein Problem darin dass es möglich sein sollte dass man die Klasse welche ITrackParser implementiert auch von dritten implementiert werden können. Nun brauche ich irgendeine Möglichkeit dass, wenn ich der Klasse OfflineProcessor den Pfad zum JAR File der Implementation zu ITrackParser angebe, dass ich dann jenen Parser in FileSystemProcessor benutze.

Kann mir hier jemand weiterhelfen bzw. ist es überhaupt möglich zur Laufzeit externe JARS zu benutzen?

OfflineProcessor:

public class OfflineProcessor {
	/**
	 * implementing class name
	 * must implement interface
	 * @see {@link org.pcd.wam.gegenstandsbereich.streetDetection.locating.parser.ITrackParser}
	 */
	private String className;
	
	/**
	 * path to jar libary path which contains <code>{@link #className}</code>
	 * if <code>{@link #className}</code> is already implemented, value is null
	 */
	private String libPath;
	
	/** */
	private String name;
	
	/**
	 * empty constructor
	 */
	public OfflineProcessor() {
		// nothing to do
	}

	/**
	 * getter method
	 * dynamically instantiate a certain processor class
	 * @return processor class
	 */
	protected ITrackParser getTrackInterface() {
		//FIXME wie implementieren?
		return null;
	}
	
	/**
	 * process <code>track</code>
	 * @param track track
	 */
	protected void processTrack(final Track track) {
	}
}

FileSystemProcessor:

public class FileSystemProcessor extends OfflineProcessor {
	
	/** file path */
	private String filePath;

	/**
	 * ??
	 * get closed files with a length greater than 0
	 * @return list of file names
	 */
	public List<String> getFiles() {
		return null;
	}
}

ITrackParser:

public interface ITrackParser {
	/**
	 * returns all tracks depending on parameter <code>fileName</code>
	 * @param s file path name or a jdbc connection string
	 * @return tracks
	 */
	public List<Track> getTracks(final String s);
	/**
	 * returns a device id which corresponds with already definded devices
	 * if not available return null
	 * @return receiver id
	 */
	public String getReceiverId();
}

mfg

 

[SlaterB]

hab mal was zum 'Jar nachladen' bei google gefunden, weiß dazu aber nix
http://www.tutorials.de/forum/java/245982-jar-file-nachladen.html

dann brauchst du noch
Class c = Class.forName(Klassenname) // evtl. mit dem neuen ClassLoader
Object o = c.newInstance(); // Reflection
und das Object auf das richtige Interface casten

 

[quippy]

Wenn ich Dich richtig verstanden habe, dann läuft das Ganze auf eine Factory hinaus. Also sowas wie bei den JDBC-Treibern für verschiedene Datenbanken.

Drittanbieter für Dein Interface müssen dann aber dafür sorgen, daß Deine Factory für das Interface sie kennt, als eine Anmeldung durchführen.

Das geht recht einfach, in dem man in der Implementierung einen static-Block in den Kopf der Klasse packt, etwas in der Art:

public class MyImpl implements ITrackParser
{
   static
   {
      YourFactory.register(MyImpl.class);
      // oder
      // YourFactory.register(new MyImpl());
   }
...
}

Dann würde ein "Class.forName("MyImpl");" ausreichen und deine Factory kennt diese Impl.

Deine Factory wäre eine Containerklasse mit Methoden "register" und "getInstance" wobei bei "getInstance" ein Entscheidungsgrund mitgegeben werden muss, warum welche Impl gezogen werden soll.
Vielleicht hat der Parser einen Namen oder so, dann kann man das angeben.

z.B. "getInstance("default");" für die Default-Impl und "getInstance("MySuperParser");" für den anderen.

Wenn Du einen vollautomatischen PlugIn-Mechanismus haben willst (also einfach ein Jar in einem Verzeichnis ablegen), wird's allerdings schwieriger, denn dann mußtest Du alle Jars diesem PlugIn-Verzeichnis öffnen (geht mit ZipInputStream) und alle Classes, die da drin sind, einmal laden. Denn erst nach dem Laden weißt Du, welche Interfaces sie implementieren - nach oben beschriebener Technik wären Sie dann aber auch schon automatisch angemeldet.

Alternativ könnte man aber auch eine properties-Datei pflegen, in welche man die zu ladenden Klassen eintragen muss.

 

[quippy]

hab mal was zum 'Jar nachladen' bei google gefunden, weiß dazu aber nix
http://www.tutorials.de/forum/java/245982-jar-file-nachladen.html

Die im Link vorgestellte Taktik ist unglücklich, denn sie verwendet eine Methode "addURL", welche private ist, und bedient sich "schmutziger" () Reflection-Tricks, um sie dennoch zu verwenden. D.h. in zukünftigen Versionen des ClassLoaders könnte sie sang- und klanglos verschwinden oder umbenannt werden - da sie private (oder protected?) ist, muss man annehmen, daß das ohne "@deprecated" erledigt würde.

Auch wenn es nicht so einfach ist: für das dynamische Nachladen von JARs würde ich eher einen neuen ClassLoader schreiben, der das beherrscht und dann damit arbeiten - das ist sauberer.