[JBoss-dev] I know why 'build/build.sh clean most' does not work any more...
Looks like in Ant 1.5 Project.getProperties() returns a copy of the properties map. The ExecuteModules task was dependent on removing the value of 'module' and 'target' properties after a module had been executing... bah! --jason --- 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://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/capability/OptimizedMBeanDispatcher.java:534: cannot resolve symbol [execmodules] symbol : class ACONST_NULL [execmodules] location: class org.jboss.mx.capability.OptimizedMBeanDispatcher [execmodules]invokeInstructions.append(new ACONST_NULL()); // Stack: = ..., null [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/capability/OptimizedMBeanDispatcher.java:535: cannot resolve symbol [execmodules] symbol : class ARETURN [execmodules] location: class org.jboss.mx.capability.OptimizedMBeanDispatcher [execmodules]invokeInstructions.append(new ARETURN()); // Stack: = empty [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/capability/OptimizedMBeanDispatcher.java:539: cannot resolve symbol [execmodules] symbol : class ARETURN [execmodules] location: class org.jboss.mx.capability.OptimizedMBeanDispatcher [execmodules]invokeInstructions.append(new ARETURN()); // Stack: = empty [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:58: warning: getPriority() in org.apache.log4j.Category has been deprecated [execmodules] return category.getPriority().toInt(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:64: warning: setPriority(org.apache.log4j.Priority) in org.apache.log4j.Category has been deprecated [execmodules] category.setPriority(Priority.toPriority(level)); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:82: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:100: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:118: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:136: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:154: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:172: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:190: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] 100 errors [execmodules] 9 warnings BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/jmx/build.xml:201: Compile failed; see the compiler error output for
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.0_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03) Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/capability/OptimizedMBeanDispatcher.java:534: cannot resolve symbol [execmodules] symbol : class ACONST_NULL [execmodules] location: class org.jboss.mx.capability.OptimizedMBeanDispatcher [execmodules]invokeInstructions.append(new ACONST_NULL()); // Stack: = ..., null [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/capability/OptimizedMBeanDispatcher.java:535: cannot resolve symbol [execmodules] symbol : class ARETURN [execmodules] location: class org.jboss.mx.capability.OptimizedMBeanDispatcher [execmodules]invokeInstructions.append(new ARETURN()); // Stack: = empty [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/capability/OptimizedMBeanDispatcher.java:539: cannot resolve symbol [execmodules] symbol : class ARETURN [execmodules] location: class org.jboss.mx.capability.OptimizedMBeanDispatcher [execmodules]invokeInstructions.append(new ARETURN()); // Stack: = empty [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:58: warning: getPriority() in org.apache.log4j.Category has been deprecated [execmodules] return category.getPriority().toInt(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:64: warning: setPriority(org.apache.log4j.Priority) in org.apache.log4j.Category has been deprecated [execmodules] category.setPriority(Priority.toPriority(level)); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:82: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:100: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:118: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:136: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:154: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:172: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:190: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] 100 errors [execmodules] 9 warnings BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/jmx/build.xml:201: Compile failed; see the compiler error output for
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/capability/OptimizedMBeanDispatcher.java:534: cannot resolve symbol [execmodules] symbol : class ACONST_NULL [execmodules] location: class org.jboss.mx.capability.OptimizedMBeanDispatcher [execmodules]invokeInstructions.append(new ACONST_NULL()); // Stack: = ..., null [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/capability/OptimizedMBeanDispatcher.java:535: cannot resolve symbol [execmodules] symbol : class ARETURN [execmodules] location: class org.jboss.mx.capability.OptimizedMBeanDispatcher [execmodules]invokeInstructions.append(new ARETURN()); // Stack: = empty [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/capability/OptimizedMBeanDispatcher.java:539: cannot resolve symbol [execmodules] symbol : class ARETURN [execmodules] location: class org.jboss.mx.capability.OptimizedMBeanDispatcher [execmodules]invokeInstructions.append(new ARETURN()); // Stack: = empty [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:58: warning: getPriority() in org.apache.log4j.Category has been deprecated [execmodules] return category.getPriority().toInt(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:64: warning: setPriority(org.apache.log4j.Priority) in org.apache.log4j.Category has been deprecated [execmodules] category.setPriority(Priority.toPriority(level)); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:82: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:100: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:118: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:136: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:154: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:172: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:190: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] 100 errors [execmodules] 9 warnings BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/jmx/build.xml:201: Compile failed; see the compiler error output for
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.0_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03) Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/capability/OptimizedMBeanDispatcher.java:534: cannot resolve symbol [execmodules] symbol : class ACONST_NULL [execmodules] location: class org.jboss.mx.capability.OptimizedMBeanDispatcher [execmodules]invokeInstructions.append(new ACONST_NULL()); // Stack: = ..., null [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/capability/OptimizedMBeanDispatcher.java:535: cannot resolve symbol [execmodules] symbol : class ARETURN [execmodules] location: class org.jboss.mx.capability.OptimizedMBeanDispatcher [execmodules]invokeInstructions.append(new ARETURN()); // Stack: = empty [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/capability/OptimizedMBeanDispatcher.java:539: cannot resolve symbol [execmodules] symbol : class ARETURN [execmodules] location: class org.jboss.mx.capability.OptimizedMBeanDispatcher [execmodules]invokeInstructions.append(new ARETURN()); // Stack: = empty [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:58: warning: getPriority() in org.apache.log4j.Category has been deprecated [execmodules] return category.getPriority().toInt(); [execmodules]^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:64: warning: setPriority(org.apache.log4j.Priority) in org.apache.log4j.Category has been deprecated [execmodules] category.setPriority(Priority.toPriority(level)); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:82: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:100: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:118: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:136: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:154: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:172: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] /disk/orig/home/lubega/jbossro/jboss-all/jmx/src/main/org/jboss/mx/logging/log4j/Log4jAdapter.java:190: warning: getChainedPriority() in org.apache.log4j.Category has been deprecated [execmodules] return p.isGreaterOrEqual(category.getChainedPriority()); [execmodules] ^ [execmodules] 100 errors [execmodules] 9 warnings BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/jmx/build.xml:201: Compile failed; see the compiler error output for
[JBoss-dev] Win32 Users README...
Can someone with a win32 workspace, which they build out of regularly using build.bat, please try to execute the build.sh script using tools/bin/sh.exe: ..\tools\bin\sh.exe build.sh I am hoping this will work well... if it does I would like to change the build.bat files to simple invoke the build.sh with the ASH win32 /bin/sh impl. Can someone please give it a try and let me know? Thanks, --jason --- 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] Build system changes :: README
I just finished some cleansing of the buildsystem. The build.xml files are much smaller now... as some of the complexity has moved to include files. I will be working on simplification of those include files a little later, as well as trying to increase the performance of the build. In case you missed the CVS changelog for my recent changes; this is what I did (as far as I can remember that is): o Updated all .cvsingore files o Updated build.sh and build.bat to not need any special properties o Cleaned up buildfragments, now only buildmagic, defaults, tools, targets modules (can still clean these up lots more) o Removed ~250 lines from each build.xml (common bits are references from the specific buildframement) o Removed the _available_* targets, path specs which do not use filesets do not complain when their files or directories are missing o 'jars' target has become 'output' o 'install' target has gone away o All common targets have been moved to targets.ent, targets which build files might want to override are prefixed with _default: o Fixed 'clean most' problems o Can now execute build (from build.sh anywhere... do not need to be in the project directory or the module directory. o All fragments are anchored on ../tools, same with custom buildmagic tasks. Might work now with vanilla Ant 1.5, but have not tested o Re-organized build/build.xml module group definitions o Fixed some problems when executing modules that the project would re-initialize. o Changed all _jars: targets to _output: * I am sure I changed more stuff, but I can't seem to think of them at the moment... If you have any questions or comments, please let me know. (NO FLAMES PLEASE... my fragile psyche can't handle it... =P) --jason --- 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://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/conf [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/deploy modules-most: partition-build: [move] Moving 34 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/lib [copy] Copying 112 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/lib [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/deploy [delete] Deleting 1 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/conf [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [move] Moving 1 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-common-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-system-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-j2ee.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jnp-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-jsr77-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-transaction-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-ejb-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-connector-client-factory.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-rmi-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/concurrent.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbosssx-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmq-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmqha.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossha-client.jar into
[JBoss-dev] Projects other than jboss-all (HEAD) :: README
I will get to fixing these projects shortly... chances are that none of them will be functional. Sorry for the inconvenience. I will try to have this fixed by tomorrow evening. FYI, I do not plan on back-porting any of the build system changes to pre-HEAD jboss-all flavors. --jason --- 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] [AUTOMATED] (HEAD) JBoss compilation failed
I believe this might be resolved by forcing a full checkout... but I can't get to lubega.com at the moment... --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, October 03, 2002 4:48 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed = ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/server/all/conf [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/server/all/deploy modules-most: partition-build: [move] Moving 34 files to /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/server/all/lib [copy] Copying 112 files to /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/server/default [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/server/default/lib [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/server/default/deploy [delete] Deleting 1 files from /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/server/default/conf [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/server/minimal/deploy [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/server/minimal/conf [move] Moving 1 files to /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/server/minimal/conf [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/server/minimal/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/server/minimal/deploy [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/server/minimal/lib [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss- all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/client/jboss-common-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/client/jboss-system-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/client/jboss-j2ee.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/client/jnp-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/client/jboss-jsr77-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/client/jboss-transaction-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/client/jboss-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/client/jmx-ejb-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/client/jmx-connector-client-factory.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/client/jmx-rmi-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/client/concurrent.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss- all/build/output/testbuild/client/jbosssx-client.jar into
RE: [JBoss-dev] Build system changes :: README
If you have any questions or comments, please let me know. (NO FLAMES PLEASE... my fragile psyche can't handle it... =P) Thank you for these changes Jason. We all love you. Cheers, Sacha --- 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
FW: [JBoss-dev] Projects other than jboss-all (HEAD) :: README
A side note about this... If you want to keep working with you project before I can updated your build files, I recommend that you do not update your workspace and that you do not make any build.xml changes. --jason --- 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-all daily clean failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.0_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03) Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE == == == == Executing 'clean' in module 'iiop'... == == _buildmagic:init: configure: configure-libraries: configure-modules: configure-defaults: configure-tools: _default:init: init: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/iiop/output _default:clean: clean: == == == Finished 'clean' in module 'iiop'. == == modules-clean: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/build/output clean: BUILD SUCCESSFUL Total time: 48 seconds SHUTDOWN --- 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] EJB's as Xmbeans?
On 2002.10.03 02:00:12 -0400 Scott M Stark wrote: Really? You want 2 complete sets of interceptor definititions with exactly the same functionality? I don't. The whole ejb interceptor layer should be deprecated if not replaced in 4.0. 1. change all the ejb interceptors so they only have an invoke method, no invokeHome. The kind of invocation is already carried in the invocation object, 2 methods are silly. that is good. Agreed. Let's keep our invokes clean in their implementation. It won't bring ANY feature and will just give us complex code. David, yes you can do it but it is useless and won't be understandable. Please don't touch that part. I have no problem not implementing (2), but I'm not sure you understand what I'm proposing since it looks to me as if you are arguing _for_ my idea. I'm proposing to make the mbean interceptors like the ejb interceptors in that they have the lifecycle methods explictly written, just like the ejb interceptors. st Several of the mbean interceptors already need the service lifecycle, they have ugly and fragile hacks since it is missing. I want to build it directly into our mbean infrastructure just as it is in our ejb infrastructure. current ejb interceptor: create start stop destroy setContainer setConfiguration setNext getNext invoke invokeHome //obsolete current mbean interceptor: getNext insert insertLast invoke proposed mbean interceptor: create start stop destroy setMBeanInvoker //not sure of name, this is like setContainer. getNext insert or setNext invoke Now, this is an mbean stack, so there needs to be something to call the lifecycle methods. It could be something in the top of the stack, but I think it is better to have a single interceptor that looks for lifecycle methods and recycles them through the stack. With this interceptor, there only has to be one thing looking for these methods. Without it, any interceptor that wants to participate in the service lifecycle has to look for itself. It looks to me as if you think my proposal will cause all the interceptors to have to look for themselves, whereas I am proposing the opposite. I don't see the need to throw away the ServiceController here. Rather, the Service proxy is what calls the lifecycle methods. When the controller calls create on the proxy it invokes create through the stack and ultimately this is invoked on the mbean. The same for all the other life cycle methods. I'm not sure if I want to completely remove ServiceController. I do want the ServiceProxy to be part of the final interceptor on the chain, calling methods on the actual managed object. The lifecycle calls always need to get to the interceptors so the mbean stack is set up properly, whether or not the managed object needs them. I want to remove the current anomoly that calling say start on an mbean directly bypasses the dependency checking whereas calling ServiceController.start(mbeanName) does the dependency checking. Putting the ServiceContext and dependency checking code in an interceptor will do this. What does the generalized container, metadata, and factories look like? I don't know yet, I have to do this one step at a time or I get confused. 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] [ jboss-Bugs-614116 ] Oracle XA pooling/repeated rollback
Bugs item #614116, was opened at 2002-09-24 17:56
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=614116group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Elias Ross (genman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Oracle XA pooling/repeated rollback
Initial Comment:
I've been trying to isolate some problems I've been
having with transaction roll-backs and message-driven
beans. Basically, when a transaction is rolled-back
a number of times in the onMessage() body
(by calling MessageDrivenContext.setRollbackOnly()
5-10 times in succession),
the message is re-delivered to the MDB, but the Oracle
Connection is no longer in a good state.
This problem manifests itself when using a very small
connection pool (say 1-5) connections.
Example code snippet:
public void onMessage(javax.jms.Message jmsMessage)
{
Connection c = null;
try {
TextMessage tm = (TextMessage)jmsMessage;
String text = tm.getText();
c = ds.getConnection();
PreparedStatement s = c.prepareStatement(insert into test values (?));
s.setString(1, text);
s.executeUpdate();
mdc.setRollbackOnly();
} catch (Exception e) {
throw new EJBException(e);
} finally {
if (c != null) {
try { c.close(); }
catch (Exception e) {
e.printStackTrace();
}
}
First I see it works for a few times. It rolls-back successfully
about 5 or 6 times. Then, for no reason, I see:
15:50:44,922 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//4,
BranchQual=] errorCode=XAER_RMERR
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.allowGlobalTxnModeOnly(OracleXAResource.java:1069)
at oracle.jdbc.xa.OracleXAResource.suspendStacked(OracleXAResource.java:296)
at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:381)
at org.jboss.tm.TxCapsule.endResource(TxCapsule.java:1237)
at org.jboss.tm.TxCapsule.delistResource(TxCapsule.java:579)
at org.jboss.tm.TransactionImpl.delistResource(TransactionImpl.java:92)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.delist(XATxConnectionManager.java:284)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.connectionClosed(XATxConnectionManager.java:331)
at
org.jboss.resource.adapter.jdbc.BaseManagedConnection.fireConnectionEvent(BaseManagedConnection.java:152)
at
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.fireConnectionEvent(XAManagedConnection.java:215)
at
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection$1.connectionClosed(XAManagedConnection.java:127)
at
oracle.jdbc.pool.OraclePooledConnection.callListener(OraclePooledConnection.java:482)
at
oracle.jdbc.pool.OraclePooledConnection.logicalClose(OraclePooledConnection.java:445)
at oracle.jdbc.driver.OracleConnection.logicalClose(OracleConnection.java:2900)
at oracle.jdbc.driver.OracleConnection.close(OracleConnection.java:1418)
at com.proteusmobile.smx.AMDB.onMessage(AMDB.java:140)
Later:
15:50:44,929 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//4,
BranchQual=] errorCode=XAER_RMERR
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.allowGlobalTxnModeOnly(OracleXAResource.java:1069)
at oracle.jdbc.xa.OracleXAResource.suspendStacked(OracleXAResource.java:296)
at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:381)
at org.jboss.tm.TxCapsule.endResource(TxCapsule.java:1237)
at org.jboss.tm.TxCapsule.endResources(TxCapsule.java:1312)
at org.jboss.tm.TxCapsule.rollback(TxCapsule.java:440)
at org.jboss.tm.TransactionImpl.rollback(TransactionImpl.java:83)
at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:301)
at
org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:603)
at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:417)
at org.jboss.mq.SpySession.run(SpySession.java:259)
at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:177)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:655)
at java.lang.Thread.run(Thread.java:479)
And then, I can no longer get a connection:
15:50:44,971 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//5,
BranchQual=] errorCode=XAER_PROTO
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.disallowLocalTxnMode(OracleXAResource.java:1045)
at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:153)
at org.jboss.tm.TxCapsule.startResource(TxCapsule.java:1180)
at org.jboss.tm.TxCapsule.enlistResource(TxCapsule.java:679)
at org.jboss.tm.TransactionImpl.enlistResource(TransactionImpl.java:102)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.enlist(XATxConnectionManager.java:262)
at
RE: [JBoss-dev] creating persistent MBeans dynamically
Juha, what you need to persist from the registry is the information to recreate the mbeans OK. Great. Sorry for the confusion. I think this information is essentially the MBeanInfo, the object name, and possibly, a dependency indicator (MB foo must be loaded after MB foobar). here. Incidentally, it appears to indicate that the entire MMB (MMB info and data) should be persisted at store(). no, just the state of the attributes (or diff update on one changed attribute, actually)... imagine an ON_UPDATE policy writing the whole metadata down to storage every time, doesn't make sense. Could you clarify the following from P. 87 of the spec? store Writes the MBean in a persistent store. Should only called by an implementation of the ModelMBean interface to store itself according to persistence policy for the MBean. When used, it may be called with every invocation of setAttribute or on a periodic basis. (optional) If the MBean is (MB info + state), then this clearly states that the *entire* MB is written. It is not specified how it is written (overwrite or write diff). I aggree that this does not make sense, especially considering the fact that dynamic changes to the MBeanInfo are ignored by the server. Perhaps this sentence should be re-written? developers are going to want to know that their beans will be treated similarly across implementations when it comes to the server lifecycle persistence. Does anyone coughJuha/cough know if this is likely? there doesn't seem to be much interest in that at the moment on the other hand it gives us the freedom to write implementations that make sense Well, I'm very interested. The work I do is spec-friendly. An important selling point for us with JBoss is flexibility via spec compliance. Since I see persistence as an invaluable feature for JMX, having it be a full fledged aspect of the spec is important for me. Perhaps if JBoss does it right, it will make its way into the spec eventually :) - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juha-P Lindfors Sent: Wednesday, October 02, 2002 5:39 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] creating persistent MBeans dynamically On Wed, 2 Oct 2002, Matt Munz wrote: Perhaps we're using 'persist' differently. The mbean registry contains object references to all of the mbeans in the server.To me, persisting the registry (or a part of it), means serializing those objects completely (MB info + data). no, the individual mbeans already persisted their state they need on their own, what you need to persist from the registry is the information to recreate the mbeans (who will then go an load() their own state they already persisted), ie which constructor to use at startup, what args go into the constructor As I understand it, MBs that want to persist their state must implement the PersistentMBean interface. If the state for all MBs in the server is also to be persisted, then I suppose that all MBs registered must be adapted to the PersistentMBean interface. Does this sound reasonable? I think you're confusing the two different modes of persistence: say I registered an XMbean instance from location http://foo/bar.xml (which is my mbean definition). When you register this mbean to the registry you pass in the valueMap that info, init(URL) was used with arg http://foo/bar.xml + objectname blah. Registry stores this info as part of its own state. When registry is recreated (server restart) it goes to its own persistence location and gets this info, calls the constructor, creates the new mbean instance, bar.xml has the persistence info for the mbean and the bean will load() its own state. I tried to scan the spec for some guidance, but was unable to find portions relating to persistence or lifecycle issues that would be relevant here. Incidentally, it appears to indicate that the entire MMB (MMB info and data) should be persisted at store(). no, just the state of the attributes (or diff update on one changed attribute, actually)... imagine an ON_UPDATE policy writing the whole metadata down to storage every time, doesn't make sense. It would definately be more convienient if some of these issues were addressed in the spec, IMHO. It seems to me that this whole discussion is a logical extension of MMB persistence in the first place, and that MB developers are going to want to know that their beans will be treated similarly across implementations when it comes to the server lifecycle persistence. Does anyone coughJuha/cough know if this is likely? there doesn't seem to be much interest in that at the moment on the other hand it gives us the freedom to write implementations that make sense -- Juha --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___
[JBoss-dev] jboss-all daily clean failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE == == == == Executing 'clean' in module 'iiop'... == == _buildmagic:init: configure: configure-libraries: configure-modules: configure-defaults: configure-tools: _default:init: init: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/iiop/output _default:clean: clean: == == == Finished 'clean' in module 'iiop'. == == modules-clean: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/build/output clean: BUILD SUCCESSFUL Total time: 46 seconds SHUTDOWN --- 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] creating persistent MBeans dynamically
On Thu, 3 Oct 2002, Matt Munz wrote: Juha, what you need to persist from the registry is the information to recreate the mbeans OK. Great. Sorry for the confusion. I think this information is essentially the MBeanInfo, the object name, and possibly, a dependency indicator (MB foo must be loaded after MB foobar). all of mbeaninfo should not be always stored. for instance, if I instantiate my MMB by using a definition from an URL or db then the mbeaninfo is already persisted there and should not be duplicated (only the ref to where to locate it is needed). This is to avoid the confusion to users where an mbean seems to be stored in two different locations (we already had this problem with 2.0). If on the other hand you created the mbean info at runtime then obviously you need to persist it. The only changing part in the metadata should be the descriptor which should be persisted regardless of how the mbeaninfo was loaded to the runtime system in the first place. So a simple key, value map or a property file even. The rest of the metadata should remain unchanged during the lifetime of the MBean. Could you clarify the following from P. 87 of the spec? how an mbean is persisted is really not defined in the spec. If the MBean is (MB info + state), then this clearly states that the *entire* MB is written. It is not specified how it is written (overwrite or write diff). I aggree that this does not make sense if the assumption doesn't make sense, and we both agree it doesn't make sense, then concentrate on the part that *does* make sense ;-) Well, I'm very interested. The work I do is spec-friendly. An important selling point for us with JBoss is flexibility via spec compliance. Since I see persistence as an invaluable feature for JMX, having it be a full fledged aspect of the spec is important for me. Perhaps if JBoss does it right, it will make its way into the spec eventually :) perhaps -- Juha --- 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] creating persistent MBeans dynamically
Well, I'm very interested. The work I do is spec-friendly. An important selling point for us with JBoss is flexibility via spec compliance. Since I see persistence as an invaluable feature for JMX, having it be a full fledged aspect of the spec is important for me. Perhaps if JBoss does it right, it will make its way into the spec eventually :) The spec moves slowly and they don't standardize advanced stuff (like simple interceptors), so I would focus on ourselves for now. We clearly push the technology through the channels at SUN but it takes time. Put it in JBoss and use the feature. The specs will follow one day, in the mean time we have a working implementation. JBoss vs.NET is an implementation war finally, The spec is dead long live the implementation. marc f --- 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-all daily clean failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.0_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03) Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE == == == == Executing 'clean' in module 'iiop'... == == _buildmagic:init: configure: configure-libraries: configure-modules: configure-defaults: configure-tools: _default:init: init: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/iiop/output _default:clean: clean: == == == Finished 'clean' in module 'iiop'. == == modules-clean: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/build/output clean: BUILD SUCCESSFUL Total time: 50 seconds SHUTDOWN --- 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://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.0_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03) Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/conf [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/deploy modules-most: partition-build: [move] Moving 34 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/lib [copy] Copying 112 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/lib [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/deploy [delete] Deleting 1 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/conf [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [move] Moving 1 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-common-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-system-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-j2ee.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jnp-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-jsr77-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-transaction-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-ejb-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-connector-client-factory.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-rmi-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/concurrent.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbosssx-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmq-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmqha.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossha-client.jar into
RE: [JBoss-dev] Directory hot-deploy granularity
Hi,
I've been working on this and have run into a problem that
I hope someone can clear up real quick. I'm trying to get
a list of the EJB's deployed within an EAR. I go through
DeploymentInfo.subDeployments, and it looks like what I
need to do is for each of these sub-deployments, get the
DeploymentInfo instance, get the DeploymentInfo.deployedObject,
and mess around with it. Being new to the code I have no idea
where to look for the EJB's in each subDeployment, but my guess
was to do something like
Collection c = (Collection)server.invoke(di.deployedObject,
getContainers,
new Object[]{},
new String[]{});
where di is an instance of DeploymentInfo, since the
getContainers() method is defined in EjbModuleMBean.
However, the method apparently is not available. So my
questions are:
1. Is the information on the EJB's actually in the containers
collection or should I look somewhere else instead?
2. What method are available to be called on di.deployedObject?
How can I find out? Note that di.deployedObject.toString()
for the deployedObject in question is the following:
jboss.j2ee:service=EjbModule,url=...etc...
Thanks in advance for any answers!
Dani
-Original Message-
From: marc fleury [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 02, 2002 4:48 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Directory hot-deploy granularity
microwave popcorn -- Wait until 2 seconds between pops
before removing from the microwave.
clear communication is Good,
just go ahead guys,
marc f
---
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] EJB's as Xmbeans?
all that is needed is init, start, stop, destroy On Thu, 3 Oct 2002, David Jencks wrote: proposed mbean interceptor: create start stop destroy setMBeanInvoker //not sure of name, this is like setContainer. getNext insert or setNext invoke Now, this is an mbean stack, so there needs to be something to call the lifecycle methods. It could be something in the top of the stack, but I think it is better to have a single interceptor that looks for lifecycle methods and recycles them through the stack. no, the invoker initializes its own interceptor stack, it can call init, start, stop, destroy explicitly. -- Juha --- 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-all daily clean failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE == == == == Executing 'clean' in module 'iiop'... == == _buildmagic:init: configure: configure-libraries: configure-modules: configure-defaults: configure-tools: _default:init: init: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/iiop/output _default:clean: clean: == == == Finished 'clean' in module 'iiop'. == == modules-clean: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/build/output clean: BUILD SUCCESSFUL Total time: 45 seconds SHUTDOWN --- 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-606704 ] Log bean when checking method permission
Bugs item #606704, was opened at 2002-09-09 15:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=606704group_id=22866 Category: JBossSX Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mathias Bogaert (pathoss) Assigned to: Nobody/Anonymous (nobody) Summary: Log bean when checking method permission Initial Comment: When no method permission is assigned to a remote method you get the following exception: 2002-09-09 15:02:19,851 ERROR [org.jboss.ejb.plugins.LogInterceptor] EJBException, causedBy: java.lang.SecurityException: No method permissions assigned to method=retrieve, interface=REMOTE at org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityInterceptor.java:190) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:119) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:203) at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313) at org.jboss.ejb.Container.invoke(Container.java:720) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:370) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) at sun.rmi.transport.Transport$1.run(Transport.java:147) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:143) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:479) 2002-09-09 15:02:20,226 ERROR [org.jboss.ejb.plugins.SecurityInterceptor] No method permissions assigned to method=retrieve, interface=REMOTE 2002-09-09 15:02:20,226 ERROR [org.jboss.ejb.plugins.LogInterceptor] EJBException, causedBy: java.lang.SecurityException: No method permissions assigned to method=retrieve, interface=REMOTE at org.jboss.ejb.plugins.SecurityInterceptor.checkSecurityAssociation(SecurityInterceptor.java:190) at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:119) at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:203) at org.jboss.ejb.StatelessSessionContainer.invoke(StatelessSessionContainer.java:313) at org.jboss.ejb.Container.invoke(Container.java:720) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:517) at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:370) at java.lang.reflect.Method.invoke(Native Method) at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236) at sun.rmi.transport.Transport$1.run(Transport.java:147) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.transport.Transport.serviceCall(Transport.java:143) at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460) at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701) at java.lang.Thread.run(Thread.java:479) But this doesn't show what bean the problem is in!! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=606704group_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] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/conf [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/deploy modules-most: partition-build: [move] Moving 34 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/lib [copy] Copying 112 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/lib [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/deploy [delete] Deleting 1 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/conf [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [move] Moving 1 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-common-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-system-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-j2ee.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jnp-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-jsr77-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-transaction-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-ejb-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-connector-client-factory.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-rmi-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/concurrent.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbosssx-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmq-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmqha.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossha-client.jar into
Re: [JBoss-dev] Directory hot-deploy granularity
In principle I think this is a good idea. I'm not 100% sure the possible implementation complexity will be worth the gains... 1. You can already redeploy a subpackage of even a packed .ear by using the jmx console and MainDeployer.redeploy. You can do the same thing with the ant jmx task. Personally I think that using the ant jmx task to deploy/redeploy explicitly is more development-friendly tnan copying to a particular directory. In any case I highly recommend you try this out in various combinations to see what will work... 2. You may need a UnifiedClassLoader per class or to reload substantial parts of the application or be very careful about packaging. At the minimum you will have to keep ejb interfaces and implementations in separate packages so you don't have to reload the servlet clients. With the project I've played with redeploy just a bit with I haven't straightened out how to redeploy just the ejb implementations without the interfaces or depending packages. david jencks On 2002.10.02 13:38:01 -0400 Gredler, Dani wrote: Hi, I'm thinking about adding some code to JBoss to provide better granularity to the [hot] deployment of directories. Here's the situation: I'm getting tired of repackaging my EJB's into a JAR, creating a WAR, combining them into an EAR, dropping the EAR file into the deployment directory, and waiting for the whole EAR to redeploy before testing my one-line change. Now, I know JBoss lets you drop a directory in the hot-deploy directory, and as long as it matches the EAR file structure, it will deploy it, and I have considered using this. What I would like, however, is to be able to make my one-line change to one of the EJB's in the directory, recompile the .class file, and have JBoss automatically recognize that the one EJB in the application needs to be redeployed, instead of having to redeploy the whole application. This would speed my development on JBoss incredibly, and would mitigate what I consider to be the Achilles heel of J2EE development. I've looked through the JBoss code available for download on the site, and from my quick perusing am inclined to think that, among others, my changes need to happen in: org.jboss.net.protocol.file.FileURLConnection - change the implementation of getLastModified() so that it recurses all subdirectories and checks all files for modifications, not just the base directory. org.jboss.deployment.URLDeploymentScanner - change the implementation of scan() so that modified directories do not get bluntly undeployed and redeployed. Instead, intelligently determine which parts of the application need redeploying, and do them instead. Basically I'm looking for feedback here. Is there an easier way to achieve my goal than this? If not, am I on the right track as far as how to make the changes? Does anyone who is more familiar with the code than I have any suggestions or pointers? Thanks for reading my long rambling post :) Dani --- 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] EJB's as Xmbeans?
Ok, but should the lifecycle of the interceptors be the same as the lifecycle of the bean? Right now a service is an mbean that is available through the jmx-console indepedenent of its JBoss service lifecycle notion. How is that going to change if the dependency is embedded into the interceptors? Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 03, 2002 5:23 AM Subject: Re: [JBoss-dev] EJB's as Xmbeans? I want to remove the current anomoly that calling say start on an mbean directly bypasses the dependency checking whereas calling ServiceController.start(mbeanName) does the dependency checking. Putting the ServiceContext and dependency checking code in an interceptor will do this. --- 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-all daily clean failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.0_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03) Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE == == == == Executing 'clean' in module 'iiop'... == == _buildmagic:init: configure: configure-libraries: configure-modules: configure-defaults: configure-tools: _default:init: init: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/iiop/output _default:clean: clean: == == == Finished 'clean' in module 'iiop'. == == modules-clean: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/build/output clean: BUILD SUCCESSFUL Total time: 49 seconds SHUTDOWN --- 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] JbossTX vs. Tyrex
On 2002.09.27 16:21:33 -0400 Igor Fedorenko wrote: David Jencks wrote: Hi Igor, I'd like to stick with the jboss tm and add the needed functionality. Can you outline what you have been thinking of? I want to allow resource manager specific variation of XAResource state change sequence. This way we'll decouple different RMs from each other and developers will be able to concentrate on one RM without concerns to break others. I have very brief idea how this can be implemented, but I believe it is doable and not too complicated. I'd like to see what you have in mind. Also, is the new xa wrapper in cvs HEAD working well enough to move to 3.2? Should we even move it to 3.0? What do you think about cached javax.jdbc.XAConnection.getConnection() problem I've mentioned few days ago? Can we afford saying Oracle 8i is not supported in XA mode? I don't know... saying it isn't supported might be better than all the problems people are having. Do you think it is ok to get a new Connection from the XAConnection whenever associateConnection is called? If we can do this, it wouldn't be too hard to change. I'm still mystified as to how Oracle can tell how many Connection handles we are using and how it can decide to object. thanks david jencks I think there may still be issues in what xa flags we send in the start/end calls, but I haven't had time to make a complete analysis. Thanks! david jencks On 2002.09.27 11:05:57 -0400 Igor Fedorenko wrote: Thank you, David. JBossTX still has problems with oracle (see for example #614116 I've been working on recently) and I was thinking if it worth fixing or we can switch to Tyrex. I have a solution that will solve JBossTX compatibility problems once and forever, however this solution is not trivial to implement and I am looking for alternatives. David Jencks wrote: jboss tm -- fast. Does not handle distributed (multiple jboss instances) tx. Does not do tx logging, so automated recovery is not really possible. tyrex tm -- does handle distributed tx and logging. both will handle xa transactions with many participants where there is only one tm instance and nothing crashes. If you need distributed tx (several cooperating tm) or automatic recovery use tyrex. The distributed part is nearly done in jboss 4 for the jboss tm: as part of the jca 1.5 support there is a tx import facility. We just need an invoker that has an XAResource in the client half and uses the Work interfaces in the server half. AFAIK no one is working on the logging part, but I don't see why it should be hard. With logging in place I would expect automatic recovery to be fairly simple also but I haven't thought about it much. david jencks On 2002.09.27 09:37:50 -0400 Igor Fedorenko wrote: Hi, Could somebody give brief comparison JBossTX and Tyrex transaction manager and explain when I should prefer one over another? Thanks in advance. -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.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 -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.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: [JBoss-dev] Directory hot-deploy granularity
The code you are looking for may be changed extensively by me in the near
future, I'm slowly migrating it to use the mbean framework rather than
duplicate functionality.
In HEAD find the DeploymentInfo for the EJB module and get its list of
mbeans. This list contains the EjbModule mbean and all the containers.
You can figure out which are containers by looking at the object names.
The presence and contents of the mbeans list is not likely to change. What
is in the DeploymentInfo may.
thanks
david jencks
On 2002.10.03 10:35:09 -0400 Gredler, Dani wrote:
Hi,
I've been working on this and have run into a problem that
I hope someone can clear up real quick. I'm trying to get
a list of the EJB's deployed within an EAR. I go through
DeploymentInfo.subDeployments, and it looks like what I
need to do is for each of these sub-deployments, get the
DeploymentInfo instance, get the DeploymentInfo.deployedObject,
and mess around with it. Being new to the code I have no idea
where to look for the EJB's in each subDeployment, but my guess
was to do something like
Collection c = (Collection)server.invoke(di.deployedObject,
getContainers,
new Object[]{},
new String[]{});
where di is an instance of DeploymentInfo, since the
getContainers() method is defined in EjbModuleMBean.
However, the method apparently is not available. So my
questions are:
1. Is the information on the EJB's actually in the containers
collection or should I look somewhere else instead?
2. What method are available to be called on di.deployedObject?
How can I find out? Note that di.deployedObject.toString()
for the deployedObject in question is the following:
jboss.j2ee:service=EjbModule,url=...etc...
Thanks in advance for any answers!
Dani
-Original Message-
From: marc fleury [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 02, 2002 4:48 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] Directory hot-deploy granularity
microwave popcorn -- Wait until 2 seconds between pops
before removing from the microwave.
clear communication is Good,
just go ahead guys,
marc f
---
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] RE: [Tapestry-developer] .jwc files
Tapestry doesn't care about file extensions. By convention, page-specifications are .page and component-specifications are .jwc. Earlier versions of tapestry didn't differentiate between page-specification and component-specification, pages and components alike used .jwc. -- [EMAIL PROTECTED] http://tapestry.sf.net I believe that what used to be called a .jwc is now called a .page file.. I am not sure what version it changed over.. but the new 2.2 uses .page. Luke Galea Software Development BlueCat Networks 905-762-5225 -Original Message- From: Schneider, Eric [mailto:[EMAIL PROTECTED]] Sent: October 3, 2002 11:45 AM To: [EMAIL PROTECTED] Subject: [Tapestry-developer] .jwc files Hi, I've just started looking at Tapestry today for the first time. So far it seems pretty straight forward. Pages and components seem to have .page, .java, and .html files associated with them. One thing I'm not clear about is when you are required to have a .jwc file. From the docs and examples I've looked at there only seem to .jwc file with page wrapping components. Can someone explain when these files are appropriate? Thanks, Eric ** This message, including any attachments, contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, please contact sender immediately by reply e-mail and destroy all copies. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. TIAA-CREF ** --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer --- 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-Bugs-617574 ] Classloader deadlock
Hello marc, That's not enough to simply add this: as the JVM will automatically create one instance of this class (no arg constructor), we would end up with a UCL that don't have an associated Repository. We will need to implement a new classloader that delegates loading correctly. Do you think that delegating to the context classloader is enough? In multi-Repository situations, does the current repository is correctly associated with each thread? (maybe that's one for Scott) Cheers, Sacha -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]De la part de marc fleury Envoye : mercredi, 2 octobre 2002 20:18 A : [EMAIL PROTECTED] Objet : RE: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock I come back again with my old trick that hadn't much success in the past. To solve the system class loader problem definitivly, at least with JDK 1.4 and upper, why not use the java.system.class.loader system property (see javadoc of java.lang.Classloader.getSystemClassLoader). Sacha that is the solution, also it makes sure that cretins that don't delegate to context get this working properly. Can you add the System ClassLoader definition to the run scripts? thanks marc f --- 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] Build system changes :: README
Hi Jason, even with a completely new checkout the build of jboss-all fails for me with Java 1.4.1-b21on Linux. Using java 1.3.1 on ReliantUnix works fine. Tagets build and clobber fail with the same Exception immediatly. Executing: /home/jboss/java/JBoss-cvs/jboss-all/tools/bin/ant -find build.xml clobber Searching for build.xml ... Buildfile: /unixware/home/jboss/java/JBoss-cvs/jboss-all/build/build.xml Trying to override old definition of task property _buildmagic:init: _buildmagic:init:global: _buildmagic:init:local-properties: _buildmagic:init:buildlog: configure: configure-libraries: configure-modules: configure-defaults: configure-tools: _configure:xdoclet:tasks: _configure:xdoclet:ejbdoclet: _configure:xdoclet:webdoclet: configure-project: [echo] groups: default [echo] modules: jmx,common,system,j2ee,naming,management,transaction,server,blocks,console,security,messaging,connector,varia,cluster,jetty,jboss.net,iiop _default:init: init: _buildmagic:clobber: [delete] Deleting: /unixware/home/jboss/java/JBoss-cvs/jboss-all/build/local.properties [delete] Deleting: /unixware/home/jboss/java/JBoss-cvs/jboss-all/build/build.log _buildmagic:modules:clean: BUILD FAILED java.lang.IllegalAccessError: tried to access field org.apache.tools.ant.ProjectComponent.project from class org.jboss.tools.buildmagic.task.module.ExecuteModules$MyEcho at org.jboss.tools.buildmagic.task.module.ExecuteModules$MyEcho.execute(ExecuteModules.java:416) at org.jboss.tools.buildmagic.task.module.ExecuteModules.printHeading(ExecuteModules.java:338) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(ExecuteModules.java:312) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteModules.java:209) at org.apache.tools.ant.Task.perform(Task.java:317) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:334) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) Total time: 6 seconds java.lang.IllegalAccessError: tried to access field org.apache.tools.ant.ProjectComponent.project from class org.jboss.tools.buildmagic.task.module.ExecuteModules$MyEcho at org.jboss.tools.buildmagic.task.module.ExecuteModules$MyEcho.execute(ExecuteModules.java:416) at org.jboss.tools.buildmagic.task.module.ExecuteModules.printHeading(ExecuteModules.java:338) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(ExecuteModules.java:312) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteModules.java:209) at org.apache.tools.ant.Task.perform(Task.java:317) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:334) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) tried to access field org.apache.tools.ant.ProjectComponent.project from class org.jboss.tools.buildmagic.task.module.ExecuteModules$MyEcho SHUTDOWN Regards Frank Jason Dillon wrote: I just finished some cleansing of the buildsystem. The build.xml files are much smaller now... as some of the complexity has moved to include files. I will be working on simplification of those include files a little later, as well as trying to increase the performance of the build. In case you missed the CVS changelog for my recent changes; this is what I did (as far as I can remember that is): o Updated all .cvsingore files o Updated build.sh and build.bat to not need any special properties o Cleaned up buildfragments, now only buildmagic, defaults, tools, targets modules (can still clean these up lots more) o Removed ~250 lines from each build.xml (common bits are references from the specific buildframement) o Removed the _available_* targets, path specs which do not use filesets do not complain when their files or directories are missing o 'jars' target has become 'output' o 'install' target has gone away o All common targets have been moved to targets.ent, targets which build files might want to override are prefixed with _default: o Fixed 'clean most' problems o Can now execute build (from build.sh anywhere... do not need to be in the project directory or the module directory. o All fragments are anchored on ../tools, same with custom buildmagic tasks.
[JBoss-dev] jboss-all daily clean failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE == == == == Executing 'clean' in module 'iiop'... == == _buildmagic:init: configure: configure-libraries: configure-modules: configure-defaults: configure-tools: _default:init: init: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/iiop/output _default:clean: clean: == == == Finished 'clean' in module 'iiop'. == == modules-clean: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/build/output clean: BUILD SUCCESSFUL Total time: 47 seconds SHUTDOWN --- 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://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/conf [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/deploy modules-most: partition-build: [move] Moving 34 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/lib [copy] Copying 112 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/lib [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/deploy [delete] Deleting 1 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/conf [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [move] Moving 1 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-common-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-system-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-j2ee.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jnp-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-jsr77-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-transaction-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-ejb-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-connector-client-factory.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-rmi-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/concurrent.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbosssx-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmq-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmqha.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossha-client.jar into
[JBoss-dev] jboss-all daily clean failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.0_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03) Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE == == == == Executing 'clean' in module 'iiop'... == == _buildmagic:init: configure: configure-libraries: configure-modules: configure-defaults: configure-tools: _default:init: init: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/iiop/output _default:clean: clean: == == == Finished 'clean' in module 'iiop'. == == modules-clean: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/build/output clean: BUILD SUCCESSFUL Total time: 49 seconds SHUTDOWN --- 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://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.0_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03) Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/conf [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/deploy modules-most: partition-build: [move] Moving 34 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/lib [copy] Copying 112 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/lib [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/deploy [delete] Deleting 1 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/conf [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [move] Moving 1 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-common-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-system-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-j2ee.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jnp-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-jsr77-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-transaction-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-ejb-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-connector-client-factory.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-rmi-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/concurrent.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbosssx-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmq-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmqha.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossha-client.jar into
[JBoss-dev] ¯Â°Ó·~¿ì¤½«Ç¥X¯²
**
¯Â°Ó·~¿ì¤½«Ç¥X¯²
**
±MªùªA°È°Ó¥Î¿ì¤½«Ç¤§©Ó¯²¤H¡C
¥x¥_¦Uµ¥¯Å°Ó¥Î¿ì¤½«Ç®×¥ó¡A¾A¦X¦UºØ°Ó·~»Ý¨D¡I¡I
§Ú֦̾³ºZ³qªº¸ê°T¡B¦³«Ü¦h¥ß§Yn¥X¯²ªº¿ì¤½«Ç¡A¥¿µ¥«ÝµÛ±zªº¬D¿ï¡A
¤@©wn¬°±z§ä¨ì¤@³B³Ì¾A¦X±z¹ê²{±z¶¯¹Ï§§§Óªº³õ©Ò¡I¡I¡I¡I
Á|¨Ò¦p¤U¡G
°Ï°ì¡G
¤j¦w°Ï¡G ¤¯·R¸ô¡B´°¤Æ«n¡B¥_¸ô
50-300©W¡]¯²ª÷1200-2500¤¸¡^¡B
¯Â¿ì®ð¬£¤j¼Ó¡A²{¦¨¦Ê¸U¸ËæC¡]§K³»Åýª÷¡^¡B
°¨¤W¥i¨Ï¥Î
«H¸q°Ï¡G «H¸q¸ô¤@¡B¤G¡B¤T¡B¥|¡B¤¬q¡C
30-500©W¡]1200-2100¤¸¡^
¥þ·s®ð¬£¤j¼Ó¡Bªñ±¶¹B¯¸¤f¡B¥æ³q¤è«K
¡]¯²ª÷¦X²z¡B¥i±Ä³»ù¡^
ªQ¤s°Ï¡G «n¨ÊªF¸ô¤T¡B¥|¡B¤¡B¬q
30-450©W¡]¯²ª÷1000-1800¤¸¡^
®ð¬£¡B´ºÆ[µ´¨Î
¤¤¤s°Ï¡G ªQ¦¿¸ô¡Bªø¦wªF¸ô¡A¤¤¤s¥_¸ô
70¢w400©W¡]¯²ª÷1000-2200¤¸¡^
¯Â¿ì¡B²{¦³¸ËæC
¦è °Ï¡G ©¾§µ¦è¸ô¡BÀ]«e¸ô¡B©Ó¼w¸ô¡B¿Å¶§¸ô
50-500©W
¦Ê¸U¸ËæC¡B«K©y¥X¯²¡]Åwªï¬Ý«Î¡^
¤º´ò°Ï¡G «¹º°Ï
80-500©W1300¤¸°_¡C½Ð§â´¤¨}¾÷
¥þ·s®ð¬£¤j¼Ó¡B²{¦³¸ËæC¡B°¨¤W¥i¨Ï¥Î
ªA°È²Ä¤@¡A«~½è«OÃÒ¡CÅwªï¬¢¸ß.
·ç°T¤£°Ê²£ °Ó¥ò³¡
Ápµ¸¤H¡G³³¤p©j ·q¤W
TeL¡]¥Nªí¸¹¡^¡G 02-27492314
¦æ°Ê¹q¸Ü¡G0937063831
±zªºº¡·N¡A¬O§Ú̪º¦¨´N¡I¡I¡I¡I
---
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-all daily clean failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE == == == == Executing 'clean' in module 'iiop'... == == _buildmagic:init: configure: configure-libraries: configure-modules: configure-defaults: configure-tools: _default:init: init: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/iiop/output _default:clean: clean: == == == Finished 'clean' in module 'iiop'. == == modules-clean: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/build/output clean: BUILD SUCCESSFUL Total time: 44 seconds SHUTDOWN --- 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://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/conf [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/deploy modules-most: partition-build: [move] Moving 34 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/lib [copy] Copying 112 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/lib [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/deploy [delete] Deleting 1 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/conf [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [move] Moving 1 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-common-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-system-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-j2ee.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jnp-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-jsr77-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-transaction-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-ejb-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-connector-client-factory.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-rmi-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/concurrent.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbosssx-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmq-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmqha.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossha-client.jar into
RE: [JBoss-dev] creating persistent MBeans dynamically
Juha, sometimes design-by-email is not a fast route :) ... all of mbeaninfo should not be always stored. for instance, if I instantiate my MMB by using a definition from an URL or db then the mbeaninfo is already persisted there and should not be duplicated (only the ref to where to locate it is needed). This is to avoid the confusion to users where an mbean seems to be stored in two different locations (we already had this problem with 2.0). If on the other hand you created the mbean info at runtime then obviously you need to persist it. Perhaps I'm too simplistic, but I think that the server is either responsible for MB info persistence, or it isn't. How about this? -- When I register my MB with the server, the server takes a peek at the MB's descriptor. If it says Persist my info, then the server takes responsibility for persisting the MB info; else, the server operates as it does now. The entity that persists the MB info should be responsible for loading it at server start. If MBean info persistence customization is required, I suppose we can have an MBeanInfoPersistenceManager with store() and load() methods similar to the PersistenceManager used to store MBean state, but is this really necessary? Either way, what is the benefit of saving part of the MBeanInfo in location A, and part of it in location B? Please explain :) I don't have the pleasure of knowing 2.0 ;), but I think I kind of know what you're talking about. Deployment of XMBeans, for example, involves two similar files with nonetheless distinct roles. I think it is necessary to either separate or merge the ideas of the deploy folder and the MB info store. I favor the former. It is easy for me to treat files in the deploy dir as deployment descriptors, and files in the MB info store as server state files. This perhaps could be indicated with appropriate naming conventions, comments, and documentation. If it is clear that modifications in the deploy folder will re-deploy the entire application, while the MB info store is generated and maintained by the server, I think the confusion will go away. Between the http jmx-console, JMX-GUI interfaces, the JMX API, and ANT JMX support, people have plenty of ways to modify the state of the server at runtime. Hacking the files in the store should be considered at-your-own-risk. These files will be generated by the server and loaded at startup only. The other option is to say that the deploy folder is the MB info store (this is kind of how it works today). I don't favor this -- I like to keep my peas on one side of the plate, and my mash potatoes on the other side ;) There is a way to make this work, if desired, but I believe that the route there is to delegate the responsibility for MB info persistence to an object other than the MB registry. Perhaps you have a use case / user story in mind that I can use as a guide. For my MBs, there is no MB info storage -- adding this mechanism will give me one and only one location for that state. This is how it should be in general, I think. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juha-P Lindfors Sent: Thursday, October 03, 2002 10:07 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] creating persistent MBeans dynamically On Thu, 3 Oct 2002, Matt Munz wrote: Juha, what you need to persist from the registry is the information to recreate the mbeans OK. Great. Sorry for the confusion. I think this information is essentially the MBeanInfo, the object name, and possibly, a dependency indicator (MB foo must be loaded after MB foobar). all of mbeaninfo should not be always stored. for instance, if I instantiate my MMB by using a definition from an URL or db then the mbeaninfo is already persisted there and should not be duplicated (only the ref to where to locate it is needed). This is to avoid the confusion to users where an mbean seems to be stored in two different locations (we already had this problem with 2.0). If on the other hand you created the mbean info at runtime then obviously you need to persist it. The only changing part in the metadata should be the descriptor which should be persisted regardless of how the mbeaninfo was loaded to the runtime system in the first place. So a simple key, value map or a property file even. The rest of the metadata should remain unchanged during the lifetime of the MBean. Could you clarify the following from P. 87 of the spec? how an mbean is persisted is really not defined in the spec. If the MBean is (MB info + state), then this clearly states that the *entire* MB is written. It is not specified how it is written (overwrite or write diff). I aggree that this does not make sense if the assumption doesn't make sense, and we both agree it doesn't make sense, then concentrate on the part that *does* make sense ;-) Well, I'm very interested. The work I do is spec-friendly. An
[JBoss-dev] jboss-all daily clean failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.0_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03) Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE == == == == Executing 'clean' in module 'iiop'... == == _buildmagic:init: configure: configure-libraries: configure-modules: configure-defaults: configure-tools: _default:init: init: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/iiop/output _default:clean: clean: == == == Finished 'clean' in module 'iiop'. == == modules-clean: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/build/output clean: BUILD SUCCESSFUL Total time: 44 seconds SHUTDOWN --- 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://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.0_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03) Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/conf [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/deploy modules-most: partition-build: [move] Moving 34 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/lib [copy] Copying 112 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/lib [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/deploy [delete] Deleting 1 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/conf [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [move] Moving 1 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-common-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-system-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-j2ee.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jnp-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-jsr77-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-transaction-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-ejb-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-connector-client-factory.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-rmi-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/concurrent.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbosssx-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmq-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmqha.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossha-client.jar into
[JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
Bugs item #617574, was opened at 2002-10-02 07:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=617574group_id=22866 Category: JBossMX Group: v3.2 Status: Pending Resolution: Fixed Priority: 7 Submitted By: Michael Bartmann (bartmann) Assigned to: Scott M Stark (starksm) Summary: Classloader deadlock Initial Comment: We have for the third time in quite some weeks experienced a partial lookup of the JBoss server (some services responsive, others not). The bug is not deterministically reproducible for us. But this time we luckily had a debugger online and drilled down to what seems to be a classloader deadlock. This was under NT4.0 (it happend before under W2000 also) We used Branch_3_2 (checkout 12 hours before it went beta) under JDK1.4.0-b92. It happened when many separate ear-scoped mbeans and dependent MDBs got deployed in a short time. Many of the mbeans are JMSProviders and the MDBs recieve external messages almost immediatelly after startup, so they all try to load classes simultaneously. Most of the threads were waiting for a lock at line 84 in the loadClass() of HeirarchicalLoaderRepository2; only one threads was locked in loadClass() of java.lang.ClassLoader. The two threads which seem to have caused the deadlock were Thread-47 (java.util.TimerThread) and Thread Pool Worker-0 (EDU.oswego.blablaWorker), both childs of the ThreadGroup ASF Session Pool Threads. === Thread-47 has the following trace: loadClass() at line 84 of org.jboss.mx.loading.HeirarchicalLoaderRepository2, this=org.jboss.mx.loading.HeirarchicalLoaderRepository2@129c ... loadClass() at line 262 of java.lang.ClassLoader, this=org.jboss.mx.loading.UnifiedClassLoader@1299 ... === Thread Pool Worker-0 has the following trace: loadClass() at line 295 of java.lang.ClassLoader, this=org.jboss.mx.loading.UnifiedClassLoader@1299 ... loadClass() at line 88 of org.jboss.mx.loading.HeirarchicalLoaderRepository2, this=org.jboss.mx.loading.HeirarchicalLoaderRepository2@129c ... === ...so the deadlock seems evident. -- Comment By: Scott M Stark (starksm) Date: 2002-10-03 13:59 Message: Logged In: YES user_id=175228 See the changes added today to address this issue. I have not been able to come up with a testcase that reproduces the original deadlock so the completion of the fix is waiting that. -- Comment By: Scott M Stark (starksm) Date: 2002-10-02 12:58 Message: Logged In: YES user_id=175228 Checkout the VM docs for your platform on how to generate a thread dump. Its Ctrl-Break on windows, Ctrl-\ or SIGQUIT on most *unix like systems for the sun based VMs. Ok, I see what you are referring to reguarding the loadClass calls to UCL@1299. The call from Thread-47 is does not have a top level call through a UnifiedClassLoader2 at any point and this will violate the use condition for the UnfiedClassLoader entering loadClass. I'll look into that. -- Comment By: Michael Bartmann (bartmann) Date: 2002-10-02 12:42 Message: Logged In: YES user_id=69300 Please forgive me. I write highly parallel code for years and don't know how to generate a VM thread dump w/o the debugger. Got to find out how. What we did instead is: we walked through the JBuilder debug thread list and saved a stacktrace of every single thread that had a loadClass anywhere in its stacktrace (as bmp, I can see you roll on the floor...). But there is one thing with your argument that I don't understand: At least in what JBuilder showed as the source of the java.lang.ClassLoader we have a lock (synchronized..) in the java.lang.ClassLoader too. So I saw two synchronized sections locking on two different ClassLoader instances, which are overcross in the two threads. Shouldn't this deadlock? -- Comment By: Scott M Stark (starksm) Date: 2002-10-02 11:37 Message: Logged In: YES user_id=175228 Can't you just provide the VM thread dump rather than having to run the server in a debugger? The thread dumps shown by the two images do not indicate to me that the threads are deadlocked. The Thread Pool Worker-0 thread is in ClassLoader.loadClass with the HeirarchicalLoaderRepository2 lock held which will stop the Thread-47 from entering the HeirarchicalLoaderRepository2, but loadClass will proceed. We need the full VM thread dump in general to look at deadlock issues. The likely problem is inconsistent locking at the HeirarchicalLoaderRepository2 level which would allow for recursive calls into a HeirarchicalLoaderRepository2 by two different threads. Another change made in the 3.2 beta release that will affect this startup issue is that the
Re: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock
This problem is not related to the thread context class loader. The heiarichical repositories were incorrectly synchronized and naked calls to the delegate class loaders generated by the VM were not synchronized with the repository. Both issues have been fixed. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Sacha Labourey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 03, 2002 9:40 AM Subject: RE: [JBoss-dev] [ jboss-Bugs-617574 ] Classloader deadlock Hello marc, That's not enough to simply add this: as the JVM will automatically create one instance of this class (no arg constructor), we would end up with a UCL that don't have an associated Repository. We will need to implement a new classloader that delegates loading correctly. Do you think that delegating to the context classloader is enough? In multi-Repository situations, does the current repository is correctly associated with each thread? (maybe that's one for Scott) Cheers, Sacha --- 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-613809 ] SECURITY: Tomcat 4.0.x Security updates
Bugs item #613809, was opened at 2002-09-24 06:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=613809group_id=22866 Category: CatalinaBundle Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Alexander Opitz (opi) Assigned to: Scott M Stark (starksm) Summary: SECURITY: Tomcat 4.0.x Security updates Initial Comment: Hi, since today there are Tomcat Security updates available. See http://jakarta.apache.org/site/news.html#0924.1 Newest stable Versions are 4.0.5 and 4.1.12 Greetings opi// -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=613809group_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] creating persistent MBeans dynamically
On 2002.10.03 16:06:36 -0400 Matt Munz wrote: Juha, sometimes design-by-email is not a fast route :) ... all of mbeaninfo should not be always stored. for instance, if I instantiate my MMB by using a definition from an URL or db then the mbeaninfo is already persisted there and should not be duplicated (only the ref to where to locate it is needed). This is to avoid the confusion to users where an mbean seems to be stored in two different locations (we already had this problem with 2.0). If on the other hand you created the mbean info at runtime then obviously you need to persist it. Perhaps I'm too simplistic, but I think that the server is either responsible for MB info persistence, or it isn't. I agree, and think it is. How about this? -- When I register my MB with the server, the server takes a peek at the MB's descriptor. If it says Persist my info, then the server takes responsibility for persisting the MB info; else, the server operates as it does now. I agree The entity that persists the MB info should be responsible for loading it at server start. If MBean info persistence customization is required, I suppose we can have an MBeanInfoPersistenceManager with store() and load() methods similar to the PersistenceManager used to store MBean state, but is this really necessary? I hope not. Either way, what is the benefit of saving part of the MBeanInfo in location A, and part of it in location B? Please explain :) I don't have the pleasure of knowing 2.0 ;), but I think I kind of know what you're talking about. Deployment of XMBeans, for example, involves two similar files with nonetheless distinct roles. I think it is necessary to either separate or merge the ideas of the deploy folder and the MB info store. I favor the former. It is easy for me to treat files in the deploy dir as deployment descriptors, and files in the MB info store as server state files. yes. Since you can deploy through the jmx console and ant jmx from an arbitrary location, and then remove the deployed files, you can't use the original deployment for anything other than, well, the original deployment. After that it is irrelevant unless you are using one of the timestamp watchers, which although somewhat convenient for some things should not drive any part of the design or functionality of mbean persistence. This perhaps could be indicated with appropriate naming conventions, comments, and documentation. If it is clear that modifications in the deploy folder will re-deploy the entire application, while the MB info store is generated and maintained by the server, I think the confusion will go away. Between the http jmx-console, JMX-GUI interfaces, the JMX API, and ANT JMX support, people have plenty of ways to modify the state of the server at runtime. Hacking the files in the store should be considered at-your-own-risk. These files will be generated by the server and loaded at startup only. The other option is to say that the deploy folder is the MB info store (this is kind of how it works today). I don't favor this -- I like to keep my peas on one side of the plate, and my mash potatoes on the other side ;) There is a way to make this work, if desired, but I believe that the route there is to delegate the responsibility for MB info persistence to an object other than the MB registry. PLEASE NO!! NO!! NO!! This was the disaster in 2.0. Perhaps you have a use case / user story in mind that I can use as a guide. For my MBs, there is no MB info storage -- adding this mechanism will give me one and only one location for that state. This is how it should be in general, I think. - Matt It seems to me that we have to store the following for each mbean: object name constructor to use constructor arguments class of the managed resource mbeaninfo values for the attributes. there may be lots of jboss specific info in the mbean info. this may be redundant, since the attribute values are known in mbean info and could be stored there. On the other hand we could take them out and store them separately. If we fixed (specified) the location of persistent storage, we could store all of this info in the mbeaninfo as one thing, and on startup load everything from the persistent store. if we want to be able to have several persistent store locations, we need one place that lists the mbeans and where to find the info for them. I think this is the idea behind Juha's suggestion that we persist the registry, getting a list of ObjectNames, constructors+args, and persistence locations. In this scheme, we could store the mbeaninfos with the object name in the registry, or with the attribute values specific to the mbean. If we do not store the attribute values in the mbeaninfos, we could share them: mbeans that are created referring to the same xml representation of their mbeaninfo could end up sharing the
[JBoss-dev] [ jboss-Bugs-612087 ] Jetty reploy problem
Bugs item #612087, was opened at 2002-09-20 05:03
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=612087group_id=22866
Category: JBossWeb
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Scott M Stark (starksm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Jetty reploy problem
Initial Comment:
Reployment of wars with updated jars are failing in the
current 3.0.3RC1 codebase with the following error:
04:54:10,037 ERROR [URLDeploymentScanner] Failed
to deploy: org.jboss.deployment
.scanner.URLDeploymentScanner$DeployedURL@9e32
a5ce{ url=file:/C:/usr/JBoss3.0/jb
oss-all/build/output/jboss-
3.0.3RC1/server/default/deploy/jbosstest-web.ear, dep
loyedLastModified=1032521971244 }
org.jboss.deployment.DeploymentException: Could not
create deployment: file:/C:/
usr/JBoss3.0/jboss-all/build/output/jboss-
3.0.3RC1/server/default/tmp/deploy/ser
ver/default/deploy/jbosstest-web.ear/65.jbosstest-
web.ear-contents/jbosstest-web
.war; - nested throwable: (java.lang.InternalError: jzentry
== 0)
at org.jboss.deployment.MainDeployer.start
(MainDeployer.java:822)
at org.jboss.deployment.MainDeployer.start
(MainDeployer.java:794)
at org.jboss.deployment.MainDeployer.deploy
(MainDeployer.java:616)
at org.jboss.deployment.MainDeployer.deploy
(MainDeployer.java:580)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invok
e(ReflectedMBea
nDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:517)
at org.jboss.util.jmx.MBeanProxy.invoke
(MBeanProxy.java:174)
at $Proxy4.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.
deploy(URLDeploymen
tScanner.java:427)
at
org.jboss.deployment.scanner.URLDeploymentScanner.
scan(URLDeploymentS
canner.java:553)
at
org.jboss.deployment.scanner.AbstractDeploymentScan
ner$ScannerThread.
doScan(AbstractDeploymentScanner.java:212)
at
org.jboss.deployment.scanner.AbstractDeploymentScan
ner$ScannerThread.
loop(AbstractDeploymentScanner.java:225)
at
org.jboss.deployment.scanner.AbstractDeploymentScan
ner$ScannerThread.
run(AbstractDeploymentScanner.java:202)
+ nested throwable:
java.lang.InternalError: jzentry == 0
at java.util.zip.ZipFile$2.nextElement
(ZipFile.java:292)
at java.util.jar.JarFile$1.nextElement
(JarFile.java:193)
at
org.apache.jasper.compiler.TldLocationsCache.tldConfig
Jar(TldLocation
sCache.java:238)
at
org.apache.jasper.compiler.TldLocationsCache.processJ
ars(TldLocations
Cache.java:211)
at
org.apache.jasper.compiler.TldLocationsCache.init
(TldLocationsCache
.java:139)
at
org.apache.jasper.EmbededServletOptions.init
(EmbededServletOptions.
java:350)
at org.apache.jasper.servlet.JspServlet.init
(JspServlet.java:265)
at org.mortbay.jetty.servlet.ServletHolder.start
(ServletHolder.java:218)
at
org.mortbay.jetty.servlet.ServletHandler.initializeServlets
(ServletHa
ndler.java:426)
at
org.mortbay.jetty.servlet.WebApplicationContext.start
(WebApplicationC
ontext.java:492)
at
org.mortbay.j2ee.J2EEWebApplicationContext.start
(J2EEWebApplicationCo
ntext.java:85)
at org.jboss.jetty.Jetty.deploy(Jetty.java:409)
at org.jboss.jetty.JettyService.performDeploy
(JettyService.java:243)
at org.jboss.web.AbstractWebContainer.start
(AbstractWebContainer.java:30
0)
at org.jboss.deployment.MainDeployer.start
(MainDeployer.java:802)
at org.jboss.deployment.MainDeployer.start
(MainDeployer.java:794)
at org.jboss.deployment.MainDeployer.deploy
(MainDeployer.java:616)
at org.jboss.deployment.MainDeployer.deploy
(MainDeployer.java:580)
at java.lang.reflect.Method.invoke(Native Method)
at
org.jboss.mx.capability.ReflectedMBeanDispatcher.invok
e(ReflectedMBea
nDispatcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke
(MBeanServerImpl.java:517)
at org.jboss.util.jmx.MBeanProxy.invoke
(MBeanProxy.java:174)
at $Proxy4.deploy(Unknown Source)
at
org.jboss.deployment.scanner.URLDeploymentScanner.
deploy(URLDeploymen
tScanner.java:427)
at
org.jboss.deployment.scanner.URLDeploymentScanner.
scan(URLDeploymentS
canner.java:553)
at
org.jboss.deployment.scanner.AbstractDeploymentScan
ner$ScannerThread.
doScan(AbstractDeploymentScanner.java:212)
at
org.jboss.deployment.scanner.AbstractDeploymentScan
ner$ScannerThread.
loop(AbstractDeploymentScanner.java:225)
at
org.jboss.deployment.scanner.AbstractDeploymentScan
ner$ScannerThread.
run(AbstractDeploymentScanner.java:202)
This is occurring on WindowsXP using jdk1.3.1_04.
Steps to reproduce:
1. Deploy the testsuite/output/lib/jbosstest-web.ear
2. Edit the
testsuite/src/main/org/jboss/test/web/util/Util.java and
add a do
RE: [JBoss-dev] creating persistent MBeans dynamically
On Thu, 3 Oct 2002, Matt Munz wrote: all of mbeaninfo should not be always stored. for instance, if I instantiate my MMB by using a definition from an URL or db then the mbeaninfo is already persisted there and should not be duplicated (only the ref to where to locate it is needed). This is to avoid the confusion to users where an mbean seems to be stored in two different locations (we already had this problem with 2.0). If on the other hand you created the mbean info at runtime then obviously you need to persist it. Perhaps I'm too simplistic, but I think that the server is either responsible for MB info persistence, or it isn't. there's no point duplicating data that doesn't change (mbeaninfo) most of it will be generated and externalized by xdoclet IMHO, nobody's going hand code it for their mbeans. so it is already stored somewhere. How about this? -- When I register my MB with the server, the server takes a peek at the MB's descriptor. If it says Persist my info, then the server takes responsibility for persisting the MB info; else, the server operates as it does now. sure. The entity that persists the MB info should be responsible for loading it at server start. yes, but an MBean loads its own state based on that metadata If MBean info persistence customization is required, I suppose we can have an MBeanInfoPersistenceManager with store() and load() methods similar to the PersistenceManager used to store MBean state, but is this really necessary? no idea, I'm not sure how you got there Either way, what is the benefit of saving part of the MBeanInfo in location A, and part of it in location B? Please explain :) no this is not what I mean at all. You have the mbean info stored once. No duplication. the number of attributes or operations the mbean has does not change during its lifetime. persistence of the metadata is different from the runtime state (the values in your attributes) I think it is necessary to either separate or merge the ideas of the deploy folder and the MB info store. I favor the former. It is easy for me to treat files in the deploy dir as deployment descriptors, and files in the MB info store as server state files. ok now you're getting JBoss deployment mixed into this as well, time to take a break. MB info store is not the state of the server (as in what values the object instances held at time T), it is the definition of it (what mbeans were registered to the server at time T, how to recreate them) and this you want to load at startup the state is separate (handled by individual mbean store() operations), and you did this already, let the individual mbeans worry about how they store and load their state like think of what the registry should store is somewhat similar to creating a db.script with CREATE and REMOVE operations of MBeans. At startup you want to read in that script to recreate the registry. You store just enough info for the MBean to be able to 'prime' itself (eg. you loaded your definition from URL A and your stored your state to URL B, here they are, you're on your own now) This perhaps could be indicated with appropriate naming conventions, comments, and documentation. If it is clear that modifications in the deploy folder will re-deploy the entire application, while the MB info store is generated and maintained by the server, I think the confusion will go away. Between the http jmx-console, JMX-GUI interfaces, the JMX API, and ANT JMX support, people have plenty of ways to modify the state of the server at runtime. Hacking the files in the store should be considered at-your-own-risk. These files will be generated by the server and loaded at startup only. erm, you're losing the control of the vehicle, matt. keep deployment out of it for now, focus on how to get the restart to work. Perhaps you have a use case / user story in mind that I can use as a guide. For my MBs, there is no MB info storage -- adding this mechanism will give me one and only one location for that state. mbeaninfo is the definition, not the state, the state is in the object instances, separate -- Juha --- 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-598809 ] Inconsistancy in template app
Bugs item #598809, was opened at 2002-08-22 07:49
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=598809group_id=22866
Category: None
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Joseph Barillari (jdbarillari)
Assigned to: Andreas Schaefer (schaefera)
Summary: Inconsistancy in template app
Initial Comment:
The JBoss template application package
(JBoss.3.0TemplateAndExamples.zip) has a case
inconsistancy in its build file which prevents it from
building.
!--
===
--
!-- Creates the war archives
--
!--
===
--
target name=war depends=compile-web
if=servlet-lib.path
mkdir dir=${build.deploy.dir}/
copy todir=${build.war.dir}/WEB-INF
!--- Here, the directory is web-inf ---
fileset dir=${src.etc.dir}/web-inf
includes=jboss-web.xml/
/copy
war
warfile=${build.deploy.dir}/web-client.war
!--- But here, it's WEB-INF --
webxml=${src.etc.dir}/WEB-INF/web-client.xml
fileset dir=${src.web.dir}/
fileset dir=${build.war.dir}/
classes dir=${build.classes.dir}
includes=test/interfaces/**/
/war
/target
Changing the second web-inf
(webxml=${src.etc.dir}/WEB-INF/web-client.xml) to
lowercase
(webxml=${src.etc.dir}/web-inf/web-client.xml)
solves the problem.
--
Comment By: Scott M Stark (starksm)
Date: 2002-10-03 14:28
Message:
Logged In: YES
user_id=175228
This was fixed in the Aug25
JBoss.3.0TemplateAndExamples.zip
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=598809group_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-all daily clean failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE == == == == Executing 'clean' in module 'iiop'... == == _buildmagic:init: configure: configure-libraries: configure-modules: configure-defaults: configure-tools: _default:init: init: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/iiop/output _default:clean: clean: == == == Finished 'clean' in module 'iiop'. == == modules-clean: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/build/output clean: BUILD SUCCESSFUL Total time: 42 seconds SHUTDOWN --- 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://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/conf [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/deploy modules-most: partition-build: [move] Moving 34 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/lib [copy] Copying 112 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/lib [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/deploy [delete] Deleting 1 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/conf [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [move] Moving 1 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-common-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-system-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-j2ee.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jnp-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-jsr77-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-transaction-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-ejb-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-connector-client-factory.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-rmi-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/concurrent.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbosssx-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmq-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmqha.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossha-client.jar into
[JBoss-dev] [ jboss-Bugs-582195 ] JBoss.3.0QuickStart.doc - link to CVS
Bugs item #582195, was opened at 2002-07-16 05:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=582195group_id=22866 Category: JBossDoc Group: v3.0 Rabbit Hole Status: Closed Resolution: Fixed Priority: 5 Submitted By: Thomas Gran (thomasgran) Assigned to: Nobody/Anonymous (nobody) Summary: JBoss.3.0QuickStart.doc - link to CVS Initial Comment: Wrong link to cvs: Error: www.cvs.org Correct: www.cvshome.org Page 19: 3. Sample Project - Skeleton of a JBoss Project -- Comment By: Scott M Stark (starksm) Date: 2002-10-03 15:00 Message: Logged In: YES user_id=175228 Fixed in CVS. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=582195group_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-all daily clean failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.0_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03) Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE == == == == Executing 'clean' in module 'iiop'... == == _buildmagic:init: configure: configure-libraries: configure-modules: configure-defaults: configure-tools: _default:init: init: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/iiop/output _default:clean: clean: == == == Finished 'clean' in module 'iiop'. == == modules-clean: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/build/output clean: BUILD SUCCESSFUL Total time: 49 seconds SHUTDOWN --- 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] creating persistent MBeans dynamically
On 2002.10.03 17:19:27 -0400 Juha-P Lindfors wrote: On Thu, 3 Oct 2002, Matt Munz wrote: all of mbeaninfo should not be always stored. for instance, if I instantiate my MMB by using a definition from an URL or db then the mbeaninfo is already persisted there and should not be duplicated (only the ref to where to locate it is needed). This is to avoid the confusion to users where an mbean seems to be stored in two different locations (we already had this problem with 2.0). If on the other hand you created the mbean info at runtime then obviously you need to persist it. Perhaps I'm too simplistic, but I think that the server is either responsible for MB info persistence, or it isn't. there's no point duplicating data that doesn't change (mbeaninfo) most of it will be generated and externalized by xdoclet IMHO, nobody's going hand code it for their mbeans. so it is already stored somewhere. The location does not have to be accessible after deployment, so the mbean persistence mechanism has to store it itself. How about this? -- When I register my MB with the server, the server takes a peek at the MB's descriptor. If it says Persist my info, then the server takes responsibility for persisting the MB info; else, the server operates as it does now. sure. The entity that persists the MB info should be responsible for loading it at server start. yes, but an MBean loads its own state based on that metadata If MBean info persistence customization is required, I suppose we can have an MBeanInfoPersistenceManager with store() and load() methods similar to the PersistenceManager used to store MBean state, but is this really necessary? no idea, I'm not sure how you got there Either way, what is the benefit of saving part of the MBeanInfo in location A, and part of it in location B? Please explain :) no this is not what I mean at all. You have the mbean info stored once. No duplication. the number of attributes or operations the mbean has does not change during its lifetime. True, but the values of attributes are stored in the mbean info objects and can be stored in the xmbean xml. You can already specify initial values for mbean attributes in the xml rather than specifying them in jboss mbean dd. In fact you can supply the xmbean xml in the *-service.xml file complete with values. I keep waffling on this, but at the moment I think it makes more sense to store the attribute values separately even though this may be more work. david jencks persistence of the metadata is different from the runtime state (the values in your attributes) I think it is necessary to either separate or merge the ideas of the deploy folder and the MB info store. I favor the former. It is easy for me to treat files in the deploy dir as deployment descriptors, and files in the MB info store as server state files. ok now you're getting JBoss deployment mixed into this as well, time to take a break. MB info store is not the state of the server (as in what values the object instances held at time T), it is the definition of it (what mbeans were registered to the server at time T, how to recreate them) and this you want to load at startup the state is separate (handled by individual mbean store() operations), and you did this already, let the individual mbeans worry about how they store and load their state like think of what the registry should store is somewhat similar to creating a db.script with CREATE and REMOVE operations of MBeans. At startup you want to read in that script to recreate the registry. You store just enough info for the MBean to be able to 'prime' itself (eg. you loaded your definition from URL A and your stored your state to URL B, here they are, you're on your own now) This perhaps could be indicated with appropriate naming conventions, comments, and documentation. If it is clear that modifications in the deploy folder will re-deploy the entire application, while the MB info store is generated and maintained by the server, I think the confusion will go away. Between the http jmx-console, JMX-GUI interfaces, the JMX API, and ANT JMX support, people have plenty of ways to modify the state of the server at runtime. Hacking the files in the store should be considered at-your-own-risk. These files will be generated by the server and loaded at startup only. erm, you're losing the control of the vehicle, matt. keep deployment out of it for now, focus on how to get the restart to work. Perhaps you have a use case / user story in mind that I can use as a guide. For my MBs, there is no MB info storage -- adding this mechanism will give me one and only one location for that state. mbeaninfo is the definition, not the state, the state is in the object instances, separate -- Juha
[JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.4.0_01 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03) Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/conf [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/deploy modules-most: partition-build: [move] Moving 34 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/lib [copy] Copying 112 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/lib [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/deploy [delete] Deleting 1 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/conf [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [move] Moving 1 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-common-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-system-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-j2ee.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jnp-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-jsr77-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-transaction-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-ejb-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-connector-client-factory.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-rmi-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/concurrent.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbosssx-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmq-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmqha.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossha-client.jar into
Re: [JBoss-dev] jboss-all daily clean failed
I think this is not happy because the last line is SHUTDOWN... I will remove that println. --jason On Thu, 3 Oct 2002 [EMAIL PROTECTED] wrote: = ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE == == == == Executing 'clean' in module 'iiop'... == == _buildmagic:init: configure: configure-libraries: configure-modules: configure-defaults: configure-tools: _default:init: init: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/iiop/output _default:clean: clean: == == == Finished 'clean' in module 'iiop'. == == modules-clean: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/build/output clean: BUILD SUCCESSFUL Total time: 46 seconds SHUTDOWN --- 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] creating persistent MBeans dynamically
On Thu, 3 Oct 2002, David Jencks wrote: The location does not have to be accessible after deployment, so the mbean persistence mechanism has to store it itself. why wouldn't it be accessible? and if my persistence mechanism is something like Dain's CMP engine, I don't expect it to store the whole mbean info object graph, only the values of individual attributes True, but the values of attributes are stored in the mbean info objects theyre cached there, this is no reason to store the whole mbean info structure if a simple getAttribute() will get me the value can be stored in the xmbean xml. You can already specify initial values for mbean attributes in the xml rather than specifying them in jboss mbean dd. In fact you can supply the xmbean xml in the *-service.xml file complete with values. oh well, I give up. too much talk already and no code. you guys do what you do, no biggie. -- Juha --- 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] Build system changes :: README
Okay, I will look into... must be an Ant CL issue. --jason On Thu, 3 Oct 2002, Langelage, Frank wrote: Hi Jason, even with a completely new checkout the build of jboss-all fails for me with Java 1.4.1-b21on Linux. Using java 1.3.1 on ReliantUnix works fine. Tagets build and clobber fail with the same Exception immediatly. Executing: /home/jboss/java/JBoss-cvs/jboss-all/tools/bin/ant -find build.xml clobber Searching for build.xml ... Buildfile: /unixware/home/jboss/java/JBoss-cvs/jboss-all/build/build.xml Trying to override old definition of task property _buildmagic:init: _buildmagic:init:global: _buildmagic:init:local-properties: _buildmagic:init:buildlog: configure: configure-libraries: configure-modules: configure-defaults: configure-tools: _configure:xdoclet:tasks: _configure:xdoclet:ejbdoclet: _configure:xdoclet:webdoclet: configure-project: [echo] groups: default [echo] modules: jmx,common,system,j2ee,naming,management,transaction,server,blocks,console,security,messaging,connector,varia,cluster,jetty,jboss.net,iiop _default:init: init: _buildmagic:clobber: [delete] Deleting: /unixware/home/jboss/java/JBoss-cvs/jboss-all/build/local.properties [delete] Deleting: /unixware/home/jboss/java/JBoss-cvs/jboss-all/build/build.log _buildmagic:modules:clean: BUILD FAILED java.lang.IllegalAccessError: tried to access field org.apache.tools.ant.ProjectComponent.project from class org.jboss.tools.buildmagic.task.module.ExecuteModules$MyEcho at org.jboss.tools.buildmagic.task.module.ExecuteModules$MyEcho.execute(ExecuteModules.java:416) at org.jboss.tools.buildmagic.task.module.ExecuteModules.printHeading(ExecuteModules.java:338) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(ExecuteModules.java:312) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteModules.java:209) at org.apache.tools.ant.Task.perform(Task.java:317) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:334) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) Total time: 6 seconds java.lang.IllegalAccessError: tried to access field org.apache.tools.ant.ProjectComponent.project from class org.jboss.tools.buildmagic.task.module.ExecuteModules$MyEcho at org.jboss.tools.buildmagic.task.module.ExecuteModules$MyEcho.execute(ExecuteModules.java:416) at org.jboss.tools.buildmagic.task.module.ExecuteModules.printHeading(ExecuteModules.java:338) at org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(ExecuteModules.java:312) at org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(ExecuteModules.java:209) at org.apache.tools.ant.Task.perform(Task.java:317) at org.apache.tools.ant.Target.execute(Target.java:309) at org.apache.tools.ant.Target.performTasks(Target.java:334) at org.apache.tools.ant.Project.executeTarget(Project.java:1306) at org.apache.tools.ant.Project.executeTargets(Project.java:1250) at org.apache.tools.ant.Main.runBuild(Main.java:610) at org.apache.tools.ant.Main.start(Main.java:196) at org.apache.tools.ant.Main.main(Main.java:235) tried to access field org.apache.tools.ant.ProjectComponent.project from class org.jboss.tools.buildmagic.task.module.ExecuteModules$MyEcho SHUTDOWN Regards Frank Jason Dillon wrote: I just finished some cleansing of the buildsystem. The build.xml files are much smaller now... as some of the complexity has moved to include files. I will be working on simplification of those include files a little later, as well as trying to increase the performance of the build. In case you missed the CVS changelog for my recent changes; this is what I did (as far as I can remember that is): o Updated all .cvsingore files o Updated build.sh and build.bat to not need any special properties o Cleaned up buildfragments, now only buildmagic, defaults, tools, targets modules (can still clean these up lots more) o Removed ~250 lines from each build.xml (common bits are references from the specific buildframement) o Removed the _available_* targets, path specs which do not use filesets do not complain when their files or directories are missing o 'jars' target has become 'output' o 'install' target has gone away o All common targets have been moved to targets.ent, targets which build files might want to override are prefixed with _default: o Fixed 'clean most' problems o Can now execute build (from build.sh
[JBoss-dev] [ jboss-Bugs-614116 ] Oracle XA pooling/repeated rollback
Bugs item #614116, was opened at 2002-09-24 19:56
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=376685aid=614116group_id=22866
Category: JBossTX
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Elias Ross (genman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Oracle XA pooling/repeated rollback
Initial Comment:
I've been trying to isolate some problems I've been
having with transaction roll-backs and message-driven
beans. Basically, when a transaction is rolled-back
a number of times in the onMessage() body
(by calling MessageDrivenContext.setRollbackOnly()
5-10 times in succession),
the message is re-delivered to the MDB, but the Oracle
Connection is no longer in a good state.
This problem manifests itself when using a very small
connection pool (say 1-5) connections.
Example code snippet:
public void onMessage(javax.jms.Message jmsMessage)
{
Connection c = null;
try {
TextMessage tm = (TextMessage)jmsMessage;
String text = tm.getText();
c = ds.getConnection();
PreparedStatement s = c.prepareStatement(insert into test values (?));
s.setString(1, text);
s.executeUpdate();
mdc.setRollbackOnly();
} catch (Exception e) {
throw new EJBException(e);
} finally {
if (c != null) {
try { c.close(); }
catch (Exception e) {
e.printStackTrace();
}
}
First I see it works for a few times. It rolls-back successfully
about 5 or 6 times. Then, for no reason, I see:
15:50:44,922 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//4,
BranchQual=] errorCode=XAER_RMERR
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.allowGlobalTxnModeOnly(OracleXAResource.java:1069)
at oracle.jdbc.xa.OracleXAResource.suspendStacked(OracleXAResource.java:296)
at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:381)
at org.jboss.tm.TxCapsule.endResource(TxCapsule.java:1237)
at org.jboss.tm.TxCapsule.delistResource(TxCapsule.java:579)
at org.jboss.tm.TransactionImpl.delistResource(TransactionImpl.java:92)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.delist(XATxConnectionManager.java:284)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.connectionClosed(XATxConnectionManager.java:331)
at
org.jboss.resource.adapter.jdbc.BaseManagedConnection.fireConnectionEvent(BaseManagedConnection.java:152)
at
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.fireConnectionEvent(XAManagedConnection.java:215)
at
org.jboss.resource.adapter.jdbc.xa.XAManagedConnection$1.connectionClosed(XAManagedConnection.java:127)
at
oracle.jdbc.pool.OraclePooledConnection.callListener(OraclePooledConnection.java:482)
at
oracle.jdbc.pool.OraclePooledConnection.logicalClose(OraclePooledConnection.java:445)
at oracle.jdbc.driver.OracleConnection.logicalClose(OracleConnection.java:2900)
at oracle.jdbc.driver.OracleConnection.close(OracleConnection.java:1418)
at com.proteusmobile.smx.AMDB.onMessage(AMDB.java:140)
Later:
15:50:44,929 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//4,
BranchQual=] errorCode=XAER_RMERR
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.allowGlobalTxnModeOnly(OracleXAResource.java:1069)
at oracle.jdbc.xa.OracleXAResource.suspendStacked(OracleXAResource.java:296)
at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:381)
at org.jboss.tm.TxCapsule.endResource(TxCapsule.java:1237)
at org.jboss.tm.TxCapsule.endResources(TxCapsule.java:1312)
at org.jboss.tm.TxCapsule.rollback(TxCapsule.java:440)
at org.jboss.tm.TransactionImpl.rollback(TransactionImpl.java:83)
at org.jboss.jms.asf.StdServerSession.onMessage(StdServerSession.java:301)
at
org.jboss.mq.SpyMessageConsumer.sessionConsumerProcessMessage(SpyMessageConsumer.java:603)
at org.jboss.mq.SpyMessageConsumer.addMessage(SpyMessageConsumer.java:417)
at org.jboss.mq.SpySession.run(SpySession.java:259)
at org.jboss.jms.asf.StdServerSession.run(StdServerSession.java:177)
at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(PooledExecutor.java:655)
at java.lang.Thread.run(Thread.java:479)
And then, I can no longer get a connection:
15:50:44,971 WARN [TxCapsule] XAException: tx=XidImpl [FormatId=257,
GlobalId=eross.m-qube.com//5,
BranchQual=] errorCode=XAER_PROTO
javax.transaction.xa.XAException
at oracle.jdbc.xa.OracleXAResource.disallowLocalTxnMode(OracleXAResource.java:1045)
at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:153)
at org.jboss.tm.TxCapsule.startResource(TxCapsule.java:1180)
at org.jboss.tm.TxCapsule.enlistResource(TxCapsule.java:679)
at org.jboss.tm.TransactionImpl.enlistResource(TransactionImpl.java:102)
at
org.jboss.resource.connectionmanager.XATxConnectionManager$XAConnectionEventListener.enlist(XATxConnectionManager.java:262)
at
[JBoss-dev] jboss-all daily clean failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE == == == == Executing 'clean' in module 'iiop'... == == _buildmagic:init: configure: configure-libraries: configure-modules: configure-defaults: configure-tools: _default:init: init: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/iiop/output _default:clean: clean: == == == Finished 'clean' in module 'iiop'. == == modules-clean: _buildmagic:clean: [delete] Deleting directory /disk/orig/home/lubega/jbossro/jboss-all/build/output clean: BUILD SUCCESSFUL Total time: 42 seconds SHUTDOWN --- 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://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/conf [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/deploy modules-most: partition-build: [move] Moving 34 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/all/lib [copy] Copying 112 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/lib [delete] Deleting 4 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/deploy [delete] Deleting 1 files from /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/default/conf [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [move] Moving 1 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/conf [copy] Copying 3 files to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/deploy [copy] Copying 1 file to /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/server/minimal/lib [mkdir] Created dir: /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-common-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-system-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-j2ee.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jnp-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-jsr77-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-transaction-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jboss-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-ejb-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-connector-client-factory.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jmx-rmi-connector-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/concurrent.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbosssx-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmq-client.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossmqha.jar into /disk/orig/home/lubega/jbossro/jboss-all/build/build [unjar] Expanding: /disk/orig/home/lubega/jbossro/jboss-all/build/output/testbuild/client/jbossha-client.jar into
[JBoss-dev] jboss daily test failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = JAVA VERSION DETAILS java version 1.3.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Server VM (build 1.3.1_03-b03, mixed mode) = HERE ARE THE LAST 50 LINES OF THE LOG FILE Executing: /home/lubega/jbossro/jboss-all/tools/bin/ant -find build.xml testsuite Searching for build.xml ... Buildfile: /disk/orig/home/lubega/jbossro/jboss-all/build/build.xml Trying to override old definition of task property _buildmagic:init: _buildmagic:init:global: _buildmagic:init:local-properties: _buildmagic:init:buildlog: configure: configure-libraries: configure-modules: configure-defaults: configure-tools: _configure:xdoclet:tasks: _configure:xdoclet:ejbdoclet: _configure:xdoclet:webdoclet: configure-project: [echo] groups: default [echo] modules: jmx,common,system,j2ee,naming,management,transaction,server,blocks,console,security,messaging,connector,varia,cluster,jetty,jboss.net,iiop _default:init: init: run-testsuite: [execmodules] Missing build file; skipping module: testsuite testsuite: BUILD SUCCESSFUL Total time: 6 seconds SHUTDOWN --- 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] Build System... any ideas
The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find ANT XML to be a bit limiting, and I don't see the comparative advantage of a scripting language (over java) in this case. If you're writing your app in java, and your build system engine uses java, why not write the build system in java too? Every function in ANT can be called programmatically from java. Doing so allows one to avoid the expressive limitations of XML. I know that this is an atypical approach, and I'm not suggesting you use it -- I just want to point out that there are alternatives to adding another language to the build system. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, September 19, 2002 1:29 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas I think we should develop a new custom task to initialize the properties and classpaths for the thirdparty packages. I wrote a hack to check that directories are available before calling the task that declares the classpath. We could write a task that takes the dir name properties to set and paths to create, or we could load an xml file from the thirdparty directory that had the above. I think either would be easier to understand. Another possibility would be to make use of the script task. I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use of some of the other Ant based tools out there... though I think that no matter what we will have to write some custom bits to make it work as we want and need. Other then that I think we should use the parallel task in the testsuite to speed up the xdoclet and jar tasks. I'm not sure if it would really speed it up but doing a one-test takes forever because of the xdoclet tasks. Also the default test suite takes so long that no one runs it anymore and most have created smaller sub suites, but I don't think that is a build system problem. David and I talked about this on the way back from Tahoe. I would like to revisit the entire TestSuite, putting a testsuite in each module, which would perform Unit tests for components and parts of components for that module alone. Then the jboss/testsuite would be an integration testsuite. This way, if you are working on bits from the cluster module, you can write simple tests to validate your component and run the tests quickly. Then when you are satisfied, you can write an integration test, which would actual test a real component inside of a JBoss instance. This will get us more coverage, but will also encourage developers to make smaller, simpler tests for stuff and make it more likely they will run them, as it won't take forever. Also, on the subject of build systems and testsuites, I have been toying with the idea of allow Java and Jython tests to be run together. Using Jython it will be faster to throw together small and functional tests with much less code and a lot less trouble. We would still need Java tests to run stuff that is type dependant, but the two could live together happy. The build system overhaul is a dependency of this I believe. I have been planning on doing all of the above... just I haven't had the time to make any progress. Also I really want to finish the basic command line console framework. Fuck, I need my boss to stop making me work on their lame ass projects. Who cares about that shit really... bah! --jason -dain Jason Dillon wrote: Can I get anyone who knows anything about Ant based build systems (extensions, helpers, whatever) to send me some feedback on both positive and negative experiences they have had. It is becoming very apparent that we need to
RE: [JBoss-dev] Build System... any ideas
As I was struggling today with the classpath for tapestry compilation and messing around with ant files and (gasp!) build magic files, I found myself thinking that Build on JBoss could possibly be a project. JUST THE CLASSLOADERS with the complete visibility thingy would be pretty interesting. We could run a ANT-like MBean and blah blah blah. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find ANT XML to be a bit limiting, and I don't see the comparative advantage of a scripting language (over java) in this case. If you're writing your app in java, and your build system engine uses java, why not write the build system in java too? Every function in ANT can be called programmatically from java. Doing so allows one to avoid the expressive limitations of XML. I know that this is an atypical approach, and I'm not suggesting you use it -- I just want to point out that there are alternatives to adding another language to the build system. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, September 19, 2002 1:29 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas I think we should develop a new custom task to initialize the properties and classpaths for the thirdparty packages. I wrote a hack to check that directories are available before calling the task that declares the classpath. We could write a task that takes the dir name properties to set and paths to create, or we could load an xml file from the thirdparty directory that had the above. I think either would be easier to understand. Another possibility would be to make use of the script task. I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use of some of the other Ant based tools out there... though I think that no matter what we will have to write some custom bits to make it work as we want and need. Other then that I think we should use the parallel task in the testsuite to speed up the xdoclet and jar tasks. I'm not sure if it would really speed it up but doing a one-test takes forever because of the xdoclet tasks. Also the default test suite takes so long that no one runs it anymore and most have created smaller sub suites, but I don't think that is a build system problem. David and I talked about this on the way back from Tahoe. I would like to revisit the entire TestSuite, putting a testsuite in each module, which would perform Unit tests for components and parts of components for that module alone. Then the jboss/testsuite would be an integration testsuite. This way, if you are working on bits from the cluster module, you can write simple tests to validate your component and run the tests quickly. Then when you are satisfied, you can write an integration test, which would actual test a real component inside of a JBoss instance. This will get us more coverage, but will also encourage developers to make smaller, simpler tests for stuff and make it more likely they will run them, as it won't take forever. Also, on the subject of build systems and testsuites, I have been toying with the idea of allow Java and Jython tests to be run together. Using Jython it will be faster to throw together small and functional tests with much less code and a
Re: [JBoss-dev] Build System... any ideas
FWIW I think ant could be better replaced by a bunch of mbeans running in an mbean server. Basically task == mbean and target also == mbean. This would solve about 90% of their problems (especially their incompetent classloaders) with no work. However none of the ant committers seem interested. david jencks On 2002.10.03 21:34:24 -0400 marc fleury wrote: As I was struggling today with the classpath for tapestry compilation and messing around with ant files and (gasp!) build magic files, I found myself thinking that Build on JBoss could possibly be a project. JUST THE CLASSLOADERS with the complete visibility thingy would be pretty interesting. We could run a ANT-like MBean and blah blah blah. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find ANT XML to be a bit limiting, and I don't see the comparative advantage of a scripting language (over java) in this case. If you're writing your app in java, and your build system engine uses java, why not write the build system in java too? Every function in ANT can be called programmatically from java. Doing so allows one to avoid the expressive limitations of XML. I know that this is an atypical approach, and I'm not suggesting you use it -- I just want to point out that there are alternatives to adding another language to the build system. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, September 19, 2002 1:29 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas I think we should develop a new custom task to initialize the properties and classpaths for the thirdparty packages. I wrote a hack to check that directories are available before calling the task that declares the classpath. We could write a task that takes the dir name properties to set and paths to create, or we could load an xml file from the thirdparty directory that had the above. I think either would be easier to understand. Another possibility would be to make use of the script task. I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use of some of the other Ant based tools out there... though I think that no matter what we will have to write some custom bits to make it work as we want and need. Other then that I think we should use the parallel task in the testsuite to speed up the xdoclet and jar tasks. I'm not sure if it would really speed it up but doing a one-test takes forever because of the xdoclet tasks. Also the default test suite takes so long that no one runs it anymore and most have created smaller sub suites, but I don't think that is a build system problem. David and I talked about this on the way back from Tahoe. I would like to revisit the entire TestSuite, putting a testsuite in each module, which would perform Unit tests for components and parts of components for that module alone. Then the jboss/testsuite would be an integration testsuite. This way, if you are working on bits from the cluster module, you can write simple tests to validate your component and run the tests quickly. Then when you are satisfied, you can write an integration test, which would actual test a
Re: [JBoss-dev] JbossTX vs. Tyrex
David Jencks wrote:
On 2002.09.27 16:21:33 -0400 Igor Fedorenko wrote:
David Jencks wrote:
Hi Igor,
I'd like to stick with the jboss tm and add the needed functionality.
Can you outline what you have been thinking of?
I want to allow resource manager specific variation of XAResource state
change sequence. This way we'll decouple different RMs from each other
and developers will be able to concentrate on one RM without concerns to
break others. I have very brief idea how this can be implemented, but I
believe it is doable and not too complicated.
I'd like to see what you have in mind.
I'm thinking about creating xa resource handlers responsible for making
calls on xa resources. TransactionImpl will keep track of all xa
resources involved into the transaction but will delegate real xa work
to the appropriate handler. These handlers will implement interface
something like:
interface XAResourceHandler {
void commit(TransactionImpl tx) throws ...;
boolean delistResource(TransactionImpl tx, int flag) throws ...;
boolean enlistResource(TransactionImpl tx) throws ...;
void rollback(TransactionImpl tx) throws ...;
}
We will provide DefaultXAResourceHandler which will work with ideal xa
resource implementations but will allow registration of rm specific
implementations which will support whatever crazy logic in necessary to
work with the rm.
Obviously I do not know all implementation details yet but I am pretty
sure that it will not complicate our code much. Unfortunately I do not
know when I'll be able to implement it.
Also, is the new xa wrapper in cvs HEAD working well enough to move to
3.2?
Should we even move it to 3.0?
What do you think about cached javax.jdbc.XAConnection.getConnection()
problem I've mentioned few days ago? Can we afford saying Oracle 8i is
not supported in XA mode?
I don't know... saying it isn't supported might be better than all the
problems people are having.
Do you think it is ok to get a new Connection from the XAConnection
whenever associateConnection is called? If we can do this, it wouldn't be
too hard to change. I'm still mystified as to how Oracle can tell how many
Connection handles we are using and how it can decide to object.
Well, most likely I misinterpreted the behaviour I've observed ;-) I
believe oracle 8i should work fine with TrackConnectionByTx.
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.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] Build System... any ideas
This is done, though only Ant 1.5 aware tools will function at the moment. If there are other version that need to be compatible (if they can be) let me know. --jason On Thu, 19 Sep 2002, Scott M Stark wrote: Anymove that restores that ability to run our build in Ant aware tools is a good thing. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 18, 2002 10:29 PM Subject: RE: [JBoss-dev] Build System... any ideas I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use of some of the other Ant based tools out there... though I think that no matter what we will have to write some custom bits to make it work as we want and need. --- 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] Build System... any ideas
I can not find the include task in the 1.5 branch of Ant. I see some proposal/embed stuff in HEAD... but I can not get it to compile. --jason On Thu, 19 Sep 2002, David Jencks wrote: On 2002.09.19 19:32:25 -0400 Scott M Stark wrote: I still don't buy it. Many of the existing tests involve several functional modules so how do I associate the test with its module? I see your point, many of the jmx tests that test system module functionality rely on ejbs, etc etc, to provide a sufficient environment. The compilation issue is a simple by product of having a huge monolithic build file, and further complicated by xdoclet having to be run as a first pass to generate the code. I better not wake up one morning and have the testsuite laying in pieces in CVS without a clear consensus on this approach. So are you suggesting that there be, more or less, a build file per testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then the testsuite/build.xml calls each of them? I think that would accomplish essentially the same thing I was suggesting with the generic targets for run xdoclet in one directory and build jars from one directory suggestion. Smaller build files might be easier to understand individually, but might also be significantly slower. The ant 1.5.1 include task might help, we could include the specific xdoclet and jar targets from small build files while keeping a single global javac task. david jencks Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 4:15 PM Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 18:05:46 -0400 Scott M Stark wrote: Add -Dnojars=true during the run of the single test and zero compilation time is the result. Umm, yes, I know about nojars, I wrote it. It doesn't help much if you changed the test and need to recompile, the situation I find time consuming. Add -Djbosstest.nodeploy=true and you can also avoid having to deploy the tests into the server. Doesn't this require you to copy the appropriate test jar into the deploy directory? Are there any deployments that take a significant amount of time? I routinely run single tests in 10 seconds with these options. Refactoring the entire testsuite for a simple usage problems is silly. Having to spend 7 minutes to try a simple change to a test is a lot sillier. Breaking up the huge monolithic build file into seperates test files would be a good thing. This is what we had in 2.4 and it was nice when we had 200 tests. Now as we approach 1000 its time to revisit this as well. Agreed, this is a better solution, but also more work. I think the test/module in the modules is the way to go here. 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 --- 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] Give me your build system complaints or desires...
I would really like the build.xml files to be consistently indented. It is also really annoying for them to have 2 spaces instead of 3 like the rest of jboss (I have to tab by hand now or reset my vim environment). Feel free... tis a pain to keep these consistent. Perhaps you can write a generic indent tool for xml? Or perhaps there is one already. Also, I think we should make ant complain if invoked without the build script. As Scott said, it would be really helpful to be able to run the builds from ant aware tools. Done. ;) --jason --- 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] Build System... any ideas
I have some ideas on using xslt, but I am not sure what the performance impact would be. I would need your help to write the stylesheets though... --jason On Thu, 19 Sep 2002, David Jencks wrote: There seems to be an import and an include and I'm not completely sure what the difference is or where the include task is. The import might get into ant 1.6 and is already part of centipede. Here's the code for import: http://cvs.apache.org/viewcvs.cgi/jakarta-ant/proposal/embed/#dirlist Most of the build gurus on the ant list seem to like the idea of generating build files using xslt or velocity and then running them with plain ant rather than using things like foreach. I haven't seen an example of this yet. david jencks On 2002.09.19 20:43:43 -0400 Jason Dillon wrote: Where is the include task documented... I didn't find it on their website. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 5:27 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 19:32:25 -0400 Scott M Stark wrote: I still don't buy it. Many of the existing tests involve several functional modules so how do I associate the test with its module? I see your point, many of the jmx tests that test system module functionality rely on ejbs, etc etc, to provide a sufficient environment. The compilation issue is a simple by product of having a huge monolithic build file, and further complicated by xdoclet having to be run as a first pass to generate the code. I better not wake up one morning and have the testsuite laying in pieces in CVS without a clear consensus on this approach. So are you suggesting that there be, more or less, a build file per testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then the testsuite/build.xml calls each of them? I think that would accomplish essentially the same thing I was suggesting with the generic targets for run xdoclet in one directory and build jars from one directory suggestion. Smaller build files might be easier to understand individually, but might also be significantly slower. The ant 1.5.1 include task might help, we could include the specific xdoclet and jar targets from small build files while keeping a single global javac task. david jencks Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 4:15 PM Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 18:05:46 -0400 Scott M Stark wrote: Add -Dnojars=true during the run of the single test and zero compilation time is the result. Umm, yes, I know about nojars, I wrote it. It doesn't help much if you changed the test and need to recompile, the situation I find time consuming. Add -Djbosstest.nodeploy=true and you can also avoid having to deploy the tests into the server. Doesn't this require you to copy the appropriate test jar into the deploy directory? Are there any deployments that take a significant amount of time? I routinely run single tests in 10 seconds with these options. Refactoring the entire testsuite for a simple usage problems is silly. Having to spend 7 minutes to try a simple change to a test is a lot sillier. Breaking up the huge monolithic build file into seperates test files would be a good thing. This is what we had in 2.4 and it was nice when we had 200 tests. Now as we approach 1000 its time to revisit this as well. Agreed, this is a better solution, but also more work. I think the test/module in the modules is the way to go here. 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 --- This sf.net
Re: [JBoss-dev] Build System... any ideas
Right, we can publish all of the build documentation. --jason On Fri, 20 Sep 2002, David Jencks wrote: I agree. Having them posted might encourage people to make them more accurate and comprehensive. The xdoclet-generated todo list would be good also. This is now generated by the all build. Along with the javadocs I'd like to suggest we work a little more on the jmx-api docs I started on that basically provide a user manual for mbeans from xdoclet markup in the source. The info provided is basically the same you get on jmx-console with an xmbean (currently XidFactory and TransactionManagerService), but I think it's good to have it as static html also. I sort of enabled this everywhere by including the targets in documentation.ent, however due to parsing problems with xdoclet on excaped unicode characters it is currently disabled everywhere. I hope to have a solution soon. So, this isn't so much a build system request as a suggestion that we add additional documentation to all our mbeans (and convert them all to xmbeans). xdocletgui makes this pretty simple, it shows you what tags are available and lets you add them and fill in the values. david jencks On 2002.09.20 11:59:09 -0400 Dain Sundstrom wrote: I think it would be cool (which means it is not a formal request) to be able to have some tasks that can build the javadocs and push them to our webserver (of course you would have to authenticate by hand). It would be nice if this were simple, so we can have (trusted) others post results to our site. Actually, it would be better to have the automatic build scripts that Chris runs to be integrated into the build system with server push. What I mean is every night we pull down the new code, build, run the tests, generate the java docs, and post the source, binary (if built), the test results, and the java docs to the JBoss website. This would be similar to the Jakarta nightly builds. No matter what we do I think we should have the JBoss javadocs posted on our site or available for download. Maybe it is already there and I can't find it. What do you think? -dain Jason Dillon wrote: Can I get anyone who knows anything about Ant based build systems (extensions, helpers, whatever) to send me some feedback on both positive and negative experiences they have had. It is becoming very apparent that we need to overhaul the build system to meet the current and future needs. I would appreciate any input you have. --jason --- 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] Build System... any ideas
Sounds like a good idea. I will set this up when I get to fixing the snapshots. --jason On Fri, 20 Sep 2002, Dain Sundstrom wrote: I think it would be cool (which means it is not a formal request) to be able to have some tasks that can build the javadocs and push them to our webserver (of course you would have to authenticate by hand). It would be nice if this were simple, so we can have (trusted) others post results to our site. Actually, it would be better to have the automatic build scripts that Chris runs to be integrated into the build system with server push. What I mean is every night we pull down the new code, build, run the tests, generate the java docs, and post the source, binary (if built), the test results, and the java docs to the JBoss website. This would be similar to the Jakarta nightly builds. No matter what we do I think we should have the JBoss javadocs posted on our site or available for download. Maybe it is already there and I can't find it. What do you think? -dain Jason Dillon wrote: Can I get anyone who knows anything about Ant based build systems (extensions, helpers, whatever) to send me some feedback on both positive and negative experiences they have had. It is becoming very apparent that we need to overhaul the build system to meet the current and future needs. I would appreciate any input you have. --jason --- 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] Give me your build system complaints or desires...
This is done. Look in tools/etc/buildfragments for all of the included bits. --jason On Fri, 20 Sep 2002, Scott M Stark wrote: The one item I have run into now and then are not being able to see the default property settings that drive the build because they are stuck in a buildmagic jar someplace. All the properties and their defaults should be readily available as a file included into the build so that problems are easy to troubleshoot, and there is a quick reference for the properties that affect the build. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Jason Dillon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 4:15 PM Subject: [JBoss-dev] Give me your build system complaints or desires... I would like to collect a list of all of the current complaints about the current build system and any desired features, so I can begin to evaluate the options. Please, I don't care how harsh the complaint or how ridiculous the desire... TELL ME... PLEASE. --jason --- 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] Build System... any ideas
I agree... but the trick is to accomplish this and still keep the build files simple, small. I am thinking about how to do this. --jason On Fri, 20 Sep 2002, Scott M Stark wrote: Less mysteriousness, as in: !-- | Initialize the build system. Must depend on '_buildmagic:init'. | Other targets should depend on 'init' or things will mysteriously fail. -- target name=init unless=init.disable depends=_buildmagic:init /target I would like standard Ant + JBoss custom Ant tasks + scripting? all manifest in the build.xml files rather than hidden in corners of the build system. 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 --- 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] Build System... any ideas
If I send you an example .xml file can you send me a basic skeleton stylesheet with examples on how to replave tags and access emements? --jason On Fri, 20 Sep 2002, David Jencks wrote: I've seen similar explanations on the ant list sometimes, but they all go way over my head. Is there any chance of showing us one of these projects build system to look at in detail? thanks david jencks On 2002.09.20 15:49:51 -0400 James Higginbotham wrote: Not sure what you may want to do with XSL, but we use it for our product's build system and I use it for a personal project as well. Its quite powerful, since you have define a modules.xml that has all the dependencies and let XSL generate the right build targets. It would offer primary targets for the caller to invoke and would delegate to the generated script. The main build.xml would determine if the generated xml is out of date or missing and XSLT the modules.xml or whatever into the resulting ant script before invoking the delegated call. I haven't dove into your buildmagic too much, but a commontargets that is shared by all modules lets you share common targets, while the XSL could be done to drive each modules' build script or a master build script. I'm sure you guys have a complex build env, but thought I'd throw this out for you and others that may want to know how we are using XSL + Ant. HTH, James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 2:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas Can you find any more info about using xslt or velocity as a preprocessor to the build files? I think this might be a good idea, but just as you say I can not find any examples of it to study. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 6:43 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas There seems to be an import and an include and I'm not completely sure what the difference is or where the include task is. The import might get into ant 1.6 and is already part of centipede. Here's the code for import: http://cvs.apache.org/viewcvs.cgi/jakarta-ant/proposal/embed/#dirlist Most of the build gurus on the ant list seem to like the idea of generating build files using xslt or velocity and then running them with plain ant rather than using things like foreach. I haven't seen an example of this yet. david jencks On 2002.09.19 20:43:43 -0400 Jason Dillon wrote: Where is the include task documented... I didn't find it on their website. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 5:27 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 19:32:25 -0400 Scott M Stark wrote: I still don't buy it. Many of the existing tests involve several functional modules so how do I associate the test with its module? I see your point, many of the jmx tests that test system module functionality rely on ejbs, etc etc, to provide a sufficient environment. The compilation issue is a simple by product of having a huge monolithic build file, and further complicated by xdoclet having to be run as a first pass to generate the code. I better not wake up one morning and have the testsuite laying in pieces in CVS without a clear consensus on this approach. So are you suggesting that there be, more or less, a build file per testsuite directory (e.g. org/jboss/test/jmx gets a build.xml)? Then the testsuite/build.xml calls each of them? I think that would accomplish essentially the same thing I was suggesting with the generic targets for run xdoclet in one directory and build jars from one directory suggestion. Smaller build files might be easier to understand individually, but might also be significantly slower. The ant 1.5.1 include task might help, we could include the specific xdoclet and jar targets from small build files while keeping a single global javac task. david jencks Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: [EMAIL
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 3-October-2002
Number of tests run: 934
Successful tests: 930
Errors:4
Failures: 0
[time of test: 3 October 2002 12:59 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.1]
See http://lubega.com/testarchive/${build.uid} for details of this test.
See http://lubega.com for general test information.
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.
Remember - if a test becomes broken after your changes - fix it or fix the test!
Oh dear - still got some errors!
Thanks for all your effort - we really do love you!
---
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] Build System... any ideas
Sorry for the delay...
Probably the biggest annoyance I have with using a sub-module is that
the ${project.root} property within the sub-module ends up including the
module above it instead of being the actual project root, so I have to
define my own local ${project.root.local} property in each sub-module.
To illustrate:
from a first level module:
${project.root}=/home/ssayles/src/myProject
from within a sub-module:
${project.root}=/home/ssayles/src/myProject/myModule
Is it possible to get this value to remain the real project root?
Perhaps I'm missing something?
Sub-modules are not supported at the moment. Currently all modules must be
direct peers. I might find a way around this in the future.
Also, one of my thoughts is that we should raise developer awareness
about the associated tests for a module. In other words, if they change
something in the code which breaks the tests for that module, this
should be readily apparent. Of course, this will happen when you
This is planned.
2. Force the integration of the module build with the associated
testsuite. In other words, have build targets within the module call
correlating targets in the testsuite sub-module. This does not seem to
fit within the buildmagic way of doing things (to me), but it could
work.
Perhaps... will have to see. Would probably be better to leave them
seperate but require developers to run the modele tests. I know what you
mean though... problems is that by doing so, making small changes and
recompiling would take too long.
Or I could short-circuit with unless properties.
Anyways... we'll see.
--jason
---
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] Build System... any ideas
The ant committers are all insane. --jason On Thu, 3 Oct 2002, David Jencks wrote: FWIW I think ant could be better replaced by a bunch of mbeans running in an mbean server. Basically task == mbean and target also == mbean. This would solve about 90% of their problems (especially their incompetent classloaders) with no work. However none of the ant committers seem interested. david jencks On 2002.10.03 21:34:24 -0400 marc fleury wrote: As I was struggling today with the classpath for tapestry compilation and messing around with ant files and (gasp!) build magic files, I found myself thinking that Build on JBoss could possibly be a project. JUST THE CLASSLOADERS with the complete visibility thingy would be pretty interesting. We could run a ANT-like MBean and blah blah blah. marc f -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Dillon Sent: Thursday, October 03, 2002 9:18 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas The problem with writing build components in Java is that the maintenece process is slow and difficult, and only a select few can currently perform this. Perhaps if the build components were made into a included module this would different... I am undescided as of yet to which is better/easier/simpiler/faster. --jason On Thu, 19 Sep 2002, Matt Munz wrote: Jason, I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. FYI, an alternative to using javascript (or another scripting language) in your XML to provide complex ant-based algorithms is to write part or all of the build system in java. I have done this before and it works quite well. FWIW, I find ANT XML to be a bit limiting, and I don't see the comparative advantage of a scripting language (over java) in this case. If you're writing your app in java, and your build system engine uses java, why not write the build system in java too? Every function in ANT can be called programmatically from java. Doing so allows one to avoid the expressive limitations of XML. I know that this is an atypical approach, and I'm not suggesting you use it -- I just want to point out that there are alternatives to adding another language to the build system. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Thursday, September 19, 2002 1:29 AM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas I think we should develop a new custom task to initialize the properties and classpaths for the thirdparty packages. I wrote a hack to check that directories are available before calling the task that declares the classpath. We could write a task that takes the dir name properties to set and paths to create, or we could load an xml file from the thirdparty directory that had the above. I think either would be easier to understand. Another possibility would be to make use of the script task. I had looked into this, making a custom task, but dropped it... why... I can't remember. I think that making use of the script task would be a good idea. I have been thinking about using script todo most of the complicated stuff, deal with the includes and make the module integration stuff work better. This would leave Ant todo what it is good at... building a simple module. I think this is the way to go, but have not really decided a concrete direction for it yet. I also think that we could probably make use of some of the other Ant based tools out there... though I think that no matter what we will have to write some custom bits to make it work as we want and need. Other then that I think we should use the parallel task in the testsuite to speed up the xdoclet and jar tasks. I'm not sure if it would really speed it up but doing a one-test takes forever because of the xdoclet tasks. Also the default test suite takes so long that no one runs it anymore and most have created smaller sub suites, but I don't think that is a build system problem. David and I talked about this on the way back from Tahoe. I would like to revisit the entire TestSuite, putting a testsuite in each module, which would perform Unit tests for components and parts of components for that module alone. Then the jboss/testsuite would be an integration testsuite. This way, if you are working
Re: [JBoss-dev] JbossTX vs. Tyrex
On 2002.10.03 22:12:42 -0400 Igor Fedorenko wrote:
David Jencks wrote:
On 2002.09.27 16:21:33 -0400 Igor Fedorenko wrote:
David Jencks wrote:
Hi Igor,
I'd like to stick with the jboss tm and add the needed functionality.
Can you outline what you have been thinking of?
I want to allow resource manager specific variation of XAResource state
change sequence. This way we'll decouple different RMs from each other
and developers will be able to concentrate on one RM without concerns
to
break others. I have very brief idea how this can be implemented, but I
believe it is doable and not too complicated.
I'd like to see what you have in mind.
I'm thinking about creating xa resource handlers responsible for making
calls on xa resources. TransactionImpl will keep track of all xa
resources involved into the transaction but will delegate real xa work
to the appropriate handler. These handlers will implement interface
something like:
interface XAResourceHandler {
void commit(TransactionImpl tx) throws ...;
boolean delistResource(TransactionImpl tx, int flag) throws ...;
boolean enlistResource(TransactionImpl tx) throws ...;
void rollback(TransactionImpl tx) throws ...;
}
We will provide DefaultXAResourceHandler which will work with ideal xa
resource implementations but will allow registration of rm specific
implementations which will support whatever crazy logic in necessary to
work with the rm.
Obviously I do not know all implementation details yet but I am pretty
sure that it will not complicate our code much. Unfortunately I do not
know when I'll be able to implement it.
This looks like it would work, but I don't see why this would be better
than implementing specific XAResource wrappers for the bizarre XAResource
implementations. I'm thinking
txImpl calls say XAWrapper.start(xid, TMRESUME)
and XAWrapper says, hmmm I don't support resume, I'll get a new branch on
this tx and call BizarroXAResource.start(newXid, TMJOIN).
I think with either approach their may be problems keeping track of all the
modifications. Anyway I wonder if you have thought of this and know of
problems with it.
thanks
david jencks
Also, is the new xa wrapper in cvs HEAD working well enough to move to
3.2?
Should we even move it to 3.0?
What do you think about cached javax.jdbc.XAConnection.getConnection()
problem I've mentioned few days ago? Can we afford saying Oracle 8i is
not supported in XA mode?
I don't know... saying it isn't supported might be better than all the
problems people are having.
Do you think it is ok to get a new Connection from the XAConnection
whenever associateConnection is called? If we can do this, it wouldn't
be
too hard to change. I'm still mystified as to how Oracle can tell how
many
Connection handles we are using and how it can decide to object.
Well, most likely I misinterpreted the behaviour I've observed ;-) I
believe oracle 8i should work fine with TrackConnectionByTx.
--
Igor Fedorenko
Think smart. Think automated. Think Dynamics.
www.thinkdynamics.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: [JBoss-dev] Build System... any ideas
Jason, I had submitted an example directly to David sometime last week, but I'll share with the world now so that the entire Jboss team can benefit. Its not a Java project per se, as it really only uses a sitemap.xml and an XSL to produce another ant script for running XSL transformations on a web site I manage. But, you are welcome to use it as a starting point. I was hoping to convert a project that I am managing from using redundant task bodies to use something like (half-baked mind you): module name=Foo depends module name=Bar/ /depends libs lib ref=my.class.path.ref /libs ear/ war/ java/ xdoclet/ /module But for now, take a look at the following project for an example of using XSL + XML to produce dynamic Ant scripts. Not sure if it will help, but see if it will get you started. I can answer any questions you have about how it works, as I am fluent in XSL. cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/ccaustin login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/ccaustin co ccaustin The interesting files are the src/web/xml/sitemap.xml , src/web/xml/sitemap-build.xsl, and if you run the ant script with an XSL engine in your $ANT_HOME/lib, it will produce a file called autogen-build.xml in src/web/xml HTH, James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 03, 2002 9:26 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas If I send you an example .xml file can you send me a basic skeleton stylesheet with examples on how to replave tags and access emements? --jason On Fri, 20 Sep 2002, David Jencks wrote: I've seen similar explanations on the ant list sometimes, but they all go way over my head. Is there any chance of showing us one of these projects build system to look at in detail? thanks david jencks On 2002.09.20 15:49:51 -0400 James Higginbotham wrote: Not sure what you may want to do with XSL, but we use it for our product's build system and I use it for a personal project as well. Its quite powerful, since you have define a modules.xml that has all the dependencies and let XSL generate the right build targets. It would offer primary targets for the caller to invoke and would delegate to the generated script. The main build.xml would determine if the generated xml is out of date or missing and XSLT the modules.xml or whatever into the resulting ant script before invoking the delegated call. I haven't dove into your buildmagic too much, but a commontargets that is shared by all modules lets you share common targets, while the XSL could be done to drive each modules' build script or a master build script. I'm sure you guys have a complex build env, but thought I'd throw this out for you and others that may want to know how we are using XSL + Ant. HTH, James -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Friday, September 20, 2002 2:17 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Build System... any ideas Can you find any more info about using xslt or velocity as a preprocessor to the build files? I think this might be a good idea, but just as you say I can not find any examples of it to study. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 6:43 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas There seems to be an import and an include and I'm not completely sure what the difference is or where the include task is. The import might get into ant 1.6 and is already part of centipede. Here's the code for import: http://cvs.apache.org/viewcvs.cgi/jakarta-ant/proposal/embed/#dirl ist Most of the build gurus on the ant list seem to like the idea of generating build files using xslt or velocity and then running them with plain ant rather than using things like foreach. I haven't seen an example of this yet. david jencks On 2002.09.19 20:43:43 -0400 Jason Dillon wrote: Where is the include task documented... I didn't find it on their website. --jason -Original Message- From: [EMAIL PROTECTED] [mailto:jboss- [EMAIL PROTECTED]] On Behalf Of David Jencks Sent: Thursday, September 19, 2002 5:27 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Build System... any ideas On 2002.09.19 19:32:25 -0400 Scott M Stark wrote: I still don't buy it. Many of the existing tests involve several functional
