The propeties file will contain a main.class property, maybe an optional main.method property, and a set of description properties.

Size: px

Start display at page:

Download "The propeties file will contain a main.class property, maybe an optional main.method property, and a set of description properties."

Ashlynn Glenn
5 years ago
Views:

1 Executables This doc describes the design-in-progress for revamping the command-line execution of openejb. Basic ideas: Commands can be added/removed (start, stop, test, validate, deploy) Adding/removing only requires adding/removing jars from the classpath We can stuff properties files into jars at: META-INF/org.openejb.cli/{name The propeties file will contain a main.class property, maybe an optional main.method property, and a set of description properties. Here is an example of the start command: It would be located at META-INF/org.openejb.cli/start start main.class=org.openejb.server.main description.en=starts the Remote Server description.es=ejecuta el Servidor Remoto We would pull in all these files in the launcher's main method and parse them. If someone typed "openejb --help" then we would list the commands and descriptions. Getting the properties files Hiram wrote some code like this for activeio FactoryFinder.java /** * */ package org.activeio; import java.io.bufferedinputstream; import java.io.ioexception; import java.io.inputstream; import java.util.properties; import EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap; public class FactoryFinder {

2 private final String path; private final ConcurrentHashMap classmap = new ConcurrentHashMap(); public FactoryFinder(String path) { this.path = path; /** * Creates a new instance of the given key * key * is the key to add to the path to find a text file * containing the factory name a newly created instance */ public Object newinstance(string key) throws IllegalAccessException, InstantiationException, IOException, ClassNotFoundException { return newinstance(key, null); public Object newinstance(string key, String propertyprefix) throws IllegalAccessException, InstantiationException, IOException, ClassNotFoundException { if (propertyprefix == null) propertyprefix = ""; Class clazz = (Class) classmap.get(propertyprefix+key); if( clazz == null ) { clazz = newinstance(dofindfactoryproperies(key), propertyprefix); return clazz.newinstance(); private Class newinstance(properties properties, String propertyprefix) throws ClassNotFoundException, InstantiationException, IllegalAccessException, IOException { String classname = properties.getproperty(propertyprefix + "class"); if (classname == null) { throw new IOException("Expected property is missing: " + propertyprefix + "class"); Class clazz; clazz = Thread.currentThread().getContextClassLoader(). loadclass(classname); catch (ClassNotFoundException e) { clazz = FactoryFinder.class.getClassLoader().loadClass (classname);

3 return clazz; private Properties dofindfactoryproperies(string key) throws IOException, ClassNotFoundException { String uri = path + key; // lets try the thread context class loader first InputStream in = Thread.currentThread().getContextClassLoader(). getresourceasstream(uri); in = FactoryFinder.class.getClassLoader().getResourceAsStream (uri); throw new IOException("Could not find factory class for resource: " + uri); // lets load the file BufferedInputStream reader = null; reader = new BufferedInputStream(in); Properties properties = new Properties(); properties.load(reader); return properties; finally { reader.close(); catch (Exception e) { If we used a class similar to that, we could get the commands like such:

4 Main.java FactoryFinder finder = new FactoryFinder("META-INF/org.openejb.cli/"); Properties props = finder.dofindfactoryproperies("start") commands.put("start",props); // we should try and load them all into properties instances and map them in advance //.. later to list help String local = //get the i18n 2 character local (en, es, fr...) for each commands.entryset()... { Map.Entry entry = commandentries.next(); String command = entry.getkey(); Properties props = (Properties) entry.getvalue(); String description = props.getproperty("description."+local, props. getproperty("description")); System.out.print(" "+command+"\t"+description); //.. later to execute a command Properties props = (Properties)commands.get("start"); String mainclass = props.getproperty("main.class"); Class clazz = getclassloader().loadclass(mainclass); Method mainmethod = clazz.getmethod("main", new Class[]{String[].class); mainmethod.invoke(args); // obviously the "start" arg has been shaved off first Actual implementation I took a different approach. Since we won't use this class to actually return a class loaded from the properties file, I made minor changes. I also made the CommandFinder.java capable of finding all possible command homes so that others wouldn't have to implement it themselves. Also, the CommandFinder will automatically set the openejb.home. The idea is that we may be able to get rid of all of the scripts checking for OPENEJB_HOME for us. This is the initial concept so please make changes or suggestions. CommandFinder.java package org.openejb.cli; import java.io.bufferedinputstream; import java.io.file; import java.io.ioexception; import java.io.inputstream; import java.net.url; import java.util.collections; import java.util.enumeration; import java.util.hashmap; import java.util.map;

5 import java.util.properties; public class CommandFinder { private String path; private Map classmap = Collections.synchronizedMap(new HashMap()); public CommandFinder(String path) { this.path = path; public Properties dofindcommandproperies(string key) throws IOException { String uri = path + key; // lets try the thread context class loader first InputStream in = Thread.currentThread().getContextClassLoader(). getresourceasstream(uri); in = CommandFinder.class.getClassLoader().getResourceAsStream (uri); throw new IOException("Could not find factory class for resource: " + uri); // lets load the file BufferedInputStream reader = null; reader = new BufferedInputStream(in); Properties properties = new Properties(); properties.load(reader); //All is well, set openejb.home URL propsurl = Thread.currentThread().getContextClassLoader(). getresource(uri); String propsstring = propsurl.getfile(); URL jarurl; File jarfile; ("!")); propsstring = propsstring.substring(0, propsstring.indexof jarurl = new URL(propsString); jarfile = new File(jarURL.getFile()); if (jarfile.getname().indexof("openejb-core") > -1) { File lib = jarfile.getparentfile(); File home = lib.getparentfile(); getabsolutepath()); System.setProperty("openejb.home", home.

6 return properties; finally { reader.close(); catch (Exception e) { public Enumeration dofindcommands() throws IOException { return Thread.currentThread().getContextClassLoader(). getresources(path); Current Implementation Usage The usage for this is the same as before but you would use the following approach to run instead of the OPENEJB_HOME/bin/openejb command: Usage java -jar OPENEJB_HOME/lib/openejb-core-<VERSION>.jar Eventually, once David and I talk, we will wrap this in a script, like we do now. Right now, only the core commands are implemented: deploy help start stop validate Current Questions Before Integrating Into Mainstream Classpath - Will the command implementors be responsible for managing their classpath? Logging - Will we log errors in the CommandFinder.java or continue as-is outputting StackTrace and OpenEJB messages Handling non-core command - We should have an OPENEJB_HOME/lib/etc where all 3rd party commands, like tests, can house their jars. We need a standard location so the code can just work without the user having to add things to the classpath manually Wrapping in script - We will eventually wrap our executable jar in a script. Help! openejb --help (list the commands and descriptions) This would be the job of the main class of the launcher. It would find all the commands in the system, and list their names and print their "description" property. openejb start --help (list the start help text)

7 The main class of the launcher would do nothing with this. The start command would need to grab it's help text and print it to the system.out. Yes, this is extra work, but the various commands already support this. Also, at some point we won't have the help text as is and will use commons.cli to create the text.

CS5233 Components Models and Engineering

Prof. Dr. Th. Letschert CS5233 Components Models and Engineering - Komponententechnologien Master of Science (Informatik) Working with Jars (and other files using NIO) Seite 1 Jars http://download.oracle.com/javase/tutorial/deployment/jar/index.html