December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAOP-416) Exclude tests testing new functionality from

by Kabir Khan (JIRA)

Exclude tests testing new functionality from --------------------------------------------- Key: JBAOP-416 URL: http://jira.jboss.com/jira/browse/JBAOP-416 Project: JBoss AOP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 1.5.6.GA, 2.0.0.alpha6 Once that is done, can you do me a favour? Kabir says: build.sh -f build-test-jdk50.xml clean-tests compile-test-classes precompiled-compatibility-tests Kabir says: It weaves with aop 1.5.5.GA and runs with AOP 2.0 Kabir says: some tests will fail, but most should pass Flávia says: Sure Kabir says: The tests that fail will hopefully be tests where we added some functionality in AOP 2.0 that does not exist in AOP 1.5.5.GA Kabir says: Ideally we need some way to exclude tests that are newer functionality than exists in the old version Kabir says: I'll add a JIRA for that Kabir says: since it would be good to get these automated Kabir says: I only remembered this since I spoke to Jason Green earlier about backward compatibility Flávia says: Yes. After all, we don't have a way of making new functionality work in JBAOP1.5 Kabir says: Thanks -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

2
19
0 / 0

[JBoss JIRA] Created: (JBAOP-405) IllegalAccessException when accessing a private field through reflection after call to Field.SetAccessable()

by Jason Hill (JIRA)

IllegalAccessException when accessing a private field through reflection after call to Field.SetAccessable() ------------------------------------------------------------------------------------------------------------ Key: JBAOP-405 URL: http://jira.jboss.com/jira/browse/JBAOP-405 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Environment: AOP Standalone Reporter: Jason Hill When a call to java.lang.reflect.Field.set() is intercepted by org.jboss.aop.reflection.ReflectionAspect, it invokes the original interceptor chain for the field instead of allowing the set call to run. Since the Field.set() function is never invoked, any previous calls to Field.setAccessable() have no affect. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

3
16
0 / 0

[JBoss JIRA] Created: (JBAOP-446) Get loadtime weaving working with jboss embedded

by Kabir Khan (JIRA)

Get loadtime weaving working with jboss embedded ------------------------------------------------ Key: JBAOP-446 URL: http://jira.jboss.com/jira/browse/JBAOP-446 Project: JBoss AOP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Fix For: 2.0.0.GA -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

1
9
0 / 0

[JBoss JIRA] Created: (JBAOP-422) Document advice matching involving generics

by Flavia Rainone (JIRA)

Document advice matching involving generics ------------------------------------------- Key: JBAOP-422 URL: http://jira.jboss.com/jira/browse/JBAOP-422 Project: JBoss AOP Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.0.0.alpha5 Reporter: Flavia Rainone Assigned To: Flavia Rainone Fix For: 2.1.0.GA We should add text explainingg in details how advice matching on genadvisor mode when dealing with generics. We have three major scenarios: - there is generics only on the joinpoint being intercepted - there is generics only on the advice/aspect class making the interception - there is generics on both the joinpoint and advice/aspect All three scenarios have to be explained in the documentation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

2
1
0 / 0

[JBoss JIRA] Created: (JBAOP-468) Add ManagedOperation metadata to AOP

by Kabir Khan (JIRA)

Add ManagedOperation metadata to AOP ------------------------------------ Key: JBAOP-468 URL: http://jira.jboss.com/jira/browse/JBAOP-468 Project: JBoss AOP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.0.0.GA Folllowing discussions in Neuchatel, what this will involve from our end is to have the full featureset of -aop.xml doable in a -beans.xml resulting in managed beans implementing everything -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

1
13
0 / 0

[JBoss JIRA] Created: (JBAOP-459) CLONE -Memory leaks (advanced)

by Kabir Khan (JIRA)

CLONE -Memory leaks (advanced) ------------------------------ Key: JBAOP-459 URL: http://jira.jboss.com/jira/browse/JBAOP-459 Project: JBoss AOP Issue Type: Task Affects Versions: 1.3.6 Reporter: Kabir Khan Fix For: 2.0.0.beta1 Need to resolve memory leaks for * AOP with generated weaving (domain per class) * AOP in scoped deployments (domain per scoped classloader) * standalone jboss-aop.xml files deployed in jboss (we will probably need to make the advisor clear itself from the woven class if "empty" following a rebind, and have something in the woven code to repopulate the classadvisor when executing the joinpoints) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

2
15
0 / 0

[JBoss JIRA] Created: (EJBTHREE-750) support xml overides/augmentations for WS annotations

