March 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMDR-10) Move the primitive handling from MetaData/Signature into PrimitiveInfo

by Adrian Brock (JIRA)

Move the primitive handling from MetaData/Signature into PrimitiveInfo ---------------------------------------------------------------------- Key: JBMDR-10 URL: http://jira.jboss.com/jira/browse/JBMDR-10 Project: JBoss MetaData Repository Issue Type: Task Components: General Affects Versions: JBossMDR-2.0.0.CR1 Reporter: Adrian Brock Assigned To: Adrian Brock The primitive handling should be in the reflection project. The existing public method will have to just delegate for backwards compatibility. -- 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

18 years, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREFLECT-18) Move the primitive handling from MetaData/Signature into PrimitiveInfo

by Adrian Brock (JIRA)

Move the primitive handling from MetaData/Signature into PrimitiveInfo ---------------------------------------------------------------------- Key: JBREFLECT-18 URL: http://jira.jboss.com/jira/browse/JBREFLECT-18 Project: JBoss Reflection Issue Type: Task Components: ClassInfo Affects Versions: JBossReflection.2.0.0.CR1 Reporter: Adrian Brock Assigned To: Adrian Brock The Signature class in MetaData is doing stuff that should be in PrimitiveInfo in the reflection abstraction. -- 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

18 years, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREFLECT-17) Move the javabean parsing into the JBossXB project

by Adrian Brock (JIRA)

Move the javabean parsing into the JBossXB project -------------------------------------------------- Key: JBREFLECT-17 URL: http://jira.jboss.com/jira/browse/JBREFLECT-17 Project: JBoss Reflection Issue Type: Task Components: JavaBean Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossReflection.2.0.0.CR1 Move the javabean parsing into JBossXB to break the circular dependency -- 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

18 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4434) Create tests of file locking in the deploy dir

by Brian Stansberry (JIRA)

Create tests of file locking in the deploy dir ---------------------------------------------- Key: JBAS-4434 URL: http://jira.jboss.com/jira/browse/JBAS-4434 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Brian Stansberry Need simple tests where different sorts of deployments are copied to deploy, allowed to deploy, and then deleted. Intent is to prove that the file in the deploy dir can be deleted; i.e. the deployment process doesn't create a file lock. Most AS tests today do deployments via the RMIAdaptor, an approach that doesn't detect file lock issues. See JBAS--4415 and EJBTHREE-969 for an example of where this broke down. The FarmService tests have to use a 'copy file to farm dir' approach, so they detected a file lock issue. But this kind of problem should be directly tested so it's easier to know when problems like EJBTHREE-969 creep in. Also the FarmService test only deploys one jar; if by chance it had been a war instead of an ejb jar, the problem would not have been detected, since the JBossWeb deployer would have handled the war before accepts() was called on the Ejb3Deployer. -- 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

18 years, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1300) Standardize mechanism for setting defaultClassLoader

by Brian Stansberry (JIRA)

Standardize mechanism for setting defaultClassLoader ---------------------------------------------------- Key: JBCACHE-1300 URL: http://jira.jboss.com/jira/browse/JBCACHE-1300 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Manik Surtani Priority: Minor Right now the default classloader used by the cache's marshaller is fixed to CacheImpl.class.getClassLoader(), with no clear mechanism for users to change that. In the Hibernate/JBC testsuite I did the following: public class CustomClassLoaderCacheFactory<K, V> extends DefaultCacheFactory<K, V> { private ClassLoader customClassLoader; public CustomClassLoaderCacheFactory(ClassLoader customClassLoader) { this.customClassLoader = customClassLoader; } @Override protected void bootstrap(CacheImpl cache, CacheSPI spi, Configuration configuration) { super.bootstrap(cache, spi, configuration); // Replace the deployerClassLoader componentRegistry.registerComponent("deployerClassLoader", customClassLoader, ClassLoader.class); } } That works, but seems fragile, e.g .if how super.bootstrap() works changes it could break. It would be better to have something more standardized; perhaps a property on DefaultCacheFactory that could be set, w/ a guarantee in the DefaultCacheFactory javadoc that it will be used if set. Or something else. :-) Manik, not sure where you're planning to go w/ defaultClassLoader; I'm just throwing this request out there to get the topic in JIRA. OT: doing this is great in testsuites, as you can use it to configure a default classloader that can't see some of your test classes, and thus test marshalling. -- 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

18 years, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (JBXB-128) @JBossXmlGroupText doesn't process attributes on the wrapper

