[starksm64]

Can you set the output directory to target/classes via outputDirectory? Actually, they show that in the usage page:

"rmic plugin usage" wrote:

Including the stub classes in the main project jar

Output is by default written to the directory target/rmi-classes. Using this default behavior the stub classes will not be included in the main project artifact. To include the stubs in the main project jar the outputDirectory can be set to ${project.build.outputDirectory}.

Similarly, to include the stubs in the test jar the testOutputDirectory should be set to ${project.build.testOutputDirectory}

[adrian.brock]

Can you set the output directory to target/classes via outputDirectory? Actually, they show that in the usage page

Right, I thought I tried that, but I actually changed the classesDirectory
It must be Friday. ;-)

[adrian.brock]

Ive uploaded a 5.0.1-SNAPSHOT release if you want to try that Dimitris.
This release has the stub in the both the server and client jars.

I don't see the point in creating many GA point releases until you've
verified there are no other problems. ;-)

[adrian.brock]

The naming project looks very out-of-date in terms of the dependencies it using,
so we need to fix that as well for the 5.0.1.GA release.

[dimitris]

Ok, I'll test it and see also what dependecies we can update.

[dimitris]

The naming issue looks resolved, so I'll create a 5.0.0.SP1 for that.

BTW, now different issues show up, on of which is the missing jbossMQ classes, now that it was removed from trunk :-)

at org.jboss.test.jbossmq.test.JBossMQUnitTest.testQueueMessageOrder(JBossMQUnitTest.java:181)
at org.jboss.test.compatibility.test.matrix.MatrixTestContainer$TestProxy.run(MatrixTestContainer.java:185)
at org.jboss.test.compatibility.test.matrix.MatrixTestContainer$TestSuiteProxy.run(MatrixTestContainer.java:85)
Caused by: java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
java.lang.ClassNotFoundException: org.jboss.mq.referenceable.ObjectRefAddr (no security manager: RMI class loader disabled)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:162)
at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:713)
... 23 more
Caused by: java.lang.ClassNotFoundException: org.jboss.mq.referenceable.ObjectRefAddr (no security manager: RMI class loader disabled)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:371)
at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)

[adrian.brock]

BTW, now different issues show up, on of which is the missing jbossMQ classes, now that it was removed from trunk :-)

Which way around is this test?

I guess this is the 5.0.x testsuite (i.e. client side) running against a 4.2.x server?

The other way around wouldn't work either.
4.2.x doesn't include the jboss messaging jars. :-)

There's two likely solutions as far as I can see.
1) Disable the test for 5.0.x talking to older versions
(its still needed for future tests of JBoss Messaging compatiblity)
2) Include the jbossmq-client.jar from whatever version you are running against
when it is pre 5.0.x in the classpath

(2) Is what you would do for any other remote jms and it is also what
users will have to do if they want JBoss5 to use an older JBoss running jbossmq
as their JMS server.

Or a there's a third option which is to include a binary version
of jbossmq-client.jar from 4.2.x in the shared lib directory of JBoss5
to make things easier for users (although its not exactly rocket
for them to copy it across themselves. :-)

The downside of the third option is that it introduces a permenant dependency
on concurrent.jar (jbossmq still uses it) which I think we'd like to get rid of
at some point soon.

[adrian.brock]

2) Include the jbossmq-client.jar from whatever version you are running against
when it is pre 5.0.x in the classpath

(2) Is what you would do for any other remote jms and it is also what
users will have to do if they want JBoss5 to use an older JBoss running jbossmq
as their JMS server.

But this isn't testing very much in terms of compatiblity since you are running
with the same classes on both sides. ;-)

[slaboure]

so let's get rid of concurrent.jar in 6.x

[dimitris]

I have excluded the JBossMQ test from the 4_2_x matrix (AS5 client jars against AS42 server).

Now the issue that comes is this:
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-4.2.x-CompatibilityMatrix/245/testReport/org.jboss.test.compatibility.test.matrix/MatrixTestContainer(cmp2_5_0_x)/org_jboss_test_JBossTestCase$1/

java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is:
 java.io.InvalidClassException: org.jboss.security.auth.callback.SecurityAssociationHandler; class invalid for deserialization
 at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:282)
 at sun.rmi.transport.Transport$1.run(Transport.java:153)
 at java.security.AccessController.doPrivileged(Native Method)
 at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
 at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:466)
 at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:707)
 at java.lang.Thread.run(Thread.java:595)
Caused by: java.io.InvalidClassException: org.jboss.security.auth.callback.SecurityAssociationHandler; class invalid for deserialization
 at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:571)
 at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552)
 at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908)
 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
 at org.jboss.invocation.MarshalledInvocation.readExternal(MarshalledInvocation.java:665)
 at java.io.ObjectInputStream.readExternalData(ObjectInputStream.java:1755)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1717)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
 at sun.rmi.server.UnicastRef.unmarshalValue(UnicastRef.java:290)
 at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:279)
 ... 6 more

Somethings wrong with this class?
https://svn.jboss.org/repos/jbossas/projects/security/security-jboss-sx/trunk/jbosssx/src/main/java/org/jboss/security/auth/callback/SecurityAssociationHandler.java

[adrian.brock]

Somethings wrong with this class?
https://svn.jboss.org/repos/jbossas/projects/security/security-jboss-sx/trunk/jbosssx/src/main/java/org/jboss/security/auth/callback/SecurityAssociationHandler.java

No, but there is with this one. :-)
https://svn.jboss.org/repos/jbossas/branches/Branch_4_2/security/src/main/org/jboss/security/auth/callback/SecurityAssociationHandler.java

[anil.saldhana]

I am trying to remember why the handler was made serializable in AS5. There is no reason for it to be.

Dimitris, can we know from the test who is holding a reference to the handler? I will certainly try to locate it.

[anil.saldhana]

I am going to revert back the SecurityAssociationHandler to being non-serializable in AS5, in line with AS4.2

I am replacing all non-testsuite usage of SecurityAssociationHandler in AS5 with a new clone which is serializable called as JBossCallbackHandler. This will remove the conflicts with AS4.x

[anil.saldhana]

This should be fixed with security 2.0.2.SP3

To make the upgrade, we have to test AS.

Additionally, as/security/JNDIBasedSecurityRegistration should use transient callbackhandler (JBossCallbackHandler).

I will try this out later in the day today.

[anil.saldhana]

Dimitris, I have upgraded AS to use Security 2.0.2.SP3 and made the necessary changes in the AS/security module.

Please verify that the compatibility test is fixed.