Activation subsystem - Non-public Interfaces

[Greg Trasuk <tr...@stratuscom.com>]

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

Re: Activation subsystem - Non-public Interfaces

[Greg Trasuk <tr...@stratuscom.com>]

> On Nov 2, 2015, at 5:29 PM, Peter <ji...@zeus.net.au> wrote:
> 
> Hmm,
> 
> Last time we tried to remove Phoenix, someone replied to this list, who was reportedly using it as a watchdog, so we ended up retaining it.

That discussion seems to have generated much heat and little light.  So I’ll ask again, directly - is anyone actually using Activation?

> 
> Have a look in the qa-refactor branch, there may be some comments in the code.  All activation tests pass there and it runs on JDK8.  It's probably something simple that's causing the issue.
> 

http://svn.apache.org/viewvc?view=revision&revision=1596790
It appears that you went through and changed the affected interfaces to ‘public’, although that doesn’t seem to be what the commit is about, and the commit message doesn’t mention anything about activation.  The commit calls out RIVER-439, which is about removing dependencies on Sun implementation classes.  

I suspect the change got swept up in whatever you were doing at the time.  In retrospect, it’s a challenge to keep a clean commit stream, but it would be nice in the future to make sure that a commit or set of commits only affects one feature and the commit message is more descriptive (There’s plenty of Linus Torvalds’ rants out there to draw inspiration from).

So, despite the fact that the changes are in river-qa-refactor, I’d like to ask if anyone has opinions on whether that approach is appropriate.  It doesn’t look like it was discussed at the time.


> If you want the 2.2 branch to run on Java 9, you'll need the security policy providers from qa-refactor as these don't need to be loaded from the extension classloader.  The extension mechanism has been removed from Java 9.   It's worth remembering however, that those policy providers are built for concurrency and scalability, which unfortunately exposed the concurrency bugs that instigated the work in qa-refactor.  Another way to solve that problem would be to only use the policy parser from qa-refactor and build your own file policy provider that uses a HashMap with CodeSource as key's and Permissions (an instance of PermissionCollection) as values, that should eliminate concurrency and ensure latent bugs aren't exposed, if you want the 2.2 branch to live beyond Java 8.
> 

A couple of things…
(1) I think it’s best not to conflate the question with any discussion of Java 9, which is still over the horizon.
(2) I’m not sure where this idea comes from that the security providers need to be in the extension class loader.    I suspect it predates the starter framework or any container implementations.  The example projects run perfectly nicely without putting anything in the extensions folder, and they use DynamicPolicyProvider, as does my container project. 
(3) As you know, I tend to think of the 2.2 branch as being the conservative development counterpart to the 3.0 branch, so IMO we should not do anything too radical with it.  On the other hand, if there’s code in there that’s no longer useful, we should get rid of it.

> In my local copy of River, I also removed rmi stub generation, all except for one local stub in Phoenix related to Activation, at some point after River 3.0 is released, I'll investigate how to commit parts of my local work back into River.
> 

A good point - I would also support deprecating or removing the JRMP portions of the 2.2 branch - they have been pretty much obsolete for 15 years now.  Does anyone have any opinions on that?

Greg Trasuk

> Regards,
> 
> Peter.
> 
> On 3/11/2015 12:24 AM, Greg Trasuk wrote:
>> 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
>> 
>> 
> 

Re: Activation subsystem - Non-public Interfaces

[Peter <ji...@zeus.net.au>]

Hmm,

Last time we tried to remove Phoenix, someone replied to this list, who 
was reportedly using it as a watchdog, so we ended up retaining it.

Have a look in the qa-refactor branch, there may be some comments in the 
code.  All activation tests pass there and it runs on JDK8.  It's 
probably something simple that's causing the issue.

If you want the 2.2 branch to run on Java 9, you'll need the security 
policy providers from qa-refactor as these don't need to be loaded from 
the extension classloader.  The extension mechanism has been removed 
from Java 9.   It's worth remembering however, that those policy 
providers are built for concurrency and scalability, which unfortunately 
exposed the concurrency bugs that instigated the work in qa-refactor.  
Another way to solve that problem would be to only use the policy parser 
from qa-refactor and build your own file policy provider that uses a 
HashMap with CodeSource as key's and Permissions (an instance of 
PermissionCollection) as values, that should eliminate concurrency and 
ensure latent bugs aren't exposed, if you want the 2.2 branch to live 
beyond Java 8.

In my local copy of River, I also removed rmi stub generation, all 
except for one local stub in Phoenix related to Activation, at some 
point after River 3.0 is released, I'll investigate how to commit parts 
of my local work back into River.

Regards,

Peter.

On 3/11/2015 12:24 AM, Greg Trasuk wrote:
> 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
>
>