March 2008 - jboss-jira - Jboss List Archives

[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, 10 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBBUILD-458) Create thirdparty repo based on scopes

by Paul Gier (JIRA)

Create thirdparty repo based on scopes -------------------------------------- Key: JBBUILD-458 URL: http://jira.jboss.com/jira/browse/JBBUILD-458 Project: JBoss Build System Issue Type: Feature Request Components: maven-buildmagic-thirdparty-plugin Reporter: Paul Gier Fix For: maven-buildmagic-thirdparty-plugin-2.0 Enable creation of different thirdparty downloads and libraries.ent files based on different scopes. -- 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, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-825) Verify that CoyoteInvoker works with Apache Portable Runtime

by Ron Sigal (JIRA)

Verify that CoyoteInvoker works with Apache Portable Runtime ------------------------------------------------------------ Key: JBREM-825 URL: http://jira.jboss.com/jira/browse/JBREM-825 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Trustin Lee The http transport - org.jboss.remoting.transport.coyote.CoyoteInvoker, in particular - now works with either jbossweb.jar or the tomcat jars. When the APR native libraries are deposited in a directory on the system path on a Windows machine, the http transport tests run successfully, but the https tests fail: 21:10:14,906 DEBUG [main] [HTTPClientInvoker] Error invoking http client invoker. javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(Unknown Source) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(Unknown Source) at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:276) at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:136) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:123) at org.jboss.remoting.Client.invoke(Client.java:1632) at org.jboss.remoting.Client.invoke(Client.java:548) at org.jboss.test.remoting.transport.http.ssl.basic.HTTPSInvokerTestClient.testInvocationWithHeaders(HTTPSInvokerTestClient.java:77) 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 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 junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) 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) Caused by: java.io.EOFException: SSL peer shut down incorrectly at com.sun.net.ssl.internal.ssl.InputRecord.read(Unknown Source) ... 31 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

17 years, 10 months

2
5
0 / 0

[JBoss JIRA] Commented: (JBMESSAGING-153) Support for very large messages

by Tim Fox (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-153?page=comments#action_12... ] Tim Fox commented on JBMESSAGING-153: ------------------------------------- Yes, 2.0 will support very large messages (multi-gigabyte) > Support for very large messages > ------------------------------- > > Key: JBMESSAGING-153 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-153 > Project: JBoss Messaging > Issue Type: Feature Request > Components: Messaging Core > Affects Versions: 1.0.0 alpha PR3 > Reporter: Karl de Boer > Fix For: 2.0.0 Beta > > Original Estimate: 4 minutes > Remaining Estimate: 4 minutes > > As dicussed during JBW Barcelona i want to ask to investigate if it is posible to reliably sent very big messages from one jboss messaging node to another one (most likely on top of HTTPS(S). The business case is: mulitple organisations working in one workflow on digitally signed documents where Quality of Service is extremely important for instance patent applications. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-5274) Default log4j conversion pattern should log Thread name

by Galder Zamarreno (JIRA)

Default log4j conversion pattern should log Thread name ------------------------------------------------------- Key: JBAS-5274 URL: http://jira.jboss.com/jira/browse/JBAS-5274 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Logging Reporter: Galder Zamarreno Assigned To: Galder Zamarreno Fix For: JBossAS-5.0.0.CR1 >From a support point of view, I often find myself asking users/customers to enable the full conversion pattern in the server.log's log4j appender in order to get a better idea of what each thread is doing. I suggest that we add %t to the default conversion pattern to to speed up problem resolution. The server.log is already verbose enough and few of our users/customers understand it, so I wouldn't expect such change to have a major impact on our users/customers:  <param name="ConversionPattern" value="%d %-5p [%c] (%t) %m%n"/> -- 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, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-899) Verify sslservlet transport works with jbossweb

by Ron Sigal (JIRA)

Verify sslservlet transport works with jbossweb ----------------------------------------------- Key: JBREM-899 URL: http://jira.jboss.com/jira/browse/JBREM-899 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.4.1.Beta Reporter: Ron Sigal Fix For: 2.4.0.CR1 (Pinto) Unlike tomcat, jbossweb uses openssl for authentication. Need to create suitable certificate files and run sslservlet unit 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, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JBBUILD-454) Add new mojo to jboss deploy plugin that can create a thirdparty folder from pom dependnecies.

by Paul Gier (JIRA)

Add new mojo to jboss deploy plugin that can create a thirdparty folder from pom dependnecies. ---------------------------------------------------------------------------------------------- Key: JBBUILD-454 URL: http://jira.jboss.com/jira/browse/JBBUILD-454 Project: JBoss Build System Issue Type: Feature Request Components: maven-jboss-deploy-plugin Reporter: Paul Gier Fix For: maven-jboss-deploy-plugin-1.7 The app server build needs to be able to reproduce the thirdparty folder using artifacts downloaded from the maven repository. -- 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, 10 months

1
2
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1204) hibernate-client.jar should contain AbstractComponentType and all Type implementations

by Sergey Koshcheyev (JIRA)

hibernate-client.jar should contain AbstractComponentType and all Type implementations -------------------------------------------------------------------------------------- Key: EJBTHREE-1204 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1204 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: AS 4.2.2.GA Reporter: Sergey Koshcheyev Proxies of entities with composite identifiers make use of AbstractComponentType so it should be included in the client jar. Since AbstractComponentType can contain properties of other types, all org.hibernate.Type implementations should probably be included as well. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBMESSAGING-153) Support for very large messages

by lepe (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-153?page=comments#action_12... ] lepe commented on JBMESSAGING-153: ---------------------------------- Will this be done in 2.0? /L Redpill > Support for very large messages > ------------------------------- > > Key: JBMESSAGING-153 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-153 > Project: JBoss Messaging > Issue Type: Feature Request > Components: Messaging Core > Affects Versions: 1.0.0 alpha PR3 > Reporter: Karl de Boer > Fix For: 2.0.0 Beta > > Original Estimate: 4 minutes > Remaining Estimate: 4 minutes > > As dicussed during JBW Barcelona i want to ask to investigate if it is posible to reliably sent very big messages from one jboss messaging node to another one (most likely on top of HTTPS(S). The business case is: mulitple organisations working in one workflow on digitally signed documents where Quality of Service is extremely important for instance patent applications. -- 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, 10 months

1
0
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