March 2008 - jboss-jira - Jboss List Archives

[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

17 years, 6 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

17 years, 6 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

17 years, 6 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

17 years, 6 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

17 years, 6 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

17 years, 6 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

17 years, 6 months

3
9
0 / 0

[JBoss JIRA] Created: (JBREM-922) Release 2.4.0.Beta2

by Ron Sigal (JIRA)

Release 2.4.0.Beta2 ------------------- Key: JBREM-922 URL: http://jira.jboss.com/jira/browse/JBREM-922 Project: JBoss Remoting Issue Type: Release Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta2 (Pinto) -- 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

17 years, 6 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1298) Removal of non-existent node leaves invalid tombstone on remote nodes

by Brian Stansberry (JIRA)

Removal of non-existent node leaves invalid tombstone on remote nodes --------------------------------------------------------------------- Key: JBCACHE-1298 URL: http://jira.jboss.com/jira/browse/JBCACHE-1298 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Optimistic Locking, Replication Reporter: Brian Stansberry Assigned To: Manik Surtani Fix For: 2.1.0.CR4 Problem with optimistic locking and invalidation: Say node with Fqn "/a" doesn't exist in memory in any cache in cluster. On node1, call to cache.removeNode("/a") is made. This is a valid call even though "/a" doesn't exist in the local cache -- caller wants it removed/invalidated across the cluster. This results in an invalidate() call around the cluster for "/a". Since "/a" doesn't exist, no DataVersion is passed with the call. On other nodes in the cluster, the invalidate() method detects that "/a" doesn't exist locally. So, invalidate() creates a tombstone for "/a". Tombstone gets initialized with a DefaultDataVersion. Since no other DataVersion was passed with the call, the tombstone gets left with that DefaultDataVersion. Now on node2 an attempt is made to do a put to "/a", passing in a DataVersion. The put fails with a version conflict due to the presence of the tombstone. InvalidationInterceptorTest.testAddOfDeletedNonExistent() shows the problem. This same issue is coming up in the Hibernate/JBC integration tests. -- 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

17 years, 6 months

2
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1206) Interceptors do not work on @WebService EJBs without @Remote, @Local, or @Service

by Ryan Carmichael (JIRA)

Interceptors do not work on @WebService EJBs without @Remote, @Local, or @Service --------------------------------------------------------------------------------- Key: EJBTHREE-1206 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1206 Project: EJB 3.0 Issue Type: Bug Components: interceptors Affects Versions: AS 4.2.2.GA Environment: JBoss Portal 2.6.4 (AS 4.2.2) on x86 Windows XP Sun JVM 1.5_09 Reporter: Ryan Carmichael EJB3 with @WebService and @Stateless only defined does not cause interceptors to be called. If you add @Remote, @Local, or @Service, everything works fine. The example code below does NOT cause the interceptor to be called. If you add "@Remote(TestWSIF.class)" under @Stateless, the interceptor works as expected. package org.example; import javax.ejb.Remote; import javax.ejb.Stateless; import javax.interceptor.Interceptors; import javax.jws.WebService; @WebService(serviceName="TestWS", portName="TestWSPort", endpointInterface="org.example.TestWSIF") @Stateless public class TestWS implements TestWSIF { @Interceptors(TestInterceptor.class) public void sayHello(String name) { System.out.println("Hello " + name); } } ------------------- package org.example; import javax.jws.WebService; @WebService public interface TestWSIF { public void sayHello(String name); } ------------------- package org.example; import javax.interceptor.AroundInvoke; import javax.interceptor.InvocationContext; public class TestInterceptor { @AroundInvoke public Object doStuff(InvocationContext ctx) throws Exception { System.out.println("Doing stuff"); return ctx.proceed(); } } -- 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

17 years, 6 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2008