by William DeCoste (JIRA)

support xml overides/augmentations for WS annotations ----------------------------------------------------- Key: EJBTHREE-750 URL: http://jira.jboss.com/jira/browse/EJBTHREE-750 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: EJB 3.0 RC9 - FD Reporter: William DeCoste Assigned To: William DeCoste For example, @PortComponent. See the org.jboss.test.ws.jaxws.samples.jsr181ejb test. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-3952) Problem with SerializableProxy when de-serializing in a remote client

by Frank Ulbricht (JIRA)

Problem with SerializableProxy when de-serializing in a remote client --------------------------------------------------------------------- Key: JBAS-3952 URL: http://jira.jboss.com/jira/browse/JBAS-3952 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3, Hibernate service Affects Versions: JBossAS-4.0.5.GA Environment: Windows Vista and Windows XP, Java 1.5.0 Update 10 and Java 1.6.0 Reporter: Frank Ulbricht Assigned To: Bill Burke After calling a SessionBean method that returns an entity with a lazy relation there is an problem with de-serialization on the client side. The lazy field cannot not be assigned because of a ClassCastException. In other projects the same happens after a method returns the result of a query where lazy fields are involved. The problem occurs only with lazy fields. The is a simple test case attached with the problem code line marked. Here is the complete stacktrace: java.lang.reflect.UndeclaredThrowableException at $Proxy6.updateAddress(Unknown Source) at com.qualitype.testcase.client.RemoteClientTestCase.test(RemoteClientTestCase.java:48) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.junit.internal.runners.TestMethodRunner.executeMethodBody(TestMethodRunner.java:99) at org.junit.internal.runners.TestMethodRunner.runUnprotected(TestMethodRunner.java:81) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:71) at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35) at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: java.rmi.MarshalException: Failed to communicate. Problem during marshalling/unmarshalling; nested exception is: java.lang.ClassCastException: cannot assign instance of org.hibernate.proxy.pojo.javassist.SerializableProxy to field com.qualitype.testcase.entity.Address.person of type com.qualitype.testcase.entity.Person in instance of com.qualitype.testcase.entity.Address at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:306) at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143) at org.jboss.remoting.Client.invoke(Client.java:525) at org.jboss.remoting.Client.invoke(Client.java:488) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:55) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:77) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102) ... 22 more Caused by: java.lang.ClassCastException: cannot assign instance of org.hibernate.proxy.pojo.javassist.SerializableProxy to field com.qualitype.testcase.entity.Address.person of type com.qualitype.testcase.entity.Person in instance of com.qualitype.testcase.entity.Address at java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(Unknown Source) at java.io.ObjectStreamClass.setObjFieldValues(Unknown Source) at java.io.ObjectInputStream.defaultReadFields(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:122) at java.io.ObjectInputStream.readExternalData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.defaultReadFields(Unknown Source) at java.io.ObjectInputStream.readSerialData(Unknown Source) at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:128) at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:66) at org.jboss.remoting.transport.socket.SocketClientInvoker.transport(SocketClientInvoker.java:279) ... 34 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

5
6
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1734) "edit mode" could be checked for authorization

by Thomas Heute (JIRA)

"edit mode" could be checked for authorization ---------------------------------------------- Key: JBPORTAL-1734 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1734 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal Core Reporter: Thomas Heute Assigned To: Julien Viet Fix For: 2.8 Final An admin should be able to define which roles have access to the edit mode for a particular portlet. Since it would break backward compatibility, it has to be part of a major release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1214) drools-server should not have .settings commited into svn

by Geoffrey De Smet (JIRA)

drools-server should not have .settings commited into svn --------------------------------------------------------- Key: JBRULES-1214 URL: http://jira.jboss.com/jira/browse/JBRULES-1214 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-brms Affects Versions: 4.0.1 Reporter: Geoffrey De Smet Assigned To: Mark Proctor Priority: Trivial Fix For: FUTURE See JBRULES-834. As far as I can tell, the commit of /drools-server/.settings is an error because the other server modules explicitly svn:ignore the .settings directory. The svn ignore was probably forgotten, which might have given our good friend eclipse the opportunity to commit it. I could be wrong though. If I am right though, the .settings directory should be deleted in svn, which will cause havoc when everyone updates who's relying on .settings in drools-server, and the svn:ignore should be edited to contain these 3 items: .metadata .settings .wtpmodules This way it uses standardized svn ignores just like the other modules. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 6 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2007