[JBoss-dev] [ jboss-Bugs-644289 ] ClassLoader issue with protected access and manifest refs
Bugs item #644289, was opened at 2002-11-26 11:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=644289&group_id=22866 Category: JBossMX Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Scott M Stark (starksm) Summary: ClassLoader issue with protected access and manifest refs Initial Comment: When package protected access is used with classes that are loaded by more than one classloader via manifest Class-Path references you can get IllegalAccessErrors when more than one jar references the jar containing the classes due to the use of a UCL per jar. This has been reported in various forms in bugs 565701, 606359, 641740 and is consolidated here with a trival testcase that demonstrates the problem. The org.jboss.test.classloader.test.CircularityUnitTestCase testPackageProtected unit test demonstrates the problem with a repository that contains a login.jar and a usrmgr.jar, both of which reference a cl-util.jar. The contents of the jars is: login.jar +- org/jboss/test/classloader/circularity/support/UserOfLogi nInfo.class +- META-INF/MANIFEST.MF Class-Path: cl-util.jar usrmgr.jar +- org/jboss/test/classloader/circularity/support/UserOfUsr Mgr.class +- META-INF/MANIFEST.MF Class-Path: cl-util.jar cl-util.jar +- org/jboss/test/classloader/circularity/support/LoginInfo.cl ass +- org/jboss/test/classloader/circularity/support/UsrMgr.cla ss +- META-INF/MANIFEST.MF The test first loads the UserOfLoginInfo class using the UCL associated with login.jar, and then loads the UserOfUsrMgr class using the UCL associated with usrmgr.jar. A changePassword method is then invoked on an instance of UserOfUsrMgr and this results in an IllegalAccessError because the LoginInfo class was seen to be loaded from the UCL associated with login.jar while the UsMgr class was loaded from the UCL associated with usrmgr.jar. Although both are in the same package and jar, two different class loaders are involved and so the access check fails. The only workaround at the moment requires moving the common jar to the server/xxx/lib directory so that the UCLs do not see common jar as part of their classes. -- >Comment By: Scott M Stark (starksm) Date: 2002-12-23 23:48 Message: Logged In: YES user_id=175228 This has been fixed in the 3.0 and 3.2 branches. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=644289&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-658134 ] JaasSecurityDomain NPE
Bugs item #658134, was opened at 2002-12-23 23:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=658134&group_id=22866 Category: JBossSX Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Scott M Stark (starksm) Summary: JaasSecurityDomain NPE Initial Comment: A bug was introduced in 3.0.4 that disallows a JaasSecurityDomain from functioning as an AuthenticationManager due to NPEs because the authentication cache is not being set. This is due to the JaasSecurityManager no longer creating a default cache. The JaasSecurityManagerService now will set the authentication cache for security managers that register via the registerSecurityDomain op. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=658134&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-658134 ] JaasSecurityDomain NPE
Bugs item #658134, was opened at 2002-12-23 23:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=658134&group_id=22866 Category: JBossSX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Scott M Stark (starksm) Summary: JaasSecurityDomain NPE Initial Comment: A bug was introduced in 3.0.4 that disallows a JaasSecurityDomain from functioning as an AuthenticationManager due to NPEs because the authentication cache is not being set. This is due to the JaasSecurityManager no longer creating a default cache. The JaasSecurityManagerService now will set the authentication cache for security managers that register via the registerSecurityDomain op. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=658134&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-658060 ] Several locking problems in connectors
Bugs item #658060, was opened at 2002-12-24 01:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=658060&group_id=22866 Category: JBossCX Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stefan Reich (sreich) >Assigned to: David Jencks (d_jencks) Summary: Several locking problems in connectors Initial Comment: While browsing the 3.0.5RC1 source I discovered several places with inconsistent locking: * org/jboss/resource/adapter/jdbc/local/LocalManagedConnection: field cels is locked on "this" in add/removeConnectionEventListener, but locked on cels in closeHandle and connectionError. The field "handles" is accessed w/o a lock in getConnection() * org/jboss/resource/connectionmanager/BaseConnectionManager2 The fields "handleCount" and "handles" are accessed w/o holding the lock on "this" in isManagedConnectionFree() and unregisterConnections() * main/org/jboss/resource/connectionmanager/InternalManagedConnectionPool exception gets logged at the wrong level in returnConnection() * org/jboss/resource/connectionmanager/JBossManagedConnectionPool All methods iterating over the "pools" field must lock to avoid ConcurrentModificationExceptions or otherwise inconsistent state. Diffs attached. -- >Comment By: David Jencks (d_jencks) Date: 2002-12-24 05:05 Message: Logged In: YES user_id=60525 Thanks very much. I've applied these to 3.0, 3.2, and 4 with the following exception: I retained the non-synchronized collections in LocalManagedConnection and applied explicit synchronization. According to the discussion of locks and memory in the Java Virtual Machine Specification section 8.6 (more or less copied from the Java Language Spec), every lock/unlock operation requires synchronizing a threads local memore with main memory, not just the outermost lock/unlock. Using explicit synchronization everywhere avoids this double memory synch when iterating through the collection. I also find it clearer to show al the synchronization explicitly. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=658060&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] IMPORTANT! for jboss 4-- xdoclet built inside jboss
Spel again ! ... tisdagen den 24 december 2002 kl 01.14 skrev David Jencks: I've addded an xdoclet module to jboss 4 (head) that builds xdoclet from source from the xdoclet cvs tree. To minize disruption, please read! You can avoid requiring a fresh jboss checkout by executing in jboss-head cvs get _jboss_xdoclet WARNING you may have to run build/build.sh twice, see "Issues". I am investigating this. HOW IT WORkS--- The first time you build jboss, xdoclet source is checked out into a directory checkout by the xdoclet/build.xml ant script. The cvs properties are set in the xdoclet.cvs.properties file. After successful checkout and build, flag files are created xdoclet.last.checkout and xdoclet.last.build. As long as the checkout folder remains, and these files are not touched, xdoclet will not be rebuilt. On my machines building xdoclet takes about the same amount of time as building jboss. The xdoclet build is supplied with some properties so it builds into xdoclet/output/lib. The libraries.ent file is modified to use xdoclet from here. If all goes well I will remove the xdoclet copy from thirdparty in a day or two. if you want to modify xdoclet, remove the xdoclet.last.build file and your modifications will be compiled the next time you build jboss. CHANGES WITH THIS VERSION OF XDOCLET--- --The main change is that xdoclet no longer copies over all the imports from your source class to generated interfaces, instead fully qualifying all class names in the generated interfaces. WARNING!!! THIS REQUIRES YOU TO EXPLICITLY IMPORT EVERY CLASS IN EVERY JAVA FILE XDOCLET LOOKS AT!! NO import x.y.x.*;! If you import a package.*, xdoclet may find a class referenced in a file in which it is not explicitly imported and decide the class is "unknown" and therefore to be generated in the "current" package, and not fully qualify the name in ANY file it generates. This can be extremely confusing since the effects are in a file totally unrelated to the file with the package import, and there is no obvious warning of where the problem came from. I'm looking for a way to at least provide a more obvious warning for this. --xmbean operations require you to list the managed-parameters with the correct types. While a nuisance, this at least encourages you to comment them. --xmbean display-names can be specified, and they display in the jmx-console. - Issues: --currently xdoclet head is checked out. After I make sure this works a little more and fix a couple of xdoclet problems I will tag xdoclet source so we have a more stable checkout. --On some machines it appears that the first build will not be able to find the just-compiled xdoclet jars. Running build/build.sh again seems to find them. (I thought it worked on apple 1.4.1, but a fresh checkout on linux sun 1.3.1 fails on the first build). I'm looking at this. -- Next steps: put the jboss xdoclet module into jboss cvs and build it with the rest of xdoclet. provide instructions for xdoclet committers to work with a "live" copy of xdoclet in jboss. Thanks david jencks --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://jboss.kimptoc.net FOR DETAILS= = JAVA VERSION DETAILS java version "1.3.1_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01) Java HotSpot(TM) Server VM (build 1.3.1_06-b01, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE _buildmagic:modules:most: [execmodules] Missing build file; skipping module: xdoclet == == == Executing 'most' in module 'common'... == == configure-modules: Overriding previous definition of reference to jboss.naming.classpath compile-mbean-sources: [mkdir] Created dir: /home/jboss/jbossci/jboss-head/common/output/gen/classes BUILD FAILED file:/home/jboss/jbossci/jboss-head/common/build.xml:118: Could not create task or type of type: jmxdoclet. Ant could not find the task or a class this task relies upon. This is common and has a number of causes; the usual solutions are to read the manual pages then download and install needed JAR files, or fix the build file: - You have misspelt 'jmxdoclet'. Fix: check your spelling. - The task needs an external JAR file to execute and this is not found at the right place in the classpath. Fix: check the documentation for dependencies. Fix: declare the task. - The task is an Ant optional task and optional.jar is absent Fix: look for optional.jar in ANT_HOME/lib, download if needed - The task was not built into optional.jar as dependent libraries were not found at build time. Fix: look in the JAR to verify, then rebuild with the needed libraries, or download a release version from apache.org - The build file was written for a later version of Ant Fix: upgrade to at least the latest release version of Ant - The task is not an Ant core or optional task and needs to be declared using . Remember that for JAR files to be visible to Ant tasks implemented in ANT_HOME/lib, the files must be in the same directory or on the classpath Please neither file bug reports on this problem, nor email the Ant mailing lists, until all of these causes have been explored, as this is not an Ant bug. Total time: 3 seconds --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-658042 ] High contention in jboss/naming
Bugs item #658042, was opened at 2002-12-23 15:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=658042&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stefan Reich (sreich) >Assigned to: Scott M Stark (starksm) Summary: High contention in jboss/naming Initial Comment: While running ECperf Scott and I discovered high contention in two classes of the JNDI naming implementation of JBoss: 1) org.jboss.naming.ENCFactory calls a native method (Thread.currentThread) while holding a lock, which is very expensive in most vms. Fix: moved the call out of the synchronized bloc. 2) org.jnp.interfaces.NamingParser has a static Properties instance that holds JNDI read-only properties. In the tests we saw as many as 30% of all threads waiting to acquire the lock for the Hashtable, from which java.util.Properties extends. The synchronization is unnecessary, since the static instance is read-only after its allocation. Fix: wrote a custom class that extends java.util.Properties overriding all methods to get rid of unwanted locking and ensure read-only semantics. Both fixes result in an increase of about factor three in ECperf BBops on a Dual 500MHz PowerMac and have been tested for a week on Jboss 3.0.5RC1. Diff attached. -- >Comment By: Scott M Stark (starksm) Date: 2002-12-23 17:07 Message: Logged In: YES user_id=175228 Integrated into 3.0+ -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=658042&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-658060 ] Several locking problems in connectors
Bugs item #658060, was opened at 2002-12-23 17:03 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=658060&group_id=22866 Category: JBossCX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Stefan Reich (sreich) Assigned to: Nobody/Anonymous (nobody) Summary: Several locking problems in connectors Initial Comment: While browsing the 3.0.5RC1 source I discovered several places with inconsistent locking: * org/jboss/resource/adapter/jdbc/local/LocalManagedConnection: field cels is locked on "this" in add/removeConnectionEventListener, but locked on cels in closeHandle and connectionError. The field "handles" is accessed w/o a lock in getConnection() * org/jboss/resource/connectionmanager/BaseConnectionManager2 The fields "handleCount" and "handles" are accessed w/o holding the lock on "this" in isManagedConnectionFree() and unregisterConnections() * main/org/jboss/resource/connectionmanager/InternalManagedConnectionPool exception gets logged at the wrong level in returnConnection() * org/jboss/resource/connectionmanager/JBossManagedConnectionPool All methods iterating over the "pools" field must lock to avoid ConcurrentModificationExceptions or otherwise inconsistent state. Diffs attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=658060&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-658052 ] XDoclet built in JBoss
Change Notes item #658052, was opened at 2002-12-24 00:22 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381174&aid=658052&group_id=22866 Category: Build System Group: v4.0 Status: Open Priority: 5 Submitted By: David Jencks (d_jencks) Assigned to: David Jencks (d_jencks) Summary: XDoclet built in JBoss Initial Comment: I've addded an xdoclet module to jboss 4 (head) that builds xdoclet from source from the xdoclet cvs tree. To minize disruption, please read! You can avoid requiring a fresh jboss checkout by executing in jboss-head cvs get _jboss_xdoclet WARNING you may have to run build/build.sh twice, see "Issues". I am investigating this. HOW IT WORkS--- The first time you build jboss, xdoclet source is checked out into a directory checkout by the xdoclet/build.xml ant script. The cvs properties are set in the xdoclet.cvs.properties file. After successful checkout and build, flag files are created xdoclet.last.checkout and xdoclet.last.build. As long as the checkout folder remains, and these files are not touched, xdoclet will not be rebuilt. On my machines building xdoclet takes about the same amount of time as building jboss. The xdoclet build is supplied with some properties so it builds into xdoclet/output/lib. The libraries.ent file is modified to use xdoclet from here. If all goes well I will remove the xdoclet copy from thirdparty in a day or two. if you want to modify xdoclet, remove the xdoclet.last.build file and your modifications will be compiled the next time you build jboss. CHANGES WITH THIS VERSION OF XDOCLET--- --The main change is that xdoclet no longer copies over all the imports from your source class to generated interfaces, instead fully qualifying all class names in the generated interfaces. WARNING!!! THIS REQUIRES YOU TO EXPLICITLY IMPORT EVERY CLASS IN EVERY JAVA FILE XDOCLET LOOKS AT!! NO import x.y.x.*;! If you import a package.*, xdoclet may find a class referenced in a file in which it is not explicitly imported and decide the class is "unknown" and therefore to be generated in the "current" package, and not fully qualify the name in ANY file it generates. This can be extremely confusing since the effects are in a file totally unrelated to the file with the package import, and there is no obvious warning of where the problem came from. I'm looking for a way to at least provide a more obvious warning for this. --xmbean operations require you to list the managed-parameters with the correct types. While a nuisance, this at least encourages you to comment them. --xmbean display-names can be specified, and they display in the jmx-console. - Issues: --currently xdoclet head is checked out. After I make sure this works a little more and fix a couple of xdoclet problems I will tag xdoclet source so we have a more stable checkout. --On some machines it appears that the first build will not be able to find the just-compiled xdoclet jars. Running build/build.sh again seems to find them. (I thought it worked on apple 1.4.1, but a fresh checkout on linux sun 1.3.1 fails on the first build). I'm looking at this. -- Next steps: put the jboss xdoclet module into jboss cvs and build it with the rest of xdoclet. provide instructions for xdoclet committers to work with a "live" copy of xdoclet in jboss. Thanks david jencks -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=381174&aid=658052&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] IMPORTANT! for jboss 4-- xdoclet built inside jboss
I've addded an xdoclet module to jboss 4 (head) that builds xdoclet from source from the xdoclet cvs tree. To minize disruption, please read! You can avoid requiring a fresh jboss checkout by executing in jboss-head cvs get _jboss_xdoclet WARNING you may have to run build/build.sh twice, see "Issues". I am investigating this. HOW IT WORkS--- The first time you build jboss, xdoclet source is checked out into a directory checkout by the xdoclet/build.xml ant script. The cvs properties are set in the xdoclet.cvs.properties file. After successful checkout and build, flag files are created xdoclet.last.checkout and xdoclet.last.build. As long as the checkout folder remains, and these files are not touched, xdoclet will not be rebuilt. On my machines building xdoclet takes about the same amount of time as building jboss. The xdoclet build is supplied with some properties so it builds into xdoclet/output/lib. The libraries.ent file is modified to use xdoclet from here. If all goes well I will remove the xdoclet copy from thirdparty in a day or two. if you want to modify xdoclet, remove the xdoclet.last.build file and your modifications will be compiled the next time you build jboss. CHANGES WITH THIS VERSION OF XDOCLET--- --The main change is that xdoclet no longer copies over all the imports from your source class to generated interfaces, instead fully qualifying all class names in the generated interfaces. WARNING!!! THIS REQUIRES YOU TO EXPLICITLY IMPORT EVERY CLASS IN EVERY JAVA FILE XDOCLET LOOKS AT!! NO import x.y.x.*;! If you import a package.*, xdoclet may find a class referenced in a file in which it is not explicitly imported and decide the class is "unknown" and therefore to be generated in the "current" package, and not fully qualify the name in ANY file it generates. This can be extremely confusing since the effects are in a file totally unrelated to the file with the package import, and there is no obvious warning of where the problem came from. I'm looking for a way to at least provide a more obvious warning for this. --xmbean operations require you to list the managed-parameters with the correct types. While a nuisance, this at least encourages you to comment them. --xmbean display-names can be specified, and they display in the jmx-console. - Issues: --currently xdoclet head is checked out. After I make sure this works a little more and fix a couple of xdoclet problems I will tag xdoclet source so we have a more stable checkout. --On some machines it appears that the first build will not be able to find the just-compiled xdoclet jars. Running build/build.sh again seems to find them. (I thought it worked on apple 1.4.1, but a fresh checkout on linux sun 1.3.1 fails on the first build). I'm looking at this. -- Next steps: put the jboss xdoclet module into jboss cvs and build it with the rest of xdoclet. provide instructions for xdoclet committers to work with a "live" copy of xdoclet in jboss. Thanks david jencks --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-658042 ] High contention in jboss/naming
Bugs item #658042, was opened at 2002-12-23 15:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=658042&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Stefan Reich (sreich) Assigned to: Nobody/Anonymous (nobody) Summary: High contention in jboss/naming Initial Comment: While running ECperf Scott and I discovered high contention in two classes of the JNDI naming implementation of JBoss: 1) org.jboss.naming.ENCFactory calls a native method (Thread.currentThread) while holding a lock, which is very expensive in most vms. Fix: moved the call out of the synchronized bloc. 2) org.jnp.interfaces.NamingParser has a static Properties instance that holds JNDI read-only properties. In the tests we saw as many as 30% of all threads waiting to acquire the lock for the Hashtable, from which java.util.Properties extends. The synchronization is unnecessary, since the static instance is read-only after its allocation. Fix: wrote a custom class that extends java.util.Properties overriding all methods to get rid of unwanted locking and ensure read-only semantics. Both fixes result in an increase of about factor three in ECperf BBops on a Dual 500MHz PowerMac and have been tested for a week on Jboss 3.0.5RC1. Diff attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=658042&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Review the coding standards please
If you ever decide to change the standards I highly recommend the book The Elements of Java Style by Ambler, et al. It fills in the blanks to Sun's Java coding conventions and provides an accessible quick reference you can keep on your desk. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Monday, December 23, 2002 1:57 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] Review the coding standards please Inconsistent treatment of spaces and braces is creeping into the codebase again. Review the coding guidelines with regard to these issues so that someone else does not have to reformat your code to bring it to spec and waste a cvs history entry. Coding standards are here: http://www.jboss.org/developers/guides/codestyle.jsp The documentation of revision changes in the class header is deprecated. Use good comments on the cvs checkin so that there is a meanignful branch specific change log. Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 23-December-2002
JBoss daily test results SUMMARY Number of tests run: 991 Successful tests: 984 Errors:6 Failures: 1 [time of test: 2002-12-23.12-05 GMT] [java.version: 1.3.1] [java.vendor: Apple Computer, Inc.] [java.vm.version: 1.3.1_03-69] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Mac OS X] [os.arch: ppc] [os.version: 10.2.3] See http://users.jboss.org/~starksm/Branch_3_0/2002-12-23.12-05 for details of this test. NOTE: If there are any errors shown above - this mail is only highlighting them - it is NOT indicating that they are being looked at by anyone. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! DETAILS OF ERRORS Suite: CircularityUnitTestCase Test: testPackageProtected(org.jboss.test.classloader.test.CircularityUnitTestCase) Type:error Exception: javax.management.MBeanException Message: Exception in MBean operation 'testPackageProtected()' - Suite: LocalWrapperCleanupUnitTestCase Test: testAutoCommitOffInRemoteUserTx(org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase) Type:error Exception: java.rmi.ServerException Message: RemoteException occurred in server thread; nested exception is: java.rmi.ServerException: EJBException:; nested exception is: javax.ejb.EJBException: Row committed, autocommit still on! - Suite: MissingClassUnitTestCase Test: testDeployServiceWithoutClass(org.jboss.test.jmx.test.MissingClassUnitTestCase) Type:error Exception: org.jboss.deployment.DeploymentException Message: jboss.test:name=missingclasstest is not registered.; - nested throwable: (javax.management.InstanceNotFoundException: jboss.test:name=missingclasstest is not registered.) - Suite: SimpleUnitTestCase Test:testSecureHttpInvoker(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.security.auth.login.LoginException Message: Missing users.properties file. - Suite: SimpleUnitTestCase Test:testLoginInitialContext(org.jboss.test.naming.test.SimpleUnitTestCase) Type:error Exception: javax.naming.AuthenticationException Message: Failed to login using protocol=testLoginInitialContext - Suite: BeanStressTestCase Test:testDeadLockFromClient(org.jboss.test.deadlock.test.BeanStressTestCase) Type:failure Exception: junit.framework.AssertionFailedError Message: expected a client deadlock for AB BA - Suite: ContextCLTestCase Test: testInvokeNeedingTCL(org.jboss.test.jbossmx.implementation.server.ContextCLTestCase) Type:error Exception: javax.management.RuntimeMBeanException Message: RuntimeException in MBean operation 'registerClassLoader(,org.jboss.mx.loading.UnifiedClassLoader)' - --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Copyright of personal work (Was:RE: [JBoss-dev] Good-bye II)
The key phrase in the US code governing this is "a work prepared by an employee within the scope of his or her employment", and the determining case at the federal level is CCNV v. Reid. From http://www.utsystem.edu/ogc/intellectualproperty/cybrscen.htm: "The Court emphasized that state laws of agency govern whether one is an employee... In determining whether a work is within the scope of employment, the courts will focus on whether the employee was hired to do the kind of work in question or how closely related it is to the employees primary job responsibilities; whether the employee created the work substantially on the companys time and using its facilities; and whether the motivation to create the work was at least in part, to serve the employer, including serving fellow employees or the employers customers needs." Note the sentence "whether the employee was hired to do the kind of work in question or how closely related it is to the employees primary job responsibilities," and note also that it is state laws of agency which determine the "employee" and "scope of employment" status. As Dain said, it's something that varies state to state and is complex enough that just saying "but I did it at home" isn't enough. Do you ever do work at home for the employer? Were you hired by the employer to do the same type of work? My message was just meant as a word of caution. Whenever I'm hired as an employee, I try to advise them of the work I occasionally do on Open Source software, and if possible get a written agreement that they will eschew any copyright claim for work I do on my own time & equipment. Needless to say, they are almost never willing to do that, and what I usually end up with is a verbal agreement to that on principle, and then I'm careful not to work on any open source stuff that's too similar to what I do at work. Dave --- Rhett Aultman <[EMAIL PROTECTED]> wrote: > I honestly don't think that's the > case, which leads me to suspect that your employer > cannot just unilaterally annex work you do in your > spare time unless they can cite a conflict of > interests or some sort of other direct threat to > their interests (such as stealing a trade secret). > > Really...does anyone know a little of the case law > here? > > -Original Message- > From: Dave Neuer [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 23, 2002 2:05 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Good-bye II > > > > --- Dain Sundstrom <[EMAIL PROTECTED]> wrote: > > Andy, > > > > Do you own your own work anymore? > > > > This is actually a key issue that everyone working > on > this type of projejct should really be aware of. If > you are a permanent employee of a company in the > USofA > which produces copyrightable material (such as > software) --unless you have a contract to the > contrary > -- that company owns the copyright to the work you > do. > Not just the work you do on company time & > equipment, > but often even the work you do from home on your > spare > time. > > IANAL, and my understanding is that the degree to > which the latter is the case MAY depend on how > similar > the work you've done on your own time & equipment is > to the work you get paid to do, but since that's up > to > a judge's discretion -- and case law, I guess -- it > would be insane for someone running an Open Source > project to knowingly allow questionable code into > their base as, LGPL, GPL or Bob's License, license > issues don't help you if some other entity can claim > to own the copyright. This is why the FSF asks > people > to formally assign the copyright to free software > under the GNU project to them. > > If Andy really does work for a company, as a regular > employee, who produces software similar to JBoss, > removing his code is the right thing to do even if > it's technically superior to every other bit of code > in the codebase and he's the sweetest human being > that > ever lived, to protect the right of all of the rest > of > us to use this awesome software. > > Dave Neuer > > __ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up > now. > http://mailplus.yahoo.com > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/list
RE: [JBoss-dev] Fixing the management info layer
FYI, I've created a forum on the topic. http://www.jboss.org/forums/forum.jsp?forum=160 Scott McLaughlin, do you want to drive any of this? Seems you've had some energy around this. Bill Burke Chief Architect JBoss Group, LLC > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Scott > M Stark > Sent: Monday, December 23, 2002 2:48 PM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] Fixing the management info layer > > > We need better management information. A lot of the JSR-77 stuff is useful > information, the only problem was with how it was integrated, not really > tested, and not understood by the people working on the core stuff into > which this foreign code was interjected. > > > Where applicable this should be integrated via interceptors > and/or aspects that > emit JMX notifications on which JSR-77 bean may be created. So the first > step is to replace the existing JSR-77 stuff with what we > actually need to do > management and support of JBoss. For caches, pools, invocations, > etc. there > needs to be low impact asynchronous events that allow for > collection of this > information and rehashing statistically and historically. > > I want this working in 3.2 as well so where the aspect stuff > cannot be used > alternative approaches are needed. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > > From: "David Jencks" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Sent: Monday, December 23, 2002 11:22 AM > Subject: Management layer > > > > Before you do anything to the jsr-77 stuff, I'd like to know if > we plan to > > continue to implement it. Although I personally never got why > it is useful > > under any circumstances, I'm willing to believe e.g. marc if he says we > > should keep it. anyway, > > > > -- if we plan to implement it, I suggest moving directly to an mbean > > interceptor/aspect based implementation where we keep the "management" > > module more or less the same but replace the stuff spread all > over the rest > > of the code with interceptors. > > > > -- if we plan to not implement it, ... remove it all. > > > > I think even a somewhat lame implementation will provide an > easier base for > > improvement than starting over from scratch. Do we have anyone > interested > > in working on it? There was a guy helping andy for a while. > > > > > > thanks > > david > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Review the coding standards please
Inconsistent treatment of spaces and braces is creeping into the codebase again. Review the coding guidelines with regard to these issues so that someone else does not have to reformat your code to bring it to spec and waste a cvs history entry. Coding standards are here: http://www.jboss.org/developers/guides/codestyle.jsp The documentation of revision changes in the class header is deprecated. Use good comments on the cvs checkin so that there is a meanignful branch specific change log. Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Copyright of personal work (Was:RE: [JBoss-dev] Good-bye II)
Rhett, It all depends on your specific case. When it comes to this type of law, there are no hard and fast rules (every contract and country/state is different). You need to talk to a lawyer. -dain On Monday, December 23, 2002, at 01:31 PM, Rhett Aultman wrote: I know that I am not a lawyer and have only a semester of law to my name, but is there any real case law related to this matter? I could see where your employer could make claims against your private work if you were working on an open source project that was the spitting image of some proprietary work you were engaged in with said employer, but I would think that the claim would not be on the copyright of your own work but instead on divulging secrets or merely representing a conflict of interest. If what you're saying is true...that anything I do in my spare time can become the copyright of my employer, then I need to seriously rethink my budding writing career, since the articles and books I am writing on my home computer could fall in a legal gray area. I honestly don't think that's the case, which leads me to suspect that your employer cannot just unilaterally annex work you do in your spare time unless they can cite a conflict of interests or some sort of other direct threat to their interests (such as stealing a trade secret). Really...does anyone know a little of the case law here? -Original Message- From: Dave Neuer [mailto:[EMAIL PROTECTED]] Sent: Monday, December 23, 2002 2:05 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Good-bye II --- Dain Sundstrom <[EMAIL PROTECTED]> wrote: > Andy, > > Do you own your own work anymore? > This is actually a key issue that everyone working on this type of projejct should really be aware of. If you are a permanent employee of a company in the USofA which produces copyrightable material (such as software) --unless you have a contract to the contrary -- that company owns the copyright to the work you do. Not just the work you do on company time & equipment, but often even the work you do from home on your spare time. IANAL, and my understanding is that the degree to which the latter is the case MAY depend on how similar the work you've done on your own time & equipment is to the work you get paid to do, but since that's up to a judge's discretion -- and case law, I guess -- it would be insane for someone running an Open Source project to knowingly allow questionable code into their base as, LGPL, GPL or Bob's License, license issues don't help you if some other entity can claim to own the copyright. This is why the FSF asks people to formally assign the copyright to free software under the GNU project to them. If Andy really does work for a company, as a regular employee, who produces software similar to JBoss, removing his code is the right thing to do even if it's technically superior to every other bit of code in the codebase and he's the sweetest human being that ever lived, to protect the right of all of the rest of us to use this awesome software. Dave Neuer __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Copyright of personal work (Was:RE: [JBoss-dev] Good-bye II)
As much as I hate to let this whole thread spin too far off topic... In California I know that work you do does NOT get automatically assigned to your employer and, if your employer wants your independent work assigned over to them they must put that in the employment contract AND a copy of Section 2870(a) of the Calif. Labor Code. 2870 basically says your employer cannot force you to assign any of your rights to something you have created yourself on your own time with your own equipment unless what you have created relates at the time of conception or reduction to practice to work you are doing for that employer. I don't know about other states... However, if Andy was told by his employer not to work on JBoss because it competes in any way with the product his employer is making, taking CVS RW access away is the correct thing to do. At least until there is an agreement, in writing, giving blanket permission to contribute to the JBoss code base. The last thing you would want is for a company with their own EJB/Servlet/JSP/etc. implementation to slap an injunction against distributing JBoss right as they launch their product arguing that JBoss likely contains code that is their intellectual property. It could take months to clear the legal issues, all the while they are making money selling their product and JBoss developers find their consulting income wither to nothing. At 02:31 PM 12/23/2002 -0500, you wrote: I know that I am not a lawyer and have only a semester of law to my name, but is there any real case law related to this matter? I could see where your employer could make claims against your private work if you were working on an open source project that was the spitting image of some proprietary work you were engaged in with said employer, but I would think that the claim would not be on the copyright of your own work but instead on divulging secrets or merely representing a conflict of interest. If what you're saying is true...that anything I do in my spare time can become the copyright of my employer, then I need to seriously rethink my budding writing career, since the articles and books I am writing on my home computer could fall in a legal gray area. I honestly don't think that's the case, which leads me to suspect that your employer cannot just unilaterally annex work you do in your spare time unless they can cite a conflict of interests or some sort of other direct threat to their interests (such as stealing a trade secret). Really...does anyone know a little of the case law here? --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Fixing the management info layer
We need better management information. A lot of the JSR-77 stuff is useful information, the only problem was with how it was integrated, not really tested, and not understood by the people working on the core stuff into which this foreign code was interjected. Where applicable this should be integrated via interceptors and/or aspects that emit JMX notifications on which JSR-77 bean may be created. So the first step is to replace the existing JSR-77 stuff with what we actually need to do management and support of JBoss. For caches, pools, invocations, etc. there needs to be low impact asynchronous events that allow for collection of this information and rehashing statistically and historically. I want this working in 3.2 as well so where the aspect stuff cannot be used alternative approaches are needed. Scott Stark Chief Technology Officer JBoss Group, LLC From: "David Jencks" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent: Monday, December 23, 2002 11:22 AM Subject: Management layer > Before you do anything to the jsr-77 stuff, I'd like to know if we plan to > continue to implement it. Although I personally never got why it is useful > under any circumstances, I'm willing to believe e.g. marc if he says we > should keep it. anyway, > > -- if we plan to implement it, I suggest moving directly to an mbean > interceptor/aspect based implementation where we keep the "management" > module more or less the same but replace the stuff spread all over the rest > of the code with interceptors. > > -- if we plan to not implement it, ... remove it all. > > I think even a somewhat lame implementation will provide an easier base for > improvement than starting over from scratch. Do we have anyone interested > in working on it? There was a guy helping andy for a while. > > > thanks > david --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Copyright of personal work (Was:RE: [JBoss-dev] Good-bye II)
Title: Re: [JBoss-dev] Good-bye II I know that I am not a lawyer and have only a semester of law to my name, but is there any real case law related to this matter? I could see where your employer could make claims against your private work if you were working on an open source project that was the spitting image of some proprietary work you were engaged in with said employer, but I would think that the claim would not be on the copyright of your own work but instead on divulging secrets or merely representing a conflict of interest. If what you're saying is true...that anything I do in my spare time can become the copyright of my employer, then I need to seriously rethink my budding writing career, since the articles and books I am writing on my home computer could fall in a legal gray area. I honestly don't think that's the case, which leads me to suspect that your employer cannot just unilaterally annex work you do in your spare time unless they can cite a conflict of interests or some sort of other direct threat to their interests (such as stealing a trade secret). Really...does anyone know a little of the case law here? -Original Message-From: Dave Neuer [mailto:[EMAIL PROTECTED]]Sent: Monday, December 23, 2002 2:05 PMTo: [EMAIL PROTECTED]Subject: Re: [JBoss-dev] Good-bye II --- Dain Sundstrom <[EMAIL PROTECTED]> wrote:> Andy,>> Do you own your own work anymore?>This is actually a key issue that everyone working onthis type of projejct should really be aware of. Ifyou are a permanent employee of a company in the USofAwhich produces copyrightable material (such assoftware) --unless you have a contract to the contrary-- that company owns the copyright to the work you do.Not just the work you do on company time & equipment,but often even the work you do from home on your sparetime.IANAL, and my understanding is that the degree towhich the latter is the case MAY depend on how similarthe work you've done on your own time & equipment isto the work you get paid to do, but since that's up toa judge's discretion -- and case law, I guess -- itwould be insane for someone running an Open Sourceproject to knowingly allow questionable code intotheir base as, LGPL, GPL or Bob's License, licenseissues don't help you if some other entity can claimto own the copyright. This is why the FSF asks peopleto formally assign the copyright to free softwareunder the GNU project to them.If Andy really does work for a company, as a regularemployee, who produces software similar to JBoss,removing his code is the right thing to do even ifit's technically superior to every other bit of codein the codebase and he's the sweetest human being thatever lived, to protect the right of all of the rest ofus to use this awesome software.Dave Neuer__Do you Yahoo!?Yahoo! Mail Plus - Powerful. Affordable. Sign up now.http://mailplus.yahoo.com---This sf.net email is sponsored by:ThinkGeekWelcome to geek heaven.http://thinkgeek.com/sf___Jboss-development mailing list[EMAIL PROTECTED]https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Good-bye II
--- Dain Sundstrom <[EMAIL PROTECTED]> wrote: > Andy, > > Do you own your own work anymore? > This is actually a key issue that everyone working on this type of projejct should really be aware of. If you are a permanent employee of a company in the USofA which produces copyrightable material (such as software) --unless you have a contract to the contrary -- that company owns the copyright to the work you do. Not just the work you do on company time & equipment, but often even the work you do from home on your spare time. IANAL, and my understanding is that the degree to which the latter is the case MAY depend on how similar the work you've done on your own time & equipment is to the work you get paid to do, but since that's up to a judge's discretion -- and case law, I guess -- it would be insane for someone running an Open Source project to knowingly allow questionable code into their base as, LGPL, GPL or Bob's License, license issues don't help you if some other entity can claim to own the copyright. This is why the FSF asks people to formally assign the copyright to free software under the GNU project to them. If Andy really does work for a company, as a regular employee, who produces software similar to JBoss, removing his code is the right thing to do even if it's technically superior to every other bit of code in the codebase and he's the sweetest human being that ever lived, to protect the right of all of the rest of us to use this awesome software. Dave Neuer __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Good-bye II
When lawyers and law are involved, compromize is often impossible. If you are working on a competing product at your day job and JBoss by night, you risk infecting your employer's codebase with LGPL code, and the JBoss code by proprietary code. I'm not saying you'd intentionally do that, but it would be legally difficult to defend even incidental similarities in the code base. There probably are similarities, since both products attempt to implement the same spec. Sorry to see you go, Andy, but this is one where pragmatics point to listening to the lawers. -danch Andy wrote: Hi Oohh, the power of legal issues, you can justify nearly everything. Instead of looking for a mutual compromise to resolve this issue Marc (and others) sought a more terminal solution. Andy - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "'JBoss Group'" <[EMAIL PROTECTED]> Sent: Monday, December 23, 2002 7:49 AM Subject: jRE: [JBoss-dev] Good-bye II Andy is working on a competing implementation to jboss. His own lawyers at his company have requested he not work on JBoss, he was doing so anyway under an alias. We only found out about the competing aspect a couple of days ago. To protect ourselves legally, we removed Andy's RW, we will in fact remove the code contributions. We cannot have a competitor's code in our base as it exposes us legally. It is only the second time this has happened in our history. The mail below is an expression of Andy's personal gripes and bitterness. Period. marcf --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Committed support for remote deployment scanning
I put in a check so that errors getting last-modified do not trigger redeployment. > > I haven't I'm afraid, I did enough to get the rest of my team > working and left it at that :-(. I suspect it may be similar > to the WebSphere problem that I had to work around. > > I'll have a quick look at it again and see if I can get any > further, although we have just upgraded Solaris and it may > no longer happen :-). > > Thanks again, > Kev > I don't have a Solaris host to test with so any help here is appreciated. Thanks Jeremy --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Good-bye II
Andy, I agree with the meta point that it would be better to have a publicly defined structure for how the JBoss project is managed, but I think you are the wrong advocate for this issue. I actually think you make it less likely that such a thing will ever occur. Andy, if you want to be honest with everyone, why don't you start by answering the following questions? Do you work for a commercial J2EE tools vendor (it is your choice to tell everyone who you work specifically for)? Does your company want you to work on JBoss? Do you own your own work anymore? I think everyone will agree that the legal issues alone are enough to remove rw from someone. If you get your legal issues cleared up, I think they may reconsider, but as you have already stepped outside of the legal boundaries laid down by your employer, I personally would not risk give you rw again. The good think for you is I don't make those decisions. -dain On Monday, December 23, 2002, at 11:19 AM, Andy wrote: Hi Oohh, the power of legal issues, you can justify nearly everything. Instead of looking for a mutual compromise to resolve this issue Marc (and others) sought a more terminal solution. Andy - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "'JBoss Group'" <[EMAIL PROTECTED]> Sent: Monday, December 23, 2002 7:49 AM Subject: jRE: [JBoss-dev] Good-bye II Andy is working on a competing implementation to jboss. His own lawyers at his company have requested he not work on JBoss, he was doing so anyway under an alias. We only found out about the competing aspect a couple of days ago. To protect ourselves legally, we removed Andy's RW, we will in fact remove the code contributions. We cannot have a competitor's code in our base as it exposes us legally. It is only the second time this has happened in our history. The mail below is an expression of Andy's personal gripes and bitterness. Period. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Michael Bartmann Sent: Monday, December 23, 2002 9:09 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Good-bye II None of the JBG supporters has written everything by himself. This is of course a matter of control and organization, which you do very well as "master of the tree". I wont let everybody do everything, but if somebody wants to contribute "in the right direction" he should not be blocked. OTOH if somebody would insist to commit something you dont want to go in and he refuses to restrain himself this is another question. In the end you'll have to protect jbg (and jboss) from sabotage. I cannot judge about what happend in Andy's case; most of the discussion fortunately seems to have happened in private mail. I just want to get rid of the doubt that something went wrong due to political reasons. Otherwise contributors might come to the conclusion that they support jbg, not the jboss community. So I simply wanted to provoke some clarifications; a little bit of meta-discussion might be ok on this list and of interest for other contributors, too. Regards, Michael Bartmann PS.: The forum would be ok for me, simply tell me where to go... Scott M Stark wrote: Development and support are not separable. Do you let anyone modify code you support? This discussion needs to move the forums. Marc will take it up tomorrow. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Michael Bartmann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, December 23, 2002 1:54 AM Subject: Re: [JBoss-dev] Good-bye II - Andy: please keep cool and stay online (I like EJB timers :-) - Marc: consider developing and consulting as two different jboss ASPECTS. Again, I fear I misjudge because of lacking knowledge, but I couldn't resist to comment on this. I really don't like the idea of non-technical clash on jboss-developement. Regards, Michael Bartmann --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --
Re: [JBoss-dev] Good-bye II
Hi Oohh, the power of legal issues, you can justify nearly everything. Instead of looking for a mutual compromise to resolve this issue Marc (and others) sought a more terminal solution. Andy - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "'JBoss Group'" <[EMAIL PROTECTED]> Sent: Monday, December 23, 2002 7:49 AM Subject: jRE: [JBoss-dev] Good-bye II > Andy is working on a competing implementation to jboss. His own lawyers > at his company have requested he not work on JBoss, he was doing so > anyway under an alias. We only found out about the competing aspect a > couple of days ago. To protect ourselves legally, we removed Andy's RW, > we will in fact remove the code contributions. We cannot have a > competitor's code in our base as it exposes us legally. It is only the > second time this has happened in our history. The mail below is an > expression of Andy's personal gripes and bitterness. Period. > > marcf > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]] On > > Behalf Of Michael Bartmann > > Sent: Monday, December 23, 2002 9:09 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] Good-bye II > > > > > > None of the JBG supporters has written everything by himself. > > This is of course a matter of control and organization, which > > you do very well as "master of the tree". I wont let > > everybody do everything, but if somebody wants to contribute > > "in the right direction" he should not be blocked. > > > > OTOH if somebody would insist to commit something you dont > > want to go in and he refuses to restrain himself this is > > another question. In the end you'll have to protect jbg (and > > jboss) from sabotage. > > > > I cannot judge about what happend in Andy's case; most of the > > discussion fortunately seems to have happened in private > > mail. I just want to get rid of the doubt that something went > > wrong due to political reasons. Otherwise contributors might > > come to the conclusion that they support jbg, not the jboss community. > > > > So I simply wanted to provoke some clarifications; a little > > bit of meta-discussion might be ok on this list and of > > interest for other contributors, too. > > > > Regards, > > Michael Bartmann > > > > PS.: The forum would be ok for me, simply tell me where to go... > > > > > > Scott M Stark wrote: > > > Development and support are not separable. Do you let anyone modify > > > code you support? This discussion needs to move the forums. > > Marc will > > > take it up tomorrow. > > > > > > > > > Scott Stark > > > Chief Technology Officer > > > JBoss Group, LLC > > > > > > > > > - Original Message - > > > From: "Michael Bartmann" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Monday, December 23, 2002 1:54 AM > > > Subject: Re: [JBoss-dev] Good-bye II > > > > > > > > > > > >>- Andy: please keep cool and stay online (I like EJB timers :-) > > >>- Marc: consider developing and consulting as two different jboss > > >>ASPECTS. > > >> > > >>Again, I fear I misjudge because of lacking knowledge, but > > I couldn't > > >>resist to comment on this. I really don't like the idea of > > >>non-technical clash on jboss-developement. > > >> > > >>Regards, > > >>Michael Bartmann > > > > > > > > > > > > > > > --- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > ___ > > > Jboss-development mailing list > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > --- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Good-bye II
Marc, I don't want to encourage this thread by adding to it, but I think a few clarifications would be beneficial for me. > Andy is working on a competing implementation to jboss. Would it be possible to name this competing implementation? > We cannot have a competitor's code in our base as it exposes us legally Is the issue that Andy does not own the code he wrote, and therefore does not have the right to contribute it to JBoss.org? It is my understanding of the LGPL that it permits proprietary derivatives, such that I may embed JBoss within another product, and even modify JBoss, as long as modifications to JBoss are released publicly. Modifications made to the product JBoss is embedded within would not need to be released to the public. I see no distinction whereby, if the encapsulating product is itself an enterprise server (a competitor), that this behavior would be prohibited. Am I misinterpreting the license? I imagine that one legal scenario is that several commercial competitors would all share the same opensource kernel at their core -- That one would see a product like "Joe's Enterprise Server, with 'JBoss Inside'(TM)". Perhaps you mean something else when you say "compete"? - Matt -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Mon 12/23/2002 10:49 AM To: [EMAIL PROTECTED] Cc: 'JBoss Group' Subject: jRE: [JBoss-dev] Good-bye II Andy is working on a competing implementation to jboss. His own lawyers at his company have requested he not work on JBoss, he was doing so anyway under an alias. We only found out about the competing aspect a couple of days ago. To protect ourselves legally, we removed Andy's RW, we will in fact remove the code contributions. We cannot have a competitor's code in our base as it exposes us legally. It is only the second time this has happened in our history. The mail below is an expression of Andy's personal gripes and bitterness. Period. marcf > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On > Behalf Of Michael Bartmann > Sent: Monday, December 23, 2002 9:09 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Good-bye II > > > None of the JBG supporters has written everything by himself. > This is of course a matter of control and organization, which > you do very well as "master of the tree". I wont let > everybody do everything, but if somebody wants to contribute > "in the right direction" he should not be blocked. > > OTOH if somebody would insist to commit something you dont > want to go in and he refuses to restrain himself this is > another question. In the end you'll have to protect jbg (and > jboss) from sabotage. > > I cannot judge about what happend in Andy's case; most of the > discussion fortunately seems to have happened in private > mail. I just want to get rid of the doubt that something went > wrong due to political reasons. Otherwise contributors might > come to the conclusion that they support jbg, not the jboss community. > > So I simply wanted to provoke some clarifications; a little > bit of meta-discussion might be ok on this list and of > interest for other contributors, too. > > Regards, > Michael Bartmann > > PS.: The forum would be ok for me, simply tell me where to go... > > > Scott M Stark wrote: > > Development and support are not separable. Do you let anyone modify > > code you support? This discussion needs to move the forums. > Marc will > > take it up tomorrow. > > > > > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > > > > > - Original Message - > > From: "Michael Bartmann" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, December 23, 2002 1:54 AM > > Subject: Re: [JBoss-dev] Good-bye II > > > > > > > >>- Andy: please keep cool and stay online (I like EJB timers :-) > >>- Marc: consider developing and consulting as two different jboss > >>ASPECTS. > >> > >>Again, I fear I misjudge because of lacking knowledge, but > I couldn't > >>resist to comment on this. I really don't like the idea of > >>non-technical clash on jboss-developement. > >>
Re: [JBoss-dev] jboss and icmp sockets (any use?)
> o do you want to integrate it using jni and run the >jboss jvm as root, or No. > o do you want to run it in a separate process and >interface (with simple udp encaps. as I proposed) >or e.g. with corba. Yes, an MBean has to provide the channel through which ICMP requests are sent. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Michael Bartmann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, December 23, 2002 8:23 AM Subject: Re: [JBoss-dev] jboss and icmp sockets (any use?) > There is a portable api below ethereal. It uses > libpcap, a packet capturing api. It puts the > nic card in promiscuous mode and reads raw frames. > It is available on many platforms and used by > many traffic analyser guis. > > But: libpcap is not only for icmp but for any > (raw) packet, and it only listens to traffic, > for ping you've got to _generate_ icmp packets. > > So it is good if you want to build a kind of traffic > analysis mbean. > > The integration problem stands: > > o do you want to integrate it using jni and run the >jboss jvm as root, or > o do you want to run it in a separate process and >interface (with simple udp encaps. as I proposed) >or e.g. with corba. > > Regards, > Michael Bartmann --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss and icmp sockets (any use?)
There is a portable api below ethereal. It uses libpcap, a packet capturing api. It puts the nic card in promiscuous mode and reads raw frames. It is available on many platforms and used by many traffic analyser guis. But: libpcap is not only for icmp but for any (raw) packet, and it only listens to traffic, for ping you've got to _generate_ icmp packets. So it is good if you want to build a kind of traffic analysis mbean. The integration problem stands: o do you want to integrate it using jni and run the jboss jvm as root, or o do you want to run it in a separate process and interface (with simple udp encaps. as I proposed) or e.g. with corba. Regards, Michael Bartmann Scott M Stark wrote: If anything has a portable ICMP layer I would expect it in the Ethereal protocol analyzer : http://www.ethereal.com/ I'm interested in getting this an other network topology tools working in JBoss to better support cluster configuration issues so I'll help get something going here. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Michael Bartmann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, December 22, 2002 4:22 AM Subject: [JBoss-dev] jboss and icmp sockets (any use?) Hi socket programmers, While writing mbeans to interface with legacy tcp/ip hosts, I often thought it would be really usefull to be able to "ping" them. [[ As you surely know "ping" is icmp based, and jdks up to 1.4 don't support icmp sockets. Even if you write some jni code you are urged to run the whole jvm as root if running under unix, which you might not prefer to do; these security nightmares are probably the main reason for sun not to include icmp in the standard. (OTOH: there exists a jni icmp implementation for winsocks.) Now you could work around this by exec()-ing the ping utility of your favourite os. This is: 1) not so cheap (ressource wise, at least an exec() per ping) 2) quite slow (most ping utilities can only ping one host at a time and only once per second) 3) not so portable, you'll have to setup arguments and parse results in a way depending on your "ping" variant. ]] I came up with this solution: I wrote a very small C programm which acts as a gateway between a special udp socket and an icmp raw socket. So the java thread sends udp packets to that port, they get resend as icmp packets, the remote side responds, the response is translated back to udp and the java thread can read them. This is quite cheep and the C programm is very lightweight, but it is sort of system specific anyway (at the moment I only have a linux version, which should work under other unices - but probably not under winsocks). At least the java side is of course the same for every platform; this might be the only thing to go into the jboss distribution, so we don't pollute the build system with C. All this is not exactly jboss-specific, but I wondered if other jboss services could use icmp access? Is there a more simple icmp solution around, which works at least under win2k _and_ linux? (I heard there is something planned for jdk 1.5; I'd like to see how sun works around the "root-only" problem under unix...) Regards, Michael --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
jRE: [JBoss-dev] Good-bye II
Andy is working on a competing implementation to jboss. His own lawyers at his company have requested he not work on JBoss, he was doing so anyway under an alias. We only found out about the competing aspect a couple of days ago. To protect ourselves legally, we removed Andy's RW, we will in fact remove the code contributions. We cannot have a competitor's code in our base as it exposes us legally. It is only the second time this has happened in our history. The mail below is an expression of Andy's personal gripes and bitterness. Period. marcf > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On > Behalf Of Michael Bartmann > Sent: Monday, December 23, 2002 9:09 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] Good-bye II > > > None of the JBG supporters has written everything by himself. > This is of course a matter of control and organization, which > you do very well as "master of the tree". I wont let > everybody do everything, but if somebody wants to contribute > "in the right direction" he should not be blocked. > > OTOH if somebody would insist to commit something you dont > want to go in and he refuses to restrain himself this is > another question. In the end you'll have to protect jbg (and > jboss) from sabotage. > > I cannot judge about what happend in Andy's case; most of the > discussion fortunately seems to have happened in private > mail. I just want to get rid of the doubt that something went > wrong due to political reasons. Otherwise contributors might > come to the conclusion that they support jbg, not the jboss community. > > So I simply wanted to provoke some clarifications; a little > bit of meta-discussion might be ok on this list and of > interest for other contributors, too. > > Regards, > Michael Bartmann > > PS.: The forum would be ok for me, simply tell me where to go... > > > Scott M Stark wrote: > > Development and support are not separable. Do you let anyone modify > > code you support? This discussion needs to move the forums. > Marc will > > take it up tomorrow. > > > > > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > > > > > - Original Message - > > From: "Michael Bartmann" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Monday, December 23, 2002 1:54 AM > > Subject: Re: [JBoss-dev] Good-bye II > > > > > > > >>- Andy: please keep cool and stay online (I like EJB timers :-) > >>- Marc: consider developing and consulting as two different jboss > >>ASPECTS. > >> > >>Again, I fear I misjudge because of lacking knowledge, but > I couldn't > >>resist to comment on this. I really don't like the idea of > >>non-technical clash on jboss-developement. > >> > >>Regards, > >>Michael Bartmann > > > > > > > > > > --- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > ___ > > Jboss-development mailing list > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Dynamic Loading/Unloading of Plugins (was: RE: [eclipse-dev] Eclipse Project 2.2 Draft Plan posted)
James,
> We called it our "Groove Killer" but never got enough $$ after 9-11 to
> launch it full scale. I'd like to rewrite the framework I built our
> product on using Jboss and open source it. Something like Eclipse but
> not so IDE-centric in focus. Anyway, it modeled the EJB lifecycle for
You might be interested to know that the release plan for eclipse 2.2 includes a
separation of the IDE concern from the Application Framework concern. Although it is
possible now to use Eclipse as a non-IDE platform, I believe that they are going to
support this officially, perhaps even providing a separate download just for the
application framework component.
- Matt
-Original Message-
From: James Higginbotham [mailto:[EMAIL PROTECTED]]
Sent: Mon 12/23/2002 12:22 AM
To: [EMAIL PROTECTED]
Cc:
Subject: RE: [JBoss-dev] Dynamic Loading/Unloading of Plugins (was: RE:
[eclipse-dev] Eclipse Project 2.2 Draft Plan posted)
> How much of what you are thinking of would be handled by:
>
> jmx
Most if not all of it - the JMX timer would be responsible for the async
work of taking down and upgrading the module and its dependencies. In
addition, the rich client platform would benefit from JMX itself. The
only problem is transports between rich clients, but that is out of
scope for long enough that the JMX spec should catch up anyway. Besides,
JXTA could handle that if I really needed peer-to-peer rather than a
more client-server approach. Or, I could just use your built-in
clustering using JavaGroups as another option.
>
> jboss service lifecycle
All of it, as I would see a "module" as the equiv of an EJB on the
client side from the standpoint of componentized development and the
need for component lifecycles. I actually built a similar application
that was Swing-based, used JXTA, and resembled something like Groove..
We called it our "Groove Killer" but never got enough $$ after 9-11 to
launch it full scale. I'd like to rewrite the framework I built our
product on using Jboss and open source it. Something like Eclipse but
not so IDE-centric in focus. Anyway, it modeled the EJB lifecycle for
the "modules" and provided a "Module context" for accessing known
platform services, plus a service locator for a more dynamic lookup
(including web services on the desktop over JXTA - that was fun!).
>
> jboss mbean dependencies enhanced by including the version as
> a key in the ObjectName and using queries or filter
> conditions rather than equality for resolution of dependencies.
Jboss dependencies would be a must. I hadn't thought about versioning in
the name.. In the past I've shyed away from things like that in a
"name", but since its unique to the JMX container, that should be fine..
Like encoding the version number in a OID I guess.
>
> BTW in jboss 4 clients using the trunk invoker already have jmx client
> side: others will follow when I get to work on tx
> propagation for the other transports.
True, but I would want the JMX container initialized first thing..
Consider the typical startup as something like splash, init Jboss
Kernel, Load core platform services, load user services, launch user
application.
>
> david jencks
>
James
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
N¬±ùÞµéX¬²'²Þu¼)äç¤Yé\¢g¢½éá¶ÚþØbH zG(û %º,±×¯zZ)éí¨¥x%ËIn,uëÞfz{eËl²«qç讧zØm¶?þX¬¶Ë(º· ~àzwþX¬¶ÏåËbú?º,±×¯zZ)éí
Re: [JBoss-dev] Good-bye II
None of the JBG supporters has written everything by himself. This is of course a matter of control and organization, which you do very well as "master of the tree". I wont let everybody do everything, but if somebody wants to contribute "in the right direction" he should not be blocked. OTOH if somebody would insist to commit something you dont want to go in and he refuses to restrain himself this is another question. In the end you'll have to protect jbg (and jboss) from sabotage. I cannot judge about what happend in Andy's case; most of the discussion fortunately seems to have happened in private mail. I just want to get rid of the doubt that something went wrong due to political reasons. Otherwise contributors might come to the conclusion that they support jbg, not the jboss community. So I simply wanted to provoke some clarifications; a little bit of meta-discussion might be ok on this list and of interest for other contributors, too. Regards, Michael Bartmann PS.: The forum would be ok for me, simply tell me where to go... Scott M Stark wrote: Development and support are not separable. Do you let anyone modify code you support? This discussion needs to move the forums. Marc will take it up tomorrow. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Michael Bartmann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, December 23, 2002 1:54 AM Subject: Re: [JBoss-dev] Good-bye II - Andy: please keep cool and stay online (I like EJB timers :-) - Marc: consider developing and consulting as two different jboss ASPECTS. Again, I fear I misjudge because of lacking knowledge, but I couldn't resist to comment on this. I really don't like the idea of non-technical clash on jboss-developement. Regards, Michael Bartmann --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-657837 ] IllegalAccessException - after redeploy
Bugs item #657837, was opened at 2002-12-23 08:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=657837&group_id=22866 Category: JBossServer Group: None Status: Open Resolution: None Priority: 5 Submitted By: Eyal Lupu (eyall) Assigned to: Nobody/Anonymous (nobody) Summary: IllegalAccessException - after redeploy Initial Comment: OS: W2K JDK: 1.4.1 JBoss 3.0.4 We have an application build of 1 ear including: -5 EJB jars -2 WARs -1 SAR - and 10 library jars (/library/xxx.jar) There are no duplicate classes. After redeployment we start to get IllegalAccessException when accessing package protected method. If no redeployment has taken place everything works fine. We suspect that classes has more than one instance. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=657837&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] NEW STOCK PICK: TWLO - AMCG WENT UP 461%..................................................................................................................................................................................... ugmbi
Did you miss out on AMCG, UP 461%? Here's another pick - Another SHORT PLAY CLICK HERE Click here to unsubscribe buvvkfvfwmpulmohbpffydxwxqpnroqukpm --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Good-bye II
Development and support are not separable. Do you let anyone modify code you support? This discussion needs to move the forums. Marc will take it up tomorrow. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Michael Bartmann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, December 23, 2002 1:54 AM Subject: Re: [JBoss-dev] Good-bye II > > - Andy: please keep cool and stay online (I like EJB timers :-) > - Marc: consider developing and consulting as two different jboss ASPECTS. > > Again, I fear I misjudge because of lacking knowledge, but I couldn't > resist to comment on this. I really don't like the idea of > non-technical clash on jboss-developement. > > Regards, > Michael Bartmann --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] hello 100th was Good-bye II
> I really don't like the idea of > non-technical clash on jboss-developement. > should one open a new discussion board about this issue ? to prevent future invention of this uncomfortable stuff unconveniently. couldn't resist too bax > Regards, > Michael Bartmann > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Good-bye II
Oh my, it is difficult to judge with only "second hand" information, but I feel very annoyed about the (possible) mix of commercial aspects (between JBG and Andy as a consultant) with developement aspects. But should cvs write access be the battlefield for this? The jsr-77 issue is a separate question; there should be an authority which decides about directions. Maybe my understanding of all this is too naive: I thought there was the -1- the public (?) JBoss project (hosted by sf.net) and -2- the JBG owning the JBoss trademark and interested mostly in consulting Ok, these two domains mix up and I never had a problem with this, somebody has to lead the effort and the copyright of the original sources are held by Marc anyway, even if the LGPL license gives everybody the possibility to use and modify it. So this whole controversy seems sadly overloaded. I sincerly hope that you can solve this in a way which is the best technology wise. - Andy: please keep cool and stay online (I like EJB timers :-) - Marc: consider developing and consulting as two different jboss ASPECTS. Again, I fear I misjudge because of lacking knowledge, but I couldn't resist to comment on this. I really don't like the idea of non-technical clash on jboss-developement. Regards, Michael Bartmann --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Committed support for remote deployment scanning
> I hadn't, but have now. I have not changed > URLDirectoryScanner but attempted > to roll its functionality into the core URLDeploymentScanner using > collection URLs to discriminate - does this work for you? This would be great, thanks for taking the time. > It seems the root cause of your bug is the lack of response to the GET > request used by getLastModified(). This is basically Jetty > not responding to > a simple GET request which seems a bit more fundamental. I traced it as far as the connection being accepted on the netboot side and then being closed before the response was being sent. According to snoop there was no data returned in the response. I have previously encountered problems with WebSphere on Solaris where the socket accept started throwning exceptions which were not expected nor handled. It was tied down to a change in the Solaris IP stack. I don't know whether this is relevant. In any case I thought that the client side should be in a position to handle transient network errors, hence the fix I suggested. It was a real pain for us to have the resources undeploying and redeploying for no apparent reason. > The old netboot helper mapped the host server's configuration > to a /files > URL by adding a dedicated context handler. The new helper > does not use the > host server's configurations but instead stores the config in > a war - so, > the GET for last-modified is handled directly by the > container and if this > is broken, GET for any resource is broken :-( > > Did you ever find out why Jetty is closing the socket without > responding, or > log a bug for it? I haven't I'm afraid, I did enough to get the rest of my team working and left it at that :-(. I suspect it may be similar to the WebSphere problem that I had to work around. I'll have a quick look at it again and see if I can get any further, although we have just upgraded Solaris and it may no longer happen :-). Thanks again, Kev Kevin Conner This is a personal e-mail. Any views or opinions presented are solely those of the author and do not necessarily represent those of Orchard Information Systems Ltd. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Good-bye II
At 01:27 PM 12/22/2002 -0800, you wrote: At the end it also leads to the question if Marc or JBG can take JBoss, kick out all the developers and sell it. But I am not a layer and cannot answer the question. Isn't all the code LGPL? It is theoretically possible to remove CVS access to all the developers, but the code can be taken, modified, improved and released - it'd just need a different name since "JBoss" has been registered as a trademark (though you could state that you are based on / an extension of the JBoss code base). Anybody can take JBoss and sell it. Not sure why anybody would buy it though, the money in things like this is usually consulting. -Joe --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
