[JBoss-dev] Automated JBoss(Branch_3_0) Testsuite Results: 30-June-2002
Number of tests run: 668
Successful tests: 667
Errors:0
Failures: 1
[time of test: 30 June 2002 0:27 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.1.5]
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] Automated JBoss(Branch_3_0) Testsuite Results: 30-June-2002
Number of tests run: 668
Successful tests: 668
Errors:0
Failures: 0
[time of test: 30 June 2002 12:27 GMT]
[java.version: 1.3.1]
[java.vendor: Apple Computer, Inc.]
[java.vm.version: 1.3.1]
[java.vm.name: Java HotSpot(TM) Client VM]
[java.vm.info: mixed mode]
[os.name: Mac OS X]
[os.arch: ppc]
[os.version: 10.1.5]
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!
HURRAY - everything worked!
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-559232 ] RC3 CMP 2 create table exception
Bugs item #559232, was opened at 2002-05-22 17:09 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=559232group_id=22866 Category: JBossCMP Group: v3.1 Status: Open Resolution: Postponed Priority: 5 Submitted By: Rik de Groot (synotix) Assigned to: Dain Sundstrom (dsundstrom) Summary: RC3 CMP 2 create table exception Initial Comment: I recently switched from Jboss 3RC1 to RC2. In the standardjbosscmp-jdbc.xml I have the following settings create-tabletrue/create-table remove-tablefalse/remove-table When I deployed an EAR file on RC2, the instance logs that the table exists, but carries on with the deployment. The new RC3 throws an exception and doesnt deploy at all. When I set the create-table on false the EAR deploys normally. Rik. 2002-05-22 11:11:24,002 ERROR [org.jboss.ejb.EjbModule] Starting failed org.jboss.deployment.DeploymentException: Error while creating table; - nested throwable: (java.sql.SQLException: General error: Table 'votebean' already exists) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.createTable(JDBCStartCommand.ja va:190) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStartCommand.execute(JDBCStartCommand.java:8 4) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.start(JDBCStoreManager.java:384 ) at org.jboss.ejb.plugins.CMPPersistenceManager.start(CMPPersistenceManager.java:19 8) at org.jboss.ejb.EntityContainer.start(EntityContainer.java:376) at org.jboss.ejb.Container.invoke(Container.java:793) at org.jboss.ejb.EntityContainer.invoke(EntityContainer.java:1055) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:8 67) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:339) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatche r.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy18.start(Unknown Source) at org.jboss.ejb.EjbModule.startService(EjbModule.java:440) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatche r.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:8 67) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:339) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatche r.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy5.start(Unknown Source) at org.jboss.ejb.EJBDeployer.start(EJBDeployer.java:394) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:692) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:685) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:527) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:490) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatche r.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy4.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.j ava:405) at org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeploymentSc anner.java:586) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.jav a:465) at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDep loymentScanner.java:237) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:162) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatche r.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:8 67) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:339) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispatche r.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:491) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy3.start(Unknown Source) at org.jboss.deployment.SARDeployer.start(SARDeployer.java:276) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:692) at
[JBoss-dev] Dreamweaver MX: njar vs. expanded directories?
Let us say you are using a tool like Macromedia Dreamweaver UltraDev/MX and their LiveUpdate feature. This is where you are using a wysiwyg HTML/JSP editor and you can click a button, it uploads a temporary version of the file to the server, it invokes the JSP generating the page, gets the results, correlates the generated page to the original JSP, and displays as a web page. You can fill in data, press buttons, follow hyperlinks etc. You are working with a live page. Very cool and useful. But you have to be able to copy/ftp the JSP to a real directory. Now it was a mildly annoying, under JBoss 2.4.x, that with the hot deploy the temporary directory name could keep changing because Dreamweaver didn't know how to deal with it, but it worked. So the question is, how do I do that now with the .war appearing to be bundled up? Where would I copy the JSP? Fred. --- 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] Dreamweaver MX: njar vs. expanded directories?
This should really be posted to jboss-user or the forums - jboss-dev is for discussion amongst developers of (not 'on') JBoss. It's a BAD idea for any tool to be second guessing where a WebContainer will be unpacking it's wars - because the spec does not say anything about it. In fact the WebContainer may just run them packed. If your tool will only work with unpacked dirs - then deploy your war unpacked (a dir hierarchy called e.g. my.war that mirrors the packed tree), and write your files back into this. I THINK that Jasper will spot the changes and react accordingly. Jules Frederick N. Brier wrote: Let us say you are using a tool like Macromedia Dreamweaver UltraDev/MX and their LiveUpdate feature. This is where you are using a wysiwyg HTML/JSP editor and you can click a button, it uploads a temporary version of the file to the server, it invokes the JSP generating the page, gets the results, correlates the generated page to the original JSP, and displays as a web page. You can fill in data, press buttons, follow hyperlinks etc. You are working with a live page. Very cool and useful. But you have to be able to copy/ftp the JSP to a real directory. Now it was a mildly annoying, under JBoss 2.4.x, that with the hot deploy the temporary directory name could keep changing because Dreamweaver didn't know how to deal with it, but it worked. So the question is, how do I do that now with the .war appearing to be bundled up? Where would I copy the JSP? Fred. --- 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-575767 ] Bug in startup
Bugs item #575767, was opened at 2002-06-30 14:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=575767group_id=22866 Category: JBossServer Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Turner (sgturner) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in startup Initial Comment: This is a bug in 3.0.1RC1. OS = Win2000 JDK=1.3 I have an ear file whose meta-inf directory contains a jboss-app.xml file. The jboss-app.xml file references a sar file which is located in the root of the ear file. The meta-inf/manifest.mf file references a dependency library jar file called common.jar in the class path. common.jar is also located in the root of the ear file. The MBean referenced in the sar file uses a class (InvokerProperties) that is located in common.jar. On startup, there is a error message that complains that the sar can not find InvokerProperties. The classes in my war file are able to locate the classes in common.jar, should the same be true for the MBean class in the sar? url=file:/C:/JBoss/build/output/JBoss/server/default/tmp/deploy/server/default/deploy/Application.ear/62.Ap plication.ear-contents/TesFramework.sar } 2002-06-30 14:12:55,792 DEBUG [org.jboss.system.ServiceCreator] About to create bean: TiburonFramework:service=PropertiesCache 2002-06-30 14:12:55,792 DEBUG [org.jboss.system.ServiceCreator] code: com.tes.framework.base.mbeans.PropertiesCache 2002-06-30 14:12:55,802 ERROR [org.jboss.deployment.MainDeployer] could not create deployment: file:/C:/JBoss/build/output/JBoss/server/default/tmp/deploy/server/default/deploy/Application.ear/62.Applic ation.ear-contents/TesFramework.sar java.lang.NoClassDefFoundError: com/tes/framework/base/common/InvokerProperties at java.lang.Class.getMethods0(Native Method) at java.lang.Class.getMethods(Class.java:742) at org.jboss.mx.metadata.StandardMetaData.build(StandardMetaData.java:65) at org.jboss.mx.metadata.MBeanCapability.of(MBeanCapability.java:63) at org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean(BasicMBeanRegistry.java:178) at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:949) at org.jboss.mx.server.MBeanServerImpl.registerMBean(MBeanServerImpl.java:896) at org.jboss.mx.server.MBeanServerImpl.createMBean(MBeanServerImpl.java:268) at org.jboss.system.ServiceCreator.install(ServiceCreator.java:86) at org.jboss.system.ServiceConfigurator.internalInstall(ServiceConfigurator.java:167) at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:130) at org.jboss.system.ServiceController.install(ServiceController.java:217) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=575767group_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] Dreamweaver MX: njar vs. expanded directories?
Sorry Jules, I wasn't sure where to post it. But I was posting this more as a design discussion and a continuation of an earlier post about the njar protocol and whether it was really a good idea. Not that it isn't slick piece of encapsulation. I will try your recommendation and copy the .jsp into the my.war directory. As far as the tool, Ultradev/Drumbeat/MX, I believe its Live Data feature predates the use of .war(s) to bundle .jsp(s) and servlets. But even that isn't the issue. Easy to use GUI tools lower development costs. Just because the spec says we are allowed to hide how we access an archive, doesn't mean its a good idea not to provide an interface by which development tools can interact with the container. If the above approach doesn't work, maybe we need to design one that does. If it does, we should document it and submit as a standard. Fred. At 05:29 PM 6/30/2002, Jules Gosnell wrote: This should really be posted to jboss-user or the forums - jboss-dev is for discussion amongst developers of (not 'on') JBoss. It's a BAD idea for any tool to be second guessing where a WebContainer will be unpacking it's wars - because the spec does not say anything about it. In fact the WebContainer may just run them packed. If your tool will only work with unpacked dirs - then deploy your war unpacked (a dir hierarchy called e.g. my.war that mirrors the packed tree), and write your files back into this. I THINK that Jasper will spot the changes and react accordingly. Jules Frederick N. Brier wrote: Let us say you are using a tool like Macromedia Dreamweaver UltraDev/MX and their LiveUpdate feature. This is where you are using a wysiwyg HTML/JSP editor and you can click a button, it uploads a temporary version of the file to the server, it invokes the JSP generating the page, gets the results, correlates the generated page to the original JSP, and displays as a web page. You can fill in data, press buttons, follow hyperlinks etc. You are working with a live page. Very cool and useful. But you have to be able to copy/ftp the JSP to a real directory. Now it was a mildly annoying, under JBoss 2.4.x, that with the hot deploy the temporary directory name could keep changing because Dreamweaver didn't know how to deal with it, but it worked. So the question is, how do I do that now with the .war appearing to be bundled up? Where would I copy the JSP? Fred. --- 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] I can't believe france is out of the world cup
|-Original Message- |From: Emerson Cargnin [mailto:[EMAIL PROTECTED]] |Sent: Sunday, June 30, 2002 6:28 AM |To: 'marc fleury '; '[EMAIL PROTECTED] ' |Cc: 'tre-sc.gov.br'; [EMAIL PROTECTED] |Subject: RE: [JBoss-dev] I can't believe france is out of the world cup | | | É PENTA BRASIL!!! | |I even caught myself cheering for Germany for awhile these guys really |wanted it and it. They were really pounding and deserved to win, they |really wanted it bad, but hey it's the way it goes, | |Thanks, we deserved dude, I don't know about that, I really thought the Germans were impressive and that goalie you got, that marcos guy he is a fucking star. Your 3 strikers up there, rarely pass among each other, they are all on their own, but when they pass they score, Germany's team was full of young guys, I hear the 2006 cup will be germany, I would put my money on germany then, well if france isn't back in top place that is :) Anyway, it was a great game, great goalie great strikers, it was fun, marcf | |mrcf | | | | |--- |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-575815 ] CMR and commit option A
Bugs item #575815, was opened at 2002-07-01 13:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=575815group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Stephen Coy (scoy) Assigned to: Nobody/Anonymous (nobody) Summary: CMR and commit option A Initial Comment: I think that Dain's fix to properly report java.lang.IllegalStateException when accessing CMR collections outside of their original transaction is broken when Commit Option A is in effect. I have a User entity bean that has a many-to-many relationship with a Role entity bean. The User bean has a method which iterates over the roles looking for a particular attribute (which we should probably re-implement as an ejbSelect method). When the bean is configured with Commit Option A, the first access of this method works fine, subsequent accesses throw a java.lang.IllegalStateException containing the text A CMR collection may only be used within the transction in which it was created. Reverting the configuration to the default Commit Option B works OK. The code was built from Branch_3_0 as of about four hours ago, although the problem manifested itself toward the end of last week. I'm using the current Apple 1.3.1 JVM for what it's worth. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=575815group_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] Build broken?
Is it just me or is HEAD broken? When I do a fresh check out and build I get the following build errors. [javac] Compiling 437 source files to /home/dain/work/jboss/jboss-all/jmx/ou tput/classes [execmodules] /home/dain/work/jboss/jboss-all/jmx/src/main/org/jboss/mx/util/MBe anInstaller.java:79: cannot resolve symbol [execmodules] symbol : method getVersions () [execmodules] location: class org.jboss.mx.loading.MBeanElement [execmodules] if (element.getVersions() == null) [execmodules] ^ [execmodules] /home/dain/work/jboss/jboss-all/jmx/src/main/org/jboss/mx/util/MBe anInstaller.java:125: cannot resolve symbol [execmodules] symbol : method getVersions () [execmodules] location: class org.jboss.mx.loading.MBeanElement [execmodules] MLetVersion newVersion = new MLetVersion(element.getVersion s()); [execmodules]^ [execmodules] /home/dain/work/jboss/jboss-all/jmx/src/main/org/jboss/mx/util/MBe anInstaller.java:149: cannot resolve symbol [execmodules] symbol : method getVersions () [execmodules] location: class org.jboss.mx.loading.MBeanElement [execmodules] if (element.getVersions() != null) [execmodules] ^ [execmodules] /home/dain/work/jboss/jboss-all/jmx/src/main/org/jboss/mx/util/MBe anInstaller.java:150: cannot resolve symbol [execmodules] symbol : method getVersions () [execmodules] location: class org.jboss.mx.loading.MBeanElement [execmodules] valueMap.put(VERSIONS, element.getVersions()); [execmodules]^ --- 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
