[kepler-dev] kar format

Kevin Ruland kruland at ku.edu
Wed Oct 12 07:10:10 PDT 2005


Hi,

After digging through the kar files some I have some suggestions.

1)  The PTII standard actors/directors should not be included in kar
files.  They are already in the ptolemy.jar file and having duplicates
in kar files pose some problems which can be avoided.  Each kar file
requires some processing on startup either blowing it apart in the
classpath, or reading the supplemental cache files, or having extra
files in the classpath.  The advantages of kar file delivery are not
necessary for these actors because they are very likely to remain
unchanged for long periods of time.

2)  The structure should be modified so raw classes are in the jar
directly rather than in a jar-in-a-jar.  The reason for this is simple,
it is much easier and faster to load classes directly from a jar.  When
jared-in-a-jar, either the contained jar needs to be expanded into the
filesystem, or some very ugly serial processing need to be performed to
extract the classes.  Suppose the user has written a couple of .java
files and uses a 3rd party jar, then the kar structure should be like this:

usercontrib.kar
---------------
META-INF/MANIFEST.MF
org/usercontribActor.class
org/usercontribUtil1.class
supplemental.jar

I believe that the typical use case would not have 3rd party jars
contained in the kar (I say this because none of the prebuilt kars do). 
This way the typical use case would be very fast and resource light.

3) In order to implement some classloader security/sanity certain
restrictions on the contents of kar files needs to be specified.  The
minimal is that classes cannot be in the java. package.  This helps
limit java runtime corruption and possible secuirty breaches.  Further,
I would suggest that the restriction be even stronger and not allow
classes in the ptolemy and org.kepler packages -- and perhaps others
like diva.  Further I think some type of jar signing should be
implemented where the user is notified of the signing authority and can
accept/deny all kars for particular signing authorities.  If the kar
file mechanism is to be used to provide runtime patches to the protected
packages (ptolemy, org.kepler) then the signing mechanism can be used to
verify that the classes deserve special treatment and are to be loaded
by the principal classloader.

4) The documentation for providing user contributed kar files should
encourage developers to use resources for static data files so they can
be loaded directly from the kar file without having to be placed in the
filesystem. 

Kevin


More information about the Kepler-dev mailing list