note to charles - if you prefix a bz number with "bug #" - bugzilla will display that as a link from right here in the comments view :)

see bug #759173

I wonder if bug #759615 could also be related to this

(In reply to comment #2)
> I wonder if bug #759615 could also be related to this

I would bet it is. I actually forgot about that utility I wrote. I'll rescan the libs. I was just working on this today and can confirm if we sign all the jars in the CLI lib/ the error still happens.

to replicate the problem:

1. Start the CLI and connect to RHQ server (rhq-cli.sh -u rhqadmin -p rhqadmin)
2. Locate an web-app for a Tomcat Server (in this example 10218)
2. Run the following commands:
 a. webapp = ProxyFactory.getResource(10218)
 b. webapp.retrieveBackingContent("/foo/bar.war")

It doesn't matter what path you put in for b. - if you see something to the effect of:

TypeError: Cannot find function retrieveBackingContent

the problem exists.

To test, you need to sign the jars (note, step 3 just confirms the keystore is OK):

1. keytool -genkey -keystore /tmp/myKeystore -alias myself
2. keytool -selfcert -alias myself -keystore /tmp/myKeystore
3. keytool -list -keystore /tmp/myKeystore
4. jarsigner -keystore /tmp/myKeystore <a jar file in /lib> myself

Repeat step 4 for all the jars in the CLI lib/ and run the replication steps and the problem will happen.

I ended up refactoring the org.rhq.core.server package name to
org.rhq.core.domain.server thinking
https://bugzilla.redhat.com/show_bug.cgi?id=759615#c1 is the cause.

But the problem is still showing up. I thought this was the magic bullet, but I
guess not.

(5:32:07 PM) ccrouch: mazz: so are you still seeing https://bugzilla.redhat.com/show_bug.cgi?id=759173#c9
(5:32:55 PM) ccrouch: that seems to describe the problem pretty succinctly
(5:32:59 PM) ccrouch: javassist.CannotCompileException: by java.lang.SecurityException: class "org.rhq.bindings.client.ResourceClientProxy5bc8d4d1a9859af5aab6a918a6d1029f0a8754cc60136a74fe735ef34d2ff4f1"'s
(5:35:15 PM) ccrouch: somewhere in the CLI we're using javassist to create classes, presumably extending ResourceClientProxy?, and the classes are being put in the wrong package
(5:36:16 PM) ccrouch: i.e. an existing package which has got signed stuff in it already
(5:36:16 PM) ccrouch: the classes just need to go into a different package
(5:44:51 PM) ccrouch: http://git.fedorahosted.org/git?p=rhq/rhq.git;a=blob;f=modules/enterprise/binding/src/main/java/org/rhq/bindings/client/ResourceClientFactory.java#l149
(5:46:39 PM) ccrouch: we shouldn't be using class.getName(), rather "org.rhq.our.new.random.package" + class.getSimpleName()

OK, yes, this CLI log clearly states the issue:

2012-03-30 09:45:03,610 ERROR [RHQ Client Prompt Input Thread] (org.rhq.bindings.client.ResourceClientFactory)- Could not create custom interface for resource with id 10218
javassist.CannotCompileException: by java.lang.SecurityException: class "org.rhq.bindings.client.ResourceClientProxye56bc7edadf38ce9e6deadd7f7b3e77a98baef002ed39ce37a04eb3b457d4c28"'s signer information does not match signer information of other classes in the same package
	at javassist.ClassPool.toClass(ClassPool.java:1035)
   ...
	at org.rhq.bindings.client.ResourceClientFactory.defineCustomInterface(ResourceClientFactory.java:205)
	at org.rhq.bindings.client.ResourceClientFactory.getResource(ResourceClientFactory.java:79)
   ...
	at java.lang.reflect.Method.invoke(Method.java:597)
   ...
	at com.sun.script.javascript.RhinoScriptEngine.eval(RhinoScriptEngine.java:167)
	at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:247)
	at org.rhq.enterprise.client.commands.ScriptCommand.execute(ScriptCommand.java:156)
	at org.rhq.enterprise.client.ClientMain.executePromptCommand(ClientMain.java:364)
	at org.rhq.enterprise.client.ClientMain$1.run(ClientMain.java:311)
	at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.SecurityException: class "org.rhq.bindings.client.ResourceClientProxye56bc7edadf38ce9e6deadd7f7b3e77a98baef002ed39ce37a04eb3b457d4c28"'s signer information does not match signer information of other classes in the same package
	at java.lang.ClassLoader.checkCerts(ClassLoader.java:806)
	...

master commit: 3266294b4768113f529df1d77b03e056579389e5

see comment #4 for replication procedures.

Pushing this to ONQA, any recent JON ER build should not be signed and would be 
suitable for testing this

Verified on 3.1.0.GA for eap5 and eap6. It was working for both signed and unsigned jars. Found bug #830841 during verification.

Bulk closing of old issues in VERIFIED state.