[JBoss-dev] Checking out the main branch code, use jboss-head
SF mail seems hours behind so I don't know if there is a mail in the backlog from Jason describing the last changes he made to create the jboss-3.0, jboss-3.2, etc version modules with jboss-all being the main branch. If there is, this applies to the CVSROOT/modules file version 1.188 which keeps the jboss-all branch as an alias for the 3.0 production branch. The documented procedure for building 3.0 using the Branch_3_0 version of the jboss-all module continues to be valid and will remain so. You can also check out and build 3.0 using the more descriptive jboss-3.0 module name. So, the following are valid for obtaining the current 3.0 code: cvs co -r Banch_3_0 jboss-all -> a jboss-all directory cvs co -r Banch_3_0 jboss-3.0 -> a jboss-3.0 directory To obtain the main branch you must use: cvs co jboss-head -> jboss-head directory Scott Stark Chief Technology Officer JBoss Group, LLC --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] 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 build.sh: Executing: /home/lubega/jbossro/jboss-all/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger clean Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/build/../tools/etc/buildfragments/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found Total time: 7 seconds --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] HEAD Build: numerous failure
Using build.sh or build.bat? --jason On Tue, 8 Oct 2002, Sacha Labourey wrote: > I think the reason is the JVM size that is necessary (-Xmx): it must be > higher probably. Which is why, doing it step by step succeeds: as numerous > steps are already done, the memory is simply exhausted later. > > > -Message d'origine- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]De la part de > > Jason Dillon > > Envoye : lundi, 7 octobre 2002 23:07 > > A : Jboss-Dev > > Objet : Re: [JBoss-dev] HEAD Build: numerous failure > > > > > > What errors do you get specifically Sacha? > > > > --jason > > > > > > On Mon, 7 Oct 2002, Sacha Labourey wrote: > > > > > Hello, > > > > > > Is it just me? I am trying to compile jboss-all from HEAD (I did a fresh > > > checkout a few minutes ago) on windows 2000 and I get lots of > > errors which > > > change over time i.e the compiler (1.4.0) makes an exception > > and, if I start > > > again the build process, it goes further, ... then it is an RMI compiler > > > errror (couldn't read LOC header), then it is a set of silent > > break, etc. At > > > the end (after 4-5 restart, it is build successfuly) > > > > > > 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 > > > > > > > > > > > --- > > 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] README :: Thirdparty structure changed
I hope so... but I do not think there are plans to go away from SourceForge anytime soon. Perhaps they will start using somthing better sometime this century... --jason On Tue, 8 Oct 2002, Sacha Labourey wrote: > One day Subversion will save us from CVS ;) > > http://subversion.tigris.org/ > > > -Message d'origine- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]De la part de > > David Jencks > > Envoyé : lundi, 7 octobre 2002 23:10 > > À : [EMAIL PROTECTED] > > Objet : Re: [JBoss-dev] README :: Thirdparty structure changed > > > > > > CVS can't handle thirdparty only including some of the subdirectories. On > > checkout you get one set of stuff, if you update you get much more. Jason > > was trying to make the set of stuff you get from checkout and update the > > same. I think its really important to ensure this, whether or not Jason's > > fix is the best possible. I think fixing it (at least in head) is more > > important than keeping the directory structure the same. If you > > have a way > > to fix the problem while keeping the structure the same, I think > > that would > > be better. I don't have such a way. > > > > > --- > 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] HEAD Build: numerous failure
I do not think that is possible... could be a problem with 1.4.1. I verified that clean builds of all projects build correctly with 1.3.1 (using the new module names that is... did anyone get that email? I sent it hours agao?). --jason On Tue, 8 Oct 2002, Sacha Labourey wrote: > Here is one I got on 3.0 with jdk 1.4.0_01-b03 on windows: > > I simply think that the new libs introduce more memory overhead > > > [xdoclet] Generating output for > 'org.jboss.management.j2ee.MessageDrivenBean > ' using template file > 'jar:file:/J:/CVS_HOME/jboss-3.0/tools/lib/xdoclet.jar!/xd > oclet/jmx/mbean.j'. > [xdoclet] Generating output for > 'org.jboss.management.j2ee.ResourceAdapter' > using template file > 'jar:file:/J:/CVS_HOME/jboss-3.0/tools/lib/xdoclet.jar!/xdoc > let/jmx/mbean.j'. > [xdoclet] Generating output for > 'org.jboss.management.j2ee.ResourceAdapterMo > dule' using template file > 'jar:file:/J:/CVS_HOME/jboss-3.0/tools/lib/xdoclet.jar > !/xdoclet/jmx/mbean.j'. > [xdoclet] Generating output for > 'org.jboss.management.j2ee.RMI_IIOPResource' > using template file > 'jar:file:/J:/CVS_HOME/jboss-3.0/tools/lib/xdoclet.jar!/xdo > clet/jmx/mbean.j'. > [xdoclet] > [xdoclet] Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at > PC=0x6D3B > 784D > [xdoclet] Function=JVM_RegisterUnsafeMethods+0x1166 > [xdoclet] Library=H:\java\j2sdk1.4.0_01\jre\bin\client\jvm.dll > [xdoclet] > [xdoclet] Current Java thread: > [xdoclet] at java.lang.Throwable.fillInStackTrace(Native Method) > [xdoclet] - locked <029F0590> (a java.lang.NullPointerException) > [xdoclet] at java.lang.Throwable.(Throwable.java:180) > [xdoclet] at java.lang.Exception.(Exception.java:29) > [xdoclet] at > java.lang.RuntimeException.(RuntimeException.java:32) > [xdoclet] at > java.lang.NullPointerException.(NullPointerException.ja > va:36) > [xdoclet] [error occured during error reporting] > J:\CVS_HOME\jboss-3.0\management\build.xml:238: Java returned: -2147483645 > at org.apache.tools.ant.taskdefs.Java.execute(Java.java:90) > at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:175) > at xdoclet.DocletTask.execute(DocletTask.java:298) > at > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:104) > at org.apache.tools.ant.Task.perform(Task.java:217) > at org.apache.tools.ant.Target.execute(Target.java:164) > at org.apache.tools.ant.Target.performTasks(Target.java:182) > at org.apache.tools.ant.Project.executeTarget(Project.java:601) > at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261) > at > org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(E > xecuteModules.java:269) > at > org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(Execute > Modules.java:184) > at org.apache.tools.ant.Task.perform(Task.java:217) > at org.apache.tools.ant.Target.execute(Target.java:164) > at org.apache.tools.ant.Target.performTasks(Target.java:182) > at org.apache.tools.ant.Project.executeTarget(Project.java:601) > at org.apache.tools.ant.Project.executeTargets(Project.java:560) > at org.apache.tools.ant.Main.runBuild(Main.java:454) > at org.apache.tools.ant.Main.start(Main.java:153) > at org.apache.tools.ant.Main.main(Main.java:176) > > BUILD FAILED > > J:\CVS_HOME\jboss-3.0\management\build.xml:238: Java returned: -2147483645 > > Total time: 1 minute 14 seconds > > > > > -Message d'origine- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]De la part de > > Jason Dillon > > Envoye : lundi, 7 octobre 2002 23:07 > > A : Jboss-Dev > > Objet : Re: [JBoss-dev] HEAD Build: numerous failure > > > > > > What errors do you get specifically Sacha? > > > > --jason > > > > > > On Mon, 7 Oct 2002, Sacha Labourey wrote: > > > > > Hello, > > > > > > Is it just me? I am trying to compile jboss-all from HEAD (I did a fresh > > > checkout a few minutes ago) on windows 2000 and I get lots of > > errors which > > > change over time i.e the compiler (1.4.0) makes an exception > > and, if I start > > > again the build process, it goes further, ... then it is an RMI compiler > > > errror (couldn't read LOC header), then it is a set of silent > > break, etc. At > > > the end (after 4-5 restart, it is build successfuly) > > > > > > 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 > > > > > > > > > > > --- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > >
[JBoss-dev] FWD: README :: JBoss Projects & Build System (fwd)
Looks like mail is slow these days, so I am copying this again... * * * I have just verified that all of the branches for the currently active JBoss versions build correctly out of the box. I did however need to make some modifications to the CVSROOT/modules file to make this work correctly and to help prevent future fuckups (probably by me) when changing the structure of a project (which should not other branches a project). To make use of this I have setup 3 new project definitions in CVSROOT/modules: jboss-3.0 - The JBoss 3.0.x project structure definition jboss-3.2 - The JBoss 3.2.x '' jboss-2.4 - The JBoss 2.4.x '' Unfortunately CVS does not allow branch tags (or any tags) to be specified in the module definition, so you must still specific '-r ' on the command line. The above simply specifies the correct structure for the project. For example, to check out the latest JBoss 3.0.x you would: cvs get -r Branch_3_0 jboss-3.0 For JBoss 3.2 you would: cvs get -r Branch_3_2 jboss-3.2 Keep in mind that you should use the correct project definition even when checking out non-branch tags as well. 'jboss-all' is still the HEAD branch. I think that we should eventually change this name to 'jboss' or 'jboss-head', since it does not really contain 'all' of the modules anymore. But this can wait until later. I am currently working on making the JBoss 2.4 project independent of other structure changes, but I have not completed it yet. The current branch will build as it did before; I have changed nothing that would affect that. * * * I am really sorry about the mess I created last night. I don't know why, but I had convinced myself that the other branches would work fine. Before I stopped for the evening I thought about that issue for a bit and decided things were okay. Anyways, I am really sorry for the trouble. I hope to avoid such messes in the future. Your humble build system slave (AKA. That guy who always breaks things), --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.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 build.sh: Executing: /home/lubega/jbossro/jboss-all/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger clean Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/build/../tools/etc/buildfragments/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found Total time: 7 seconds --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-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 build.sh: Executing: /home/lubega/jbossro/jboss-all/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger clean Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/build/../tools/etc/buildfragments/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found Total time: 8 seconds --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [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 build.sh: Executing: /home/lubega/jbossro/jboss-all/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger -Dinstall.id=testbuild release Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/build/../tools/etc/buildfragments/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found Total time: 6 seconds --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed
Hi, > > _buildmagic:init: > Trying to override old definition of task property > > BUILD FAILED > file:/disk/orig/home/lubega/jbossro/jboss-all/build/../tools/etc/buildfragments/tools.ent:29: > taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found > We've got past the other problems - but still have this one - is it just me - or is there really a problem here? I did a full checkout earlier - so it should be up to date. Chris = __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[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 build.sh: Executing: /home/lubega/jbossro/jboss-all/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger clean Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/build/../tools/etc/buildfragments/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found Total time: 5 seconds --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [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 build.sh: Executing: /home/lubega/jbossro/jboss-all/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger -Dinstall.id=testbuild release Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/build/../tools/etc/buildfragments/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found Total time: 5 seconds --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss-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 build.sh: Executing: /home/lubega/jbossro/jboss-all/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger clean Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/build/../tools/etc/buildfragments/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found Total time: 27 seconds --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] HEAD Build: numerous failure
build.bat > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de > Jason Dillon > Envoye : mardi, 8 octobre 2002 10:37 > A : [EMAIL PROTECTED] > Objet : RE: [JBoss-dev] HEAD Build: numerous failure > > > Using build.sh or build.bat? > > --jason > > > On Tue, 8 Oct 2002, Sacha Labourey wrote: > > > I think the reason is the JVM size that is necessary (-Xmx): it must be > > higher probably. Which is why, doing it step by step succeeds: > as numerous > > steps are already done, the memory is simply exhausted later. > > > > > -Message d'origine- > > > De : [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]De la part de > > > Jason Dillon > > > Envoye : lundi, 7 octobre 2002 23:07 > > > A : Jboss-Dev > > > Objet : Re: [JBoss-dev] HEAD Build: numerous failure > > > > > > > > > What errors do you get specifically Sacha? > > > > > > --jason > > > > > > > > > On Mon, 7 Oct 2002, Sacha Labourey wrote: > > > > > > > Hello, > > > > > > > > Is it just me? I am trying to compile jboss-all from HEAD > (I did a fresh > > > > checkout a few minutes ago) on windows 2000 and I get lots of > > > errors which > > > > change over time i.e the compiler (1.4.0) makes an exception > > > and, if I start > > > > again the build process, it goes further, ... then it is an > RMI compiler > > > > errror (couldn't read LOC header), then it is a set of silent > > > break, etc. At > > > > the end (after 4-5 restart, it is build successfuly) > > > > > > > > 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 > > > > > > > > > > > > > > > > --- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > --- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] HEAD Build: numerous failure
It wasn't with 1.4.1, but with 1.4.0. Maybe that was just my particular setup. Let's wait to have more user feedback to see if I am the only one having this issue. > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]De la part de > Jason Dillon > Envoye : mardi, 8 octobre 2002 10:40 > A : [EMAIL PROTECTED] > Objet : RE: [JBoss-dev] HEAD Build: numerous failure > > > I do not think that is possible... could be a problem with 1.4.1. I > verified that clean builds of all projects build correctly with > 1.3.1 (using > the new module names that is... did anyone get that email? I > sent it hours > agao?). > > --jason > > > On Tue, 8 Oct 2002, Sacha Labourey wrote: > > > Here is one I got on 3.0 with jdk 1.4.0_01-b03 on windows: > > > > I simply think that the new libs introduce more memory overhead > > > > > > [xdoclet] Generating output for > > 'org.jboss.management.j2ee.MessageDrivenBean > > ' using template file > > 'jar:file:/J:/CVS_HOME/jboss-3.0/tools/lib/xdoclet.jar!/xd > > oclet/jmx/mbean.j'. > > [xdoclet] Generating output for > > 'org.jboss.management.j2ee.ResourceAdapter' > > using template file > > 'jar:file:/J:/CVS_HOME/jboss-3.0/tools/lib/xdoclet.jar!/xdoc > > let/jmx/mbean.j'. > > [xdoclet] Generating output for > > 'org.jboss.management.j2ee.ResourceAdapterMo > > dule' using template file > > 'jar:file:/J:/CVS_HOME/jboss-3.0/tools/lib/xdoclet.jar > > !/xdoclet/jmx/mbean.j'. > > [xdoclet] Generating output for > > 'org.jboss.management.j2ee.RMI_IIOPResource' > > using template file > > 'jar:file:/J:/CVS_HOME/jboss-3.0/tools/lib/xdoclet.jar!/xdo > > clet/jmx/mbean.j'. > > [xdoclet] > > [xdoclet] Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at > > PC=0x6D3B > > 784D > > [xdoclet] Function=JVM_RegisterUnsafeMethods+0x1166 > > [xdoclet] Library=H:\java\j2sdk1.4.0_01\jre\bin\client\jvm.dll > > [xdoclet] > > [xdoclet] Current Java thread: > > [xdoclet] at java.lang.Throwable.fillInStackTrace(Native Method) > > [xdoclet] - locked <029F0590> (a java.lang.NullPointerException) > > [xdoclet] at java.lang.Throwable.(Throwable.java:180) > > [xdoclet] at java.lang.Exception.(Exception.java:29) > > [xdoclet] at > > java.lang.RuntimeException.(RuntimeException.java:32) > > [xdoclet] at > > java.lang.NullPointerException.(NullPointerException.ja > > va:36) > > [xdoclet] [error occured during error reporting] > > J:\CVS_HOME\jboss-3.0\management\build.xml:238: Java returned: > -2147483645 > > at org.apache.tools.ant.taskdefs.Java.execute(Java.java:90) > > at xjavadoc.ant.XJavadocTask.execute(XJavadocTask.java:175) > > at xdoclet.DocletTask.execute(DocletTask.java:298) > > at > > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:104) > > at org.apache.tools.ant.Task.perform(Task.java:217) > > at org.apache.tools.ant.Target.execute(Target.java:164) > > at org.apache.tools.ant.Target.performTasks(Target.java:182) > > at org.apache.tools.ant.Project.executeTarget(Project.java:601) > > at org.jboss.tools.buildmagic.task.Ant.execute(Ant.java:261) > > at > > org.jboss.tools.buildmagic.task.module.ExecuteModules.executeModule(E > > xecuteModules.java:269) > > at > > org.jboss.tools.buildmagic.task.module.ExecuteModules.execute(Execute > > Modules.java:184) > > at org.apache.tools.ant.Task.perform(Task.java:217) > > at org.apache.tools.ant.Target.execute(Target.java:164) > > at org.apache.tools.ant.Target.performTasks(Target.java:182) > > at org.apache.tools.ant.Project.executeTarget(Project.java:601) > > at org.apache.tools.ant.Project.executeTargets(Project.java:560) > > at org.apache.tools.ant.Main.runBuild(Main.java:454) > > at org.apache.tools.ant.Main.start(Main.java:153) > > at org.apache.tools.ant.Main.main(Main.java:176) > > > > BUILD FAILED > > > > J:\CVS_HOME\jboss-3.0\management\build.xml:238: Java returned: > -2147483645 > > > > Total time: 1 minute 14 seconds > > > > > > > > > -Message d'origine- > > > De : [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]De la part de > > > Jason Dillon > > > Envoye : lundi, 7 octobre 2002 23:07 > > > A : Jboss-Dev > > > Objet : Re: [JBoss-dev] HEAD Build: numerous failure > > > > > > > > > What errors do you get specifically Sacha? > > > > > > --jason > > > > > > > > > On Mon, 7 Oct 2002, Sacha Labourey wrote: > > > > > > > Hello, > > > > > > > > Is it just me? I am trying to compile jboss-all from HEAD > (I did a fresh > > > > checkout a few minutes ago) on windows 2000 and I get lots of > > > errors which > > > > change over time i.e the compiler (1.4.0) makes an exception > > > and, if I start > > > > again the build process, it goes further, ... then it is an > RMI compiler > > > > errror (couldn't read LOC header), then it is a set of silent > > > break, etc. At > > > > the end (after 4
Re: [JBoss-dev] JBoss 3.0.3 Bug: typo in TransactionImpl + trying to change Tx in enlist exception
Can you please file two bug reports for these? (please assign them to me if possible) If you can supply any kind of example to reproduce the second bug I would appreciate it. I find it mysterious because the code for LocalTx is supposed to return connections to the pool only after the transaction is committed. Anything else is a serious error. No workarounds should be necessary. thanks david jencks On 2002.10.08 04:08:24 -0400 Marko Štrukelj wrote: > > > (using: JBoss-3.0.3-src) > > > There is a typo in TransactionImpl disassociateCurrentThread(). > tx.associateCurrentThread() is called instead of > tx.disassociateCurrentThread() > > > > > There is another more annoying bug/feature. > When doing very intensive remote calls via statefull session, using the > database with user managed transactions I often get this error: > > > 2002-10-03 15:51:16,000 WARN >[org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEventListener] > in Enlisting tx, trying to change tx. illegal state: old: > TransactionImpl:XidImpl [FormatId=257, GlobalId=brutus//233, > BranchQual=], new: TransactionImpl:XidImpl [FormatId=257, > GlobalId=brutus//234, BranchQual=], cel: > >org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEventListener@1f8d0a4 > 2002-10-03 15:51:16,000 ERROR [STDERR] java.lang.IllegalStateException: > Trying to change Tx in enlist! > 2002-10-03 15:51:16,000 ERROR [STDERR] at > >org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEventListener.enlist(LocalTxConnectionManager.java:309) > 2002-10-03 15:51:16,000 ERROR [STDERR] at > >org.jboss.resource.connectionmanager.LocalTxConnectionManager.managedConnectionReconnected(LocalTxConnectionManager.java:255) > 2002-10-03 15:51:16,000 ERROR [STDERR] at > >org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:534) > 2002-10-03 15:51:16,000 ERROR [STDERR] at > >org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:812) > 2002-10-03 15:51:16,000 ERROR [STDERR] at > >org.jboss.resource.adapter.jdbc.local.LocalDataSource.getConnection(LocalDataSource.java:102) > > > It only happens when there is severe concurent use of the database. But > it does happen a lot. > > > What happens is this: > > Thread 1: > > userTransaction.begin(); > Connection c=ds.getConnection();// lets call this > Connection1 > > // ... use connection > > c.close(); // close connection > > // now don't commit transaction yet > > > > Thread 2: > userTransaction.begin(); > Connection c=ds.getConnection(); // KABOOOM! Exception > happens here. > > > > Exception happened because Connection1 was trying to be returned - the > same connection that was used by another thread. > > In the time between returning a connection to the pool and calling commit > on UserTransaction the same connection is checked out to another thread. > > > I played around with connector package and managed to reduce the problem > to virtually zero occurances. Now, the changes to the code I did are > quite crude and probably aren't in the spirit of code separation as was > envisaged (talk about casting interface to actual implementation and some > classes made public) so they are not suitable to be commited to cvs. > > > > The solution depends on InternalManagedConnectionPool.getConnection > method detecting in advance the condition that causes 'trying to change > Tx in enlist' exception. If ManagedConection is in 'transaction > collision' we simply find another one that is not. > > > To sum up the patch: > > - The main code is in InternalManagedConnectionPool.getConnection > > In order to make this code work and in order for the whole code to > compile other changes had to be made: > - methodvoid setBaseConnectionManager2(BaseConnectionManager2 bcm) > was added to ManagedConnectionPool interface. > - It had to be implemented on several places in > JBossManagedConnectionPool.java > - It was implemented in InternalManagerConnectionPool > - Calls to setBaseConnectionManager2 had to be added in > BaseConnectionManager2 to pass reference to LocalTxConnectionManager. > > - LocalTxConnectionManager.LocalConnectionEventListener has new method: > boolean isTransactionCollisionFree() > > > > This quick patch is posted here more as an example of the kind of > checking that needs to be done in order to make the exception go away. > > > regards, > > -Marko > > > > > > > > JBoss 3.0.3 Bug: typo in TransactionImpl + trying to change Tx in > enlist exception > > > > > > (using: JBoss-3.0.3-src) > > > > There is a typo in TransactionImpl > disassociateCurrentThread(). tx.associateCurrentThread() is called > instead of tx.disassociateCurrentThread() > > > > > There is another more annoying bug/fe
[JBoss-dev] [ jboss-Bugs-608790 ] [3.0.2]Hot deploy of unpackaged SAR bug?
Bugs item #608790, was opened at 2002-09-13 07:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=608790&group_id=22866 Category: JBossMX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 4 Submitted By: Chris Kimpton (kimptoc) Assigned to: Nobody/Anonymous (nobody) Summary: [3.0.2]Hot deploy of unpackaged SAR bug? Initial Comment: Hi, I was deploying my sar in the unpackaged form, like the jbossweb.sar directory. Deployment works fine. The problem I hit with re-deployment (that is deleting the directory and copying it over again) is that messages appear in the jboss log, so you think it is doing a redployment, but it restarts the old code, not a new version. I was changing the log messages from the code and the old ones kept being displayed. But it works fine if I deploy as a packaged sar file. Is this a known problem? Regards, Chris -- >Comment By: Chris Kimpton (kimptoc) Date: 2002-10-08 12:40 Message: Logged In: YES user_id=39204 This was on Windows2000 -- Comment By: Scott M Stark (starksm) Date: 2002-09-29 02:29 Message: Logged In: YES user_id=175228 On what operating system? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=608790&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-620254 ] A typo in TransactionImpl
Bugs item #620254, was opened at 2002-10-08 16:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620254&group_id=22866 Category: JBossTX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Marko Strukelj (mstruk) Assigned to: Nobody/Anonymous (nobody) Summary: A typo in TransactionImpl Initial Comment: There is a typo in TransactionImpl disassociateCurrentThread(). tx.associateCurrentThread() is called instead of tx.disassociateCurrentThread(). using: JBoss-3.0.3-src.tgz download -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620254&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-620254 ] A typo in TransactionImpl
Bugs item #620254, was opened at 2002-10-08 16:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620254&group_id=22866 Category: JBossTX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Marko Strukelj (mstruk) >Assigned to: David Jencks (d_jencks) Summary: A typo in TransactionImpl Initial Comment: There is a typo in TransactionImpl disassociateCurrentThread(). tx.associateCurrentThread() is called instead of tx.disassociateCurrentThread(). using: JBoss-3.0.3-src.tgz download -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620254&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-620262 ] Trying to change Tx in enlist exception
Bugs item #620262, was opened at 2002-10-08 16:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620262&group_id=22866 Category: JBossCX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Marko Strukelj (mstruk) Assigned to: Nobody/Anonymous (nobody) Summary: Trying to change Tx in enlist exception Initial Comment: When doing very intensive remote calls via statefull session, using the database with user managed transactions I often get this error: 2002-10-03 15:51:16,000 WARN [org.jboss.resource.connectionmanager.LocalTxConnecti onManager$LocalConnectionEventListener] in Enlisting tx, trying to change tx. illegal state: old: TransactionImpl:XidImpl [FormatId=257, GlobalId=brutus//233, BranchQual=], new: TransactionImpl:XidImpl [FormatId=257, GlobalId=brutus//234, BranchQual=], cel: org.jboss.resource.connectionmanager.LocalTxConnecti onManager$LocalConnectionEventListener@1f8d0a4 2002-10-03 15:51:16,000 ERROR [STDERR] java.lang.IllegalStateException: Trying to change Tx in enlist! 2002-10-03 15:51:16,000 ERROR [STDERR] at org.jboss.resource.connectionmanager.LocalTxConnecti onManager$LocalConnectionEventListener.enlist (LocalTxConnectionManager.java:309) 2002-10-03 15:51:16,000 ERROR [STDERR] at org.jboss.resource.connectionmanager.LocalTxConnecti onManager.managedConnectionReconnected (LocalTxConnectionManager.java:255) 2002-10-03 15:51:16,000 ERROR [STDERR] at org.jboss.resource.connectionmanager.BaseConnection Manager2.allocateConnection (BaseConnectionManager2.java:534) 2002-10-03 15:51:16,000 ERROR [STDERR] at org.jboss.resource.connectionmanager.BaseConnection Manager2$ConnectionManagerProxy.allocateConnection (BaseConnectionManager2.java:812) 2002-10-03 15:51:16,000 ERROR [STDERR] at org.jboss.resource.adapter.jdbc.local.LocalDataSource.g etConnection(LocalDataSource.java:102) It only happens when there is severe concurent use of the database. But it does happen a lot. What seems to happen is this: Thread 1: userTransaction.begin(); Connection c=ds.getConnection();// lets call this Connection1 // ... use connection c.close(); // close connection // now don't commit transaction yet Thread 2: userTransaction.begin(); Connection c=ds.getConnection(); // KABOOOM! Exception happens here. Exception happened because Connection1 was trying to be returned - the same connection that was used by another thread. In the time between returning a connection to the pool and calling commit on UserTransaction the same connection is checked out to another thread. I am trying to make an example to reproduce the bug. So far the only way I can reproduce it is on my production system with full application deployed. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620262&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-620293 ] oracle-jbossmq-service.xml buggy
Bugs item #620293, was opened at 2002-10-08 15:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620293&group_id=22866 Category: JBossMQ Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Bernd Zeitler (frito) Assigned to: Nobody/Anonymous (nobody) Summary: oracle-jbossmq-service.xml buggy Initial Comment: When Oracle (8.1.7 with XA transactions) is used as persistent store for messages configuring org.jboss.mq.pm.jdbc2.PersistenceManager with oracle- jbossmq-service.xml a SQLException is thrown when MARK_MESSAGE is executed (file version 1.1.2.1, latest version in CVS). Workaround: edit the .xml and change MARK_MESSAGE to: UPDATE JMS_MESSAGES SET TXID=?, TXOP=? WHERE MESSAGEID=? AND DESTINATION=? Greetings, Frito -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620293&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] README :: Thirdparty structure changed
Food for thought? >From www.dictionary.com Modesty - The quality or state of being modest; that lowly temper which accompanies a moderate estimate of one's own worth and importance; absence of self-assertion, arrogance, and presumption; humility respecting one's own merit Pride - an excessively high opinion of oneself Humility - a modest estimate of one's own worth --- 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] Fixing module defintions now for head, 3.0 & 3.2
Why don't we set up a CVS testbed somewhere to test CVS changes? You (editorial 'you') don't (shouldn't) commit changes to code without thorough testing. Considering what's at risk, it seems to me that CVS changes should be made even more cautiously. This project already has too many 'moving targets' to try to deal with. > > I have to modify CVSROOT/modules to test, so please be patient if > something does not function. I will make sure that all jboss-* projects > function by the days end. > --- 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] How is Constructor Info used?
JMX gurus, When I first saw XMBean XML, I assumed that referred to the constructor for the resource (model object). On a closer look, it appears that this information (ModelMBeanConstructorInfo) refers only to the constructor for the MB itself. Is this information being used in any way in the server? What purpose is it intended to serve? When loading the registry from the store, I need to instantiate the appropriate resources (model objects). Any reason why I shouldn't store the constructor information for the resource in the MMB descriptor, similar to what I did with the persistence information? - Matt Munz --- 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-all daily clean failed
Hi, They are kept on the lubega server - only... Chris - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 08, 2002 10:38 AM Subject: Re: [JBoss-dev] jboss-all daily clean failed > Hey... where do the scripts that controll the nightly build live? We need > to make some modifications so that the correct bits are checked out. > > --jason > > > On Tue, 8 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 > > > > build.sh: Executing: /home/lubega/jbossro/jboss-all/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger clean > > Buildfile: build.xml > > > > _buildmagic:init: > > Trying to override old definition of task property > > > > BUILD FAILED > > file:/disk/orig/home/lubega/jbossro/jboss-all/build/../tools/etc/buildfragme nts/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found > > > > Total time: 7 seconds > > > > > > --- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > --- 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 had the same problem yesterday. I've deleted jboss-all (and directory jboss which temporary existed) and made a new checkout. Now compilation is fine again. Regards Frank Chris Kimpton wrote: >Hi, > > > >>_buildmagic:init: >>Trying to override old definition of task property >> >>BUILD FAILED >> >> >> >file:/disk/orig/home/lubega/jbossro/jboss-all/build/../tools/etc/buildfragments/tools.ent:29: > > >>taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found >> >> >> > >We've got past the other problems - but still have this one - is it >just me - or is there really a problem here? > >I did a full checkout earlier - so it should be up to date. > >Chris > >= > > >__ >Do you Yahoo!? >Faith Hill - Exclusive Performances, Videos & More >http://faith.yahoo.com > > >--- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >___ >Jboss-development mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/jboss-development > > > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-620254 ] A typo in TransactionImpl
Bugs item #620254, was opened at 2002-10-08 09:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620254&group_id=22866 Category: JBossTX Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Marko Strukelj (mstruk) >Assigned to: Bill Burke (patriot1burke) Summary: A typo in TransactionImpl Initial Comment: There is a typo in TransactionImpl disassociateCurrentThread(). tx.associateCurrentThread() is called instead of tx.disassociateCurrentThread(). using: JBoss-3.0.3-src.tgz download -- >Comment By: Bill Burke (patriot1burke) Date: 2002-10-08 12:51 Message: Logged In: YES user_id=176497 My bad, I'll fix. Sorry for the type. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620254&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-620254 ] A typo in TransactionImpl
Bugs item #620254, was opened at 2002-10-08 09:31 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620254&group_id=22866 Category: JBossTX Group: v3.0 Rabbit Hole >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Marko Strukelj (mstruk) Assigned to: Bill Burke (patriot1burke) Summary: A typo in TransactionImpl Initial Comment: There is a typo in TransactionImpl disassociateCurrentThread(). tx.associateCurrentThread() is called instead of tx.disassociateCurrentThread(). using: JBoss-3.0.3-src.tgz download -- Comment By: Bill Burke (patriot1burke) Date: 2002-10-08 12:51 Message: Logged In: YES user_id=176497 My bad, I'll fix. Sorry for the type. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620254&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Fixing module defintions now for head, 3.0 & 3.2
Ummm think about it... for CVSROOT changes that would mean being easily able to get a mirror of the project cvs files (the blah.java,v files), which AFAIK sourceforge does not enable. Perhaps a more doable alternative is a list of what to check after CVSROOT changes. david jencks On 2002.10.08 12:33:30 -0400 Tom Coleman wrote: > > Why don't we set up a CVS testbed somewhere to test CVS changes? > > You (editorial 'you') don't (shouldn't) commit changes to code without > thorough testing. Considering what's at risk, it seems to me that CVS > changes should be made even more cautiously. > > This project already has too many 'moving targets' to try to deal with. > > > > > I have to modify CVSROOT/modules to test, so please be patient if > > something does not function. I will make sure that all jboss-* > projects > > function by the days end. > > > > > --- > 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] JBoss 3.0.3 Bug: typo in TransactionImpl + tryingto change Tx in enlist exception
I am trying to put together a working example to reproduce the problem. I will try to go along the following lines: limit connection pool to 2 connections. Create 10 threads that invoke on the server side : ut.begin(); ds.getConnection(); c.close(); And hope to see the error happen. But I'm just so busy this week... It may take me days, so if you get's tired waiting ... regards, - Marko >Can you please file two bug reports for these? (please assign them to me if >possible) > >If you can supply any kind of example to reproduce the second bug I would >appreciate it. I find it mysterious because the code for LocalTx is >supposed to return connections to the pool only after the transaction is >committed. Anything else is a serious error. No workarounds should be >necessary. > >thanks >david jencks > > --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] README :: Thirdparty structure changed
Oops. Missed an important one... >From www.dictionary.com Ego - An inflated feeling of pride in your superiority to others --- 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] How is Constructor Info used?
On Tue, 8 Oct 2002, Matt Munz wrote: > When I first saw XMBean XML, I assumed that referred to the > constructor for the resource (model object). On a closer look, it appears > that this information (ModelMBeanConstructorInfo) refers only to the > constructor for the MB itself. it is not clearly defined which it should refer to in case of MMB. It might be better defined in JMX 1.2 version of the spec. > Is this information being used in any way in the server? no, as far as I know > What purpose is it intended to serve? not sure -- 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] [AUTOMATED] (HEAD) JBoss compilation failed
The head revision cannot be checked out using the jboss-all module alias any longer. The jboss-head alias must be used instead. If you successfully wade through the dump of CVSROOT/module changes and associated mails this is the summary statement: - To checkout 3.0 use: cvs co -r Branch_3_0 jboss-all-> a jboss-all directory with the current 3.0 structure or cvs co -r Branch_3_0 jboss-3.0-> a jboss-3.0 directory with the current 3.0 structure - To checkout 3.2 use: cvs co -r Branch_3_2 jboss-3.2-> a jboss-3.2 directory with the current 3.2 structure - To checkout main/4.0 alpha cvs co jboss-head-> a jboss-head directory with the current main branch So, jboss-all is bound to the 3.0 release for now until the end of time. All future branches will have a module alias that reflects the version number to avoid the problems of CVS not versioning its metadata. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Chris Kimpton" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 08, 2002 4:30 AM Subject: Re: [JBoss-dev] [AUTOMATED] (HEAD) JBoss compilation failed > Hi, > > > > > _buildmagic:init: > > Trying to override old definition of task property > > > > BUILD FAILED > > > >file:/disk/orig/home/lubega/jbossro/jboss-all/build/../tools/etc/buildfragments/tools.ent:29: > > taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found > > > > We've got past the other problems - but still have this one - is it > just me - or is there really a problem here? > > I did a full checkout earlier - so it should be up to date. > > Chris --- 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] README :: Thirdparty structure changed
How about these definitions: Aggravation: When somebody fucks up CVS and you waste a whole day of development. Annoyance: When somebody posts stupid definitions from www.dictionary.com > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Tom > Coleman > Sent: Tuesday, October 08, 2002 2:37 PM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] README :: Thirdparty structure changed > > > > Oops. Missed an important one... > > > >From www.dictionary.com > > Ego - An inflated feeling of pride in your superiority to others > > > --- > 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] Fixing module defintions now for head, 3.0 & 3.2
To effectivly test I would need to replicate the entire repository. --jason On Tue, 8 Oct 2002, Tom Coleman wrote: > > Why don't we set up a CVS testbed somewhere to test CVS changes? > > You (editorial 'you') don't (shouldn't) commit changes to code without > thorough testing. Considering what's at risk, it seems to me that CVS > changes should be made even more cautiously. > > This project already has too many 'moving targets' to try to deal with. > > > > > I have to modify CVSROOT/modules to test, so please be patient if > > something does not function. I will make sure that all jboss-* projects > > function by the days end. > > > > > --- > 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] Fixing module defintions now for head, 3.0 & 3.2
> To effectivly test I would need to replicate the entire repository. FWIW, this could easily be done with rsync, but, as David pointed out, SF.net probably doesn't allow this level of access to their servers. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jason Dillon Sent: Tuesday, October 08, 2002 3:15 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Fixing module defintions now for head, 3.0 & 3.2 To effectivly test I would need to replicate the entire repository. --jason On Tue, 8 Oct 2002, Tom Coleman wrote: > > Why don't we set up a CVS testbed somewhere to test CVS changes? > > You (editorial 'you') don't (shouldn't) commit changes to code without > thorough testing. Considering what's at risk, it seems to me that CVS > changes should be made even more cautiously. > > This project already has too many 'moving targets' to try to deal with. > > > > > I have to modify CVSROOT/modules to test, so please be patient if > > something does not function. I will make sure that all jboss-* projects > > function by the days end. > > > > > --- > 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] How is Constructor Info used?
Juha, It could be worse -- I could be trying to interpret legal documents ;) > it is not clearly defined which it should refer to in case of MMB. It > might be better defined in JMX 1.2 version of the spec. Let me reccommend that the resource object constructor info be given a (defined) place in the MMB info in a future version of the spec. It seems to me that this information is required for MMB info persistence, and probably useful for MMB state persistence as well. For now, I'm just going to go ahead with storing this info in the MMB info object as mentioned previously. - Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Juha-P Lindfors Sent: Tuesday, October 08, 2002 2:51 PM To: JBoss Developers Group Subject: Re: [JBoss-dev] How is Constructor Info used? On Tue, 8 Oct 2002, Matt Munz wrote: > When I first saw XMBean XML, I assumed that referred to the > constructor for the resource (model object). On a closer look, it appears > that this information (ModelMBeanConstructorInfo) refers only to the > constructor for the MB itself. it is not clearly defined which it should refer to in case of MMB. It might be better defined in JMX 1.2 version of the spec. > Is this information being used in any way in the server? no, as far as I know > What purpose is it intended to serve? not sure -- 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 --- 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] CVS lock ?
cvs server: [12:47:41] waiting for anoncvs_jboss's lock in /cvsroot/jboss/jboss-j2ee/src --- 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] JBoss3.2-Tomcat4.1.10
Because more people use Tomcat and want to be able to integrate with existing distributions that they can run standalone. No one has asked for this with Jetty as yet. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Remy Maucherat" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 08, 2002 12:25 AM Subject: Re: [JBoss-dev] JBoss3.2-Tomcat4.1.10 > Scott M Stark wrote: > > If you look at the Embedded usage in the JBoss service it is not doing much. > > Being able to run off a sar with the minimum elements from tomcat would be > > good, but I want to keep the ability to run with a pristine tomcat dist. > > Using the normal Tomcat startup code directly instead of Embedded should > allow it, but what's the rationale behind that ? > I'm asking since that's not the policy with Jetty. Why is Tomcat handled > differently ? > > Remy --- 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-620440 ] Hot deploy DeploymentException
Bugs item #620440, was opened at 2002-10-08 16:37 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620440&group_id=22866 Category: CatalinaBundle Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Don Laidlaw (dlaidlaw) Assigned to: Scott M Stark (starksm) Summary: Hot deploy DeploymentException Initial Comment: jboss 3.0.3 with tomcat 4.1.12 bundle Windows XP, 2000, NT Java 1.3.1_03 and 4.1.1 Happening on combinations of the above! I am hot deploying an ear file, everwriting the existing one of the same name in the deploy directory. The undeploy is throwing the exception as it undeploys the war part of the ear. Undeploys the ejb part just fine. 2002-10-07 20:00:22,035 INFO [org.jboss.deployment.MainDeployer] Undeploying file:/C:/Java/jboss/server/eBuy/deploy/eBuy.ear 2002-10-07 20:00:22,045 INFO [org.jboss.ejb.EjbModule] Stopping 2002-10-07 20:00:22,075 INFO [org.jboss.ejb.EjbModule] Stopped 2002-10-07 20:00:22,075 INFO [org.jboss.web.catalina.EmbeddedCatalinaService41] undeploy, ctxPath=/eBuy, warUrl=file:/C:/Java/jboss/server/eBuy/tmp/deploy/server/ eBuy/deploy/eBuy.ear/91.eBuy.ear-contents/eBuy- web.war 2002-10-07 20:00:22,085 INFO [org.jboss.web.localhost.Engine] StandardHost [localhost]: Removing web application at context path /eBuy 2002-10-07 20:00:22,165 ERROR [org.jboss.deployment.MainDeployer] Undeployment failed: file:/C:/Java/jboss/server/eBuy/tmp/deploy/server/eBuy/d eploy/eBuy.ear/91.eBuy.ear-contents/eBuy-web.war org.jboss.deployment.DeploymentException: Error during deploy; - nested throwable: (java.lang.NullPointerException) at org.jboss.web.AbstractWebContainer.stop (AbstractWebContainer.java:355) at org.jboss.deployment.MainDeployer.stop (MainDeployer.java:469) at org.jboss.deployment.MainDeployer.stop (MainDeployer.java:481) at org.jboss.deployment.MainDeployer.undeploy (MainDeployer.java:443) at org.jboss.deployment.MainDeployer.undeploy (MainDeployer.java:438) at org.jboss.deployment.MainDeployer.undeploy (MainDeployer.java:411) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invok e(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:517) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) at $Proxy4.undeploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner. undeploy(URLDeploymentScanner.java:457) at org.jboss.deployment.scanner.URLDeploymentScanner. scan(URLDeploymentScanner.java:552) 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.NullPointerException at org.jboss.util.file.Files.delete(Files.java:39) at org.jboss.web.catalina.EmbeddedCatalinaService41.perfo rmUndeploy(EmbeddedCatalinaService41.java:330) at org.jboss.web.AbstractWebContainer.stop (AbstractWebContainer.java:345) at org.jboss.deployment.MainDeployer.stop (MainDeployer.java:469) at org.jboss.deployment.MainDeployer.stop (MainDeployer.java:481) at org.jboss.deployment.MainDeployer.undeploy (MainDeployer.java:443) at org.jboss.deployment.MainDeployer.undeploy (MainDeployer.java:438) at org.jboss.deployment.MainDeployer.undeploy (MainDeployer.java:411) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invok e(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:517) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) at $Proxy4.undeploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner. undeploy(URLDeploymentScanner.java:457) at org.jboss.deployment.scanner.URLDeploymentScanner. scan(URLDeploymentScanner.java:552) 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) 2002-10-07 20:00:22,406 INFO [org.jboss.deployment.EARDeployer] Undeploying J2EE application, destroy step: file:/C:/Java/jboss/server/eBuy/deploy/eBuy.ear 2002-10-07 20:00:22,416 INFO [org.jboss.ejb.EjbModule] Destroying 2002-10-07 20:00:22,446 INFO [org.jboss.ejb.EjbModule] Remove JSR-77 EJB Module: jboss.management.single:J2EEApplication=eBuy.ear,J2 EEServer=Single,j2eeType=EJBModule,name=eBuy- ejb.jar 2002-10-07 20:00:22,456 INFO [org.jboss.ejb.EjbModule] Destroyed 2002-10-07 20:00:22,466 INFO [org.jboss.deployment.MainDeployer] not deleting localUrl, it is null or not
[JBoss-dev] somebody has cvs lock in jboss-j2ee/src
...waiting for maximal's lock in /cvsroot/jboss/jboss-j2ee/src Please somebody remove it. Thanks, Bill --- 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-Patches-620459 ] Workaround for buggy Oracle driver
Patches item #620459, was opened at 2002-10-08 21:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376687&aid=620459&group_id=22866 Category: JAWS (inactive) Group: v3.2 Status: Open Resolution: None Priority: 5 Submitted By: Christian Sprajc (totmacherr) Assigned to: Nobody/Anonymous (nobody) Summary: Workaround for buggy Oracle driver Initial Comment: There is a problem in the old JAWs ejb 1.1 layer. When using blobs in CMP beans, i always get a ClassCastException. that is a problem of the oracle driver. but you can get around with changing the standartjaws.xml: in the oracle mapping change the following lines: java.lang.Object BLOB BLOB into: java.lang.Object JAVA_OBJECT BLOB like in the old jboss 2.4.x config. then everything works correct thnx, totmacher -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376687&aid=620459&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 8-October-2002
Number of tests run: 942
Successful tests: 939
Errors:2
Failures: 1
[time of test: 8 October 2002 15:13 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
[JBoss-dev] [ jboss-Bugs-620514 ] MQ OutOfMemoryException
Bugs item #620514, was opened at 2002-10-08 18:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620514&group_id=22866 Category: JBossMQ Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Steve Wolfangel (swolfangel) Assigned to: Nobody/Anonymous (nobody) Summary: MQ OutOfMemoryException Initial Comment: I am getting the following exception when running a test that continously publishes messages. JMSTest.java is included. org.jboss.mq.SpyJMSException: Cannot send a message to the JMS server; - nested throwable: (java.rmi .ServerError: Error occurred in server thread; nested exception is: java.lang.OutOfMemoryError) at org.jboss.mq.Connection.sendToServer (Connection.java:1127) at org.jboss.mq.SpySession.sendMessage (SpySession.java:562) at org.jboss.mq.SpyTopicPublisher.internalPublish (SpyTopicPublisher.java:120) at org.jboss.mq.SpyTopicPublisher.publish (SpyTopicPublisher.java:68) at JMSTest.main(JMSTest.java:121) + nested throwable: java.rmi.ServerError: Error occurred in server thread; nested exception is: java.lang.OutOfMemoryError java.lang.OutOfMemoryError at sun.rmi.transport.StreamRemoteCall.exceptionRecei vedFromServer(StreamRemoteCall.java:245) at sun.rmi.transport.StreamRemoteCall.executeCall (StreamRemoteCall.java:220) at sun.rmi.server.UnicastRef.invoke (UnicastRef.java:122) at org.jboss.mq.il.rmi.RMIServerIL_Stub.addMessage (Unknown Source) at org.jboss.mq.Connection.sendToServer (Connection.java:1119) at org.jboss.mq.SpySession.sendMessage (SpySession.java:562) at org.jboss.mq.SpyTopicPublisher.internalPublish (SpyTopicPublisher.java:120) at org.jboss.mq.SpyTopicPublisher.publish (SpyTopicPublisher.java:68) at JMSTest.main(JMSTest.java:121) 17:20:58,683 INFO [Server] JBoss Release: JBoss- 3.0.3 CVSTag=JBoss_3_0_3 17:20:58,730 INFO [Server] Home Dir: E:\cvs\jboss-3.0.3-src\build\output\jboss-3 .0.3 17:20:58,730 INFO [Server] Home URL: file:/E:/cvs/jboss-3.0.3-src/build/output/j boss-3.0.3/ 17:20:58,730 INFO [Server] Library URL: file:/E:/cvs/jboss-3.0.3-src/build/outpu t/jboss-3.0.3/lib/ 17:20:58,745 INFO [Server] Patch URL: null 17:20:58,745 INFO [Server] Server Name: default 17:20:58,745 INFO [Server] Server Home Dir: E:\cvs\jboss-3.0.3-src\build\output\ jboss-3.0.3\server\default 17:20:58,745 INFO [Server] Server Home URL: file:/E:/cvs/jboss-3.0.3-src/build/o utput/jboss-3.0.3/server/default/ 17:20:58,745 INFO [Server] Server Data Dir: E:\cvs\jboss-3.0.3-src\build\output\ jboss-3.0.3\server\default\db 17:20:58,745 INFO [Server] Server Temp Dir: E:\cvs\jboss-3.0.3-src\build\output\ jboss-3.0.3\server\default\tmp 17:20:58,745 INFO [Server] Server Config URL: file:/E:/cvs/jboss-3.0.3-src/build /output/jboss-3.0.3/server/default/conf/ 17:20:58,745 INFO [Server] Server Library URL: file:/E:/cvs/jboss-3.0.3-src/buil d/output/jboss-3.0.3/server/default/lib/ 17:20:58,745 INFO [Server] Root Deployemnt Filename: jboss-service.xml 17:20:58,776 INFO [Server] Starting General Purpose Architecture (GPA)... 17:20:59,198 INFO [ServerInfo] Java version: 1.3.1_01,Sun Microsystems Inc. 17:20:59,198 INFO [ServerInfo] Java VM: Java HotSpot(TM) Client VM 1.3.1_01,Sun Microsystems Inc. 17:20:59,198 INFO [ServerInfo] OS-System: Windows NT 4.0,x86 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=376685&aid=620514&group_id=22866 --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] HEAD Build: numerous failure
If you run the build by hand with -Xmx640m does it function? This is what build.sh uses. Newer build.bat (coming soon) will also include this. --jason > -Original Message- > From: [EMAIL PROTECTED] [mailto:jboss- > [EMAIL PROTECTED]] On Behalf Of Sacha Labourey > Sent: Tuesday, October 08, 2002 5:07 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] HEAD Build: numerous failure > > build.bat > > > -Message d'origine- > > De : [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]De la part de > > Jason Dillon > > Envoye : mardi, 8 octobre 2002 10:37 > > A : [EMAIL PROTECTED] > > Objet : RE: [JBoss-dev] HEAD Build: numerous failure > > > > > > Using build.sh or build.bat? > > > > --jason > > > > > > On Tue, 8 Oct 2002, Sacha Labourey wrote: > > > > > I think the reason is the JVM size that is necessary (-Xmx): it must > be > > > higher probably. Which is why, doing it step by step succeeds: > > as numerous > > > steps are already done, the memory is simply exhausted later. > > > > > > > -Message d'origine- > > > > De : [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED]]De la part de > > > > Jason Dillon > > > > Envoye : lundi, 7 octobre 2002 23:07 > > > > A : Jboss-Dev > > > > Objet : Re: [JBoss-dev] HEAD Build: numerous failure > > > > > > > > > > > > What errors do you get specifically Sacha? > > > > > > > > --jason > > > > > > > > > > > > On Mon, 7 Oct 2002, Sacha Labourey wrote: > > > > > > > > > Hello, > > > > > > > > > > Is it just me? I am trying to compile jboss-all from HEAD > > (I did a fresh > > > > > checkout a few minutes ago) on windows 2000 and I get lots of > > > > errors which > > > > > change over time i.e the compiler (1.4.0) makes an exception > > > > and, if I start > > > > > again the build process, it goes further, ... then it is an > > RMI compiler > > > > > errror (couldn't read LOC header), then it is a set of silent > > > > break, etc. At > > > > > the end (after 4-5 restart, it is build successfuly) > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > --- > > > > This sf.net email is sponsored by:ThinkGeek > > > > Welcome to geek heaven. > > > > http://thinkgeek.com/sf > > > > ___ > > > > Jboss-development mailing list > > > > [EMAIL PROTECTED] > > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > > > > > > --- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > > > > --- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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] Design: Plans to decouple JBoss from log4j
It is too bad commons logging does not provide abstractions for a ContextStack or ContextMap similar to Log4j's NDC and MDC. These are valuable constructs. Do you know anyone on the commons logging team? --jason > -Original Message- > From: [EMAIL PROTECTED] [mailto:jboss- > [EMAIL PROTECTED]] On Behalf Of James Higginbotham > Sent: Friday, October 04, 2002 6:41 AM > To: [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] Design: Plans to decouple JBoss from log4j > > > > Do you know how you switch the LogFactory impl? I am > > guessing there is a > > system property, but I did not see anything obvious by looking at the > > javadocs. > > I've been using commons logging for a few months now - not bad at all.. > You drive the impl from a properties file called commons-logging, like > so: > > org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog > > If you put in log4j, just put the log4j properties or xml file in the > classpath so log4j can initialize when needed. The nice thing about > using this API is that they have done the factory work for you, allowing > jboss clients to use the simplelog they provide, a null log, jdk1.4 > (ugh), or whatever. Sure, you have that abstraction, but do you really > want to do the simple factory work? Probably not, as you guys have more > important things to do ;) > > James > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development --- 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] Design: Plans to decouple JBoss from log4j
Apparently several people have had trouble with jakarta-commons logging, including xdoclet; this got mentioned on their list: http://www.qos.ch/logging/thinkAgain.html Personally I'd be in favor of unwrapping log4j and using it asis. I'm not convinced that the debug/trace split buys us very much. david jencks On 2002.10.08 21:24:12 -0400 Jason Dillon wrote: > It is too bad commons logging does not provide abstractions for a > ContextStack or ContextMap similar to Log4j's NDC and MDC. These are > valuable constructs. > > Do you know anyone on the commons logging team? > > --jason > > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:jboss- > > [EMAIL PROTECTED]] On Behalf Of James > Higginbotham > > Sent: Friday, October 04, 2002 6:41 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] Design: Plans to decouple JBoss from log4j > > > > > > > Do you know how you switch the LogFactory impl? I am > > > guessing there is a > > > system property, but I did not see anything obvious by looking at > the > > > javadocs. > > > > I've been using commons logging for a few months now - not bad at > all.. > > You drive the impl from a properties file called commons-logging, like > > so: > > > > > org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog > > > > If you put in log4j, just put the log4j properties or xml file in the > > classpath so log4j can initialize when needed. The nice thing about > > using this API is that they have done the factory work for you, > allowing > > jboss clients to use the simplelog they provide, a null log, jdk1.4 > > (ugh), or whatever. Sure, you have that abstraction, but do you really > > want to do the simple factory work? Probably not, as you guys have > more > > important things to do ;) > > > > James > > > > > > --- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > --- > 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] Design: Plans to decouple JBoss from log4j
The major issue with Log4j that I have is size... it is huge. Commons is very small. If Log4j has a 20k footprint (or smaller) for client usage an dprovided a simple method to disable logging, then I would see no need for Commons Logging. Generally I am a pro-"just use log4j", but our own requirement for org.jboss.logging.Logger (for TRACE, removing need for huge jars on client and serialization) makes me wonder of the commons approache is really a better solution... backed by Log4j of course. What were the specific CL issues you had witrh XDoclet? --jason On Tue, 8 Oct 2002, David Jencks wrote: > Apparently several people have had trouble with jakarta-commons logging, > including xdoclet; this got mentioned on their list: > > http://www.qos.ch/logging/thinkAgain.html > > Personally I'd be in favor of unwrapping log4j and using it asis. I'm not > convinced that the debug/trace split buys us very much. > > david jencks > > On 2002.10.08 21:24:12 -0400 Jason Dillon wrote: > > It is too bad commons logging does not provide abstractions for a > > ContextStack or ContextMap similar to Log4j's NDC and MDC. These are > > valuable constructs. > > > > Do you know anyone on the commons logging team? > > > > --jason > > > > > > > -Original Message- > > > From: [EMAIL PROTECTED] [mailto:jboss- > > > [EMAIL PROTECTED]] On Behalf Of James > > Higginbotham > > > Sent: Friday, October 04, 2002 6:41 AM > > > To: [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] Design: Plans to decouple JBoss from log4j > > > > > > > > > > Do you know how you switch the LogFactory impl? I am > > > > guessing there is a > > > > system property, but I did not see anything obvious by looking at > > the > > > > javadocs. > > > > > > I've been using commons logging for a few months now - not bad at > > all.. > > > You drive the impl from a properties file called commons-logging, like > > > so: > > > > > > > > org.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog > > > > > > If you put in log4j, just put the log4j properties or xml file in the > > > classpath so log4j can initialize when needed. The nice thing about > > > using this API is that they have done the factory work for you, > > allowing > > > jboss clients to use the simplelog they provide, a null log, jdk1.4 > > > (ugh), or whatever. Sure, you have that abstraction, but do you really > > > want to do the simple factory work? Probably not, as you guys have > > more > > > important things to do ;) > > > > > > James > > > > > > > > > --- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > ___ > > > Jboss-development mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > > > > > > --- > > 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] Design: Plans to decouple JBoss from log4j
Unless there is a clear advantange to commons over the generalization Sacha did it is not worth the trouble to switch to an alternate logging wrapper. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 08, 2002 9:30 PM Subject: Re: [JBoss-dev] Design: Plans to decouple JBoss from log4j > The major issue with Log4j that I have is size... it is huge. Commons is > very small. If Log4j has a 20k footprint (or smaller) for client usage an > dprovided a simple method to disable logging, then I would see no need for > Commons Logging. > > Generally I am a pro-"just use log4j", but our own requirement for > org.jboss.logging.Logger (for TRACE, removing need for huge jars on client > and serialization) makes me wonder of the commons approache is really a > better solution... backed by Log4j of course. > > What were the specific CL issues you had witrh XDoclet? > > --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.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 build.sh: Executing: /home/lubega/jbossro/jboss-all/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger clean Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/build/../tools/etc/buildfragments/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found Total time: 6 seconds --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss3.2-Tomcat4.1.10
Scott M Stark wrote: > If you look at the Embedded usage in the JBoss service it is not doing much. > Being able to run off a sar with the minimum elements from tomcat would be > good, but I want to keep the ability to run with a pristine tomcat dist. Using the normal Tomcat startup code directly instead of Embedded should allow it, but what's the rationale behind that ? I'm asking since that's not the policy with Jetty. Why is Tomcat handled differently ? Remy --- 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 build.sh: Executing: /home/lubega/jbossro/jboss-all/tools/bin/ant -logger org.apache.tools.ant.NoBannerLogger -Dinstall.id=testbuild release Buildfile: build.xml _buildmagic:init: Trying to override old definition of task property BUILD FAILED file:/disk/orig/home/lubega/jbossro/jboss-all/build/../tools/etc/buildfragments/tools.ent:29: taskdef class xdoclet.modules.jmx.JMXDocletTask cannot be found Total time: 5 seconds --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBoss 3.0.3 Bug: typo in TransactionImpl + trying to change Tx inenlist exception
Title: JBoss 3.0.3 Bug: typo in TransactionImpl + trying to change Tx in enlist exception (using: JBoss-3.0.3-src) There is a typo in TransactionImpl disassociateCurrentThread(). tx.associateCurrentThread() is called instead of tx.disassociateCurrentThread() There is another more annoying bug/feature. When doing very intensive remote calls via statefull session, using the database with user managed transactions I often get this error: 2002-10-03 15:51:16,000 WARN [org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEventListener] in Enlisting tx, trying to change tx. illegal state: old: TransactionImpl:XidImpl [FormatId=257, GlobalId=brutus//233, BranchQual=], new: TransactionImpl:XidImpl [FormatId=257, GlobalId=brutus//234, BranchQual=], cel: org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEventListener@1f8d0a4 2002-10-03 15:51:16,000 ERROR [STDERR] java.lang.IllegalStateException: Trying to change Tx in enlist! 2002-10-03 15:51:16,000 ERROR [STDERR] at org.jboss.resource.connectionmanager.LocalTxConnectionManager$LocalConnectionEventListener.enlist(LocalTxConnectionManager.java:309) 2002-10-03 15:51:16,000 ERROR [STDERR] at org.jboss.resource.connectionmanager.LocalTxConnectionManager.managedConnectionReconnected(LocalTxConnectionManager.java:255) 2002-10-03 15:51:16,000 ERROR [STDERR] at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:534) 2002-10-03 15:51:16,000 ERROR [STDERR] at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:812) 2002-10-03 15:51:16,000 ERROR [STDERR] at org.jboss.resource.adapter.jdbc.local.LocalDataSource.getConnection(LocalDataSource.java:102) It only happens when there is severe concurent use of the database. But it does happen a lot. What happens is this: Thread 1: userTransaction.begin(); Connection c=ds.getConnection(); // lets call this Connection1 // ... use connection c.close(); // close connection // now don't commit transaction yet Thread 2: userTransaction.begin(); Connection c=ds.getConnection(); // KABOOOM! Exception happens here. Exception happened because Connection1 was trying to be returned - the same connection that was used by another thread. In the time between returning a connection to the pool and calling commit on UserTransaction the same connection is checked out to another thread. I played around with connector package and managed to reduce the problem to virtually zero occurances. Now, the changes to the code I did are quite crude and probably aren't in the spirit of code separation as was envisaged (talk about casting interface to actual implementation and some classes made public) so they are not suitable to be commited to cvs. The solution depends on InternalManagedConnectionPool.getConnection method detecting in advance the condition that causes 'trying to change Tx in enlist' exception. If ManagedConection is in 'transaction collision' we simply find another one that is not. To sum up the patch: - The main code is in InternalManagedConnectionPool.getConnection In order to make this code work and in order for the whole code to compile other changes had to be made: - method void setBaseConnectionManager2(BaseConnectionManager2 bcm) was added to ManagedConnectionPool interface. - It had to be implemented on several places in JBossManagedConnectionPool.java - It was implemented in InternalManagerConnectionPool - Calls to setBaseConnectionManager2 had to be added in BaseConnectionManager2 to pass reference to LocalTxConnectionManager. - LocalTxConnectionManager.LocalConnectionEventListener has new method: boolean isTransactionCollisionFree() This quick patch is posted here more as an example of the kind of checking that needs to be done in order to make the exception go away. regards, -Marko connector-quick-n-dirty-patch.zip Description: Binary data
