[JBoss-dev] Re: [jboss-cvs] repository.jboss.com/jboss/remoting/1.4.2.GA-patch1/lib ...
Per http://jira.jboss.com/jira/browse/JBAS-3208, this has been resolved. Dimitris Andreadis wrote: A couple of days ago Telrod modifed JBossRemoting to fix a dubious warning in SerializationStreamFactory, and re-checked this in as jboss remoting 1.4.2.GA Now Bill, made some change in remoting to produce a patch version, but Telrod's change is missing. What's happened? Wasn't Tom's version tagged (including the change) with 1.4.2.GA? Or Bill produced a patch from the wrong sources? We don't even need a patch version here. We can just patch, re-tag, and override the 1.4.2.GA, nobody else except JBAS is using this now. But we need to make sure both Tom's change and Bill's patch are there. Tom can you help? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Burke Sent: 11 May, 2006 23:30 To: [EMAIL PROTECTED] Subject: [jboss-cvs] repository.jboss.com/jboss/remoting/1.4.2.GA-patch1/lib ... User: bill Date: 06/05/11 16:29:39 Added: jboss/remoting/1.4.2.GA-patch1/lib jboss-remoting.jar Log: jboss-remoting patch for ObjectInputStreamWithClassloader Revision ChangesPath 1.1 date: 2006/05/11 20:29:39; author: bill; state: Exp;repository.jboss.com/jboss/remoting/1.4.2.GA-patch1/lib/jb oss-remoting.jar Binary file --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057; dat=121642 ___ jboss-cvs-commits mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-cvs-commits --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Problem with minimal config in Branch_4_0
Not really. The SerializationStreamFactory will try to statically load both java and jboss serialization. There is a try/catch around the loading of the jboss serialization, but only catches Exception. However, when tries to load it and JBossObjectOutputStream is not found, throws a NoClassDefFoundError, which is an error (which extends Throwable, not Exception) so causes Naming to not be deployed. So can either add the jboss serialization classes (JBossObjectOutputStream imports a lot of the other jboss serialization classes) or change this within SerializationStreamFactory so catches throwable and allows processing to continue (but is going to require another remoting release). Dimitris Andreadis wrote: I meant actually used by remoting in this setup, sorry. -Original Message- From: Dimitris Andreadis Sent: 04 May, 2006 23:34 To: Tom Elrod Cc: Scott M Stark; Clebert Suconic; QA; jboss-development@lists.sourceforge.net Subject: RE: Problem with minimal config in Branch_4_0 Is JBossSerialization actually, or this is just the API, in which case you can just bundle the missing classes? JBossSerialization is about 121Kb, and jboss-minimal 190kb. -Original Message- From: Tom Elrod Sent: 04 May, 2006 22:48 To: Dimitris Andreadis Cc: Scott M Stark; Clebert Suconic; Tom Elrod; QA; jboss-development@lists.sourceforge.net Subject: Re: Problem with minimal config in Branch_4_0 I have locally changed server/build.xml to include the 15 classes needed from remoting into the jboss-minimal.jar. However, is going to still need jboss serialization classes (see below). Should jboss-serialization.jar be added to minimal lib directory? 14:14:29,494 INFO [NamingService] JNDI bootstrap JNP=/0.0.0.0:1099, RMI=/0.0.0.0:1098, backlog=50, no client SocketFactory, Server SocketFactory=class org.jboss.net.sockets.DefaultSocketFactory 14:14:29,524 WARN [ServiceController] Problem starting service jboss:service=Naming java.lang.NoClassDefFoundError: org/jboss/serial/io/JBossObjectOutputStream at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:1610) at java.lang.Class.getConstructor0(Class.java:1922) at java.lang.Class.newInstance0(Class.java:278) at java.lang.Class.newInstance(Class.java:261) at org.jboss.remoting.serialization.SerializationStreamFactory.lo adObjectManagerClass(Serial izationStreamFactory.java:139) Dimitris Andreadis wrote: http://jira.jboss.com/jira/browse/JBAS-3171 -Original Message- From: Scott M Stark Sent: 02 May, 2006 07:34 To: Clebert Suconic; Tom Elrod Cc: Dimitris Andreadis; QA; 'jboss-development@lists.sourceforge.net' Subject: RE: Problem with minimal config in Branch_4_0 Ok, this package already is in the jboss-minmal.jar -Original Message- From: Clebert Suconic Sent: Monday, May 01, 2006 9:20 PM To: Scott M Stark; Tom Elrod Cc: Dimitris Andreadis; QA; 'jboss-development@lists.sourceforge.net' Subject: RE: Problem with minimal config in Branch_4_0 Eh eh... sorry, I should have been clearer. There is an implementation under org.jboss.invocation.unified package. If that package is available under the minimal configuration, we don't need to add the streaming Tom mentioned. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Problem with minimal config in Branch_4_0
I have updated the jboss-remoting.jar (1.4.2.GA) to include code change to org.jboss.remoting.serialization.SerializationStreamFactory where in it's static block of loading serialization managers, if the jboss serialization manager is not found, will write out warning to log and proceed. If someone were to explicitly try to use jboss serialization (instead of java, which is the default), will get an error at that point in time. The 4.0 branch's minimal is now starting up. Dimitris Andreadis wrote: What is the algorithm to decide which serialization manager to use? Is there a flag to override the choice? If the choice is to explicitly use JBossSerialization and it cannot be loaded, then that's an error to be reported. If the choice is JavaSerialization, then you shoulnd't even attempt to load JBossSerialization. If the choice is auto then try JBossSerialization and silently fallback to JavaSerialization, if it cannot be loaded. Maybe report the chosen implementation as debug/info. So I think it would be better to fix this and re-release, rathen than bundling more jboss serialization classes. You can override the existing jboss remoting 1.4.2.GA, since nobody is using it yet. Does this make sense? -Original Message- From: Tom Elrod Sent: 05 May, 2006 04:38 To: Dimitris Andreadis Cc: Tom Elrod; Scott M Stark; Clebert Suconic; QA; jboss-development@lists.sourceforge.net Subject: Re: Problem with minimal config in Branch_4_0 Not really. The SerializationStreamFactory will try to statically load both java and jboss serialization. There is a try/catch around the loading of the jboss serialization, but only catches Exception. However, when tries to load it and JBossObjectOutputStream is not found, throws a NoClassDefFoundError, which is an error (which extends Throwable, not Exception) so causes Naming to not be deployed. So can either add the jboss serialization classes (JBossObjectOutputStream imports a lot of the other jboss serialization classes) or change this within SerializationStreamFactory so catches throwable and allows processing to continue (but is going to require another remoting release). --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: JBAS 4.0.4.GA project dependencies
- JBossRemoting, (a) the version number shouldn't be 1.4.2.GA ??. Second, I don't see any dependency in its component-info.xml on JBossRemoting ? Don't understand what you mean by the second point. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: JBAS 4.0.4.GA project dependencies
Remoting changed to be 1.4.2.GA (as well as ws references) Dimitris Andreadis wrote: This is the current jboss project dependencies on JBoss 4.0.4.GA componentref name=jboss/aop version=1.5.0-snapshot/ componentref name=jboss/backport-concurrent version=2.1.0.GA/ componentref name=jboss/cache version=1.2.4.SP2/ componentref name=jboss/microcontainer version=1.0.2/ componentref name=jboss/jbossretro version=1.0.0.CR1/ componentref name=jboss/jbossws version=1.0.0.GA/ componentref name=jboss/jbossws14 version=1.0.0.GA/ componentref name=jboss/jbossxb version=snapshot/ componentref name=jboss/remoting version=1.4.2/ componentref name=jboss/serialization version=1.0.0.GA/ Issues/Tasks: - We need AOP release 1.5.0.GA, Kabir will release it early next week. - Scott has produced JBossRetro 1.0.0.GA (http://jira.jboss.com/jira/browse/JBAS-3108), that tidied up the retro jars. Can we just update the build/build-thirdparty.xml, or is there anything (webservices?) that needs rebuild? - JBossAS/WebServices are still on JBossXB snapshot which is actually jbossxb 1.0.0.CR4. Can we safely update both, since 1.0.0.CR4 is the version that will be used, or Alexey wants to make this 1.0.0.GA ? - JBossRemoting, (a) the version number shouldn't be 1.4.2.GA ??. Second, I don't see any dependency in its component-info.xml on JBossRemoting ? - WebServices recap - 1.0.0.GA needs update to, jbossretro 1.0.0.GA, jbossxb 1.0.0.CR4 (or GA), and remoting 1.4.2.GA, we is ready. - EJB3 should really be standalone for the next release, right? If there are other issues, let us know! Please, be prepared to help in case integration issues arise in jboss 4.0.4.GA, we just have a week left. Thanks all /Dimitris --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: JBAS 4.0.4.GA project dependencies
Well, if using jboss serialization, there is a dependency. However, this is not the default (java serialization is). So should I include it if there *may* be a dependency on it? Clebert Suconic wrote: Maybe Dimitris meant JBossRemoting should have a dependency on JBossSerialization 1.0.0.GA declared -Original Message- From: Tom Elrod Sent: Thursday, May 04, 2006 9:34 AM To: Dimitris Andreadis Cc: Scott M Stark; Adrian Brock; Kabir Khan; Alexey Loubyansky; Thomas Diesler; Tom Elrod; Clebert Suconic; jboss-development@lists.sourceforge.net; QA Subject: Re: JBAS 4.0.4.GA project dependencies - JBossRemoting, (a) the version number shouldn't be 1.4.2.GA ??. Second, I don't see any dependency in its component-info.xml on JBossRemoting ? Don't understand what you mean by the second point. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: JBAS 4.0.4.GA project dependencies
Ok. Have changed to following now: project name=jboss/remoting-component-info !-- -- !-- JBOSS REMOTING -- !-- -- component id=jboss/remoting licenseType=lgpl version=1.4.2.GA projectHome=http://www.jboss.org/products/remoting; description=a single API for most network based invocations and related service that uses pluggable transports and data marshallers artifact id=jboss-remoting.jar/ import componentref=jboss/serialization compatible version=1.0.0.GA/ /import export include input=jboss-remoting.jar/ /export /component /project Dimitris Andreadis wrote: I think it should be declared, even if not configured by default, so a possible version conflict with other components using a different version of JBossSerialization can be detected. -Original Message- From: Tom Elrod Sent: 04 May, 2006 21:39 To: Clebert Suconic Cc: Tom Elrod; Dimitris Andreadis; Scott M Stark; Adrian Brock; Kabir Khan; Alexey Loubyansky; Thomas Diesler; jboss-development@lists.sourceforge.net; QA Subject: Re: JBAS 4.0.4.GA project dependencies Well, if using jboss serialization, there is a dependency. However, this is not the default (java serialization is). So should I include it if there *may* be a dependency on it? Clebert Suconic wrote: Maybe Dimitris meant JBossRemoting should have a dependency on JBossSerialization 1.0.0.GA declared -Original Message- From: Tom Elrod Sent: Thursday, May 04, 2006 9:34 AM To: Dimitris Andreadis Cc: Scott M Stark; Adrian Brock; Kabir Khan; Alexey Loubyansky; Thomas Diesler; Tom Elrod; Clebert Suconic; jboss-development@lists.sourceforge.net; QA Subject: Re: JBAS 4.0.4.GA project dependencies - JBossRemoting, (a) the version number shouldn't be 1.4.2.GA ??. Second, I don't see any dependency in its component-info.xml on JBossRemoting ? Don't understand what you mean by the second point. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Problem with minimal config in Branch_4_0
I have locally changed server/build.xml to include the 15 classes needed from remoting into the jboss-minimal.jar. However, is going to still need jboss serialization classes (see below). Should jboss-serialization.jar be added to minimal lib directory? 14:14:29,494 INFO [NamingService] JNDI bootstrap JNP=/0.0.0.0:1099, RMI=/0.0.0.0:1098, backlog=50, no client SocketFactory, Server SocketFactory=class org.jboss.net.sockets.DefaultSocketFactory 14:14:29,524 WARN [ServiceController] Problem starting service jboss:service=Naming java.lang.NoClassDefFoundError: org/jboss/serial/io/JBossObjectOutputStream at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:1610) at java.lang.Class.getConstructor0(Class.java:1922) at java.lang.Class.newInstance0(Class.java:278) at java.lang.Class.newInstance(Class.java:261) at org.jboss.remoting.serialization.SerializationStreamFactory.loadObjectManagerClass(Serial izationStreamFactory.java:139) Dimitris Andreadis wrote: http://jira.jboss.com/jira/browse/JBAS-3171 -Original Message- From: Scott M Stark Sent: 02 May, 2006 07:34 To: Clebert Suconic; Tom Elrod Cc: Dimitris Andreadis; QA; 'jboss-development@lists.sourceforge.net' Subject: RE: Problem with minimal config in Branch_4_0 Ok, this package already is in the jboss-minmal.jar -Original Message- From: Clebert Suconic Sent: Monday, May 01, 2006 9:20 PM To: Scott M Stark; Tom Elrod Cc: Dimitris Andreadis; QA; 'jboss-development@lists.sourceforge.net' Subject: RE: Problem with minimal config in Branch_4_0 Eh eh... sorry, I should have been clearer. There is an implementation under org.jboss.invocation.unified package. If that package is available under the minimal configuration, we don't need to add the streaming Tom mentioned. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Problem with minimal config in Branch_4_0
They are not broken out in terms of jar currently (all in one jar). However, the org.jboss.remoting.serialization package can be broken out, but will need to include org.jboss.remoting.loading.ObjectInputStreamWithClassLoader as well. Scott M Stark wrote: It does not make sense to add the full remoting jar as there is no dependency on this other than the serialization classes. This comes back to the fact that org/jboss/invocation needs to be refactored into a separate legacy remoting jar, and org.jboss.remoting.serialization included in it or broken out. For now the minimal jar should just include the org.jboss.remoting.serialization package classes. These are self container aren't they? -Original Message- From: Tom Elrod Sent: Friday, April 28, 2006 8:47 AM To: Dimitris Andreadis Cc: QA; jboss-development@lists.sourceforge.net; Clebert Suconic; Tom Elrod Subject: Re: Problem with minimal config in Branch_4_0 The problem stems from NamingService using MarshalledInvocation, which now requires org.jboss.remoting.serialization.IMarshalledValue and org.jboss.remoting.serialization.SerializationStreamFactory (which is found within jboss-remoting.jar). However, jboss-remoting.jar is not included within server/minimal/lib nor within jboss-minimal.jar. Easiest thing to do would be to include jboss-remoting.jar in the minimal/lib directory (which is 586K). This what you think should be done Dimitris? Dimitris Andreadis wrote: Did something change recently in serialization/remoting? run -c minimal ... 15:15:32,609 INFO [NamingService] JNDI bootstrap JNP=/0.0.0.0:1099, RMI=/0.0.0.0:1098, backlog=50, no client SocketFactory, Server SocketFactory=class org.jboss.net.sockets.DefaultSocketFactory 15:15:32,629 WARN [ServiceController] Problem starting service jboss:service=Naming java.lang.NoClassDefFoundError: org/jboss/remoting/serialization/impl/java/JavaSerializationManager at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123 ) ... --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM --- ObjectName: jboss:service=Naming State: FAILED Reason: java.lang.NoClassDefFoundError: org/jboss/remoting/serialization/impl/ java/JavaSerializationManager I Depend On: jboss.system:service=ThreadPool --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: Problem with minimal config in Branch_4_0
The problem stems from NamingService using MarshalledInvocation, which now requires org.jboss.remoting.serialization.IMarshalledValue and org.jboss.remoting.serialization.SerializationStreamFactory (which is found within jboss-remoting.jar). However, jboss-remoting.jar is not included within server/minimal/lib nor within jboss-minimal.jar. Easiest thing to do would be to include jboss-remoting.jar in the minimal/lib directory (which is 586K). This what you think should be done Dimitris? Dimitris Andreadis wrote: Did something change recently in serialization/remoting? run -c minimal ... 15:15:32,609 INFO [NamingService] JNDI bootstrap JNP=/0.0.0.0:1099, RMI=/0.0.0.0:1098, backlog=50, no client SocketFactory, Server SocketFactory=class org.jboss.net.sockets.DefaultSocketFactory 15:15:32,629 WARN [ServiceController] Problem starting service jboss:service=Naming java.lang.NoClassDefFoundError: org/jboss/remoting/serialization/impl/java/JavaSerializationManager at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:539) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123) ... --- MBEANS THAT ARE THE ROOT CAUSE OF THE PROBLEM --- ObjectName: jboss:service=Naming State: FAILED Reason: java.lang.NoClassDefFoundError: org/jboss/remoting/serialization/impl/ java/JavaSerializationManager I Depend On: jboss.system:service=ThreadPool --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss-head, Testsuite for all configuration fails
Running the all config from a clean check out and build is fine (at least for booting). Running the testsuite does give an error when booting the all configuration (during jboss-all-config-tests target), but logs indicate is due to port 1098 already being in use. Saw the same on the cruisecontrol run - http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-1.5/20060405002821/build/output/jboss-5.0.0.Alpha/server/all/log/output.log. Not sure where the error you are seeing came from. Hany Mesha wrote: Hi all, When I run the test suite, it fails with the excpetion below. Is there a problem with head or is it just my env.? Thanks, Hany Mesha ==Begin=== 20:28:08,943 INFO [Server] Starting JBoss (MX MicroKernel)... 20:28:08,944 INFO [Server] Release ID: JBoss [Morpheus] 5.0.0.Alpha (build: CVSTag=HEAD date=200604041919) 20:28:08,946 INFO [Server] Home Dir: /home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha 20:28:09,099 INFO [Server] Home URL: file:/home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/ 20:28:09,100 INFO [Server] Patch URL: null 20:28:09,282 INFO [Server] Server Name: default 20:28:09,283 INFO [Server] Server Home Dir: /home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/server/default 20:28:09,283 INFO [Server] Server Home URL: file:/home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/server/default/ 20:28:09,283 INFO [Server] Server Temp Dir: /home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/server/default/tmp 20:28:09,284 INFO [Server] Root Deployment Filename: jboss-service.xml 20:28:10,072 INFO [ServerInfo] Java version: 1.5.0_03,Sun Microsystems Inc. 20:28:10,072 INFO [ServerInfo] Java VM: Java HotSpot(TM) Server VM 1.5.0_03-b07,Sun Microsystems Inc. 20:28:10,072 INFO [ServerInfo] OS-System: Linux 2.6.5-7.243-default,i386 20:28:11,228 INFO [Server] Core system initialized 20:28:17,840 ERROR [BasicMBeanRegistry] Cannot register MBean java.lang.NoClassDefFoundError: [Lorg/jboss/remoting/InvokerLocator; at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2365) at java.lang.Class.privateGetPublicMethods(Class.java:2488) at java.lang.Class.getMethods(Class.java:1406) at org.jboss.mx.metadata.StandardMetaData.build(StandardMetaData.java:208) at org.jboss.mx.modelmbean.XMBean.init(XMBean.java:224) at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:203) at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:262) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1426) at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:1359) at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:345) at org.jboss.system.ServiceCreator.install(ServiceCreator.java:157) at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:449) at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:171) at org.jboss.system.ServiceController.install(ServiceController.java:226) 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 org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:262) at
Re: [JBoss-dev] jboss-head, Testsuite for all configuration fails
The 'all' target and the 'most' target are the same except that 'all' calls 'modules-all' and 'most' calls 'modules-most'. Anyone know the difference between the two (modules-all and modules-most)? Hany Mesha wrote: It turned out that build clean then build all doesn't copy jboss-remoting.jar to the server build lib directory causing this error. I overcome the issue by copying the above jar to build/output/jboss-5.0.0.alpha/server/all/lib directory. Now I see the error reported on cruise control but only on my linux machine. My windows machine is able to run without a problem. Hany Mesha On 4/5/06, *Tom Elrod* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Running the all config from a clean check out and build is fine (at least for booting). Running the testsuite does give an error when booting the all configuration (during jboss-all-config-tests target), but logs indicate is due to port 1098 already being in use. Saw the same on the cruisecontrol run - http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-1.5/20060405002821/build/output/jboss-5.0.0.Alpha/server/all/log/output.log http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-1.5/20060405002821/build/output/jboss-5.0.0.Alpha/server/all/log/output.log. Not sure where the error you are seeing came from. Hany Mesha wrote: Hi all, When I run the test suite, it fails with the excpetion below. Is there a problem with head or is it just my env.? Thanks, Hany Mesha ==Begin=== 20:28:08,943 INFO [Server] Starting JBoss (MX MicroKernel)... 20:28:08,944 INFO [Server] Release ID: JBoss [Morpheus] 5.0.0.Alpha (build: CVSTag=HEAD date=200604041919) 20:28:08,946 INFO [Server] Home Dir: /home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha 20:28:09,099 INFO [Server] Home URL: file:/home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/ 20:28:09,100 INFO [Server] Patch URL: null 20:28:09,282 INFO [Server] Server Name: default 20:28:09,283 INFO [Server] Server Home Dir: /home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/server/default 20:28:09,283 INFO [Server] Server Home URL: file:/home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha /server/default/ 20:28:09,283 INFO [Server] Server Temp Dir: /home/hmesha/jboss_work/jboss-head/build/output/jboss-5.0.0.Alpha/server/default/tmp 20:28:09,284 INFO [Server] Root Deployment Filename: jboss-service.xml 20:28:10,072 INFO [ServerInfo] Java version: 1.5.0_03,Sun Microsystems Inc. 20:28:10,072 INFO [ServerInfo] Java VM: Java HotSpot(TM) Server VM 1.5.0_03-b07,Sun Microsystems Inc. 20:28:10,072 INFO [ServerInfo] OS-System: Linux 2.6.5-7.243-default,i386 20:28:11,228 INFO [Server] Core system initialized 20:28:17,840 ERROR [BasicMBeanRegistry] Cannot register MBean java.lang.NoClassDefFoundError: [Lorg/jboss/remoting/InvokerLocator; at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2365) at java.lang.Class.privateGetPublicMethods(Class.java:2488) at java.lang.Class.getMethods(Class.java:1406) at org.jboss.mx.metadata.StandardMetaData.build(StandardMetaData.java:208) at org.jboss.mx.modelmbean.XMBean.init(XMBean.java:224) at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:203) at sun.reflect.GeneratedMethodAccessor1.invoke (Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.interceptor.AbstractInterceptor.invoke (AbstractInterceptor.java:138) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java :140) at org.jboss.mx.server.Invocation.invoke(Invocation.java:90) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:262) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:668) at org.jboss.mx.server.MBeanServerImpl$3.run(MBeanServerImpl.java:1431) at java.security.AccessController.doPrivileged(Native Method
[JBoss-dev] JBossRemoting roadmap
I have updated the remoting road map to reflect what I want to deliver within the next quarter - http://jira.jboss.com/jira/secure/BrowseProject.jspa?id=10031subset=-1. In short: 2.0.0 (Boon) - mainly stability and performance release with minor features and bug fixes. estimated release mid May. 2.2.0 (Bluto) - major features and some design refactoring. Beta release end of June and GA end of August. Please take a look and see if there is anything you need added or if there are any issues with the scheduling. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossRemoting roadmap
Have not put a date in jira for jboss-remoting 2.0.0 yet, as need to make sure nothing else needs to be added (by the other projects). Assuming that nothing else is added to that release, expect GA release to be end of May (which would then go into jboss-as 4.0.5). Dimitris Andreadis wrote: So jboss-remoting 2.0.0 could come with the next version of jboss-as 2.0.5, unless there are other dependencies. Why not putting dates on the remoting releases? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Elrod Sent: 04 April, 2006 17:04 To: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] JBossRemoting roadmap I have updated the remoting road map to reflect what I want to deliver within the next quarter - http://jira.jboss.com/jira/secure/BrowseProject.jspa?id=10031; subset=-1. In short: 2.0.0 (Boon) - mainly stability and performance release with minor features and bug fixes. estimated release mid May. 2.2.0 (Bluto) - major features and some design refactoring. Beta release end of June and GA end of August. Please take a look and see if there is anything you need added or if there are any issues with the scheduling. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720; dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=kkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Do a clean build before committing changes to build-thirdparty.xml
Ok. I have rolled back to 1.4.0. The web services team can put back to
1.4.1 when they are ready.
Scott M Stark wrote:
Start doing a clean build before committing any changes to
build-thirdparty.xml to avoid this consistent problem:
[synchronizeinfo] Checking currentComponentRef:
ComponentRef{id=jboss/remoting,n
ame=jboss/remoting,filename=component-info.xml,location=null,version=1.4
.0_final
,[EMAIL PROTECTED],
version=1.4.0_final}],component=null,im
[EMAIL PROTECTED]/jbossws
atts={licensetype=lgpl} outpu
t=C:\cvs\JBoss4.0\jboss-4.0.x\thirdparty\jboss\jbossws version=1.0.0.CR6
isLocal
=false [EMAIL PROTECTED]
output=C:\cvs\JBoss4.0\jboss-4.
0.x\thirdparty\jboss\jbossws\lib\jbossws.sar type=null},
[EMAIL PROTECTED]
sws-client.jar
output=C:\cvs\JBoss4.0\jboss-4.0.x\thirdparty\jboss\jbossws\lib\j
bossws-client.jar type=null}] module=null
location=null},fileResolved=true}
[synchronizeinfo] against newComponent:
[EMAIL PROTECTED]/remoting atts=
{projecthome=http://www.jboss.org/products/remoting, licensetype=lgpl}
output=C:
\cvs\JBoss4.0\jboss-4.0.x\thirdparty\jboss\remoting version=1.4.1_final
isLocal=
false [EMAIL PROTECTED]
output=C:\cvs\JBoss4.0\j
boss-4.0.x\thirdparty\jboss\remoting\lib\jboss-remoting.jar type=null}]
module=n
ull location=null}
setVersion, version=1.4.1_final
BUILD FAILED
C:\cvs\JBoss4.0\jboss-4.0.x\build\build.xml:937: The following error
occurred wh
ile executing this line:
C:\cvs\JBoss4.0\jboss-4.0.x\build\build-thirdparty.xml:125: A versioning
problem
exists:
Component: jboss/remoting is at version: 1.4.1_final
but it is also required to be compatible with:
[EMAIL PROTECTED], version=1.4.0_final}]
by: jboss/jbossws
Scott Stark
VP Architecture Technology
JBoss Inc.
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=kkid0944bid$1720dat1642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why isn't server building?
I think this has to do with moving the IMarshalledValue out of common and into remoting (which would be in the remoting 1.4.1 release). I know Clebert was waiting on the upgrade to 1.4.1 to commit his changes to 4.0 branch that reflected this change (am guess he made that commit?) Scott M Stark wrote: My common, server, and remoting thirdparty are in synch with the 4.0 branch but there is a conflict: [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:285: incompatible types [javac] found : org.jboss.remoting.serialization.impl.jboss.LocalMarshalledValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] value = new LocalMarshalledValue(invocation.getArguments(),n ew SafeCloningRepository(safeToReuse)); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:289: incompatible types [javac] found : org.jboss.remoting.serialization.IMarshalledValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] value = SerializationStreamFactory.getManagerInstance().crea tedMarshalledValue((Object)invocation.getArguments()); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:304: incompatible types [javac] found : org.jboss.remoting.serialization.impl.jboss.LocalMarshalle dValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] mv = new LocalMarshalledValue(rtnValue,new SafeCloningR epository(safeToReuse)); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:308: incompatible types [javac] found : org.jboss.remoting.serialization.IMarshalledValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] mv = SerializationStreamFactory.getManagerInstance().cr eatedMarshalledValue(rtnValue); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:315: incompatible types [javac] found : org.jboss.remoting.serialization.IMarshalledValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] IMarshalledValue mv = SerializationStreamFactory.getManager Instance().createdMarshalledValue(t); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\uni fied\interfaces\JavaSerializationManager.java:97: createdMarshalledValue(java.la ng.Object) in org.jboss.invocation.unified.interfaces.JavaSerializationManager c annot override createdMarshalledValue(java.lang.Object) in org.jboss.remoting.se rialization.SerializationManager; attempting to use incompatible return type [javac] found : org.jboss.util.stream.IMarshalledValue [javac] required: org.jboss.remoting.serialization.IMarshalledValue [javac] public IMarshalledValue createdMarshalledValue(Object source) [javac] ^ [javac] 6 errors [javac] 1 warning Scott Stark VP Architecture Technology JBoss Inc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=kkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Why is all of this stuff in the jbossas build-thirdparty?
I think jmx server uses (or at least used to use) gnu-regexp Scott M Stark wrote: Where are all of these thirdparty elements being used such that they are specified here? In particular, what is using the * ones? componentref name=antlr version=2.7.6rc1/ * componentref name=apache-addressing version=cvsbuild-7-19/ componentref name=apache-avalon version=4.1.5/ componentref name=apache-avalon-logkit version=1.2/ componentref name=apache-bcel version=5.1/ * componentref name=apache-beanutils version=1.6.0/ componentref name=apache-bsf version=2.3.0/ * componentref name=apache-codec version=1.2.0/ componentref name=apache-collections version=2.1/ * componentref name=apache-crimson version=1.1.1/ componentref name=apache-digester version=1.6/ componentref name=apache-discovery version=0.2/ * componentref name=apache-fileupload version=1.0/ componentref name=apache-httpclient version=2.0.2/ * componentref name=apache-jaxme version=0.2-cvs/ Can this be dropped from jbossxb? * componentref name=apache-lang version=1.0/ componentref name=apache-log4j version=1.2.8/ componentref name=apache-logging version=1.0.4.1jboss/ componentref name=apache-myfaces version=1.1.1/ * componentref name=apache-pool version=1.0.1/ componentref name=apache-scout version=1.0/ componentref name=apache-slide version=1.0.16/ componentref name=apache-tomcat version=5.5.16/ componentref name=apache-velocity version=1.4jboss/ componentref name=apache-wss4j version=cvs-7-19/ componentref name=apache-xalan version=j_2.7.0/ componentref name=apache-xerces version=2.7.1/ componentref name=apache-xmlsec version=1.2.97/ componentref name=beanshell version=1.3.0/ componentref name=cglib version=2.1.2jboss/ componentref name=dom4j version=1.6.1jboss/ componentref name=gjt-jpl-util version=1.0/ componentref name=gnu-getopt version=1.0.10/ * componentref name=gnu-regexp version=1.1.14/ componentref name=hibernate version=3.2.0.CR1/ componentref name=hibernate-annotations version=3.1beta9/ componentref name=hibernate-entitymanager version=3.1beta7/ componentref name=hsqldb version=1.8.0.2/ componentref name=ibm-wsdl4j version=1.5.2jboss/ componentref name=jacorb version=2.2.3/ componentref name=javassist version=3.2.0.CR1/ componentref name=jaxen version=1.1beta4/ componentref name=jboss/aop version=1.3.6/ componentref name=jboss/backport-concurrent version=2.1.0.GA/ componentref name=jboss/cache version=1.2.4.SP2/ componentref name=jboss/microcontainer version=1.0.2/ componentref name=jboss/jbossretro version=1.0.0.CR1/ componentref name=jboss/jbossws version=1.0.0.CR6/ componentref name=jboss/jbossws14 version=1.0.0.CR6/ componentref name=jboss/jbossxb version=snapshot/ componentref name=jboss/remoting version=1.4.0_final/ componentref name=jboss/serialization version=1.0.0.CR4/ componentref name=jfreechart version=0.9.20/ componentref name=jgroups version=2.2.7/ componentref name=joesnmp version=0.3.3/ componentref name=juddi version=0.9RC4/ componentref name=junit version=3.8.1/ componentref name=junitejb version=1.4/ componentref name=objectweb-joramtests version=1.1/ componentref name=odmg version=3.0/ componentref name=oswego-concurrent version=1.3.4/ * componentref name=qdox version=1.4/ componentref name=sleepycat version=1.5.2/ componentref name=sun-jaf version=1.0.2/ componentref name=sun-javacc version=3.2/ componentref name=sun-javamail version=1.3.1/ componentref name=sun-servlet version=2.4/ componentref name=trove version=1.0.2/ * componentref name=wutka-dtdparser version=1.2.1/ Can this be dropped from jbossxb? componentref name=xdoclet version=1.2b3/ * componentref name=xml-sax version=2.0.x/ Scott Stark VP Architecture Technology JBoss Inc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=kkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory!
Re: [JBoss-dev] Why isn't server building?
FYI, it *does* have remoting 1.4.1 now. Thanks for your help Clebert. Clebert Suconic wrote: It should be fixed now. BTW I've removed org.jboss.util.stream.IMarshalledValue It was confusing to have IMarshalledValue in both versions. Since org.jboss.util.stream.IMarshalledValue wasn't introduced in a final version, I thought it should be okay removing it. Clebert From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clebert Suconic Sent: Tuesday, March 28, 2006 9:28 PM To: jboss-development@lists.sourceforge.net; jboss-development@lists.sourceforge.net Subject: RE: [JBoss-dev] Why isn't server building? I didn't commit my changes. I was waiting the newer version of Remoting. I will be looking into that now. From: [EMAIL PROTECTED] on behalf of Tom Elrod Sent: Tue 3/28/2006 8:51 PM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] Why isn't server building? I think this has to do with moving the IMarshalledValue out of common and into remoting (which would be in the remoting 1.4.1 release). I know Clebert was waiting on the upgrade to 1.4.1 to commit his changes to 4.0 branch that reflected this change (am guess he made that commit?) Scott M Stark wrote: My common, server, and remoting thirdparty are in synch with the 4.0 branch but there is a conflict: [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:285: incompatible types [javac] found : org.jboss.remoting.serialization.impl.jboss.LocalMarshalledValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] value = new LocalMarshalledValue(invocation.getArguments(),n ew SafeCloningRepository(safeToReuse)); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:289: incompatible types [javac] found : org.jboss.remoting.serialization.IMarshalledValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] value = SerializationStreamFactory.getManagerInstance().crea tedMarshalledValue((Object)invocation.getArguments()); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:304: incompatible types [javac] found : org.jboss.remoting.serialization.impl.jboss.LocalMarshalle dValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] mv = new LocalMarshalledValue(rtnValue,new SafeCloningR epository(safeToReuse)); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:308: incompatible types [javac] found : org.jboss.remoting.serialization.IMarshalledValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] mv = SerializationStreamFactory.getManagerInstance().cr eatedMarshalledValue(rtnValue); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\Inv okerInterceptor.java:315: incompatible types [javac] found : org.jboss.remoting.serialization.IMarshalledValue [javac] required: org.jboss.util.stream.IMarshalledValue [javac] IMarshalledValue mv = SerializationStreamFactory.getManager Instance().createdMarshalledValue(t); [javac] ^ [javac] C:\cvs\JBoss4.0\jboss-4.0.x\server\src\main\org\jboss\invocation\uni fied\interfaces\JavaSerializationManager.java:97: createdMarshalledValue(java.la ng.Object) in org.jboss.invocation.unified.interfaces.JavaSerializationManager c annot override createdMarshalledValue(java.lang.Object) in org.jboss.remoting.se rialization.SerializationManager; attempting to use incompatible return type [javac] found : org.jboss.util.stream.IMarshalledValue [javac] required: org.jboss.remoting.serialization.IMarshalledValue [javac] public IMarshalledValue createdMarshalledValue(Object source) [javac] ^ [javac] 6 errors [javac] 1 warning Scott Stark VP Architecture Technology JBoss Inc. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=kkid0944bid$1720dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends
[JBoss-dev] Re: ejb3-4.0-testsuite Build Failed
Am finished adding the remoting-int module (see JBAS-2698). The jar produced (and put in the lib directory of default and all server config) is jboss-remoting-int.jar (instead of jbossas-remoting.jar, which is how it is in HEAD). I am not sure if/where there will need to be any adjustments for this within the ejb3 project. Ryan Campbell wrote: Yes, this is Branch_4_0. Thanks, Tom. -Original Message- From: Tom Elrod Sent: Tuesday, January 31, 2006 1:28 PM To: Tom Elrod Cc: Ryan Campbell; Tom Elrod; Kabir Khan; Bill Burke; jboss-development@lists.sourceforge.net Subject: Re: ejb3-4.0-testsuite Build Failed I think I get the mis-match now. This is being build out of JBoss 4.x branch, right? If so, then the code for jbossas-remoting.jar is not there. There is an issue for this (JBAS-2698), which I will work on today. Tom Elrod wrote: The class that is not being found is within jbossas-remoting.jar. This is part of JBossAS code base and not remoting. Only way this would be called to be loaded is if was configured to use the JBossAS security domain via configuration. So am guessing the jar was excluded from the build? Ryan Campbell wrote: The ejb3-ssl-advanced test server is broken: 2006-01-30 20:09:06,202 DEBUG [org.jboss.deployment.SARDeployer] create operation failed for package file:/services/cruisecontrol/checkout/ejb3-4.0-testsuite/build/output/jb oss-4.0.4RC1/server/ejb3-ssl-advanced/deploy/ejb3.deployer/ org.jboss.deployment.DeploymentException: No ClassLoaders found for: org.jboss.remoting.security.domain.DomainServerSocketFactoryService; - nested throwable: (java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.remoting.security.domain.DomainServerSocketFactoryService) at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:19 6) at org.jboss.system.ServiceController.install(ServiceController.java:226) *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *Sent:* Monday, January 30, 2006 7:12 PM *To:* Adrian Brock; Bill Decoste; Bill Burke; Gavin King; jboss-development@lists.sourceforge.net; Kabir Khan; QA; Ruel Loehr; Scott M Stark; Thomas Diesler *Subject:* ejb3-4.0-testsuite Build Failed *Importance:* High View results here - http://cruisecontrol.jboss.com/cc/buildresults/ejb3-4.0-testsuite?log=lo g20060130193339 *BUILD FAILED* *Ant Error Message: */services/cruisecontrol/work/scripts/build-ejb3-4.0-testsuite.xml:83: Exit code: 1 See tests.log in Build Artifacts for details. *Date of build: *01/30/2006 19:33:39 *Time to build: *37 minutes 18 seconds *Last changed: *12/31/2005 16:46:08 *Last log entry: *call isOpen() when obtaining session so that HEM registers with EM with TXset cglib_use_reflection flag to false --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss Remoting 1.4.0 final integration
JBoss Remoting 1.4.0 final was release late last week. I am finishing up integrating this into JBossAS 4.0 branch and HEAD. The items of note with this integration are: 4.0 branch HEAD - Updated build-thirdpary.xml to use remoting 1.4.0_final from repository - removed javax.servlet.jar from jboss all client jar. I think remoting was the reason this was initially added and is no longer needed (since http implementation based on Tomcat connectors now). 4.0 branch only - Added new module, remoting-int. This is same as jbossas module from HEAD, but renamed to better distinguish it. Biggest component of remoting-int is security integration between remoting SSL and using the JBoss security domain. The product of this module is jboss-remoting-int.jar, and is being placed in the lib directory of default and all server config. See JBAS-2698 for more details. The only remaining issue I am aware of is the Tomcat connector jars being available, which is only an issue when http transport within remoting. Jira issue for this is JBAS-2766. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: ejb3-4.0-testsuite Build Failed
The class that is not being found is within jbossas-remoting.jar. This is part of JBossAS code base and not remoting. Only way this would be called to be loaded is if was configured to use the JBossAS security domain via configuration. So am guessing the jar was excluded from the build? Ryan Campbell wrote: The ejb3-ssl-advanced test server is broken: 2006-01-30 20:09:06,202 DEBUG [org.jboss.deployment.SARDeployer] create operation failed for package file:/services/cruisecontrol/checkout/ejb3-4.0-testsuite/build/output/jboss-4.0.4RC1/server/ejb3-ssl-advanced/deploy/ejb3.deployer/ org.jboss.deployment.DeploymentException: No ClassLoaders found for: org.jboss.remoting.security.domain.DomainServerSocketFactoryService; - nested throwable: (java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.remoting.security.domain.DomainServerSocketFactoryService) at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:196) at org.jboss.system.ServiceController.install(ServiceController.java:226) *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *Sent:* Monday, January 30, 2006 7:12 PM *To:* Adrian Brock; Bill Decoste; Bill Burke; Gavin King; jboss-development@lists.sourceforge.net; Kabir Khan; QA; Ruel Loehr; Scott M Stark; Thomas Diesler *Subject:* ejb3-4.0-testsuite Build Failed *Importance:* High View results here - http://cruisecontrol.jboss.com/cc/buildresults/ejb3-4.0-testsuite?log=log20060130193339 *BUILD FAILED* *Ant Error Message: */services/cruisecontrol/work/scripts/build-ejb3-4.0-testsuite.xml:83: Exit code: 1 See tests.log in Build Artifacts for details. *Date of build: *01/30/2006 19:33:39 *Time to build: *37 minutes 18 seconds *Last changed: *12/31/2005 16:46:08 *Last log entry: *call isOpen() when obtaining session so that HEM registers with EM with TXset cglib_use_reflection flag to false --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: ejb3-4.0-testsuite Build Failed
I think I get the mis-match now. This is being build out of JBoss 4.x branch, right? If so, then the code for jbossas-remoting.jar is not there. There is an issue for this (JBAS-2698), which I will work on today. Tom Elrod wrote: The class that is not being found is within jbossas-remoting.jar. This is part of JBossAS code base and not remoting. Only way this would be called to be loaded is if was configured to use the JBossAS security domain via configuration. So am guessing the jar was excluded from the build? Ryan Campbell wrote: The ejb3-ssl-advanced test server is broken: 2006-01-30 20:09:06,202 DEBUG [org.jboss.deployment.SARDeployer] create operation failed for package file:/services/cruisecontrol/checkout/ejb3-4.0-testsuite/build/output/jboss-4.0.4RC1/server/ejb3-ssl-advanced/deploy/ejb3.deployer/ org.jboss.deployment.DeploymentException: No ClassLoaders found for: org.jboss.remoting.security.domain.DomainServerSocketFactoryService; - nested throwable: (java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.remoting.security.domain.DomainServerSocketFactoryService) at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:196) at org.jboss.system.ServiceController.install(ServiceController.java:226) *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *Sent:* Monday, January 30, 2006 7:12 PM *To:* Adrian Brock; Bill Decoste; Bill Burke; Gavin King; jboss-development@lists.sourceforge.net; Kabir Khan; QA; Ruel Loehr; Scott M Stark; Thomas Diesler *Subject:* ejb3-4.0-testsuite Build Failed *Importance:* High View results here - http://cruisecontrol.jboss.com/cc/buildresults/ejb3-4.0-testsuite?log=log20060130193339 *BUILD FAILED* *Ant Error Message: */services/cruisecontrol/work/scripts/build-ejb3-4.0-testsuite.xml:83: Exit code: 1 See tests.log in Build Artifacts for details. *Date of build: *01/30/2006 19:33:39 *Time to build: *37 minutes 18 seconds *Last changed: *12/31/2005 16:46:08 *Last log entry: *call isOpen() when obtaining session so that HEM registers with EM with TXset cglib_use_reflection flag to false --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: FW: jboss-remoting-testsuite-1.5 Thread Dump
Have made the change and checked in. Should be IOException that is
thrown, but can't hurt to check for all.
Ryan Campbell wrote:
Tom,
Here is the stack trace from a hung remoting testsuite on jdk 1.5. It
looks like all of the threads have exited, but the test is still trying
to increment the count, and hasn’t found an exception. Perhaps the
catch block should be expanded to include any throwable? Rajesh is
testing to see if this allows the test to fail instead of hanging.
ie,
catch(Throwable e)
{
error = true;
assertTrue(Error: + e.getMessage(), false);
}
*From:* Rajesh Rajasekaran
*Sent:* Monday, January 23, 2006 4:54 PM
*To:* Ryan Campbell
*Subject:* RE: jboss-remoting-testsuite-1.5 Build Completed With
Testsuite Errors
Stack trace of thread dump
[junit] Running org.jboss.test.remoting.util.PortUtilTestCase
[junit] Full thread dump Java HotSpot(TM) Server VM (1.5.0_03-b07
mixed mode):
[junit] Low Memory Detector daemon prio=1 tid=0x8df3a4e0
nid=0x4ec5 runnable [0x..0x]
[junit] CompilerThread1 daemon prio=1 tid=0x8df39140 nid=0x4ec4
waiting on condition [0x..0x8da79788]
[junit] CompilerThread0 daemon prio=1 tid=0x8df38200 nid=0x4ec3
waiting on condition [0x..0x8dafa708]
[junit] AdapterThread daemon prio=1 tid=0x8df37280 nid=0x4ec2
waiting on condition [0x..0x]
[junit] Signal Dispatcher daemon prio=1 tid=0x8df36460 nid=0x4ec1
waiting on condition [0x..0x]
[junit] Finalizer daemon prio=1 tid=0x8df2cad0 nid=0x4ec0 in
Object.wait() [0x8de7e000..0x8de7e770]
[junit] at java.lang.Object.wait(Native Method)
[junit] - waiting on 0x925138d0 (a
java.lang.ref.ReferenceQueue$Lock)
[junit] at
java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
[junit] - locked 0x925138d0 (a java.lang.ref.ReferenceQueue$Lock)
[junit] at
java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
[junit] at
java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
[junit] Reference Handler daemon prio=1 tid=0x8df2be90 nid=0x4ebf
in Object.wait() [0x8deff000..0x8deff6f0]
[junit] at java.lang.Object.wait(Native Method)
[junit] - waiting on 0x9254a538 (a java.lang.ref.Reference$Lock)
[junit] at java.lang.Object.wait(Object.java:474)
[junit] at
java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
[junit] - locked 0x9254a538 (a java.lang.ref.Reference$Lock)
[junit] main prio=1 tid=0x0805d188 nid=0x4eb7 waiting on condition
[0xbfffb000..0xbfffc118]
[junit] at java.lang.Thread.sleep(Native Method)
[junit] at
org.jboss.test.remoting.util.PortUtilTestCase.testFindingFreePorts(PortUtilTestCase.java:83)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:585)
[junit] at junit.framework.TestCase.runTest(TestCase.java:154)
[junit] at junit.framework.TestCase.runBare(TestCase.java:127)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:106)
[junit] at
junit.framework.TestResult.runProtected(TestResult.java:124)
[junit] at junit.framework.TestResult.run(TestResult.java:109)
[junit] at junit.framework.TestCase.run(TestCase.java:118)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:208)
[junit] at junit.framework.TestSuite.run(TestSuite.java:203)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:289)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:656)
[junit] at
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:558)
[junit] VM Thread prio=1 tid=0x8df29310 nid=0x4ebe runnable
[junit] GC task thread#0 (ParallelGC) prio=1 tid=0x080e3930
nid=0x4eba runnable
[junit] GC task thread#1 (ParallelGC) prio=1 tid=0x080e3d18
nid=0x4ebb runnable
[junit] GC task thread#2 (ParallelGC) prio=1 tid=0x080e4100
nid=0x4ebc runnable
[junit] GC task thread#3 (ParallelGC) prio=1 tid=0x080e48e0
nid=0x4ebd runnable
[junit] VM Periodic Task Thread prio=1 tid=0x8df3ba00 nid=0x4ec6
waiting on condition
*From:* Ryan Campbell
*Sent:* Monday, January 23, 2006 2:57 PM
*To:* Tom Elrod
*Cc
Re: [JBoss-dev] RE: ejb3-4.0-testsuite Build Failed
So how should the be addressed when using 1.4? I just added used of Timer for client side leases within remoting. Adrian Brock wrote: 1.5 added a java.util.Timer.purge() I didn't realise Elias had changed TimeoutFactory to use a Timer. He said he was just changing it so it can be used as something other than a singleton: http://jira.jboss.com/jira/browse/JBAS-2205 From the cvs commit, it looks like he did this because the old implementation didn't have a shutdown method: http://anoncvs.forge.jboss.com/viewrep/JBoss/jboss-common/src/main/org/jboss/util/timeout/TimeoutFactory.java See version 1.4 On Sun, 2006-01-22 at 03:18, Scott M Stark wrote: The issue is that the cancelation of the timer is not removing its association from the java.util.Timer as the TimerTask.cancel just marks the TimerTask.state as cancelled, but its not removed until the timer actually expires. This was leading to a huge list of transaction timeout objects and the associated object graph. Clearing the TimeoutImpl refs in cancel restricts the transient buildup to just the TimeoutImpl. I don't see a way to immeadiate disassociate the TimeoutImpl from the java.util.Timer internals. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Saturday, January 21, 2006 10:12 PM To: jboss-development@lists.sourceforge.net; Bill Burke Subject: RE: [JBoss-dev] RE: ejb3-4.0-testsuite Build Failed So after profiling this the problem looks to be recent changes in org.jboss.util.timeout.TimeoutFactory as the leaks are related to transaction timeouts. By clearing the TimeoutFactory$TimeoutImpl references the test gets past the OME, but there are 73k TimeoutFactory$TimeoutImpl left after the test has completed and has been undeployed. One gc root is the java.util.TimerThread task queue. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott M Stark Sent: Saturday, January 21, 2006 2:17 PM To: Bill Burke Cc: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] RE: ejb3-4.0-testsuite Build Failed This is just the org.jboss.ejb3.test.microbench.unit.BenchUnitTestCase requiring too much memory. Memory usage during this test goes from 40m to 130m even using the default config so the memory usage of this needs to be looked at. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=kkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: EJB 3 release slipping
TaskJBAS-2604 Update the remoting version to a stable release I'll have a 1.4.0 RC1 available for testing before tomorrow morning (if no problems with this, will make the final next week). --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: jboss-remoting-testsuite Build Failed
This should be fixed now. Don't know if I made it in time for tonight's build though. Ryan Campbell wrote: JRunit tests/config for remoting seem to be broken: http://cruisecontrol.jboss.com/cc/artifacts/jboss-remoting-testsuite/20050913121659/tests.log [receiver] Caused by: java.io.FileNotFoundException: ./output/jrunit-report.html (No such file or directory) [receiver]at java.io.FileOutputStream.open(Native Method) [receiver]at java.io.FileOutputStream.init(FileOutputStream.java:179) [receiver]at java.io.FileOutputStream.init(FileOutputStream.java:131) [receiver]at org.jboss.jrunit.controller.reporters.XrefReporter.init(XrefReporter.java:42) [receiver]... 25 more BUILD FAILED *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *Sent:* Tuesday, September 13, 2005 11:31 AM *To:* jboss-development@lists.sourceforge.net; QA *Subject:* jboss-remoting-testsuite Build Failed *Importance:* High View results here - http://cruisecontrol.jboss.com/cc/buildresults/jboss-remoting-testsuite?log=log20050913121659 *BUILD FAILED* *Ant Error Message: */home/cruisecontrol/work/scripts/build-jboss-remoting.xml:42: Exit code: 1 See tests.log in Build Artifacts for details. *Date of build: *09/13/2005 12:16:59 *Time to build: *13 minutes 30 seconds *Last changed: *09/13/2005 11:51:12 *Last log entry: *JBREM-194 - updated build for multiplex performance tests (which require larger memory heap and timeouts). Unit Tests: (0) Total Errors and Failures: (0) Modifications since last builds: (first 50 of 17) 1.30 modified telrod /build.xml JBREM-194 - updated build for multiplex performance tests (which require larger memory heap and timeouts). 1.29 modified telrod /build.xml JBREM-9 - updated performance tests to include metadata with benchmarks and reporting 1.4 modified telrod lib/jboss/jrunit.jar JBREM-9 - updated performance tests to include metadata with benchmarks and reporting 1.3 modified telrod src/tests/org/jboss/test/remoting/performance/asynchronous/PerformanceClientSideClientTest.java JBREM-9 - updated performance tests to include metadata with benchmarks and reporting 1.3 modified telrod src/tests/org/jboss/test/remoting/performance/asynchronous/PerformanceServerSideClientTest.java JBREM-9 - updated performance tests to include metadata with benchmarks and reporting 1.3 modified telrod src/tests/org/jboss/test/remoting/performance/synchronous/MultiThreadedPerformanceClientTest.java JBREM-9 - updated performance tests to include metadata with benchmarks and reporting 1.9 modified telrod src/tests/org/jboss/test/remoting/performance/synchronous/PerformanceClientTest.java JBREM-9 - updated performance tests to include metadata with benchmarks and reporting 1.2 deleted telrod src/main/org/jboss/remoting/marshal/MarshallIOException.java JBREM-182 - removed MarshallIOException and changed to use java.rmi.MarshalException to be more compliant with the way rmi handles the exception. 1.3 modified telrod src/main/org/jboss/remoting/transport/multiplex/MultiplexClientInvoker.java JBREM-182 - removed MarshallIOException and changed to use java.rmi.MarshalException to be more compliant with the way rmi handles the exception. 1.11 modified telrod src/main/org/jboss/remoting/transport/socket/SocketClientInvoker.java JBREM-182 - removed MarshallIOException and changed to use java.rmi.MarshalException to be more compliant with the way rmi handles the exception. 1.28 modified telrod /build.xml JBREM-182 - updated to throws MarshallIOException when connection disconnects (caused by EOFException) instead of ConnectException. MarshalledIOException extends IOExcpetion, but allows for getCause(). 1.1 added telrod src/main/org/jboss/remoting/marshal/MarshallIOException.java JBREM-182 - updated to throws MarshallIOException when connection disconnects (caused by EOFException) instead of ConnectException. MarshalledIOException extends IOExcpetion, but allows for getCause(). 1.2 modified telrod src/main/org/jboss/remoting/transport/multiplex/MultiplexClientInvoker.java JBREM-182 - updated to throws MarshallIOException when connection disconnects (caused by
Re: [JBoss-dev] org.jboss.naming package cleanup
Scott M Stark wrote: another package that needs to be broken out of jboss.jar is org.jboss.invocation. There are dependencies on the remoting implementation in the NamingService, HttpNamingContextFactory and the naming proxy interceptors. This package should be in a jboss-remoting-legacy.jar or some such. The classes you mention don't import any remoting classes directly. You mean because of UnifiedInvoker under the org.jboss.invocation package causes the dependency on remoting, right? If that is broken out, wouldn't require jboss-remoting-legacy.jar, just the regular jboss-remoting.jar, right? I am a little lost as to why need a jboss-remoting-legacy.jar. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: MORE RANTS. was RE: [JBoss-dev] creating jboss thirdparty directory
Scott M Stark wrote: ... The only thing that has been done as far as I know if removal of remoting from jboss-head to introduce the binary. Correct. I did two things. 1. Added remoting binary and changed the current builds to use the library instead of the module. 2. Added new integration code under jbossas/remoting directory. There are only a few files (for new aspect interceptor for remoting and security domain factory), which don't belong in core remoting. As for who is doing what, I'm done with anything build related for the time being. The only thing I have left to do is figure out if/when I want to use the new build in JBossRemoting for my test runs (which has been discussed on the build forum), but am going to wait till the new build is further along before tackling this. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Brock Sent: Thursday, May 12, 2005 5:19 PM To: jboss-development@lists.sourceforge.net Subject: MORE RANTS. was RE: [JBoss-dev] creating jboss thirdparty directory Ok, so I missed this post. Why are we changing the build structure before we have the new build in place and for untested/unvalidated/undiscussed requirements? My concerns (basically trying to run before we can walk): 1) We still don't have a new build that reproduces the old build 2) Some of the changes we have discussed or articulated are being done almost without people getting chance to respond or review 3) None of these changes has any experiments or use case descriptions showing how it will work. I'm confused, god knows about the other developers who are less involved in the project or paying less attention to the discussions? e.g. a use case I described for the new build, and I thought Scott articulated in his original response to this thread was the following: I want to test a patch to jboss-4.0.5 with the new build without going through all the tedium of a full rebuild/recompile on every small change. With the new build, the way I envisioned it was it would work as follows: 1) Download the main structure from the relevent branch cvs co -r JBoss_4_0_5 jbossas cd jbossas 2) Tell the build system I'm only interested in binaries by editing my local properties and retrieve the binaries ant synchronize 4) Build the release from the binaries ant release 5) Checkout the module I want to patch as source make my changes and recompile ant release 6) Run all the tests in all the projects (the tests are binary artifacts/jars in the repository) ant test How is this going to be possible if everything is in one module under cvs? Equally, how does this work with other integrations like jbossas + portal jbossas + seam etc. that have their own notion of the build totality. e.g. I would doubt portal wants to build jbossas from source! Also, I've been arguing for a while now that putting everything in one big ball of mud (as Andy calls it) just leads to everybody referencing everybody else and an integration/dependency nightmare. I see this only getting worse if everything is under one source tree. What I'd like to see before we make more changes are: 1) A working new build 2) Definition of build uses cases/procedures/requirements 3) Experiments that show these are supported and work 4) A dry run through the whole release cycle to show the process is working By a dry run, I mean smaller test project(s) where we can experiment/test the procedures and use cases before implementing them with our real projects. Rather than hoping that the new build will eventually support what you are trying to do. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_ids93alloc_id281op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] creating jboss thirdparty directory
Its done (will send out e-mail about the changes in a minute). The only issue now is exactly how we want to include jboss binaries within thirdparty. Right now, the entry brining in the jboss-remoting.jar is defined as: _thirdparty_jboss_remoting -d jboss thirdparty/jboss and _thirdparty_jboss_remoting is included in the _jboss_thirdparty definition. This means that a checkout of jboss-head will create: thridparty/jboss/aop/lib/jboss-aop.jar thridparty/jboss/aop/lib/jboss-aspect-library.jar thridparty/jboss/plastic/lib/ thridparty/jboss/remoting/lib/jboss-remoting.jar As far as I can tell, the thirdparty/jboss/aop is for 4.0 and is defined as: _binary_jboss_aop -d jboss-aop thirdparty/jboss/aop so that there is thirdparty/jboss-aop/lib/jboss-aop.jar thirdparty/jboss-aop/lib/jboss-aspect-library.jar Should I leave jboss-head the way it is or change to match the way aop is included in 4.0? Really just down to whether we want a bunch of thridparty/jboss-XXX directories or thirdparty/jboss/XXX with some of the XXX directories not being needed. BTW, looks like HEAD build is broken due to: C:\tmp\jboss-head2\jboss-head\aspects\src\main\org\jboss\aspects\security\AuthenticationInterceptor. java:43: cannot resolve symbol symbol : constructor SecurityException (java.security.GeneralSecurityException) location: class java.lang.SecurityException throw new SecurityException(gse); Scott M Stark wrote: Yes, go ahead. After I finish the 4.0 thirdparty setup I'll migrate it to the jbossas build on head as well. The code that will continue to live in jbossas like the legacy ejb container, jbossmq, etc. should be copied into the jbossas module with its cvs history to get rid of the modules file usage as well to complete this. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Elrod Sent: Tuesday, May 10, 2005 8:58 PM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] creating jboss thirdparty directory ... I think we are there. There is already a jbossas module defined with nothing but the new build in it. Remoting is ready to make this move (no better time actually). If you give the green light, I will execute what I have described below and we will be on our way to this new path. As other projects break off, they can do the same. I think with the new build process, it would also be a big help to network as will have modular, versioned components that will be easier to do patch updates for. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_ids93alloc_id281op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] remoting now external to jbossas
The changes to make JBossRemoting a completely external project of JBossAS is now complete. To get the changes, either do a clean checkout of HEAD, or and update and then cvs checkout thirdparty/jboss from the root jboss-head directory. This ONLY pertains to CVS HEAD (i.e. jboss-head, jboss5, or whatever you call it). The jboss-remoting.jar is now in the thirdparty/jboss/remoting/lib directory and is a library instead of a module (as seen from the buildmagic view). This means that references to the jboss remoting jar should be made from the library classpath and not the dependent module classpath. Files changed (and checked in) for this: aspects/build-test.xml aspects/build-test50.xml aspects/build.xml build/build.xml ejb3/build-test.xml ejb3/build.xml jmx-remoting/build.xml server/build.xml testsuite/build.xml testsuite/deprecated-build.xml tools/etc/buildmagic/libraries.ent tools/etc/buildmagic/libraries.xml tools/ent/buildmagic/modules.ent tools/ent/buildmagic/modules.xml transaction/build.xml webservice/build.xml The integration code between JBossAS and JBossRemoting now lives under the jbossas module in a subdirectory called remoting. When this is built, it will yield a jbossas-remoting.jar. The full jbossas server build will put the jboss-remoting.jar and jbossas-remoting.jar in the default all lib directories. The only build file I did not change was for jmx\build.xml, since it uses a custom jboss-remoting.jar under its resources directory. I will be updating the jboss-remoting.jar in the thirdparty lib directory as I add features and will notify everyone before making an update if there are ever any API changes that may impact dependent projects. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] creating jboss thirdparty directory
I have the old build ready locally for both the jboss-head and JBossRemoting. Now I need to change the CVSROOT/modules file. I want to take the _jboss_remoting module (the current one under jboss-head) and rename the alias to something like remoting-integration. Could really use suggestions for a better name. This will contain only the integration code between JBossRemoting and JBossAS. Then I will declare another entry for JBossRemoting, which has the old alias remoting. This is so the new build will work. I will also need to add a new component for the remoting-integration. So, the new CVSROOT/modules would have the following entries: _jboss_remoting -d remoting-integration jboss-remoting-integration JBossRemoting -d remoting jboss-remoting Will also have to change the component declarations within the new build to have: component id=remoting-integration module=jboss-remoting-integration version=5.0-SNAPSHOT artifact id=jboss-remoting-integration.jar release=server/all/lib/ /component component id=remoting module=jboss-remoting version=5.0-SNAPSHOT artifact id=jboss-remoting.jar release=server/all/lib/ /component I don't think the JBossRemoting project is getting built via cruise control, so the jboss-remoting.jar snapshot will not be getting updated until we can get this added. Will also need to have it add jboss-remoting-integration.jar as well. Is there anything else I am missing for this to work? Once this change is made, am not sure exactly what people will need to get the update view of the source. Go to jboss-head root directory and run 'cvs co remoting'? Guess will need to do same thing for thirdparty (to get thirdparty/jboss/remoting/lib/jboss-remoting.jar)? Scott M Stark wrote: That is fine, but I'm creating a jbossbuild script that will generate the legacy thirdparty structure from the repository to get rid of the existing thirdparty cvs tree. I would like to have the option of not having to checkout the legacy thirdparty tree as part of the jboss-4.0/jboss-head co and instead build this on demand based on a synchronize target to avoid having to duplicate where thirdparty jars need to be checked in. I guess this will require a new cvs module alias (at least for jboss-4.0) to avoid breaking the build of existing releases. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Elrod Sent: Monday, May 09, 2005 1:34 PM To: jboss-development@lists.sourceforge.net Subject: [JBoss-dev] creating jboss thirdparty directory Since I am now doing all new development in the JBossRemoting module, which is stand alone, I would like to make a few changes as to how jboss-head picks up the remoting code. First, I would like to make the remoting code visible to jboss-head as a binary. For the old build, this means adding it to the thirdparty directory and changing the old build scripts for the modules that need remoting to include the remoting jar from the thirdparty directory. I was going to create a new directory that looked something like: thirdparty/jboss/remoting/lib/jboss-remoting.jar For the new build, can just include the pointer to the repository for the remoting jar. I also want to keep the jboss-head/remoting directory, but make it contain the code for integration between JBossAS and JBossRemoting. So I will be removing almost all of the code that is currently there (which is the core remoting code currently). Please let me know if this is going to be a problem or if you have any other suggestions on how to do this. Thanks. -Tom --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_ids93alloc_id281op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click
Re: [JBoss-dev] creating jboss thirdparty directory
So you want? 1. The jboss-head/remoting directory and its contents (which now only contains integration code on my local disk) to be moved under the jboss-head/jbossas directory (including src/main and src/tests). 2. Then update the jbossas build so it will be its new remoting subdirectory. 3. Remove the jboss-head/remoting directory (thus making it dead in jboss-head). I can't remove the _jboss_remoting module reference from within the jboss-head project definition because of previous versions will still need to have it available, right? (based on some tag earlier on jboss-head). 4. Change the component definition for remoting to use module=JBossRemoting instead of module=jboss-remoting within the new build. Scott M Stark wrote: We need to stop using the cvs module as the merge mechanism. I don't think integration code should be a seperate cvs module. I would view it as code inherent to jbossas, so the integration code for the various services should just be subdirectories of the jbossas module: jbossas/build jbossas/microcontainer jbossas/naming jbossas/remoting ... I'm never going to use the _jboss_remoting by itself, so it should not exist as a top level module. We also need a cvs module naming convention as I have no idea what all this crap is: [EMAIL PROTECTED]:~$ ls -1 /cvsroot/jboss/ admin aop applications Attic blocks-jboss build build-jboss buildmagic cheese cluster-jboss common common-jboss console container contrib CVS CVSROOT docbook-support ecperf hibernate javassist jaxrpc jboss jboss-3.2 JBoss-3.2 jboss-admin-console jboss-all jboss-aop jboss-aop-eclipse jbossas jboss-aspects jboss-blocks jbossbuild jboss-cache JBossCache jboss-common jboss-compatibility jboss-console jbosscx jboss_deployment jboss-deployment jboss-docs jboss-ejb jboss-ejb3 jboss-ejb3x jboss-head jbosside jboss-j2ee jboss-j2se jboss-jms jboss-mail jboss-management jboss-mbeans jboss-media jbossmq jbossmqadmin jbossmqbench jbossmx jboss-persistence jbosspool jboss-portal jboss-portal-docs _jboss-portal-setup jboss-portal-thirdparty jboss-portal-tools jboss-profiler jboss-remoting JBossRemoting jboss-seam jboss-site jbosssx jboss-system jbosstest jboss-tomcat jboss-transaction jboss-v3.2.x jboss-xdoclet jbportal-upgrade jmx jmx2 jmx-remoting jnp jrunit junitejb manual microkernel netboot-demo newsite nukes nukes-2 nukes-2-thirdparty nukes-docs nukes-thirdparty nukes-tools nukes-website opennms person pn-website repository.jboss.com specj sun-ejb system2 test thirdparty tools tools-win32 webservice website website-forums website-snapshots website-survey wiki2html xpetstore-ejb3 xpetstore-ejb3.0 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Elrod Sent: Tuesday, May 10, 2005 11:42 AM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] creating jboss thirdparty directory I have the old build ready locally for both the jboss-head and JBossRemoting. Now I need to change the CVSROOT/modules file. I want to take the _jboss_remoting module (the current one under jboss-head) and rename the alias to something like remoting-integration. Could really use suggestions for a better name. This will contain only the integration code between JBossRemoting and JBossAS. Then I will declare another entry for JBossRemoting, which has the old alias remoting. This is so the new build will work. I will also need to add a new component for the remoting-integration. So, the new CVSROOT/modules would have the following entries: _jboss_remoting -d remoting-integration jboss-remoting-integration JBossRemoting -d remoting jboss-remoting Will also have to change the component declarations within the new build to have: component id=remoting-integration module=jboss-remoting-integration version=5.0-SNAPSHOT artifact id=jboss-remoting-integration.jar release=server/all/lib/ /component component id=remoting module=jboss-remoting version=5.0-SNAPSHOT artifact id=jboss-remoting.jar release=server/all/lib/ /component I don't think the JBossRemoting project is getting built via cruise control, so the jboss-remoting.jar snapshot will not be getting updated until we can get this added. Will also need to have it add jboss-remoting-integration.jar as well. Is there anything else I am missing for this to work? Once this change is made, am not sure exactly what people will need to get the update view of the source. Go to jboss-head root directory and run 'cvs co remoting'? Guess will need to do same thing for thirdparty (to get thirdparty/jboss/remoting/lib/jboss-remoting.jar)? --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com
Re: [JBoss-dev] creating jboss thirdparty directory
Now the problem is how we get there. Its going to take the creation of a jbossas cvs module and copying the existing inherent and integration code modules into jbossas so as not to lose cvs history. As features like remoting and cache are broken out, we add the integration code to the jbossas module, and import the binaries using component references. I think we are there. There is already a jbossas module defined with nothing but the new build in it. Remoting is ready to make this move (no better time actually). If you give the green light, I will execute what I have described below and we will be on our way to this new path. As other projects break off, they can do the same. I think with the new build process, it would also be a big help to network as will have modular, versioned components that will be easier to do patch updates for. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Elrod Sent: Tuesday, May 10, 2005 12:55 PM To: jboss-development@lists.sourceforge.net Subject: Re: [JBoss-dev] creating jboss thirdparty directory So you want? 1. The jboss-head/remoting directory and its contents (which now only contains integration code on my local disk) to be moved under the jboss-head/jbossas directory (including src/main and src/tests). 2. Then update the jbossas build so it will be its new remoting subdirectory. 3. Remove the jboss-head/remoting directory (thus making it dead in jboss-head). I can't remove the _jboss_remoting module reference from within the jboss-head project definition because of previous versions will still need to have it available, right? (based on some tag earlier on jboss-head). 4. Change the component definition for remoting to use module=JBossRemoting instead of module=jboss-remoting within the new build. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_ids93alloc_id281op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] creating jboss thirdparty directory
Since I am now doing all new development in the JBossRemoting module, which is stand alone, I would like to make a few changes as to how jboss-head picks up the remoting code. First, I would like to make the remoting code visible to jboss-head as a binary. For the old build, this means adding it to the thirdparty directory and changing the old build scripts for the modules that need remoting to include the remoting jar from the thirdparty directory. I was going to create a new directory that looked something like: thirdparty/jboss/remoting/lib/jboss-remoting.jar For the new build, can just include the pointer to the repository for the remoting jar. I also want to keep the jboss-head/remoting directory, but make it contain the code for integration between JBossAS and JBossRemoting. So I will be removing almost all of the code that is currently there (which is the core remoting code currently). Please let me know if this is going to be a problem or if you have any other suggestions on how to do this. Thanks. -Tom --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBREM-101) Fix serialization versioning between releases of remoting
[ http://jira.jboss.com/jira/browse/JBREM-101?page=history ] Tom Elrod resolved JBREM-101: -- Resolution: Done Should be up to date and in sync with remoting release in JBossAS 4 series (based on 4.0.1 and 4.0.2 release). Fix serialization versioning between releases of remoting - Key: JBREM-101 URL: http://jira.jboss.com/jira/browse/JBREM-101 Project: JBoss Remoting Type: Task Components: general Versions: 1.0.2 final Reporter: Tom Elrod Assignee: Tom Elrod Fix For: 1.1.0 beta Need to fix the classes that will be passed over the wire so that they contain serialVersionUID and versioning for Externalizable classes to allowed for release version 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-101) Fix serialization versioning between releases of remoting
Fix serialization versioning between releases of remoting - Key: JBREM-101 URL: http://jira.jboss.com/jira/browse/JBREM-101 Project: JBoss Remoting Type: Task Components: general Versions: 1.0.2 final Reporter: Tom Elrod Assigned to: Tom Elrod Fix For: 1.1.0 beta Need to fix the classes that will be passed over the wire so that they contain serialVersionUID and versioning for Externalizable classes to allowed for release version 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBREM-86) finish RMIJRMPServerImpl implementation
[ http://jira.jboss.com/jira/browse/JBREM-86?page=history ] Tom Elrod closed JBREM-86: --- Resolution: Done All methods implemented. finish RMIJRMPServerImpl implementation --- Key: JBREM-86 URL: http://jira.jboss.com/jira/browse/JBREM-86 Project: JBoss Remoting Type: Task Components: jmx remoting Versions: JMX Remoting 1.0.1 Reporter: Tom Elrod Assignee: Tom Elrod Fix For: JMX Remoting 1.0.1 Original Estimate: 2 days Remaining: 2 days A few methods yet to be implemented. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBREM-78) RMIConnector implementation
[ http://jira.jboss.com/jira/browse/JBREM-78?page=comments#action_12316825 ] Tom Elrod commented on JBREM-78: - Finished all implementation besides notification handling, which needs to be implemented throughout. RMIConnector implementation --- Key: JBREM-78 URL: http://jira.jboss.com/jira/browse/JBREM-78 Project: JBoss Remoting Type: Task Components: jmx remoting Versions: JMX Remoting 1.0.1 Reporter: Tom Elrod Assignee: Tom Elrod Priority: Critical Fix For: JMX Remoting 1.0.1 Original Estimate: 1 week, 3 days Remaining: 1 week, 3 days Implement RMIConnector per spec (which is required protocol). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBREM-76) Classloading support
[ http://jira.jboss.com/jira/browse/JBREM-76?page=history ] Tom Elrod closed JBREM-76: --- Resolution: Done This has been implemented throughout the RMI implementation (will need to add into any new transport implementations). Classloading support Key: JBREM-76 URL: http://jira.jboss.com/jira/browse/JBREM-76 Project: JBoss Remoting Type: Task Components: jmx remoting Versions: JMX Remoting 1.0.1 Reporter: Tom Elrod Assignee: Tom Elrod Fix For: JMX Remoting 1.0.1 Original Estimate: 1 week, 3 days Remaining: 1 week, 3 days Need support for class loading as defined in spec (section 2.11). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBREM-74) Notification support
[ http://jira.jboss.com/jira/browse/JBREM-74?page=comments#action_12316827 ] Tom Elrod commented on JBREM-74: - Pretty much all the other core calls have been implemented except the notification handling. All the notification methods have been stubbed out to throw runtime exceptions saying that that method has not yet been implemented. Also noted by TODO: -TME Implement comments. Notification support Key: JBREM-74 URL: http://jira.jboss.com/jira/browse/JBREM-74 Project: JBoss Remoting Type: Task Components: jmx remoting Versions: JMX Remoting 1.0.1 Reporter: Tom Elrod Assignee: Tom Elrod Fix For: JMX Remoting 1.0.1 Original Estimate: 1 week Remaining: 1 week Remote notifications support, including notification buffer. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBREM-93) Callback handler returning a generic Object
[ http://jira.jboss.com/jira/browse/JBREM-93?page=comments#action_12316828 ] Tom Elrod commented on JBREM-93: - I don't think this is documented anywhere. The real problem lies in that there can be many exceptions that are raised that have nothing to do with the actual callback handler receiving the callback (i.e. network connection problem). Another major issue is that the client may get the callbacks by polling, so even if the client has a problem processing the callback, there is no way to provide this feedback to server (and is up to client if is push or pull, so no way for server side to rely on this behavior). I would prefer to change the HandleCallbackException than return an Object from the handleCallback() method because of the forementioned problem of not knowing if is push or pull (as would always have to return some default value if was pull, like null, since would not be able to get it from the client till sometime later). So if I added something to HandleCallbackException like getUserException() which would return original exception thrown by client (if there was one, otherwise return null), would that work? Also, would it be useful to provide a way of knowing if CallbackHandler is using pull or push model? Maybe a use case would help me understand what you are after a little better. Callback handler returning a generic Object --- Key: JBREM-93 URL: http://jira.jboss.com/jira/browse/JBREM-93 Project: JBoss Remoting Type: Feature Request Components: callbacks Reporter: Ovidiu Feodorov Assignee: Tom Elrod Priority: Optional InvokerCallbackHandler.handleCallback() returns void. However, is is able to throw a HandleCallbackException that ultimately reaches the calling party. I was wondering if it is a big deal to have handleCallback() returning a generic Object. This would make the handleCallback()'s semantics more flexible. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBREM-96) Get stand alone build working
[ http://jira.jboss.com/jira/browse/JBREM-96?page=comments#action_12316829 ] Tom Elrod commented on JBREM-96: - Standalone build working, but does not use new jboss build and is static, so will have to change it often to keep up with the other jboss modules (i.e. jboss-common). Get stand alone build working - Key: JBREM-96 URL: http://jira.jboss.com/jira/browse/JBREM-96 Project: JBoss Remoting Type: Sub-task Reporter: Tom Elrod Assignee: Tom Elrod -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBREM-95) Need to clean up lib directory
[ http://jira.jboss.com/jira/browse/JBREM-95?page=comments#action_12316830 ] Tom Elrod commented on JBREM-95: - Is cleaned up as good as it can get for now, but will need to switch to jboss build. Need to clean up lib directory -- Key: JBREM-95 URL: http://jira.jboss.com/jira/browse/JBREM-95 Project: JBoss Remoting Type: Sub-task Components: general Versions: 1.1.0 beta Reporter: Tom Elrod Assignee: Tom Elrod Fix For: 1.1.0 beta Need to clean up lib directory so only using exactly what is needed by remoting. Also need to make sure using the exact versions for jboss binaries for release so no conflict when used within jboss as. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-99) Switch to jboss build
Switch to jboss build - Key: JBREM-99 URL: http://jira.jboss.com/jira/browse/JBREM-99 Project: JBoss Remoting Type: Sub-task Reporter: Tom Elrod Assigned to: Tom Elrod -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-100) Add remoting standalone to CVSROOT/modules
Add remoting standalone to CVSROOT/modules -- Key: JBREM-100 URL: http://jira.jboss.com/jira/browse/JBREM-100 Project: JBoss Remoting Type: Sub-task Reporter: Tom Elrod Assigned to: Tom Elrod -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-98) remove isDebugEnabled() within code as is now depricated
remove isDebugEnabled() within code as is now depricated Key: JBREM-98 URL: http://jira.jboss.com/jira/browse/JBREM-98 Project: JBoss Remoting Type: Task Components: general Versions: 1.0.2 final Reporter: Tom Elrod Assigned to: Tom Elrod Fix For: 1.2.0 beta -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBREM-98) remove isDebugEnabled() within code as is now depricated
[ http://jira.jboss.com/jira/browse/JBREM-98?page=history ] Tom Elrod closed JBREM-98: --- Resolution: Done Either removed the isDebugEnabled() or changed to isTraceEnabled(). remove isDebugEnabled() within code as is now depricated Key: JBREM-98 URL: http://jira.jboss.com/jira/browse/JBREM-98 Project: JBoss Remoting Type: Task Components: general Versions: 1.0.2 final Reporter: Tom Elrod Assignee: Tom Elrod Fix For: 1.2.0 beta -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBREM-93) Callback handler returning a generic Object
[ http://jira.jboss.com/jira/browse/JBREM-93?page=comments#action_12316700 ] Tom Elrod commented on JBREM-93: - It just wraps any Throwable thrown when calling callBackClient.invoke(internalInvocation,callback.getRequestPayload()), so can just get original exception by calling getCause() on the HandleCallbackException thrown. Not sure I understand your request. Is it that you want the original exception throw from callBackClient.invoke() to be throw out of handleCallback() method, without wrapping it? Maybe you can explain use case? Callback handler returning a generic Object --- Key: JBREM-93 URL: http://jira.jboss.com/jira/browse/JBREM-93 Project: JBoss Remoting Type: Feature Request Components: callbacks Reporter: Ovidiu Feodorov Assignee: Tom Elrod Priority: Optional InvokerCallbackHandler.handleCallback() returns void. However, is is able to throw a HandleCallbackException that ultimately reaches the calling party. I was wondering if it is a big deal to have handleCallback() returning a generic Object. This would make the handleCallback()'s semantics more flexible. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBREM-97) Won't compile under JDK 1.5
[ http://jira.jboss.com/jira/browse/JBREM-97?page=history ] Tom Elrod closed JBREM-97: --- Resolution: Done Changed so not using enum keyword for variable names. Everything else is fine. Won't compile under JDK 1.5 --- Key: JBREM-97 URL: http://jira.jboss.com/jira/browse/JBREM-97 Project: JBoss Remoting Type: Bug Components: general Versions: 1.0.2 final Reporter: Tom Elrod Assignee: Tom Elrod Fix For: 1.2.0 beta Need to change so will compile under JDK 1.5 -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-95) Need to clean up lib directory
Need to clean up lib directory -- Key: JBREM-95 URL: http://jira.jboss.com/jira/browse/JBREM-95 Project: JBoss Remoting Type: Sub-task Components: general Versions: 1.2.0 beta Reporter: Tom Elrod Assigned to: Tom Elrod Fix For: 1.2.0 beta Need to clean up lib directory so only using exactly what is needed by remoting. Also need to make sure using the exact versions for jboss binaries for release so no conflict when used within jboss as. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-96) Get stand alone build working
Get stand alone build working - Key: JBREM-96 URL: http://jira.jboss.com/jira/browse/JBREM-96 Project: JBoss Remoting Type: Sub-task Reporter: Tom Elrod Assigned to: Tom Elrod -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBREM-43) custom socket factories
[ http://jira.jboss.com/jira/browse/JBREM-43?page=history ] Tom Elrod updated JBREM-43: Priority: Critical (was: Major) custom socket factories --- Key: JBREM-43 URL: http://jira.jboss.com/jira/browse/JBREM-43 Project: JBoss Remoting Type: Feature Request Components: transport Versions: 1.0.1 beta Reporter: Tom Elrod Assignee: Tom Elrod Priority: Critical Fix For: 1.2.0 beta Add support for custom socket factories for socket invoker (and maybe others) -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-94) callback server specific implementation
callback server specific implementation --- Key: JBREM-94 URL: http://jira.jboss.com/jira/browse/JBREM-94 Project: JBoss Remoting Type: Feature Request Components: callbacks Versions: 1.0.2 final Reporter: Tom Elrod Assigned to: Tom Elrod Fix For: 1.2.0 beta Since it is possible to have a callback server that never receives direct invocations and only callbacks, there is no need for the requirement to have a handler registered for the server (since will never be called upon). Therefore, need to add a callback server specific implementation for this behaviour. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBREM-36) performance tests fail for http transports
[ http://jira.jboss.com/jira/browse/JBREM-36?page=history ] Tom Elrod updated JBREM-36: Fix Version: 1.0.2 final (was: 1.2.0 beta) performance tests fail for http transports -- Key: JBREM-36 URL: http://jira.jboss.com/jira/browse/JBREM-36 Project: JBoss Remoting Type: Bug Components: transport Versions: 1.0.1 beta Reporter: Tom Elrod Assignee: Tom Elrod Fix For: 1.0.2 final Either some of the messages are getting lost or the invoker is so slow that the test finishes before invoker can finish sending messages. Says that it only got about 4900 messages of 5000 it should have. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBREM-36) performance tests fail for http transports
[ http://jira.jboss.com/jira/browse/JBREM-36?page=history ] Tom Elrod resolved JBREM-36: - Resolution: Done Fixed. Tests passing for standard and oneway invocations using the http invoker. performance tests fail for http transports -- Key: JBREM-36 URL: http://jira.jboss.com/jira/browse/JBREM-36 Project: JBoss Remoting Type: Bug Components: transport Versions: 1.0.1 beta Reporter: Tom Elrod Assignee: Tom Elrod Fix For: 1.0.2 final Either some of the messages are getting lost or the invoker is so slow that the test finishes before invoker can finish sending messages. Says that it only got about 4900 messages of 5000 it should have. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-91) UIL2 type transport (duplex calling of same socket)
UIL2 type transport (duplex calling of same socket) --- Key: JBREM-91 URL: http://jira.jboss.com/jira/browse/JBREM-91 Project: JBoss Remoting Type: Feature Request Components: transport Versions: 1.0.2 final Reporter: Tom Elrod Assigned to: Tom Elrod Fix For: 1.2.0 beta Need transport that will allow for calling back from the server to the client using the same socket. This will allow for async callbacks to clients that will not allow outside connections. This is basically the same as the JMS UIL2 transport. Required for JMS implementation. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-87) Add handler metadata to detection messages
Add handler metadata to detection messages -- Key: JBREM-87 URL: http://jira.jboss.com/jira/browse/JBREM-87 Project: JBoss Remoting Type: Feature Request Components: detection Versions: 1.0.1 final Reporter: Tom Elrod Assigned to: Tom Elrod Fix For: 1.2.0 beta Need ability to provide more information in the Detection message about the server invoker's handlers. Should include subsystem and other metadata that the handler supplies. This would then be included in the NetworkNotification that the NetworkRegistry emits upon detection of new servers (also returned in the NetworkRegistry::getServers() call). See http://www.jboss.org/index.html?module=bbop=viewtopict=61823 for more info. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBREM-83) Updated Invocation marshalling to support standard payloads
[ http://jira.jboss.com/jira/browse/JBREM-83?page=history ] Tom Elrod updated JBREM-83: Fix Version: 1.0.2 final (was: 1.2.0 beta) Updated Invocation marshalling to support standard payloads --- Key: JBREM-83 URL: http://jira.jboss.com/jira/browse/JBREM-83 Project: JBoss Remoting Type: Task Components: marshall Versions: 1.0.1 final Reporter: Tom Elrod Assignee: Tom Elrod Priority: Critical Fix For: 1.0.2 final Need to update InvocationMarshaller/InvocationUnMarshaller so that if payload not org.jboss.Invocation or org.jboss.MarshalledInvocation, will just marshall/unmarshaller using default parent behavior (SerializableMarshaller/SerializableUnMarshaller). Currently will throw exception otherwise. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBREM-66) Race condition on startup
[ http://jira.jboss.com/jira/browse/JBREM-66?page=history ] Tom Elrod updated JBREM-66: Fix Version: 1.0.2 final (was: 1.2.0 beta) Race condition on startup - Key: JBREM-66 URL: http://jira.jboss.com/jira/browse/JBREM-66 Project: JBoss Remoting Type: Bug Versions: 1.0.1 final Environment: linux, jobss 4.0.1, jdk 1.5_01 Reporter: james ahlborn Assignee: Tom Elrod Priority: Minor Fix For: 1.0.2 final Original Estimate: 1 day Remaining: 1 day I occassionally get this exception trace on jboss startup: 2005-02-25 13:51:26,981 ERROR [org.jboss.remoting.detection.multicast.MulticastD etector] Error during detection of: Detection [identity:JBOSS Identity [address: itsy.hmsonline.com/10.67.89.58,instanceid:9d49962ca1854d0cx21bc15d1x1014159608ax -7fff718,JMX id:itsy.hmsonline.com_1109263894685,domain:JBOSS],locators:2] javax.management.RuntimeOperationsException at org.jboss.mx.server.registry.BasicMBeanRegistry.get(BasicMBeanRegistry.java :495) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:636) at org.jboss.remoting.detection.AbstractDetector.detect(AbstractDetector.java: 327) at org.jboss.remoting.detection.multicast.MulticastDetector.listen(MulticastDe tector.java:212) at org.jboss.remoting.detection.multicast.MulticastDetector.access$100(Multica stDetector.java:32) at org.jboss.remoting.detection.multicast.MulticastDetector$Listener.run(Multi castDetector.java:240) Caused by: java.lang.IllegalArgumentException: null object name ... 6 more I traced it through the 4.0.1 source code, and it seems that the null pointer is the member variable registryObjectName in AbstractDetector.java. this variable only is set during the start() method of this class, and if the value is null, a warning is logged. i don't see this warning, so i am assuming this variable is set to a non-null value during the start() method. this implies that this member variable is sometimes being accessed before the start() method completes. This is probably because the MulticaseDetector$Listener class is running on a separate thread. it should probably block until the outer class is done starting. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBREM-70) Clean up build.xml. Fix .classpath and .project for eclipse
[ http://jira.jboss.com/jira/browse/JBREM-70?page=history ] Tom Elrod updated JBREM-70: Fix Version: 1.0.2 final (was: 1.2.0 beta) Clean up build.xml. Fix .classpath and .project for eclipse --- Key: JBREM-70 URL: http://jira.jboss.com/jira/browse/JBREM-70 Project: JBoss Remoting Type: Task Components: general Versions: 1.0.1 final Environment: Debian Sarge Eclipse Version: 3.0.1 Reporter: karan malhi Assignee: karan malhi Priority: Trivial Fix For: 1.0.2 final Attachments: .classpath, .project, Eclipse-HowTo.txt Original Estimate: 1 hour Remaining: 1 hour build.xml contains dependencies on j2ee, jaxrpc and transaction projects which are not used by remoting. remove those entries. For eclipse usage, the .classpath has to be fixed to use a variable name instead of the relative path. This fix would assume that the user checked out Remoting as part of the jboss head. When JBREM 20 and JBREM 11 are finished, this classpath setting would change. .project doesnt need to have projects listed in there. Eclipse should just depend on jars instead of making seperate projects and adding dependencies to those projects. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBREM-82) Bad warning in Connector.
[ http://jira.jboss.com/jira/browse/JBREM-82?page=history ]
Tom Elrod resolved JBREM-82:
-
Resolution: Done
Moved from 1.2.0 beta to 1.0.2 final release.
Bad warning in Connector.
-
Key: JBREM-82
URL: http://jira.jboss.com/jira/browse/JBREM-82
Project: JBoss Remoting
Type: Bug
Components: transport
Versions: 1.2.0 beta
Environment: In Jboss Head (CVS)
Reporter: rimmeraj
Assignee: Tom Elrod
Priority: Minor
Fix For: 1.0.2 final
JBoss head:
remoting/src/main/org/jboss/remoting/transport/Connector.java , start method
after you create the server invoker you try to register it with the mbean
server. If it fails you register a warning. When you are using the ejb3
deployers it registers its own socket Connector. It is quite legal to have
the standard Connector in conf/jboss-service.xml registers a socket
protocol. The EJB3 deployer registers a socket listener on a different port.
This triggers an annoying warning that in my option is more of a programming
error that a valid warning.
Warning.
Error registering invoker [EMAIL PROTECTED] with MBeanServer.
javax.management.InstanceAlreadyExistsException:
jboss.remoting:service=invoker,transport=socket already registered.
Suggested Fix.
1. org/jboss/remoting/transport/InvokerRegistry.java, createServerInvoker
should log a warning if the InvokerLocator is already found.
2. Connector.java, start should check to see if the object name is not
registered before trying. Something like
ObjectName name=new ObjectName(invoker.getMBeanObjectName());
try
{
server.getInstance(name);
}
catch(InstanceNotFoundException e)
{
server.registerMBean(invoker, name);
invoker.setMBeanServer(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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) Windows Mobile(tm) platforms, applications content. Register
by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Reopened: (JBREM-82) Bad warning in Connector.
[ http://jira.jboss.com/jira/browse/JBREM-82?page=history ]
Tom Elrod reopened JBREM-82:
-
Reopening to move to 1.0.2 release.
Bad warning in Connector.
-
Key: JBREM-82
URL: http://jira.jboss.com/jira/browse/JBREM-82
Project: JBoss Remoting
Type: Bug
Components: transport
Versions: 1.2.0 beta
Environment: In Jboss Head (CVS)
Reporter: rimmeraj
Assignee: Tom Elrod
Priority: Minor
Fix For: 1.0.2 final
JBoss head:
remoting/src/main/org/jboss/remoting/transport/Connector.java , start method
after you create the server invoker you try to register it with the mbean
server. If it fails you register a warning. When you are using the ejb3
deployers it registers its own socket Connector. It is quite legal to have
the standard Connector in conf/jboss-service.xml registers a socket
protocol. The EJB3 deployer registers a socket listener on a different port.
This triggers an annoying warning that in my option is more of a programming
error that a valid warning.
Warning.
Error registering invoker [EMAIL PROTECTED] with MBeanServer.
javax.management.InstanceAlreadyExistsException:
jboss.remoting:service=invoker,transport=socket already registered.
Suggested Fix.
1. org/jboss/remoting/transport/InvokerRegistry.java, createServerInvoker
should log a warning if the InvokerLocator is already found.
2. Connector.java, start should check to see if the object name is not
registered before trying. Something like
ObjectName name=new ObjectName(invoker.getMBeanObjectName());
try
{
server.getInstance(name);
}
catch(InstanceNotFoundException e)
{
server.registerMBean(invoker, name);
invoker.setMBeanServer(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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) Windows Mobile(tm) platforms, applications content. Register
by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBREM-82) Bad warning in Connector.
[ http://jira.jboss.com/jira/browse/JBREM-82?page=history ]
Tom Elrod updated JBREM-82:
Fix Version: 1.0.2 final
(was: 1.2.0 beta)
Bad warning in Connector.
-
Key: JBREM-82
URL: http://jira.jboss.com/jira/browse/JBREM-82
Project: JBoss Remoting
Type: Bug
Components: transport
Versions: 1.2.0 beta
Environment: In Jboss Head (CVS)
Reporter: rimmeraj
Assignee: Tom Elrod
Priority: Minor
Fix For: 1.0.2 final
JBoss head:
remoting/src/main/org/jboss/remoting/transport/Connector.java , start method
after you create the server invoker you try to register it with the mbean
server. If it fails you register a warning. When you are using the ejb3
deployers it registers its own socket Connector. It is quite legal to have
the standard Connector in conf/jboss-service.xml registers a socket
protocol. The EJB3 deployer registers a socket listener on a different port.
This triggers an annoying warning that in my option is more of a programming
error that a valid warning.
Warning.
Error registering invoker [EMAIL PROTECTED] with MBeanServer.
javax.management.InstanceAlreadyExistsException:
jboss.remoting:service=invoker,transport=socket already registered.
Suggested Fix.
1. org/jboss/remoting/transport/InvokerRegistry.java, createServerInvoker
should log a warning if the InvokerLocator is already found.
2. Connector.java, start should check to see if the object name is not
registered before trying. Something like
ObjectName name=new ObjectName(invoker.getMBeanObjectName());
try
{
server.getInstance(name);
}
catch(InstanceNotFoundException e)
{
server.registerMBean(invoker, name);
invoker.setMBeanServer(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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005
Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows
Embedded(r) Windows Mobile(tm) platforms, applications content. Register
by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-88) HTTP invoker only binds to localhost
HTTP invoker only binds to localhost Key: JBREM-88 URL: http://jira.jboss.com/jira/browse/JBREM-88 Project: JBoss Remoting Type: Bug Components: transport Versions: 1.0.1 final Reporter: Tom Elrod Assigned to: Tom Elrod Priority: Blocker Fix For: 1.0.2 final Bug in HTTPInvokerServer where would only bind to localhost. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-90) HTTP header values not being picked up on the http invoker server
HTTP header values not being picked up on the http invoker server - Key: JBREM-90 URL: http://jira.jboss.com/jira/browse/JBREM-90 Project: JBoss Remoting Type: Bug Components: transport Versions: 1.0.1 final Reporter: Tom Elrod Assigned to: Tom Elrod Fix For: 1.0.2 final The HTTPServerInvoker was not picking up the headers properly and putting into the metadata map being passed to both the unmarshaller and the handler. The value in the metadata was actually the header key (so header name put in as key and value). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBREM-88) HTTP invoker only binds to localhost
[ http://jira.jboss.com/jira/browse/JBREM-88?page=history ] Tom Elrod resolved JBREM-88: - Resolution: Done Have fixed so will use the host specified by the locator url to bind to. HTTP invoker only binds to localhost Key: JBREM-88 URL: http://jira.jboss.com/jira/browse/JBREM-88 Project: JBoss Remoting Type: Bug Components: transport Versions: 1.0.1 final Reporter: Tom Elrod Assignee: Tom Elrod Priority: Blocker Fix For: 1.0.2 final Bug in HTTPInvokerServer where would only bind to localhost. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBREM-89) HTTPUnMarshaller finishing read early
[ http://jira.jboss.com/jira/browse/JBREM-89?page=history ] Tom Elrod resolved JBREM-89: - Resolution: Done Fixed by taking the content-length value from the header (via metadata passed) to figure out what the total amount read should be. HTTPUnMarshaller finishing read early - Key: JBREM-89 URL: http://jira.jboss.com/jira/browse/JBREM-89 Project: JBoss Remoting Type: Bug Components: marshall Versions: 1.0.1 final Reporter: Tom Elrod Assignee: Tom Elrod Priority: Critical Fix For: 1.0.2 final There is a bug in the HTTPUnMarshaller where it would get ahead of the client sending bytes and think that it was done reading and finsih (before all the data was sent to the server from the client). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBREM-90) HTTP header values not being picked up on the http invoker server
[ http://jira.jboss.com/jira/browse/JBREM-90?page=history ] Tom Elrod resolved JBREM-90: - Resolution: Done Fixed so will get the header value instead of the header name for the value of the metadata map. HTTP header values not being picked up on the http invoker server - Key: JBREM-90 URL: http://jira.jboss.com/jira/browse/JBREM-90 Project: JBoss Remoting Type: Bug Components: transport Versions: 1.0.1 final Reporter: Tom Elrod Assignee: Tom Elrod Fix For: 1.0.2 final The HTTPServerInvoker was not picking up the headers properly and putting into the metadata map being passed to both the unmarshaller and the handler. The value in the metadata was actually the header key (so header name put in as key and value). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- This SF.net email is sponsored by Microsoft Mobile Embedded DevCon 2005 Attend MEDC 2005 May 9-12 in Vegas. Learn more about the latest Windows Embedded(r) Windows Mobile(tm) platforms, applications content. Register by 3/29 save $300 http://ads.osdn.com/?ad_id=6883alloc_id=15149op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-85) implement RMI IIOP
implement RMI IIOP -- Key: JBREM-85 URL: http://jira.jboss.com/jira/browse/JBREM-85 Project: JBoss Remoting Type: Task Components: jmx remoting Versions: JMX Remoting 1.0.1 Reporter: Tom Elrod Assigned to: Tom Elrod Fix For: JMX Remoting 1.0.1 Need to implement RMIIIOPServerImpl (just stubbed out for now) as well as IIOP specific bindings in RMIConnectorServer (just a TODO in code for this). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-86) finish RMIJRMPServerImpl implementation
finish RMIJRMPServerImpl implementation --- Key: JBREM-86 URL: http://jira.jboss.com/jira/browse/JBREM-86 Project: JBoss Remoting Type: Task Components: jmx remoting Versions: JMX Remoting 1.0.1 Reporter: Tom Elrod Assigned to: Tom Elrod Fix For: JMX Remoting 1.0.1 A few methods yet to be implemented. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-83) Updated Invocation marshalling to support standard payloads
Updated Invocation marshalling to support standard payloads --- Key: JBREM-83 URL: http://jira.jboss.com/jira/browse/JBREM-83 Project: JBoss Remoting Type: Task Components: marshall Versions: 1.0.1 final Reporter: Tom Elrod Assigned to: Tom Elrod Priority: Critical Fix For: 1.2.0 beta Need to update InvocationMarshaller/InvocationUnMarshaller so that if payload not org.jboss.Invocation or org.jboss.MarshalledInvocation, will just marshall/unmarshaller using default parent behavior (SerializableMarshaller/SerializableUnMarshaller). Currently will throw exception otherwise. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBREM-82) Bad warning in Connector.
[ http://jira.jboss.com/jira/browse/JBREM-82?page=history ]
Tom Elrod closed JBREM-82:
---
Resolution: Done
Fix Version: 1.2.0 beta
Have updated the ObjectName generated for the server invoker to be unique to
the locator uri so that if a new server invoker is created by the
InvokerRegistry, then that invoker will be registered with the MBeanServer. If
InvokerRegistry does not create a new server invoker, but returns an existing
one because the locator uri was the same, then it will not re-register that
invoker with the MBeanServer.
Bad warning in Connector.
-
Key: JBREM-82
URL: http://jira.jboss.com/jira/browse/JBREM-82
Project: JBoss Remoting
Type: Bug
Components: transport
Versions: 1.2.0 beta
Environment: In Jboss Head (CVS)
Reporter: rimmeraj
Assignee: Tom Elrod
Priority: Minor
Fix For: 1.2.0 beta
JBoss head:
remoting/src/main/org/jboss/remoting/transport/Connector.java , start method
after you create the server invoker you try to register it with the mbean
server. If it fails you register a warning. When you are using the ejb3
deployers it registers its own socket Connector. It is quite legal to have
the standard Connector in conf/jboss-service.xml registers a socket
protocol. The EJB3 deployer registers a socket listener on a different port.
This triggers an annoying warning that in my option is more of a programming
error that a valid warning.
Warning.
Error registering invoker [EMAIL PROTECTED] with MBeanServer.
javax.management.InstanceAlreadyExistsException:
jboss.remoting:service=invoker,transport=socket already registered.
Suggested Fix.
1. org/jboss/remoting/transport/InvokerRegistry.java, createServerInvoker
should log a warning if the InvokerLocator is already found.
2. Connector.java, start should check to see if the object name is not
registered before trying. Something like
ObjectName name=new ObjectName(invoker.getMBeanObjectName());
try
{
server.getInstance(name);
}
catch(InstanceNotFoundException e)
{
server.registerMBean(invoker, name);
invoker.setMBeanServer(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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click
___
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-84) Duplicate Connector shutdown using same server invoker
Duplicate Connector shutdown using same server invoker -- Key: JBREM-84 URL: http://jira.jboss.com/jira/browse/JBREM-84 Project: JBoss Remoting Type: Bug Components: general Versions: 1.0.1 final Reporter: Tom Elrod Assigned to: Tom Elrod Fix For: 1.2.0 beta if shutdown a connector that is using the same server invoker as another connector, will be shutting down the server invoker underneath the other connector (without warning or notification). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBREM-83) Updated Invocation marshalling to support standard payloads
[ http://jira.jboss.com/jira/browse/JBREM-83?page=history ] Tom Elrod resolved JBREM-83: - Resolution: Done Updated the InvocationMarshaller so will allow for non org.jboss.Invocation payloads. Should be able to send any Serialiable payloads and responses using datatype=invocation. This is not really for the remoting release as these marshallers have been moved under the server module where they belong. Updated Invocation marshalling to support standard payloads --- Key: JBREM-83 URL: http://jira.jboss.com/jira/browse/JBREM-83 Project: JBoss Remoting Type: Task Components: marshall Versions: 1.0.1 final Reporter: Tom Elrod Assignee: Tom Elrod Priority: Critical Fix For: 1.2.0 beta Need to update InvocationMarshaller/InvocationUnMarshaller so that if payload not org.jboss.Invocation or org.jboss.MarshalledInvocation, will just marshall/unmarshaller using default parent behavior (SerializableMarshaller/SerializableUnMarshaller). Currently will throw exception otherwise. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBREM-8) Ability to stream files via remoting
[ http://jira.jboss.com/jira/browse/JBREM-8?page=history ] Tom Elrod updated JBREM-8: --- Priority: Major (was: Minor) Ability to stream files via remoting Key: JBREM-8 URL: http://jira.jboss.com/jira/browse/JBREM-8 Project: JBoss Remoting Type: Feature Request Components: general Versions: 1.0.1 alpha Reporter: Tom Elrod Assignee: Tom Elrod Fix For: 1.2.0 beta Would like to add ability for user to stream files using remoting. Initially requested by Dimitris for deploying files from management console using remoting. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-71) Find JMXConnectorProvider as a service
Find JMXConnectorProvider as a service -- Key: JBREM-71 URL: http://jira.jboss.com/jira/browse/JBREM-71 Project: JBoss Remoting Type: Feature Request Components: jmx remoting Versions: JMX Remoting 1.0.1 Reporter: Tom Elrod Assigned to: Tom Elrod Priority: Optional Per javadoc for JMXConnectorFactory: An implementation may choose to find providers by other means. For example, it may support the JAR conventions for service providers, where the service interface is JMXConnectorProvider. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-72) Implement provider for rmi and iiop protocols
Implement provider for rmi and iiop protocols - Key: JBREM-72 URL: http://jira.jboss.com/jira/browse/JBREM-72 Project: JBoss Remoting Type: Task Components: jmx remoting Versions: JMX Remoting 1.0.1 Reporter: Tom Elrod Assigned to: Tom Elrod Fix For: JMX Remoting 1.0.1 Per spec, Every implementation must support the RMI connector protocols, specified with the string rmi or iiop. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-73) JMXMP connector implementation
JMXMP connector implementation -- Key: JBREM-73 URL: http://jira.jboss.com/jira/browse/JBREM-73 Project: JBoss Remoting Type: Feature Request Components: jmx remoting Versions: JMX Remoting 1.0.1 Reporter: Tom Elrod Assigned to: Tom Elrod Priority: Optional Per spec, the JMX Messaging Protocol (JMXMP) is optional. However, is important to include after completion of RMIConnector (which is required). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-74) Notification support
Notification support Key: JBREM-74 URL: http://jira.jboss.com/jira/browse/JBREM-74 Project: JBoss Remoting Type: Task Components: jmx remoting Versions: JMX Remoting 1.0.1 Reporter: Tom Elrod Assigned to: Tom Elrod Fix For: JMX Remoting 1.0.1 Remote notifications support, including notification buffer. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBREM-73) JMXMP connector implementation
[ http://jira.jboss.com/jira/browse/JBREM-73?page=history ] Tom Elrod updated JBREM-73: Original Estimate: 288000 Remaining Estimate: 288000 JMXMP connector implementation -- Key: JBREM-73 URL: http://jira.jboss.com/jira/browse/JBREM-73 Project: JBoss Remoting Type: Feature Request Components: jmx remoting Versions: JMX Remoting 1.0.1 Reporter: Tom Elrod Assignee: Tom Elrod Priority: Optional Original Estimate: 2 weeks Remaining: 2 weeks Per spec, the JMX Messaging Protocol (JMXMP) is optional. However, is important to include after completion of RMIConnector (which is required). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-75) Termination detection
Termination detection - Key: JBREM-75 URL: http://jira.jboss.com/jira/browse/JBREM-75 Project: JBoss Remoting Type: Task Components: jmx remoting Versions: JMX Remoting 1.0.1 Reporter: Tom Elrod Assigned to: Tom Elrod Fix For: JMX Remoting 1.0.1 Need to be support client termination in regards to notification management. This includes abnormal termination detection. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-77) Connector server security
Connector server security - Key: JBREM-77 URL: http://jira.jboss.com/jira/browse/JBREM-77 Project: JBoss Remoting Type: Task Components: jmx remoting Versions: JMX Remoting 1.0.1 Reporter: Tom Elrod Assigned to: Tom Elrod Priority: Minor Fix For: JMX Remoting 1.0.1 Support for connector server security as per spec (section 2.12). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-76) Classloading support
Classloading support Key: JBREM-76 URL: http://jira.jboss.com/jira/browse/JBREM-76 Project: JBoss Remoting Type: Task Components: jmx remoting Versions: JMX Remoting 1.0.1 Reporter: Tom Elrod Assigned to: Tom Elrod Fix For: JMX Remoting 1.0.1 Need support for class loading as defined in spec (section 2.11). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-78) RMIConnector implementation
RMIConnector implementation --- Key: JBREM-78 URL: http://jira.jboss.com/jira/browse/JBREM-78 Project: JBoss Remoting Type: Task Components: jmx remoting Versions: JMX Remoting 1.0.1 Reporter: Tom Elrod Assigned to: Tom Elrod Priority: Critical Fix For: JMX Remoting 1.0.1 Implement RMIConnector per spec (which is required protocol). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-79) Generic connector implementation
Generic connector implementation Key: JBREM-79 URL: http://jira.jboss.com/jira/browse/JBREM-79 Project: JBoss Remoting Type: Task Components: jmx remoting Versions: JMX Remoting 1.0.1 Reporter: Tom Elrod Assigned to: Tom Elrod Priority: Minor Fix For: JMX Remoting 1.0.1 Need generic connector implementation (need for JMXMP). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-80) JNDI discovery
JNDI discovery -- Key: JBREM-80 URL: http://jira.jboss.com/jira/browse/JBREM-80 Project: JBoss Remoting Type: Task Components: jmx remoting Versions: JMX Remoting 1.0.1 Reporter: Tom Elrod Assigned to: Tom Elrod Priority: Minor Fix For: JMX Remoting 1.0.1 Would like to have service discovery via JNDI. May also want to include jboss service to perform bindings for server automatically. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-81) Remoting discovery
Remoting discovery -- Key: JBREM-81 URL: http://jira.jboss.com/jira/browse/JBREM-81 Project: JBoss Remoting Type: Task Components: jmx remoting Versions: JMX Remoting 1.0.1 Reporter: Tom Elrod Assigned to: Tom Elrod Fix For: JMX Remoting 1.0.1 Discovery using JBoss Remoting detectors. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Resolved: (JBREM-72) Implement provider for rmi and iiop protocols
[ http://jira.jboss.com/jira/browse/JBREM-72?page=history ] Tom Elrod resolved JBREM-72: - Resolution: Done Implement provider for rmi and iiop protocols - Key: JBREM-72 URL: http://jira.jboss.com/jira/browse/JBREM-72 Project: JBoss Remoting Type: Task Components: jmx remoting Versions: JMX Remoting 1.0.1 Reporter: Tom Elrod Assignee: Tom Elrod Fix For: JMX Remoting 1.0.1 Per spec, Every implementation must support the RMI connector protocols, specified with the string rmi or iiop. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Closed: (JBREM-69) Implement JMXServiceURl
[ http://jira.jboss.com/jira/browse/JBREM-69?page=history ] Tom Elrod closed JBREM-69: --- Resolution: Done Implementation finished and should be compliant. As for default protocol, am asking jsr 255 group to clarify (but think indirectly means have to have jmxmp implementation). As for default port, means default for protocol being used. Implement JMXServiceURl --- Key: JBREM-69 URL: http://jira.jboss.com/jira/browse/JBREM-69 Project: JBoss Remoting Type: Task Components: jmx remoting Reporter: Tom Elrod Assignee: Tom Elrod Priority: Critical Fix For: JMX Remoting 1.0.1 Original Estimate: 6 hours Remaining: 6 hours Per spec, need following requirements met: - prefix of service:jmx:; - string of one or more ASCII characters, each of which is a letter, a digit, or one of the characters + or - (for protocol) - Uppercase letters are converted into lowercase ones (for protocol) - host is a host name, an IPv4 numeric host address, or an IPv6 numeric address enclosed in square brackets - port is a decimal port number. 0 means a default or anonymous port, depending on the protocol - port cannot be supplied without a host - url-path, if any, begins with a slash (/) or a semicolon (;) and continues to the end of the address. It can contain attributes using the semicolon syntax specified in RFC 2609. Those attributes are not parsed by this class and incorrect attribute syntax is not detected -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBREM-70) Clean up build.xml. Fix .classpath and .project for eclipse
[ http://jira.jboss.com/jira/browse/JBREM-70?page=comments#action_12316043 ] Tom Elrod commented on JBREM-70: - Nope. I have removed them and checked in a new build.xml. Clean up build.xml. Fix .classpath and .project for eclipse --- Key: JBREM-70 URL: http://jira.jboss.com/jira/browse/JBREM-70 Project: JBoss Remoting Type: Task Components: general Environment: Debian Sarge Eclipse Version: 3.0.1 Reporter: karan malhi Assignee: karan malhi Priority: Trivial Original Estimate: 1 hour Remaining: 1 hour build.xml contains dependencies on j2ee, jaxrpc and transaction projects which are not used by remoting. remove those entries. For eclipse usage, the .classpath has to be fixed to use a variable name instead of the relative path. This fix would assume that the user checked out Remoting as part of the jboss head. When JBREM 20 and JBREM 11 are finished, this classpath setting would change. .project doesnt need to have projects listed in there. Eclipse should just depend on jars instead of making seperate projects and adding dependencies to those projects. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBREM-70) Clean up build.xml. Fix .classpath and .project for eclipse
[ http://jira.jboss.com/jira/browse/JBREM-70?page=history ] Tom Elrod updated JBREM-70: Version: 1.0.1 final Fix Version: 1.2.0 beta Clean up build.xml. Fix .classpath and .project for eclipse --- Key: JBREM-70 URL: http://jira.jboss.com/jira/browse/JBREM-70 Project: JBoss Remoting Type: Task Components: general Versions: 1.0.1 final Environment: Debian Sarge Eclipse Version: 3.0.1 Reporter: karan malhi Assignee: karan malhi Priority: Trivial Fix For: 1.2.0 beta Original Estimate: 1 hour Remaining: 1 hour build.xml contains dependencies on j2ee, jaxrpc and transaction projects which are not used by remoting. remove those entries. For eclipse usage, the .classpath has to be fixed to use a variable name instead of the relative path. This fix would assume that the user checked out Remoting as part of the jboss head. When JBREM 20 and JBREM 11 are finished, this classpath setting would change. .project doesnt need to have projects listed in there. Eclipse should just depend on jars instead of making seperate projects and adding dependencies to those projects. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-69) Implement JMXServiceURl
Implement JMXServiceURl --- Key: JBREM-69 URL: http://jira.jboss.com/jira/browse/JBREM-69 Project: JBoss Remoting Type: Task Components: jmx remoting Reporter: Tom Elrod Assigned to: Tom Elrod Priority: Critical Fix For: JMX Remoting 1.0.1 Per spec, need following requirements met: - prefix of service:jmx:; - string of one or more ASCII characters, each of which is a letter, a digit, or one of the characters + or - - Uppercase letters are converted into lowercase ones - host is a host name, an IPv4 numeric host address, or an IPv6 numeric address enclosed in square brackets - port is a decimal port number. 0 means a default or anonymous port, depending on the protocol - port cannot be supplied without a host - url-path, if any, begins with a slash (/) or a semicolon (;) and continues to the end of the address. It can contain attributes using the semicolon syntax specified in RFC 2609. Those attributes are not parsed by this class and incorrect attribute syntax is not detected -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBREM-69) Implement JMXServiceURl
[ http://jira.jboss.com/jira/browse/JBREM-69?page=history ] Tom Elrod updated JBREM-69: Description: Per spec, need following requirements met: - prefix of service:jmx:; - string of one or more ASCII characters, each of which is a letter, a digit, or one of the characters + or - (for protocol) - Uppercase letters are converted into lowercase ones (for protocol) - host is a host name, an IPv4 numeric host address, or an IPv6 numeric address enclosed in square brackets - port is a decimal port number. 0 means a default or anonymous port, depending on the protocol - port cannot be supplied without a host - url-path, if any, begins with a slash (/) or a semicolon (;) and continues to the end of the address. It can contain attributes using the semicolon syntax specified in RFC 2609. Those attributes are not parsed by this class and incorrect attribute syntax is not detected was: Per spec, need following requirements met: - prefix of service:jmx:; - string of one or more ASCII characters, each of which is a letter, a digit, or one of the characters + or - - Uppercase letters are converted into lowercase ones - host is a host name, an IPv4 numeric host address, or an IPv6 numeric address enclosed in square brackets - port is a decimal port number. 0 means a default or anonymous port, depending on the protocol - port cannot be supplied without a host - url-path, if any, begins with a slash (/) or a semicolon (;) and continues to the end of the address. It can contain attributes using the semicolon syntax specified in RFC 2609. Those attributes are not parsed by this class and incorrect attribute syntax is not detected Implement JMXServiceURl --- Key: JBREM-69 URL: http://jira.jboss.com/jira/browse/JBREM-69 Project: JBoss Remoting Type: Task Components: jmx remoting Reporter: Tom Elrod Assignee: Tom Elrod Priority: Critical Fix For: JMX Remoting 1.0.1 Original Estimate: 6 hours Remaining: 6 hours Per spec, need following requirements met: - prefix of service:jmx:; - string of one or more ASCII characters, each of which is a letter, a digit, or one of the characters + or - (for protocol) - Uppercase letters are converted into lowercase ones (for protocol) - host is a host name, an IPv4 numeric host address, or an IPv6 numeric address enclosed in square brackets - port is a decimal port number. 0 means a default or anonymous port, depending on the protocol - port cannot be supplied without a host - url-path, if any, begins with a slash (/) or a semicolon (;) and continues to the end of the address. It can contain attributes using the semicolon syntax specified in RFC 2609. Those attributes are not parsed by this class and incorrect attribute syntax is not detected -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBREM-69) Implement JMXServiceURl
[ http://jira.jboss.com/jira/browse/JBREM-69?page=comments#action_12316009 ] Tom Elrod commented on JBREM-69: - Implementation pretty much done. Only remaining issues are: - is jmxmp required default by spec for the protocol? - what is the default port? Spec says, 0 means a default or anonymous port, depending on the protocol. Assume this mean default port for protocol? For example, 80 for http? Implement JMXServiceURl --- Key: JBREM-69 URL: http://jira.jboss.com/jira/browse/JBREM-69 Project: JBoss Remoting Type: Task Components: jmx remoting Reporter: Tom Elrod Assignee: Tom Elrod Priority: Critical Fix For: JMX Remoting 1.0.1 Original Estimate: 6 hours Remaining: 6 hours Per spec, need following requirements met: - prefix of service:jmx:; - string of one or more ASCII characters, each of which is a letter, a digit, or one of the characters + or - (for protocol) - Uppercase letters are converted into lowercase ones (for protocol) - host is a host name, an IPv4 numeric host address, or an IPv6 numeric address enclosed in square brackets - port is a decimal port number. 0 means a default or anonymous port, depending on the protocol - port cannot be supplied without a host - url-path, if any, begins with a slash (/) or a semicolon (;) and continues to the end of the address. It can contain attributes using the semicolon syntax specified in RFC 2609. Those attributes are not parsed by this class and incorrect attribute syntax is not detected -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Created: (JBREM-68) Add persistent store for oneway messages
Add persistent store for oneway messages Key: JBREM-68 URL: http://jira.jboss.com/jira/browse/JBREM-68 Project: JBoss Remoting Type: Task Components: transport Versions: 1.0.1 final Reporter: Tom Elrod Assigned to: Tom Elrod Priority: Optional Fix For: 1.2.0 beta Need to add ability to persist invocation messages on server when using oneway on the server side. This will ensure that if server crashes and one message has made it to server worker pool, it will be processed when the server is restarted. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Commented: (JBREM-42) two phase deserialization - handler classloading
[ http://jira.jboss.com/jira/browse/JBREM-42?page=comments#action_12315952 ] Tom Elrod commented on JBREM-42: - Need to add API in the ServerInvocationHandler to get the classloader the handler wishes the server invoker to use for classloading. This is already available from the client side. This should resolve problems with loading context specific classes and will fall to the handler to be responsible for providing the correct classloader (or ruturn null if just wants to use the default). two phase deserialization - handler classloading Key: JBREM-42 URL: http://jira.jboss.com/jira/browse/JBREM-42 Project: JBoss Remoting Type: Task Components: general Versions: 1.0.1 beta Reporter: Tom Elrod Assignee: Tom Elrod Fix For: 1.2.0 beta The payload is currently deserialized on the server side (ServerInvoker). Need to only deserialize the remoting specific payload in the ServerInvoker and pass along the still marshaled target payload to the sub-system handler (UnifiedInvoker), since should have the same classloader context as the end target. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBREM-47) Dynamic classloading
[ http://jira.jboss.com/jira/browse/JBREM-47?page=history ] Tom Elrod updated JBREM-47: Fix Version: 1.2.0 beta Dynamic classloading Key: JBREM-47 URL: http://jira.jboss.com/jira/browse/JBREM-47 Project: JBoss Remoting Type: Feature Request Components: general Versions: 1.0.1 beta Reporter: Tom Elrod Assignee: Tom Elrod Fix For: 1.2.0 beta Need ability for dynamic classloading to satisfy two needs. The first, is when an ejb lookup is done, and if do not have the class on the client, can download the client classes for remoting. This is much more efficient than having to serialize all these classes (as there may be many and may not even know what they are until runtime). Also, would like to add the ability for client or server to pass implementation for interfaces across the wire and if the other side does not have those classes, can load them. Once particular case when this might be needed is if using JMX sub-system, client could create custom QueryExp? implementation and pass to the server, and the server could load that class and perform the query. Will require security around this. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBREM-55) Clean up Callback implementation
[ http://jira.jboss.com/jira/browse/JBREM-55?page=history ] Tom Elrod updated JBREM-55: Fix Version: 1.2.0 beta Clean up Callback implementation Key: JBREM-55 URL: http://jira.jboss.com/jira/browse/JBREM-55 Project: JBoss Remoting Type: Task Components: general Versions: 1.0.1 beta Reporter: Tom Elrod Assignee: Tom Elrod Fix For: 1.2.0 beta There are several issues with remoting callbacks discussed on the forum (see http://www.jboss.org/index.html?module=bbop=viewtopicp=3865270#3865270) that need to be addressed. This will probably end up being the root issue with sub-issues opened for the particular tasks as they are addressed. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBREM-57) Remove use of InvokerRequest in favor of Callback object
[ http://jira.jboss.com/jira/browse/JBREM-57?page=history ] Tom Elrod updated JBREM-57: Fix Version: 1.2.0 beta Remove use of InvokerRequest in favor of Callback object Key: JBREM-57 URL: http://jira.jboss.com/jira/browse/JBREM-57 Project: JBoss Remoting Type: Task Components: general Versions: 1.0.1 final Reporter: Tom Elrod Assignee: Tom Elrod Fix For: 1.2.0 beta In order to remain backwards compatible with the 1.0.1 beta release, code was added to the 1.0.1 final release so that Callback class extended the InvocationRequest class. This allowed for use of either class in the final release. In a future release, only the Callback class should be supported, as there is no real reason for use of InvocationRequest other than 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [JBoss JIRA] Updated: (JBREM-44) HA support for unified invoker
[ http://jira.jboss.com/jira/browse/JBREM-44?page=history ] Tom Elrod updated JBREM-44: Fix Version: 1.2.0 beta HA support for unified invoker -- Key: JBREM-44 URL: http://jira.jboss.com/jira/browse/JBREM-44 Project: JBoss Remoting Type: Task Components: general Versions: 1.0.1 beta Reporter: Tom Elrod Assignee: Tom Elrod Fix For: 1.2.0 beta Need to support HA fail-over in unified invoker proxy. Will borrow from current approach. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ JBoss-Development mailing list JBoss-Development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jboss-development
