[JBoss-dev] Automated JBoss Testsuite Results: 16-April-2002
Number of tests run: 563 Successful tests: 527 Errors:30 Failures: 6 [time of test: 16 April 2002 7:19 GMT] [java.version: 1.3.1_02] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1_02-b02] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/sun_jdk131_02 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/catalina/src/main/org/jboss/test/tomcat/servlet PrintClassLoaders.java
User: starksm
Date: 02/04/15 23:34:11
Modified:catalina/src/main/org/jboss/test/tomcat/servlet
PrintClassLoaders.java
Log:
Merge the JBoss_3_0_0_RC1 changes back into main
Revision ChangesPath
1.2 +2 -2
contrib/catalina/src/main/org/jboss/test/tomcat/servlet/PrintClassLoaders.java
Index: PrintClassLoaders.java
===
RCS file:
/cvsroot/jboss/contrib/catalina/src/main/org/jboss/test/tomcat/servlet/PrintClassLoaders.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- PrintClassLoaders.java11 Feb 2002 23:02:15 - 1.1
+++ PrintClassLoaders.java16 Apr 2002 06:34:11 - 1.2
@@ -9,8 +9,8 @@
/**
*
- * @author [EMAIL PROTECTED]
- * @version $Revision: 1.1 $
+ * @author [EMAIL PROTECTED]
+ * @version $Revision: 1.2 $
*/
public class PrintClassLoaders extends HttpServlet
{
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/catalina/src/main/org/jboss/web/catalina EmbeddedCatalinaServiceSX.java
User: starksm
Date: 02/04/15 23:34:11
Modified:catalina/src/main/org/jboss/web/catalina
EmbeddedCatalinaServiceSX.java
Log:
Merge the JBoss_3_0_0_RC1 changes back into main
Revision ChangesPath
1.9 +24 -2
contrib/catalina/src/main/org/jboss/web/catalina/EmbeddedCatalinaServiceSX.java
Index: EmbeddedCatalinaServiceSX.java
===
RCS file:
/cvsroot/jboss/contrib/catalina/src/main/org/jboss/web/catalina/EmbeddedCatalinaServiceSX.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- EmbeddedCatalinaServiceSX.java12 Apr 2002 01:10:34 - 1.8
+++ EmbeddedCatalinaServiceSX.java16 Apr 2002 06:34:11 - 1.9
@@ -9,6 +9,7 @@
import java.io.InputStream;
import java.io.IOException;
import java.io.File;
+import java.io.FileInputStream;
import java.io.PrintWriter;
import java.net.UnknownHostException;
import java.net.URL;
@@ -32,6 +33,7 @@
import org.jboss.deployment.DeploymentException;
import org.jboss.metadata.WebMetaData;
import org.jboss.security.SecurityDomain;
+import org.jboss.util.file.JarUtils;
import org.jboss.web.AbstractWebContainer;
import org.jboss.web.AbstractWebContainer.WebDescriptorParser;
import org.jboss.web.WebApplication;
@@ -67,7 +69,7 @@
@see org.apache.catalina.startup.Embedded
@author [EMAIL PROTECTED]
- @version $Revision: 1.8 $
+ @version $Revision: 1.9 $
*/
public class EmbeddedCatalinaServiceSX extends AbstractWebContainer
implements EmbeddedCatalinaServiceSXMBean
@@ -183,6 +185,22 @@
log.info(deploy, ctxPath=+ctxPath+, warUrl=+warUrl);
URL url = new URL(warUrl);
+ // Catalina needs a war in a dir so extract the nested war
+ if( url.getProtocol().equals(njar) )
+ {
+ url = org.jboss.net.protocol.njar.Handler.njarToFile(url);
+ log.debug(Extracted war from njar, warUrl=+url);
+ File warFile = new File(url.getFile());
+ String warFileName = warFile.getName();
+ warFileName = warFileName.substring(0, warFileName.length()-3);
+ warFileName += war;
+ File warDir = new File(warFile.getParent(), warFileName);
+ FileInputStream warStream = new FileInputStream(warFile);
+ JarUtils.unjar(warStream, warDir);
+ warStream.close();
+ log.debug(Unpacked war into dir: +warDir);
+ url = warDir.toURL();
+ }
createWebContext(appInfo, url, webAppParser);
log.debug(Initialized: +appInfo);
}
@@ -193,10 +211,14 @@
{
// find the javax.servlet.ServletContext in the repository
WebApplication appInfo = getDeployedApp(warUrl);
+ if( appInfo == null )
+ log.debug(performUndeploy, no WebApplication found for URL +warUrl);
+
+ log.info(undeploy, ctxPath=+appInfo.getMetaData().getContextRoot()+,
warUrl=+warUrl);
Context context = null;
if( appInfo != null )
context = (Context) appInfo.getAppData();
-
+
if(context == null)
throw new DeploymentException(URL + warUrl + is not deployed);
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/catalina/src/resources jboss-service.xml
User: starksm Date: 02/04/15 23:34:12 Modified:catalina/src/resources jboss-service.xml Log: Merge the JBoss_3_0_0_RC1 changes back into main Revision ChangesPath 1.4 +5 -2 contrib/catalina/src/resources/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/contrib/catalina/src/resources/jboss-service.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- jboss-service.xml 12 Apr 2002 01:31:28 - 1.3 +++ jboss-service.xml 16 Apr 2002 06:34:12 - 1.4 @@ -1,7 +1,10 @@ ?xml version=1.0 encoding=UTF-8? -!-- Set this to the location of the Tomcat-4.x dist -- +!-- Set catalina.home to the location of the Tomcat-4.x dist. +The default value is that of the JBoss/Catalina bundle where the +jakarta-tomcat-4.0.3-LE-jdk14 is included as jboss_dist/catalina + -- !DOCTYPE server [ - !ENTITY catalina.home /usr/local/Java/servlets/jakarta-tomcat-4.0.3 + !ENTITY catalina.home ../catalina ] !-- The service configuration for the embedded Tomcat4 web container ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 16-April-2002
Number of tests run: 563 Successful tests: 527 Errors:32 Failures: 4 [time of test: 16 April 2002 8:22 GMT] [java.version: 1.4.0] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.4.0-b92] [java.vm.name: Java HotSpot(TM) Server VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/sun_j2sdk140 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Contrib: db2-service.xml
Hello, I did a cvs check out this morning, and I could not find any db2-service.xml in jboss-all\connector\src\etc\example-config. So here is the one I use. Regards, Jerome. PS: I do not know if it is the right place to post such a file, sorry for that. * * * View thread online: http://main.jboss.org/thread.jsp?forum=66thread=13030 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Compile problem with iiop
I am not getting the error. Default build works for me on a very similar environment: linux kernel 2.2.19, jdk 1.3.1_03 from sun. Really weird... Claudio run into something like this on NT. I have never seen it on linux. Best, Francisco On Tue, 16 Apr 2002, David Jencks wrote: Anyone else getting this from the iiop module? I have linux 2.4.16, jdk 1.3.1_03 from sun. Any advice? compile-rmi: Verify has been turned on. RMI Compiling 1 class to /usr/java/jboss/co12/jboss-all/iiop/output/classes IIOP has been turned on. java.lang.UnsatisfiedLinkError: hasStaticInitializer at com.sun.corba.ee.internal.io.ObjectStreamClass.hasStaticInitializer(Native Method) at com.sun.corba.ee.internal.io.ObjectStreamClass._computeSerialVersionUID(ObjectStreamClass.java:943) at com.sun.corba.ee.internal.io.ObjectStreamClass.init(ObjectStreamClass.java:459) at com.sun.corba.ee.internal.io.ObjectStreamClass.lookupInternal(ObjectStreamClass.java:139) at com.sun.corba.ee.internal.io.ObjectStreamClass.lookup(ObjectStreamClass.java:96) at com.sun.corba.ee.internal.io.ObjectStreamClass.lookupInternal(ObjectStreamClass.java:133) at com.sun.corba.ee.internal.io.ObjectStreamClass.lookup(ObjectStreamClass.java:96) at com.sun.corba.ee.internal.io.ObjectStreamClass.getSerialVersionUID(ObjectStreamClass.java:159) at com.sun.corba.ee.internal.util.RepositoryId.clinit(RepositoryId.java:150) at sun.rmi.rmic.iiop.IDLNames.convertToISOLatin1(IDLNames.java:139) at sun.rmi.rmic.iiop.IDLNames.getClassOrInterfaceName(IDLNames.java:233) at sun.rmi.rmic.iiop.CompoundType.init(CompoundType.java:644) at sun.rmi.rmic.iiop.InterfaceType.init(InterfaceType.java:104) at sun.rmi.rmic.iiop.RemoteType.init(RemoteType.java:115) at sun.rmi.rmic.iiop.RemoteType.forRemote(RemoteType.java:79) at sun.rmi.rmic.iiop.StubGenerator.getTopType(StubGenerator.java:119) at sun.rmi.rmic.iiop.Generator.generate(Generator.java:262) at sun.rmi.rmic.Main.doCompile(Main.java:526) at sun.rmi.rmic.Main.compile(Main.java:133) at java.lang.reflect.Method.invoke(Native Method) at org.apache.tools.ant.taskdefs.rmic.SunRmic.execute(SunRmic.java:89) at org.apache.tools.ant.taskdefs.Rmic.execute(Rmic.java:397) 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) error: An error has occurred in the compiler; please file a bug report (http://java.sun.com/cgi-bin/bugreport.cgi). 1 error ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-541424 ] Unpacked deploy of ear fails
Bugs item #541424, was opened at 2002-04-09 08:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=541424group_id=22866 Category: JBossMX Group: v3.0 Rabbit Hole Status: Open Resolution: Fixed Priority: 5 Submitted By: Erik Turesson (eritu) Assigned to: Nobody/Anonymous (nobody) Summary: Unpacked deploy of ear fails Initial Comment: I am trying to deploy an anpacked ear file using the latest from CVS. I use Windows 2000 and JDK 1.3.1_02 I have the directorystructure that I have submited a image file. Jboss is not deploying my ear. If I try deploying it by hand using the MainDeployer I receive the following printouts: 2002-04-09 08:24:47,441 INFO [org.jboss.deployment.MainDeployer] Starting deployment of package: file:/c:/Program/Jboss- jetty/server/default/deploy/webbpublication.ear/META- INF/application.xml 2002-04-09 08:24:47,441 DEBUG [org.jboss.deployment.MainDeployer] Starting deployment (init step) of package at: file:/c:/Program/Jboss- jetty/server/default/deploy/webbpublication.ear/META- INF/application.xml 2002-04-09 08:24:47,491 DEBUG [org.jboss.deployment.MainDeployer] No deployer found for url: file:/c:/Program/Jboss- jetty/server/default/deploy/webbpublication.ear/META- INF/application.xml 2002-04-09 08:24:47,491 DEBUG [org.jboss.deployment.MainDeployer] Watching new file: file:/c:/Program/Jboss- jetty/server/default/deploy/webbpublication.ear/META- INF/application.xml 2002-04-09 08:24:47,491 INFO [org.jboss.deployment.MainDeployer] Deployment of package: file:/c:/Program/Jboss- jetty/server/default/deploy/webbpublication.ear/META- INF/application.xml is waiting for an appropriate deployer. My application.xml file looks like this. ?xml version=1.0 encoding=UTF-8? !DOCTYPE application PUBLIC '-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN' 'file:///jboss/lib/dtd/application_1_3.dtd' application display-nameWebb Publication/display-name descriptionApplication description/description module web web-uriwebbpublication.war/web-uri context-root/webbpublication/*/context-root /web /module module ejbsequence.jar/ejb /module module ejbpublication.jar/ejb /module module ejbconfiguration.jar/ejb /module module ejblayout.jar/ejb /module /application If I have the ear in a packed format it is deployed fine. /Erik Turesson -- Comment By: Erik Turesson (eritu) Date: 2002-04-16 14:52 Message: Logged In: YES user_id=143667 It seems to my that this have been corrected. Now it works with that latest in CVS -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=541424group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Oracle claims to be our partner
http://www.oracle.com/corporate/press/index.html?1279885.html and we didn't even know about it! how about that... these people are incredible, I need someone like that JBoss partners with AOL and BellSouth to deliver the infrastructure of tomorrow and say it with a straight face. The world is coming to an end. marcf x Marc Fleury, Ph.D President and CEO JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: [JBoss-user] Oracle claims to be our partner
On a related note - I downloaded their OC4J app server (just being curious, not really straying from JBoss) in mid-March and it appears to be Orion underneath. All the xml config files are orion-this and orion-that. -- marc fleury wrote: http://www.oracle.com/corporate/press/index.html?1279885.html and we didn't even know about it! how about that... these people are incredible, I need someone like that JBoss partners with AOL and BellSouth to deliver the infrastructure of tomorrow and say it with a straight face. The world is coming to an end. marcf x Marc Fleury, Ph.D President and CEO JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RC1 release branch occuring at 00:00
Yes, the iiop stuff is now generated by a default build. I have changed a couple of files (jboss-services.xml and run.sh) in order to run it. Please see the patchfile attached. Should I commit these changes? Cheers, Francisco PS: David Jencks is getting a very strange error from rmic. Are you also getting this error? On Mon, 15 Apr 2002, Jason Dillon wrote: I setup the build system to include jboss.net iiop in the default builds. Please look at the configuration that is generated and make sure that iiop stuff will work with a default build. Note, this is on HEAD. --jason Francisco Reverbel wrote: Will it include the iiop stuff? Jason and I were talking about making it part of the default build. User feedback would be a good thing for me at this point. Best, Francisco On Sun, 14 Apr 2002, Scott M Stark wrote: I'm creating the 3.0 branch for the RC1 release at midnight (GMT-0700). Do not commit any changes to main after 22:00 -0700 until the branch is announced to be complete. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development Index: server/src/etc/conf/default/jboss-service.xml === RCS file: /cvsroot/jboss/jboss/src/etc/conf/default/jboss-service.xml,v retrieving revision 1.44 diff -u -r1.44 jboss-service.xml --- server/src/etc/conf/default/jboss-service.xml 14 Apr 2002 19:42:56 - 1.44 +++ server/src/etc/conf/default/jboss-service.xml 16 Apr 2002 16:17:34 - @@ -110,7 +110,7 @@ !-- -- !-- RMI/IIOP -- !-- -- - !-- Uncomment to use the iiop module with JacORB + mbean code=org.jboss.iiop.CorbaORBService name=jboss:service=CorbaORB attribute name=ORBClassorg.jacorb.orb.ORB/attribute @@ -120,7 +120,6 @@ attribute name=PortableInterceptorInitializerClassorg.jboss.ejb.plugins.iiop.server.CodebaseInterceptorInitializer/attribute attribute name=Verbosity1/attribute /mbean - -- !-- -- !-- The deployers... -- Index: system/src/bin/run.sh === RCS file: /cvsroot/jboss/jboss-system/src/bin/run.sh,v retrieving revision 1.5 diff -u -r1.5 run.sh --- system/src/bin/run.sh 5 Apr 2002 00:00:12 - 1.5 +++ system/src/bin/run.sh 16 Apr 2002 16:17:34 - @@ -110,7 +110,17 @@ fi fi -# Setup JBoss sepecific properties +# If the JVM is not HOTSPOT enabled, then assume it is an IBM JVM +# (IBM JVMs need jacorb.jar in the classpath) +if [ x$HAS_HOTSPOT = x ]; then +JBOSS_CLASSPATH=$JBOSS_CLASSPATH:$JBOSS_HOME/lib/jacorb.jar +fi + +# Use JacORB as the default ORB +JAVA_OPTS=$JAVA_OPTS -Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB +JAVA_OPTS=$JAVA_OPTS -Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton + +# Setup JBoss specific properties JAVA_OPTS=$JAVA_OPTS -Dprogram.name=$PROGNAME # For Cygwin, switch paths to Windows format before running java
RE: [JBoss-dev] RC1 release branch occuring at 00:00
Can you pull IIOP out of jboss-services.xml and put in in a separate deployable service xml file like cluster-service.xml, etc..? I think this would be better. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Francisco Reverbel Sent: Tuesday, April 16, 2002 12:47 PM To: Jason Dillon Cc: Scott M Stark; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RC1 release branch occuring at 00:00 Yes, the iiop stuff is now generated by a default build. I have changed a couple of files (jboss-services.xml and run.sh) in order to run it. Please see the patchfile attached. Should I commit these changes? Cheers, Francisco PS: David Jencks is getting a very strange error from rmic. Are you also getting this error? On Mon, 15 Apr 2002, Jason Dillon wrote: I setup the build system to include jboss.net iiop in the default builds. Please look at the configuration that is generated and make sure that iiop stuff will work with a default build. Note, this is on HEAD. --jason Francisco Reverbel wrote: Will it include the iiop stuff? Jason and I were talking about making it part of the default build. User feedback would be a good thing for me at this point. Best, Francisco On Sun, 14 Apr 2002, Scott M Stark wrote: I'm creating the 3.0 branch for the RC1 release at midnight (GMT-0700). Do not commit any changes to main after 22:00 -0700 until the branch is announced to be complete. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RC1 release branch occuring at 00:00
Yes, I think that can be done. Must somehow ensure it will be deployed before any bean. I don't know how to do this, but it should be possible (cluster service has the same requirement). I´ll look into it. Thanks, Francisco On Tue, 16 Apr 2002, Bill Burke wrote: Can you pull IIOP out of jboss-services.xml and put in in a separate deployable service xml file like cluster-service.xml, etc..? I think this would be better. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Francisco Reverbel Sent: Tuesday, April 16, 2002 12:47 PM To: Jason Dillon Cc: Scott M Stark; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RC1 release branch occuring at 00:00 Yes, the iiop stuff is now generated by a default build. I have changed a couple of files (jboss-services.xml and run.sh) in order to run it. Please see the patchfile attached. Should I commit these changes? Cheers, Francisco PS: David Jencks is getting a very strange error from rmic. Are you also getting this error? On Mon, 15 Apr 2002, Jason Dillon wrote: I setup the build system to include jboss.net iiop in the default builds. Please look at the configuration that is generated and make sure that iiop stuff will work with a default build. Note, this is on HEAD. --jason Francisco Reverbel wrote: Will it include the iiop stuff? Jason and I were talking about making it part of the default build. User feedback would be a good thing for me at this point. Best, Francisco On Sun, 14 Apr 2002, Scott M Stark wrote: I'm creating the 3.0 branch for the RC1 release at midnight (GMT-0700). Do not commit any changes to main after 22:00 -0700 until the branch is announced to be complete. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RC1 release branch occuring at 00:00
Yes, seperate this into a seperate service. I don't have a problem compiling cvs head with: [starksm@banshee build]$ uname -a Linux banshee.starkinternational.com 2.4.18-6mdk #1 Fri Mar 15 02:59:08 CET 2002 i686 unknown [starksm@banshee build]$ java -version java version 1.3.1_03 Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_03-b03) Java HotSpot(TM) Client VM (build 1.3.1_03-b03, mixed mode) Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Bill Burke [EMAIL PROTECTED] To: Francisco Reverbel [EMAIL PROTECTED]; Jason Dillon [EMAIL PROTECTED] Cc: Scott M Stark [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, April 16, 2002 10:07 AM Subject: RE: [JBoss-dev] RC1 release branch occuring at 00:00 Can you pull IIOP out of jboss-services.xml and put in in a separate deployable service xml file like cluster-service.xml, etc..? I think this would be better. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Francisco Reverbel Sent: Tuesday, April 16, 2002 12:47 PM To: Jason Dillon Cc: Scott M Stark; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RC1 release branch occuring at 00:00 Yes, the iiop stuff is now generated by a default build. I have changed a couple of files (jboss-services.xml and run.sh) in order to run it. Please see the patchfile attached. Should I commit these changes? Cheers, Francisco PS: David Jencks is getting a very strange error from rmic. Are you also getting this error? ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: Bomb the bug parade! was AW: [JBoss-dev] Thread deadlock in class loader
Sounds like a good idea. When you get your example done post it here. g On Thu, 11 Apr 2002 16:10:54 -0500, G. Reno wrote: Create a real world, simple, reproducible, vendor-independent example that demonstrates the problem. Bring others on board using this, explain it to the press, and then have everyone together apply pressure to SUN to correct their faulty implementation. _ View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12688 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] org.jboss.test.testbeancluster.test.BeanUnitTestCase
The clustering BeanUnitTestCase is not running in any JDK configuration and appears to be misconfigured. Look at http://lubega.com/testarchive/sun_jdk131_02/ for example. Please fix this or remove the test until it is ready. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Multiple Instance - continued
You guys probably have more to worry about right now, with RC1 and all, but: A while back there was a thread regarding the whole 'multiple instance detection' thing - where the problem of managing multiple listeners vying for the same port was discussed (JNDI, RMI, etc). Was there any resolution or direction? This is of interest to me as we do often have multiple JBosses running on a single box (to make it more challenging - we share a box with another group that has pure RMI apps running on it..). One of the options was a 'port manager' that would (if I understand) forward traffic (like a proxy) to the correct port for the requested service. 1) To do this, I imagine the 'port mgr' would have to be able to sniff the incoming bytestream and determine the requested service by interrogating the content. This imposes the restriction that only one instance of a service (service being wire protocol - JNDI, HTTP, RMI, etc) can be routed, since there probably would be no unambiguous way to differentiate between two HTTP streams (for instance). 2) The port mgr (MBean?) would somehow need to be aware of the 'real' ports being used within the JBoss process space by the managed services. Would the MBean Notification mechanism suffice? Where each MBean that owns a "managed" port would send a notification with the port/s onwhich itit is listening. Or, as (I think) Marc suggested, a P2P solution like JXTA (which may be a better solution than JMX Notifications?). Or a config file (less than optimal, IMO). Thoughts? I would definitely be interested in contributing on this. Or maybe no one cares about this one anymore. :-) Mike BEGIN:VCARD VERSION:2.1 N:Finn;Mike FN:Mike Finn ORG:Frontier Communications;Global Information Systems TITLE:Principal Software Engineer TEL;WORK;VOICE:(585) 777-8202 TEL;VOICE:IM: micktoolz TEL;PAGER;VOICE:716-521-9822 TEL;WORK;FAX:(585) 454-6726 ADR;WORK;ENCODING=QUOTED-PRINTABLE:;Enterprise Integration;180 S. Clinton Ave=0D=0AFC 3;Rochester;NY;14646;Unit= ed States of America LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Enterprise Integration=0D=0A180 S. Clinton Ave=0D=0AFC 3=0D=0ARochester, NY = 14646=0D=0AUnited States of America URL;HOME:http://www.globalcrossing.com URL;WORK:http://www.citizenscommunications.com EMAIL;PREF;INTERNET:[EMAIL PROTECTED] REV:20020107T134207Z END:VCARD
RE: [JBoss-dev] org.jboss.test.testbeancluster.test.BeanUnitTestCase
This test used to work like a charm a month or two ago. I thought I had it working last weekDon't remove it because it means something is wrong that I need to fix. Thanks, Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott M Stark Sent: Tuesday, April 16, 2002 1:58 PM To: [EMAIL PROTECTED] Subject: [JBoss-dev] org.jboss.test.testbeancluster.test.BeanUnitTestCase The clustering BeanUnitTestCase is not running in any JDK configuration and appears to be misconfigured. Look at http://lubega.com/testarchive/sun_jdk131_02/ for example. Please fix this or remove the test until it is ready. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Multiple Instance - continued
we care, revive the thread if you can, better submit configuration that would work with "many instances" on the same machine marcf -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mike FinnSent: Tuesday, April 16, 2002 11:01 AMTo: Jboss-Development-ListSubject: [JBoss-dev] Multiple Instance - continued You guys probably have more to worry about right now, with RC1 and all, but: A while back there was a thread regarding the whole 'multiple instance detection' thing - where the problem of managing multiple listeners vying for the same port was discussed (JNDI, RMI, etc). Was there any resolution or direction? This is of interest to me as we do often have multiple JBosses running on a single box (to make it more challenging - we share a box with another group that has pure RMI apps running on it..). One of the options was a 'port manager' that would (if I understand) forward traffic (like a proxy) to the correct port for the requested service. 1) To do this, I imagine the 'port mgr' would have to be able to sniff the incoming bytestream and determine the requested service by interrogating the content. This imposes the restriction that only one instance of a service (service being wire protocol - JNDI, HTTP, RMI, etc) can be routed, since there probably would be no unambiguous way to differentiate between two HTTP streams (for instance). 2) The port mgr (MBean?) would somehow need to be aware of the 'real' ports being used within the JBoss process space by the managed services. Would the MBean Notification mechanism suffice? Where each MBean that owns a "managed" port would send a notification with the port/s onwhich itit is listening. Or, as (I think) Marc suggested, a P2P solution like JXTA (which may be a better solution than JMX Notifications?). Or a config file (less than optimal, IMO). Thoughts? I would definitely be interested in contributing on this. Or maybe no one cares about this one anymore. :-) Mike
[JBoss-dev] [ jboss-Bugs-544778 ] generation of uni-directional CMR b0rked
Bugs item #544778, was opened at 2002-04-16 19:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=544778group_id=22866 Category: JBossCMP Group: CVS HEAD Status: Open Resolution: None Priority: 5 Submitted By: Christian Riege (lqd) Assigned to: Dain Sundstrom (dsundstrom) Summary: generation of uni-directional CMR b0rked Initial Comment: it seems that when trying to use a UNIdirectional CMR relationship JBossCMP insists on creating a foreign key field on BOTH sides of the relationship. this should not be; JBossCMP should ignore the side of the relationship where no cmr-field element is defined. snippet from ejb-jar.xml: ejb-relation ejb-relation-nameA-Uni-B/ejb-relation-name ejb-relationship-role ejb-relationship-role-namea-uni-b/ejb-relationship-role-name multiplicityOne/multiplicity relationship-role-source ejb-nameA/ejb-name /relationship-role-source cmr-field cmr-field-namefk_field/cmr-field-name /cmr-field /ejb-relationship-role ejb-relationship-role ejb-relationship-role-nameb-maps-a/ejb-relationship-role-name multiplicityOne/multiplicity relationship-role-source ejb-nameB/ejb-name /relationship-role-source /ejb-relationship-role /ejb-relation the tables created look like this: table_a a_id a_fk_field table_b b_id b_a_fk_field the field 'b_a_fk_field' should *not* be generated in my opinion as it is not declared in the deployment descriptor; i.e. it has no matching cmr-field entry. (jbosscmp-jdbc.xml is empty except for defaults element). tested against both jboss 3.0rc1 as well as CVS HEAD. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=544778group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-517062 ] JAWS ResultSet Column Order
Bugs item #517062, was opened at 2002-02-13 11:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=517062group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Michael Prescott (fuseboy) Assigned to: Dan Christopherson (danch) Summary: JAWS ResultSet Column Order Initial Comment: The free and otherwise decent Microsoft JDBC Driver for SQL Server 2000 (they've licensed Merant's driver) has a limitation that requires that 'TEXT' fields be retrieved from ResultSets in the order that they're specified in the SELECT statement. JAWS composes the SELECT statement based on the order that CMP fields are returned from a Hashtable (effectively an undefined order), but moves primary key fields to be the first columns in the SELECT statement. (See http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/jboss/jboss/src/main/org/jboss/ejb/plug ins/jaws/jdbc/JDBCLoadEntityCommand.java?annotate=1.18 lines 214-242). On retrieval, however, it doesn't retrieve the primary key columns first, it retrieves them in the Hashtable order. Is there any reason for this, or can I submit a patch that causes the retrieval order to match the SELECT column order? There are numerous workarounds, from changing the name of the pk columns until the hash causes them to come out first (a flaky hack) to changing the JDBC driver, but this since the Microsoft driver is likely to be come the default for SQL Server installations it strikes me as an important compatability issue. Incidentally, lines 215-221 don't seem to have any effect, nor have they done since they were written. Am I just on crack? -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=517062group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: build/jboss build.xml
User: starksm Date: 02/04/16 10:37:07 Modified:jbossbuild.xml Log: Main is now 3.1 development Revision ChangesPath 1.119 +3 -3 build/jboss/build.xml Index: build.xml === RCS file: /cvsroot/jboss/build/jboss/build.xml,v retrieving revision 1.118 retrieving revision 1.119 diff -u -r1.118 -r1.119 --- build.xml 15 Apr 2002 22:50:22 - 1.118 +++ build.xml 16 Apr 2002 17:37:06 - 1.119 @@ -12,7 +12,7 @@ !---- !-- == -- -!-- $Id: build.xml,v 1.118 2002/04/15 22:50:22 user57 Exp $ -- +!-- $Id: build.xml,v 1.119 2002/04/16 17:37:06 starksm Exp $ -- project default=main name=JBoss/Build @@ -62,9 +62,9 @@ !-- Version identifiers for the server. -- property name=version.major value=3/ -property name=version.minor value=0/ +property name=version.minor value=1/ property name=version.revision value=0/ -property name=version.tag value=beta2/ +property name=version.tag value=alpha/ !-- This must be set to the CVS tag for any release -- property name=version.name value=HEAD/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/jmx test-service.xml
User: d_jencks Date: 02/04/16 11:27:39 Modified:src/resources/jmx test-service.xml Log: fix 2 tests Revision ChangesPath 1.7 +2 -2 jbosstest/src/resources/jmx/test-service.xml Index: test-service.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/jmx/test-service.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- test-service.xml 7 Apr 2002 05:25:59 - 1.6 +++ test-service.xml 16 Apr 2002 18:27:39 - 1.7 @@ -34,7 +34,7 @@ config-property config-property-nameUserName/config-property-name config-property-typejava.lang.String/config-property-type - config-property-value/config-property-value + config-property-valuesa/config-property-value /config-property config-property config-property-namePassword/config-property-name @@ -66,7 +66,7 @@ /mbean /depends depends optional-attribute-name=CachedConnectionManagerjboss.jca:service=CachedConnectionManager/depends -attribute name=SecurityDomainJndiNamejava:/jaas/DefaultDbRealm/attribute +!--attribute name=SecurityDomainJndiNamejava:/jaas/DefaultDbRealm/attribute-- attribute name=TransactionManagerjava:/TransactionManager/attribute /mbean ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jmx/test DeployServiceUnitTestCase.java
User: d_jencks
Date: 02/04/16 11:27:38
Modified:src/main/org/jboss/test/jmx/test
DeployServiceUnitTestCase.java
Log:
fix 2 tests
Revision ChangesPath
1.14 +3 -5
jbosstest/src/main/org/jboss/test/jmx/test/DeployServiceUnitTestCase.java
Index: DeployServiceUnitTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/jmx/test/DeployServiceUnitTestCase.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- DeployServiceUnitTestCase.java7 Apr 2002 05:25:59 - 1.13
+++ DeployServiceUnitTestCase.java16 Apr 2002 18:27:37 - 1.14
@@ -31,7 +31,7 @@
/**
* @see related
* @authora href=mailto:[EMAIL PROTECTED];David Jencks/a
- * @version $Revision: 1.13 $
+ * @version $Revision: 1.14 $
*/
public class DeployServiceUnitTestCase
extends JBossTestCase
@@ -140,8 +140,6 @@
ObjectName testObjectName = new ObjectName(test:name=TestDeployer);
ObjectName testObjectName2 = new ObjectName(test:name=TestDeployer2);
ObjectName testObjectName3 = new ObjectName(test:name=TestDeployer3);
- //the classloader mbean
- ObjectName classLoaderObjectName = new
ObjectName(jboss.system:service=ServiceClassLoader);
//check they aren't there already
assertTrue(test mbean already registered before deploy,
!getServer().isRegistered(testObjectName));
@@ -154,7 +152,7 @@
//make sure we can create an mbean based on the class we just deployed.
try
{
- getServer().createMBean(org.jboss.test.jmx.mbean.TestDeployer,
testObjectName2, classLoaderObjectName);
+ getServer().createMBean(org.jboss.test.jmx.mbean.TestDeployer,
testObjectName2);
}
catch (Exception e)
{
@@ -185,7 +183,7 @@
//check the class is not available
try
{
- ObjectInstance oe =
getServer().createMBean(org.jboss.test.jmx.mbean.TestDeployer, testObjectName3,
classLoaderObjectName);
+ ObjectInstance oe =
getServer().createMBean(org.jboss.test.jmx.mbean.TestDeployer, testObjectName3);
fail(created mbean when class should not be present: object instance: +
oe);
}
catch (ReflectionException re)
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Are we logging the exception enough!!!
The following exception is getting logged by the StatelessSessionContainer, the EjbModule, and finally the MainDeployer 3 times, and this is overkill in my book. If an exception is being thrown or rethrown I don't think it should be logged unless trace level logging is enabled. The MainDeployer could better handle reporting the failure of a nested deployment so that redundant logging does not occur. 13:00:07,937 WARN [EjbModule] you are using deprecated JRMPContainerInvoker. Please change to org.jboss.proxy.ejb.ProxyFactory 13:00:07,953 ERROR [StatelessSessionContainer] Exception in service lifecyle operation: create org.jboss.deployment.DeploymentException: There are no home interface interceptors configured at org.jboss.proxy.ejb.ProxyFactory.initInterceptorClasses(ProxyFactory.java:21 6) at org.jboss.proxy.ejb.ProxyFactory.create(ProxyFactory.java:176) at org.jboss.ejb.StatelessSessionContainer.create(StatelessSessionContainer.jav a:175) at org.jboss.ejb.Container.invoke(Container.java:790) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:867) at $Proxy0.create(Unknown Source) at org.jboss.system.ServiceController.create(ServiceController.java:271) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy18.create(Unknown Source) at org.jboss.ejb.EjbModule.createService(EjbModule.java:381) at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:134) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:867) at $Proxy0.create(Unknown Source) at org.jboss.system.ServiceController.create(ServiceController.java:271) at org.jboss.system.ServiceController.create(ServiceController.java:211) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy5.create(Unknown Source) at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:376) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:626) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:620) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:506) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:470) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy4.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanne r.java:350) at org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeploymen tScanner.java:530) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner. java:410) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(Ab stractDeploymentScanner.java:202) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(Abs tractDeploymentScanner.java:191) 13:00:08,062 WARN [ServiceController] Ignoring request to destroy non-existant service: jboss.j2ee:service=EJB,jndiName=tomcat-test/Optimized 13:00:08,062 INFO [EjbModule] Remove JSR-77 EJB Module: jboss.management.single:J2EEApplication=tomcat-test.ear,J2EEServer=Single,j2 eeType=EJBModule,name=tomca t-test.jar 13:00:08,078 ERROR [EjbModule] Initialization failed org.jboss.deployment.DeploymentException: There are no home interface interceptors configured at org.jboss.proxy.ejb.ProxyFactory.initInterceptorClasses(ProxyFactory.java:21 6) at org.jboss.proxy.ejb.ProxyFactory.create(ProxyFactory.java:176) at org.jboss.ejb.StatelessSessionContainer.create(StatelessSessionContainer.jav a:175) at org.jboss.ejb.Container.invoke(Container.java:790) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:867) at
[JBoss-dev] CVS update: jboss/src/main/org/jboss/proxy ClientContainer.java
User: starksm
Date: 02/04/16 13:17:12
Modified:src/main/org/jboss/proxy Tag: Branch_3_0
ClientContainer.java
Log:
Validate the setup of the client interceptors and throw an exception
if none exist to avoid NullPointerExceptions at runtime.
Revision ChangesPath
No revision
No revision
1.1.2.1 +4 -24 jboss/src/main/org/jboss/proxy/ClientContainer.java
Index: ClientContainer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/proxy/ClientContainer.java,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- ClientContainer.java 7 Mar 2002 18:20:49 - 1.1
+++ ClientContainer.java 16 Apr 2002 20:17:10 - 1.1.2.1
@@ -20,29 +20,9 @@
import org.jboss.invocation.Invocation;
import org.jboss.invocation.InvocationContext;
-/*
-import javax.transaction.TransactionManager;
-import java.security.Principal;
-import javax.transaction.Transaction;
-import javax.transaction.SystemException;
-import javax.naming.InitialContext;
-import javax.naming.NamingException;
-
-import javax.ejb.EJBObject;
-import javax.ejb.EJBHome;
-import java.rmi.RemoteException;
-
-import org.jboss.proxy.ejb.ReadAheadBuffer;
-import org.jboss.proxy.ejb.ListEntityProxy;
-import org.jboss.invocation.Invocation;
-import org.jboss.invocation.Invoker;
-import org.jboss.tm.TransactionPropagationContextFactory;
-import org.jboss.security.SecurityAssociation;
-*/
-
/**
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.1.2.1 $
*
* pb2001/11/19: marcf/b
* ol
@@ -50,7 +30,7 @@
* /ol
*/
public class ClientContainer
-implements Externalizable, InvocationHandler
+ implements Externalizable, InvocationHandler
{
// the static information that gets attached to every invocation
@@ -104,7 +84,7 @@
}
public void writeExternal(final ObjectOutput out)
- throws IOException
+ throws IOException
{
out.writeObject(next);
out.writeObject(context);
@@ -119,7 +99,7 @@
* @throws ClassNotFoundException
*/
public void readExternal(final ObjectInput in)
- throws IOException, ClassNotFoundException
+ throws IOException, ClassNotFoundException
{
next = (Interceptor) in.readObject();
context = (InvocationContext) in.readObject();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/proxy/ejb ProxyFactory.java
User: starksm
Date: 02/04/16 13:17:13
Modified:src/main/org/jboss/proxy/ejb Tag: Branch_3_0
ProxyFactory.java
Log:
Validate the setup of the client interceptors and throw an exception
if none exist to avoid NullPointerExceptions at runtime.
Revision ChangesPath
No revision
No revision
1.13.2.1 +93 -73jboss/src/main/org/jboss/proxy/ejb/ProxyFactory.java
Index: ProxyFactory.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/proxy/ejb/ProxyFactory.java,v
retrieving revision 1.13
retrieving revision 1.13.2.1
diff -u -r1.13 -r1.13.2.1
--- ProxyFactory.java 13 Mar 2002 03:24:23 - 1.13
+++ ProxyFactory.java 16 Apr 2002 20:17:13 - 1.13.2.1
@@ -26,24 +26,25 @@
import javax.naming.NameNotFoundException;
import javax.management.ObjectName;
+import org.jboss.deployment.DeploymentException;
import org.jboss.ejb.Container;
import org.jboss.ejb.ContainerInvoker;
import org.jboss.ejb.ContainerInvokerContainer;
+import org.jboss.ejb.FinderResults;
+import org.jboss.ejb.ListCacheKey;
import org.jboss.invocation.Invoker;
import org.jboss.invocation.InvocationContext;
-import org.jboss.proxy.Interceptor;
-import org.jboss.proxy.ClientContainer;
-import org.jboss.proxy.ejb.handle.HomeHandleImpl;
+import org.jboss.logging.Logger;
import org.jboss.metadata.MetaData;
import org.jboss.metadata.ConfigurationMetaData;
import org.jboss.metadata.EntityMetaData;
import org.jboss.metadata.SessionMetaData;
import org.jboss.naming.Util;
+import org.jboss.proxy.Interceptor;
+import org.jboss.proxy.ClientContainer;
+import org.jboss.proxy.ejb.handle.HomeHandleImpl;
import org.jboss.system.Registry;
-import org.jboss.ejb.FinderResults;
-import org.jboss.ejb.ListCacheKey;
-
-import org.jboss.logging.Logger;
+import org.jboss.util.NestedRuntimeException;
import org.w3c.dom.Element;
@@ -62,7 +63,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
- * @version $Revision: 1.13 $
+ * @version $Revision: 1.13.2.1 $
*
* pbRevisions:/bbr
* pb2001/12/30: billb/b
@@ -205,15 +206,19 @@
/** Load the client interceptor classes
*/
- protected void initInterceptorClasses()
+ protected void initInterceptorClasses() throws Exception
{
ConfigurationMetaData configMetaData =
container.getBeanMetaData().getContainerConfiguration();
Element homeInterceptorConf =
configMetaData.getClientInterceptorConf(HOME_INTERCEPTOR);
loadInterceptorClasses(homeInterceptorClasses, homeInterceptorConf);
+ if( homeInterceptorClasses.size() == 0 )
+ throw new DeploymentException(There are no home interface interceptors
configured);
Element beanInterceptorConf =
configMetaData.getClientInterceptorConf(BEAN_INTERCEPTOR);
loadInterceptorClasses(beanInterceptorClasses, beanInterceptorConf);
+ if( beanInterceptorClasses.size() == 0 )
+ throw new DeploymentException(There are no bean interface interceptors
configured);
Element listEntityInterceptorConf =
configMetaData.getClientInterceptorConf(LIST_ENTITY_INTERCEPTOR);
loadInterceptorClasses(listEntityInterceptorClasses,
listEntityInterceptorConf);
@@ -225,55 +230,44 @@
* @exception Exception if an error occurs
*/
protected void loadInterceptorClasses(ArrayList classes, Element interceptors)
+ throws Exception
{
- try
+ Iterator interceptorElements = MetaData.getChildrenByTagName(interceptors,
interceptor);
+ ClassLoader loader = container.getClassLoader();
+ Interceptor last = null;
+ while( interceptorElements != null interceptorElements.hasNext() )
{
- Iterator interceptorElements = MetaData.getChildrenByTagName(interceptors,
interceptor);
- ClassLoader loader = container.getClassLoader();
- Interceptor last = null;
- while( interceptorElements != null interceptorElements.hasNext() )
- {
-Element ielement = (Element) interceptorElements.next();
-String className = null;
-className = MetaData.getElementContent(ielement);
-Class clazz = loader.loadClass(className);
-classes.add(clazz);
- }
- }
- catch (Exception ex)
- {
- log.error(failed to load client interceptor chain, ex);
+ Element ielement = (Element) interceptorElements.next();
+ String className = null;
+ className = MetaData.getElementContent(ielement);
+ Class clazz = loader.loadClass(className);
+ classes.add(clazz);
}
}
[JBoss-dev] CVS update: jboss/src/main/org/jboss/proxy/ejb ProxyFactory.java
User: starksm
Date: 02/04/16 13:18:21
Modified:src/main/org/jboss/proxy/ejb ProxyFactory.java
Log:
Validate the setup of the client interceptors and throw an exception
if none exist to avoid NullPointerExceptions at runtime.
Revision ChangesPath
1.14 +93 -73jboss/src/main/org/jboss/proxy/ejb/ProxyFactory.java
Index: ProxyFactory.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/proxy/ejb/ProxyFactory.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- ProxyFactory.java 13 Mar 2002 03:24:23 - 1.13
+++ ProxyFactory.java 16 Apr 2002 20:18:21 - 1.14
@@ -26,24 +26,25 @@
import javax.naming.NameNotFoundException;
import javax.management.ObjectName;
+import org.jboss.deployment.DeploymentException;
import org.jboss.ejb.Container;
import org.jboss.ejb.ContainerInvoker;
import org.jboss.ejb.ContainerInvokerContainer;
+import org.jboss.ejb.FinderResults;
+import org.jboss.ejb.ListCacheKey;
import org.jboss.invocation.Invoker;
import org.jboss.invocation.InvocationContext;
-import org.jboss.proxy.Interceptor;
-import org.jboss.proxy.ClientContainer;
-import org.jboss.proxy.ejb.handle.HomeHandleImpl;
+import org.jboss.logging.Logger;
import org.jboss.metadata.MetaData;
import org.jboss.metadata.ConfigurationMetaData;
import org.jboss.metadata.EntityMetaData;
import org.jboss.metadata.SessionMetaData;
import org.jboss.naming.Util;
+import org.jboss.proxy.Interceptor;
+import org.jboss.proxy.ClientContainer;
+import org.jboss.proxy.ejb.handle.HomeHandleImpl;
import org.jboss.system.Registry;
-import org.jboss.ejb.FinderResults;
-import org.jboss.ejb.ListCacheKey;
-
-import org.jboss.logging.Logger;
+import org.jboss.util.NestedRuntimeException;
import org.w3c.dom.Element;
@@ -62,7 +63,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
- * @version $Revision: 1.13 $
+ * @version $Revision: 1.14 $
*
* pbRevisions:/bbr
* pb2001/12/30: billb/b
@@ -205,15 +206,19 @@
/** Load the client interceptor classes
*/
- protected void initInterceptorClasses()
+ protected void initInterceptorClasses() throws Exception
{
ConfigurationMetaData configMetaData =
container.getBeanMetaData().getContainerConfiguration();
Element homeInterceptorConf =
configMetaData.getClientInterceptorConf(HOME_INTERCEPTOR);
loadInterceptorClasses(homeInterceptorClasses, homeInterceptorConf);
+ if( homeInterceptorClasses.size() == 0 )
+ throw new DeploymentException(There are no home interface interceptors
configured);
Element beanInterceptorConf =
configMetaData.getClientInterceptorConf(BEAN_INTERCEPTOR);
loadInterceptorClasses(beanInterceptorClasses, beanInterceptorConf);
+ if( beanInterceptorClasses.size() == 0 )
+ throw new DeploymentException(There are no bean interface interceptors
configured);
Element listEntityInterceptorConf =
configMetaData.getClientInterceptorConf(LIST_ENTITY_INTERCEPTOR);
loadInterceptorClasses(listEntityInterceptorClasses,
listEntityInterceptorConf);
@@ -225,55 +230,44 @@
* @exception Exception if an error occurs
*/
protected void loadInterceptorClasses(ArrayList classes, Element interceptors)
+ throws Exception
{
- try
+ Iterator interceptorElements = MetaData.getChildrenByTagName(interceptors,
interceptor);
+ ClassLoader loader = container.getClassLoader();
+ Interceptor last = null;
+ while( interceptorElements != null interceptorElements.hasNext() )
{
- Iterator interceptorElements = MetaData.getChildrenByTagName(interceptors,
interceptor);
- ClassLoader loader = container.getClassLoader();
- Interceptor last = null;
- while( interceptorElements != null interceptorElements.hasNext() )
- {
-Element ielement = (Element) interceptorElements.next();
-String className = null;
-className = MetaData.getElementContent(ielement);
-Class clazz = loader.loadClass(className);
-classes.add(clazz);
- }
- }
- catch (Exception ex)
- {
- log.error(failed to load client interceptor chain, ex);
+ Element ielement = (Element) interceptorElements.next();
+ String className = null;
+ className = MetaData.getElementContent(ielement);
+ Class clazz = loader.loadClass(className);
+ classes.add(clazz);
}
}
+
/** The codeloadInterceptorChain/code create instances of interceptor
* classes previously loaded in
RE: [JBoss-dev] Are we logging the exception enough!!!
yeah I have the same gripe :) marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Tuesday, April 16, 2002 1:23 PM |To: [EMAIL PROTECTED] |Subject: [JBoss-dev] Are we logging the exception enough!!! | | |The following exception is getting logged by the StatelessSessionContainer, |the EjbModule, and finally the MainDeployer 3 times, and this is |overkill in |my |book. If an exception is being thrown or rethrown I don't think it |should be |logged unless trace level logging is enabled. The MainDeployer could better |handle reporting the failure of a nested deployment so that redundant |logging |does not occur. | |13:00:07,937 WARN [EjbModule] you are using deprecated |JRMPContainerInvoker. Please change to org.jboss.proxy.ejb.ProxyFactory |13:00:07,953 ERROR [StatelessSessionContainer] Exception in |service lifecyle |operation: create |org.jboss.deployment.DeploymentException: There are no home interface |interceptors configured |at |org.jboss.proxy.ejb.ProxyFactory.initInterceptorClasses(ProxyFactor |y.java:21 |6) |at org.jboss.proxy.ejb.ProxyFactory.create(ProxyFactory.java:176) |at |org.jboss.ejb.StatelessSessionContainer.create(StatelessSessionCont |ainer.jav |a:175) |at org.jboss.ejb.Container.invoke(Container.java:790) |at |org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) |at |org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceContr |oller.jav |a:867) |at $Proxy0.create(Unknown Source) |at |org.jboss.system.ServiceController.create(ServiceController.java:271) |at java.lang.reflect.Method.invoke(Native Method) |at |org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMB |eanDispat |cher.java:284) |at |org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) |at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) |at $Proxy18.create(Unknown Source) |at org.jboss.ejb.EjbModule.createService(EjbModule.java:381) |at |org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:134) |at java.lang.reflect.Method.invoke(Native Method) |at |org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMB |eanDispat |cher.java:284) |at |org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) |at |org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceContr |oller.jav |a:867) |at $Proxy0.create(Unknown Source) |at |org.jboss.system.ServiceController.create(ServiceController.java:271) |at |org.jboss.system.ServiceController.create(ServiceController.java:211) |at java.lang.reflect.Method.invoke(Native Method) |at |org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMB |eanDispat |cher.java:284) |at |org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) |at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) |at $Proxy5.create(Unknown Source) |at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:376) |at org.jboss.deployment.MainDeployer.create(MainDeployer.java:626) |at org.jboss.deployment.MainDeployer.create(MainDeployer.java:620) |at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:506) |at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:470) |at java.lang.reflect.Method.invoke(Native Method) |at |org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMB |eanDispat |cher.java:284) |at |org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) |at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) |at $Proxy4.deploy(Unknown Source) |at |org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploym |entScanne |r.java:350) |at |org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URL |Deploymen |tScanner.java:530) |at |org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymen |tScanner. |java:410) |at |org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThrea |d.loop(Ab |stractDeploymentScanner.java:202) |at |org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThrea |d.run(Abs |tractDeploymentScanner.java:191) | |13:00:08,062 WARN [ServiceController] Ignoring request to destroy |non-existant |service: jboss.j2ee:service=EJB,jndiName=tomcat-test/Optimized |13:00:08,062 INFO [EjbModule] Remove JSR-77 EJB Module: |jboss.management.single:J2EEApplication=tomcat-test.ear,J2EEServer= |Single,j2 |eeType=EJBModule,name=tomca |t-test.jar |13:00:08,078 ERROR [EjbModule] Initialization failed |org.jboss.deployment.DeploymentException: There are no home interface |interceptors configured |at |org.jboss.proxy.ejb.ProxyFactory.initInterceptorClasses(ProxyFactor |y.java:21 |6) |at
RE: [JBoss-dev] RC1 release branch occuring at 00:00
Yes, please do this. --jason Quoting Bill Burke [EMAIL PROTECTED]: Can you pull IIOP out of jboss-services.xml and put in in a separate deployable service xml file like cluster-service.xml, etc..? I think this would be better. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Francisco Reverbel Sent: Tuesday, April 16, 2002 12:47 PM To: Jason Dillon Cc: Scott M Stark; [EMAIL PROTECTED] Subject: Re: [JBoss-dev] RC1 release branch occuring at 00:00 Yes, the iiop stuff is now generated by a default build. I have changed a couple of files (jboss-services.xml and run.sh) in order to run it. Please see the patchfile attached. Should I commit these changes? Cheers, Francisco PS: David Jencks is getting a very strange error from rmic. Are you also getting this error? On Mon, 15 Apr 2002, Jason Dillon wrote: I setup the build system to include jboss.net iiop in the default builds. Please look at the configuration that is generated and make sure that iiop stuff will work with a default build. Note, this is on HEAD. --jason Francisco Reverbel wrote: Will it include the iiop stuff? Jason and I were talking about making it part of the default build. User feedback would be a good thing for me at this point. Best, Francisco On Sun, 14 Apr 2002, Scott M Stark wrote: I'm creating the 3.0 branch for the RC1 release at midnight (GMT-0700). Do not commit any changes to main after 22:00 -0700 until the branch is announced to be complete. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RC1 release branch occuring at 00:00
Why runs.sh... this is what was concerned about. Can you please explain this. --jason Quoting Francisco Reverbel [EMAIL PROTECTED]: Yes, the iiop stuff is now generated by a default build. I have changed a couple of files (jboss-services.xml and run.sh) in order to run it. Please see the patchfile attached. Should I commit these changes? Cheers, Francisco PS: David Jencks is getting a very strange error from rmic. Are you also getting this error? On Mon, 15 Apr 2002, Jason Dillon wrote: I setup the build system to include jboss.net iiop in the default builds. Please look at the configuration that is generated and make sure that iiop stuff will work with a default build. Note, this is on HEAD. --jason Francisco Reverbel wrote: Will it include the iiop stuff? Jason and I were talking about making it part of the default build. User feedback would be a good thing for me at this point. Best, Francisco On Sun, 14 Apr 2002, Scott M Stark wrote: I'm creating the 3.0 branch for the RC1 release at midnight (GMT-0700). Do not commit any changes to main after 22:00 -0700 until the branch is announced to be complete. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/main/org/jboss/jetty/session DistributedHttpSessionManager.java
User: jules_gosnell
Date: 02/04/16 13:29:57
Modified:jetty/src/main/org/jboss/jetty/session
DistributedHttpSessionManager.java
Log:
logging changes
Revision ChangesPath
1.14 +10 -6
contrib/jetty/src/main/org/jboss/jetty/session/DistributedHttpSessionManager.java
Index: DistributedHttpSessionManager.java
===
RCS file:
/cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/session/DistributedHttpSessionManager.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- DistributedHttpSessionManager.java14 Feb 2002 01:03:16 - 1.13
+++ DistributedHttpSessionManager.java16 Apr 2002 20:29:57 - 1.14
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: DistributedHttpSessionManager.java,v 1.13 2002/02/14 01:03:16 jules_gosnell
Exp $
+// $Id: DistributedHttpSessionManager.java,v 1.14 2002/04/16 20:29:57 jules_gosnell
Exp $
// TODO
@@ -118,6 +118,8 @@
class IntervalSnapshotStrategy
extends SnapshotStrategy
{
+ static final Logger _log=Logger.getLogger(IntervalSnapshotStrategy);
+
static class
TimeOutHelper
implements AbstractTimeOutManager.TimeOutHelper
@@ -126,7 +128,7 @@
timeOut(Object object)
{
IntervalSnapshotStrategy iss=(IntervalSnapshotStrategy)object;
- System.out.println(snapshotting HttpSessions for Context
(+iss._manager.getServletContext().getServletContextName()+));
+ _log.info(snapshotting HttpSessions for Context
(+iss._manager.getServletContext().getServletContextName()+));
iss._manager.snapshot(iss._notifyActivate, iss._notifyPassivate); //
should probably be done on another thread
iss._timer.reregister(iss, System.currentTimeMillis(), iss._interval*1000);
}
@@ -179,14 +181,16 @@
//--
-class MyTimeOutHelper
+class DistributedHttpSessionTimer
implements AbstractTimeOutManager.TimeOutHelper
{
+ static final Logger _log=Logger.getLogger(DistributedHttpSessionTimer);
+
public void
timeOut(Object object)
{
DistributedHttpSession session=(DistributedHttpSession)object;
-System.out.println(session (+session.getId()+) timed out - cleaning up);
+_log.info(session (+session.getId()+) timed out - cleaning up);
session.getManager().destroyHttpSession(session);
}
@@ -201,7 +205,7 @@
//--
/**
*
- * @version $Id: DistributedHttpSessionManager.java,v 1.13 2002/02/14 01:03:16
jules_gosnell Exp $
+ * @version $Id: DistributedHttpSessionManager.java,v 1.14 2002/04/16 20:29:57
jules_gosnell Exp $
* @author [EMAIL PROTECTED]
*/
//
@@ -209,7 +213,7 @@
public class DistributedHttpSessionManager
implements org.mortbay.jetty.servlet.SessionManager
{
- static AbstractTimeOutManager_scavenger =new
NaiveTimeOutManager(5*1000, new MyTimeOutHelper());
+ static AbstractTimeOutManager_scavenger =new
NaiveTimeOutManager(5*1000, new DistributedHttpSessionTimer());
final AbstractStore _store;
final SnapshotStrategy _snapshotStrategy;
final Logger _log;
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/proxy ClientContainer.java
User: starksm
Date: 02/04/16 13:39:32
Modified:src/main/org/jboss/proxy ClientContainer.java
Log:
Remove the commented out imports
Revision ChangesPath
1.2 +4 -24 jboss/src/main/org/jboss/proxy/ClientContainer.java
Index: ClientContainer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/proxy/ClientContainer.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ClientContainer.java 7 Mar 2002 18:20:49 - 1.1
+++ ClientContainer.java 16 Apr 2002 20:39:32 - 1.2
@@ -20,29 +20,9 @@
import org.jboss.invocation.Invocation;
import org.jboss.invocation.InvocationContext;
-/*
-import javax.transaction.TransactionManager;
-import java.security.Principal;
-import javax.transaction.Transaction;
-import javax.transaction.SystemException;
-import javax.naming.InitialContext;
-import javax.naming.NamingException;
-
-import javax.ejb.EJBObject;
-import javax.ejb.EJBHome;
-import java.rmi.RemoteException;
-
-import org.jboss.proxy.ejb.ReadAheadBuffer;
-import org.jboss.proxy.ejb.ListEntityProxy;
-import org.jboss.invocation.Invocation;
-import org.jboss.invocation.Invoker;
-import org.jboss.tm.TransactionPropagationContextFactory;
-import org.jboss.security.SecurityAssociation;
-*/
-
/**
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
- * @version $Revision: 1.1 $
+ * @version $Revision: 1.2 $
*
* pb2001/11/19: marcf/b
* ol
@@ -50,7 +30,7 @@
* /ol
*/
public class ClientContainer
-implements Externalizable, InvocationHandler
+ implements Externalizable, InvocationHandler
{
// the static information that gets attached to every invocation
@@ -104,7 +84,7 @@
}
public void writeExternal(final ObjectOutput out)
- throws IOException
+ throws IOException
{
out.writeObject(next);
out.writeObject(context);
@@ -119,7 +99,7 @@
* @throws ClassNotFoundException
*/
public void readExternal(final ObjectInput in)
- throws IOException, ClassNotFoundException
+ throws IOException, ClassNotFoundException
{
next = (Interceptor) in.readObject();
context = (InvocationContext) in.readObject();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Are we logging the exception enough!!!
Sounds like MainDeployer should be the one to log this exception. I have noticed that we generally misuse exceptions in many places... ie. catching exceptions to log, then rethrow, or just to ignore. There are also places where we wrap exceptions when we could really just add a checked Exception to the method and let higher level logic handle the failure. This was the case with ServiceMBeanSupport.stopService() in previous releases. I changed this to declare a checked Exception which simplifies implementing services, as they don't need to handle the exceptions that occu here, the support class does that for you. Anyways, my point is that I think we can clean up our exception/throwable usage significantly. Doing so will simplify code which is current handling some exceptions as well as make it easier to debug, as we won't have a billon traces for a single exception. It is a big job though... to clean this up, which is why I think it has not been attempted before. We might also want to provide a guide for new developers on how to deal with exception coding, as it seems to be a common problem. --jason Quoting Scott M Stark [EMAIL PROTECTED]: The following exception is getting logged by the StatelessSessionContainer, the EjbModule, and finally the MainDeployer 3 times, and this is overkill in my book. If an exception is being thrown or rethrown I don't think it should be logged unless trace level logging is enabled. The MainDeployer could better handle reporting the failure of a nested deployment so that redundant logging does not occur. 13:00:07,937 WARN [EjbModule] you are using deprecated JRMPContainerInvoker. Please change to org.jboss.proxy.ejb.ProxyFactory 13:00:07,953 ERROR [StatelessSessionContainer] Exception in service lifecyle operation: create org.jboss.deployment.DeploymentException: There are no home interface interceptors configured at org.jboss.proxy.ejb.ProxyFactory.initInterceptorClasses(ProxyFactory.java:21 6) at org.jboss.proxy.ejb.ProxyFactory.create(ProxyFactory.java:176) at org.jboss.ejb.StatelessSessionContainer.create(StatelessSessionContainer.jav a:175) at org.jboss.ejb.Container.invoke(Container.java:790) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:867) at $Proxy0.create(Unknown Source) at org.jboss.system.ServiceController.create(ServiceController.java:271) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy18.create(Unknown Source) at org.jboss.ejb.EjbModule.createService(EjbModule.java:381) at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:134) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:867) at $Proxy0.create(Unknown Source) at org.jboss.system.ServiceController.create(ServiceController.java:271) at org.jboss.system.ServiceController.create(ServiceController.java:211) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy5.create(Unknown Source) at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:376) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:626) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:620) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:506) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:470) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy4.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanne r.java:350) at org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeploymen tScanner.java:530) at
Re: [JBoss-dev] Are we logging the exception enough!!!
Naaah... we need to log it several times within the same object!!! Any exception should fill up your hard drive with the log file!! I'll take a look at fixing this. thanks david jencks On 2002.04.16 16:22:41 -0400 Scott M Stark wrote: The following exception is getting logged by the StatelessSessionContainer, the EjbModule, and finally the MainDeployer 3 times, and this is overkill in my book. If an exception is being thrown or rethrown I don't think it should be logged unless trace level logging is enabled. The MainDeployer could better handle reporting the failure of a nested deployment so that redundant logging does not occur. 13:00:07,937 WARN [EjbModule] you are using deprecated JRMPContainerInvoker. Please change to org.jboss.proxy.ejb.ProxyFactory 13:00:07,953 ERROR [StatelessSessionContainer] Exception in service lifecyle operation: create org.jboss.deployment.DeploymentException: There are no home interface interceptors configured at org.jboss.proxy.ejb.ProxyFactory.initInterceptorClasses(ProxyFactory.java:21 6) at org.jboss.proxy.ejb.ProxyFactory.create(ProxyFactory.java:176) at org.jboss.ejb.StatelessSessionContainer.create(StatelessSessionContainer.jav a:175) at org.jboss.ejb.Container.invoke(Container.java:790) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:867) at $Proxy0.create(Unknown Source) at org.jboss.system.ServiceController.create(ServiceController.java:271) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy18.create(Unknown Source) at org.jboss.ejb.EjbModule.createService(EjbModule.java:381) at org.jboss.system.ServiceMBeanSupport.create(ServiceMBeanSupport.java:134) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.jav a:867) at $Proxy0.create(Unknown Source) at org.jboss.system.ServiceController.create(ServiceController.java:271) at org.jboss.system.ServiceController.create(ServiceController.java:211) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy5.create(Unknown Source) at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:376) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:626) at org.jboss.deployment.MainDeployer.create(MainDeployer.java:620) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:506) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:470) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDispat cher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.util.jmx.MBeanProxy.invoke(MBeanProxy.java:174) at $Proxy4.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanne r.java:350) at org.jboss.deployment.scanner.URLDeploymentScanner.scanDirectory(URLDeploymen tScanner.java:530) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner. java:410) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(Ab stractDeploymentScanner.java:202) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(Abs tractDeploymentScanner.java:191) 13:00:08,062 WARN [ServiceController] Ignoring request to destroy non-existant service: jboss.j2ee:service=EJB,jndiName=tomcat-test/Optimized 13:00:08,062 INFO [EjbModule] Remove JSR-77 EJB Module: jboss.management.single:J2EEApplication=tomcat-test.ear,J2EEServer=Single,j2 eeType=EJBModule,name=tomca t-test.jar 13:00:08,078 ERROR [EjbModule] Initialization failed org.jboss.deployment.DeploymentException: There are no home interface interceptors configured at org.jboss.proxy.ejb.ProxyFactory.initInterceptorClasses(ProxyFactory.java:21 6) at org.jboss.proxy.ejb.ProxyFactory.create(ProxyFactory.java:176) at
[JBoss-dev] What can change in rc1?
Just to make sure I understand... I can change in rc1: bug fixes, especially those that improve testsuite results (also fix in main) additional comments, especially those that make it into generated jmx-api documentation (also in main) additional sample db config files (also in main) - Any design changes no matter how trivial I think they are should be reserved for main. Agreed? Thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RC1 release branch occuring at 00:00
I changed run.sh to add the properties JacORB needs: -Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB -Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton If the JVM is an IBM one I also add $JBOSS_HOME/lib/jacorb.jar to the classpath. These changes allow you to start an iiop-enabled server without passing any switches to run.sh. This should be good for automatic testing, I presume. (I would really like to see the iiop testcases running successfully at lubega.) Please let me know if there is a better way to accomplish this. Thanks, Francisco PS: I removed the iiop stuff from jboss-service.xml and moved it to a separate service, as Bill and Scott indicated. It worked perfectly. On Tue, 16 Apr 2002, Jason Dillon wrote: Why runs.sh... this is what was concerned about. Can you please explain this. --jason Quoting Francisco Reverbel [EMAIL PROTECTED]: Yes, the iiop stuff is now generated by a default build. I have changed a couple of files (jboss-services.xml and run.sh) in order to run it. Please see the patchfile attached. Should I commit these changes? Cheers, Francisco PS: David Jencks is getting a very strange error from rmic. Are you also getting this error? On Mon, 15 Apr 2002, Jason Dillon wrote: I setup the build system to include jboss.net iiop in the default builds. Please look at the configuration that is generated and make sure that iiop stuff will work with a default build. Note, this is on HEAD. --jason Francisco Reverbel wrote: Will it include the iiop stuff? Jason and I were talking about making it part of the default build. User feedback would be a good thing for me at this point. Best, Francisco On Sun, 14 Apr 2002, Scott M Stark wrote: I'm creating the 3.0 branch for the RC1 release at midnight (GMT-0700). Do not commit any changes to main after 22:00 -0700 until the branch is announced to be complete. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: What can change in rc1?
Yes, these are fine. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: David Jencks [EMAIL PROTECTED] To: jboss-dev [EMAIL PROTECTED]; Scott Stark [EMAIL PROTECTED] Sent: Tuesday, April 16, 2002 1:57 PM Subject: What can change in rc1? Just to make sure I understand... I can change in rc1: bug fixes, especially those that improve testsuite results (also fix in main) additional comments, especially those that make it into generated jmx-api documentation (also in main) additional sample db config files (also in main) - Any design changes no matter how trivial I think they are should be reserved for main. Agreed? Thanks david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work the same
It was my patch that changed this. I changed the EARDeployer to only deploy those applications listed in an application.xml file (I believe that this was another bug on sourceforge?). The struts.jar should only be included on the classpath if it is an application in the application.xml file, if it is in the WEB-INF/lib, or if it is listed in a Class-Path entry in the META-INF file. I believe this is how the spec defines things. Is this right? -Larry Bugs item #544848, was opened at 2002-04-16 15:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id= 22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: EAR Deployments don't work the same Initial Comment: with jboss3.0rc1 with tomcat4.0.3 if I create an ear file such as this: one.war two.war struts.jar META-INF/application.xml where one.war and two.war depend on structs.jar, jboss blows up when one.war attempts to preload the structs servlet. with jboss3.0b1 with tomcat4.0.3, the above configuration worked perfectly. was this intentionally changed? or is it a bug? if i use the Class-Path entry to specify the structs.jar file in the manifest file for both one.war and two.war it also works. I've only tested this on rc1. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id= 22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Are we logging the exception enough!!!
he he, funny I want a new developer that wants to get RW and prove he brings something to take it though. I would formulate the project like jason did and put it on the website see if someone takes it. (or someone lurking on this list speak up). It is big and gives you an overview of many classes. marcf |Naaah... we need to log it several times within the same object!!! Any |exception should fill up your hard drive with the log file!! | |I'll take a look at fixing this. |thanks |david jencks | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JMS with JBossMQ over high latency links
Hi, guys I posted this on JMS/JBossMQ forum but it seems that posting to jboss-dev will make this issue more visible. We are trying to run an MDB that listens to a Topic on a remote JMS provider which resides across a high latency link. The behavior we encountered was that with relatively high load (about 10 or so messages/sec) the delay for all messages to reach the MDB gets to be very, very large. (We are using the 'fastest' of the IL -- OIL) I dug into the Source and realized that, perhaps, this is due to the fact that all methods that ServerIL and ClientIL interfaces expose end up being synchronized in the OIL implementation. Judging from the source, this is because in OIL you have to stuff everything down a single socket and since multiple threads have access to a JMS Connection and it has to be thread safe, synchronizing is a reasonable solution. On high latency links this is a killer, though. I am wondering how much work would it involve to write an extended OIL which can use a socket pool or something of that sort to multiplex communications better. What do you say? Anatoly Akkerman. * * * View thread online: http://main.jboss.org/thread.jsp?forum=66thread=13074 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work the same
Bugs item #544848, was opened at 2002-04-16 15:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: EAR Deployments don't work the same Initial Comment: with jboss3.0rc1 with tomcat4.0.3 if I create an ear file such as this: one.war two.war struts.jar META-INF/application.xml where one.war and two.war depend on structs.jar, jboss blows up when one.war attempts to preload the structs servlet. with jboss3.0b1 with tomcat4.0.3, the above configuration worked perfectly. was this intentionally changed? or is it a bug? if i use the Class-Path entry to specify the structs.jar file in the manifest file for both one.war and two.war it also works. I've only tested this on rc1. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work the same
Hmmm, I thought that might be what the spec wanted, but when I read it I decided it was consistent with put everything in sight on the classpath since then everything they mention is definitely on the classpath. Maybe we need a configuration switch? What problems come from everything in sight? If you have server-specific jars, you'd need to change the ear anyway to change which are deployed, so why not take out the packages you don't want deployed? Any other thoughts? david jencks On 2002.04.16 17:01:13 -0400 lsanders wrote: It was my patch that changed this. I changed the EARDeployer to only deploy those applications listed in an application.xml file (I believe that this was another bug on sourceforge?). The struts.jar should only be included on the classpath if it is an application in the application.xml file, if it is in the WEB-INF/lib, or if it is listed in a Class-Path entry in the META-INF file. I believe this is how the spec defines things. Is this right? -Larry Bugs item #544848, was opened at 2002-04-16 15:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id= 22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: EAR Deployments don't work the same Initial Comment: with jboss3.0rc1 with tomcat4.0.3 if I create an ear file such as this: one.war two.war struts.jar META-INF/application.xml where one.war and two.war depend on structs.jar, jboss blows up when one.war attempts to preload the structs servlet. with jboss3.0b1 with tomcat4.0.3, the above configuration worked perfectly. was this intentionally changed? or is it a bug? if i use the Class-Path entry to specify the structs.jar file in the manifest file for both one.war and two.war it also works. I've only tested this on rc1. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id= 22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Are we logging the exception enough!!!
Title: RE: [JBoss-dev] Are we logging the exception enough!!! It's funny, I was just emailing David about a good starting point for contributing. Not sure if I have the time or knowledge of the framework, but I'll take a day or two digging around to see if the scope is a good fit for me. -Casey -Original Message- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 2:05 PM To: David Jencks; Scott M Stark Cc: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] Are we logging the exception enough!!! he he, funny I want a new developer that wants to get RW and prove he brings something to take it though. I would formulate the project like jason did and put it on the website see if someone takes it. (or someone lurking on this list speak up). It is big and gives you an overview of many classes. marcf |Naaah... we need to log it several times within the same object!!! Any |exception should fill up your hard drive with the log file!! | |I'll take a look at fixing this. |thanks |david jencks | ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RC1 release branch occuring at 00:00
-Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB -Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton Any reason why the service can not set these props? If the JVM is an IBM one I also add $JBOSS_HOME/lib/jacorb.jar to the classpath. Why the special case for IBM? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] JBossMQ Memory Leak
Hi Hiram I just heared from a customer that they found a memory leak in JBossMQ with a profiler. He promised to send information about it soon I am also working on a long term test. Because of that I will create a marathon test case for JBossMQ in the next days to investigate this issue further. So I will let you know as soon as I get more information. Andy x Andreas Schaefer Senior Consultant JBoss Group, LLC x ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/etc/example-config mysql-service.xml
User: d_jencks Date: 02/04/16 15:13:18 Modified:src/etc/example-config Tag: Branch_3_0 mysql-service.xml Log: merge change back from MAIN Revision ChangesPath No revision No revision 1.1.2.1 +2 -2 jbosscx/src/etc/example-config/mysql-service.xml Index: mysql-service.xml === RCS file: /cvsroot/jboss/jbosscx/src/etc/example-config/mysql-service.xml,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 --- mysql-service.xml 8 Apr 2002 15:37:55 - 1.1 +++ mysql-service.xml 16 Apr 2002 22:13:18 - 1.1.2.1 @@ -30,7 +30,7 @@ config-property config-property-nameConnectionURL/config-property-name config-property-typejava.lang.String/config-property-type - config-property-valuejdbc:mysql://dell:/jbossdb/config-property-value + config-property-valuejdbc:mysql://dell:3306/jbossdb/config-property-value /config-property config-property config-property-nameDriverClass/config-property-name @@ -50,7 +50,7 @@ /properties /attribute -attribute name=JndiNameDefaultDS/attribute +attribute name=JndiNameMySqlDS/attribute /mbean /depends ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work the same
The J2EE 1.3 spec (8.1.1.2) goes into several examples of how nested ejb-jar's and war's should share classes, and it is all based on Class-Path Manifest entries. Technically, per spec, nested archives should never share Classpath's unless there is a Class-Path META-INF entry (i.e. web archives should not, by default, be able to see ejb-jar files within the same ear archive). JBoss takes a more conservative approach, and gives each deployment access to each other's information. This sacrifices archive interoperability for ease of use. The patch I put forward took a middle of the road approach - only those archives specified in application.xml are deployed, but they can all access each others data without Class-Path entries. I like being able to limit the deployments by commenting out portions of my application.xml. I use this all the time when testing within an exploded archive - it allows me to isolate one portion of development. Personally, I don't like the deploy everything philosophy. It just seems sloppy to me. I don't like it within sars, rars, or anything else. There should be a single, definitive, user-specified list of exactly what should be deployed, and when. The idea of: search through every single file within an archive, and check to see if it is deployable leads to hacks like the one currently in MainDeployer: ... unless it is a war file, then let the war deployer figure it out. -Larry Hmmm, I thought that might be what the spec wanted, but when I read it I decided it was consistent with put everything in sight on the classpath since then everything they mention is definitely on the classpath. Maybe we need a configuration switch? What problems come from everything in sight? If you have server-specific jars, you'd need to change the ear anyway to change which are deployed, so why not take out the packages you don't want deployed? Any other thoughts? david jencks On 2002.04.16 17:01:13 -0400 lsanders wrote: It was my patch that changed this. I changed the EARDeployer to only deploy those applications listed in an application.xml file (I believe that this was another bug on sourceforge?). The struts.jar should only be included on the classpath if it is an application in the application.xml file, if it is in the WEB-INF/lib, or if it is listed in a Class-Path entry in the META-INF file. I believe this is how the spec defines things. Is this right? -Larry Bugs item #544848, was opened at 2002-04-16 15:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id= 22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: EAR Deployments don't work the same Initial Comment: with jboss3.0rc1 with tomcat4.0.3 if I create an ear file such as this: one.war two.war struts.jar META-INF/application.xml where one.war and two.war depend on structs.jar, jboss blows up when one.war attempts to preload the structs servlet. with jboss3.0b1 with tomcat4.0.3, the above configuration worked perfectly. was this intentionally changed? or is it a bug? if i use the Class-Path entry to specify the structs.jar file in the manifest file for both one.war and two.war it also works. I've only tested this on rc1. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id= 22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/jmx test-service.xml
User: d_jencks Date: 02/04/16 15:26:32 Modified:src/resources/jmx Tag: Branch_3_0 test-service.xml Log: ported test fixes back from main Revision ChangesPath No revision No revision 1.6.2.1 +2 -2 jbosstest/src/resources/jmx/test-service.xml Index: test-service.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/jmx/test-service.xml,v retrieving revision 1.6 retrieving revision 1.6.2.1 diff -u -r1.6 -r1.6.2.1 --- test-service.xml 7 Apr 2002 05:25:59 - 1.6 +++ test-service.xml 16 Apr 2002 22:26:32 - 1.6.2.1 @@ -34,7 +34,7 @@ config-property config-property-nameUserName/config-property-name config-property-typejava.lang.String/config-property-type - config-property-value/config-property-value + config-property-valuesa/config-property-value /config-property config-property config-property-namePassword/config-property-name @@ -66,7 +66,7 @@ /mbean /depends depends optional-attribute-name=CachedConnectionManagerjboss.jca:service=CachedConnectionManager/depends -attribute name=SecurityDomainJndiNamejava:/jaas/DefaultDbRealm/attribute +!--attribute name=SecurityDomainJndiNamejava:/jaas/DefaultDbRealm/attribute-- attribute name=TransactionManagerjava:/TransactionManager/attribute /mbean ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jmx/test DeployServiceUnitTestCase.java
User: d_jencks
Date: 02/04/16 15:26:32
Modified:src/main/org/jboss/test/jmx/test Tag: Branch_3_0
DeployServiceUnitTestCase.java
Log:
ported test fixes back from main
Revision ChangesPath
No revision
No revision
1.13.2.1 +3 -5
jbosstest/src/main/org/jboss/test/jmx/test/DeployServiceUnitTestCase.java
Index: DeployServiceUnitTestCase.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/jmx/test/DeployServiceUnitTestCase.java,v
retrieving revision 1.13
retrieving revision 1.13.2.1
diff -u -r1.13 -r1.13.2.1
--- DeployServiceUnitTestCase.java7 Apr 2002 05:25:59 - 1.13
+++ DeployServiceUnitTestCase.java16 Apr 2002 22:26:32 - 1.13.2.1
@@ -31,7 +31,7 @@
/**
* @see related
* @authora href=mailto:[EMAIL PROTECTED];David Jencks/a
- * @version $Revision: 1.13 $
+ * @version $Revision: 1.13.2.1 $
*/
public class DeployServiceUnitTestCase
extends JBossTestCase
@@ -140,8 +140,6 @@
ObjectName testObjectName = new ObjectName(test:name=TestDeployer);
ObjectName testObjectName2 = new ObjectName(test:name=TestDeployer2);
ObjectName testObjectName3 = new ObjectName(test:name=TestDeployer3);
- //the classloader mbean
- ObjectName classLoaderObjectName = new
ObjectName(jboss.system:service=ServiceClassLoader);
//check they aren't there already
assertTrue(test mbean already registered before deploy,
!getServer().isRegistered(testObjectName));
@@ -154,7 +152,7 @@
//make sure we can create an mbean based on the class we just deployed.
try
{
- getServer().createMBean(org.jboss.test.jmx.mbean.TestDeployer,
testObjectName2, classLoaderObjectName);
+ getServer().createMBean(org.jboss.test.jmx.mbean.TestDeployer,
testObjectName2);
}
catch (Exception e)
{
@@ -185,7 +183,7 @@
//check the class is not available
try
{
- ObjectInstance oe =
getServer().createMBean(org.jboss.test.jmx.mbean.TestDeployer, testObjectName3,
classLoaderObjectName);
+ ObjectInstance oe =
getServer().createMBean(org.jboss.test.jmx.mbean.TestDeployer, testObjectName3);
fail(created mbean when class should not be present: object instance: +
oe);
}
catch (ReflectionException re)
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/etc/example-config solid-service.xml jdatastore-service.xml
User: d_jencks Date: 02/04/16 15:22:09 Added: src/etc/example-config Tag: Branch_3_0 solid-service.xml jdatastore-service.xml Log: ported configs back from main Revision ChangesPath No revision No revision 1.1.2.1 +0 -0 jbosscx/src/etc/example-config/solid-service.xml Index: solid-service.xml === RCS file: /cvsroot/jboss/jbosscx/src/etc/example-config/solid-service.xml,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 1.1.2.1 +0 -0 jbosscx/src/etc/example-config/jdatastore-service.xml Index: jdatastore-service.xml === RCS file: /cvsroot/jboss/jbosscx/src/etc/example-config/jdatastore-service.xml,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work
Bugs item #544848, was opened at 2002-04-16 15:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id=22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: EAR Deployments don't work Initial Comment: with jboss3.0rc1 with tomcat4.0.3 if I create an ear file such as this: one.war two.war struts.jar META-INF/application.xml where one.war and two.war depend on structs.jar, jboss blows up when one.war attempts to preload the structs servlet. with jboss3.0b1 with tomcat4.0.3, the above configuration worked perfectly. was this intentionally changed? or is it a bug? if i use the Class-Path entry to specify the structs.jar file in the manifest file for both one.war and two.war it also works. I've only tested this on rc1. -- Comment By: Peter Luttrell (objec) Date: 2002-04-16 16:35 Message: Logged In: YES user_id=472835 when I mentioned that if I use the Class-Path in the war it worked, i meant that the deployment didn't throw any exceptions. however when I actually go to a page that requires classes in the jar, tomcat blows up indicating that it cannot find them. This may be a seperate issue - let me know if you want me to post another issue about it. the work around at this point is just include the struts.jar in both war files. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest build.xml
User: patriot1burke
Date: 02/04/16 15:45:34
Modified:.Tag: Branch_3_0 build.xml
Log:
forgot to add an interface to the testbeancluster.jar. This was causing this unit
test to
fail badly.
Revision ChangesPath
No revision
No revision
1.106.2.1 +2 -1 jbosstest/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jbosstest/build.xml,v
retrieving revision 1.106
retrieving revision 1.106.2.1
diff -u -r1.106 -r1.106.2.1
--- build.xml 15 Apr 2002 02:48:53 - 1.106
+++ build.xml 16 Apr 2002 22:45:34 - 1.106.2.1
@@ -13,7 +13,7 @@
!----
!-- == --
-!-- $Id: build.xml,v 1.106 2002/04/15 02:48:53 d_jencks Exp $ --
+!-- $Id: build.xml,v 1.106.2.1 2002/04/16 22:45:34 patriot1burke Exp $ --
project default=main name=JBoss/Testsuite
@@ -1721,6 +1721,7 @@
fileset dir=${build.classes}
patternset refid=common.test.application.classes/
include name=org/jboss/test/testbean/interfaces/**/
+include name=org/jboss/test/testbeancluster/interfaces/**/
include name=org/jboss/test/testbean/bean/**/
include name=org/jboss/test/testbeancluster/bean/**/
include name=org/somepackage/**/
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work the same
I agree that there should be a single definitive user-specified list of what should be deployed, but I think it belongs in the ant build file that constructs what gets deployed. To me, it is more sloppy to include stuff in your package that you don't want deployed than to deploy everything in a package. The original motivation behind the unified classloader was to make it practical to work on giant applications that are manageable only if they are packed into multiple ears, but which need to refer to each other's classes, and which need to be independently redeployable. A tree-based classloader scheme isn't going to work for this. I have never understood what the purpose of the classpath entries inside an ear really was, nor the problems with deploying everything in sight. To me, your problem seems like it is based on your convenience and way of working rather than an intrinsic problem with everything. I could be missing something, please let me know what. Also, we still need to deploy every .sar inside a j2ee package unless we want to add a jboss-specific dd to every package indicating which sars get deployed. I think adding a dd just for this is silly. Did you change the behavior of deploying sars or are all of them still deployed? Anyway for ears I guess looking at application.xml should be ok since the user has to include it anyway. Thanks david jencks On 2002.04.16 18:17:39 -0400 lsanders wrote: The J2EE 1.3 spec (8.1.1.2) goes into several examples of how nested ejb-jar's and war's should share classes, and it is all based on Class-Path Manifest entries. Technically, per spec, nested archives should never share Classpath's unless there is a Class-Path META-INF entry (i.e. web archives should not, by default, be able to see ejb-jar files within the same ear archive). JBoss takes a more conservative approach, and gives each deployment access to each other's information. This sacrifices archive interoperability for ease of use. The patch I put forward took a middle of the road approach - only those archives specified in application.xml are deployed, but they can all access each others data without Class-Path entries. I like being able to limit the deployments by commenting out portions of my application.xml. I use this all the time when testing within an exploded archive - it allows me to isolate one portion of development. Personally, I don't like the deploy everything philosophy. It just seems sloppy to me. I don't like it within sars, rars, or anything else. There should be a single, definitive, user-specified list of exactly what should be deployed, and when. The idea of: search through every single file within an archive, and check to see if it is deployable leads to hacks like the one currently in MainDeployer: ... unless it is a war file, then let the war deployer figure it out. -Larry Hmmm, I thought that might be what the spec wanted, but when I read it I decided it was consistent with put everything in sight on the classpath since then everything they mention is definitely on the classpath. Maybe we need a configuration switch? What problems come from everything in sight? If you have server-specific jars, you'd need to change the ear anyway to change which are deployed, so why not take out the packages you don't want deployed? Any other thoughts? david jencks On 2002.04.16 17:01:13 -0400 lsanders wrote: It was my patch that changed this. I changed the EARDeployer to only deploy those applications listed in an application.xml file (I believe that this was another bug on sourceforge?). The struts.jar should only be included on the classpath if it is an application in the application.xml file, if it is in the WEB-INF/lib, or if it is listed in a Class-Path entry in the META-INF file. I believe this is how the spec defines things. Is this right? -Larry Bugs item #544848, was opened at 2002-04-16 15:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=544848group_id= 22866 Category: None Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Nobody/Anonymous (nobody) Summary: EAR Deployments don't work the same Initial Comment: with jboss3.0rc1 with tomcat4.0.3 if I create an ear file such as this: one.war two.war struts.jar META-INF/application.xml where one.war and two.war depend on structs.jar, jboss blows up when one.war attempts to preload the structs servlet. with jboss3.0b1 with tomcat4.0.3, the above configuration worked perfectly. was this intentionally changed? or is it a bug? if i use the Class-Path entry to specify the structs.jar file in the manifest file for both one.war and two.war it also works.
[JBoss-dev] CVS update: jbosstest build.xml
User: patriot1burke Date: 02/04/16 15:47:18 Modified:.build.xml Log: forgot to add an interface to the testbeancluster.jar. This was causing this unit test to fail badly. Revision ChangesPath 1.107 +2 -1 jbosstest/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosstest/build.xml,v retrieving revision 1.106 retrieving revision 1.107 diff -u -r1.106 -r1.107 --- build.xml 15 Apr 2002 02:48:53 - 1.106 +++ build.xml 16 Apr 2002 22:47:18 - 1.107 @@ -13,7 +13,7 @@ !---- !-- == -- -!-- $Id: build.xml,v 1.106 2002/04/15 02:48:53 d_jencks Exp $ -- +!-- $Id: build.xml,v 1.107 2002/04/16 22:47:18 patriot1burke Exp $ -- project default=main name=JBoss/Testsuite @@ -1722,6 +1722,7 @@ patternset refid=common.test.application.classes/ include name=org/jboss/test/testbean/interfaces/**/ include name=org/jboss/test/testbean/bean/**/ +include name=org/jboss/test/testbeancluster/interfaces/**/ include name=org/jboss/test/testbeancluster/bean/**/ include name=org/somepackage/**/ /fileset ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/readahead/ejb CMPFindTestSession.java
User: danch
Date: 02/04/16 16:06:03
Modified:src/main/org/jboss/test/readahead/ejb Tag: Branch_2_4
CMPFindTestSession.java
Log:
Fixed a bug that was causing tests to error out - seems we're fast enough to insert
1 entity in the windows currentTimeMillis resolution
Revision ChangesPath
No revision
No revision
1.1.2.3 +172 -172
jbosstest/src/main/org/jboss/test/readahead/ejb/CMPFindTestSession.java
Index: CMPFindTestSession.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/readahead/ejb/CMPFindTestSession.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- CMPFindTestSession.java 29 Oct 2001 00:04:26 - 1.1.2.2
+++ CMPFindTestSession.java 16 Apr 2002 23:06:03 - 1.1.2.3
@@ -1,172 +1,172 @@
-package org.jboss.test.readahead.ejb;
-
-import java.util.Iterator;
-import java.util.Collection;
-import java.text.Collator;
-import javax.naming.InitialContext;
-import javax.naming.NamingException;
-import javax.ejb.EJBException;
-import javax.ejb.SessionBean;
-import javax.ejb.SessionContext;
-import org.jboss.test.readahead.interfaces.AddressHome;
-import org.jboss.test.readahead.interfaces.AddressRemote;
-import org.jboss.test.readahead.interfaces.CMPFindTestEntityHome;
-import org.jboss.test.readahead.interfaces.CMPFindTestEntityRemote;
-
-/**
- * Implementation class for session bean used in read-ahead finder
- * tests
- *
- * @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson/a
- * @version $Id: CMPFindTestSession.java,v 1.1.2.2 2001/10/29 00:04:26 danch Exp $
- *
- * Revision:
- */
-public class CMPFindTestSession implements SessionBean {
- private static final int DATASET_SIZE = 100;
-
- private SessionContext sessionContext;
-
- public void ejbCreate() {
- }
- public void ejbRemove() {
- }
- public void ejbActivate() {
- }
- public void ejbPassivate() {
- }
- public void setSessionContext(SessionContext context) {
- sessionContext = context;
- }
-
- public void removeTestData() {
- try {
- InitialContext ctx = new InitialContext();
- CMPFindTestEntityHome home =
(CMPFindTestEntityHome)ctx.lookup(CMPFindTestEntity);
-
- Collection coll = home.findAll();
- Iterator iter = coll.iterator();
- while (iter.hasNext()) {
-CMPFindTestEntityRemote rem = (CMPFindTestEntityRemote)iter.next();
-
-rem.remove();
- }
- } catch (Exception e) {
- }
- }
-
- public void createTestData() {
- try {
- InitialContext ctx = new InitialContext();
- CMPFindTestEntityHome home =
(CMPFindTestEntityHome)ctx.lookup(CMPFindTestEntity);
- AddressHome addrHome = (AddressHome)ctx.lookup(Address);
- for (int i=0;iDATASET_SIZE;i++) {
-String key = Long.toString(System.currentTimeMillis());
-CMPFindTestEntityRemote rem = home.create(key);
-rem.setName(Name+i);
-rem.setRank(Rank);
-rem.setSerialNumber(123456789);
-//give him an address
-if ((i % 2) ==0) {
- addrHome.create(rem.getKey(), 1, 123 east st., Eau Claire,
WI, 54701);
-} else {
- addrHome.create(rem.getKey(), 1, 123 east st., Milwaukee,
WI, 54201);
-}
- }
- } catch (Exception e) {
- System.out.println(Exception caught: +e);
- e.printStackTrace();
- throw new EJBException(e.getMessage());
- }
- }
-
- public void addressByCity() {
- try {
- InitialContext ctx = new InitialContext();
- AddressHome home = (AddressHome)ctx.lookup(Address);
-
- long startTime = System.currentTimeMillis();
- Collection coll = home.findByCity(Eau Claire);
- int count = 0;
- Iterator iter = coll.iterator();
- while (iter.hasNext()) {
-AddressRemote rem = (AddressRemote)iter.next();
-rem.getCity();
-//System.out.println(Name: +rem.getName()+ Rank: +rem.getRank());
-count++;
- }
- long endTime = System.currentTimeMillis();
- System.out.println(called +count+ beans in +(endTime-startTime)+
ms.);
- } catch (Exception e) {
- System.out.println(Caught +e);
- }
- }
-
- public void testByCity() {
- try {
- InitialContext ctx = new InitialContext();
- CMPFindTestEntityHome home =
(CMPFindTestEntityHome)ctx.lookup(CMPFindTestEntity);
-
- long startTime = System.currentTimeMillis();
-
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc JDBCLoadEntityCommand.java
User: danch
Date: 02/04/16 16:10:17
Modified:src/main/org/jboss/ejb/plugins/jaws/jdbc Tag: Branch_2_4
JDBCLoadEntityCommand.java
Log:
merged patch #520200 for bug 517062 (resultset column ordering)
Revision ChangesPath
No revision
No revision
1.11.2.3 +248 -241
jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCLoadEntityCommand.java
Index: JDBCLoadEntityCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jaws/jdbc/JDBCLoadEntityCommand.java,v
retrieving revision 1.11.2.2
retrieving revision 1.11.2.3
diff -u -r1.11.2.2 -r1.11.2.3
--- JDBCLoadEntityCommand.java14 Jul 2001 21:43:24 - 1.11.2.2
+++ JDBCLoadEntityCommand.java16 Apr 2002 23:10:17 - 1.11.2.3
@@ -1,241 +1,248 @@
-/*
- * JBoss, the OpenSource EJB server
- *
- * Distributable under LGPL license.
- * See terms of license at gnu.org.
- */
-
-package org.jboss.ejb.plugins.jaws.jdbc;
-
-import java.lang.reflect.Field;
-import java.lang.reflect.Method;
-
-import java.util.Iterator;
-import java.util.ArrayList;
-import java.util.List;
-import java.util.HashMap;
-
-import java.rmi.NoSuchObjectException;
-import java.rmi.RemoteException;
-import java.rmi.ServerException;
-
-import java.sql.PreparedStatement;
-import java.sql.ResultSet;
-
-import org.jboss.ejb.EntityEnterpriseContext;
-import org.jboss.ejb.plugins.jaws.JAWSPersistenceManager;
-import org.jboss.ejb.plugins.jaws.JPMLoadEntityCommand;
-import org.jboss.ejb.plugins.jaws.metadata.CMPFieldMetaData;
-import org.jboss.ejb.plugins.jaws.metadata.PkFieldMetaData;
-import org.jboss.ejb.plugins.jaws.metadata.JawsEntityMetaData;
-
-/**
- * JAWSPersistenceManager JDBCLoadEntityCommand
- *
- * @see related
- * @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
- * @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
- * @author a href=mailto:[EMAIL PROTECTED];Joe Shevland/a
- * @author a href=mailto:[EMAIL PROTECTED];Justin Forder/a
- * @author a href=mailto:[EMAIL PROTECTED];Dirk Zimmermann/a
- * @author a href=mailto:[EMAIL PROTECTED];danch (Dan Christopherson)/a
- * @version $Revision: 1.11.2.2 $
- */
-public class JDBCLoadEntityCommand
- extends JDBCQueryCommand
- implements JPMLoadEntityCommand
-{
- /**what is the position of each cmp field in the generated select statement?
-* this simply maps the position of the field in the CMP list to its position
-* in the generated select statement. This is neccessary because of the variable
-* number of key columns (which are skipped in a load) and because there can
-* be overlap between the two: pkfields and cmpfields are neither disjoint sets
-* nor is the cmpfields a subset of pkfields (not that that makes sense to
-* me right now, but I'll roll with it until I have more chance to analyse -
danch)
-*/
- int [] cmpFieldPositionInSelect = null;
-
- /** This const is used in places where I need to add an offset to a count
-* to account for the fact that JDBC counts from one whilst every other
-* damn thing in the languase starts at 0, the way God intended!
-*/
- private static final int JDBC_WART_OFFSET = 1;
- // Constructors --
-
- public JDBCLoadEntityCommand(JDBCCommandFactory factory)
- {
- super(factory, Load);
-
- String sql = createSelectClause() + FROM + jawsEntity.getTableName()
- + WHERE + getPkColumnWhereList();
- if (jawsEntity.hasSelectForUpdate())
- {
- sql += FOR UPDATE;
- }
-
- setSQL(sql);
- }
-
- protected String createSelectClause() {
- // Select SQL
- String sql = SELECT ;
- HashMap alreadyListed = new HashMap();
- // put the key fields in first
- // we'll stash the column names here so that we can later map an overlapped
- // column (overlap between PK and CMP) into its spot in the select statement.
- String[] pkColumnNames = new String[jawsEntity.getNumberOfPkFields()];
- Iterator keyIt = jawsEntity.getPkFields();
- int fieldCount = 0;
- while (keyIt.hasNext())
- {
- PkFieldMetaData pkField = (PkFieldMetaData)keyIt.next();
-
- sql += ((fieldCount==0) ? : ,) +
-jawsEntity.getTableName() + . + pkField.getColumnName();
- alreadyListed.put(pkField.getColumnName().toUpperCase(), pkField);
- pkColumnNames[fieldCount]=pkField.getColumnName();
- fieldCount++;
- }
-
- cmpFieldPositionInSelect = new int[jawsEntity.getNumberOfCMPFields()];
- Iterator it =
Re: [JBoss-dev] [ jboss-Bugs-544848 ] EAR Deployments don't work the same
Comments inlined... I agree that there should be a single definitive user-specified list of what should be deployed, but I think it belongs in the ant build file that constructs what gets deployed. To me, it is more sloppy to include stuff in your package that you don't want deployed than to deploy everything in a package. As an example of why this is useful, let me outline my companies development environment: Our cvs repository is itself an exploded ear file, plus an src directory, the ant build scripts, minus any compiled code. We have 3 war archives, and a single ejb-jar file. The ant scripts simply compile the appropriate source files to the propper directories (WEB-INF/classes, the ejb-jar, etc...). In development, this directory is directly deployed by JBoss. Another ant task builds the compressed archives for production (stripping out the src, build scripts, etc...), but development is done directly within the deployed application. This has improved the speed of developing / redeploying / testing dramatically. (Perhaps this gives you an idea why I have been so hung up on exploded deployment ;-) ) To remove an archive from our deployment would meen removing an entire CVS directory. The original motivation behind the unified classloader was to make it practical to work on giant applications that are manageable only if they are packed into multiple ears, but which need to refer to each other's classes, and which need to be independently redeployable. A tree-based classloader scheme isn't going to work for this. I'm not suggesting getting rid of this. In fact, I like the convenience of not specifying Class-Path entries all over my META-INF files, and I think the spec should allow shared classpaths. But, it should be recognized that any user who makes use of this feature may need to make some configuration changes if they switch app servers. I have never understood what the purpose of the classpath entries inside an ear really was, nor the problems with deploying everything in sight. It just takes control away from the user, though it could be argued that the user doesn't have to include things she does not want deployed. To me, your problem seems like it is based on your convenience and way of working rather than an intrinsic problem with everything. I could be missing something, please let me know what. No, my problem is with an app-server making assumptions that a user may not want. Further, the user has no way of overriding these assumptions. Put simply: JBoss is violating the J2EE specification here. Consider the following, legal ear archive: 2 nested war files, who use the same web-context, but only the first specified in application.xml. JBoss will not be able to deploy this because of the context root conflict, however a compliant app server would. Also, we still need to deploy every .sar inside a j2ee package unless we want to add a jboss-specific dd to every package indicating which sars get deployed. I think adding a dd just for this is silly. Yeah, a bit silly, but IMO better than what we have now. I would prefer a documented convention stating what directory within a sar archive nested deployments should live. The same goes for rar files. (Kind of like war files - they have the WEB-INF/lib and WEB-INF/classes directories). Did you change the behavior of deploying sars or are all of them still deployed? No - I got yelled at when I tried :-) Everything works exactly as it did, except the EARDeployer, and I will submit a patch to revert this functionality if required. Anyway for ears I guess looking at application.xml should be ok since the user has to include it anyway. Sorry for rambling, and I hope I'm not coming off too strongly. Thanks for listening! -Larry ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] 3.0.0 RC1 is available
on 16-04-2 01.51, marc fleury at [EMAIL PROTECTED] wrote: |4 in all + the backup of thousands more - cool ... | |;-) | |Love Love indeed my friend, your english is greatly improved Bouge de la ahhh ... Du menar denna bara i tanken by ? ... Kan inte franska ... vill *inte* kunna franska ... finmaskigheten i deras språk ger klasstillhörigheten hos dom, därför har dom i allmänhet svårt för andra språk !!! då hela deras hela förståelse av varandet bygger på språkets 'tonart' ... älskar dock människorna och landet ! ... Förlåt ... för mycket brus ... ;-) DADA /peter/f marcf |/peter_f ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Are we logging the exception enough!!!
Here is the strategy I follow in JBossCMP: Low-level non recoverable exceptions (SQLException, IOException...) are wrapped in an EJBException. (Not RemoteException or ServerException as is required by the spec). When catching an Exception, first check for EJBException, and just rethrow. (avoid EJBException in EJBException) Only log an exception if wrapping with an exception that does not support sub exception (CreateException and RemoveException). -dain Jason Dillon wrote: Sounds like MainDeployer should be the one to log this exception. I have noticed that we generally misuse exceptions in many places... ie. catching exceptions to log, then rethrow, or just to ignore. There are also places where we wrap exceptions when we could really just add a checked Exception to the method and let higher level logic handle the failure. This was the case with ServiceMBeanSupport.stopService() in previous releases. I changed this to declare a checked Exception which simplifies implementing services, as they don't need to handle the exceptions that occu here, the support class does that for you. Anyways, my point is that I think we can clean up our exception/throwable usage significantly. Doing so will simplify code which is current handling some exceptions as well as make it easier to debug, as we won't have a billon traces for a single exception. It is a big job though... to clean this up, which is why I think it has not been attempted before. We might also want to provide a guide for new developers on how to deal with exception coding, as it seems to be a common problem. --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 17-April-2002
Number of tests run: 561 Successful tests: 523 Errors:22 Failures: 16 [time of test: 17 April 2002 0:59 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20010626 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-31] See http://lubega.com/testarchive/ibm_jdk13_20010626 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-517062 ] JAWS ResultSet Column Order
Bugs item #517062, was opened at 2002-02-13 11:06 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=517062group_id=22866 Category: JBossServer Group: v2.4 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Michael Prescott (fuseboy) Assigned to: Dan Christopherson (danch) Summary: JAWS ResultSet Column Order Initial Comment: The free and otherwise decent Microsoft JDBC Driver for SQL Server 2000 (they've licensed Merant's driver) has a limitation that requires that 'TEXT' fields be retrieved from ResultSets in the order that they're specified in the SELECT statement. JAWS composes the SELECT statement based on the order that CMP fields are returned from a Hashtable (effectively an undefined order), but moves primary key fields to be the first columns in the SELECT statement. (See http://cvs.sourceforge.net/cgi- bin/viewcvs.cgi/jboss/jboss/src/main/org/jboss/ejb/plug ins/jaws/jdbc/JDBCLoadEntityCommand.java?annotate=1.18 lines 214-242). On retrieval, however, it doesn't retrieve the primary key columns first, it retrieves them in the Hashtable order. Is there any reason for this, or can I submit a patch that causes the retrieval order to match the SELECT column order? There are numerous workarounds, from changing the name of the pk columns until the hash causes them to come out first (a flaky hack) to changing the JDBC driver, but this since the Microsoft driver is likely to be come the default for SQL Server installations it strikes me as an important compatability issue. Incidentally, lines 215-221 don't seem to have any effect, nor have they done since they were written. Am I just on crack? -- Comment By: Dan Christopherson (danch) Date: 2002-04-16 18:20 Message: Logged In: YES user_id=51915 fixed, courtesy patch#520200 -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=517062group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Stateful Session Beans are not EJB2.0 yet
Hi, I raised a bug (#541855) about this a while ago, which has met a distressing amount of silence. In short, stateful session beans fail to passivate if they have EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, they fail to comply with 7.4.1 of the EJB 2.0 spec. I would tackle fixing this myself, but I don't yet know my way around inside the guts of JBoss well enough yet. Maybe one of the gurus can spend ten or fifteen minutes describing how to go about it - and then I'll be happy to write and test the implementation. Stephen Coy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Lets ditch the testsuite bin scripts
Does anyone have a problem with deleting all the testsuite/src/bin scripts? IMO they are 200% obsolete given the current test framework. david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Lets ditch the testsuite bin scripts
I like them... they make me feel warm and fuzzy and that god loves me. If you remove them does that mean that god won't love me anymore? * * * Who am I kidding... there is no god, so nuke em. --jason Quoting David Jencks [EMAIL PROTECTED]: Does anyone have a problem with deleting all the testsuite/src/bin scripts? IMO they are 200% obsolete given the current test framework. david jencks ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/util TestDBDriver.java TestConnection.java
User: d_jencks Date: 02/04/16 17:37:26 Removed: src/main/org/jboss/test/util Tag: Branch_3_0 TestDBDriver.java TestConnection.java Log: remove unused classes that have problems in jdk 1.4 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet
Any clue why they fail? --jason Quoting Stephen Coy [EMAIL PROTECTED]: Hi, I raised a bug (#541855) about this a while ago, which has met a distressing amount of silence. In short, stateful session beans fail to passivate if they have EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, they fail to comply with 7.4.1 of the EJB 2.0 spec. I would tackle fixing this myself, but I don't yet know my way around inside the guts of JBoss well enough yet. Maybe one of the gurus can spend ten or fifteen minutes describing how to go about it - and then I'll be happy to write and test the implementation. Stephen Coy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 17-April-2002
Number of tests run: 563 Successful tests: 527 Errors:21 Failures: 15 [time of test: 17 April 2002 1:46 GMT] [java.version: 1.3.0] [java.vendor: IBM Corporation] [java.vm.version: 1.3.0] [java.vm.name: Classic VM] [java.vm.info: J2RE 1.3.0 IBM build cx130-20020124 (JIT enabled: jitc)] [os.name: Linux] [os.arch: x86] [os.version: 2.4.9-31] See http://lubega.com/testarchive/ibm_jdk13_20020124 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet
Because there is not yet any code in place to handle the passivation of these objects. If you look in org.jboss.ejb.plugins.SessionObjectOutputStream you can see that it's only the original EJB1.1 stuff. EJBLocalObject and EJBLocalHome are not serializable, and so must be specially handled together with their remote brethren in SessionObjectOutputStream.replaceObject, not to mention the corresponding activation code in SessionObjectInputStream. On Wednesday, April 17, 2002, at 10:41 AM, Jason Dillon wrote: Any clue why they fail? --jason Quoting Stephen Coy [EMAIL PROTECTED]: Hi, I raised a bug (#541855) about this a while ago, which has met a distressing amount of silence. In short, stateful session beans fail to passivate if they have EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, they fail to comply with 7.4.1 of the EJB 2.0 spec. I would tackle fixing this myself, but I don't yet know my way around inside the guts of JBoss well enough yet. Maybe one of the gurus can spend ten or fifteen minutes describing how to go about it - and then I'll be happy to write and test the implementation. Stephen Coy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/loading UnifiedLoaderRepository.java
User: starksm
Date: 02/04/16 17:53:46
Modified:src/main/org/jboss/mx/loading Tag: Branch_3_0
UnifiedLoaderRepository.java
Log:
The loadClass(String) method must query the current TCL if the
if the repository does not contain the requested class and the
TCL is not a UnifiedClassLoader as the TCL will not be queried
by the loadClass(String, boolean, ClassLoader) method in this
instance. This was the reason for the
org.jboss.test.jbossmx.compliance.timer.BasicTestCase failures.
Revision ChangesPath
No revision
No revision
1.2.2.1 +19 -8 jmx/src/main/org/jboss/mx/loading/UnifiedLoaderRepository.java
Index: UnifiedLoaderRepository.java
===
RCS file:
/cvsroot/jboss/jmx/src/main/org/jboss/mx/loading/UnifiedLoaderRepository.java,v
retrieving revision 1.2
retrieving revision 1.2.2.1
diff -u -r1.2 -r1.2.2.1
--- UnifiedLoaderRepository.java 15 Apr 2002 02:48:51 - 1.2
+++ UnifiedLoaderRepository.java 17 Apr 2002 00:53:46 - 1.2.2.1
@@ -37,7 +37,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Ole Husgaard/a
* @author a href=mailto:[EMAIL PROTECTED];Juha Lindfors/a.
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.2.2.1 $
* just a hint... xdoclet not really used
* @jmx.name=JMImplementation:service=UnifiedLoaderRepository,name=Default
*
@@ -113,14 +113,11 @@
/**
* Add a class to this repository. Allows a class to be added in
* byte code form stored inside this repository.
-/**
-* Load a class in this repository.
*
* @param name The name of the class
* @param resolve If codetrue/code, the class will be resolved
* @param scl The asking class loader
-* @return The loaded class.
-* resource could not be found.
+* @return The loaded class
* @throws ClassNotFoundException If the class could not be found.
*/
public Class loadClass(String name, boolean resolve, ClassLoader scl)
@@ -165,7 +162,7 @@
{
}
}
-
+
if (foundClass == null)
{
Iterator allLoaders = classLoaders2.iterator();
@@ -384,9 +381,23 @@
// if someone comes to us directly through LoaderRepository interface
// notice that UCL loaders will skip this and invoke
// loadClass(name, resolve, cl) directly
- return loadClass(className, false,
Thread.currentThread().getContextClassLoader());
+ ClassLoader scl = Thread.currentThread().getContextClassLoader();
+ Class clazz = null;
+ try
+ {
+ clazz = loadClass(className, false, scl);
+ }
+ catch(ClassNotFoundException e)
+ {
+ /* If the TCL is not a UnifiedClassLoader then the scl was not asked
+ if it could load the class. Do so here.
+ */
+ if( (scl instanceof UnifiedClassLoader) == false )
+clazz = scl.loadClass(className);
+ }
+ return clazz;
}
-
+
public Class loadClassWithout(ClassLoader loader, String className) throws
ClassNotFoundException
{
throw new Error(NYI);
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet
Nope. How would you automate testing it? I know it doesn't work because I've observed it in the console log. On Wednesday, April 17, 2002, at 10:58 AM, Jason Dillon wrote: Does the testsuite cover these? --jason Quoting Hunter Hillegas [EMAIL PROTECTED]: I think some part of them is not marked as serializable... From: Jason Dillon [EMAIL PROTECTED] Date: Tue, 16 Apr 2002 17:41:19 -0700 To: Stephen Coy [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet Any clue why they fail? --jason Quoting Stephen Coy [EMAIL PROTECTED]: Hi, I raised a bug (#541855) about this a while ago, which has met a distressing amount of silence. In short, stateful session beans fail to passivate if they have EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, they fail to comply with 7.4.1 of the EJB 2.0 spec. I would tackle fixing this myself, but I don't yet know my way around inside the guts of JBoss well enough yet. Maybe one of the gurus can spend ten or fifteen minutes describing how to go about it - and then I'll be happy to write and test the implementation. Stephen Coy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/org/jboss/mx/loading UnifiedLoaderRepository.java
User: starksm
Date: 02/04/16 17:55:36
Modified:src/main/org/jboss/mx/loading UnifiedLoaderRepository.java
Log:
The loadClass(String) method must query the current TCL if the
if the repository does not contain the requested class and the
TCL is not a UnifiedClassLoader as the TCL will not be queried
by the loadClass(String, boolean, ClassLoader) method in this
instance. This was the reason for the
org.jboss.test.jbossmx.compliance.timer.BasicTestCase failures.
Revision ChangesPath
1.3 +19 -8 jmx/src/main/org/jboss/mx/loading/UnifiedLoaderRepository.java
Index: UnifiedLoaderRepository.java
===
RCS file:
/cvsroot/jboss/jmx/src/main/org/jboss/mx/loading/UnifiedLoaderRepository.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- UnifiedLoaderRepository.java 15 Apr 2002 02:48:51 - 1.2
+++ UnifiedLoaderRepository.java 17 Apr 2002 00:55:36 - 1.3
@@ -37,7 +37,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
* @author a href=mailto:[EMAIL PROTECTED];Ole Husgaard/a
* @author a href=mailto:[EMAIL PROTECTED];Juha Lindfors/a.
- * @version $Revision: 1.2 $
+ * @version $Revision: 1.3 $
* just a hint... xdoclet not really used
* @jmx.name=JMImplementation:service=UnifiedLoaderRepository,name=Default
*
@@ -113,14 +113,11 @@
/**
* Add a class to this repository. Allows a class to be added in
* byte code form stored inside this repository.
-/**
-* Load a class in this repository.
*
* @param name The name of the class
* @param resolve If codetrue/code, the class will be resolved
* @param scl The asking class loader
-* @return The loaded class.
-* resource could not be found.
+* @return The loaded class
* @throws ClassNotFoundException If the class could not be found.
*/
public Class loadClass(String name, boolean resolve, ClassLoader scl)
@@ -165,7 +162,7 @@
{
}
}
-
+
if (foundClass == null)
{
Iterator allLoaders = classLoaders2.iterator();
@@ -384,9 +381,23 @@
// if someone comes to us directly through LoaderRepository interface
// notice that UCL loaders will skip this and invoke
// loadClass(name, resolve, cl) directly
- return loadClass(className, false,
Thread.currentThread().getContextClassLoader());
+ ClassLoader scl = Thread.currentThread().getContextClassLoader();
+ Class clazz = null;
+ try
+ {
+ clazz = loadClass(className, false, scl);
+ }
+ catch(ClassNotFoundException e)
+ {
+ /* If the TCL is not a UnifiedClassLoader then the scl was not asked
+ if it could load the class. Do so here.
+ */
+ if( (scl instanceof UnifiedClassLoader) == false )
+clazz = scl.loadClass(className);
+ }
+ return clazz;
}
-
+
public Class loadClassWithout(ClassLoader loader, String className) throws
ClassNotFoundException
{
throw new Error(NYI);
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet
I would *guess* it would as simple as adding another bean test, which deployed a 2.0 bean with local fluff, then perhaps jmx to the server and ask the container to passivate. I am not sure if there is a such a mechanism exposed via jmx right now todo this, but it might be useful. It might also be possible to test this in isolation, but that is more work and not really an option with the current tessuite setup... --jason Quoting Stephen Coy [EMAIL PROTECTED]: Nope. How would you automate testing it? I know it doesn't work because I've observed it in the console log. On Wednesday, April 17, 2002, at 10:58 AM, Jason Dillon wrote: Does the testsuite cover these? --jason Quoting Hunter Hillegas [EMAIL PROTECTED]: I think some part of them is not marked as serializable... From: Jason Dillon [EMAIL PROTECTED] Date: Tue, 16 Apr 2002 17:41:19 -0700 To: Stephen Coy [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet Any clue why they fail? --jason Quoting Stephen Coy [EMAIL PROTECTED]: Hi, I raised a bug (#541855) about this a while ago, which has met a distressing amount of silence. In short, stateful session beans fail to passivate if they have EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, they fail to comply with 7.4.1 of the EJB 2.0 spec. I would tackle fixing this myself, but I don't yet know my way around inside the guts of JBoss well enough yet. Maybe one of the gurus can spend ten or fifteen minutes describing how to go about it - and then I'll be happy to write and test the implementation. Stephen Coy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/jca/test CachedConnectionBankStressTestCase.java CachedConnectionSessionUnitTestCase.java
User: d_jencks Date: 02/04/16 18:07:54 Removed: src/main/org/jboss/test/jca/test Tag: Branch_3_0 CachedConnectionBankStressTestCase.java CachedConnectionSessionUnitTestCase.java Log: These tests require new jca-jdbc wrappers to pass, and these won't be in jboss 3.0, so I am removing the tests from this branch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Change Notes-544913 ] Resultsets read in column order
Change Notes item #544913, was opened at 2002-04-16 18:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=544913group_id=22866 Category: JBossCMP Group: v2.4.5 Status: Open Priority: 5 Submitted By: Dan Christopherson (danch) Assigned to: Nobody/Anonymous (nobody) Summary: Resultsets read in column order Initial Comment: Applied patch #520200 to fix bug #517062. This related to some JDBC drivers (notably the free Microsoft SQL Server driver by Merant) requiring that columns be read in the order they are specified in the query. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=381174aid=544913group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Compile problem with iiop
I just fixed this on my windows box by installing the latest version of the JDK 1.3.1_03. -dain Vesco Claudio wrote: Hi! If I remember well, this is a problem with rmic but I have encontered this problem in WindowsNT sun jdk 1.3. You have said that you are in linux and linux are the Francisco's main development platform. In WindowsNT sun jdk 1.4 this problem go out. In order to obviate to the problem you can try to copy jboss-j2ee.jar in $JAVA_HOME/jre/lib/ext :-( Claudio -Original Message- From: David Jencks [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 6:43 AM To: jboss-dev Subject: [JBoss-dev] Compile problem with iiop Anyone else getting this from the iiop module? I have linux 2.4.16, jdk 1.3.1_03 from sun. Any advice? compile-rmi: Verify has been turned on. RMI Compiling 1 class to /usr/java/jboss/co12/jboss-all/iiop/output/classes IIOP has been turned on. java.lang.UnsatisfiedLinkError: hasStaticInitializer at com.sun.corba.ee.internal.io.ObjectStreamClass.hasStaticInitializer(Native Method) at com.sun.corba.ee.internal.io.ObjectStreamClass._computeSerialVersionUID(Ob jectStreamClass.java:943) at com.sun.corba.ee.internal.io.ObjectStreamClass.init(ObjectStreamClass.ja va:459) at com.sun.corba.ee.internal.io.ObjectStreamClass.lookupInternal(ObjectStream Class.java:139) at com.sun.corba.ee.internal.io.ObjectStreamClass.lookup(ObjectStreamClass.ja va:96) at com.sun.corba.ee.internal.io.ObjectStreamClass.lookupInternal(ObjectStream Class.java:133) at com.sun.corba.ee.internal.io.ObjectStreamClass.lookup(ObjectStreamClass.ja va:96) at com.sun.corba.ee.internal.io.ObjectStreamClass.getSerialVersionUID(ObjectS treamClass.java:159) at com.sun.corba.ee.internal.util.RepositoryId.clinit(RepositoryId.java:150 ) at sun.rmi.rmic.iiop.IDLNames.convertToISOLatin1(IDLNames.java:139) at sun.rmi.rmic.iiop.IDLNames.getClassOrInterfaceName(IDLNames.java:233) at sun.rmi.rmic.iiop.CompoundType.init(CompoundType.java:644) at sun.rmi.rmic.iiop.InterfaceType.init(InterfaceType.java:104) at sun.rmi.rmic.iiop.RemoteType.init(RemoteType.java:115) at sun.rmi.rmic.iiop.RemoteType.forRemote(RemoteType.java:79) at sun.rmi.rmic.iiop.StubGenerator.getTopType(StubGenerator.java:119) at sun.rmi.rmic.iiop.Generator.generate(Generator.java:262) at sun.rmi.rmic.Main.doCompile(Main.java:526) at sun.rmi.rmic.Main.compile(Main.java:133) at java.lang.reflect.Method.invoke(Native Method) at org.apache.tools.ant.taskdefs.rmic.SunRmic.execute(SunRmic.java:89) at org.apache.tools.ant.taskdefs.Rmic.execute(Rmic.java:397) 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) error: An error has occurred in the compiler; please file a bug report (http://java.sun.com/cgi-bin/bugreport.cgi). 1 error ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/etc/example-config db2-service.xml
User: d_jencks Date: 02/04/16 18:29:43 Added: src/etc/example-config db2-service.xml Log: merged from branch 3.0 Revision ChangesPath 1.2 +93 -0 jbosscx/src/etc/example-config/db2-service.xml ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 17-April-2002
Number of tests run: 563 Successful tests: 538 Errors:21 Failures: 4 [time of test: 17 April 2002 2:33 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1_02a-FCS] [java.vm.name: Java HotSpot(TM) Client VM] [java.vm.info: mixed mode] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/blackdown_jdk131_02_native 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-544778 ] generation of uni-directional CMR b0rked
Bugs item #544778, was opened at 2002-04-16 12:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=544778group_id=22866 Category: JBossCMP Group: CVS HEAD Status: Closed Resolution: Rejected Priority: 5 Submitted By: Christian Riege (lqd) Assigned to: Dain Sundstrom (dsundstrom) Summary: generation of uni-directional CMR b0rked Initial Comment: it seems that when trying to use a UNIdirectional CMR relationship JBossCMP insists on creating a foreign key field on BOTH sides of the relationship. this should not be; JBossCMP should ignore the side of the relationship where no cmr-field element is defined. snippet from ejb-jar.xml: ejb-relation ejb-relation-nameA-Uni-B/ejb-relation-name ejb-relationship-role ejb-relationship-role-namea-uni-b/ejb-relationship-role-name multiplicityOne/multiplicity relationship-role-source ejb-nameA/ejb-name /relationship-role-source cmr-field cmr-field-namefk_field/cmr-field-name /cmr-field /ejb-relationship-role ejb-relationship-role ejb-relationship-role-nameb-maps-a/ejb-relationship-role-name multiplicityOne/multiplicity relationship-role-source ejb-nameB/ejb-name /relationship-role-source /ejb-relationship-role /ejb-relation the tables created look like this: table_a a_id a_fk_field table_b b_id b_a_fk_field the field 'b_a_fk_field' should *not* be generated in my opinion as it is not declared in the deployment descriptor; i.e. it has no matching cmr-field entry. (jbosscmp-jdbc.xml is empty except for defaults element). tested against both jboss 3.0rc1 as well as CVS HEAD. -- Comment By: Dain Sundstrom (dsundstrom) Date: 2002-04-16 19:10 Message: Logged In: YES user_id=251431 As you said this is an opinion thing. I don't think it matters what the default is as long a it works and it can be overriden. If there is community support for this change I'll make it. I'm closing this, as it is not a bug. Start a discussion on the jboss-user list or in the db forum if you really want change. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=544778group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet
The silence was most likely due to a poor bug report . There is no selection of which version this applied to and no example demonstrating the problem. Start with a testcase that uses a custom container configuration to set a short passivation timeout. - Original Message - From: Stephen Coy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 16, 2002 5:23 PM Subject: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet Hi, I raised a bug (#541855) about this a while ago, which has met a distressing amount of silence. In short, stateful session beans fail to passivate if they have EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, they fail to comply with 7.4.1 of the EJB 2.0 spec. I would tackle fixing this myself, but I don't yet know my way around inside the guts of JBoss well enough yet. Maybe one of the gurus can spend ten or fifteen minutes describing how to go about it - and then I'll be happy to write and test the implementation. Stephen Coy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] RE: naming test failures
I don't know the ear spec very well. If you put: - module ejbnaminga.jar/ejb /module Should it be able to find naminga.jar in a subdirectory in the jar? -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 9:36 PM To: Bill Burke Subject: Re: naming test failures Then that is something different. - Original Message - From: Bill Burke [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Sent: Tuesday, April 16, 2002 6:18 PM Subject: RE: naming test failures Are you sure? THe ear doesn't even deploy. -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 9:20 PM To: Bill Burke Subject: Re: naming test failures No, but these are failing because we don't support cross ejb-jar links. - Original Message - From: Bill Burke [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Sent: Tuesday, April 16, 2002 6:03 PM Subject: naming test failures I'm looking into them, so let me know if you're doing the same. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RC1 release branch occuring at 00:00
-Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB -Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBS ngleton Any reason why the service can not set these props? Oops... Not really... This is much better indeed. I'll change the service to do it. If the JVM is an IBM one I also add $JBOSS_HOME/lib/jacorb.jar to the classpath. Why the special case for IBM? You're asking too many embarassing questions today, Jason... :-) I guess the answer is: because this way it works... In other words: I don't really know. Without jacorb.jar in the classpath, IBM VMs give me the following exception: 2002-04-16 21:55:19,323 DEBUG [org.jboss.deployment.MainDeployer] start step for deployment file:/home/reverbel/jboss-all/build/output/jboss-3.0.0beta2/server/d efault/deploy/iiop-service.xml 2002-04-16 21:55:19,324 DEBUG [org.jboss.deployment.SARDeployer] Deploying SAR, start step: url file:/home/reverbel/jboss-all/build/output/jboss-3.0.0beta2/serv er/default/deploy/iiop-service.xml 2002-04-16 21:55:19,324 INFO [org.jboss.iiop.CorbaORBService] Starting 2002-04-16 21:55:20,057 INFO [STDOUT] JacORB V 1.4 beta 4, www.jacorb.org 2002-04-16 21:55:20,058 INFO [STDOUT] (C) Gerald Brose, FU Berlin, March 2002 2002-04-16 21:55:21,527 ERROR [org.jboss.deployment.MainDeployer] could not star t deployment :file:/home/reverbel/jboss-all/build/output/jboss-3.0.0beta2/server /default/deploy/iiop-service.xml org.omg.CORBA.INITIALIZE: can't instantiate default ORB implementation org.jacorb.orb.ORBSingleton minor code: 0 completed: No at org.omg.CORBA.ORB.create_impl(ORB.java:330) at org.omg.CORBA.ORB.init(ORB.java:308) at org.omg.CONV_FRAME.CodeSetComponentInfoHelper.clinit(CodeSetCompone ntInfoHelper.java:12) at org.jacorb.orb.standardInterceptors.CodeSetInfoInterceptor.init(Cod eSetInfoInterceptor.java:41) at org.jacorb.orb.standardInterceptors.IORInterceptorInitializer.post_in it(IORInterceptorInitializer.java:43) at org.jacorb.orb.ORB.interceptorInit(ORB.java:1347) at org.jacorb.orb.ORB.set_parameters(ORB.java:1262) at org.omg.CORBA.ORB.init(ORB.java:389) at org.jboss.iiop.CorbaORBService.startService(CorbaORBService.java:124) at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:1 62) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBea nDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:492) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceControl ler.java:867) at $Proxy0.start(Unknown Source) ... (I'm on the forums. Pasted the stack trace to this little text input field in a web browser. Probably the stack trace will be badly reformatted. Anyway...) Sun VMs do not give me this exception. And I do not get the exception with an IBM VM if I put jacorb.jar in the classpath. There is some difference in classloader behavior I don't really understand. Cheers, Francisco * * * View thread online: http://main.jboss.org/thread.jsp?forum=66thread=12918 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/verifier/strategy EJBVerifier20.java
User: jwalters
Date: 02/04/16 18:46:43
Modified:src/main/org/jboss/verifier/strategy Tag: Branch_3_0
EJBVerifier20.java
Log:
Fixed bug #543693 where verifier didn't look into super classes for
various methods.
Revision ChangesPath
No revision
No revision
1.17.2.1 +5 -5 jboss/src/main/org/jboss/verifier/strategy/EJBVerifier20.java
Index: EJBVerifier20.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/verifier/strategy/EJBVerifier20.java,v
retrieving revision 1.17
retrieving revision 1.17.2.1
diff -u -r1.17 -r1.17.2.1
--- EJBVerifier20.java14 Apr 2002 12:00:07 - 1.17
+++ EJBVerifier20.java17 Apr 2002 01:46:43 - 1.17.2.1
@@ -19,7 +19,7 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* This package and its source code is available at www.jboss.org
- * $Id: EJBVerifier20.java,v 1.17 2002/04/14 12:00:07 jwalters Exp $
+ * $Id: EJBVerifier20.java,v 1.17.2.1 2002/04/17 01:46:43 jwalters Exp $
*/
@@ -49,7 +49,7 @@
*
* @author Juha Lindfors ([EMAIL PROTECTED])
* @author Jay Walters ([EMAIL PROTECTED])
- * @version $Revision: 1.17 $
+ * @version $Revision: 1.17.2.1 $
* @sinceJDK 1.3
*/
public class EJBVerifier20 extends AbstractVerifier {
@@ -1965,7 +1965,7 @@
fieldName.substring(1);
Class fieldType = null;
try {
- Method m = bean.getDeclaredMethod(getName, new
Class[0]);
+ Method m = bean.getMethod(getName, new Class[0]);
fieldType = m.getReturnType();
} catch (NoSuchMethodException nsme) {
fireSpecViolationEvent(entity, new Section(10.6.2.g));
@@ -1976,11 +1976,11 @@
Class[] args = new Class[1];
args[0] = fieldType;
try {
- Method m = bean.getDeclaredMethod(setName, args);
+ Method m = bean.getMethod(setName, args);
} catch (NoSuchMethodException nsme) {
args[0] = classloader.loadClass(java.util.Collection);
try {
- Method m = bean.getDeclaredMethod(setName,
args);
+ Method m = bean.getMethod(setName, args);
} catch (NoSuchMethodException nsme2) {
fireSpecViolationEvent(entity, new Section(10.6.2.h));
status = false;
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/etc/example-config db2-service.xml
User: d_jencks Date: 02/04/16 18:27:26 Added: src/etc/example-config Tag: Branch_3_0 db2-service.xml Log: contributed db2 local tx example, lost track of who submitted it. Please identify yourself so I can credit you. Revision ChangesPath No revision No revision 1.1.2.1 +93 -0 jbosscx/src/etc/example-config/Attic/db2-service.xml ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: RE: [JBoss-dev] Are we logging the exception enough!!!
Sounds very interesting and tempting but how do you propose someone do this without RW. This will require modifying a multitude of files. If someone does not have RW, the files will quickly become out of sync. The merge would be a nightmare. I would think the process would be in 2 steps. 1. Remove the redundant log statements. (low impact) 2. Then address the exceptions * * * View thread online: http://main.jboss.org/thread.jsp?forum=66thread=13067 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/naming/ear/META-INF application.xml
User: d_jencks Date: 02/04/16 18:54:34 Modified:src/resources/naming/ear/META-INF Tag: Branch_3_0 application.xml Log: include path to naminga.jar so it can be found after new EarDeployer strictness Revision ChangesPath No revision No revision 1.1.2.1 +1 -1 jbosstest/src/resources/naming/ear/META-INF/application.xml Index: application.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/naming/ear/META-INF/application.xml,v retrieving revision 1.1 retrieving revision 1.1.2.1 diff -u -r1.1 -r1.1.2.1 --- application.xml 17 Mar 2002 12:56:29 - 1.1 +++ application.xml 17 Apr 2002 01:54:34 - 1.1.2.1 @@ -4,7 +4,7 @@ display-namenaming ear test/display-name module - ejbnaminga.jar/ejb + ejbsubdir/naminga.jar/ejb /module module ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: naming test failures
No, but I fixed that already. I'm looking into the link support. david On 2002.04.16 21:41:52 -0400 Bill Burke wrote: I don't know the ear spec very well. If you put: - module ejbnaminga.jar/ejb /module Should it be able to find naminga.jar in a subdirectory in the jar? -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 9:36 PM To: Bill Burke Subject: Re: naming test failures Then that is something different. - Original Message - From: Bill Burke [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Sent: Tuesday, April 16, 2002 6:18 PM Subject: RE: naming test failures Are you sure? THe ear doesn't even deploy. -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 9:20 PM To: Bill Burke Subject: Re: naming test failures No, but these are failing because we don't support cross ejb-jar links. - Original Message - From: Bill Burke [EMAIL PROTECTED] To: Scott M Stark [EMAIL PROTECTED] Sent: Tuesday, April 16, 2002 6:03 PM Subject: naming test failures I'm looking into them, so let me know if you're doing the same. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] where is findInRange for perf test?
I can't find where it is implemented and I don't see it as a default finder in CMP 1.x or 2.x. org.jboss.test.perf.ejb.EntityBean doesn't have a method ejbFindInRange org.jboss.test.perf.interfaces.EntityHome.findInRange is the culprit. Thanks, Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-541855 ] Passivation of stateful sess beans fails
Bugs item #541855, was opened at 2002-04-10 15:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=541855group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Stephen Coy (scoy) Assigned to: Nobody/Anonymous (nobody) Summary: Passivation of stateful sess beans fails Initial Comment: Section 7.4.1 of the EJB2.0 spec says that EJBLocalHome and EJBLocalObject (amongst others) should be persisted during passivation. The code in org.jboss.ejb.plugins.SessionObjectOutputStream clearly doesn't do this yet. Someone needs to check and ifx this code for EJB2.0 conformance. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=541855group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb Container.java
User: patriot1burke Date: 02/04/16 19:44:13 Modified:src/main/org/jboss/ejb Container.java Log: don't set lockmanager to null. Passivation thread may be trying to access it on an undeploy. Revision ChangesPath 1.86 +2 -2 jboss/src/main/org/jboss/ejb/Container.java Index: Container.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/Container.java,v retrieving revision 1.85 retrieving revision 1.86 diff -u -r1.85 -r1.86 --- Container.java12 Apr 2002 19:30:41 - 1.85 +++ Container.java17 Apr 2002 02:44:13 - 1.86 @@ -82,7 +82,7 @@ * @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a. * @author a href=[EMAIL PROTECTED]Bill Burke/a * @author a href=mailto:[EMAIL PROTECTED];David Jencks/a -* @version $Revision: 1.85 $ +* @version $Revision: 1.86 $ ** pbRevisions:/b * * pb2001/07/26 bill burke:/b @@ -591,7 +591,7 @@ this.webClassLoader = null; this.localClassLoader = null; this.ejbModule = null; - this.lockManager = null; + // this.lockManager = null; Setting this to null causes AbstractCache to fail on undeployment this.methodPermissionsCache.clear(); } ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb Container.java
User: patriot1burke Date: 02/04/16 19:43:03 Modified:src/main/org/jboss/ejb Tag: Branch_3_0 Container.java Log: don't set lockmanager to null. Passivation thread may be trying to access it on an undeploy. Revision ChangesPath No revision No revision 1.85.2.1 +2 -2 jboss/src/main/org/jboss/ejb/Container.java Index: Container.java === RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/Container.java,v retrieving revision 1.85 retrieving revision 1.85.2.1 diff -u -r1.85 -r1.85.2.1 --- Container.java12 Apr 2002 19:30:41 - 1.85 +++ Container.java17 Apr 2002 02:43:03 - 1.85.2.1 @@ -82,7 +82,7 @@ * @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a. * @author a href=[EMAIL PROTECTED]Bill Burke/a * @author a href=mailto:[EMAIL PROTECTED];David Jencks/a -* @version $Revision: 1.85 $ +* @version $Revision: 1.85.2.1 $ ** pbRevisions:/b * * pb2001/07/26 bill burke:/b @@ -591,7 +591,7 @@ this.webClassLoader = null; this.localClassLoader = null; this.ejbModule = null; - this.lockManager = null; + // this.lockManager = null; Setting this to null causes AbstractCache to fail on undeployment this.methodPermissionsCache.clear(); } ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results: 17-April-2002
Number of tests run: 563 Successful tests: 534 Errors:22 Failures: 7 [time of test: 17 April 2002 3:51 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-02a-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [os.name: Linux] [os.arch: i386] [os.version: 2.4.9-31] See http://lubega.com/testarchive/blackdown_jdk131_02_green 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! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] where is findInRange for perf test?
The question is, how do you get a 2.4 testsuite? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of David Jencks Sent: Tuesday, April 16, 2002 11:03 PM To: Bill Burke Cc: Jboss-Dev Subject: Re: [JBoss-dev] where is findInRange for perf test? I could have sworn it was specified in a query in a jaws.xml but I sure can't find any trace of such a file. If you have a copy of the 2.4 testsuite you might look there. david jencks On 2002.04.16 22:18:51 -0400 Bill Burke wrote: I can't find where it is implemented and I don't see it as a default finder in CMP 1.x or 2.x. org.jboss.test.perf.ejb.EntityBean doesn't have a method ejbFindInRange org.jboss.test.perf.interfaces.EntityHome.findInRange is the culprit. Thanks, Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-543963 ] CMP Verifier doesn't check superclasses
Bugs item #543963, was opened at 2002-04-15 01:43
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=543963group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Stephen Coy (scoy)
Assigned to: Jay Walters (jwalters)
Summary: CMP Verifier doesn't check superclasses
Initial Comment:
If I have a base class bean:
public interface Applicant
extends javax.ejb.EJBObject
{
// ... various setters and getters
}
and a superclass:
public interface PrivateApplicant
extends Applicant
{
// ... various other setters and getters
}
then EJBVerifier20 does not check the superclass
for the presence of declared methods, resulting in:
Section: 10.6.2
Warning: The entity bean class must define a get
accessor for each CMP field.
etc.
Presumably, it should.
--
Comment By: Jay Walters (jwalters)
Date: 2002-04-16 21:48
Message:
Logged In: YES
user_id=183794
Fixed in the 3.0 branch. I'll put it into the CVS head
later this week.
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376685aid=543963group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-539096 ] Lack of Reasonable Error on Deployment
Bugs item #539096, was opened at 2002-04-03 23:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=539096group_id=22866 Category: None Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Peter Luttrell (objec) Assigned to: Jay Walters (jwalters) Summary: Lack of Reasonable Error on Deployment Initial Comment: I am using jboss3.0+tomcat the build from 02.22.2002. I just attempted to deploy an entity bean, where in the deployment descriptor, i specified the incorrect classname to one that did not exist. The messages on the console were just: [Bean Deployer] Deploying: file:/bla... In cases where something is as blatently wrong as a class name that does not exist in the jar file, normal users will expect somesort of error message. Maybe a ClassNotFoundException. -- Comment By: Jay Walters (jwalters) Date: 2002-04-16 21:49 Message: Logged In: YES user_id=183794 The EJB 2.0 verifier is in the 3.0 branch and it identifies this type of problem. -- Comment By: Peter Luttrell (objec) Date: 2002-04-05 00:27 Message: Logged In: YES user_id=472835 thanks. -- Comment By: Jay Walters (jwalters) Date: 2002-04-05 00:19 Message: Logged In: YES user_id=183794 The EJB 2.0 verifier currently doesn't work - it is stubbed out. I am working on this and will have a working verifier checked into the head by the end of the weekend. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=539096group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-544963 ] file: protocol incompatible with Sun's
Patches item #544963, was opened at 2002-04-16 19:12
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376687aid=544963group_id=22866
Category: JBossServer
Group: v3.0 Rabbit Hole
Status: Open
Resolution: None
Priority: 5
Submitted By: Larry Sanderson (lsanders)
Assigned to: Nobody/Anonymous (nobody)
Summary: file: protocol incompatible with Sun's
Initial Comment:
JBoss has overriden the file: protocol to provide
better lastModified information. The following code
works with the default file handler, but not with
JBoss:
[code]
URL parent = new URL(file:C:\some\directory\);
URL file = new URL(parent, myFile.txt);
[/code]
The problem is that the back-slashes are not converted
to forward-slashes, and the URL constructor does not
create a propper sub-URL. (If you println the URL
above, you get: file:myFile.txt, instead of the
correct: file:C:/some/directory/myFile.txt)
This patch is required to use the JCE libraries with
jdk1.4 and JBoss 3.0. The JCE classes have a hard-
coded reference to the URL: file:${java.home}
\jre\lib\security, and it attempts to access the
sub-file: US_export_policy.jar.
-Larry
Index:
common/src/main/org/jboss/net/protocol/file/Handler.jav
a
===
RCS file: /cvsroot/jboss/jboss-
common/src/main/org/jboss/net/protocol/file/Handler.jav
a,v
retrieving revision 1.1
diff -u -r1.1 Handler.java
---
common/src/main/org/jboss/net/protocol/file/Handler.jav
a 4 Apr 2002 22:20:22 - 1.1
+++
common/src/main/org/jboss/net/protocol/file/Handler.jav
a 17 Apr 2002 02:02:07 -
@@ -14,6 +14,7 @@
import java.net.URL;
import java.net.URLConnection;
import java.net.URLStreamHandler;
+import java.io.File;
/**
* A protocol handler for the 'file' protocol.
@@ -28,5 +29,10 @@
throws IOException
{
return new FileURLConnection(url);
+ }
+
+ protected void parseURL(URL url, String s, int i,
int j)
+ {
+ super.parseURL(url, s.replace
(File.separatorChar, '/'), i, j);
}
}
Index:
common/src/main/org/jboss/net/protocol/file/FileURLConn
ection.java
===
RCS file: /cvsroot/jboss/jboss-
common/src/main/org/jboss/net/protocol/file/FileURLConn
ection.java,v
retrieving revision 1.5
diff -u -r1.5 FileURLConnection.java
---
common/src/main/org/jboss/net/protocol/file/FileURLConn
ection.java 6 Apr 2002 05:19:35 - 1.5
+++
common/src/main/org/jboss/net/protocol/file/FileURLConn
ection.java 17 Apr 2002 02:00:18 -
@@ -41,7 +41,7 @@
{
super(url);
- file = new File(url.getFile());
+ file = new File(url.getPath().replace('/',
File.separatorChar).replace('|', ':'));
doOutput = false;
}
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detailatid=376687aid=544963group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet
Does the testsuite cover these? --jason Quoting Hunter Hillegas [EMAIL PROTECTED]: I think some part of them is not marked as serializable... From: Jason Dillon [EMAIL PROTECTED] Date: Tue, 16 Apr 2002 17:41:19 -0700 To: Stephen Coy [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet Any clue why they fail? --jason Quoting Stephen Coy [EMAIL PROTECTED]: Hi, I raised a bug (#541855) about this a while ago, which has met a distressing amount of silence. In short, stateful session beans fail to passivate if they have EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, they fail to comply with 7.4.1 of the EJB 2.0 spec. I would tackle fixing this myself, but I don't yet know my way around inside the guts of JBoss well enough yet. Maybe one of the gurus can spend ten or fifteen minutes describing how to go about it - and then I'll be happy to write and test the implementation. Stephen Coy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet
I think some part of them is not marked as serializable... From: Jason Dillon [EMAIL PROTECTED] Date: Tue, 16 Apr 2002 17:41:19 -0700 To: Stephen Coy [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet Any clue why they fail? --jason Quoting Stephen Coy [EMAIL PROTECTED]: Hi, I raised a bug (#541855) about this a while ago, which has met a distressing amount of silence. In short, stateful session beans fail to passivate if they have EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, they fail to comply with 7.4.1 of the EJB 2.0 spec. I would tackle fixing this myself, but I don't yet know my way around inside the guts of JBoss well enough yet. Maybe one of the gurus can spend ten or fifteen minutes describing how to go about it - and then I'll be happy to write and test the implementation. Stephen Coy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development - This mail sent through IMP: http://horde.org/imp/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet
Damn. I'm usually more careful than that. It must have been late. Anyway, I'm working up a test case which I'll attach to the bug report. On Wednesday, April 17, 2002, at 11:32 AM, Scott M Stark wrote: The silence was most likely due to a poor bug report . There is no selection of which version this applied to and no example demonstrating the problem. Start with a testcase that uses a custom container configuration to set a short passivation timeout. - Original Message - From: Stephen Coy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 16, 2002 5:23 PM Subject: [JBoss-dev] Stateful Session Beans are not EJB2.0 yet Hi, I raised a bug (#541855) about this a while ago, which has met a distressing amount of silence. In short, stateful session beans fail to passivate if they have EJBLocalObject or EJBLocalHome objects as instance fields. Therefore, they fail to comply with 7.4.1 of the EJB 2.0 spec. I would tackle fixing this myself, but I don't yet know my way around inside the guts of JBoss well enough yet. Maybe one of the gurus can spend ten or fifteen minutes describing how to go about it - and then I'll be happy to write and test the implementation. Stephen Coy ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] where is findInRange for perf test?
There never has been a definition for findInRange and jaws 1.1 returns an empty enumeration for this nonexistent finder so the tests in 2.4 don't appear to fail. It needs to be defined. - Original Message - From: Bill Burke [EMAIL PROTECTED] To: Jboss-Dev [EMAIL PROTECTED] Sent: Tuesday, April 16, 2002 7:18 PM Subject: [JBoss-dev] where is findInRange for perf test? I can't find where it is implemented and I don't see it as a default finder in CMP 1.x or 2.x. org.jboss.test.perf.ejb.EntityBean doesn't have a method ejbFindInRange org.jboss.test.perf.interfaces.EntityHome.findInRange is the culprit. Thanks, Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
