[Design of AOP on JBoss (Aspects/JBoss)] - Re: Privileged Blocks Issue : JBAOP-675
by flavia.rainone＠jboss.com
"anil.saldhana(a)jboss.com" wrote : Is the call to AspectManager.getAdvisor happening from aop side or it is messaging aspect?
I think that the problem is still on the aop side. But I can't see what is wrong with that. Look at the piece of code below:
public synchronized ClassAdvisor getAdvisor(Class<?> clazz)
| {
| ClassAdvisor advisor = null;
| // See if one already exists
| advisor = (ClassAdvisor)findAdvisor(clazz);
| // if one does not
| if (advisor == null)
| {
| advisor = AdvisorFactory.getClassAdvisor(clazz, this);
| initialiseClassAdvisor(clazz, advisor);
| }
| return advisor;
| }
The line 707 is:
advisor = (ClassAdvisor)findAdvisor(clazz);
As the findAdvisor call doesn't appear at the stack, I would assume that the check is being performed for the casting. But this doesn't make any sense to me. Do you have any ideas?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191024#4191024
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191024
17 years, 4 months
[Design of POJO Server] - Re: Missing org.jnp.server.NamingServer_Stub
by scott.stark＠jboss.org
I thought this was no longer needed since jdk support dynamic proxies. Probably the classpath does not have the org.jnp.server.NamingServer. What jars are in the test classpath?
"java.rmi.server.UnicastRemoteObject javadoc" wrote :
| For the constructors and static exportObject methods below, the stub for a remote object being exported is obtained as follows:
|
| * If the remote object is exported using the UnicastRemoteObject.exportObject(Remote) method, a stub class (typically pregenerated from the remote object's class using the rmic tool) is loaded and an instance of that stub class is constructed as follows.
| o A "root class" is determined as follows: if the remote object's class directly implements an interface that extends Remote, then the remote object's class is the root class; otherwise, the root class is the most derived superclass of the remote object's class that directly implements an interface that extends Remote.
| o The name of the stub class to load is determined by concatenating the binary name of the root class with the suffix "_Stub".
| o The stub class is loaded by name using the class loader of the root class. The stub class must extend RemoteStub and must have a public constructor that has one parameter, of type RemoteRef.
| o Finally, an instance of the stub class is constructed with a RemoteRef.
| * If the appropriate stub class could not be found, or the stub class could not be loaded, or a problem occurs creating the stub instance, a StubNotFoundException is thrown.
|
| * For all other means of exporting:
|
| o If the remote object's stub class (as defined above) could not be loaded or the system property java.rmi.server.ignoreStubClasses is set to "true" (case insensitive), a Proxy instance is constructed with the following properties:
| + The proxy's class is defined by the class loader of the remote object's class.
| + The proxy implements all the remote interfaces implemented by the remote object's class.
| + The proxy's invocation handler is a RemoteObjectInvocationHandler instance constructed with a RemoteRef.
| + If the proxy could not be created, a StubNotFoundException will be thrown.
|
| o Otherwise, an instance of the remote object's stub class (as described above) is used as the stub.
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191023#4191023
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191023
17 years, 4 months
[Design of AOP on JBoss (Aspects/JBoss)] - Re: Privileged Blocks Issue : JBAOP-675
by flavia.rainone＠jboss.com
"anil.saldhana(a)jboss.com" wrote : I am saying that the privileged block should be in:
|
| | 23:22:07,503 ERROR [STDERR] at org.jboss.jms.client.delegate.ClientSessionDelegate.createMessage
| | (ClientSessionDelegate.java)
| |
Unless the problem is not with Class.getClassLoader call, it shouldn't be in the joinpoint wrapper, createMessage.
There are two good reasons for this. The first one is that the joinpointwrapper, createMessage, will trigger the Class.getClassLoader call only the first time it is reached on a per scope basis (given the aspect is a PER_INSTANCE one, it will be triggered the first time this method is run for each ClientSessionDelegate instance).
So, it is not fair to pay the extra performance price of running the joinpoint inside a privileged block just because it might need to trigger a Class.getClassLoader.
Secondly, I'm following the design decision that Kabir has made for the other points of JBoss AOP code. Kabir created SecurityActions classes that perform a few operations inside privileged blocks. When I want to call, for example, Class.getClassLoader, I am supposed to call SecurityActions.getClassLader(Class).
This method was already there, but it looks like some points of the new 2.0.0GA version mistakenly were invoking Class.getClassLoader instead of delegating to SecurityActions.
There is a new version of the jar attached at the Jira issue, now with all the points replaced. Please, test that jar and let me know if it works or if I missed some Class.getClassLoader call in the code.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191021#4191021
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191021
17 years, 4 months
[Design of AOP on JBoss (Aspects/JBoss)] - Re: Privileged Blocks Issue : JBAOP-675
by anil.saldhana＠jboss.com
| 13:40:46,501 ERROR [STDERR] java.lang.Exception: Stack trace
| 13:40:46,501 ERROR [STDERR] at java.lang.Thread.dumpStack(Thread.java:1158)
| 13:40:46,501 ERROR [STDERR] at java.security.AccessControlContext.checkPermission(AccessControlContext.java:253)
| 13:40:46,501 ERROR [STDERR] at java.security.AccessController.checkPermission(AccessController.java:427)
| 13:40:46,501 ERROR [STDERR] at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
| 13:40:46,501 ERROR [STDERR] at org.jboss.aop.AspectManager.getAdvisor(AspectManager.java:707)
| 13:40:46,501 ERROR [STDERR] at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.<clinit>(ConnectionAdvised.java)
| 13:40:46,501 ERROR [STDERR] at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegateInternal(ServerConnectionFactoryEndpoint.java:288)
| 13:40:46,501 ERROR [STDERR] at org.jboss.jms.server.endpoint.ServerConnectionFactoryEndpoint.createConnectionDelegate(ServerConnectionFactoryEndpoint.java:171)
| 13:40:46,501 ERROR [STDERR] at org.jboss.jms.server.endpoint.advised.ConnectionFactoryAdvised.org$jboss$jms$server$endpoint$advised$ConnectionFactoryAdvised$createConnectionDelegate$aop(ConnectionFactoryAdvised.java:108)
|
This is the error I am getting now. It is better than the previous. Is the call to AspectManager.getAdvisor happening from aop side or it is messaging aspect?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191020#4191020
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191020
17 years, 4 months
[Design of POJO Server] - Missing org.jnp.server.NamingServer_Stub
by dimitris＠jboss.org
We've introduced reverse compatibility tests (AS5 client accessing 4.2.x server) and one of the problems I'm seeing is the client AS5 side missing the org.jnp.server.NamingServer_Stub class.
It seem after jboss-naming was broken out we don't produce this class with RMIC anymore.
Why is that?
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-4.2.x-Comp...
| javax.naming.CommunicationException: Could not obtain connection to any of these urls: localhost:1099 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server localhost:1099 [Root exception is java.lang.ClassNotFoundException: org.jnp.server.NamingServer_Stub (no security manager: RMI class loader disabled)]]
| at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1727)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:680)
| at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:673)
| at javax.naming.InitialContext.lookup(InitialContext.java:351)
| at org.jboss.test.bmp.test.SmallCacheBmpUnitTestCase.testBMP(SmallCacheBmpUnitTestCase.java:46)
| at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
| at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
| at junit.extensions.TestSetup.run(TestSetup.java:23)
| 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: javax.naming.CommunicationException: Failed to connect to server localhost:1099 [Root exception is java.lang.ClassNotFoundException: org.jnp.server.NamingServer_Stub (no security manager: RMI class loader disabled)]
| at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:311)
| at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1698)
| ... 29 more
| Caused by: java.lang.ClassNotFoundException: org.jnp.server.NamingServer_Stub (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)
| at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197)
| at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
| 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.readObject(ObjectInputStream.java:348)
| at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
| at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:290)
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4191016#4191016
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4191016
17 years, 4 months
[Design of POJO Server] - MetaValue representation of javax.management.ObjectNames
by ips
In the Topic and Queue ManagedComponents, there are a couple properties, namely "DLQ" and "expiryQueue", whose values represent JMX ObjectNames. In destinations-service.xml, the values of these properties are represented as simple Strings, e.g.:
| <mbean code="org.jboss.jms.server.destination.QueueService"
| name="jboss.messaging.destination:service=Queue,name=QueueWithOwnDLQAndExpiryQueue"
| xmbean-dd="xmdesc/Queue-xmbean.xml">
| <annotation>@org.jboss.system.deployers.managed.ManagementObjectClass(code=org.jboss.jms.server.destination.QueueServiceMO)</annotation>
| <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
| <depends>jboss.messaging:service=PostOffice</depends>
| <attribute name="DLQ">jboss.messaging.destination:service=Queue,name=PrivateDLQ</attribute>
| <attribute name="ExpiryQueue">jboss.messaging.destination:service=Queue,name=PrivateExpiryQueue</attribute>
| </mbean>
|
However, the Profile Service represents the values using an unwieldy CompositeValue that contains several levels of nested CompositeValues and SimpleValues. Its MetaType looks like this (though this toString() representation only shows the first level of nested types):
| MutableCompositeMetaType{javax.management.ObjectName items=[name=MBeanServer type=javax.management.MBeanServer], [name=canonicalKeyPropertyListString type=java.lang.String], [name=canonicalName type=java.lang.String], [name=domain type=java.lang.String], [name=domainPattern type=java.lang.Boolean], [name=keyPropertyList type=java.util.Map],[name=keyPropertyListString type=java.lang.String], [name=pattern type=java.lang.Boolean], [name=propertyListPattern type=java.lang.Boolean],[name=propertyPattern type=java.lang.Boolean],[name=propertyValuePattern type=java.lang.Boolean]}
|
This makes it a lot more difficult to provide the ability to edit these properties via Jopr. Is there any chance their types can be changed to SimpleMetaType.STRING?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4190993#4190993
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4190993
17 years, 4 months