by Adrian Brock (JIRA)

@JBossXmlGroupText doesn't process attributes on the wrapper ------------------------------------------------------------ Key: JBXB-128 URL: http://jira.jboss.com/jira/browse/JBXB-128 Project: JBoss XML Binding (JBossXB) Issue Type: Bug Affects Versions: JBossXB-2.0.0.CR6 Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossXB-2.0.0.CR7 The @JBossXMLGroupText annotation doesn't work as expected since it doesn't process annotations on the wrapper. This is because the wrapper is only being used to create an object around the object returned from the TypeBinding's CharactersHandler. This is after the attributes are processsed. It needs to be done as a BeanAdapter. -- 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

18 years, 4 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-698) Update Remoting Marshaller/UnMarshallers to implement PreferredStreamMarshaller/PreferredStreamUnMarshaller interfaces.

by Ron Sigal (JIRA)

Update Remoting Marshaller/UnMarshallers to implement PreferredStreamMarshaller/PreferredStreamUnMarshaller interfaces. ----------------------------------------------------------------------------------------------------------------------- Key: JBREM-698 URL: http://jira.jboss.com/jira/browse/JBREM-698 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta2 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.0.Beta2 (Bluto) In response to JBREM-692 the org.jboss.remoting.marshal.PreferredStreamMarshaller and org.jboss.remoting.marshal.PreferredStreamUnMarshaller interfaces were introduced, and org.jboss.remoting.marshal.serializable.SerializableMarshaller and org.jboss.remoting.marshal.serializable.SerializableUnMarshaller were modified to implement them. In particular, they implement a getMarshallingStream() method which returns an object stream that can be cached and reused by the transport layer. Now, the other Remoting marshallers (http, compressing, encrypting) should also be made to implement those interfaces. -- 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

18 years, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (JBREM-764) Wire version should be configurable per client or server

by Ron Sigal (JIRA)

Wire version should be configurable per client or server -------------------------------------------------------- Key: JBREM-764 URL: http://jira.jboss.com/jira/browse/JBREM-764 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) Currently org.jboss.remoting.Version looks to the system property "jboss.remoting.version" to determine the value to return for Version.getDefaultVersion(), and the transports refer to Version.getDefaultVersion(). This means that all clients and servers in a JVM use the same version. It would be preferable to allow the wire version to configurable as a parameter to each client and server. -- 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

18 years, 4 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-716) Reduce log output from test suite

by Ron Sigal (JIRA)

Reduce log output from test suite --------------------------------- Key: JBREM-716 URL: http://jira.jboss.com/jira/browse/JBREM-716 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Beta2 (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Minor Fix For: 2.2.0.Beta2 (Bluto) Looks like jdk 1.5 test suite on cruisecontrol didn't produce a report. Maybe it ran out of memory. -- 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

18 years, 4 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-665) Need better error reporting of response marshalling errors

by Scott M Stark (JIRA)

Need better error reporting of response marshalling errors ---------------------------------------------------------- Key: JBREM-665 URL: http://jira.jboss.com/jira/browse/JBREM-665 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.0.Alpha4 Reporter: Scott M Stark Assigned To: Tom Elrod A failure to write a response on the server such as: 21:03:32,935 ERROR [ServerThread] failed to process invocation. java.io.NotSerializableException: java.util.HashMap$KeySet at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1081) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302) at org.jboss.aop.joinpoint.InvocationResponse.writeExternal(InvocationResponse.java:101) at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1310) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1288) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302) at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:85) at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:84) at org.jboss.invocation.unified.marshall.InvocationMarshaller.write(InvocationMarshaller.java:66) at org.jboss.remoting.transport.socket.ServerThread.versionedWrite(ServerThread.java:491) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:470) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:527) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:261) results in this uninformative exception on the client: java.rmi.MarshalException: Failed to communicate. Problem during marshalling/unmarshalling; nested exception is: ... Caused by: java.net.SocketException at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:352) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:125) at org.jboss.remoting.Client.invoke(Client.java:589) at org.jboss.remoting.Client.invoke(Client.java:581) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74) 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 AOPProxy$1.getTemplateNames(AOPProxy$1.java) at org.jboss.test.profileservice.test.ProfileServiceUnitTestCase.testAddDataSource(ProfileServiceUnitTestCase.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128) 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) at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:74) ... 23 more Need to look at how this can be improved. -- 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

18 years, 4 months

3
9
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2008