Re: [JBoss-dev] **README** - 'jboss-all' Structure Changes -**README**
All these name changes are basically just screwing around with semantic trivialities. Change these names back: mq -> messaging resource -> connector plastic -> j2ee and do not make any more name changes without discussing why it is necessary. - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: "Scott M Stark" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, February 16, 2002 11:46 PM Subject: Re: [JBoss-dev] **README** - 'jboss-all' Structure Changes -**README** > On Sat, 2002-02-16 at 23:29, Scott M Stark wrote: > > > > > > o Renamed 'messaging' to 'mq'. I don't know what I was thinking before > > >when I used messaging. Sorry. > > > > > Messaging is a better name than mq. > > I figured the jbossmq folks would want something mq-like back. I > personally don't care too much... just had trouble typing messaging. > > > > o Renamed 'connector' to 'resource' for clarity. > > > > > Connector is more clearly associated with the JCA than resource. > > Leave this as connector. > > JCA uses javax.resource.* for its packaging. They really should have > called it JRCA, since it is for connecting resources. > > If you don't mind I would like to keep it as resource, as it makes it > more logically to house standard adapters there. > > Basically its just a name, so I don't care too much. I only made these > changes because I thought that the current names were poor for what > types of bits live in them. > > > > o Renamed 'j2ee' to 'plastic' for clarity and to keep folks from > > >thinking that is a j2ee impl. It is just a module to hold our own > > >imitation/synthetic/copy/plastic versions of Sun's API's > > > > > What has plastic to do with standard j2ee interfaces? These are > > getting to be riduculous name changes so knock it off and change > > plastic back to j2ee. > > I figured someone was going to say something about this. I had noticed > that we are now providing JMX interfaces in a similar style to the j2ee > interfaces. Perhaps we will do the same in the future as well. So in > comes plastic, which is a module which only serves to hold these > implementations. > > Perhaps I had picked up a little bit of an urge to have some spiffy > macosx-like names from looking over the apple website lately. > > If you feel strongly about reverting I will. > > --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/system Server.java
User: starksm
Date: 02/02/17 00:40:45
Modified:src/main/org/jboss/system Server.java
Log:
Display the org.jboss java.lang.Package information as the version
and build info.
Revision ChangesPath
1.16 +138 -109 jboss/src/main/org/jboss/system/Server.java
Index: Server.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/system/Server.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- Server.java 15 Feb 2002 06:18:32 - 1.15
+++ Server.java 17 Feb 2002 08:40:45 - 1.16
@@ -29,17 +29,17 @@
/**
* The main container component of a JBoss server instance.
- *
+ *
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Jason Dillon
- * @version $Revision: 1.15 $
+ * @version $Revision: 1.16 $
*/
public class Server
- implements ServerMBean
+implements ServerMBean
{
/** Class logger */
- private static final BootstrapLogger log =
- BootstrapLogger.getLogger(Server.class);
+ private static final BootstrapLogger log =
+ BootstrapLogger.getLogger(Server.class);
/** Container for version information. */
private final Version version = Version.getInstance();
@@ -52,30 +52,27 @@
/** When the server was started. */
private final Date started;
-
+
/** The JVM shutdown hook */
private final ShutdownHook shutdownHook;
-
- /**
+
+ /**
* Creates a new instance of Server.
*
* @param config The basic configuration of the server instance.
*
* @throws Exception Failed to initialize server instance.
*/
- public Server(final ServerConfig config) throws Exception {
+ public Server(final ServerConfig config) throws Exception
+ {
if (config == null)
throw new IllegalArgumentException("config is null");
- boolean debug = log.isDebugEnabled();
-
- this.config = config;
- if (debug) {
- log.debug("Using config: " + config);
- }
+ Package mainPkg = Package.getPackage("org.jboss");
- log.info("JBoss (MX MicroKernel) " +
- version + " [" + version.getName() + "]");
+ this.config = config;
+ log.info("Using config: " + config);
+ log.info("JBoss Release: "+mainPkg.getImplementationTitle());
// remeber when we we started
started = new Date();
@@ -83,9 +80,7 @@
// Create the MBeanServer
server = MBeanServerFactory.createMBeanServer("jboss");
- if (debug) {
- log.debug("Created MBeanServer: " + server);
- }
+ log.debug("Created MBeanServer: " + server);
// Register server components
server.registerMBean(this, ServerMBean.OBJECT_NAME);
@@ -98,14 +93,12 @@
initBootLibraries();
// Create MBeanClassLoader for the base system
- ObjectName loaderName =
- new ObjectName("jboss.system", "service", "ServiceClassLoader");
+ ObjectName loaderName =
+ new ObjectName("jboss.system", "service", "ServiceClassLoader");
MBeanClassLoader mcl = new MBeanClassLoader(loaderName);
server.registerMBean(mcl, loaderName);
- if (debug) {
- log.debug("Registered service classloader: " + loaderName);
- }
+ log.debug("Registered service classloader: " + loaderName);
// Set ServiceClassLoader as classloader for the construction of
// the basic system
@@ -128,27 +121,26 @@
server.createMBean("org.jboss.system.Info", null, loaderName);
// Service Controller
- ObjectName controllerName =
- server.createMBean("org.jboss.system.ServiceController", null,
loaderName).getObjectName();
-
- if (debug) {
- log.debug("Registered service controller: " + controllerName);
- }
+ ObjectName controllerName =
+ server.createMBean("org.jboss.system.ServiceController", null,
loaderName).getObjectName();
+ log.debug("Registered service controller: " + controllerName);
// Install the shutdown hook
shutdownHook = new ShutdownHook(controllerName);
- try {
- Runtime.getRuntime().addShutdownHook(shutdownHook);
- log.debug("Shutdown hook added");
+ try
+ {
+ Runtime.getRuntime().addShutdownHook(shutdownHook);
+ log.debug("Shutdown hook added");
}
- catch (Exception e) {
- log.warn("Failed to add shutdown hook", e);
+ catch (Exception e)
+ {
+ log.warn("Failed to add shutdown hook", e);
}
// Main Deployer
- ObjectName mainDeployer =
- serv
[JBoss-dev] CVS update: jboss/src/etc/manifest connector-client-factory.mf rmi-adaptor.mf run.mf shutdown.mf stop.mf
User: starksm Date: 02/02/17 00:37:56 Modified:src/etc/manifest connector-client-factory.mf rmi-adaptor.mf run.mf shutdown.mf stop.mf Log: Include version and build information using the standard version package manifest headers Revision ChangesPath 1.2 +6 -0 jboss/src/etc/manifest/connector-client-factory.mf Index: connector-client-factory.mf === RCS file: /cvsroot/jboss/jboss/src/etc/manifest/connector-client-factory.mf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- connector-client-factory.mf 16 Feb 2002 01:33:26 - 1.1 +++ connector-client-factory.mf 17 Feb 2002 08:37:56 - 1.2 @@ -1,2 +1,8 @@ Main-Class: org.jboss.jmx.connector.TestClient Class-Path: ./ ./jmx-rmi-connector-client.jar ./jmx-ejb-connector-client.jar ./jmxri.jar ../lib/jmxri.jar ./jnp-client.jar ../lib/jnp-client.jar ./log4j.jar +Specification-Title: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ +Specification-Version: @version.major@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ +Specification-Vendor: JBoss Group, LLC +Implementation-Title: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ [EMAIL PROTECTED]@ +Implementation-Version: @version.major@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ Date:@build.id@ +Implementation-Vendor: JBoss Group, LLC 1.2 +6 -1 jboss/src/etc/manifest/rmi-adaptor.mf Index: rmi-adaptor.mf === RCS file: /cvsroot/jboss/jboss/src/etc/manifest/rmi-adaptor.mf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- rmi-adaptor.mf16 Feb 2002 01:33:26 - 1.1 +++ rmi-adaptor.mf17 Feb 2002 08:37:56 - 1.2 @@ -1,3 +1,8 @@ Main-Class: org.jboss.jmx.connector.rmi.TestServer Class-Path: ./ ./jmxri.jar ../lib/jmxri.jar ./jnpserver.jar ../lib/ext/jnpserver.jar ./log4j.jar - +Specification-Title: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ +Specification-Version: @version.major@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ +Specification-Vendor: JBoss Group, LLC +Implementation-Title: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ [EMAIL PROTECTED]@ +Implementation-Version: @version.major@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ Date:@build.id@ +Implementation-Vendor: JBoss Group, LLC 1.2 +6 -0 jboss/src/etc/manifest/run.mf Index: run.mf === RCS file: /cvsroot/jboss/jboss/src/etc/manifest/run.mf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- run.mf16 Feb 2002 01:33:26 - 1.1 +++ run.mf17 Feb 2002 08:37:56 - 1.2 @@ -1,2 +1,8 @@ Main-Class: org.jboss.Main Class-Path: ../lib/jmxri.jar ../lib/jboss-boot.jar ../lib/crimson.jar ../lib/jaxp.jar ../lib/getopt.jar +Specification-Title: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ +Specification-Version: @version.major@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ +Specification-Vendor: JBoss Group, LLC +Implementation-Title: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ [EMAIL PROTECTED]@ +Implementation-Version: @version.major@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ Date:@build.id@ +Implementation-Vendor: JBoss Group, LLC 1.2 +6 -0 jboss/src/etc/manifest/shutdown.mf Index: shutdown.mf === RCS file: /cvsroot/jboss/jboss/src/etc/manifest/shutdown.mf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- shutdown.mf 16 Feb 2002 01:33:26 - 1.1 +++ shutdown.mf 17 Feb 2002 08:37:56 - 1.2 @@ -1,2 +1,8 @@ Main-Class: org.jboss.Shutdown Class-Path: ../lib/getopt.jar +Specification-Title: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ +Specification-Version: @version.major@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ +Specification-Vendor: JBoss Group, LLC +Implementation-Title: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ [EMAIL PROTECTED]@ +Implementation-Version: @version.major@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ Date:@build.id@ +Implementation-Vendor: JBoss Group, LLC 1.2 +6 -0 jboss/src/etc/manifest/stop.mf Index: stop.mf === RCS file: /cvsroot/jboss/jboss/src/etc/manifest/stop.mf,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- stop.mf 16 Feb 2002 01:33:26 - 1.1 +++ stop.mf
[JBoss-dev] CVS update: build/jboss/etc version.mf
User: starksm Date: 02/02/17 00:39:57 Added: jboss/etc version.mf Log: A jar manifest template for including version and build information into jars using the standard package version manifest headers Revision ChangesPath 1.1 build/jboss/etc/version.mf Index: version.mf === Specification-Title: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ Specification-Version: @version.major@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ Specification-Vendor: JBoss Group, LLC Implementation-Title: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ [EMAIL PROTECTED]@ Implementation-Version: @version.major@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@version.tag@ Date:@build.id@ Implementation-Vendor: JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss build.xml
User: starksm
Date: 02/02/17 00:39:06
Modified:.build.xml
Log:
Incorporate the build information into the output jars
Revision ChangesPath
1.67 +28 -12jboss/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jboss/build.xml,v
retrieving revision 1.66
retrieving revision 1.67
diff -u -r1.66 -r1.67
--- build.xml 17 Feb 2002 06:13:29 - 1.66
+++ build.xml 17 Feb 2002 08:39:05 - 1.67
@@ -12,7 +12,7 @@
-
+
@@ -410,11 +410,24 @@
+
+
+
+
+
+
+
+
+
+
+
@@ -453,7 +466,7 @@
-
+
@@ -485,7 +498,7 @@
| This file is always local and contains the basic classed required
| to start the server and setup network service loading.
-->
-
+
@@ -511,7 +524,7 @@
-
+
@@ -533,7 +546,7 @@
+ manifest="${build.etc}/manifest/version.mf">
@@ -581,7 +594,8 @@
-
+
@@ -593,7 +607,8 @@
-
+
@@ -608,7 +623,8 @@
-
+
@@ -620,7 +636,7 @@
+ manifest="${build.etc}/manifest/version.mf">
@@ -632,8 +648,8 @@
-
-
+
@@ -677,7 +693,7 @@
+ manifest="${build.etc}/manifest/version.mf">
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] **README** - 'jboss-all' Structure Changes-**README**
You are right. I had a momentary lapse of reason (that lasted for more than a moment actually). I still think that we should find a better name for the j2ee module, but there is only real motivation to do that if we move the jmx and other apis in there too. My apologies for my lack of sensibility on this matter. I will have it fixed shortly. --jason On Sun, 2002-02-17 at 00:24, Scott M Stark wrote: > All these name changes are basically just screwing around > with semantic trivialities. Change these names back: > > mq -> messaging > resource -> connector > plastic -> j2ee > > and do not make any more name changes without discussing > why it is necessary. > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: "Scott M Stark" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Saturday, February 16, 2002 11:46 PM > Subject: Re: [JBoss-dev] **README** - 'jboss-all' Structure > Changes -**README** > > > > On Sat, 2002-02-16 at 23:29, Scott M Stark wrote: > > > > > > > > o Renamed 'messaging' to 'mq'. I don't know what I was thinking > before > > > >when I used messaging. Sorry. > > > > > > > Messaging is a better name than mq. > > > > I figured the jbossmq folks would want something mq-like back. I > > personally don't care too much... just had trouble typing messaging. > > > > > > o Renamed 'connector' to 'resource' for clarity. > > > > > > > Connector is more clearly associated with the JCA than resource. > > > Leave this as connector. > > > > JCA uses javax.resource.* for its packaging. They really should have > > called it JRCA, since it is for connecting resources. > > > > If you don't mind I would like to keep it as resource, as it makes it > > more logically to house standard adapters there. > > > > Basically its just a name, so I don't care too much. I only made these > > changes because I thought that the current names were poor for what > > types of bits live in them. > > > > > > o Renamed 'j2ee' to 'plastic' for clarity and to keep folks from > > > >thinking that is a j2ee impl. It is just a module to hold our own > > > >imitation/synthetic/copy/plastic versions of Sun's API's > > > > > > > What has plastic to do with standard j2ee interfaces? These are > > > getting to be riduculous name changes so knock it off and change > > > plastic back to j2ee. > > > > I figured someone was going to say something about this. I had noticed > > that we are now providing JMX interfaces in a similar style to the j2ee > > interfaces. Perhaps we will do the same in the future as well. So in > > comes plastic, which is a module which only serves to hold these > > implementations. > > > > Perhaps I had picked up a little bit of an urge to have some spiffy > > macosx-like names from looking over the apple website lately. > > > > If you feel strongly about reverting I will. > > > > --jason > > > > ___ > 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] [AUTOMATED] JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE location: package ejb import javax.ejb.EJBObject; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/StatefulSessionContainer.java:18: cannot resolve symbol symbol : class EJBLocalObject location: package ejb import javax.ejb.EJBLocalObject; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/StatefulSessionContainer.java:19: cannot resolve symbol symbol : class EJBLocalHome location: package ejb import javax.ejb.EJBLocalHome; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/StatefulSessionContainer.java:20: cannot resolve symbol symbol : class EJBHome location: package ejb import javax.ejb.EJBHome; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/StatefulSessionContainer.java:21: cannot resolve symbol symbol : class EJBMetaData location: package ejb import javax.ejb.EJBMetaData; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/StatefulSessionContainer.java:22: cannot resolve symbol symbol : class RemoveException location: package ejb import javax.ejb.RemoveException; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/StatefulSessionContainer.java:23: cannot resolve symbol symbol : class EJBException location: package ejb import javax.ejb.EJBException; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:214: warning: java.security.Identity in java.security has been deprecated public Identity getCallerIdentity() ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:340: warning: java.security.Identity in java.security has been deprecated public boolean isCallerInRole(Identity id) ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:340: warning: java.security.Identity in java.security has been deprecated public boolean isCallerInRole(Identity id) ^ 100 errors 4 warnings BUILD FAILED /disk/orig/home/lubega/jbossro/jboss-all/server/build.xml:366: Compile failed, messages should have been provided. Total time: 1 minute 2 seconds ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] log4j.xml
I was able to get the xml configuration parser to use the trace priority. Any reason why we should not switch to the xml version of the configuration? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [AUTOMATED] JBoss compilation failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE location: package ejb import javax.ejb.EJBObject; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/StatefulSessionContainer.java:18: cannot resolve symbol symbol : class EJBLocalObject location: package ejb import javax.ejb.EJBLocalObject; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/StatefulSessionContainer.java:19: cannot resolve symbol symbol : class EJBLocalHome location: package ejb import javax.ejb.EJBLocalHome; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/StatefulSessionContainer.java:20: cannot resolve symbol symbol : class EJBHome location: package ejb import javax.ejb.EJBHome; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/StatefulSessionContainer.java:21: cannot resolve symbol symbol : class EJBMetaData location: package ejb import javax.ejb.EJBMetaData; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/StatefulSessionContainer.java:22: cannot resolve symbol symbol : class RemoveException location: package ejb import javax.ejb.RemoveException; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/StatefulSessionContainer.java:23: cannot resolve symbol symbol : class EJBException location: package ejb import javax.ejb.EJBException; ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:214: warning: java.security.Identity in java.security has been deprecated public Identity getCallerIdentity() ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:340: warning: java.security.Identity in java.security has been deprecated public boolean isCallerInRole(Identity id) ^ /disk/orig/home/lubega/jbossro/jboss-all/server/src/main/org/jboss/ejb/EnterpriseContext.java:340: warning: java.security.Identity in java.security has been deprecated public boolean isCallerInRole(Identity id) ^ 100 errors 4 warnings BUILD FAILED /disk/orig/home/lubega/jbossro/jboss-all/server/build.xml:366: Compile failed, messages should have been provided. Total time: 1 minute 8 seconds ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: CVSROOT modules
User: user57 Date: 02/02/17 01:50:09 Modified:.modules Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.95 +3 -8 CVSROOT/modules Index: modules === RCS file: /cvsroot/jboss/CVSROOT/modules,v retrieving revision 1.94 retrieving revision 1.95 diff -u -r1.94 -r1.95 --- modules 17 Feb 2002 04:41:39 - 1.94 +++ modules 17 Feb 2002 09:50:09 - 1.95 @@ -40,14 +40,11 @@ ## _jboss_build-d buildbuild/jboss -_jboss_plastic -d plastic jboss-j2ee _jboss_common -d common jboss-common _jboss_system -d system jboss-system _jboss_ejb -d ejb jboss-ejb _jboss_server -d server jboss _jboss_naming -d naming jnp -_jboss_resource -d resource jbosscx -_jboss_mq -d mq jbossmq _jboss_security -d security jbosssx _jboss_testsuite-d testsuitejbosstest _jboss_pool -d pool jbosspool @@ -60,8 +57,6 @@ _jboss_catalina -d catalina contrib/catalina _jboss_jboss.net-d jboss.netcontrib/jboss.net _jboss_iiop -d iiop contrib/iiop - -# deprecated _jboss_connector-d connectorjbosscx _jboss_j2ee -d j2ee jboss-j2ee _jboss_messaging-d messagingjbossmq @@ -94,15 +89,15 @@ jboss-all-modules -a \ _jboss_build \ -_jboss_plastic \ +_jboss_j2ee \ _jboss_common \ _jboss_system \ _jboss_naming \ _jboss_server \ _jboss_ejb \ _jboss_pool \ -_jboss_resource \ -_jboss_mq \ +_jboss_connector \ +_jboss_messaging \ _jboss_security \ _jboss_cluster \ _jboss_admin \ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: admin/src/bin EJBVerifier.bat EJBVerifier.sh InvocationLog.bat InvocationLog.sh JNDIBrowser.bat JNDIBrowser.sh Monitor.bat Monitor.sh SystemLog.bat SystemLog.sh adminlogin.bat adminlogin.sh
User: user57 Date: 02/02/17 01:52:53 Modified:src/bin EJBVerifier.bat EJBVerifier.sh InvocationLog.bat InvocationLog.sh JNDIBrowser.bat JNDIBrowser.sh Monitor.bat Monitor.sh SystemLog.bat SystemLog.sh adminlogin.bat adminlogin.sh Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.4 +2 -2 admin/src/bin/EJBVerifier.bat Index: EJBVerifier.bat === RCS file: /cvsroot/jboss/admin/src/bin/EJBVerifier.bat,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- EJBVerifier.bat 17 Feb 2002 04:22:23 - 1.3 +++ EJBVerifier.bat 17 Feb 2002 09:52:53 - 1.4 @@ -6,7 +6,7 @@ REMBatch file for running the JBoss EJB Verifier. REM REMAuthor:Juha Lindfors -REMRevision: $Id: EJBVerifier.bat,v 1.3 2002/02/17 04:22:23 user57 Exp $ +REMRevision: $Id: EJBVerifier.bat,v 1.4 2002/02/17 09:52:53 user57 Exp $ REM REM @@ -20,7 +20,7 @@ :SetClasspath set CP=.;..\classes -set CP=%CP%;..\lib\jboss-plastic-j2ee.jar +set CP=%CP%;..\lib\jboss-j2ee.jar set CP=%CP%;..\lib\jta-spec1_0_1.jar set CP=%CP%;..\lib\jnp-client.jar set CP=%CP%;..\lib\jbossmq-client.jar 1.3 +1 -1 admin/src/bin/EJBVerifier.sh Index: EJBVerifier.sh === RCS file: /cvsroot/jboss/admin/src/bin/EJBVerifier.sh,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- EJBVerifier.sh17 Feb 2002 04:22:23 - 1.2 +++ EJBVerifier.sh17 Feb 2002 09:52:53 - 1.3 @@ -4,7 +4,7 @@ CP=.:../classes -CP=$CP:../lib/jboss-plastic-j2ee.jar +CP=$CP:../lib/jboss-j2ee.jar CP=$CP:../lib/jta-spec1_0_1.jar CP=$CP:../lib/jnp-client.jar CP=$CP:../lib/jbossmq-client.jar 1.4 +2 -2 admin/src/bin/InvocationLog.bat Index: InvocationLog.bat === RCS file: /cvsroot/jboss/admin/src/bin/InvocationLog.bat,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- InvocationLog.bat 17 Feb 2002 04:22:23 - 1.3 +++ InvocationLog.bat 17 Feb 2002 09:52:53 - 1.4 @@ -6,7 +6,7 @@ REMBatch file for running invocation log tool. REM REMAuthor:Juha Lindfors -REMRevision: $Id: InvocationLog.bat,v 1.3 2002/02/17 04:22:23 user57 Exp $ +REMRevision: $Id: InvocationLog.bat,v 1.4 2002/02/17 09:52:53 user57 Exp $ REM REM @@ -19,7 +19,7 @@ :SetClasspath set CP=.;..\classes -set CP=%CP%;..\lib\jboss-plastic-j2ee.jar +set CP=%CP%;..\lib\jboss-j2ee.jar set CP=%CP%;..\lib\jta-spec1_0_1.jar set CP=%CP%;..\lib\jnp-client.jar set CP=%CP%;..\lib\jbossmq-client.jar 1.3 +1 -1 admin/src/bin/InvocationLog.sh Index: InvocationLog.sh === RCS file: /cvsroot/jboss/admin/src/bin/InvocationLog.sh,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- InvocationLog.sh 17 Feb 2002 04:22:23 - 1.2 +++ InvocationLog.sh 17 Feb 2002 09:52:53 - 1.3 @@ -4,7 +4,7 @@ CP=.:../classes -CP=$CP:../lib/jboss-plastic-j2ee.jar +CP=$CP:../lib/jboss-j2ee.jar CP=$CP:../lib/jta-spec1_0_1.jar CP=$CP:../lib/jnp-client.jar CP=$CP:../lib/jbossmq-client.jar 1.4 +2 -2 admin/src/bin/JNDIBrowser.bat Index: JNDIBrowser.bat === RCS file: /cvsroot/jboss/admin/src/bin/JNDIBrowser.bat,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- JNDIBrowser.bat 17 Feb 2002 04:22:23 - 1.3 +++ JNDIBrowser.bat 17 Feb 2002 09:52:53 - 1.4 @@ -6,7 +6,7 @@ REMBatch file for running the JBoss JNDI Browser. REM REMAuthor:Juha Lindfors -REMRevision: $Id: JNDIBrowser.bat,v 1.3 2002/02/17 04:22:23 user57 Exp $ +REMRevision: $Id: JNDIBrowser.bat,v 1.4 2002/02/17 09:52:53 user57 Exp $ REM REM @@ -20,7 +20,7 @@ :SetClasspath set CP=.;..\classes -set CP=%CP%;..\lib\jboss-plastic-j2ee.jar +set CP=%CP%;..\lib\jboss-j2ee.jar set CP=%CP%;..\lib\jta-spec1_0_1.jar set CP=%CP%;..\lib\jnp-client.jar set CP=%CP%;..\lib\jbossmq-client.jar 1.3 +1 -1 admin/src/bin/JNDIBrowser.sh Index: JNDIBrowser.sh === RCS file: /cvsroot/jboss/admin/src/bin/JNDIBrowser.sh,v re
[JBoss-dev] CVS update: admin/src/etc monitor.mf
User: user57 Date: 02/02/17 01:52:54 Modified:src/etc monitor.mf Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.4 +1 -1 admin/src/etc/monitor.mf Index: monitor.mf === RCS file: /cvsroot/jboss/admin/src/etc/monitor.mf,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- monitor.mf17 Feb 2002 04:22:23 - 1.3 +++ monitor.mf17 Feb 2002 09:52:54 - 1.4 @@ -1,2 +1,2 @@ Main-Class: org.jboss.admin.monitor.Main -Class-Path: .. jboss-plastic-j2ee.jar jta-spec1_0_1.jar jnp-client.jar jbossmq-client.jar jpl-util-0_6b.jar jboss-util.jar +Class-Path: .. jboss-j2ee.jar jta-spec1_0_1.jar jnp-client.jar jbossmq-client.jar jpl-util-0_6b.jar jboss-util.jar ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: admin build.xml
User: user57 Date: 02/02/17 01:52:53 Modified:.build.xml Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.17 +7 -7 admin/build.xml Index: build.xml === RCS file: /cvsroot/jboss/admin/build.xml,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- build.xml 17 Feb 2002 04:22:23 - 1.16 +++ build.xml 17 Feb 2002 09:52:53 - 1.17 @@ -12,7 +12,7 @@ - + @@ -119,11 +119,11 @@ - - - - - + + + + + @@ -142,7 +142,7 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/catalina build.xml
User: user57 Date: 02/02/17 01:52:54 Modified:catalina build.xml Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.6 +7 -7 contrib/catalina/build.xml Index: build.xml === RCS file: /cvsroot/jboss/contrib/catalina/build.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- build.xml 17 Feb 2002 04:22:23 - 1.5 +++ build.xml 17 Feb 2002 09:52:54 - 1.6 @@ -12,7 +12,7 @@ - + @@ -113,11 +113,11 @@ - - - - - + + + + + @@ -140,7 +140,7 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: build/jboss build.xml fix-workspace.xml
User: user57 Date: 02/02/17 01:52:54 Modified:jbossbuild.xml fix-workspace.xml Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.83 +27 -27build/jboss/build.xml Index: build.xml === RCS file: /cvsroot/jboss/build/jboss/build.xml,v retrieving revision 1.82 retrieving revision 1.83 diff -u -r1.82 -r1.83 --- build.xml 17 Feb 2002 06:13:28 - 1.82 +++ build.xml 17 Feb 2002 09:52:54 - 1.83 @@ -12,7 +12,7 @@ - + @@ -168,7 +168,7 @@ - + @@ -176,8 +176,8 @@ - - + + @@ -191,7 +191,7 @@ - @@ -200,9 +200,9 @@ - + + @@ -342,7 +342,7 @@ - + @@ -350,12 +350,12 @@ - + - + @@ -691,12 +691,12 @@ - - - + + + - - + + @@ -717,7 +717,7 @@ - + @@ -727,12 +727,12 @@ - - - + + + - - + + @@ -774,7 +774,7 @@ - + 1.8 +1 -13 build/jboss/fix-workspace.xml Index: fix-workspace.xml === RCS file: /cvsroot/jboss/build/jboss/fix-workspace.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- fix-workspace.xml 17 Feb 2002 04:17:24 - 1.7 +++ fix-workspace.xml 17 Feb 2002 09:52:54 - 1.8 @@ -12,7 +12,7 @@ - + @@ -89,18 +89,6 @@ - - - - - - - - - - - - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmx build.xml
User: user57 Date: 02/02/17 01:52:54 Modified:.build.xml Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.28 +13 -13jbossmx/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbossmx/build.xml,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- build.xml 17 Feb 2002 04:22:23 - 1.27 +++ build.xml 17 Feb 2002 09:52:54 - 1.28 @@ -12,7 +12,7 @@ - + @@ -145,11 +145,11 @@ - - - - - + + + + + @@ -166,11 +166,11 @@ - - - - - + + + + + @@ -182,10 +182,10 @@ - + - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty build.xml
User: user57 Date: 02/02/17 01:52:55 Modified:jettybuild.xml Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.36 +6 -6 contrib/jetty/build.xml Index: build.xml === RCS file: /cvsroot/jboss/contrib/jetty/build.xml,v retrieving revision 1.35 retrieving revision 1.36 diff -u -r1.35 -r1.36 --- build.xml 17 Feb 2002 04:22:24 - 1.35 +++ build.xml 17 Feb 2002 09:52:55 - 1.36 @@ -155,11 +155,11 @@ - - - - - + + + + + @@ -189,7 +189,7 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jboss.net/testsuite build.xml
User: user57 Date: 02/02/17 01:52:55 Modified:jboss.net/testsuite build.xml Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.5 +13 -13contrib/jboss.net/testsuite/build.xml Index: build.xml === RCS file: /cvsroot/jboss/contrib/jboss.net/testsuite/build.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- build.xml 17 Feb 2002 04:22:24 - 1.4 +++ build.xml 17 Feb 2002 09:52:55 - 1.5 @@ -10,7 +10,7 @@ - + @@ -262,11 +262,11 @@ - - - - - + + + + + @@ -285,11 +285,11 @@ - - - - - + + + + + @@ -325,10 +325,10 @@ - + - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty/src/resources/jetty-plugin/META-INF jboss-service.xml
User: user57 Date: 02/02/17 01:52:55 Modified:jetty/src/resources/jetty-plugin/META-INF jboss-service.xml Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.17 +1 -1 contrib/jetty/src/resources/jetty-plugin/META-INF/jboss-service.xml Index: jboss-service.xml === RCS file: /cvsroot/jboss/contrib/jetty/src/resources/jetty-plugin/META-INF/jboss-service.xml,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- jboss-service.xml 17 Feb 2002 04:22:24 - 1.16 +++ jboss-service.xml 17 Feb 2002 09:52:55 - 1.17 @@ -30,6 +30,6 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jboss.net build.xml
User: user57 Date: 02/02/17 01:52:55 Modified:jboss.net build.xml Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.11 +7 -7 contrib/jboss.net/build.xml Index: build.xml === RCS file: /cvsroot/jboss/contrib/jboss.net/build.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- build.xml 17 Feb 2002 04:22:24 - 1.10 +++ build.xml 17 Feb 2002 09:52:54 - 1.11 @@ -12,7 +12,7 @@ - + @@ -129,11 +129,11 @@ - - - - - + + + + + @@ -146,7 +146,7 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq build.xml
User: user57 Date: 02/02/17 01:52:55 Modified:.build.xml Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.22 +10 -10jbossmq/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbossmq/build.xml,v retrieving revision 1.21 retrieving revision 1.22 diff -u -r1.21 -r1.22 --- build.xml 17 Feb 2002 04:22:24 - 1.21 +++ build.xml 17 Feb 2002 09:52:55 - 1.22 @@ -12,9 +12,9 @@ - + - + @@ -61,8 +61,8 @@ - - + + @@ -147,11 +147,11 @@ - - - - - + + + + + @@ -184,7 +184,7 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-j2ee build.xml
User: user57 Date: 02/02/17 01:52:55 Modified:.build.xml Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.15 +6 -6 jboss-j2ee/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss-j2ee/build.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- build.xml 17 Feb 2002 04:22:24 - 1.14 +++ build.xml 17 Feb 2002 09:52:55 - 1.15 @@ -12,9 +12,9 @@ - + - + @@ -61,8 +61,8 @@ - - + + @@ -200,8 +200,8 @@ - - + + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx build.xml
User: user57 Date: 02/02/17 01:52:56 Modified:.build.xml Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.24 +10 -10jbosscx/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosscx/build.xml,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- build.xml 17 Feb 2002 06:13:29 - 1.23 +++ build.xml 17 Feb 2002 09:52:56 - 1.24 @@ -12,9 +12,9 @@ - + - + @@ -61,8 +61,8 @@ - - + + @@ -119,11 +119,11 @@ - - - - - + + + + + @@ -149,7 +149,7 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx build.xml
User: user57 Date: 02/02/17 01:52:56 Modified:.build.xml Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.17 +7 -7 jbosssx/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosssx/build.xml,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- build.xml 17 Feb 2002 04:22:25 - 1.16 +++ build.xml 17 Feb 2002 09:52:56 - 1.17 @@ -12,7 +12,7 @@ - + @@ -147,11 +147,11 @@ - - - - - + + + + + @@ -178,7 +178,7 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosspool build.xml
User: user57 Date: 02/02/17 01:52:56 Modified:.build.xml Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.16 +7 -7 jbosspool/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosspool/build.xml,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- build.xml 17 Feb 2002 04:22:24 - 1.15 +++ build.xml 17 Feb 2002 09:52:55 - 1.16 @@ -12,7 +12,7 @@ - + @@ -119,11 +119,11 @@ - - - - - + + + + + @@ -143,7 +143,7 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/etc/manifest ejb-connector-client.mf ejb-connector.mf jboss-client.mf verifier.mf
User: user57 Date: 02/02/17 01:52:52 Modified:src/etc/manifest ejb-connector-client.mf ejb-connector.mf jboss-client.mf verifier.mf Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.3 +1 -1 jboss/src/etc/manifest/ejb-connector-client.mf Index: ejb-connector-client.mf === RCS file: /cvsroot/jboss/jboss/src/etc/manifest/ejb-connector-client.mf,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ejb-connector-client.mf 17 Feb 2002 04:22:25 - 1.2 +++ ejb-connector-client.mf 17 Feb 2002 09:52:52 - 1.3 @@ -1 +1 @@ -Class-Path: ./ ./jmxri.jar ../lib/jmxri.jar ./jnp-client.jar ./jboss-plastic-j2ee.jar ./jboss-client.jar ./jbossmq-client.jar ./log4j.jar +Class-Path: ./ ./jmxri.jar ../lib/jmxri.jar ./jnp-client.jar ./jboss-j2ee.jar ./jboss-client.jar ./jbossmq-client.jar ./log4j.jar 1.3 +1 -1 jboss/src/etc/manifest/ejb-connector.mf Index: ejb-connector.mf === RCS file: /cvsroot/jboss/jboss/src/etc/manifest/ejb-connector.mf,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- ejb-connector.mf 17 Feb 2002 04:22:25 - 1.2 +++ ejb-connector.mf 17 Feb 2002 09:52:52 - 1.3 @@ -1,2 +1,2 @@ Main-Class: org.jboss.jmx.connector.ejb.TestClient -Class-Path: ./ ../lib/jmxri.jar ./jnp-client.jar ./jboss-plastic-j2ee.jar ./jboss-client.jar ./jbossmq-client.jar ./log4j.jar +Class-Path: ./ ../lib/jmxri.jar ./jnp-client.jar ./jboss-j2ee.jar ./jboss-client.jar ./jbossmq-client.jar ./log4j.jar 1.3 +1 -1 jboss/src/etc/manifest/jboss-client.mf Index: jboss-client.mf === RCS file: /cvsroot/jboss/jboss/src/etc/manifest/jboss-client.mf,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jboss-client.mf 17 Feb 2002 04:22:25 - 1.2 +++ jboss-client.mf 17 Feb 2002 09:52:52 - 1.3 @@ -1 +1 @@ -Class-Path: jnp-client.jar jbosssx-client.jar jboss-plastic-j2ee.jar jndi.jar +Class-Path: jnp-client.jar jbosssx-client.jar jboss-j2ee.jar jndi.jar 1.3 +1 -1 jboss/src/etc/manifest/verifier.mf Index: verifier.mf === RCS file: /cvsroot/jboss/jboss/src/etc/manifest/verifier.mf,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- verifier.mf 17 Feb 2002 04:22:25 - 1.2 +++ verifier.mf 17 Feb 2002 09:52:52 - 1.3 @@ -1,2 +1,2 @@ Main-Class: org.jboss.verifier.Main -Class-Path: ../lib/ext/jpl-util-0_5b.jar ../client/jboss-plastic-j2ee.jar ../lib/jaxp.jar ../lib/crimson.jar ../external/metadata.jar +Class-Path: ../lib/ext/jpl-util-0_5b.jar ../client/jboss-j2ee.jar ../lib/jaxp.jar ../lib/crimson.jar ../external/metadata.jar ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest build.xml
User: user57 Date: 02/02/17 01:52:52 Modified:.build.xml Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.70 +13 -13jbosstest/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosstest/build.xml,v retrieving revision 1.69 retrieving revision 1.70 diff -u -r1.69 -r1.70 --- build.xml 17 Feb 2002 04:22:25 - 1.69 +++ build.xml 17 Feb 2002 09:52:52 - 1.70 @@ -27,7 +27,7 @@ - + @@ -187,11 +187,11 @@ - - - - - + + + + + @@ -217,11 +217,11 @@ - - - - - + + + + + @@ -248,11 +248,11 @@ - + - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/bin jmx-test.sh testbeantest.sh
User: user57 Date: 02/02/17 01:52:53 Modified:src/bin jmx-test.sh testbeantest.sh Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.3 +2 -2 jbosstest/src/bin/jmx-test.sh Index: jmx-test.sh === RCS file: /cvsroot/jboss/jbosstest/src/bin/jmx-test.sh,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jmx-test.sh 17 Feb 2002 04:22:25 - 1.2 +++ jmx-test.sh 17 Feb 2002 09:52:52 - 1.3 @@ -1,5 +1,5 @@ #! /bin/sh -# $Id: jmx-test.sh,v 1.2 2002/02/17 04:22:25 user57 Exp $ +# $Id: jmx-test.sh,v 1.3 2002/02/17 09:52:52 user57 Exp $ TARGET_CLASSPATH=../lib/junit.jar @@ -9,7 +9,7 @@ TARGET_CLASSPATH=$TARGET_CLASSPATH:../lib/jnp-client.jar TARGET_CLASSPATH=$TARGET_CLASSPATH:../lib/connector.jar TARGET_CLASSPATH=$TARGET_CLASSPATH:../lib/testjmx.jar -TARGET_CLASSPATH=$TARGET_CLASSPATH:../lib/jboss-plastic-j2ee.jar +TARGET_CLASSPATH=$TARGET_CLASSPATH:../lib/jboss-j2ee.jar TARGET_CLASSPATH=$TARGET_CLASSPATH:../lib/jboss-client.jar DEPLOY_PATH=../deploy 1.5 +1 -1 jbosstest/src/bin/testbeantest.sh Index: testbeantest.sh === RCS file: /cvsroot/jboss/jbosstest/src/bin/testbeantest.sh,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- testbeantest.sh 17 Feb 2002 04:22:25 - 1.4 +++ testbeantest.sh 17 Feb 2002 09:52:52 - 1.5 @@ -8,7 +8,7 @@ CLASSPATH="$LIB_DIR/junit.jar:$CLASSPATH" CLASSPATH="$LIB_DIR/jndi.jar:$CLASSPATH" CLASSPATH="$LIB_DIR/jnp-client.jar:$CLASSPATH" -CLASSPATH="$LIB_DIR/jboss-plastic-j2ee.jar:$CLASSPATH" +CLASSPATH="$LIB_DIR/jboss-j2ee.jar:$CLASSPATH" CLASSPATH="$LIB_DIR/jboss-client.jar:$CLASSPATH" CLASSPATH="$LIB_DIR/jbossmq-client.jar:$CLASSPATH" CLASSPATH="$LIB_DIR/jaas.jar:$CLASSPATH" ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss build.xml
User: user57 Date: 02/02/17 01:52:52 Modified:.build.xml Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.68 +7 -7 jboss/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss/build.xml,v retrieving revision 1.67 retrieving revision 1.68 diff -u -r1.67 -r1.68 --- build.xml 17 Feb 2002 08:39:05 - 1.67 +++ build.xml 17 Feb 2002 09:52:51 - 1.68 @@ -12,7 +12,7 @@ - + @@ -188,11 +188,11 @@ - - - - - + + + + + @@ -211,7 +211,7 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/varia build.xml
User: user57 Date: 02/02/17 01:52:53 Modified:variabuild.xml Log: o revert to j2ee, connector & messaging Revision ChangesPath 1.23 +7 -7 contrib/varia/build.xml Index: build.xml === RCS file: /cvsroot/jboss/contrib/varia/build.xml,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- build.xml 17 Feb 2002 04:22:25 - 1.22 +++ build.xml 17 Feb 2002 09:52:53 - 1.23 @@ -12,7 +12,7 @@ - + @@ -207,11 +207,11 @@ - - - - - + + + + + @@ -237,7 +237,7 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] **README** - 'jboss-all' Structure Changes-**README**
This is done. --jason On Sun, 2002-02-17 at 00:39, Jason Dillon wrote: > You are right. I had a momentary lapse of reason (that lasted for more > than a moment actually). > > I still think that we should find a better name for the j2ee module, but > there is only real motivation to do that if we move the jmx and other > apis in there too. > > My apologies for my lack of sensibility on this matter. I will have it > fixed shortly. > > --jason > > > On Sun, 2002-02-17 at 00:24, Scott M Stark wrote: > > All these name changes are basically just screwing around > > with semantic trivialities. Change these names back: > > > > mq -> messaging > > resource -> connector > > plastic -> j2ee > > > > and do not make any more name changes without discussing > > why it is necessary. > > > > - Original Message - > > From: "Jason Dillon" <[EMAIL PROTECTED]> > > To: "Scott M Stark" <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]> > > Sent: Saturday, February 16, 2002 11:46 PM > > Subject: Re: [JBoss-dev] **README** - 'jboss-all' Structure > > Changes -**README** > > > > > > > On Sat, 2002-02-16 at 23:29, Scott M Stark wrote: > > > > > > > > > > o Renamed 'messaging' to 'mq'. I don't know what I was thinking > > before > > > > >when I used messaging. Sorry. > > > > > > > > > Messaging is a better name than mq. > > > > > > I figured the jbossmq folks would want something mq-like back. I > > > personally don't care too much... just had trouble typing messaging. > > > > > > > > o Renamed 'connector' to 'resource' for clarity. > > > > > > > > > Connector is more clearly associated with the JCA than resource. > > > > Leave this as connector. > > > > > > JCA uses javax.resource.* for its packaging. They really should have > > > called it JRCA, since it is for connecting resources. > > > > > > If you don't mind I would like to keep it as resource, as it makes it > > > more logically to house standard adapters there. > > > > > > Basically its just a name, so I don't care too much. I only made these > > > changes because I thought that the current names were poor for what > > > types of bits live in them. > > > > > > > > o Renamed 'j2ee' to 'plastic' for clarity and to keep folks from > > > > >thinking that is a j2ee impl. It is just a module to hold our own > > > > >imitation/synthetic/copy/plastic versions of Sun's API's > > > > > > > > > What has plastic to do with standard j2ee interfaces? These are > > > > getting to be riduculous name changes so knock it off and change > > > > plastic back to j2ee. > > > > > > I figured someone was going to say something about this. I had noticed > > > that we are now providing JMX interfaces in a similar style to the j2ee > > > interfaces. Perhaps we will do the same in the future as well. So in > > > comes plastic, which is a module which only serves to hold these > > > implementations. > > > > > > Perhaps I had picked up a little bit of an urge to have some spiffy > > > macosx-like names from looking over the apple website lately. > > > > > > If you feel strongly about reverting I will. > > > > > > --jason > > > > > > > > ___ > > 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] Automated JBoss Testsuite Results
Hi, --- Jason Dillon <[EMAIL PROTECTED]> wrote: > I am gonna need you to perform a full checkout from cvs again. > Its in progress... Chris = Need somewhere to Live in London? - Then go to http://freeflats.com __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jmx/src/main/javax/management AttributeValueExp.java BinaryOpValueExp.java BooleanValueExp.java NumberValueExp.java Query.java QueryEval.java QueryExpSupport.java SingleValueExpSupport.java StringValueExp.java ValueExpSupport.java QueryExp.java ValueExp.java
User: ejort
Date: 02/02/17 04:41:52
Modified:src/main/javax/management QueryExp.java ValueExp.java
Added: src/main/javax/management AttributeValueExp.java
BinaryOpValueExp.java BooleanValueExp.java
NumberValueExp.java Query.java QueryEval.java
QueryExpSupport.java SingleValueExpSupport.java
StringValueExp.java ValueExpSupport.java
Log:
Committed start of query support so I can do a full co
Revision ChangesPath
1.2 +49 -11jmx/src/main/javax/management/QueryExp.java
Index: QueryExp.java
===
RCS file: /cvsroot/jboss/jmx/src/main/javax/management/QueryExp.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- QueryExp.java 3 Dec 2001 01:42:58 - 1.1
+++ QueryExp.java 17 Feb 2002 12:41:52 - 1.2
@@ -1,18 +1,56 @@
/*
- * LGPL
+ * JBoss, the OpenSource J2EE webOS
+ *
+ * Distributable under LGPL license.
+ * See terms of license at gnu.org.
*/
package javax.management;
-public interface QueryExp extends java.io.Serializable {
+import java.io.Serializable;
+/**
+ * A query expression.
+ *
+ * An implementation of this interface can be used in
+ * a query. Multiple query expressions can be used together to form
+ * a more complex query.
+ *
+ * @author mailto:[EMAIL PROTECTED]";>Adrian Brock.
+ * @version $Revision: 1.2 $
+ */
+public interface QueryExp
+ extends Serializable
+{
+ // Constants ---
+
+ // Public --
+
+ /**
+* Apply this query expression to an MBean.
+*
+* @param name the object name of the mbean
+* @return true or false as the result of the query expression.
+* @exception BadStringOperationException when an invalid string operation
+*is used during query construction
+* @exception BadBinaryOpValueExpException when an invalid binary operation
+*is used during query construction
+* @exception BadAttributeValueExpException when an invalid MBean attribute
+*is used during query construction
+* @exception InvalidApplicationException when trying to apply a subquery
+*expression to an MBean or an attribute expression to an
+*MBean of the wrong class.
+*/
public boolean apply(ObjectName name)
- throws BadStringOperationException,
-BadBinaryOpValueExpException,
-BadAttributeValueExpException,
-InvalidApplicationException;
-
- public void setMBeanServer(MBeanServer s);
-
-
-
+ throws BadStringOperationException,
+ BadBinaryOpValueExpException,
+ BadAttributeValueExpException,
+ InvalidApplicationException;
+
+ /**
+* Set the MBeanServer for this query. Only MBeans registered in
+* this server can be used in queries.
+*
+* @param server the MBeanServer
+*/
+ public void setMBeanServer(MBeanServer server);
}
1.2 +43 -7 jmx/src/main/javax/management/ValueExp.java
Index: ValueExp.java
===
RCS file: /cvsroot/jboss/jmx/src/main/javax/management/ValueExp.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ValueExp.java 3 Dec 2001 01:42:58 - 1.1
+++ ValueExp.java 17 Feb 2002 12:41:52 - 1.2
@@ -1,15 +1,51 @@
/*
- * LGPL
+ * JBoss, the OpenSource J2EE webOS
+ *
+ * Distributable under LGPL license.
+ * See terms of license at gnu.org.
*/
package javax.management;
-public interface ValueExp extends java.io.Serializable {
+import java.io.Serializable;
- public ValueExp apply(ObjectName name)
- throws BadStringOperationException,
-BadBinaryOpValueExpException,
-BadAttributeValueExpException,
-InvalidApplicationException;
+/**
+ * A value expression.
+ *
+ * Implementations of this interface represent arguments to expressions.
+ *
+ * @author mailto:[EMAIL PROTECTED]";>Adrian Brock.
+ * @version $Revision: 1.2 $
+ */
+public interface ValueExp
+ extends Serializable
+{
+ /**
+* Apply this value expression to an MBean.
+*
+* @param name the object name of the mbean
+* @return this value expression
+* @exception BadStringOperationException when an invalid string operation
+*is used during query construction
+* @exception BadBinaryOpValueExpException when an invalid binary operation
+*is used during query construction
+* @exception Bad
Re: [JBoss-dev] [ jboss-Change Notes-518679 ] JMS resource adapter repackaged
Jason, could you please consult others before making this kind of change in the future, and please move this into the org.jboss.resource.adapter package with the other adapters included with jboss? I will note that I previously asked the authors of the jms adapter whether they thought it would be more appropriate in its original location or in the connector package, and they asked me not to move it. Things may have changed since then, of course. thanks david jencks On 2002.02.17 01:06:23 -0500 [EMAIL PROTECTED] wrote: > Change Notes item #518679, was opened at 2002-02-16 22:06 > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=381174&aid=518679&group_id=22866 > > Category: JBossCX > Group: v3.0 (Rabbit Hole) > Status: Open > Priority: 5 > Submitted By: Jason Dillon (user57) > Assigned to: Nobody/Anonymous (nobody) > Summary: JMS resource adapter repackaged > > Initial Comment: > It has been moved to org.jboss.resource.jms > > -- > > You can respond by visiting: > http://sourceforge.net/tracker/?func=detail&atid=381174&aid=518679&group_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-dev] jboss-all daily clean failed
= ==THIS IS AN AUTOMATED EMAIL - SEE http://www.lubega.com FOR DETAILS= = HERE ARE THE LAST 50 LINES OF THE LOG FILE build.sh: build.sh: No such file or directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Optimizing distributed transactions and introducing InvocationResult
Hi, I've been thinking of how one could reduce network traffic in distributed transactions. This is a simple scenario of what happens in a DT: client calls Bean A which calls Bean B Bean A and Bean B live in 2 distinct servers (VMs) when client calls Bean A a transation T is started when Bean A calls Bean B, T is propagated to Bean B. According to OTS, when T is propagated to B's server, a subordinate transaction T' is started in server where Bean B lives and T' registers itself with the Coordinator for transaction T as a new Resource. This results in an additional network connection to A's server. (Since Coordinator for T lives in server A) When call to Bean B returns, T' is still present in B's server. Only when the call to Bean A returns to client and T is committed, the coordinator for transaction T does a 2pc and calls all subordinate resources (including T') to prepare() and then commit(). This is 2 additional network calls. >From this example, it is aparent that T will need to know about T' only after call to Bean B returns, there is no need to know about it earlier. Unfortunately, the B's server will call the Coordinator as soon as T is propagated, when T' is created and registers itself as a subordinate. To alleviate this problem, TPC importer can fake successful registration but delay the actual registration until the return of the call to Bean B. The registration can be propagated along with the _result_ of the call to bean B, since this is a network connection to the server A anyway. This way we can cut one network connection. This raises an issue of adding payload not only to the Invocation itself but to the return from Invocation. Say we can introduce InvocationResult which can contain arbitrary payload along with the actual result of the invocation or exceptions that occured during invocation. Stripping the payload can be done by the proxy-side interceptors. In case of distributed transactions, an interceptor in the Proxy (client-side interceptors are a very smart idea :) for Bean B will perform delayed registration of subordinate transaction T' when the invocation to B returns, by extracting registration info from the payload of InvocationResult. The introduction of InvocationResult and payloads will affect performance of only unoptimized calls, since now along with the invocation result we would ship other stuff, like profiling info, etc. Supposedly, if the payloads are not excessive, this will not affect even the unoptimized calls accross the network, because latency is likely to dominate bandwidth constraints. - Anatoly Akkerman Computer Science Dept. Courant Institute of Mathematical Sciences, NYU 715 Broadway, #719 Tel: 212 998-3493 New York, NY 10003 Fax: 212 995-4123 - ___ 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/02/17 07:07:14 Modified:jbossbuild.xml Log: Update the version info for the next beta release Revision ChangesPath 1.84 +2 -2 build/jboss/build.xml Index: build.xml === RCS file: /cvsroot/jboss/build/jboss/build.xml,v retrieving revision 1.83 retrieving revision 1.84 diff -u -r1.83 -r1.84 --- build.xml 17 Feb 2002 09:52:54 - 1.83 +++ build.xml 17 Feb 2002 15:07:14 - 1.84 @@ -12,7 +12,7 @@ - + @@ -65,7 +65,7 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBossMQ test case is soooo slooooow
On 16 Feb, Jason Dillon wrote: > Is there anything we can do to speed it up any? Well, actually it is not slow enough ;-) since it does not catch all bugs as it is setup today. To chatch current buggs in threading you have to have testcases that send up to 100 000 messages, sometimes taking up to an hour to complete... How about that? //Peter > > --jason > > > > > ___ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development -- Peter Antman Technology in Media, Box 34105 100 26 Stockholm Systems ArchitectWWW: http://www.tim.se Email: [EMAIL PROTECTED]WWW: http://www.backsource.org Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Entity Bean with transaction attribute "Supports"
You would have to show the complete resource utilization and transaction graph to say. The create will run effectively as NotSupported while the find should be running as Required in the scope of the user tx. There is a lot of leeway in the container behavior in the case of Supports resulting in execution without a transaction context. What happens if the Supports is changed to Required? Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Andreas Schaefer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, February 16, 2002 11:36 PM Subject: [JBoss-dev] Entity Bean with transaction attribute "Supports" > Hi Geeks > > On the current JBoss 2.4 branch: > > An Entity Bean with transaction attribute "Supports" is > created outside a user transaction directly by the > client (Java client) and just afterwards looked up with > "findByPrimaryKey" with throws an ObjectNotFound- > Exception. When the same call is made within a > transaction everything works fine ! > > Do I miss anything here or is this a bug ? > > x > Andreas Schaefer > Senior Consultant > JBoss Group, LLC > x > > > > ___ > 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] log4j.xml
Add both and we can preferentially use the xml version. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Jason Dillon" <[EMAIL PROTECTED]> To: "Scott M Stark" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, February 17, 2002 12:47 AM Subject: [JBoss-dev] log4j.xml > I was able to get the xml configuration parser to use the trace > priority. Any reason why we should not switch to the xml version of the > configuration? > > --jason ___ 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/02/17 07:44:38 Modified:jbossbuild.xml Log: Document the use of version.name as the cvs tag for any release build Revision ChangesPath 1.85 +2 -1 build/jboss/build.xml Index: build.xml === RCS file: /cvsroot/jboss/build/jboss/build.xml,v retrieving revision 1.84 retrieving revision 1.85 diff -u -r1.84 -r1.85 --- build.xml 17 Feb 2002 15:07:14 - 1.84 +++ build.xml 17 Feb 2002 15:44:38 - 1.85 @@ -12,7 +12,7 @@ - + @@ -65,6 +65,7 @@ + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Entity Bean with transaction attribute "Supports"
Hi When all the methods are required it works fine ! When I set not transaction attribute at all it works fine, too !! When I use a transaction it works fine ! The only problem I see here is that (IMO) the tx-attribute "Supports" should work with w/o a transaction the same way as when you don't have a transaction. BTW I use commit option A. Andy - Original Message - From: "Scott M Stark" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, February 17, 2002 7:48 AM Subject: Re: [JBoss-dev] Entity Bean with transaction attribute "Supports" > You would have to show the complete resource utilization and > transaction graph to say. The create will run effectively as NotSupported > while the find should be running as Required in the scope of the > user tx. There is a lot of leeway in the container behavior in the > case of Supports resulting in execution without a transaction context. > What happens if the Supports is changed to Required? > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > - Original Message - > From: "Andreas Schaefer" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Saturday, February 16, 2002 11:36 PM > Subject: [JBoss-dev] Entity Bean with transaction attribute "Supports" > > > > Hi Geeks > > > > On the current JBoss 2.4 branch: > > > > An Entity Bean with transaction attribute "Supports" is > > created outside a user transaction directly by the > > client (Java client) and just afterwards looked up with > > "findByPrimaryKey" with throws an ObjectNotFound- > > Exception. When the same call is made within a > > transaction everything works fine ! > > > > Do I miss anything here or is this a bug ? > > > > x > > Andreas Schaefer > > Senior Consultant > > JBoss Group, LLC > > x > > > > > > > > ___ > > 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: jboss/src/main/org/jboss/system Info.java InfoMBean.java ServiceLibraries.java
User: starksm
Date: 02/02/17 09:35:22
Modified:src/main/org/jboss/system Info.java InfoMBean.java
ServiceLibraries.java
Log:
Add a displayInfoForClass method to Info that provides the ClassLoader,
ProtectionDomain and Package info for the named class.
Revision ChangesPath
1.11 +63 -2 jboss/src/main/org/jboss/system/Info.java
Index: Info.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/system/Info.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- Info.java 13 Feb 2002 04:26:40 - 1.10
+++ Info.java 17 Feb 2002 17:35:22 - 1.11
@@ -27,7 +27,7 @@
* @author mailto:[EMAIL PROTECTED]";>Hiram Chirino
* @author mailto:[EMAIL PROTECTED]";>Jason Dillon
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
- * @version $Revision: 1.10 $
+ * @version $Revision: 1.11 $
*/
public class Info
implements InfoMBean, MBeanRegistration
@@ -179,6 +179,67 @@
return "Package:"+pkgName+" Not Found!";
StringBuffer info = new StringBuffer("Package: "+pkgName+"");
+ displayPackageInfo(pkg, info);
+ return info.toString();
+ }
+ /** Display the ClassLoader, ProtectionDomain and Package information for
+the specified class.
+@return a simple html report of this information
+*/
+ public String displayInfoForClass(String className)
+ {
+ ServiceLibraries libraries = ServiceLibraries.getLibraries();
+ Class clazz = libraries.findClass(className);
+ if( clazz == null )
+ return "Class:"+className+" Not Found!";
+ Package pkg = clazz.getPackage();
+ if( pkg == null )
+ return "Class:"+className+" has no Package info";
+
+ StringBuffer info = new StringBuffer("Class: "+pkg.getName()+"");
+ ClassLoader cl = clazz.getClassLoader();
+ info.append("ClassLoader: "+cl+"\n");
+ info.append("ProtectionDomain\n");
+ info.append("\n"+clazz.getProtectionDomain()+"\n");
+ info.append("Package: "+pkg.getName()+"");
+ displayPackageInfo(pkg, info);
+ return info.toString();
+ }
+
+ /** This does not work as expected because the thread context class loader
+*is not used to determine which class loader the package list is obtained
+*from.
+*/
+ public String displayAllPackageInfo()
+ {
+ ClassLoader entryCL = Thread.currentThread().getContextClassLoader();
+ ServiceLibraries libraries = ServiceLibraries.getLibraries();
+ ClassLoader[] classLoaders = libraries.getClassLoaders();
+ StringBuffer info = new StringBuffer();
+ for(int c = 0; c < classLoaders.length; c ++)
+ {
+ ClassLoader cl = classLoaders[c];
+ Thread.currentThread().setContextClassLoader(cl);
+ try
+ {
+info.append("ClassLoader: "+cl+"\n");
+Package[] pkgs = Package.getPackages();
+for(int p = 0; p < pkgs.length; p ++)
+{
+ Package pkg = pkgs[p];
+ info.append("Package: "+pkg.getName()+"\n");
+ displayPackageInfo(pkg, info);
+}
+ }
+ catch(Throwable e)
+ {
+ }
+ }
+ Thread.currentThread().setContextClassLoader(entryCL);
+ return info.toString();
+ }
+ private void displayPackageInfo(Package pkg, StringBuffer info)
+ {
info.append("\n");
info.append("SpecificationTitle: "+pkg.getSpecificationTitle());
info.append("\nSpecificationVersion: "+pkg.getSpecificationVersion());
@@ -188,7 +249,6 @@
info.append("\nImplementationVendor: "+pkg.getImplementationVendor());
info.append("\nisSealed: "+pkg.isSealed());
info.append("\n");
- return info.toString();
}
/** Return a Map of System.getProperties() with a toString implementation
@@ -252,4 +312,5 @@
return rc.toString();
}
+
}
1.8 +8 -2 jboss/src/main/org/jboss/system/InfoMBean.java
Index: InfoMBean.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/system/InfoMBean.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- InfoMBean.java15 Feb 2002 06:18:32 - 1.7
+++ InfoMBean.java17 Feb 2002 17:35:22 - 1.8
@@ -20,7 +20,8 @@
* @author mailto:[EMAIL PROTECTED]";>Hiram Chirino
* @author mailto:[EMAIL PROTECTED]";>Jason Dillon
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
- * @version $Revision: 1.7 $
+ * @author mailto:[EMAIL PROTECTED]";>Scott Stark
+ * @version $Revision: 1.8 $
*/
public interface InfoMBean
{
@@ -52,7 +53,12 @@
*
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/uil UILServerILService.java
User: pra
Date: 02/02/17 09:51:17
Modified:src/main/org/jboss/mq/il/uil UILServerILService.java
Log:
Added numbering for worker threads
Revision ChangesPath
1.17 +7 -3 jbossmq/src/main/org/jboss/mq/il/uil/UILServerILService.java
Index: UILServerILService.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/uil/UILServerILService.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- UILServerILService.java 2 Feb 2002 04:02:23 - 1.16
+++ UILServerILService.java 17 Feb 2002 17:51:17 - 1.17
@@ -46,7 +46,7 @@
* Implements the ServerILJMXService which is used to manage the JVM IL.
*
* @authorHiram Chirino ([EMAIL PROTECTED])
- * @version $Revision: 1.16 $
+ * @version $Revision: 1.17 $
*/
public class UILServerILService extends org.jboss.mq.il.ServerILJMXService
implements Runnable, UILServerILServiceMBean
{
@@ -89,7 +89,11 @@
int serverBindPort = 0;
InetAddress bindAddress = null;
Thread worker;
-
+
+ /**
+* Number of OIL Worker threads started.
+*/
+ private int threadNumber = 0;
/**
* Used to construct the GenericConnectionFactory (bindJNDIReferences()
* builds it) Sets up the connection properties need by a client to use this
@@ -159,7 +163,7 @@
}
socket.setSoTimeout(0);
- new Thread(this, "UIL Worker").start();
+ new Thread(this, "UIL Worker-"+threadNumber++).start();
mSocket = new SocketMultiplexor(socket);
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/il/oil OILServerILService.java
User: pra
Date: 02/02/17 09:50:44
Modified:src/main/org/jboss/mq/il/oil OILServerILService.java
Log:
Added numbering for worker threads
Revision ChangesPath
1.19 +80 -70jbossmq/src/main/org/jboss/mq/il/oil/OILServerILService.java
Index: OILServerILService.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/il/oil/OILServerILService.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- OILServerILService.java 2 Feb 2002 04:02:23 - 1.18
+++ OILServerILService.java 17 Feb 2002 17:50:44 - 1.19
@@ -46,7 +46,7 @@
* Implements the ServerILJMXService which is used to manage the JVM IL.
*
* @authorHiram Chirino ([EMAIL PROTECTED])
- * @version $Revision: 1.18 $
+ * @version $Revision: 1.19 $
*/
public final class OILServerILService
extends org.jboss.mq.il.ServerILJMXService
@@ -95,6 +95,11 @@
private InetAddress bindAddress = null;
/**
+* Number of OIL Worker threads started.
+*/
+ private int threadNumber = 0;
+
+ /**
* This class is used to encapsulate the basic connection and
* work for a connected client thread. The run() method of this
* class processes requests and sends responses to and from a
@@ -192,93 +197,93 @@
switch (code)
{
- case OILConstants.SET_SPY_DISTRIBUTED_CONNECTION:
- connectionToken = (ConnectionToken)in.readObject();
- break;
+ case OILConstants.SET_SPY_DISTRIBUTED_CONNECTION:
+ connectionToken = (ConnectionToken)in.readObject();
+ break;
- case OILConstants.ACKNOWLEDGE:
- AcknowledgementRequest ack = new AcknowledgementRequest();
- ack.readExternal(in);
- server.acknowledge(connectionToken, ack);
- break;
+ case OILConstants.ACKNOWLEDGE:
+ AcknowledgementRequest ack = new AcknowledgementRequest();
+ ack.readExternal(in);
+ server.acknowledge(connectionToken, ack);
+ break;
- case OILConstants.ADD_MESSAGE:
- server.addMessage(connectionToken, SpyMessage.readMessage(in));
- break;
+ case OILConstants.ADD_MESSAGE:
+ server.addMessage(connectionToken, SpyMessage.readMessage(in));
+ break;
- case OILConstants.BROWSE:
- result = server.browse(connectionToken,
(Destination)in.readObject(), (String)in.readObject());
- break;
+ case OILConstants.BROWSE:
+ result = server.browse(connectionToken,
(Destination)in.readObject(), (String)in.readObject());
+ break;
- case OILConstants.CHECK_ID:
- server.checkID((String)in.readObject());
- break;
+ case OILConstants.CHECK_ID:
+ server.checkID((String)in.readObject());
+ break;
- case OILConstants.CONNECTION_CLOSING:
- server.connectionClosing(connectionToken);
- closed = true;
- break;
+ case OILConstants.CONNECTION_CLOSING:
+ server.connectionClosing(connectionToken);
+ closed = true;
+ break;
- case OILConstants.CREATE_QUEUE:
- result = (Queue)server.createQueue(connectionToken,
(String)in.readObject());
- break;
+ case OILConstants.CREATE_QUEUE:
+ result = (Queue)server.createQueue(connectionToken,
(String)in.readObject());
+ break;
- case OILConstants.CREATE_TOPIC:
- result = (Topic)server.createTopic(connectionToken,
(String)in.readObject());
- break;
+ case OILConstants.CREATE_TOPIC:
+ result = (Topic)server.createTopic(connectionToken,
(String)in.readObject());
+ break;
- case OILConstants.DELETE_TEMPORARY_DESTINATION:
- server.deleteTemporaryDestination(connectionToken,
(SpyDestination)in.readObject());
- break;
+ case OILConstants.DELETE_TEMPORARY_DESTINATION:
+ server.deleteTemporaryDestination(connectionToken,
(SpyDestination)in.readObject());
+ break;
- case OILConstants.GET_ID:
-
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/server MessageCache.java MessageReference.java
User: pra
Date: 02/02/17 09:55:08
Modified:src/main/org/jboss/mq/server MessageCache.java
MessageReference.java
Log:
* Corrected several bugs in LRUCache and in usage of it.
* Corrected thread locks. All access in both MessageCache and MessageReference now
sync on MessageCache. Any changes to this must be tested on at least a dual CPU and
with 100 000 messages or more, to be shure no threading locks are reintrioduced.
Revision ChangesPath
1.16 +61 -26jbossmq/src/main/org/jboss/mq/server/MessageCache.java
Index: MessageCache.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/MessageCache.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- MessageCache.java 15 Feb 2002 20:59:53 - 1.15
+++ MessageCache.java 17 Feb 2002 17:55:08 - 1.16
@@ -4,7 +4,6 @@
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
-
package org.jboss.mq.server;
import java.io.File;
@@ -32,15 +31,14 @@
*
* @author mailto:[EMAIL PROTECTED]";>Hiram Chirino
* @author mailto:[EMAIL PROTECTED]";>David Maplesden
- * @version$Revision: 1.15 $
+ * @author mailto:[EMAIL PROTECTED]";>Peter Antman
+ * @version$Revision: 1.16 $
*/
-public class MessageCache
- extends ServiceMBeanSupport
- implements MessageCacheMBean, MBeanRegistration, Runnable
+public class MessageCache extends ServiceMBeanSupport implements MessageCacheMBean,
MBeanRegistration, Runnable
{
// The cached messages are orded in a LRU linked list
private LRUCache lruCache = new LRUCache();
-
+
// Provides a Unique ID to MessageHanles
private long messageCounter = 0;
int cacheHits = 0;
@@ -72,18 +70,25 @@
*/
public MessageReference add(SpyMessage message) throws javax.jms.JMSException
{
- log.trace("add lock aquire");
+ boolean trace = log.isTraceEnabled();
+ if (trace)
+ log.trace("add lock aquire");
+
+ MessageReference mh = null;
synchronized (this)
{
- MessageReference mh = new MessageReference();
+ mh = new MessageReference();
mh.init(this, messageCounter++, message);
lruCache.addMostRecent(mh);
totalCacheSize++;
validateSoftReferenceDepth();
+
+ if(trace)
+log.trace("add lock release");
- log.trace("add lock release");
- return mh;
}
+
+ return mh;
}
/**
@@ -91,13 +96,19 @@
*/
public void remove(MessageReference mr) throws JMSException
{
- log.trace("remove lock aquire");
+ boolean trace = log.isTraceEnabled();
+ if (trace)
+ log.trace("remove lock aquire");
+
synchronized (this)
{
- mr.clear();
- lruCache.remove(mr);
+ mr.clear();//Will remove it from storage if soft
+ if (mr.hardReference != null)//If message is not hard, dont do lru stuff
+lruCache.remove(mr);
totalCacheSize--;
- log.trace("remove lock release");
+
+ if (trace)
+log.trace("remove lock release");
}
}
@@ -152,10 +163,16 @@
/**
* This method is in charge of determining if it time to convert some
* hard references over to soft references.
+*
+* It must NOT be called by a thread holding a lock on a reference wich
+* in its turn holds a lock on cache. It WILL lead to deadlocks!!!
*/
public void validateSoftReferenceDepth() throws JMSException
{
- //log.trace("run lock aquire");
+ boolean trace = log.isTraceEnabled();
+ if (trace)
+ log.trace("run lock aquire");
+
synchronized (this)
{
@@ -180,35 +197,42 @@
if (chnageCount > 1)
{
if (log.isDebugEnabled())
- log.debug("Converting " + chnageCount + " hard ref to to soft refs");
+ log.debug("Converting " + chnageCount + " hard ref to to soft refs");
Node leastRecent = lruCache.getLeastRecent();
for (int i = 0; i < chnageCount && leastRecent != null; i++)
{
+ // This is tricky, make soft should really be done outside
+ // sync on cache
MessageReference mr = (MessageReference) leastRecent.data;
mr.makeSoft();
- lruCache.remove(leastRecent);
+ lruCache.remove(mr);
leastRecent = lruCache.getLeastRecent();
}
}
- //log.trace("run lock release");
+ if (trace)
+log.trace("run lock release");
Re: [JBoss-dev] Entity Bean with transaction attribute "Supports"
> Hi > > When all the methods are required it works fine ! > > When I set not transaction attribute at all it works fine, too !! > > When I use a transaction it works fine ! > These three case are all the same as they are all effectively trans=Required. > The only problem I see here is that (IMO) the tx-attribute > "Supports" should work with w/o a transaction the same > way as when you don't have a transaction. > BTW I use commit option A. > Without seeing an example this is debateable. In general Supports may have non-deterministic behavior. The ejb spec touches on this in at least three areas: The Supports transaction attribute must be used with caution. This is because of the different transactional semantics provided by the two possible modes of execution. Only the enterprise beans that will execute correctly in both modes should use the Supports transaction attribute. The spec also states: For entity beans that use EJB 2.0 container-managed persistence, only the Required, RequiresNew, or Mandatory transaction attributes should be used for the methods defined in the bean's component interface and all the direct and indirect superinterfaces of the component interface, excluding the getEJBHome, getEJBLocalHome, getHandle, getPrimaryKey, and isIdentical methods; and for the methods defined in the bean's home interface and all the direct and indirect superinterfaces of the home interface, excluding the getEJBMetaData and getHomeHandle methods specific to the remote home interface. Containers may optionally support the use of the NotSupported, Supports, and Never transaction attributes for the methods of entity beans with container-managed persistence. However, entity beans with container-managed persistence that use these transaction attributes will not be portable. Containers may optionally support the use of the NotSupported, Supports, and Never transaction attributes for the methods of entity beans with container-managed persistence because the use of these transaction modes may be needed to make use of container-managed persistence with non-transactional data stores. In general, however, the Application Assembler should avoid use of the NotSupported, Supports, and Never transaction attributes for the methods of entity beans with container-managed persistence because it may lead to inconsistent results or to the inconsistent and/or to the partial updating of persistent state and relationships in the event of concurrent use. And also, the generic catch all that denies responsibility for requiring portable usage of Supports: The EJB specification does not prescribe how the Container should manage the execution of a method with an unspecified transaction context-the transaction semantics are left to the Container implementation. Some techniques for how the Container may choose to implement the execution of a method with an unspecified transaction context are as follows (the list is not inclusive of all possible strategies): ... So, unless you put an example together and state that Supports should be handled differently in that particular context, there is not much concrete to say on whether this is a bug. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jnp/src/etc client.mf server.mf tests.mf
User: starksm Date: 02/02/17 10:08:39 Removed: src/etc client.mf server.mf tests.mf Log: Include version info the in jar manifests ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jnp build.xml
User: starksm
Date: 02/02/17 10:08:38
Modified:.build.xml
Log:
Include version info the in jar manifests
Revision ChangesPath
1.12 +19 -5 jnp/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/jnp/build.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- build.xml 15 Feb 2002 06:32:16 - 1.11
+++ build.xml 17 Feb 2002 18:08:38 - 1.12
@@ -12,7 +12,7 @@
-
+
@@ -221,7 +221,21 @@
-
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -242,7 +256,7 @@
+ manifest="${build.etc}/manifest/version.mf">
@@ -252,7 +266,7 @@
+ manifest="${build.etc}/manifest/version.mf">
@@ -262,7 +276,7 @@
+ manifest="${build.etc}/manifest/version.mf">
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/perf/META-INF ejb-jar.xml
User: starksm Date: 02/02/17 10:31:26 Modified:src/resources/perf/META-INF ejb-jar.xml Log: Add a Probe bean deployment that has only local interfaces Revision ChangesPath 1.8 +8 -0 jbosstest/src/resources/perf/META-INF/ejb-jar.xml Index: ejb-jar.xml === RCS file: /cvsroot/jboss/jbosstest/src/resources/perf/META-INF/ejb-jar.xml,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- ejb-jar.xml 16 Feb 2002 21:12:23 - 1.7 +++ ejb-jar.xml 17 Feb 2002 18:31:25 - 1.8 @@ -65,6 +65,14 @@ Bean + LocalProbe + org.jboss.test.perf.interfaces.ProbeLocalHome + org.jboss.test.perf.interfaces.ProbeLocal + org.jboss.test.perf.ejb.ProbeBean + Stateless + Bean + + ProbeCMT org.jboss.test.perf.interfaces.ProbeHome org.jboss.test.perf.interfaces.Probe ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-j2ee build.xml
User: starksm Date: 02/02/17 10:32:08 Modified:.build.xml Log: Include version info the in jar manifests Revision ChangesPath 1.16 +21 -3 jboss-j2ee/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss-j2ee/build.xml,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- build.xml 17 Feb 2002 09:52:55 - 1.15 +++ build.xml 17 Feb 2002 18:32:08 - 1.16 @@ -12,7 +12,7 @@ - + @@ -164,7 +164,7 @@ + depends="compile-etc, compile-classes"/> @@ -186,6 +186,23 @@ + + + + + + + + + + + + + + + @@ -201,7 +218,8 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq build.xml
User: starksm Date: 02/02/17 10:32:08 Modified:.build.xml Log: Include version info the in jar manifests Revision ChangesPath 1.23 +20 -5 jbossmq/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbossmq/build.xml,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- build.xml 17 Feb 2002 09:52:55 - 1.22 +++ build.xml 17 Feb 2002 18:32:08 - 1.23 @@ -12,7 +12,7 @@ - + @@ -364,14 +364,27 @@ - + - + + + + + + + + + + + + @@ -390,7 +403,8 @@ - + @@ -398,7 +412,8 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx build.xml
User: starksm Date: 02/02/17 10:32:08 Modified:.build.xml Log: Include version info the in jar manifests Revision ChangesPath 1.25 +31 -8 jbosscx/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosscx/build.xml,v retrieving revision 1.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- build.xml 17 Feb 2002 09:52:56 - 1.24 +++ build.xml 17 Feb 2002 18:32:07 - 1.25 @@ -12,7 +12,7 @@ - + @@ -224,7 +224,7 @@ | documentation compiles. --> @@ -258,6 +258,23 @@ + + + + + + + + + + + + + + + @@ -272,7 +289,8 @@ - + @@ -297,7 +316,8 @@ - + @@ -305,7 +325,8 @@ - + @@ -316,7 +337,8 @@ - + @@ -335,7 +357,8 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx build.xml
User: starksm Date: 02/02/17 10:32:08 Modified:.build.xml Log: Include version info the in jar manifests Revision ChangesPath 1.18 +22 -5 jbosssx/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosssx/build.xml,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- build.xml 17 Feb 2002 09:52:56 - 1.17 +++ build.xml 17 Feb 2002 18:32:08 - 1.18 @@ -12,7 +12,7 @@ - + @@ -304,7 +304,21 @@ - + + + + + + + + + + + + + @@ -324,7 +338,8 @@ - + @@ -342,7 +357,8 @@ - + @@ -369,7 +385,8 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosspool build.xml
User: starksm Date: 02/02/17 10:32:08 Modified:.build.xml Log: Include version info the in jar manifests Revision ChangesPath 1.17 +31 -8 jbosspool/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosspool/build.xml,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- build.xml 17 Feb 2002 09:52:55 - 1.16 +++ build.xml 17 Feb 2002 18:32:08 - 1.17 @@ -12,7 +12,7 @@ - + @@ -217,7 +217,7 @@ | documentation compiles. --> @@ -241,7 +241,25 @@ - + + + + + + + + + + + + + + + + + - + @@ -274,7 +293,8 @@
[JBoss-dev] CVS update: contrib/jboss.net build.xml
User: starksm Date: 02/02/17 10:32:08 Modified:jboss.net build.xml Log: Include version info the in jar manifests Revision ChangesPath 1.12 +19 -4 contrib/jboss.net/build.xml Index: build.xml === RCS file: /cvsroot/jboss/contrib/jboss.net/build.xml,v retrieving revision 1.11 retrieving revision 1.12 diff -u -r1.11 -r1.12 --- build.xml 17 Feb 2002 09:52:54 - 1.11 +++ build.xml 17 Feb 2002 18:32:08 - 1.12 @@ -12,7 +12,7 @@ - + @@ -249,12 +249,25 @@ - + + + + + + + + + + + + @@ -279,7 +292,8 @@ - + @@ -288,7 +302,8 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss-common build.xml
User: starksm Date: 02/02/17 10:32:07 Modified:.build.xml Log: Include version info the in jar manifests Revision ChangesPath 1.6 +23 -4 jboss-common/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jboss-common/build.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- build.xml 17 Feb 2002 03:48:24 - 1.5 +++ build.xml 17 Feb 2002 18:32:07 - 1.6 @@ -12,7 +12,7 @@ - + @@ -174,7 +174,7 @@ + depends="compile-classes, compile-etc"/> @@ -196,6 +196,23 @@ + + + + + + + + + + + + + + + @@ -211,14 +228,16 @@ - + - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/catalina build.xml
User: starksm
Date: 02/02/17 10:32:07
Modified:catalina build.xml
Log:
Include version info the in jar manifests
Revision ChangesPath
1.7 +25 -19contrib/catalina/build.xml
Index: build.xml
===
RCS file: /cvsroot/jboss/contrib/catalina/build.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- build.xml 17 Feb 2002 09:52:54 - 1.6
+++ build.xml 17 Feb 2002 18:32:07 - 1.7
@@ -12,7 +12,7 @@
-
+
@@ -204,7 +204,7 @@
| documentation compiles.
-->
@@ -236,30 +236,35 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-
-Specification-Title: ${Name}-${module.version}
-Specification-Version: ${module.version}
-Specification-Vendor: JBoss Group, LLC
-Implementation-Title: ${Name}-${module.version} CVSTag=${version.name}
-Implementation-Version: ${module.version}.${build.id}
-Implementation-Vendor: JBoss Group, LLC
-
-
-
-
+ depends="compile">
+ manifest="${build.etc}/manifest/version.mf">
@@ -271,7 +276,7 @@
@@ -279,7 +284,7 @@
@@ -291,6 +296,7 @@
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Broken DynLoadingUnitTestCase...
I do not think you broke the test, Jason. What is broken since December or so is the feature it tests (dynamic class loading). Scott is looking at this. Cheers, Francisco On 16 Feb 2002, Jason Dillon wrote: > I apparently broke the org.jboss.test.jrmp.test.DynLoadingUnitTestCase > test, but I can't figure out why. > > Can you, or anyone else who understands this more take a look? > > --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Removal of UnifiedClassLoader.getURLs override was invalid
This change to UnifiedClassLoader: "removed invalid getURLs() method. Not sure why we want to return null for a URLClassLoader. Comments suggested it was to avoid some RMI bloat, but code that expects a URLClassLoader will expect that this baby will return something valid. It certainly won't expect a null. If this behavior of masking the url list is trully desired, then return new URL[0], but I suggest that is also invalid, since a URLClassLoader with no URLS is a wasted object... what does one load from it... IMHO (ok not so humble) it is best not to obfuscate here." breaks dynamic class loading and does cause bloat of serialized RMI objects as well as MarshalledObjects. Do not rip out code you do not like unless you really understand why it was there. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/system UnifiedClassLoader.java
User: starksm
Date: 02/02/17 13:40:16
Modified:src/main/org/jboss/system UnifiedClassLoader.java
Log:
Restore the getURLs override as its removal was invalid
Revision ChangesPath
1.7 +18 -9 jboss/src/main/org/jboss/system/UnifiedClassLoader.java
Index: UnifiedClassLoader.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/system/UnifiedClassLoader.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- UnifiedClassLoader.java 16 Feb 2002 08:50:21 - 1.6
+++ UnifiedClassLoader.java 17 Feb 2002 21:40:15 - 1.7
@@ -20,7 +20,7 @@
* @author Marc Fleury
* @author Christoph G. Jung
* @author Scott Stark/a>
- * @version $Revision: 1.6 $
+ * @version $Revision: 1.7 $
*
* 20010830 marc fleury:
*
@@ -75,14 +75,14 @@
}
catch(Exception e)
{
- //
- // FIXME: Should not mask exceptionsd like this, if it is an error, then
- //propagate it to caller tyo handle
- //
- log.warn("URL "+url+" could not be opened", e);
+ //
+ // FIXME: Should not mask exceptionsd like this, if it is an error, then
+ //propagate it to caller tyo handle
+ //
+ log.warn("URL "+url+" could not be opened", e);
}
}
-
+
/**
* We intercept the load class to know exactly the dependencies
* of the underlying jar
@@ -149,6 +149,16 @@
return url.hashCode();
}
+ /** Return an empty URL array to force the RMI marshalling subsystem to
+*use the java.server.codebase property as the annotated codebase. Do not
+*remove this method without discussing it on the dev list.
+*/
+ private static final URL[] empty = {};
+ public URL[] getURLs()
+ {
+ return empty;
+ }
+
/**
* This method simply invokes the super.getURLs() method to access the
* list of URLs that make up the UnifiedClassLoader classpath.
@@ -170,8 +180,7 @@
public String toString()
{
StringBuffer tmp = new StringBuffer("JBoss UnifiedClassloader: keyURL : ");
- tmp.append(getURL());
-
+ tmp.append(getURL());
tmp.append(']');
return tmp.toString();
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/iiop build.xml
User: reverbel Date: 02/02/17 13:45:19 Modified:iiop build.xml Log: Changing "plastic" back to "j2ee". Revision ChangesPath 1.4 +7 -7 contrib/iiop/build.xml Index: build.xml === RCS file: /cvsroot/jboss/contrib/iiop/build.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- build.xml 17 Feb 2002 04:22:24 - 1.3 +++ build.xml 17 Feb 2002 21:45:18 - 1.4 @@ -12,7 +12,7 @@ - + @@ -128,11 +128,11 @@ - - - - - + + + + + @@ -153,7 +153,7 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: build/jboss build.xml
User: reverbel Date: 02/02/17 13:50:26 Modified:jbossbuild.xml Log: Pointer to JacORB library has been deleted somehow. Added again. Revision ChangesPath 1.86 +5 -1 build/jboss/build.xml Index: build.xml === RCS file: /cvsroot/jboss/build/jboss/build.xml,v retrieving revision 1.85 retrieving revision 1.86 diff -u -r1.85 -r1.86 --- build.xml 17 Feb 2002 15:44:38 - 1.85 +++ build.xml 17 Feb 2002 21:50:26 - 1.86 @@ -12,7 +12,7 @@ - + @@ -152,6 +152,10 @@ + + + + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/iiop/src/main/org/jboss/iiop/rmi/server InterfaceMapper.java OperationMapper.java ParameterMapper.java
User: reverbel Date: 02/02/17 14:39:26 Removed: iiop/src/main/org/jboss/iiop/rmi/server InterfaceMapper.java OperationMapper.java ParameterMapper.java Log: Removing unused files. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-518896 ] config-property-type in ra.xml be primat
Bugs item #518896, was opened at 2002-02-17 14:49
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=518896&group_id=22866
Category: JBossMX
Group: v2.4 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Marc Prud'hommeaux (mprudhom)
Assigned to: Nobody/Anonymous (nobody)
Summary: config-property-type in ra.xml be primat
Initial Comment:
In 2.4.4, if my ra.xml file contains a config-property
like:
the minimum number of
connections in the connection pool
MinPool
java.lang.Integer
3
then I get warnings when I try to deploy my .rar file:
[WARN,jdoConnectionFactory] Using default value '3' for
config property 'MinPool'
[WARN,jdoConnectionFactory] Unable to find a
PropertyEditor for class 'class java.lang.Integer' of
property 'MinPool' - skipping property
Note that setting it to "int" won't work, since
Class.forName ("int") dosen't work. Line 570 of
ConnectionFactoryLoader.java should check for primitive
Object types (like Integer.class) and replace it with
primitive class type (int.class) so
PropertyEditorManager.findEditor (Class) can locate them.
Note that this isn't seen in jbosspool-jdbc.rar, since
it only uses String properties.
A fixed ConnectionFactoryLoader.java is attached
(although I haven't tested it, nor is it terribly elegant).
--
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=518896&group_id=22866
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-516684 ] CCE on redeployment of ear with sar/ejb
Bugs item #516684, was opened at 2002-02-12 14:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516684&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Scott M Stark (starksm) >Assigned to: Scott M Stark (starksm) Summary: CCE on redeployment of ear with sar/ejb Initial Comment: The perf-service.ear in the current main testsuite is not usable across redeployments. Steps to reproduce: 1. Deploy the perf-service.ear and then execute the jboss.test:service=PerfTest runTests(100) operation. Ignore the NPE shown under testTimings. 2. Simply touch the perf-service.ear and then execute the runTests(100) operation again on the jboss.test:service=PerfTest mbean, you will see: +++ testTimingsCMT() testTimingsCMT failed: java.lang.ClassCastException: $Proxy19 at org.jboss.test.perf.test.PerfTest.testTimingsCMT (PerfTest.java:134) at org.jboss.test.perf.test.PerfTest.runTests (PerfTest.java:66) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1523) at com.sun.jdmk.comm.HtmlInvokePage.buildPage (HtmlInvokePage.java:240) at com.sun.jdmk.comm.HtmlRequestHandler.processGetRequest (HtmlRequestHandler.java:325) at com.sun.jdmk.comm.HtmlRequestHandler.processRequest (HtmlRequestHandler.java:152) at com.sun.jdmk.comm.HtmlRequestHandler.doRun (HtmlRequestHandler.java:79) at com.sun.jdmk.comm.ClientHandler.run (ClientHandler.java:84) at java.lang.Thread.run(Thread.java:484) -- >Comment By: Scott M Stark (starksm) Date: 2002-02-17 16:17 Message: Logged In: YES user_id=175228 The real issue appears to be the new class loader model and caching of classes at the vm level. When the PerfTest service looks up the ProbeHome interface this is the stack trace where the class for the ProbeHome interface class gets loaded: java.lang.Class.forName (Class.java:195) sun.rmi.server.MarshalInputStream.resolveProxyClass (MarshalInputStream.java:183) java.io.ObjectInputStream.inputProxyClassDescriptor (ObjectInputStream.java:982) java.io.ObjectInputStream.readObject (ObjectInputStream.java:370) java.io.ObjectInputStream.readObject (ObjectInputStream.java:236) java.io.ObjectInputStream.inputObject (ObjectInputStream.java:1186) java.io.ObjectInputStream.readObject (ObjectInputStream.java:386) java.io.ObjectInputStream.readObject (ObjectInputStream.java:236) java.rmi.MarshalledObject.get (MarshalledObject.java:138) org.jnp.interfaces.NamingContext.lookup (NamingContext.java:376) org.jnp.interfaces.NamingContext.lookup (NamingContext.java:356) javax.naming.InitialContext.lookup (InitialContext.java:350) org.jboss.test.perf.test.PerfTest.testTimings (PerfTest.java:102) org.jboss.test.perf.test.PerfTest.runTests (PerfTest.java:56) java.lang.reflect.Method.invoke (Native Method) com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1628) com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1523) com.sun.jdmk.comm.HtmlInvokePage.buildPage (HtmlInvokePage.java:240) com.sun.jdmk.comm.HtmlRequestHandler.processGetRequest (HtmlRequestHandler.java:325) com.sun.jdmk.comm.HtmlRequestHandler.processRequest (HtmlRequestHandler.java:152) com.sun.jdmk.comm.HtmlRequestHandler.doRun (HtmlRequestHandler.java:79) com.sun.jdmk.comm.ClientHandler.run (ClientHandler.java:84) java.lang.Thread.run (Thread.java:484) The public static Class forName(String name, boolean initialize, ClassLoader loader) throws ClassNotFoundException in turn calls the forName0 native method: private static native Class forName0(String name, boolean initialize, ClassLoader loader) throws ClassNotFoundException; This ultimate calls this native function: static ClassClass * LookupLoaderCache(char *hashed_name, struct Hjava_lang_ClassLoader *loader) from j2sdk1.3.1-src/src/share/javavm/runtime/classresolver.c This is simply a hash table of class bytes keyed by the loader and class name. The issue is that mbean services run with the same thread context class MBeanClassLoader and only when a class is first seen is the is this load asked to load the class which results in a call to the ServiceLibraries repository. If the mbean service along with any external classes it references is reloaded, the next execution of the mbean service uses the same MBeanClassLoader instance to load classes, and those that were originally cached are still returned and these will conflict if when the class loader that loaded the class into the ServiceLibraries repository was not the main MBeanClassLoader. -- Comment By: David Jencks (d_jencks) Date: 2002-02-14 20
Re: [JBoss-dev] CVS update: contrib/iiop build.xml
Sorry, forgot about that one. --jason On Sun, 2002-02-17 at 13:45, Francisco Reverbel wrote: > User: reverbel > Date: 02/02/17 13:45:19 > > Modified:iiop build.xml > Log: > Changing "plastic" back to "j2ee". > > Revision ChangesPath > 1.4 +7 -7 contrib/iiop/build.xml > > Index: build.xml > === > RCS file: /cvsroot/jboss/contrib/iiop/build.xml,v > retrieving revision 1.3 > retrieving revision 1.4 > diff -u -r1.3 -r1.4 > --- build.xml 17 Feb 2002 04:22:24 - 1.3 > +++ build.xml 17 Feb 2002 21:45:18 - 1.4 > @@ -12,7 +12,7 @@ > > > > - > + > > > > @@ -128,11 +128,11 @@ > > > > - > - > - > - > - > + > + > + > + > + > > > > @@ -153,7 +153,7 @@ > > > > - > + > > > > > > > > ___ > 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: contrib/jetty/src/main/org/jboss/jetty JettyService.java
User: jules_gosnell
Date: 02/02/17 16:26:01
Modified:jetty/src/main/org/jboss/jetty JettyService.java
Log:
reenable Jan's logging stuff - fixed
Revision ChangesPath
1.47 +68 -72contrib/jetty/src/main/org/jboss/jetty/JettyService.java
Index: JettyService.java
===
RCS file: /cvsroot/jboss/contrib/jetty/src/main/org/jboss/jetty/JettyService.java,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -r1.46 -r1.47
--- JettyService.java 15 Feb 2002 00:46:52 - 1.46
+++ JettyService.java 18 Feb 2002 00:26:01 - 1.47
@@ -5,7 +5,7 @@
* See terms of license at gnu.org.
*/
-// $Id: JettyService.java,v 1.46 2002/02/15 00:46:52 user57 Exp $
+// $Id: JettyService.java,v 1.47 2002/02/18 00:26:01 jules_gosnell Exp $
//--
@@ -26,7 +26,7 @@
import org.jboss.web.AbstractWebContainer;
import org.jboss.web.WebApplication;
import org.mortbay.util.jmx.CodeMBean;
-//import org.mortbay.util.jmx.LogMBean;
+import org.mortbay.util.jmx.LogMBean;
import org.mortbay.util.Log;
//--
@@ -34,26 +34,23 @@
* A service to launch jetty from JMX.
*
* @author mailto:[EMAIL PROTECTED]";>Julian Gosnell
- * @version $Revision: 1.46 $
+ * @version $Revision: 1.47 $
*/
-// NOTES
-
-// I could parameterise the properties file - do we still need it -
-// shouldn't it use MLET ?
-
public class JettyService
extends AbstractWebContainer
implements JettyServiceMBean, MBeanRegistration
{
public static final String NAME = "Jetty";
- Logger _log = Logger.getLogger(JettyService.class);
- JettyMBean _mbean = null;
- CodeMBean_debug = null;
- Jetty_jetty = null;
- MBeanServer _server = null;
- // LogMBean _logbean = null;
+ Logger _log = Logger.getLogger(JettyService.class);
+ JettyMBean _mbean= null;
+ CodeMBean _debug= null;
+ Jetty _jetty= null;
+ MBeanServer _server = null;
+ LogMBean_logbean = null;
+ ObjectName _codeBeanName = null;
+ ObjectName _logBeanName = null;
public
JettyService()
@@ -63,6 +60,7 @@
// that logging models are connected before configure-time (via
// MLET file) which is done before initialise-time.
ensureLogging();
+ensureNaming();
}
//
@@ -80,6 +78,20 @@
//
+ public void
+ensureNaming()
+ {
+try
+{
+ _codeBeanName = new ObjectName(JettyMBean.JBOSS_DOMAIN+":Jetty=Debug");
+ _logBeanName = new ObjectName(JettyMBean.JBOSS_DOMAIN+":Jetty=Log");
+}
+catch (Exception e)
+{
+ _log.error("Could not format names for Jetty debug and log manager MBeans");
+}
+ }
+
protected void
ensureLogging()
{
@@ -89,7 +101,7 @@
JBossLogSink logSink = new JBossLogSink();
try
{
- logSink.initialize(Logger.getLogger("org.jboss.jetty.Jetty"));
+ logSink.initialize(Logger.getLogger("org.jboss.jetty.Jetty"));
}
catch(Exception e)
{
@@ -103,34 +115,13 @@
// why doesn't this work? - investigate...
//_jetty.setLogSink(logSink);
-_log.debug("connected JBoss and Jetty Log models");
+if (_log.isDebugEnabled())
+ _log.debug("connected JBoss and Jetty Log models");
}
/** the usual path separators we know */
protected final static String KNOWN_PATH_SEPARATORS=":;";
- /**
- * enter the jetty.properties file to the system properties such that
- * Jasper will find the right jars to compile
- */
- protected void
-ensureProperties()
-throws IOException
- {
-String props="jetty.properties";
-//InputStream propertiesIn =
getClass().getClassLoader().getResourceAsStream(props);
-InputStream propertiesIn = new
URL(Jetty.fixURL(getClass().getClassLoader().getResource(props).toString())).openStream();
-
-if (propertiesIn == null)
- throw new IOException("failed to load "+props);
-
-System.getProperties().load(propertiesIn);
-
-if (_log.isDebugEnabled()) {
- _log.debug("Loaded properties from: "+props);
-}
- }
-
protected void
ensureJetty()
{
@@ -147,7 +138,8 @@
_jetty=tmp; // now we are initialised.
-_log.debug("Instantiated and configured server");
+if (_log.isDebugEnabled())
+ _log.debug("Instantiated and configured server");
}
Re: [JBoss-dev] Removal of UnifiedClassLoader.getURLs override wasinvalid
Removed it because Jetty was expecting a non null. I was going to have it return a empty array, but did not understand why we would want to mask the urls in a url cl. --jason On Sun, 2002-02-17 at 13:12, Scott M Stark wrote: > > This change to UnifiedClassLoader: > "removed invalid getURLs() method. Not sure why we want to return null >for a URLClassLoader. Comments suggested it was to avoid some RMI bloat, >but code that expects a URLClassLoader will expect that this baby will >return something valid. It certainly won't expect a null. If this >behavior of masking the url list is trully desired, then return new > URL[0], >but I suggest that is also invalid, since a URLClassLoader with no URLS > is >a wasted object... what does one load from it... IMHO (ok not so humble) >it is best not to obfuscate here." > > breaks dynamic class loading and does cause bloat of serialized RMI > objects as well as MarshalledObjects. Do not rip out code you do > not like unless you really understand why it was there. > > > 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] Broken DynLoadingUnitTestCase...
Oh no I broke it. See Scott's email =) --jason On Sun, 2002-02-17 at 12:16, Francisco Reverbel wrote: > I do not think you broke the test, Jason. What is broken since December > or so is the feature it tests (dynamic class loading). Scott is looking > at this. > > Cheers, > > Francisco > > On 16 Feb 2002, Jason Dillon wrote: > > > I apparently broke the org.jboss.test.jrmp.test.DynLoadingUnitTestCase > > test, but I can't figure out why. > > > > Can you, or anyone else who understands this more take a look? > > > > --jason > > > ___ > 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] log4j.xml
I don't understand why yet, but even when using the config property to override the file file, if a .properties exists it will be used. Any idea why this is the case? --jason On Sun, 2002-02-17 at 07:49, Scott M Stark wrote: > Add both and we can preferentially use the xml version. > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > - Original Message - > From: "Jason Dillon" <[EMAIL PROTECTED]> > To: "Scott M Stark" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Sunday, February 17, 2002 12:47 AM > Subject: [JBoss-dev] log4j.xml > > > > I was able to get the xml configuration parser to use the trace > > priority. Any reason why we should not switch to the xml version of the > > configuration? > > > > --jason > > > > ___ > 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] A problem with the new class loading model
Bug #516684 has shown a problem with the new class loading model that is related to caching of class data at the JVM level. The problem is due to the fact that all mbean services execute with the same MBeanClassLoader instance. Here is the scenario in Bug #516684 1. A sar containing an mbean service and an ejb-jar is deployed. The mbean service references home and remote interfaces from the ejb-jar. 2. The home and remote interfaces are loaded into the ServiceLibraries repository by the ejb-jar class loader. 3. The mbean service is executed and it uses its thread context class loader to access the ejb home and remote interfaces. The MBeanClassLoader obtains these from the ServiceLibraries repository. However, the JVM believes that it is the MBeanClassLoader which loaded these classes and creates a cache record from the MBeanClassLoader to the ejb home interface. This is invalid because the on redeployment another ejb-jar class loader will be the source of the update ejb home. The solution is to execute mbean services with the thread context class loader set to the class loader created to load the deployment unit the mbean was in. I do not think we have this capability currently because we are using Sun jmxri implementation, but I need to look into this further. It is a point to remember for our jmx implementation. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty build.xml
User: jules_gosnell Date: 02/02/17 16:35:29 Modified:jettybuild.xml Log: ensure that jasper and servlet jars are refreshed by devel target fix deploy dir in devel target - is there a var for this ? comment web test suite from devel target Revision ChangesPath 1.37 +15 -7 contrib/jetty/build.xml Index: build.xml === RCS file: /cvsroot/jboss/contrib/jetty/build.xml,v retrieving revision 1.36 retrieving revision 1.37 diff -u -r1.36 -r1.37 --- build.xml 17 Feb 2002 09:52:55 - 1.36 +++ build.xml 18 Feb 2002 00:35:29 - 1.37 @@ -515,13 +515,13 @@ description="Deploy and Test the Jetty plugin"> Undeploying old Jetty plugin... - + @@ -529,16 +529,25 @@ + + + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CVS update: build/jboss build.xml
version.name was never meant to have anything to do with cvs. It is there to hold the rather arbitrary name of a release (ie. rabbit-hole or whistler or merlin). While understand your desire to include cvs tag information, I do not think that this is the best place for it. I suggest we add a version.cvstag for this purpose. This is currently onlyt being used to generate the spec and impl bits for mf files right? --jason On Sun, 2002-02-17 at 07:44, Scott M Stark wrote: > User: starksm > Date: 02/02/17 07:44:38 > > Modified:jbossbuild.xml > Log: > Document the use of version.name as the cvs tag for any release build > > Revision ChangesPath > 1.85 +2 -1 build/jboss/build.xml > > Index: build.xml > === > RCS file: /cvsroot/jboss/build/jboss/build.xml,v > retrieving revision 1.84 > retrieving revision 1.85 > diff -u -r1.84 -r1.85 > --- build.xml 17 Feb 2002 15:07:14 - 1.84 > +++ build.xml 17 Feb 2002 15:44:38 - 1.85 > @@ -12,7 +12,7 @@ > > > > - > + > > > > @@ -65,6 +65,7 @@ > > > > + > > > > > > > > ___ > 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-516684 ] CCE on redeployment of ear with sar/ejb
Bugs item #516684, was opened at 2002-02-12 14:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516684&group_id=22866 Category: JBossServer Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 5 Submitted By: Scott M Stark (starksm) Assigned to: Scott M Stark (starksm) Summary: CCE on redeployment of ear with sar/ejb Initial Comment: The perf-service.ear in the current main testsuite is not usable across redeployments. Steps to reproduce: 1. Deploy the perf-service.ear and then execute the jboss.test:service=PerfTest runTests(100) operation. Ignore the NPE shown under testTimings. 2. Simply touch the perf-service.ear and then execute the runTests(100) operation again on the jboss.test:service=PerfTest mbean, you will see: +++ testTimingsCMT() testTimingsCMT failed: java.lang.ClassCastException: $Proxy19 at org.jboss.test.perf.test.PerfTest.testTimingsCMT (PerfTest.java:134) at org.jboss.test.perf.test.PerfTest.runTests (PerfTest.java:66) at java.lang.reflect.Method.invoke(Native Method) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1628) at com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1523) at com.sun.jdmk.comm.HtmlInvokePage.buildPage (HtmlInvokePage.java:240) at com.sun.jdmk.comm.HtmlRequestHandler.processGetRequest (HtmlRequestHandler.java:325) at com.sun.jdmk.comm.HtmlRequestHandler.processRequest (HtmlRequestHandler.java:152) at com.sun.jdmk.comm.HtmlRequestHandler.doRun (HtmlRequestHandler.java:79) at com.sun.jdmk.comm.ClientHandler.run (ClientHandler.java:84) at java.lang.Thread.run(Thread.java:484) -- >Comment By: David Jencks (d_jencks) Date: 2002-02-17 16:36 Message: Logged In: YES user_id=60525 "If the mbean service along with any external classes it references is reloaded, the next execution of the mbean service uses the same MBeanClassLoader instance to load classes," Did you make sure it is the same MBeanClassLoader? There is code to remove the old MBeanClassLoader when the mbean is removed from the mbeanserver and then a new one is created (with the same object name) for the new deployment. If the "remove mbeanClassLoader" code is not being executed that could be the problem, maybe... -- Comment By: Scott M Stark (starksm) Date: 2002-02-17 16:17 Message: Logged In: YES user_id=175228 The real issue appears to be the new class loader model and caching of classes at the vm level. When the PerfTest service looks up the ProbeHome interface this is the stack trace where the class for the ProbeHome interface class gets loaded: java.lang.Class.forName (Class.java:195) sun.rmi.server.MarshalInputStream.resolveProxyClass (MarshalInputStream.java:183) java.io.ObjectInputStream.inputProxyClassDescriptor (ObjectInputStream.java:982) java.io.ObjectInputStream.readObject (ObjectInputStream.java:370) java.io.ObjectInputStream.readObject (ObjectInputStream.java:236) java.io.ObjectInputStream.inputObject (ObjectInputStream.java:1186) java.io.ObjectInputStream.readObject (ObjectInputStream.java:386) java.io.ObjectInputStream.readObject (ObjectInputStream.java:236) java.rmi.MarshalledObject.get (MarshalledObject.java:138) org.jnp.interfaces.NamingContext.lookup (NamingContext.java:376) org.jnp.interfaces.NamingContext.lookup (NamingContext.java:356) javax.naming.InitialContext.lookup (InitialContext.java:350) org.jboss.test.perf.test.PerfTest.testTimings (PerfTest.java:102) org.jboss.test.perf.test.PerfTest.runTests (PerfTest.java:56) java.lang.reflect.Method.invoke (Native Method) com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1628) com.sun.management.jmx.MBeanServerImpl.invoke (MBeanServerImpl.java:1523) com.sun.jdmk.comm.HtmlInvokePage.buildPage (HtmlInvokePage.java:240) com.sun.jdmk.comm.HtmlRequestHandler.processGetRequest (HtmlRequestHandler.java:325) com.sun.jdmk.comm.HtmlRequestHandler.processRequest (HtmlRequestHandler.java:152) com.sun.jdmk.comm.HtmlRequestHandler.doRun (HtmlRequestHandler.java:79) com.sun.jdmk.comm.ClientHandler.run (ClientHandler.java:84) java.lang.Thread.run (Thread.java:484) The public static Class forName(String name, boolean initialize, ClassLoader loader) throws ClassNotFoundException in turn calls the forName0 native method: private static native Class forName0(String name, boolean initialize, ClassLoader loader) throws ClassNotFoundException; This ultimate calls this native function: static ClassClass * LookupLoaderCache(char *hashed_name, struct Hjava_lang_ClassLoader *loader) from j2sdk1.3.1-src/src/share/javavm/runtime/classresolver.c This is simply a hash table of class bytes keyed by the loader and class name. The issue is that mbean services run with the same thread
Re: [JBoss-dev] JBossMQ test case is soooo slooooow
Yikes... that would not bee good. Perhaps this test case should be moved outside of tests-unit into a separate target which is depended on by tests. --jason On Sun, 2002-02-17 at 07:22, [EMAIL PROTECTED] wrote: > On 16 Feb, Jason Dillon wrote: > > Is there anything we can do to speed it up any? > > Well, actually it is not slow enough ;-) since it does not catch all > bugs as it is setup today. To chatch current buggs in threading you have > to have testcases that send up to 100 000 messages, sometimes taking up > to an hour to complete... > > How about that? > > //Peter > > > > --jason > > > > > > > > > > ___ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > -- > > Peter Antman Technology in Media, Box 34105 100 26 Stockholm > Systems ArchitectWWW: http://www.tim.se > Email: [EMAIL PROTECTED]WWW: http://www.backsource.org > Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942 > > > > ___ > 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] [ jboss-Change Notes-518679 ] JMS resource adapterrepackaged
I will move it there. Was thinking about moving it there but decided that someone would tell me which was which. Asking for forgiveness is often much easier than asking for permission. I moved this with out "asking for permission" as part of the clean up of the jboss/server module, which does entirely too much right now. True, I could have posted a message, which may or may not have been read then waited for a few days to collect all of the responses. Or I could simply move it, and see who cares about that change. It is a rather aggressive (and back wards) method for getting something done, but it does get it done. In this case the JMS RA has absolutely no need to remain in the jboss/server module. There is nothing which depends on it to compile. Logically it belongs closer to the other resource adapters. It does not currently, but could also use classes where are helpers for such adapters, which might only live in the jboss/connector module. I certainly do not want to hurt anybodies feelings by moving there code around. The last few days I have been trying to clean up loose ends and reorganize for the upcoming release. It seems that no one has been paying particular attention to these areas, so I took them up, partly to help isolate the core system from the plugins to help prepare the system for embedded use, and partly because I want todo everything in my power to help make JBoss the best it can be. In the case here, I do not think that Peter cares too much which package his RA lives in. If I am wrong then my apologies for not consulting with Peter first. --jason On Sun, 2002-02-17 at 05:07, David Jencks wrote: > Jason, could you please consult others before making this kind of change in > the future, and please move this into the org.jboss.resource.adapter > package with the other adapters included with jboss? > > I will note that I previously asked the authors of the jms adapter whether > they thought it would be more appropriate in its original location or in > the connector package, and they asked me not to move it. Things may have > changed since then, of course. > > thanks > david jencks > > > On 2002.02.17 01:06:23 -0500 [EMAIL PROTECTED] wrote: > > Change Notes item #518679, was opened at 2002-02-16 22:06 > > You can respond by visiting: > > http://sourceforge.net/tracker/?func=detail&atid=381174&aid=518679&group_id=22866 > > > > Category: JBossCX > > Group: v3.0 (Rabbit Hole) > > Status: Open > > Priority: 5 > > Submitted By: Jason Dillon (user57) > > Assigned to: Nobody/Anonymous (nobody) > > Summary: JMS resource adapter repackaged > > > > Initial Comment: > > It has been moved to org.jboss.resource.jms > > > > -- > > > > You can respond by visiting: > > http://sourceforge.net/tracker/?func=detail&atid=381174&aid=518679&group_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: contrib/jetty/src/etc jetty.xml
User: jules_gosnell Date: 02/02/17 17:12:09 Modified:jetty/src/etc jetty.xml Log: picky, picky Revision ChangesPath 1.7 +0 -1 contrib/jetty/src/etc/jetty.xml Index: jetty.xml === RCS file: /cvsroot/jboss/contrib/jetty/src/etc/jetty.xml,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- jetty.xml 10 Feb 2002 17:57:39 - 1.6 +++ jetty.xml 18 Feb 2002 01:12:09 - 1.7 @@ -46,4 +46,3 @@ - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: contrib/jetty build.xml
User: user57 Date: 02/02/17 17:11:36 Modified:jettybuild.xml Log: o using fileset on delete to avoid having to need to know the install.id o using properties for copy tasks since we can't use the above hack * need to provide better project/module integration for tests/testsuite targets to remove these hacks altogether. Revision ChangesPath 1.38 +34 -23contrib/jetty/build.xml Index: build.xml === RCS file: /cvsroot/jboss/contrib/jetty/build.xml,v retrieving revision 1.37 retrieving revision 1.38 diff -u -r1.37 -r1.38 --- build.xml 18 Feb 2002 00:35:29 - 1.37 +++ build.xml 18 Feb 2002 01:11:36 - 1.38 @@ -514,36 +514,47 @@ + + + Undeploying old Jetty plugin... - - + + + + + + Deploying new Jetty plugin... - - - - + + + + + + + + + + + + + + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: tools/etc/xdoclet - New directory
User: d_jencks Date: 02/02/17 18:08:57 tools/etc/xdoclet - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: tools/etc - New directory
User: d_jencks Date: 02/02/17 18:08:43 tools/etc - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: tools/etc/xdoclet/templates - New directory
User: d_jencks Date: 02/02/17 18:09:10 tools/etc/xdoclet/templates - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: tools/etc/xdoclet/templates mbean-custom.j
User: d_jencks
Date: 02/02/17 18:10:37
Added: etc/xdoclet/templates mbean-custom.j
Log:
xdoclet merge file that generates jboss default object names
Revision ChangesPath
1.1 tools/etc/xdoclet/templates/mbean-custom.j
Index: mbean-custom.j
===
//default object name
public static final javax.management.ObjectName OBJECT_NAME = new
org.jboss.util.jmx.ObjectNameFactory("");
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: tools/lib xdoclet.jar
User: d_jencks Date: 02/02/17 18:12:12 Modified:lib xdoclet.jar Log: xdoclet as of 2/17/2002 6:00 PM EST. Includes mbean merge point Revision ChangesPath 1.4 +1409 -1290tools/lib/xdoclet.jar <> ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest build.xml
User: d_jencks Date: 02/02/17 18:15:05 Modified:.build.xml Log: added test of identities of MBeanClassLoaders on redeployment Revision ChangesPath 1.71 +13 -5 jbosstest/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosstest/build.xml,v retrieving revision 1.70 retrieving revision 1.71 diff -u -r1.70 -r1.71 --- build.xml 17 Feb 2002 09:52:52 - 1.70 +++ build.xml 18 Feb 2002 02:15:05 - 1.71 @@ -27,7 +27,7 @@ - + @@ -367,7 +367,7 @@ - + @@ -423,7 +423,7 @@ - + + - + @@ -964,7 +965,7 @@ - + @@ -1061,6 +1062,13 @@ + + + + + + + ___ 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/mbean TestMBClassLoader.java
User: d_jencks
Date: 02/02/17 18:15:05
Added: src/main/org/jboss/test/jmx/mbean TestMBClassLoader.java
Log:
added test of identities of MBeanClassLoaders on redeployment
Revision ChangesPath
1.1
jbosstest/src/main/org/jboss/test/jmx/mbean/TestMBClassLoader.java
Index: TestMBClassLoader.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.test.jmx.mbean;
import org.jboss.system.Service;
import org.jboss.system.ServiceMBeanSupport;
/**
* TestMBClassLoader.java
*
*
* Created: Sun Feb 17 20:08:31 2002
*
* @author mailto:[EMAIL PROTECTED]";>David Jencks
* @version
* @jmx:mbean name="jboss.test:service=BrokenDeployer"
* @jmx:interface extends="org.jboss.system.Service"
*/
public class TestMBClassLoader extends ServiceMBeanSupport implements
TestMBClassLoaderMBean
{
public TestMBClassLoader ()
{
}
/**
* Describe getClassLoader method here.
*
* @return a String value
* @jmx:managed-operation
*/
public String getClassLoader()
{
return this.getClass().getClassLoader().toString();
}
}// TestMBClassLoader
___
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 MBeanClassLoaderUnitTestCase.java
User: d_jencks
Date: 02/02/17 18:15:05
Added: src/main/org/jboss/test/jmx/test
MBeanClassLoaderUnitTestCase.java
Log:
added test of identities of MBeanClassLoaders on redeployment
Revision ChangesPath
1.1
jbosstest/src/main/org/jboss/test/jmx/test/MBeanClassLoaderUnitTestCase.java
Index: MBeanClassLoaderUnitTestCase.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.test.jmx.test;
import java.io.File;
import java.net.InetAddress;
import java.net.URL;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collection;
import java.util.Iterator;
import java.util.Set;
import javax.management.MBeanRegistrationException;
import javax.management.MalformedObjectNameException;
import javax.management.ObjectInstance;
import javax.management.ObjectName;
import javax.management.ReflectionException;
import javax.management.RuntimeMBeanException;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingEnumeration;
import javax.naming.NamingException;
import junit.framework.*;
import org.jboss.test.JBossTestCase;
/**
* @see
* @authormailto:[EMAIL PROTECTED]";>David Jencks
* @version $Revision: 1.1 $
*/
public class MBeanClassLoaderUnitTestCase
extends JBossTestCase
{
// Constants -
protected final static int INSTALLED = 0;
protected final static int CONFIGURED = 1;
protected final static int CREATED = 2;
protected final static int RUNNING = 3;
protected final static int FAILED = 4;
protected final static int STOPPED = 5;
protected final static int DESTROYED = 6;
protected final static int NOTYETINSTALLED = 7;
// Attributes
ObjectName serviceControllerName;
// Static
// Constructors --
/**
* Constructor for the DeployServiceUnitTestCase object
*
* @param name Test case name
*/
public MBeanClassLoaderUnitTestCase(String name)
{
super(name);
try
{
serviceControllerName = new
ObjectName("jboss.system:service=ServiceController");
}
catch (Exception e)
{
} // end of try-catch
}
// Public
public void testMBeanClassLoaders() throws Exception
{
String testUrl = "testmbeanclassloader.jar";
getLog().debug("testUrl is : " + testUrl);
ObjectName objectNameA = new ObjectName("test:name=TestMBClassLoaderA");
ObjectName objectNameB = new ObjectName("test:name=TestMBClassLoaderB");
//deploy jar
deploy(testUrl);
//deploy service.xml
String testServiceUrl = "test-mbean-classloader-service.xml";
deploy(testServiceUrl);
String mbclA1 = (String)getServer().getAttribute(objectNameA, "ClassLoader");
String mbclB1 = (String)getServer().getAttribute(objectNameB, "ClassLoader");
getLog().debug("classloader for A: " + mbclA1);
getLog().debug("classloader for B: " + mbclB1);
undeploy(testServiceUrl);
undeploy(testUrl);
deploy(testUrl);
deploy(testServiceUrl);
String mbclA2 = (String)getServer().getAttribute(objectNameA, "ClassLoader");
String mbclB2 = (String)getServer().getAttribute(objectNameB, "ClassLoader");
getLog().debug("classloader for A: " + mbclA2);
getLog().debug("classloader for B: " + mbclB2);
undeploy(testServiceUrl);
undeploy(testUrl);
assertTrue("Classloaders for A and B are the same!", !mbclA1.equals(mbclB1));
assertTrue("Classloaders for A and B are the same!", !mbclA2.equals(mbclB2));
assertTrue("First and second Classloaders for A are the same!",
!mbclA1.equals(mbclA2));
assertTrue("First and second Classloaders for B are the same!",
!mbclB1.equals(mbclB2));
}
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosstest/src/resources/jmx test-mbean-classloader-service.xml
User: d_jencks Date: 02/02/17 18:15:06 Added: src/resources/jmx test-mbean-classloader-service.xml Log: added test of identities of MBeanClassLoaders on redeployment Revision ChangesPath 1.1 jbosstest/src/resources/jmx/test-mbean-classloader-service.xml Index: test-mbean-classloader-service.xml === ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] A problem with the new class loading model
I'm not sure this is all that is happening. I've just committed a test
case (org.jboss.test.jmx.test.MBeanClassLoaderUnitTestCase) that shows that
an mbean instance thinks it's classloader is a UnifiedClassLoader, and that
when you redeploy the classes (and mbeans), the UnifiedClassLoader changes
appropriately.
here's some test log: A and B are mbeans based on the same class, and are
deployed and redeployed.
[MBeanClassLoaderUnitTestCase,DEBUG] classloader for A: JBoss
UnifiedClassloader: keyURL :
file:/mnt/otherlinux/usr/java/jboss/co10/jboss-all/build/output/jboss-3.0.0beta/tmp/deploy/68.testmbeanclassloader.jar]
[MBeanClassLoaderUnitTestCase,DEBUG] classloader for B: JBoss
UnifiedClassloader: keyURL :
file:/mnt/otherlinux/usr/java/jboss/co10/jboss-all/build/output/jboss-3.0.0beta/tmp/deploy/68.testmbeanclassloader.jar]
[MBeanClassLoaderUnitTestCase,DEBUG] classloader for A: JBoss
UnifiedClassloader: keyURL :
file:/mnt/otherlinux/usr/java/jboss/co10/jboss-all/build/output/jboss-3.0.0beta/tmp/deploy/70.testmbeanclassloader.jar]
[MBeanClassLoaderUnitTestCase,DEBUG] classloader for B: JBoss
UnifiedClassloader: keyURL :
file:/mnt/otherlinux/usr/java/jboss/co10/jboss-all/build/output/jboss-3.0.0beta/tmp/deploy/70.testmbeanclassloader.jar]
The values we see are from:
public String getClassLoader()
{
return this.getClass().getClassLoader().toString();
}
I think this is rather odd because the ServiceCreator asked the MBeanServer
to create the mbean using an MBeanClassLoader instance created specifically
for each mbean instance.
create and register the MBeanClassLoader:
ObjectName loader = new ObjectName("jboss.system.classloader:id=" +
name.hashCode());
MBeanClassLoader cl = new MBeanClassLoader(name);
if (!server.isRegistered(loader))
server.registerMBean(cl, loader);
and
create the MBean itself.
ObjectInstance instance = server.createMBean(code,
name,
loader,
constructor.params,
constructor.signature);
Why doesn't the mbean think its classloader is an MBeanClassLoader?
What's going on?
david jencks
On 2002.02.17 19:40:08 -0500 Scott M Stark wrote:
> Bug #516684 has shown a problem with the new class loading model
> that is related to caching of class data at the JVM level. The problem
> is due to the fact that all mbean services execute with the same
> MBeanClassLoader instance. Here is the scenario in Bug #516684
>
> 1. A sar containing an mbean service and an ejb-jar is deployed.
> The mbean service references home and remote interfaces from
> the ejb-jar.
> 2. The home and remote interfaces are loaded into the ServiceLibraries
> repository by the ejb-jar class loader.
> 3. The mbean service is executed and it uses its thread context
> class loader to access the ejb home and remote interfaces. The
> MBeanClassLoader obtains these from the ServiceLibraries repository.
> However, the JVM believes that it is the MBeanClassLoader which
> loaded these classes and creates a cache record from the
> MBeanClassLoader to the ejb home interface. This is invalid because
> the on redeployment another ejb-jar class loader will be the source
> of the update ejb home.
>
> The solution is to execute mbean services with the thread context
> class loader set to the class loader created to load the deployment
> unit the mbean was in. I do not think we have this capability currently
> because we are using Sun jmxri implementation, but I need to look
> into this further. It is a point to remember for our jmx implementation.
>
>
> 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] log4j.xml
After looking into this further it looks like when Category loads it will attempt to load log4j.properties and process it. We can turn that off by default by setting -Dlog4j.defaultInitOverride=true, but I am not sure that is a good idea. I think that this all stemmed from configuration being read from system resources. This isn't really the case anymore. In fact this might be the only service left which does that... well at least most other services do not. So, I am thinking that it would be a good idea to update this to use the ServerConfig.getConfigURL() as the base for looking for configuration files. But, then to make this work and not just move the problem, we would have to remove that URL from the classpath... which I am not so sure of either. I also found a small window where log events maybe lost... which is between the time that ServiceLibraies is fully loaded and able to pull the log4j.jar and load it and before Log4jService has been started. Note, that because of the current bahavior, when Category loads it will configure using log4j.properties so some odd results may occur if you are expecting log4j.xml to be used. To debug this problem I played with using BoostrapLogger in Log4jService, which I expected would have just logged to System.out, but I found that it did not log until the Category.getRoot() method had been called in Log4jService. I then played around a little more, adding a flag in BootstrapLogger which would be set by Log4jService when it was actually initialized and ready, which finally did the trick to show the messages. Of course I had to disable the default configuration behavior of Category too, or delete log4j.properties * * * So this all seems a little wacked out to me. Essentially Log4jService only duplicates the functionality of what Log4j does already. Once we removed jboss.conf, and were forced to add a system property to change the config file we just added to the duplication. I think this should be changed... but I can't really see how. First, I think that we should put a stripped down version of log4j.jar into jboss/lib and drop the usage of BootstrapLogger. I understand that we want to pull as much from the network as possible, but I suggest that this one should be left local for the following reasons: o JBoss can not exist with out this. Since we do abstract its usage into our own Logger it is conceivable that we could remove it but I think that doing so would be highly unlikely.o Not really a strong point, but a point none-the-less. o It is not possible to provide rich debugging of the core service library classes because the log4j classes have to be loaded through them. o BootstrapLogger introduces a window which makes it possible to loose events. As the loading system changes over time this may cause some confusion over where logging events are going. o BootstrapLogger complicates it does not simplify. So, if we put log4j-core.jar into jboss/lib, and make Logger (and priotity friends) part of the jboss-boot.jar, we can use the exact same Logger objects through the entire system. We can use the default behavior of Log4j to try and configure from a log4j.properties file. This mechanism can be used to enable debugging of the boot process, until Log4jService can be loaded. I still think this is nessicary because we will want to use the logging config for the net config the user is running under. This means that we will either have to stop putting configURL into the classpath, or that we should provide a log4j.properties in jboss-boot.jar (or run.jar) which provides the initial configuration, and not interfere with the configuration setup by Log4jService. It seems like the advantages of doing this will allow us to see more debug on core components, removes any windows or jboss specific log4j problems caused by the BL, exposed more control over the exact handling of log messages during boot which can be configured in standard log4j ways. The only disadvantage that I can see is another file on the local classpath. With log4j-core.jar added to lib/ the size of the directory is 584k, still incredibly tiny. It will still fit on a floppy with lots of room to spare. This file is only 76k itself. This feels like the right thing todo. What do you think? --jason On Sun, 2002-02-17 at 16:32, Jason Dillon wrote: > I don't understand why yet, but even when using the config property to > override the file file, if a .properties exists it will be used. > > Any idea why this is the case? > > --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource/adapter/jms - New directory
User: user57 Date: 02/02/17 18:50:59 jbosscx/src/main/org/jboss/resource/adapter/jms - New directory ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/main/org/jboss/resource/jms JmsConnectionFactory.java JmsConnectionFactoryImpl.java JmsConnectionManager.java JmsConnectionRequestInfo.java JmsCred.java JmsLocalTransaction.java JmsMCFProperties.java JmsManagedConnection.java JmsManagedConnectionFactory.java JmsMetaData.java JmsSession.java JmsSessionFactory.java JmsSessionFactoryImpl.java TestClient.java package.html
User: user57 Date: 02/02/17 18:54:53 Removed: src/main/org/jboss/resource/jms JmsConnectionFactory.java JmsConnectionFactoryImpl.java JmsConnectionManager.java JmsConnectionRequestInfo.java JmsCred.java JmsLocalTransaction.java JmsMCFProperties.java JmsManagedConnection.java JmsManagedConnectionFactory.java JmsMetaData.java JmsSession.java JmsSessionFactory.java JmsSessionFactoryImpl.java TestClient.java package.html Log: o moved JMSRA to org.jboss.resource.adapter.jms * did not even see adapter/ when I moved this before ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx build.xml
User: user57 Date: 02/02/17 18:54:52 Modified:.build.xml Log: o moved JMSRA to org.jboss.resource.adapter.jms * did not even see adapter/ when I moved this before Revision ChangesPath 1.26 +2 -2 jbosscx/build.xml Index: build.xml === RCS file: /cvsroot/jboss/jbosscx/build.xml,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- build.xml 17 Feb 2002 18:32:07 - 1.25 +++ build.xml 18 Feb 2002 02:54:52 - 1.26 @@ -12,7 +12,7 @@ - + @@ -360,7 +360,7 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosscx/src/resources/jms-rar/META-INF ra.xml
User: user57 Date: 02/02/17 18:54:53 Modified:src/resources/jms-rar/META-INF ra.xml Log: o moved JMSRA to org.jboss.resource.adapter.jms * did not even see adapter/ when I moved this before Revision ChangesPath 1.2 +5 -5 jbosscx/src/resources/jms-rar/META-INF/ra.xml Index: ra.xml === RCS file: /cvsroot/jboss/jbosscx/src/resources/jms-rar/META-INF/ra.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- ra.xml17 Feb 2002 06:13:29 - 1.1 +++ ra.xml18 Feb 2002 02:54:53 - 1.2 @@ -2,7 +2,7 @@ http://java.sun.com/dtd/connector_1_0.dtd";> - + JMS Adapter @@ -11,11 +11,11 @@ 1.0 JMS - org.jboss.resource.jms.JmsManagedConnectionFactory - org.jboss.resource.jms.JmsConnectionFactory - org.jboss.resource.jms.JmsConnectionFactoryImpl + org.jboss.resource.adapter.jms.JmsManagedConnectionFactory + org.jboss.resource.adapter.jms.JmsConnectionFactory + org.jboss.resource.adapter.jms.JmsConnectionFactoryImpl javax.jms.Session - org.jboss.resource.jms.JmsSession + org.jboss.resource.adapter.jms.JmsSession XATransaction JmsProviderAdapterJNDI ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 495 Successful tests: 487 Errors:4 Failures: 4 [time of test: 18 February 2002 2:54 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-12] See http://lubega.com for full details 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! DETAILS OF ERRORS [details not shown -as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite! Its really is easy, just use the ant target 'run-basic-testsuite' from the build directory. To just run the unit tests (they are quite quick): In the testsuite directory, ./build.sh tests-unit You can run a single test case using: ./build.sh -Dtest=[XXXTestCase] one-test The XXXTestCase is the classname of the junit class to run. So, to run the EJBSpecUnitTestCase use: ./build.sh -Dtest=EJBSpecUnitTestCase one-test To run all tests within a package, use ./build.sh -Dtest=[package] test The package is name of the directory under the org/jboss/test directory that contains the tests to run. So, to run the unit tests in the org.jboss.test.security package use: ./build.sh -Dtest=security test 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: jbosscx/src/main/org/jboss/resource/adapter/jms JmsConnectionFactory.java JmsConnectionFactoryImpl.java JmsConnectionManager.java JmsConnectionRequestInfo.java JmsCred.java JmsLocalTransaction.java JmsMCFProperties.java JmsManagedConnection.java JmsManagedConnectionFactory.java JmsMetaData.java JmsSession.java JmsSessionFactory.java JmsSessionFactoryImpl.java TestClient.java package.html
User: user57
Date: 02/02/17 18:54:53
Added: src/main/org/jboss/resource/adapter/jms
JmsConnectionFactory.java
JmsConnectionFactoryImpl.java
JmsConnectionManager.java
JmsConnectionRequestInfo.java JmsCred.java
JmsLocalTransaction.java JmsMCFProperties.java
JmsManagedConnection.java
JmsManagedConnectionFactory.java JmsMetaData.java
JmsSession.java JmsSessionFactory.java
JmsSessionFactoryImpl.java TestClient.java
package.html
Log:
o moved JMSRA to org.jboss.resource.adapter.jms
* did not even see adapter/ when I moved this before
Revision ChangesPath
1.1
jbosscx/src/main/org/jboss/resource/adapter/jms/JmsConnectionFactory.java
Index: JmsConnectionFactory.java
===
/***
* *
* JBoss: The OpenSource J2EE WebOS *
* *
* Distributable under LGPL license. *
* See terms of license at gnu.org. *
* *
***/
package org.jboss.resource.adapter.jms;
import javax.jms.TopicConnectionFactory;
import javax.jms.QueueConnectionFactory;
/**
* JmsConnectionFactory.java
*
* Created: Thu Apr 26 17:01:35 2001
*
* @author mailto:[EMAIL PROTECTED]";>Peter Antman.
* @version $Revision: 1.1 $
*/
public interface JmsConnectionFactory
extends TopicConnectionFactory, QueueConnectionFactory
{
// empty
}
1.1
jbosscx/src/main/org/jboss/resource/adapter/jms/JmsConnectionFactoryImpl.java
Index: JmsConnectionFactoryImpl.java
===
/***
* *
* JBoss: The OpenSource J2EE WebOS *
* *
* Distributable under LGPL license. *
* See terms of license at gnu.org. *
* *
***/
package org.jboss.resource.adapter.jms;
import java.io.Serializable;
import javax.naming.Reference;
import javax.resource.Referenceable;
import javax.resource.ResourceException;
import javax.resource.spi.ManagedConnectionFactory;
import javax.resource.spi.ConnectionManager;
import javax.jms.JMSException;
import javax.jms.QueueConnection;
import javax.jms.TopicConnection;
/**
* ???
*
* Created: Thu Apr 26 17:02:50 2001
*
* @author mailto:[EMAIL PROTECTED]";>Peter Antman.
* @version $Revision: 1.1 $
*/
public class JmsConnectionFactoryImpl
implements JmsConnectionFactory, Serializable, Referenceable
{
private Reference reference;
/**
* JmsRa own factory
*/
private ManagedConnectionFactory mcf;
/**
* Hook to the appserver
*/
private ConnectionManager cm;
public JmsConnectionFactoryImpl(ManagedConnectionFactory mcf,
ConnectionManager cm)
{
this.mcf = mcf;
this.cm = cm;
if (cm == null) {
// This is standalone usage, no appserver
this.cm = new JmsConnectionManager();
} else {
this.cm = cm;
}
}
public void setReference(Reference reference)
{
this.reference = reference;
}
public Reference getReference()
{
return reference;
}
// --- QueueConnectionFactory
public QueueConnection createQueueConnection()
throws JMSException
{
JmsSessionFactoryImpl s = new JmsSessionFactoryImpl(mcf,cm);
s.isTopic(Boolean.FALSE);
return s;
}
public QueueConnection createQueueConnection(String userName,
String password)
throws JMSException
{
JmsSessionFactoryImpl s = new JmsSessionFactoryImpl(mcf,cm);
s.isTopic(Boolean.FALSE);
s.setUserName(userName);
s.setPassword(password);
return s;
}
// --- TopicConnectionFactory
public TopicConnection createTopicConnection()
throws JMSException
{
JmsSessionFactoryImpl s = new JmsSessionFactoryImpl(mcf,cm);
s.isTopic(Boolean.TRUE);
return s;
}
public TopicConnection createTopicConnection(String userName,
String password)
throws JMSException
{
JmsSessionFactoryImpl s = new JmsSessionFactoryImpl(mcf,cm);
s.isTopic(Bo
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb EJBDeployer.java
User: user57
Date: 02/02/17 18:58:57
Modified:src/main/org/jboss/ejb EJBDeployer.java
Log:
o info -> debug
Revision ChangesPath
1.9 +9 -5 jboss/src/main/org/jboss/ejb/EJBDeployer.java
Index: EJBDeployer.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/EJBDeployer.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- EJBDeployer.java 15 Feb 2002 06:18:30 - 1.8
+++ EJBDeployer.java 18 Feb 2002 02:58:57 - 1.9
@@ -74,7 +74,7 @@
* @author mailto:[EMAIL PROTECTED]";>Peter Antman.
* @author mailto:[EMAIL PROTECTED]";>Scott Stark
* @author mailto:[EMAIL PROTECTED]";>Sacha Labourey
-* @version $Revision: 1.8 $
+* @version $Revision: 1.9 $
*/
public class EJBDeployer
extends ServiceMBeanSupport
@@ -432,10 +432,14 @@
// Init application
//app.create();
// Start application
- log.info( "start application, deploymentInfo: " + sdi +
-", short name: " + sdi.shortName +
-", parent short name: " + ( sdi.parent == null ? "null" :
sdi.parent.shortName )
- );
+ if (debug)
+ {
+log.debug( "start application, deploymentInfo: " + sdi +
+ ", short name: " + sdi.shortName +
+ ", parent short name: " + ( sdi.parent == null ? "null" :
sdi.parent.shortName )
+ );
+ }
+
// Create JSR-77 EJB-Module
int i = app.getName().lastIndexOf( "/" );
String lName = app.getName().substring(
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] A problem with the new class loading model
Shouldn't MBeanClassLoader usage be replaced by UnifiedClassLoader ?
They appear to be very similar. Is there some special need to have
these separated?
--jason
On Sun, 2002-02-17 at 18:30, David Jencks wrote:
> I'm not sure this is all that is happening. I've just committed a test
> case (org.jboss.test.jmx.test.MBeanClassLoaderUnitTestCase) that shows that
> an mbean instance thinks it's classloader is a UnifiedClassLoader, and that
> when you redeploy the classes (and mbeans), the UnifiedClassLoader changes
> appropriately.
>
> here's some test log: A and B are mbeans based on the same class, and are
> deployed and redeployed.
>
> [MBeanClassLoaderUnitTestCase,DEBUG] classloader for A: JBoss
> UnifiedClassloader: keyURL :
>file:/mnt/otherlinux/usr/java/jboss/co10/jboss-all/build/output/jboss-3.0.0beta/tmp/deploy/68.testmbeanclassloader.jar]
> [MBeanClassLoaderUnitTestCase,DEBUG] classloader for B: JBoss
> UnifiedClassloader: keyURL :
>file:/mnt/otherlinux/usr/java/jboss/co10/jboss-all/build/output/jboss-3.0.0beta/tmp/deploy/68.testmbeanclassloader.jar]
> [MBeanClassLoaderUnitTestCase,DEBUG] classloader for A: JBoss
> UnifiedClassloader: keyURL :
>file:/mnt/otherlinux/usr/java/jboss/co10/jboss-all/build/output/jboss-3.0.0beta/tmp/deploy/70.testmbeanclassloader.jar]
> [MBeanClassLoaderUnitTestCase,DEBUG] classloader for B: JBoss
> UnifiedClassloader: keyURL :
>file:/mnt/otherlinux/usr/java/jboss/co10/jboss-all/build/output/jboss-3.0.0beta/tmp/deploy/70.testmbeanclassloader.jar]
>
> The values we see are from:
>public String getClassLoader()
>{
> return this.getClass().getClassLoader().toString();
>}
>
> I think this is rather odd because the ServiceCreator asked the MBeanServer
> to create the mbean using an MBeanClassLoader instance created specifically
> for each mbean instance.
>
> create and register the MBeanClassLoader:
> ObjectName loader = new ObjectName("jboss.system.classloader:id=" +
> name.hashCode());
>
> MBeanClassLoader cl = new MBeanClassLoader(name);
>
> if (!server.isRegistered(loader))
> server.registerMBean(cl, loader);
>
> and
>
> create the MBean itself.
> ObjectInstance instance = server.createMBean(code,
> name,
> loader,
> constructor.params,
>
> constructor.signature);
>
>
> Why doesn't the mbean think its classloader is an MBeanClassLoader?
>
> What's going on?
>
> david jencks
>
> On 2002.02.17 19:40:08 -0500 Scott M Stark wrote:
> > Bug #516684 has shown a problem with the new class loading model
> > that is related to caching of class data at the JVM level. The problem
> > is due to the fact that all mbean services execute with the same
> > MBeanClassLoader instance. Here is the scenario in Bug #516684
> >
> > 1. A sar containing an mbean service and an ejb-jar is deployed.
> > The mbean service references home and remote interfaces from
> > the ejb-jar.
> > 2. The home and remote interfaces are loaded into the ServiceLibraries
> > repository by the ejb-jar class loader.
> > 3. The mbean service is executed and it uses its thread context
> > class loader to access the ejb home and remote interfaces. The
> > MBeanClassLoader obtains these from the ServiceLibraries repository.
> > However, the JVM believes that it is the MBeanClassLoader which
> > loaded these classes and creates a cache record from the
> > MBeanClassLoader to the ejb home interface. This is invalid because
> > the on redeployment another ejb-jar class loader will be the source
> > of the update ejb home.
> >
> > The solution is to execute mbean services with the thread context
> > class loader set to the class loader created to load the deployment
> > unit the mbean was in. I do not think we have this capability currently
> > because we are using Sun jmxri implementation, but I need to look
> > into this further. It is a point to remember for our jmx implementation.
> >
> >
> > 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
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 495 Successful tests: 488 Errors:4 Failures: 3 [time of test: 18 February 2002 3:23 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-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-12] See http://lubega.com for full details 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! DETAILS OF ERRORS [details not shown -as this makes the mail too big to reach the sf mailing list] PS BEFORE you commit, run the test suite! Its really is easy, just use the ant target 'run-basic-testsuite' from the build directory. To just run the unit tests (they are quite quick): In the testsuite directory, ./build.sh tests-unit You can run a single test case using: ./build.sh -Dtest=[XXXTestCase] one-test The XXXTestCase is the classname of the junit class to run. So, to run the EJBSpecUnitTestCase use: ./build.sh -Dtest=EJBSpecUnitTestCase one-test To run all tests within a package, use ./build.sh -Dtest=[package] test The package is name of the directory under the org/jboss/test directory that contains the tests to run. So, to run the unit tests in the org.jboss.test.security package use: ./build.sh -Dtest=security test 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] A problem with the new class loading model
On 2002.02.17 22:09:50 -0500 Jason Dillon wrote:
> Shouldn't MBeanClassLoader usage be replaced by UnifiedClassLoader ?
> They appear to be very similar. Is there some special need to have
> these separated?
>
> --jason
>
Well, I don't think so.
UnifiedClassLoader actually loads classes from URLs. MBeanClassLoader is
kind of a marker: there is one for each mbean instance. The idea, which is
not yet implemented, is that it should provide class <--> mbean dependency
tracking, so if the class of an mbean is undeployed without the mbean being
explicitly removed, the MBeanClassLoader sticks around as kind of a marker,
waiting for the class to show up again, then recreating the mbean instance.
This is, as I understand it, Marc's idea for a better way to do class <-->
mbean dependencies than the classpath dependency mechanism I once
implemented.
david jencks
>
> On Sun, 2002-02-17 at 18:30, David Jencks wrote:
> > I'm not sure this is all that is happening. I've just committed a test
> > case (org.jboss.test.jmx.test.MBeanClassLoaderUnitTestCase) that shows
> that
> > an mbean instance thinks it's classloader is a UnifiedClassLoader, and
> that
> > when you redeploy the classes (and mbeans), the UnifiedClassLoader
> changes
> > appropriately.
> >
> > here's some test log: A and B are mbeans based on the same class, and
> are
> > deployed and redeployed.
> >
> > [MBeanClassLoaderUnitTestCase,DEBUG] classloader for A: JBoss
> > UnifiedClassloader: keyURL :
>file:/mnt/otherlinux/usr/java/jboss/co10/jboss-all/build/output/jboss-3.0.0beta/tmp/deploy/68.testmbeanclassloader.jar]
> > [MBeanClassLoaderUnitTestCase,DEBUG] classloader for B: JBoss
> > UnifiedClassloader: keyURL :
>file:/mnt/otherlinux/usr/java/jboss/co10/jboss-all/build/output/jboss-3.0.0beta/tmp/deploy/68.testmbeanclassloader.jar]
> > [MBeanClassLoaderUnitTestCase,DEBUG] classloader for A: JBoss
> > UnifiedClassloader: keyURL :
>file:/mnt/otherlinux/usr/java/jboss/co10/jboss-all/build/output/jboss-3.0.0beta/tmp/deploy/70.testmbeanclassloader.jar]
> > [MBeanClassLoaderUnitTestCase,DEBUG] classloader for B: JBoss
> > UnifiedClassloader: keyURL :
>file:/mnt/otherlinux/usr/java/jboss/co10/jboss-all/build/output/jboss-3.0.0beta/tmp/deploy/70.testmbeanclassloader.jar]
> >
> > The values we see are from:
> >public String getClassLoader()
> >{
> > return this.getClass().getClassLoader().toString();
> >}
> >
> > I think this is rather odd because the ServiceCreator asked the
> MBeanServer
> > to create the mbean using an MBeanClassLoader instance created
> specifically
> > for each mbean instance.
> >
> > create and register the MBeanClassLoader:
> > ObjectName loader = new ObjectName("jboss.system.classloader:id="
> +
> > name.hashCode());
> >
> > MBeanClassLoader cl = new MBeanClassLoader(name);
> >
> > if (!server.isRegistered(loader))
> > server.registerMBean(cl, loader);
> >
> > and
> >
> > create the MBean itself.
> > ObjectInstance instance = server.createMBean(code,
> > name,
> > loader,
> >
> constructor.params,
> >
> > constructor.signature);
> >
> >
> > Why doesn't the mbean think its classloader is an MBeanClassLoader?
> >
> > What's going on?
> >
> > david jencks
> >
> > On 2002.02.17 19:40:08 -0500 Scott M Stark wrote:
> > > Bug #516684 has shown a problem with the new class loading model
> > > that is related to caching of class data at the JVM level. The
> problem
> > > is due to the fact that all mbean services execute with the same
> > > MBeanClassLoader instance. Here is the scenario in Bug #516684
> > >
> > > 1. A sar containing an mbean service and an ejb-jar is deployed.
> > > The mbean service references home and remote interfaces from
> > > the ejb-jar.
> > > 2. The home and remote interfaces are loaded into the
> ServiceLibraries
> > > repository by the ejb-jar class loader.
> > > 3. The mbean service is executed and it uses its thread context
> > > class loader to access the ejb home and remote interfaces. The
> > > MBeanClassLoader obtains these from the ServiceLibraries repository.
> > > However, the JVM believes that it is the MBeanClassLoader which
> > > loaded these classes and creates a cache record from the
> > > MBeanClassLoader to the ejb home interface. This is invalid because
> > > the on redeployment another ejb-jar class loader will be the source
> > > of the update ejb home.
> > >
> > > The solution is to execute mbean services with the thread context
> > > class loader set to the class loader created to load the deployment
> > > unit the mbean was in. I do not think we have this capability
> currently
> > > because we are using Sun jmxri implementation, but I need to look
> > > into thi
