Remoting 3: Beta release imminent

[dmlloyd]

OK, so I've finished fixing up the Multiplex problems, getting integration with XNIO 1.2 and Mashalling straightened out, classloading, etc.

There is only one remaining issue for Beta1, which relates to service metainformation which I think is now covered by the service registration API, so I'll be closing this issue.

What I'd like to know is if there's anything anyone feels is missing/broken that we can't do a 3.0.0.GA without. And, of course, we need more tests... always more tests!

[anil.saldhana]

What I'd like to know is if there's anything anyone feels is missing/broken that we can't do a 3.0.0.GA without. And, of course, we need more tests... always more tests!

Maybe ant target to run your tests under a security manager with stingy security policy. ;)

[dmlloyd]

We already have that. Check out our current testing policy:

http://anonsvn.jboss.org/repos/jbossremoting/remoting3/trunk/testing-support/src/main/resources/testing.policy

[anil.saldhana]

grant codeBase "file:${build.home}/api/target/test/classes/-"
{
 permission java.lang.RuntimePermission "modifyThread"; // for executor control
};

grant codeBase "file:${build.home}/core/target/test/classes/-"
{
 permission java.lang.RuntimePermission "modifyThread"; // for executor control
 permission org.jboss.remoting.EndpointPermission "createRequestHandler";
 permission org.jboss.remoting.EndpointPermission "createClient";
};

grant codeBase "file:${build.home}/protocol/basic/target/test/classes/-"
{
 permission java.lang.RuntimePermission "modifyThread"; // for executor control
 permission java.net.SocketPermission "*:*", "accept, connect, resolve";
 permission org.jboss.remoting.EndpointPermission "createRequestHandler";
 permission org.jboss.remoting.EndpointPermission "createClient";
};

grant codeBase "file:${build.home}/protocol/multiplex/target/test/classes/-"
{
 permission java.lang.RuntimePermission "modifyThread"; // for executor control
 permission java.net.SocketPermission "*:*", "accept, connect, resolve";
 permission org.jboss.remoting.EndpointPermission "createRequestHandler";
 permission org.jboss.remoting.EndpointPermission "createClient";
};

I think the permissions assigned to the tests are pretty lenient. Mainly the socket perm.

But since this is remoting, I cannot comment.

[dmlloyd]

Well, without the ability to create servers or connect to them, the tests would be pretty boring. :)

Though in point of fact, I do not think that these permissions are needed anymore, since I use XNIO pipes for testing now, rather than sockets...

[dmlloyd]

Updated with stricter permissions. As usual. anonsvn will take a few minutes to sync up.

[dmlloyd]

I think we'll want to change the packaging somehow. I think the standalone classes should be merged into API for sure. API, and core should remain separate for classloading reasons... util should probably be split among core and API rather than being wholly in the API.

So in the end there should be:
jboss-remoting-api.jar <- api plus standalone and some util
jboss-remoting-core.jar <- core plus some util (maybe these should be merged to one module)
jboss-remoting-transporter.jar <- transporter
jboss-remoting-multiplex.jar <- multiplex transport

I dunno, needs more thinking I guess. What do you guys think?

Also, gotta remember to get COPYING.txt in all of those... and source JAR targets too.

[trustin]

I thought Transporter will be used everywhere so it could be part of core.

[dmlloyd]

Transporter should either be separate or be part of the API, one of the two... core won't be visible to end-user applications in a container situation.