river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Activation subsystem - Non-public Interfaces
Date Mon, 02 Nov 2015 14:24:17 GMT
Hi all:

I’m attempting to apply Shawn Ellis’s patch from RIVER-444 to allow the 2.2 branch to
build under JDK8.  On running the QA package, I’m getting errors on the tests that use the
activation subsystem. They are similar to:

proxy implements non-public interface 'com.sun.jini.test.impl.joinmanager.LeaseRenewDurRFE$RemoteTestServiceInterface’

The exception is thrown from the getSuperInterfaces(…) method inside ActivationExporter.
 (note that this is after I modified ActivationExporter to tell me the name of the non-public
interface).

	    /*
	     * Complain if the underlying proxy has a non-public class and
	     * implements non-public interfaces.
	     */
	    if (checkPublic && !Modifier.isPublic(intf.getModifiers())) {
		throw new ExportException(
		    "proxy implements non-public interface" + " '" + intf.getName() + "'");
	    }

So, I have a few questions…

First, does anyone actually use the Activation subsystem?  I don’t and never have, so personally
I’d be fine with dropping Phoenix and net.jini.activation, or at least just skipping the
QA tests on it.  Opinions?

ActivationExporter throws the exception above if the underlying proxy implements any non-public
interfaces.  This seems reasonable, because ActivationExporter needs to wrap the underlying
activation proxy in another proxy.  Should we just make the required interfaces (like 'com.sun.jini.test.impl.joinmanager.LeaseRenewDurRFE$RemoteTestServiceInterface’)
public?  As it’s part of the QA package, that seems pretty harmless, but I’m sure there
are others.

It’s funny that this is only showing up now.  The code is in the 2.2 branch, and I don’t
see how it could be related to JDK8 (the problem also shows under JDK7, btw).  I believe the
activation tests have been bypassed on the Jenkins QA run.

I guess the question is, should we track down what’s going on in the activation subsystem,
or just bypass the tests and forget about it?  And if that’s the case, should we deprecate
the JERI activation system? (FWIW, I’m OK with deprecating it, but as I say, someone may
be using it).

Cheers,

Greg Trasuk


Mime
View raw message