river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: Need for jsk-dl.jar
Date Tue, 04 Jan 2011 08:58:56 GMT
I don't know about forgotten but as far as I recall the separation isn't
entirely about supplying what is needed by clients or services. Looking at
the release notes below I can see a couple of critical things:

(1) The reference in respect of assuming these classes will always be
present.
(2) The statement about what is bundled - definition of "the platform".
(3) The statement that any other classes present are to be considered "an
implementation detail".

The notes also cover jsk-lib.jar of course and discuss the fact that these
are the common utility classes that services or clients may want to make use
of. Should a service make use of these utility classes for it's own
server-side implementation only it would include jsk-lib.jar on classpath
but I doubt it would expose jsk-dl.jar to clients. If of course, it wants to
make use of the utility classes in its proxy implementation, jsk-dl.jar
would appear as codebase.

In essence, although we see general usage of jsk-lib.jar, it's not part of
the platform or expected to always be present on classpaths.

*jsk-platform.jar*This JAR file contains classes and interfaces that we have
chosen to include in all of our applications, and have also chosen to assume
are available in all other applications that receive objects from our
applications. This JAR file primarily contains classes and interfaces that
are typically referenced in:

   - *service provider*<http://java.sun.com/j2se/1.4/docs/guide/jar/jar.html#Service
Provider> resources
   to control the configuration of
RMIClassLoader<http://java.sun.com/j2se/1.4/docs/api/java/rmi/server/RMIClassLoader.html>
   , TrustVerifier <../api/net/jini/security/TrustVerifier.html>,
   IntegrityVerifier <../api/net/jini/security/IntegrityVerifier.html>,
   ServerContext <../api/net/jini/export/ServerContext.html>, and
   DiscoveryFormatProvider<../api/com/sun/jini/discovery/DiscoveryFormatProvider.html>
    providers
   - ConfigurationFile <../api/net/jini/config/ConfigurationFile.html> source
   files, but which are unlikely to be referenced directly by the applications
   and services being configured (in particular, classes for creating
   Exporter <../api/net/jini/export/Exporter.html>
andProxyPreparer<../api/net/jini/security/ProxyPreparer.html>
instances
   and their components)
   - dynamically downloaded code, but which we believe are not themselves
   reasonable to download (in particular, because they are needed to bootstrap
   proxy trust verification, or because their implementations require
   extraordinary permissions)

plus all of the classes and interfaces that their implementations directly
or indirectly depend on.

This JAR file contains all of the classes and interfaces in the following
namespaces (including all subpackages):

   - net.jini.activation
   - net.jini.config
   - net.jini.constraint
   - net.jini.core
   - net.jini.export
   - net.jini.id
   - net.jini.iiop
   - net.jini.io
   - net.jini.jeri
   - net.jini.jrmp
   - net.jini.loader
   - net.jini.security
   - net.jini.url
   - com.sun.jini.discovery

plus the following classes:

   - ConstrainableLookupLocatorTrustVerifier<../api/net/jini/discovery/ConstrainableLookupLocatorTrustVerifier.html>
   - KeyStores <../api/com/sun/jini/config/KeyStores.html>
   - ConfigUtil <../api/com/sun/jini/config/ConfigUtil.html>
   - LogManager <../api/com/sun/jini/logging/LogManager.html>

Any other classes or interfaces found in this JAR file should be considered
implementation details.


On 3 January 2011 23:24, Dennis Reedy <dennis.reedy@gmail.com> wrote:

> I'm slogging through classes and jars attempting some modularization of the
> River codebase. Its going fairly well. I'm sitting here scratching my head
> whilst looking at jsk-dl.jar. My question is as follows:
>
> In general jsk-lib.jar is either in the classpath of a service, as well as
> in the classpath of a client. The inclusion of jsk-lib.jar (from a client's
> point of view) brings along helpful utilities like ServiceDiscoveryManager
> and the like. From a service developers point of view, you can't really get
> around not using it.
>
> If jsk-lib.jar is in the classpath (and by inclusion jsk-platform.jar), why
> do we need jsk-dl.jar? Unless I'm mistaken all of the classes that are in
> jsk-dl.jar are already in jsk-lib.jar, why is it needed?
>
> What have I forgotten?
>
> Regards
>
> Dennis

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message