[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 187 Successful tests: 148 Errors:25 Failures: 14 [time of test: 14 November 2001 6:23 GMT] [java.version: 1.3.1] [java.vendor: Sun Microsystems Inc.] [java.vm.version: 1.3.1-b24] [java.vm.name: Java HotSpot(TM) Server 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. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! 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 easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ 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: 172 Successful tests: 135 Errors:23 Failures: 14 [time of test: 14 November 2001 5:25 GMT] [java.version: 1.3.1] [java.vendor: Blackdown Java-Linux Team] [java.vm.version: Blackdown-1.3.1-FCS] [java.vm.name: Classic VM] [java.vm.info: green threads, nojit] [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. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! 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 easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] (no subject)
David Jencks, I've got a deployment question for you. I just finished adjusting MQ's MessageCache so that it uses a CacheStore interface to store/load/remove messages from secondary storage. We should be able to get some performance gains by having the PersistenceManager implement the CacheStore. Persistent messages have already been persisted and do not need to be persisted a second time by the CacheStore methods. The problem is that the PeristenceManager has an mbean dependency on MessagesCache and MessageCache has a mbean dependency on CacheStore. So if we have the PersistenceManager also be the CacheStore, we would have a cycle in our dependencies. Do you see a way around this?? Regards, Hiram _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm CacheStore.java CacheStoreMBean.java
User: chirino
Date: 01/11/13 20:24:08
Added: src/main/org/jboss/mq/pm CacheStore.java
CacheStoreMBean.java
Log:
Factored out a CacheStore object from the message store. This should lay the
ground work needed so that the MessageCache can use a PM for saving and loading
messages.
Also fixed a small bug in the file PM. It was not properly restoring the message
after a server restart.
Revision ChangesPath
1.1 jbossmq/src/main/org/jboss/mq/pm/CacheStore.java
Index: CacheStore.java
===
/*
* JBossMQ, the OpenSource JMS implementation
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.mq.pm;
import javax.jms.JMSException;
import org.jboss.mq.SpyMessage;
import org.jboss.mq.server.MessageReference;
/**
* This class provides the base for user supplied persistence packages.
*
* @author Hiram Chirino ([EMAIL PROTECTED])
* @author Paul Kendall ([EMAIL PROTECTED])
* @createdAugust 16, 2001
* @version$Revision: 1.1 $
*/
public interface CacheStore {
/**
* reads the message refered to by the MessagReference back as a SpyMessage
*
* @param message Description of Parameter
* @param txIdDescription of Parameter
* @exception javax.jms.JMSException Description of Exception
*/
SpyMessage loadFromStorage(MessageReference mh) throws JMSException;
/**
* Stores the given message to secondary storeage. You should be able to
* use the MessagReference to load the message back later.
*
* @param message Description of Parameter
* @param txIdDescription of Parameter
* @exception javax.jms.JMSException Description of Exception
*/
void saveToStorage(MessageReference mh, SpyMessage message) throws JMSException;
/**
* Removes the message that was stored in secondary storage.
*
* @param message Description of Parameter
* @param txIdDescription of Parameter
* @exception javax.jms.JMSException Description of Exception
*/
void removeFromStorage(MessageReference mh) throws JMSException;
}
1.1 jbossmq/src/main/org/jboss/mq/pm/CacheStoreMBean.java
Index: CacheStoreMBean.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.mq.pm;
import javax.management.ObjectName;
/**
* CacheStoreMBean.java
*
*
* @author mailto:[EMAIL PROTECTED]";>david jencks
* @author mailto:[EMAIL PROTECTED]";>Hiram Chirino
* @version
*/
public interface CacheStoreMBean
{
//methods needed for JBossMQService to set up connections
//and to require the MessageCache.
Object getInstance();
}// CacheStoreMBean
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/rollinglogged PersistenceManager.java
User: chirino
Date: 01/11/13 20:23:27
Modified:src/main/org/jboss/mq/pm/rollinglogged
PersistenceManager.java
Log:
Factored out a CacheStore object from the message store. This should lay the
ground work needed so that the MessageCache can use a PM for saving and loading
messages.
Also fixed a small bug in the file PM. It was not properly restoring the message
after a server restart.
Revision ChangesPath
1.14 +2 -2
jbossmq/src/main/org/jboss/mq/pm/rollinglogged/PersistenceManager.java
Index: PersistenceManager.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/rollinglogged/PersistenceManager.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- PersistenceManager.java 2001/11/10 21:38:05 1.13
+++ PersistenceManager.java 2001/11/14 04:23:27 1.14
@@ -39,7 +39,7 @@
*
* @author David Maplesden ([EMAIL PROTECTED])
* @author mailto:[EMAIL PROTECTED]";>David Jencks
- * @version$Revision: 1.13 $
+ * @version$Revision: 1.14 $
*/
public class PersistenceManager extends ServiceMBeanSupport implements
org.jboss.mq.pm.PersistenceManager, PersistenceManagerMBean
{
@@ -127,7 +127,7 @@
}
- public org.jboss.mq.pm.PersistenceManager getInstance()
+ public Object getInstance()
{
return this;
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file CacheStore.java CacheStoreMBean.java
User: chirino
Date: 01/11/13 20:24:08
Added: src/main/org/jboss/mq/pm/file CacheStore.java
CacheStoreMBean.java
Log:
Factored out a CacheStore object from the message store. This should lay the
ground work needed so that the MessageCache can use a PM for saving and loading
messages.
Also fixed a small bug in the file PM. It was not properly restoring the message
after a server restart.
Revision ChangesPath
1.1 jbossmq/src/main/org/jboss/mq/pm/file/CacheStore.java
Index: CacheStore.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.mq.pm.file;
import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import javax.jms.JMSException;
import org.jboss.mq.SpyJMSException;
import org.jboss.mq.SpyMessage;
import org.jboss.mq.server.MessageReference;
import org.jboss.system.ServiceMBeanSupport;
/**
* This class manages the persistence needs of the MessageCache
*
* @author Hiram Chirino
* @version$Revision: 1.1 $
*/
public class CacheStore extends ServiceMBeanSupport implements
org.jboss.mq.pm.CacheStore, CacheStoreMBean {
String dataDirectory;
File dataFile;
/**
* @see ServiceMBeanSupport#getName()
*/
public String getName() {
return "JBossMQ-CacheStore";
}
/**
* @see CacheStore#loadFromStorage(MessageReference)
*/
public SpyMessage loadFromStorage(MessageReference mh) throws JMSException {
try {
File f = new File(dataFile, "Message-" + mh.referenceId);
ObjectInputStream is = new ObjectInputStream(new BufferedInputStream(new
FileInputStream(f)));
Object rc = is.readObject();
is.close();
return (SpyMessage) rc;
} catch (ClassNotFoundException e) {
throw new SpyJMSException("Could not load message from secondary storage:
", e);
} catch (IOException e) {
throw new SpyJMSException("Could not load message from secondary storage:
", e);
}
}
/**
* @see CacheStore#saveToStorage(MessageReference, SpyMessage)
*/
public void saveToStorage(MessageReference mh, SpyMessage message) throws
JMSException {
try {
File f = new File(dataFile, "Message-" + mh.referenceId);
ObjectOutputStream os = new ObjectOutputStream(new BufferedOutputStream(new
FileOutputStream(f)));
os.writeObject(message);
os.close();
} catch (IOException e) {
throw new SpyJMSException("Could not load message from secondary storage:
", e);
}
}
/**
* @see CacheStore#removeFromStorage(MessageReference)
*/
public void removeFromStorage(MessageReference mh) throws JMSException {
File f = new File(dataFile, "Message-" + mh.referenceId);
f.delete();
}
/**
* @see CacheStoreMBean#getDataDirectory()
*/
public String getDataDirectory() {
return null;
}
/**
* @see CacheStoreMBean#setDataDirectory(String)
*/
public void setDataDirectory(String newDataDirectory) {
dataDirectory = newDataDirectory;
}
/**
* This gets called to start the service.
*/
protected void startService() throws Exception {
File jbossHome = new File(System.getProperty("jboss.system.home"));
dataFile = new File(jbossHome, dataDirectory);
log.debug("Data directory set to: " + dataFile.getCanonicalPath());
dataFile.mkdirs();
if (!dataFile.isDirectory())
throw new Exception("The configured data directory is not valid: " +
dataDirectory);
// Clean out the directory of any previous files.
File files[] = dataFile.listFiles();
log.debug("Removing " + files.length + " file(s) from: " +
dataFile.getCanonicalPath());
for (int i = 0; i < files.length; i++) {
files[i].delete();
}
}
/**
* @see CacheStoreMBean#getCacheStoreInstance()
*/
public Object getInstance() {
return this;
}
}
1.1 jbossmq/src/main/org/jboss/mq/pm/file/CacheStoreMBean.java
Index: CacheStoreMBean.java
===
/*
* JBoss, the OpenSource J2EE webOS
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package org.jboss.mq.pm.file;
import org.jboss.system.ServiceMBean;
import javax.management.Object
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/server MessageCache.java MessageCacheMBean.java MessageReference.java
User: chirino
Date: 01/11/13 20:23:27
Modified:src/main/org/jboss/mq/server MessageCache.java
MessageCacheMBean.java MessageReference.java
Log:
Factored out a CacheStore object from the message store. This should lay the
ground work needed so that the MessageCache can use a PM for saving and loading
messages.
Also fixed a small bug in the file PM. It was not properly restoring the message
after a server restart.
Revision ChangesPath
1.7 +25 -52jbossmq/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.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- MessageCache.java 2001/11/14 01:53:40 1.6
+++ MessageCache.java 2001/11/14 04:23:27 1.7
@@ -15,6 +15,7 @@
import org.jboss.system.ServiceMBeanSupport;
import org.jboss.mq.SpyMessage;
import javax.jms.JMSException;
+import org.jboss.mq.pm.CacheStore;
/**
* This class implements a Message cache so that larger amounts of messages
@@ -23,7 +24,7 @@
* later.
*
* @author mailto:[EMAIL PROTECTED]";>Hiram Chirino
- * @version$Revision: 1.6 $
+ * @version$Revision: 1.7 $
*/
public class MessageCache extends ServiceMBeanSupport implements MessageCacheMBean,
MBeanRegistration, Runnable
{
@@ -39,8 +40,9 @@
int cacheHits = 0;
int cacheMisses = 0;
- private File dataFile;
- private String dataDirectory;
+ CacheStore cacheStore;
+ ObjectName cacheStoreObjectName;
+
private Thread referenceSoftner;
private long highMemoryMark = 1024L * 1000 * 16;
@@ -219,29 +221,20 @@
//
// Perisitence methods used by the MessageReference.
- // TODO: delegate this work to a PM.
//
- SpyMessage loadFromStorage(MessageReference mh) throws IOException,
ClassNotFoundException
+ SpyMessage loadFromStorage(MessageReference mh) throws JMSException
{
- File f = new File(dataFile, "Message-" + mh.referenceId);
- ObjectInputStream is = new ObjectInputStream(new BufferedInputStream(new
FileInputStream(f)));
- Object rc = is.readObject();
- is.close();
- return (SpyMessage) rc;
+ return (SpyMessage)cacheStore.loadFromStorage(mh);
}
- void saveToStorage(MessageReference mh, SpyMessage message) throws IOException
+ void saveToStorage(MessageReference mh, SpyMessage message) throws JMSException
{
- File f = new File(dataFile, "Message-" + mh.referenceId);
- ObjectOutputStream os = new ObjectOutputStream(new BufferedOutputStream(new
FileOutputStream(f)));
- os.writeObject(message);
- os.close();
+ cacheStore.saveToStorage(mh, message);
}
- void removeFromStorage(MessageReference mh) throws IOException
+ void removeFromStorage(MessageReference mh) throws JMSException
{
- File f = new File(dataFile, "Message-" + mh.referenceId);
- f.delete();
+ cacheStore.removeFromStorage(mh);
}
//
@@ -256,29 +249,15 @@
*/
protected void startService() throws Exception
{
- File jbossHome = new File(System.getProperty("jboss.system.home"));
- dataFile = new File(jbossHome, dataDirectory);
- log.debug("Data directory set to: " + dataFile.getCanonicalPath());
-
- dataFile.mkdirs();
- if (!dataFile.isDirectory())
- throw new Exception("The configured data directory is not valid: " +
dataDirectory);
-
- // Clean out the directory of any previous files.
- File files[] = dataFile.listFiles();
- log.debug("Removing " + files.length + " file(s) from: " +
dataFile.getCanonicalPath());
- for (int i = 0; i < files.length; i++)
- {
- files[i].delete();
- }
-
+
+ cacheStore = (CacheStore)getServer().invoke(cacheStoreObjectName,
"getInstance", new Object[] {}, new String[] {});
+
if (getState() == ServiceMBeanSupport.STARTED)
throw new Exception("Cannot be initialized from the current state");
referenceSoftner = new Thread(this, "JBossMQ Cache Reference Softner");
referenceSoftner.setDaemon(true);
referenceSoftner.start();
-
}
/**
@@ -293,22 +272,6 @@
referenceSoftner = null;
}
- /**
-* Gets the dataDirectory
-* @return Returns a String
-*/
- public String getDataDirectory()
- {
- return dataDirectory;
- }
- /**
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/jdbc PersistenceManager.java
User: chirino
Date: 01/11/13 20:23:27
Modified:src/main/org/jboss/mq/pm/jdbc PersistenceManager.java
Log:
Factored out a CacheStore object from the message store. This should lay the
ground work needed so that the MessageCache can use a PM for saving and loading
messages.
Also fixed a small bug in the file PM. It was not properly restoring the message
after a server restart.
Revision ChangesPath
1.13 +2 -2 jbossmq/src/main/org/jboss/mq/pm/jdbc/PersistenceManager.java
Index: PersistenceManager.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/jdbc/PersistenceManager.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- PersistenceManager.java 2001/11/12 17:01:17 1.12
+++ PersistenceManager.java 2001/11/14 04:23:27 1.13
@@ -40,7 +40,7 @@
*
* @author: Jayesh Parayali ([EMAIL PROTECTED])
*
- * @version $Revision: 1.12 $
+ * @version $Revision: 1.13 $
*/
public class PersistenceManager extends ServiceMBeanSupport implements
PersistenceManagerMBean, org.jboss.mq.pm.PersistenceManager {
@@ -75,7 +75,7 @@
txManager = new TxManager(this);
}
- public org.jboss.mq.pm.PersistenceManager getInstance()
+ public Object getInstance()
{
return this;
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/etc/conf/default jbossmq-service.xml
User: chirino Date: 01/11/13 20:23:27 Modified:src/etc/conf/default jbossmq-service.xml Log: Factored out a CacheStore object from the message store. This should lay the ground work needed so that the MessageCache can use a PM for saving and loading messages. Also fixed a small bug in the file PM. It was not properly restoring the message after a server restart. Revision ChangesPath 1.15 +10 -1 jbossmq/src/etc/conf/default/jbossmq-service.xml Index: jbossmq-service.xml === RCS file: /cvsroot/jboss/jbossmq/src/etc/conf/default/jbossmq-service.xml,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- jbossmq-service.xml 2001/11/12 17:00:26 1.14 +++ jbossmq-service.xml 2001/11/14 04:23:26 1.15 @@ -7,7 +7,7 @@ - + + tmp/jbossmq ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file PersistenceManager.java
User: chirino
Date: 01/11/13 20:23:27
Modified:src/main/org/jboss/mq/pm/file PersistenceManager.java
Log:
Factored out a CacheStore object from the message store. This should lay the
ground work needed so that the MessageCache can use a PM for saving and loading
messages.
Also fixed a small bug in the file PM. It was not properly restoring the message
after a server restart.
Revision ChangesPath
1.10 +7 -5 jbossmq/src/main/org/jboss/mq/pm/file/PersistenceManager.java
Index: PersistenceManager.java
===
RCS file:
/cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/file/PersistenceManager.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- PersistenceManager.java 2001/11/10 21:38:04 1.9
+++ PersistenceManager.java 2001/11/14 04:23:27 1.10
@@ -43,7 +43,7 @@
* persistence.
*
* @author Paul Kendall ([EMAIL PROTECTED])
- * @version$Revision: 1.9 $
+ * @version$Revision: 1.10 $
*/
public class PersistenceManager extends ServiceMBeanSupport implements
PersistenceManagerMBean, org.jboss.mq.pm.PersistenceManager
{
@@ -80,7 +80,7 @@
txManager = new TxManager(this);
}
- public org.jboss.mq.pm.PersistenceManager getInstance()
+ public Object getInstance()
{
return this;
}
@@ -169,7 +169,6 @@
*/
private void restoreTransactions() throws javax.jms.JMSException
{
- //reconstruct TXs
TreeSet txs = new TreeSet();
File[] transactFiles = dataDirFile.listFiles();
if(transactFiles != null)
@@ -180,7 +179,7 @@
if( transactFiles[i].isDirectory() )
{
String dirName = transactFiles[i].toString();
- int start = transactFiles[i].getParent().length();
+ int start = transactFiles[i].getParent().length()+1;
String key = dirName.substring(start);
MessageLog log = new MessageLog(messageCache, transactFiles[i]);
LogInfo info = new LogInfo(log, null);
@@ -229,6 +228,7 @@
{
Object key = i.next();
LogInfo logInfo = (LogInfo)clone.get(key);
+ log.debug("Recovered messages destined for: "+key);
unrestoredMessages.put(key, logInfo.log.restore(txs));
}
@@ -289,9 +289,10 @@
public void restoreQueue(JMSDestination jmsDest, SpyDestination dest)
throws JMSException
{
+ log.debug("restoring destination: "+dest);
//remember this queue
- String queueName = dest.toString();
+ String queueName = dest.toString();
LogInfo info = (LogInfo)messageLogs.get(queueName);
if (info == null)
{
@@ -314,6 +315,7 @@
Map messages = (Map)unrestoredMessages.remove(queueName);
if (messages != null)
{
+ log.debug("Restore message count: "+messages.size());
synchronized (jmsDest)
{
Iterator m = messages.values().iterator();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm PersistenceManagerMBean.java
User: chirino Date: 01/11/13 20:23:27 Modified:src/main/org/jboss/mq/pm PersistenceManagerMBean.java Log: Factored out a CacheStore object from the message store. This should lay the ground work needed so that the MessageCache can use a PM for saving and loading messages. Also fixed a small bug in the file PM. It was not properly restoring the message after a server restart. Revision ChangesPath 1.2 +1 -1 jbossmq/src/main/org/jboss/mq/pm/PersistenceManagerMBean.java Index: PersistenceManagerMBean.java === RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/PersistenceManagerMBean.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- PersistenceManagerMBean.java 2001/11/10 21:38:03 1.1 +++ PersistenceManagerMBean.java 2001/11/14 04:23:27 1.2 @@ -26,7 +26,7 @@ //methods needed for JBossMQService to set up connections //and to require the MessageCache. - PersistenceManager getInstance(); + Object getInstance(); ObjectName getMessageCache(); ___ 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: 187 Successful tests: 148 Errors:25 Failures: 14 [time of test: 14 November 2001 3:59 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. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! 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 easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc JDBCStartCommand.java
User: dbudworth
Date: 01/11/13 19:52:15
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc
JDBCStartCommand.java
Log:
Added check for relatedCMRField existance in execute.
Was assuming there was one and crashing with NPE when attempting to deploy
1:1 cmr beans
Revision ChangesPath
1.7 +5 -2
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCStartCommand.java
Index: JDBCStartCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCStartCommand.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JDBCStartCommand.java 2001/09/11 18:35:00 1.6
+++ JDBCStartCommand.java 2001/11/14 03:52:15 1.7
@@ -23,7 +23,7 @@
* @author mailto:[EMAIL PROTECTED]";>Joe Shevland
* @author mailto:[EMAIL PROTECTED]";>Justin Forder
* @author mailto:[EMAIL PROTECTED]";>Michel de Groot
- * @version $Revision: 1.6 $
+ * @version $Revision: 1.7 $
*/
public class JDBCStartCommand extends JDBCUpdateCommand implements StartCommand {
// Constructors --
@@ -43,7 +43,10 @@
// create relation tables
JDBCCMRFieldBridge[] cmrFields = entity.getJDBCCMRFields();
for(int i=0; ihttps://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Automated JBoss Testsuite Results
JBoss daily test results SUMMARY Number of tests run: 187 Successful tests: 146 Errors:26 Failures: 15 [time of test: 14 November 2001 3:12 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. It is assumed that whoever makes change(s) to jboss that break the test will be fixing the test or jboss, as appropriate! 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 easy, just run the target 'run-basic-testsuite' from the main build.xml. PPS Come on people - there were a few days back in July 2001 when we had ZERO tests failing! Oh, and thanks - remember we love you too! ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: JBossMQ PM XAResource interface
>From: Charles Chan <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: Hiram Chirino <[EMAIL PROTECTED]> >Subject: Re: JBossMQ PM XAResource interface >Date: Tue, 13 Nov 2001 18:29:40 -0800 (PST) > >My initial idea with XML is simple... Just create an >XMLMessage type (extended from TextMessage). Create a >new Session interface that exposes the factory method >to create this type of message. We could also provide >a proprietary message selector based on XPath. That's >what BEA WebLogic basically do. > That would be cool. >However, after much thought, I think what you've >suggested made more sense. HTTP is becoming important. >We need a solid messaging framework over HTTP if we >want reliable web services. > I agree. >I am not sure if JBossSOAP uses JBossMQ as its >transport but it can't unless JBossMQ supports HTTP >and HTTPS. > JBoss SOAP aka JBoss.Net will use the apache Axis server for HTTP and HTTPS. What I want to do is be able either deploy a web service or a plain servlet that would allow JBossMQ clients come in over HTTP/S So what I think we need is an IL that kinda goes like this: HTTPServerIL -> (uses HTTP) -> MQHTTPServlet -> (JVM-IL) -> Server The hard part of this IL is going to be that the server can't directly invoke methods on the client. The client is going to have to poll for asynch message from the client by some thing like: 1. (Data structure accessible via the servlet) <- (JVM-IL) <- Server 2. Client pool -> (uses HTTP) -> MQHTTPServlet -> (Data structure accessible via the servlet) This approach would also let us run the web server in a different process as the MQ server since the JVM-IL in my example could be replaced with any of the other ILs. What do you think?? Regards, Hiram >Any discussion on this issue yet? I would like to look >deeper into this. :) > >Thanks >Charles > > >--- Hiram Chirino <[EMAIL PROTECTED]> wrote: > > > > What were your ideas with XML?? > > > > A feature request that seemed interesting never had > > been implemented was a > > JMS over HTTP. Alot of companys only want to expose > > port 80 at thier > > firewall, and nothing else. > > > > Regards, > > Hiram > > > > >From: Charles Chan <[EMAIL PROTECTED]> > > >Reply-To: [EMAIL PROTECTED] > > >To: Hiram Chirino <[EMAIL PROTECTED]> > > >Subject: Re: JBossMQ PM XAResource interface > > >Date: Tue, 13 Nov 2001 16:15:50 -0800 (PST) > > > > > > > > >--- Hiram Chirino <[EMAIL PROTECTED]> wrote: > > > > > > > I don't think this a huge priority, since the > > stuff > > > > kinda works. But if > > > > your intrested, go for it! > > > > > >I don't think it's a high priority either. The > > >clustering work, however, is still rather unstable > > at > > >this point (I can't even run a JBoss cluster). I am > > >now looking into using XML with JMS and hope to add > > >something to our framework. Other suggestions? > > > > > >Charles > > > > > > > > > > > > > > > > > Regards, > > > > Hiram > > > > > > > > >Any thoughts? > > > > > > > > > >Charles > > > > > > > > > > > > > > > > > > > >--- David Jencks > > <[EMAIL PROTECTED]> > > > > >wrote: > > > > > > On 2001.11.11 22:23:58 -0500 Charles Chan > > wrote: > > > > > > > HI, David, > > > > > > > > > > > > > > I replied your message on the list. To > > tell > > > > you > > > > > > the > > > > > > > truth, I found the JDBC PM stuffs a bit > > > > > > convoluted... > > > > > > > > > > > > That's an understatement;-) > > > > > > > (I admit I am totally new to this > > framework) > > > > > > > > > > > > > > I was thinking of helping Hiram to get > > some > > > > > > clustering > > > > > > > work done. Tell me some of your ideas, > > maybe > > > > they > > > > > > will > > > > > > > fit into the clustering work too. > > > > > > > > > > > > Mostly I was thinking it would be a good > > idea to > > > > > > change the pm interface to > > > > > > expose an XAResource for transaction > > management. > > > > > > This would make using a > > > > > > jca-wrapped xa datasource pretty easy for a > > jdbc > > > > pm. > > > > > > The jca spec mentions > > > > > > the possibility of a caching layer on top of > > a > > > > jca > > > > > > connector: in this case > > > > > > the caching layer registers a > > synchronization > > > > > > interface with the tm, and > > > > > > flushes it's cached changes to the connector > > on > > > > the > > > > > > before completion > > > > > > notification. I'm wondering if it would be > > > > possible > > > > > > to treat the jms stuff > > > > > > as such a caching layer, thus allowing us to > > > > expose > > > > > > the pm's XAResource as > > > > > > the jms implementation's XAResource. This > > would > > > > > > allow 1phase optimization > > > > > > if you are using the same db for jms and > > regular > > > > db > > > > > > storage: I think this > > > > > > would make jdbc based jms the clear speed > > > > winner: > > > > > > otherwise a more special > > > > > > purpose method will be faster. > > > > > > > > > > > > So, I'm not sure
Re: [JBoss-dev] CacheKey copy semantics and speed
Ok, but all of that time was really due to the removal of the MarshalledObject.get(). Running with the CacheKey implementation pre the copy gives basically the same time as the non-MarshalledObject version: 1 minute 48 seconds - Original Message - From: "Scott M Stark" <[EMAIL PROTECTED]> To: "Jboss-Development@Lists. Sourceforge. Net" <[EMAIL PROTECTED]> Sent: Tuesday, November 13, 2001 5:43 PM Subject: Re: [JBoss-dev] CacheKey copy semantics and speed > > Yes it does use byte[] comparisons in a for loop. Let me give you > a push in my direction. We know there is a performance drop in 2.4.4 > that has yet to be resolved, but profiling shows it is related to > interaction > with the entity cache and that the CacheKey ctor ends up being the largest > hotspot. By simply changing the CacheKey to use the input id directly > rather than MarshalledObject, the timing of the bank unit test goes from: > > 2 minutes 43 seconds > > to: > > 1 minute 46 seconds > > Pretty big improvement for a trival change. That's the 80/20 rule in action > big time. > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/cluster/jms ClusterTopicSession.java
User: dmaplesden Date: 01/11/13 17:53:40 Modified:src/main/org/jboss/mq/cluster/jms ClusterTopicSession.java Log: Added message object pool and changed file PM message log to use generic SpyMessage.writeMessage and readMessage methods. Revision ChangesPath 1.5 +9 -9 jbossmq/src/main/org/jboss/mq/cluster/jms/ClusterTopicSession.java Index: ClusterTopicSession.java === RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/cluster/jms/ClusterTopicSession.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- ClusterTopicSession.java 2001/10/28 04:07:34 1.4 +++ ClusterTopicSession.java 2001/11/14 01:53:40 1.5 @@ -42,7 +42,7 @@ * * @author Hiram Chirino ([EMAIL PROTECTED]) * @createdAugust 16, 2001 - * @version$Revision: 1.4 $ + * @version$Revision: 1.5 $ */ public class ClusterTopicSession implements TopicSession @@ -192,7 +192,7 @@ throw new IllegalStateException( "The session is closed" ); } - SpyBytesMessage message = new SpyBytesMessage(); + SpyBytesMessage message = org.jboss.mq.MessagePool.getBytesMessage(); message.header.producerClientId = connection.getClientID(); return message; } @@ -203,7 +203,7 @@ throw new IllegalStateException( "The session is closed" ); } - SpyMapMessage message = new SpyMapMessage(); + SpyMapMessage message = org.jboss.mq.MessagePool.getMapMessage(); message.header.producerClientId = connection.getClientID(); return message; } @@ -214,7 +214,7 @@ throw new IllegalStateException( "The session is closed" ); } - SpyMessage message = new SpyMessage(); + SpyMessage message = org.jboss.mq.MessagePool.getMessage(); message.header.producerClientId = connection.getClientID(); return message; } @@ -225,7 +225,7 @@ throw new IllegalStateException( "The session is closed" ); } - SpyObjectMessage message = new SpyObjectMessage(); + SpyObjectMessage message = org.jboss.mq.MessagePool.getObjectMessage(); message.header.producerClientId = connection.getClientID(); return message; } @@ -236,7 +236,7 @@ throw new IllegalStateException( "The session is closed" ); } - SpyObjectMessage message = new SpyObjectMessage(); + SpyObjectMessage message = org.jboss.mq.MessagePool.getObjectMessage(); message.setObject( object ); message.header.producerClientId = connection.getClientID(); return message; @@ -248,7 +248,7 @@ throw new IllegalStateException( "The session is closed" ); } - SpyStreamMessage message = new SpyStreamMessage(); + SpyStreamMessage message = org.jboss.mq.MessagePool.getStreamMessage(); message.header.producerClientId = connection.getClientID(); return message; } @@ -259,7 +259,7 @@ throw new IllegalStateException( "The session is closed" ); } - SpyTextMessage message = new SpyTextMessage(); + SpyTextMessage message = org.jboss.mq.MessagePool.getTextMessage(); message.header.producerClientId = connection.getClientID(); return message; } @@ -270,7 +270,7 @@ throw new IllegalStateException( "The session is closed" ); } - SpyTextMessage message = new SpyTextMessage(); + SpyTextMessage message = org.jboss.mq.MessagePool.getTextMessage(); message.setText( string ); message.header.producerClientId = connection.getClientID(); return message; ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq MessagePool.java SpyBytesMessage.java SpyEncapsulatedMessage.java SpyMapMessage.java SpyMessage.java SpyObjectMessage.java SpyQueueSender.java SpySession.java SpyStreamMessage.java SpyTextMessage.java SpyTopicPublisher.java SpyXAResourceManager.java
User: dmaplesden
Date: 01/11/13 17:53:40
Modified:src/main/org/jboss/mq SpyBytesMessage.java
SpyEncapsulatedMessage.java SpyMapMessage.java
SpyMessage.java SpyObjectMessage.java
SpyQueueSender.java SpySession.java
SpyStreamMessage.java SpyTextMessage.java
SpyTopicPublisher.java SpyXAResourceManager.java
Added: src/main/org/jboss/mq MessagePool.java
Log:
Added message object pool and changed file PM message log to use generic
SpyMessage.writeMessage and readMessage methods.
Revision ChangesPath
1.5 +2 -2 jbossmq/src/main/org/jboss/mq/SpyBytesMessage.java
Index: SpyBytesMessage.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyBytesMessage.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- SpyBytesMessage.java 2001/10/28 04:07:34 1.4
+++ SpyBytesMessage.java 2001/11/14 01:53:39 1.5
@@ -18,7 +18,7 @@
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.4 $
+ * @version$Revision: 1.5 $
*/
public class SpyBytesMessage
extends SpyMessage
@@ -402,7 +402,7 @@
public SpyMessage myClone()
throws JMSException {
- SpyBytesMessage result = new SpyBytesMessage();
+ SpyBytesMessage result = MessagePool.getBytesMessage();
this.reset();
result.copyProps( this );
if ( this.InternalArray != null ) {
1.4 +2 -2 jbossmq/src/main/org/jboss/mq/SpyEncapsulatedMessage.java
Index: SpyEncapsulatedMessage.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyEncapsulatedMessage.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- SpyEncapsulatedMessage.java 2001/10/28 04:07:34 1.3
+++ SpyEncapsulatedMessage.java 2001/11/14 01:53:39 1.4
@@ -15,7 +15,7 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author Hiram Chirino ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.3 $
+ * @version$Revision: 1.4 $
*/
public class SpyEncapsulatedMessage
extends SpyObjectMessage {
@@ -54,7 +54,7 @@
public SpyMessage myClone()
throws javax.jms.JMSException {
- SpyEncapsulatedMessage result = new SpyEncapsulatedMessage();
+ SpyEncapsulatedMessage result = MessagePool.getEncapsulatedMessage();
result.copyProps( this );
//HACK to get around read only problem
boolean readOnly = result.header.msgReadOnly;
1.4 +2 -2 jbossmq/src/main/org/jboss/mq/SpyMapMessage.java
Index: SpyMapMessage.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyMapMessage.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- SpyMapMessage.java2001/10/28 04:07:34 1.3
+++ SpyMapMessage.java2001/11/14 01:53:39 1.4
@@ -20,7 +20,7 @@
*
* @author Norbert Lataille ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.3 $
+ * @version$Revision: 1.4 $
*/
public class SpyMapMessage
extends SpyMessage
@@ -373,7 +373,7 @@
public SpyMessage myClone()
throws JMSException {
- SpyMapMessage result = new SpyMapMessage();
+ SpyMapMessage result = MessagePool.getMapMessage();
result.copyProps( this );
result.content = ( Hashtable )this.content.clone();
return result;
1.10 +44 -11jbossmq/src/main/org/jboss/mq/SpyMessage.java
Index: SpyMessage.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/SpyMessage.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- SpyMessage.java 2001/11/10 21:38:04 1.9
+++ SpyMessage.java 2001/11/14 01:53:40 1.10
@@ -25,7 +25,7 @@
* @author Hiram Chirino ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
*
- * @version $Revision: 1.9 $
+ * @version $Revision: 1.10 $
*/
public class SpyMessage implements Serializable, Message, Comparable,
Externalizable {
@@ -68,7 +68,7 @@
//For ordering in the JMSServerQueue (set on the server side)
public transient long messageId;
}
-
+
public Header header = new Header();
public transient AcknowledgementRequest ack;
@@ -445,7 +445,7 @@
}
public SpyMessage myClone() throws JMSException {
- SpyMessage result
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/pm/file MessageLog.java
User: dmaplesden
Date: 01/11/13 17:53:40
Modified:src/main/org/jboss/mq/pm/file MessageLog.java
Log:
Added message object pool and changed file PM message log to use generic
SpyMessage.writeMessage and readMessage methods.
Revision ChangesPath
1.7 +46 -45jbossmq/src/main/org/jboss/mq/pm/file/MessageLog.java
Index: MessageLog.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/pm/file/MessageLog.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- MessageLog.java 2001/11/10 21:38:04 1.6
+++ MessageLog.java 2001/11/14 01:53:40 1.7
@@ -29,7 +29,7 @@
*
* @createdAugust 16, 2001
* @author:Paul Kendall ([EMAIL PROTECTED])
- * @version$Revision: 1.6 $
+ * @version$Revision: 1.7 $
*/
public class MessageLog {
@@ -57,11 +57,11 @@
public MessageLog(MessageCache messageCache, File file )
{
- if (messageCache == null)
+ if (messageCache == null)
{
throw new IllegalArgumentException("Need a MessageCache to construct a
MessageLog!");
} // end of if ()
-
+
this.messageCache = messageCache;
queueName = file;
queueName.mkdirs();
@@ -200,22 +200,23 @@
throws IOException {
ObjectOutputStream out = new ObjectOutputStream( new FileOutputStream( file )
);
out.writeLong( message.header.messageId );
- if ( message instanceof SpyEncapsulatedMessage ) {
- out.writeByte( ENCAP_MESS );
- } else if ( message instanceof SpyObjectMessage ) {
- out.writeByte( OBJECT_MESS );
- } else if ( message instanceof SpyBytesMessage ) {
- out.writeByte( BYTES_MESS );
- } else if ( message instanceof SpyMapMessage ) {
- out.writeByte( MAP_MESS );
- } else if ( message instanceof SpyTextMessage ) {
- out.writeByte( TEXT_MESS );
- } else if ( message instanceof SpyStreamMessage ) {
- out.writeByte( STREAM_MESS );
- } else {
- out.writeByte( SPY_MESS );
- }
- message.writeExternal( out );
+ SpyMessage.writeMessage(message,out);
+// if ( message instanceof SpyEncapsulatedMessage ) {
+// out.writeByte( ENCAP_MESS );
+// } else if ( message instanceof SpyObjectMessage ) {
+// out.writeByte( OBJECT_MESS );
+// } else if ( message instanceof SpyBytesMessage ) {
+// out.writeByte( BYTES_MESS );
+// } else if ( message instanceof SpyMapMessage ) {
+// out.writeByte( MAP_MESS );
+// } else if ( message instanceof SpyTextMessage ) {
+// out.writeByte( TEXT_MESS );
+// } else if ( message instanceof SpyStreamMessage ) {
+// out.writeByte( STREAM_MESS );
+// } else {
+// out.writeByte( SPY_MESS );
+// }
+// message.writeExternal( out );
out.flush();
out.close();
}
@@ -224,34 +225,34 @@
throws Exception {
ObjectInputStream in = new ObjectInputStream( new FileInputStream( file ) );
long msgId = in.readLong();
- SpyMessage message = null;
- byte type = in.readByte();
- switch ( type ) {
- case OBJECT_MESS:
-message = new SpyObjectMessage();
-break;
- case BYTES_MESS:
-message = new SpyBytesMessage();
-break;
- case MAP_MESS:
-message = new SpyMapMessage();
-break;
- case STREAM_MESS:
-message = new SpyStreamMessage();
-break;
- case TEXT_MESS:
-message = new SpyTextMessage();
-break;
- case ENCAP_MESS:
-message = new SpyEncapsulatedMessage();
-break;
- default:
-message = new SpyMessage();
- }
- message.readExternal( in );
+ SpyMessage message = SpyMessage.readMessage(in);
+// byte type = in.readByte();
+// switch ( type ) {
+// case OBJECT_MESS:
+//message = new SpyObjectMessage();
+//break;
+// case BYTES_MESS:
+//message = new SpyBytesMessage();
+//break;
+// case MAP_MESS:
+//message = new SpyMapMessage();
+//break;
+// case STREAM_MESS:
+//message = new SpyStreamMessage();
+//break;
+// case TEXT_MESS:
+//message = new SpyTextMessage();
+//break;
+// case ENCAP_MESS:
+//message = new SpyEncapsulatedMessage();
+//break;
+// default:
+//message = new SpyMessage();
+// }
+// message.readExternal( in );
in.close();
message.
[JBoss-dev] CVS update: jbossmq/src/main/org/jboss/mq/server BasicQueue.java MessageCache.java MessageReference.java
User: dmaplesden
Date: 01/11/13 17:53:40
Modified:src/main/org/jboss/mq/server BasicQueue.java
MessageCache.java MessageReference.java
Log:
Added message object pool and changed file PM message log to use generic
SpyMessage.writeMessage and readMessage methods.
Revision ChangesPath
1.9 +5 -3 jbossmq/src/main/org/jboss/mq/server/BasicQueue.java
Index: BasicQueue.java
===
RCS file: /cvsroot/jboss/jbossmq/src/main/org/jboss/mq/server/BasicQueue.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- BasicQueue.java 2001/10/28 04:07:35 1.8
+++ BasicQueue.java 2001/11/14 01:53:40 1.9
@@ -31,7 +31,7 @@
* @author Norbert Lataille ([EMAIL PROTECTED])
* @author David Maplesden ([EMAIL PROTECTED])
* @createdAugust 16, 2001
- * @version$Revision: 1.8 $
+ * @version$Revision: 1.9 $
*/
//abstract public class BasicQueue implements Runnable {
public class BasicQueue {
@@ -211,7 +211,7 @@
restoreMessage(message);
}
}
-
+
class RemoveMessageTask implements Runnable {
MessageReference message;
RemoveMessageTask(MessageReference m) {
@@ -220,6 +220,8 @@
public void run() {
try {
server.getMessageCache().remove(message);
+ //we are finally done with message so we can release it back to pool
+ org.jboss.mq.MessagePool.releaseMessage(message.hardReference);
} catch ( JMSException e ) {
cat.error("Could not remove an acknowleged message from the
message cache: ", e);
}
@@ -257,7 +259,7 @@
Runnable task = new RestoreMessageTask(m, item.subscriberId);
server.getPersistenceManager().getTxManager().addPostRollbackTask(txId,
task);
-
+
task = new RemoveMessageTask(m);
server.getPersistenceManager().getTxManager().addPostCommitTask(txId,
task);
}
1.6 +76 -52jbossmq/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.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- MessageCache.java 2001/11/12 06:36:49 1.5
+++ MessageCache.java 2001/11/14 01:53:40 1.6
@@ -23,38 +23,61 @@
* later.
*
* @author mailto:[EMAIL PROTECTED]";>Hiram Chirino
- * @version$Revision: 1.5 $
+ * @version$Revision: 1.6 $
*/
public class MessageCache extends ServiceMBeanSupport implements MessageCacheMBean,
MBeanRegistration, Runnable
{
+ //pool of message ref objects
+ public static final int MAX_POOL_SIZE = 100*1000;
+ protected ArrayList pool = new ArrayList(MAX_POOL_SIZE);
+
// The cached messages are orded in a LRU linked list
private LinkedList lruCache = new LinkedList();
-
+
// Provides a Unique ID to MessageHanles
private long messageCounter = 0;
int cacheHits = 0;
int cacheMisses = 0;
-
+
private File dataFile;
private String dataDirectory;
private Thread referenceSoftner;
-
+
private long highMemoryMark = 1024L * 1000 * 16;
private long maxMemoryMark = 1024L * 1000 * 32;
public static final long ONE_MEGABYTE = 1024L * 1000;
-
+
int softRefCacheSize = 0;
int totalCacheSize = 0;
-
+
// Used to get notified when message are being deleted by GC
ReferenceQueue referenceQueue = new ReferenceQueue();
-
+
public MessageCache getInstance()
{
return this;
}
+ //this method is only called from within synchronized block, so don't need to
sync
+ protected MessageReference getMessageReference(MessageCache messageCache, Long
referenceId, SpyMessage message) {
+ MessageReference ref = null;
+ if(!pool.isEmpty())
+ ref = (MessageReference)pool.remove(pool.size()-1);
+ else
+ ref = new MessageReference();
+ ref.init(messageCache,referenceId,message);
+ return ref;
+ }
+
+ //this method is only called from within synchronized block, so don't need to
sync
+ protected void releaseMessageReference(MessageReference ref){
+ if(pool.size() < MAX_POOL_SIZE){
+ ref.reset();
+ pool.add(ref);
+ }
+ }
+
/**
* Adds a message to the cache
*/
@@ -63,16 +86,16 @@
log.trace("add lock aquire");
synchronized (this)
{
- MessageReference mh = new MessageReference(this, new
Long(messageCounter++), message);
+ MessageReference mh = getMessag
RE: [JBoss-dev] CacheKey copy semantics and speed
:) you win marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Tuesday, November 13, 2001 8:44 PM |To: Jboss-Development@Lists. Sourceforge. Net |Subject: Re: [JBoss-dev] CacheKey copy semantics and speed | | | |Yes it does use byte[] comparisons in a for loop. Let me give you |a push in my direction. We know there is a performance drop in 2.4.4 |that has yet to be resolved, but profiling shows it is related to |interaction |with the entity cache and that the CacheKey ctor ends up being the largest |hotspot. By simply changing the CacheKey to use the input id directly |rather than MarshalledObject, the timing of the bank unit test goes from: | |2 minutes 43 seconds | |to: | |1 minute 46 seconds | |Pretty big improvement for a trival change. That's the 80/20 rule in action |big time. | |- Original Message - |From: "marc fleury" <[EMAIL PROTECTED]> |To: "marc fleury" <[EMAIL PROTECTED]>; "Scott M Stark" |<[EMAIL PROTECTED]>; "Jboss-Development@Lists. Sourceforge. |Net" <[EMAIL PROTECTED]> |Sent: Tuesday, November 13, 2001 5:24 PM |Subject: RE: [JBoss-dev] CacheKey copy semantics and speed | | |> rereading the equals implementation, |> |> It compares the equals of a marshalled object and I am left wondering how |> fast that really is. |> |> I guess it is a byte[] comparison under it? I don't know. |> |> marcf |> |> |-Original Message- |> |From: marc fleury [mailto:[EMAIL PROTECTED]] |> |Sent: Tuesday, November 13, 2001 8:17 PM |> |To: Scott M Stark; Jboss-Development@Lists. Sourceforge. Net |> |Subject: RE: [JBoss-dev] CacheKey copy semantics and speed |> | |> | |> ||How can it be lightweight when it has to make a deep copy of the true |key |> ||using serialization? Bill's change was to add yet another copy, so |> | |> |because the precalculated stuff is used in the subsequent calls. |> | |> ||now there |> ||is the copying of the true key into a MarshalledObject followed by |> ||a copy of |> ||this |> ||using MarshalledObject.get(). Your change just removed both of these |which |> ||seems |> ||like NullPointerException territory in the equals() method. |> | |> |Yes the mo should be there I will add this. |> | |> ||Your comment in equals about the fool-proofness of this implementation |> ||has already been demonstrated to be false, so unless we go beyond this |> ||how is this class gaining us any performance? |> | |> |Because they are different issues. |> | |> |marcf |> | |> || |> ||- Original Message - |> ||From: "marc fleury" <[EMAIL PROTECTED]> |> ||To: "Scott M Stark" <[EMAIL PROTECTED]>; |> ||"Jboss-Development@Lists. Sourceforge. Net" |> ||<[EMAIL PROTECTED]> |> ||Sent: Tuesday, November 13, 2001 3:59 PM |> ||Subject: RE: [JBoss-dev] CacheKey copy semantics and speed |> || |> || |> ||> The basic cachekey is not expensive, in fact it is more |> ||lightweight than a |> ||> regular key, creating the serialized representation is expensive, and |> ||again |> ||> afair it was bill correcting the copy problem on key reuse |> |inside one VM. |> ||> |> ||> marcf |> ||> |> || |> || |> || |> ||___ |> ||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] CacheKey copy semantics and speed
well, then you don't win, but I don't win either today is a crappy day but the fix is relevant marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Tuesday, November 13, 2001 8:55 PM |To: Jboss-Development@Lists. Sourceforge. Net |Subject: Re: [JBoss-dev] CacheKey copy semantics and speed | | |Ok, but all of that time was really due to the removal of the |MarshalledObject.get(). Running with the CacheKey implementation |pre the copy gives basically the same time as the non-MarshalledObject |version: | |1 minute 48 seconds | |- Original Message - |From: "Scott M Stark" <[EMAIL PROTECTED]> |To: "Jboss-Development@Lists. Sourceforge. Net" |<[EMAIL PROTECTED]> |Sent: Tuesday, November 13, 2001 5:43 PM |Subject: Re: [JBoss-dev] CacheKey copy semantics and speed | | |> |> Yes it does use byte[] comparisons in a for loop. Let me give you |> a push in my direction. We know there is a performance drop in 2.4.4 |> that has yet to be resolved, but profiling shows it is related to |> interaction |> with the entity cache and that the CacheKey ctor ends up being |the largest |> hotspot. By simply changing the CacheKey to use the input id directly |> rather than MarshalledObject, the timing of the bank unit test goes from: |> |> 2 minutes 43 seconds |> |> to: |> |> 1 minute 46 seconds |> |> Pretty big improvement for a trival change. That's the 80/20 rule in |action |> big time. |> | | | |___ |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] CacheKey copy semantics and speed
Yes it does use byte[] comparisons in a for loop. Let me give you a push in my direction. We know there is a performance drop in 2.4.4 that has yet to be resolved, but profiling shows it is related to interaction with the entity cache and that the CacheKey ctor ends up being the largest hotspot. By simply changing the CacheKey to use the input id directly rather than MarshalledObject, the timing of the bank unit test goes from: 2 minutes 43 seconds to: 1 minute 46 seconds Pretty big improvement for a trival change. That's the 80/20 rule in action big time. - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: "marc fleury" <[EMAIL PROTECTED]>; "Scott M Stark" <[EMAIL PROTECTED]>; "Jboss-Development@Lists. Sourceforge. Net" <[EMAIL PROTECTED]> Sent: Tuesday, November 13, 2001 5:24 PM Subject: RE: [JBoss-dev] CacheKey copy semantics and speed > rereading the equals implementation, > > It compares the equals of a marshalled object and I am left wondering how > fast that really is. > > I guess it is a byte[] comparison under it? I don't know. > > marcf > > |-Original Message- > |From: marc fleury [mailto:[EMAIL PROTECTED]] > |Sent: Tuesday, November 13, 2001 8:17 PM > |To: Scott M Stark; Jboss-Development@Lists. Sourceforge. Net > |Subject: RE: [JBoss-dev] CacheKey copy semantics and speed > | > | > ||How can it be lightweight when it has to make a deep copy of the true key > ||using serialization? Bill's change was to add yet another copy, so > | > |because the precalculated stuff is used in the subsequent calls. > | > ||now there > ||is the copying of the true key into a MarshalledObject followed by > ||a copy of > ||this > ||using MarshalledObject.get(). Your change just removed both of these which > ||seems > ||like NullPointerException territory in the equals() method. > | > |Yes the mo should be there I will add this. > | > ||Your comment in equals about the fool-proofness of this implementation > ||has already been demonstrated to be false, so unless we go beyond this > ||how is this class gaining us any performance? > | > |Because they are different issues. > | > |marcf > | > || > ||- Original Message - > ||From: "marc fleury" <[EMAIL PROTECTED]> > ||To: "Scott M Stark" <[EMAIL PROTECTED]>; > ||"Jboss-Development@Lists. Sourceforge. Net" > ||<[EMAIL PROTECTED]> > ||Sent: Tuesday, November 13, 2001 3:59 PM > ||Subject: RE: [JBoss-dev] CacheKey copy semantics and speed > || > || > ||> The basic cachekey is not expensive, in fact it is more > ||lightweight than a > ||> regular key, creating the serialized representation is expensive, and > ||again > ||> afair it was bill correcting the copy problem on key reuse > |inside one VM. > ||> > ||> marcf > ||> > || > || > || > ||___ > ||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] CacheKey copy semantics and speed
rereading the equals implementation, It compares the equals of a marshalled object and I am left wondering how fast that really is. I guess it is a byte[] comparison under it? I don't know. marcf |-Original Message- |From: marc fleury [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, November 13, 2001 8:17 PM |To: Scott M Stark; Jboss-Development@Lists. Sourceforge. Net |Subject: RE: [JBoss-dev] CacheKey copy semantics and speed | | ||How can it be lightweight when it has to make a deep copy of the true key ||using serialization? Bill's change was to add yet another copy, so | |because the precalculated stuff is used in the subsequent calls. | ||now there ||is the copying of the true key into a MarshalledObject followed by ||a copy of ||this ||using MarshalledObject.get(). Your change just removed both of these which ||seems ||like NullPointerException territory in the equals() method. | |Yes the mo should be there I will add this. | ||Your comment in equals about the fool-proofness of this implementation ||has already been demonstrated to be false, so unless we go beyond this ||how is this class gaining us any performance? | |Because they are different issues. | |marcf | || ||- Original Message - ||From: "marc fleury" <[EMAIL PROTECTED]> ||To: "Scott M Stark" <[EMAIL PROTECTED]>; ||"Jboss-Development@Lists. Sourceforge. Net" ||<[EMAIL PROTECTED]> ||Sent: Tuesday, November 13, 2001 3:59 PM ||Subject: RE: [JBoss-dev] CacheKey copy semantics and speed || || ||> The basic cachekey is not expensive, in fact it is more ||lightweight than a ||> regular key, creating the serialized representation is expensive, and ||again ||> afair it was bill correcting the copy problem on key reuse |inside one VM. ||> ||> marcf ||> || || || ||___ ||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] CacheKey copy semantics and speed
One thing I have noticed it that the newbie programmers that are most likely to not implement equals and hashCode correctly, don't use a custom primary key. Instead they use an Integer, Long, or String. -dain > -Original Message- > From: marc fleury [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 13, 2001 5:11 PM > To: Jboss-Development@Lists. Sourceforge. Net > Subject: [JBoss-dev] CacheKey copy semantics and speed > > > I am reading the CMR 2.0 code and I see that it makes > intensive use of the > CacheKey creation (which I guess is normal). > > In cachekey, the change introduced by Bill, i.e. to enforce > copy semantics > is a very slow operation. It involves a full serialization. This has > negative effects. > > 1- it slows the finders > 2- it slows the cmr stuff > 3- thank god it doesn't affect the "normal operation" speed > which is the > optimized lookup > > One of the points of the cachekey is to be fast, uber fast by > precompiling > the key hashcode to be used and the equals. I understand the > problem that > bill was trying to solve with the serialization but it is just too > expensive. > > I want to turn this behavior off by default, Bill if you feel > strongly we > could put an optional field so that these keys are copied but > by default it > is a killer. > > It must be a property of the cache and I intend to expose more of them > through the JMX interface. In any case it would be a > jboss.xml thingy. > > Just being a good boy and following Scott's demand for > "tracking" changes, I > fully agree. > > marcf > > > > > Marc Fleury > President > 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-dev] undeployment of failed deployment fails
touch /var/lib/jboss/deploy/foo.jar .. [AutoDeployer] Auto deploy of file:/home.local/var/lib/jboss/deploy/foo.jar [J2EE Deployer Default] Deploy J2EE application: file:/home.local/var/lib/jboss/deploy/foo.jar [AutoDeployer] Deployment failed:file:/home.local/var/lib/jboss/deploy/foo.jar [AutoDeployer] java.util.zip.ZipException: error in opening zip file [AutoDeployer] at java.util.zip.ZipFile.open(Native Method) [AutoDeployer] at java.util.zip.ZipFile.(ZipFile.java:110) ... rm /var/lib/jboss/deploy/foo.jar ... [AutoDeployer] Auto undeploy of file:/home.local/var/lib/jboss/deploy/foo.jar [AutoDeployer] Undeployment failed [AutoDeployer] org.jboss.deployment.J2eeDeploymentException: The application " Default" has not been deployed. [AutoDeployer] at org.jboss.deployment.J2eeDeployer.undeploy(J2eeDeployer.java) ... If it was never deployed, it shouldn't try to undeploy it. A message stating that it was never deployed would be nice. This is with jboss 2.4.3. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CacheKey copy semantics and speed
So make it even more efficient by not using the MarshalledObject at all. I'm not saying get rid of CacheKey, get rid of its use of MarshalledObject and use the id directly. - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: "Scott M Stark" <[EMAIL PROTECTED]>; Sent: Tuesday, November 13, 2001 5:16 PM Subject: RE: [JBoss-dev] CacheKey copy semantics and speed > |How can it be lightweight when it has to make a deep copy of the true key > |using serialization? Bill's change was to add yet another copy, so > > because the precalculated stuff is used in the subsequent calls. > > |now there > |is the copying of the true key into a MarshalledObject followed by > |a copy of > |this > |using MarshalledObject.get(). Your change just removed both of these which > |seems > |like NullPointerException territory in the equals() method. > > Yes the mo should be there I will add this. > > |Your comment in equals about the fool-proofness of this implementation > |has already been demonstrated to be false, so unless we go beyond this > |how is this class gaining us any performance? > > Because they are different issues. > > marcf > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CMR container invocation
> > Dain, > > I am reading your stuff and I see that you use the invocation > chain to do > "ADD_RELATION" on the bean you are working with. Is this > what you were > talking about the other day? Yep. > My question is do you really need to go through the container > chain, since > it goes through the security and transactional interceptors > or could you do > without. Do you mean it this way (go through interceptors > again) or do you > only need to invoke that method on the target bean. > > marcf Yes. Adding a bean to a relationship is the equivalent of calling a business method on the bean, because adding a bean to a relationship can change a foreign key on the bean, which is exactly equivalent to setting a cmp-field. If I don't go through the interceptor chain, the bean is not added to the transaction and then doesn't get stored. -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] CacheKey copy semantics and speed
|How can it be lightweight when it has to make a deep copy of the true key |using serialization? Bill's change was to add yet another copy, so because the precalculated stuff is used in the subsequent calls. |now there |is the copying of the true key into a MarshalledObject followed by |a copy of |this |using MarshalledObject.get(). Your change just removed both of these which |seems |like NullPointerException territory in the equals() method. Yes the mo should be there I will add this. |Your comment in equals about the fool-proofness of this implementation |has already been demonstrated to be false, so unless we go beyond this |how is this class gaining us any performance? Because they are different issues. marcf | |- Original Message - |From: "marc fleury" <[EMAIL PROTECTED]> |To: "Scott M Stark" <[EMAIL PROTECTED]>; |"Jboss-Development@Lists. Sourceforge. Net" |<[EMAIL PROTECTED]> |Sent: Tuesday, November 13, 2001 3:59 PM |Subject: RE: [JBoss-dev] CacheKey copy semantics and speed | | |> The basic cachekey is not expensive, in fact it is more |lightweight than a |> regular key, creating the serialized representation is expensive, and |again |> afair it was bill correcting the copy problem on key reuse inside one VM. |> |> marcf |> | | | |___ |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/ejb CacheKey.java
User: mnf999
Date: 01/11/13 17:19:40
Modified:src/main/org/jboss/ejb CacheKey.java
Log:
Warming up :)
Revision ChangesPath
1.18 +7 -6 jboss/src/main/org/jboss/ejb/CacheKey.java
Index: CacheKey.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/CacheKey.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- CacheKey.java 2001/11/13 23:41:20 1.17
+++ CacheKey.java 2001/11/14 01:19:40 1.18
@@ -29,7 +29,7 @@
*
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author Bill Burke
- * @version $Revision: 1.17 $
+ * @version $Revision: 1.18 $
*/
public class CacheKey
implements Externalizable
@@ -78,20 +78,21 @@
this.id = null;
try {
-
+
+ // Equals rely on the MarshalledObject itself
+ mo = new MarshalledObject(id);
- /*
+/*
* FIXME MARCF: The reuse of the primary key is an "exception" and this fix
makes
everyone pay an hefty price. If we really want this behavior we can put
it in
the cache. Is there a test for this?
-
- // Equals rely on the MarshalledObject itself
- mo = new MarshalledObject(id);
+
// Make a copy of the id to enforce copy semantics and
// allow reuse of the original primary key
this.id = mo.get();
*/
+ this.id = id;
// Precompute the hashCode (speed)
hashCode = mo.hashCode();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RH: tools.jar (javac)...
That is how both the bundled tomcat and standalone tomcat handles this. You have to have the JDK tools.jar, or jikes, or some other compiler configured as part of the installation. Since we can't bundle tools.jar and javac.jar is just a black box we don't want to include since it source for it can't be obtained, there is nothing we can do to make this a platform independent zero configuration issue as far as I know. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "David Maplesden" <[EMAIL PROTECTED]> To: "JBossDev (E-mail)" <[EMAIL PROTECTED]> Sent: Tuesday, November 13, 2001 4:14 PM Subject: RE: [JBoss-dev] RH: tools.jar (javac)... > No I haven't and I see now what you mean, I didn't read what you put > carefully enough. Still you might be able to do it this way, IIRC we used > to distribute javac in a javac.jar that was distributed with JBoss to > different platforms and it seemed to work OK. > > I thought the only reason we weren't distributing tools.jar in the same way > is because of licensing issues with Sun. > > That of course brings up a problem with 1) you can't distribute any package > you create that contains tools.jar (I think). > > Perhaps the easiest thing to do for the Jetty dist is to reference tools.jar > as if it exists in the lib/ext dir and simply include a README telling > people what is going on, then they can supply their own (platform specific > if neccessary) jar. > > David > > > -Original Message- > > From: Julian Gosnell [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, November 14, 2001 1:02 PM > > To: David Maplesden; [EMAIL PROTECTED]; > > [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] RH: tools.jar (javac)... > > > > > > David Maplesden wrote: > > > > > 1) worked fine for me... > > > > Have you tried it on different architectures? > > > > My concern is that if I do the build on Linux, the tools.jar > > from my 1.3.1 > > distrib may not work on e.g. a Mac etc... > > > > Jules ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RH: tools.jar (javac)...
No I haven't and I see now what you mean, I didn't read what you put carefully enough. Still you might be able to do it this way, IIRC we used to distribute javac in a javac.jar that was distributed with JBoss to different platforms and it seemed to work OK. I thought the only reason we weren't distributing tools.jar in the same way is because of licensing issues with Sun. That of course brings up a problem with 1) you can't distribute any package you create that contains tools.jar (I think). Perhaps the easiest thing to do for the Jetty dist is to reference tools.jar as if it exists in the lib/ext dir and simply include a README telling people what is going on, then they can supply their own (platform specific if neccessary) jar. David > -Original Message- > From: Julian Gosnell [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 14, 2001 1:02 PM > To: David Maplesden; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] RH: tools.jar (javac)... > > > David Maplesden wrote: > > > 1) worked fine for me... > > Have you tried it on different architectures? > > My concern is that if I do the build on Linux, the tools.jar > from my 1.3.1 > distrib may not work on e.g. a Mac etc... > > Jules > > > > > > > > > -Original Message- > > > From: Julian Gosnell [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, November 14, 2001 10:05 AM > > > To: [EMAIL PROTECTED] > > > Subject: [JBoss-dev] RH: tools.jar (javac)... > > > > > > > > > > > > Jasper requires tools.jar to be available to it. > > > > > > Should I: > > > > > > 1. copy it from my java distrib into lib/ext with the > Jetty jars at > > > build time (is the jar arch independent) > > > 2. try to get it on the JBOSS_CLASSPATH and hope > Jetty/Jasper can see > > > it... > > > 3. find another way - suggestions ? > > > > > > In short, given the ClassLoader architecture of RH - how > should I get > > > hold of tools.jar > > > > > > Thanks for your time, > > > > > > > > > Jules > > > > > > > > > > > > _ > > > Do You Yahoo!? > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > > ___ > > > 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 > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CacheKey copy semantics and speed
How can it be lightweight when it has to make a deep copy of the true key using serialization? Bill's change was to add yet another copy, so now there is the copying of the true key into a MarshalledObject followed by a copy of this using MarshalledObject.get(). Your change just removed both of these which seems like NullPointerException territory in the equals() method. Your comment in equals about the fool-proofness of this implementation has already been demonstrated to be false, so unless we go beyond this how is this class gaining us any performance? - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: "Scott M Stark" <[EMAIL PROTECTED]>; "Jboss-Development@Lists. Sourceforge. Net" <[EMAIL PROTECTED]> Sent: Tuesday, November 13, 2001 3:59 PM Subject: RE: [JBoss-dev] CacheKey copy semantics and speed > The basic cachekey is not expensive, in fact it is more lightweight than a > regular key, creating the serialized representation is expensive, and again > afair it was bill correcting the copy problem on key reuse inside one VM. > > marcf > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-481533 ] new file - stopjboss.sh (for RH)
Patches item #481533, was opened at 2001-11-13 16:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=481533&group_id=22866 Category: JBossServer Group: v2.5 Rabbit Hole (unstable) Status: Open Resolution: None Priority: 5 Submitted By: Jeff Tulley (jtulley) Assigned to: Nobody/Anonymous (nobody) Summary: new file - stopjboss.sh (for RH) Initial Comment: This is the UNIX shell script equivalent to the stopjboss.bat that I just submitted. It also calls into the Shutdown class, with the optional args of hostname and port. It goes in server/src/bin -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=481533&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[Fwd: [JBoss-dev] RH: tools.jar (javac)...]
--- Begin Message --- David Maplesden wrote: > 1) worked fine for me... Have you tried it on different architectures? My concern is that if I do the build on Linux, the tools.jar from my 1.3.1 distrib may not work on e.g. a Mac etc... Jules > > > > -Original Message- > > From: Julian Gosnell [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, November 14, 2001 10:05 AM > > To: [EMAIL PROTECTED] > > Subject: [JBoss-dev] RH: tools.jar (javac)... > > > > > > > > Jasper requires tools.jar to be available to it. > > > > Should I: > > > > 1. copy it from my java distrib into lib/ext with the Jetty jars at > > build time (is the jar arch independent) > > 2. try to get it on the JBOSS_CLASSPATH and hope Jetty/Jasper can see > > it... > > 3. find another way - suggestions ? > > > > In short, given the ClassLoader architecture of RH - how should I get > > hold of tools.jar > > > > Thanks for your time, > > > > > > Jules > > > > > > > > _ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > ___ > > 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 --- End Message ---
RE: [JBoss-dev] CacheKey copy semantics and speed
The basic cachekey is not expensive, in fact it is more lightweight than a regular key, creating the serialized representation is expensive, and again afair it was bill correcting the copy problem on key reuse inside one VM. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Scott |M Stark |Sent: Tuesday, November 13, 2001 6:51 PM |To: Jboss-Development@Lists. Sourceforge. Net |Subject: Re: [JBoss-dev] CacheKey copy semantics and speed | | |It wasn't Bill that added this. It was first added in 1.2 and then expanded |in |1.8, more copying added in 1.10, etc. This whole thing started to create an |idiot proof key, which cannot be done. Instead we have a big fat expensive |key that is killing performance. Let the user live and die by their ability |to |code an entity key class. | | |Scott Stark |Chief Technology Officer |JBoss Group, LLC | |- Original Message - |From: "marc fleury" <[EMAIL PROTECTED]> |To: "Jboss-Development@Lists. Sourceforge. Net" |<[EMAIL PROTECTED]> |Sent: Tuesday, November 13, 2001 3:11 PM |Subject: [JBoss-dev] CacheKey copy semantics and speed | | |> I am reading the CMR 2.0 code and I see that it makes intensive |use of the |> CacheKey creation (which I guess is normal). |> |> In cachekey, the change introduced by Bill, i.e. to enforce copy |semantics |> is a very slow operation. It involves a full serialization. This has |> negative effects. |> |> 1- it slows the finders |> 2- it slows the cmr stuff |> 3- thank god it doesn't affect the "normal operation" speed which is the |> optimized lookup |> |> One of the points of the cachekey is to be fast, uber fast by |precompiling |> the key hashcode to be used and the equals. I understand the |problem that |> bill was trying to solve with the serialization but it is just too |> expensive. |> |> I want to turn this behavior off by default, Bill if you feel strongly we |> could put an optional field so that these keys are copied but by default |it |> is a killer. |> |> It must be a property of the cache and I intend to expose more of them |> through the JMX interface. In any case it would be a jboss.xml thingy. |> |> Just being a good boy and following Scott's demand for |"tracking" changes, |I |> fully agree. |> |> marcf |> |> |> |> |> Marc Fleury |> President |> 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] CMR container invocation
Dain, I am reading your stuff and I see that you use the invocation chain to do "ADD_RELATION" on the bean you are working with. Is this what you were talking about the other day? My question is do you really need to go through the container chain, since it goes through the security and transactional interceptors or could you do without. Do you mean it this way (go through interceptors again) or do you only need to invoke that method on the target bean. marcf Marc Fleury President JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] CacheKey copy semantics and speed
It wasn't Bill that added this. It was first added in 1.2 and then expanded in 1.8, more copying added in 1.10, etc. This whole thing started to create an idiot proof key, which cannot be done. Instead we have a big fat expensive key that is killing performance. Let the user live and die by their ability to code an entity key class. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "marc fleury" <[EMAIL PROTECTED]> To: "Jboss-Development@Lists. Sourceforge. Net" <[EMAIL PROTECTED]> Sent: Tuesday, November 13, 2001 3:11 PM Subject: [JBoss-dev] CacheKey copy semantics and speed > I am reading the CMR 2.0 code and I see that it makes intensive use of the > CacheKey creation (which I guess is normal). > > In cachekey, the change introduced by Bill, i.e. to enforce copy semantics > is a very slow operation. It involves a full serialization. This has > negative effects. > > 1- it slows the finders > 2- it slows the cmr stuff > 3- thank god it doesn't affect the "normal operation" speed which is the > optimized lookup > > One of the points of the cachekey is to be fast, uber fast by precompiling > the key hashcode to be used and the equals. I understand the problem that > bill was trying to solve with the serialization but it is just too > expensive. > > I want to turn this behavior off by default, Bill if you feel strongly we > could put an optional field so that these keys are copied but by default it > is a killer. > > It must be a property of the cache and I intend to expose more of them > through the JMX interface. In any case it would be a jboss.xml thingy. > > Just being a good boy and following Scott's demand for "tracking" changes, I > fully agree. > > marcf > > > > > Marc Fleury > President > 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-dev] CVS update: newsite build.xml
User: tmcsys Date: 01/11/13 15:44:42 Modified:.build.xml Log: Allow users to build website.ear without building and including snapshots.war. To build website and manual: build.sh -Dmodules=website,manual -Dsnapshot.disable=true -Dsnapshot-export-cvs.disable=true website To build website: build.sh -Dmodules=website -Dsnapshot.disable=true -Dsnapshot-export-cvs.disable=true website Revision ChangesPath 1.24 +24 -3 newsite/build.xml Index: build.xml === RCS file: /cvsroot/jboss/newsite/build.xml,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- build.xml 2001/11/02 17:29:53 1.23 +++ build.xml 2001/11/13 23:44:42 1.24 @@ -10,7 +10,7 @@ - + @@ -414,9 +414,12 @@ - - + + + + @@ -442,6 +445,24 @@ + + + + + + + + + + + + + + + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/metadata website-application-nosnaps.xml
User: tmcsys Date: 01/11/13 15:43:17 Added: src/metadata website-application-nosnaps.xml Log: Allow users to build website.ear without building and including snapshots.war. To build website and manual: build.sh -Dmodules=website,manual -Dsnapshot.disable=true -Dsnapshot-export-cvs.disable=true website To build website: build.sh -Dmodules=website -Dsnapshot.disable=true -Dsnapshot-export-cvs.disable=true website Revision ChangesPath 1.1 newsite/src/metadata/website-application-nosnaps.xml Index: website-application-nosnaps.xml === JBoss Website website.war / ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb CacheKey.java
User: mnf999
Date: 01/11/13 15:41:20
Modified:src/main/org/jboss/ejb CacheKey.java
Log:
The performance of the copy semantics is just too expensive, if we want to enforce
the copy semantics in the future (commented out here) then we should put that in some
cache class that can read a configuration field.
This is intended to speed up the finder (large ones) and 2.0 CMR that makes
extensive use of these.
Revision ChangesPath
1.17 +11 -1 jboss/src/main/org/jboss/ejb/CacheKey.java
Index: CacheKey.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/CacheKey.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- CacheKey.java 2001/08/03 17:15:43 1.16
+++ CacheKey.java 2001/11/13 23:41:20 1.17
@@ -29,7 +29,7 @@
*
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author Bill Burke
- * @version $Revision: 1.16 $
+ * @version $Revision: 1.17 $
*/
public class CacheKey
implements Externalizable
@@ -78,11 +78,21 @@
this.id = null;
try {
+
+
+ /*
+ * FIXME MARCF: The reuse of the primary key is an "exception" and this fix
makes
+ everyone pay an hefty price. If we really want this behavior we can put
it in
+ the cache. Is there a test for this?
+
// Equals rely on the MarshalledObject itself
mo = new MarshalledObject(id);
// Make a copy of the id to enforce copy semantics and
// allow reuse of the original primary key
this.id = mo.get();
+
+ */
+
// Precompute the hashCode (speed)
hashCode = mo.hashCode();
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-481521 ] new file - bin\stopjboss.bat
Patches item #481521, was opened at 2001-11-13 15:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=481521&group_id=22866 Category: JBossServer Group: v2.5 Rabbit Hole (unstable) Status: Open Resolution: None Priority: 5 Submitted By: Jeff Tulley (jtulley) Assigned to: Nobody/Anonymous (nobody) Summary: new file - bin\stopjboss.bat Initial Comment: This batch file simply calls into RH's Shutdown class, passing in the optional host name and port, to do a complete shutdown of JBoss. This ought to go into server/src/bin -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=481521&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs/common jboss-tomcat.jsp
User: tmcsys Date: 01/11/13 15:12:19 Modified:src/docs/common jboss-tomcat.jsp Log: Fix the picture Revision ChangesPath 1.3 +3 -2 newsite/src/docs/common/jboss-tomcat.jsp Index: jboss-tomcat.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/common/jboss-tomcat.jsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- jboss-tomcat.jsp 2001/10/12 23:01:28 1.2 +++ jboss-tomcat.jsp 2001/11/13 23:12:19 1.3 @@ -1,3 +1,4 @@ +<%-- $Id: jboss-tomcat.jsp,v 1.3 2001/11/13 23:12:19 tmcsys Exp $ --%> STOP! USE THE BUNDLE @@ -9,7 +10,7 @@ A FULL J2EE STACK -The +The JBoss organization wants to deliver a complete J2EE based product to the market. The JBoss organization decided to integrate the Tomcat engine stack with a running version of JBoss in a single VM. Now you can serve all your servlet and JSP needs @@ -288,4 +289,4 @@ For a full example including a servlet and an EJB, see the tomcat-test.ear in the contrib/tomcat module - \ No newline at end of file + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CacheKey copy semantics and speed
I am reading the CMR 2.0 code and I see that it makes intensive use of the CacheKey creation (which I guess is normal). In cachekey, the change introduced by Bill, i.e. to enforce copy semantics is a very slow operation. It involves a full serialization. This has negative effects. 1- it slows the finders 2- it slows the cmr stuff 3- thank god it doesn't affect the "normal operation" speed which is the optimized lookup One of the points of the cachekey is to be fast, uber fast by precompiling the key hashcode to be used and the equals. I understand the problem that bill was trying to solve with the serialization but it is just too expensive. I want to turn this behavior off by default, Bill if you feel strongly we could put an optional field so that these keys are copied but by default it is a killer. It must be a property of the cache and I intend to expose more of them through the JMX interface. In any case it would be a jboss.xml thingy. Just being a good boy and following Scott's demand for "tracking" changes, I fully agree. marcf Marc Fleury President JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Do we need a stop.java?
The 2.4 shutdown code is not applicable to 3.0 as the services layer has changed significantly, and still has more to do. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "Jeff Tulley" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 13, 2001 2:12 PM Subject: [JBoss-dev] Do we need a stop.java? Hey all, I just ported the old 2.4.x version of Stop.java over to Rabbit Hole, then realized that there is a Shutdown.java command that actually does a full shutdown. So, before I chuck the "new" version of Stop.java as a "fun academic exercise", I was wondering if the stop functionality is needed and/or useful. The old Stop.java did not perform a full shutdown, but instead stopped each of the MBeans. Not being a JBoss power user (yet?), I do not know if such stop functionality is every really useful. The version I had was updated to use the RMIAdaptor instead of the old JMXAdaptor. Keep (and submit as a patch) or scrap it? Regards, Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., the leading provider of Net services software. ___ 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] Do we need a stop.java?
I've never seen the stop.java, but the shutdown now proceeds by calling shutdown on ServiceController, which undeploys all mbeans(registered with it) in reverse order of their deployment. So I think the Stop.java would duplicate this functionality but worse, since it has no way to know what order to shut the mbeans down in. david jencks On 2001.11.13 17:12:36 -0500 Jeff Tulley wrote: > Hey all, >I just ported the old 2.4.x version of Stop.java over to Rabbit Hole, > then realized that there is a Shutdown.java command that actually does a > full shutdown. So, before I chuck the "new" version of Stop.java as a > "fun academic exercise", I was wondering if the stop functionality is > needed and/or useful. The old Stop.java did not perform a full shutdown, > but instead stopped each of the MBeans. Not being a JBoss power user > (yet?), I do not know if such stop functionality is every really useful. > > The version I had was updated to use the RMIAdaptor instead of the old > JMXAdaptor. > > Keep (and submit as a patch) or scrap it? > > Regards, > > Jeff Tulley ([EMAIL PROTECTED]) > (801)861-5322 > Novell, Inc., the leading provider of Net services software. > > > ___ > 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] Do we need a stop.java?
Hmm, now I see you are asking if "stop all without undeploy" is useful. I don't think so: it is very apt to interfere with the stopping/restarting of mbeans based on their mbean-ref dependencies. In particular, unless you stop mbeans in the reverse order of their deployment (actually startup), some will stop others. I don't think this order is accessible. Most of our mbeans don't actually implement stop properly (so they can be restarted). I can't think of any reason to stop all the mbeans without stopping the server. david jencks On 2001.11.13 17:12:36 -0500 Jeff Tulley wrote: > Hey all, >I just ported the old 2.4.x version of Stop.java over to Rabbit Hole, > then realized that there is a Shutdown.java command that actually does a > full shutdown. So, before I chuck the "new" version of Stop.java as a > "fun academic exercise", I was wondering if the stop functionality is > needed and/or useful. The old Stop.java did not perform a full shutdown, > but instead stopped each of the MBeans. Not being a JBoss power user > (yet?), I do not know if such stop functionality is every really useful. > > The version I had was updated to use the RMIAdaptor instead of the old > JMXAdaptor. > > Keep (and submit as a patch) or scrap it? > > Regards, > > Jeff Tulley ([EMAIL PROTECTED]) > (801)861-5322 > Novell, Inc., the leading provider of Net services software. > > > ___ > 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] Message object pools for MQ
Just a warning too, a side effect of this is I made a very slight change to the way the file PM writes its messages to disk, so any old files from the file PM won't work after you download the change, you will have to delete them. > -Original Message- > From: David Maplesden [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 14, 2001 11:27 AM > To: JBossDev (E-mail) > Subject: [JBoss-dev] Message object pools for MQ > > > > For those MQ heads out there. > > I thought it was about time we started pooling our message > objects, since > the JMS server uses so many of them. I have just about finished > implementing a very simple object pooling structure for the > various types of > spy messages and message reference objects. > > My early tests indicate a reasonable performance improvement (most > noticeable with non-persistent messaging where you don't have the PM > overhead). I don't think the changes will break anything > anyone else is > currently doing so barring any strenuous objections I will > finish testing > and commit later today. > > Cheers > David. > > ___ > 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/iiop/src/main/org/jboss/iiop CorbaORBServiceMBean.java
User: reverbel
Date: 01/11/13 14:47:08
Modified:iiop/src/main/org/jboss/iiop CorbaORBServiceMBean.java
Log:
Changed base class for RH: was org.jboss.util.ServiceMBean, now is
org.jboss.system.ServiceMBean.
Revision ChangesPath
1.4 +2 -2 contrib/iiop/src/main/org/jboss/iiop/CorbaORBServiceMBean.java
Index: CorbaORBServiceMBean.java
===
RCS file:
/cvsroot/jboss/contrib/iiop/src/main/org/jboss/iiop/CorbaORBServiceMBean.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- CorbaORBServiceMBean.java 2001/08/09 14:19:02 1.3
+++ CorbaORBServiceMBean.java 2001/11/13 22:47:08 1.4
@@ -11,10 +11,10 @@
* Mbean interface for the JBoss CORBA ORB service.
*
* @author mailto:[EMAIL PROTECTED]";>Ole Husgaard
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*/
public interface CorbaORBServiceMBean
- extends org.jboss.util.ServiceMBean
+ extends org.jboss.system.ServiceMBean
{
// Constants -
public static final String OBJECT_NAME = ":service=JBossCorbaORB";
___
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 OperationAnalysis.java
User: reverbel Date: 01/11/13 14:43:28 Modified:iiop/src/main/org/jboss/iiop/rmi OperationAnalysis.java Log: Fixed bug in the analysis of operations of non-remote interfaces: RMIIIOPViolationException should not be thrown in this case. Revision ChangesPath 1.3 +3 -2 contrib/iiop/src/main/org/jboss/iiop/rmi/OperationAnalysis.java Index: OperationAnalysis.java === RCS file: /cvsroot/jboss/contrib/iiop/src/main/org/jboss/iiop/rmi/OperationAnalysis.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- OperationAnalysis.java2001/08/08 20:19:39 1.2 +++ OperationAnalysis.java2001/11/13 22:43:28 1.3 @@ -22,7 +22,7 @@ * Specification", version 1.1 (01-06-07). * * @author mailto:[EMAIL PROTECTED]";>Ole Husgaard - * @version $Revision: 1.2 $ + * @version $Revision: 1.3 $ */ public class OperationAnalysis extends AbstractAnalysis @@ -59,7 +59,8 @@ !RemoteException.class.isAssignableFrom(ex[i]) ) a.add(ExceptionAnalysis.getExceptionAnalysis(ex[i])); // map this } - if (!gotRemoteException) + if (!gotRemoteException && + Remote.class.isAssignableFrom(method.getDeclaringClass())) throw new RMIIIOPViolationException( "All interface methods must throw java.rmi.RemoteException, " + "or a superclass of java.rmi.RemoteException, but method " + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] communicating changes
On 2001.11.13 16:11:47 -0500 Scott M Stark wrote: > That was a good start to which there was one reply that was a question > by you asking if the change to the jbossmq layer would work. There were > other messages threads in which elements of this was discussed, but I > never got the feeling from these that a decision had been made as to the > efficacy of the approach. There was no concluding "this is how we have > worked it out..." concluding message that I saw. Maybe I missed. Good point, the warning message wasn't very loud. (I got it back from jboss-dev but can't find it in the archives) I think I assumed that the initial discussion between Rickard who I think basically proposed the idea and Marc and others had established that the mbean-ref style of dependency was a good idea, only needing implementation. I think another thing to consider is that without tests, there is essentially no way to find out if something is broken. It's not easy to test a cluster, especially if you only have one machine;-), but maybe some startup/sanity checks could be possible. david jencks > > > Scott Stark > Chief Technology Officer > JBoss Group, LLC > > - Original Message - > From: "David Jencks" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, November 13, 2001 11:47 AM > Subject: Re: [JBoss-dev] communicating changes > > > > Like this? > > > http://www.mail-archive.com/jboss-development%40lists.sourceforge.net/msg110 > 85.html > > > > david jencks > > > > On 2001.11.13 13:43:12 -0500 Scott M Stark wrote: > > > Part of the problem with communicating architecture changes is that > > > discussions are embedded in threads whose subject ultimiately is > > > virtually meaningless for the concluding remarks. Also, the > conclusions > > > about what is to be done are often left implied based on the thread > > > arguments. > > > > > > If your going to make an architectural change, especially if it is an > > > incomptible > > > one, clearly state that is a message with an approriate subject that > > > concludes > > > with a task list of the changes. > > > > > > > > > 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-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs petstore_frames.html
User: tmcsys Date: 01/11/13 14:26:50 Modified:src/docs petstore_frames.html Log: Adapt to new site design Revision ChangesPath 1.4 +3 -4 newsite/src/docs/petstore_frames.html Index: petstore_frames.html === RCS file: /cvsroot/jboss/newsite/src/docs/petstore_frames.html,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- petstore_frames.html 2001/10/04 00:17:28 1.3 +++ petstore_frames.html 2001/11/13 22:26:50 1.4 @@ -1,15 +1,14 @@ + - JBoss Pet Store - - + + Run the Java Pet Store using JBoss - ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Message object pools for MQ
For those MQ heads out there. I thought it was about time we started pooling our message objects, since the JMS server uses so many of them. I have just about finished implementing a very simple object pooling structure for the various types of spy messages and message reference objects. My early tests indicate a reasonable performance improvement (most noticeable with non-persistent messaging where you don't have the PM overhead). I don't think the changes will break anything anyone else is currently doing so barring any strenuous objections I will finish testing and commit later today. Cheers David. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/ejbql EJBQLParser.java SQLTarget.java
User: dsundstrom
Date: 01/11/13 14:26:25
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/ejbql
EJBQLParser.java SQLTarget.java
Log:
Remove typo that caused the literal "WHERE" to be case sensitive.
Made idenfification variables case insensitive as required by the spec.
Revision ChangesPath
1.8 +13 -16
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/ejbql/EJBQLParser.java
Index: EJBQLParser.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/ejbql/EJBQLParser.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- EJBQLParser.java 2001/11/06 04:21:44 1.7
+++ EJBQLParser.java 2001/11/13 22:26:25 1.8
@@ -247,7 +247,10 @@
SQLTarget target = (SQLTarget)a.getTarget();
List clause = new ArrayList();
- for(String s = a.pop().toString(); !"WHERE".equals(s); s =
a.pop().toString()) {
+ for(String s = a.pop().toString();
+ !"WHERE".equalsIgnoreCase(s);
+ s = a.pop().toString()) {
+
clause.add(s);
}
@@ -975,24 +978,16 @@
}
protected Parser identifier() {
- return new Word();
- }
-
-/*
- protected Parser inputParameter() {
- Parser inputParam = new InputParameter();
- inputParam.setAssembler(new Assembler() {
+ Word identifier = new Word();
+ identifier.setAssembler(new Assembler() {
public void workOn(Assembly a) {
-SQLTarget target = (SQLTarget)a.getTarget();
-InputParameterToken token = (InputParameterToken)a.pop();
-
-target.registerParameter(token);
-a.push("?");
+// convert identifier to lowercase
+// identifiers are case insensitive
+a.push(a.pop().toString().toLowerCase());
}
});
- return inputParam;
+ return identifier;
}
-*/
protected Parser cmpField() {
Word cmpFieldParser = new Word();
@@ -1056,7 +1051,9 @@
identificationVariable.setAssembler(new Assembler() {
public void workOn(Assembly a) {
SQLTarget target = (SQLTarget)a.getTarget();
-String identifier = a.pop().toString();
+// convert identifier to lowercase
+// identifiers are case insensitive
+String identifier = a.pop().toString().toLowerCase();
if(!target.isIdentifierRegistered(identifier)) {
a.setInvalid();
1.8 +2 -2
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/ejbql/SQLTarget.java
Index: SQLTarget.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/ejbql/SQLTarget.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- SQLTarget.java2001/11/06 04:21:44 1.7
+++ SQLTarget.java2001/11/13 22:26:25 1.8
@@ -122,7 +122,7 @@
// is this a select object(o) style query?
if(selectPathList.size() == 1) {
- String identifier = (String)selectPathList.get(0);
+ String identifier = ((String)selectPathList.get(0)).toLowerCase();
// verify that the abstract schema already exists
// this method will throw an exception if the identifier
@@ -131,7 +131,7 @@
selectPath = identifier;
} else {
// select a.b.c.d style query
- String path = (String)selectPathList.get(0);
+ String path = ((String)selectPathList.get(0)).toLowerCase();
for(int i=1; i < selectPathList.size(); i++) {
// are we done yet?
if(ihttps://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Do we need a stop.java?
Hey all, I just ported the old 2.4.x version of Stop.java over to Rabbit Hole, then realized that there is a Shutdown.java command that actually does a full shutdown. So, before I chuck the "new" version of Stop.java as a "fun academic exercise", I was wondering if the stop functionality is needed and/or useful. The old Stop.java did not perform a full shutdown, but instead stopped each of the MBeans. Not being a JBoss power user (yet?), I do not know if such stop functionality is every really useful. The version I had was updated to use the RMIAdaptor instead of the old JMXAdaptor. Keep (and submit as a patch) or scrap it? Regards, Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., the leading provider of Net services software. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Tomcat 4.0 with JBoss 3.0alpha
No, the catalina service has not been updated to work with 3.0 yet. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Brian Sondergaard To: [EMAIL PROTECTED] Sent: Tuesday, November 13, 2001 1:12 PM Subject: [JBoss-dev] Tomcat 4.0 with JBoss 3.0alpha I'm sure I'm overlooking the key issues here, but is it currently possible to use JBoss (3.0a) with Tomcat (4.0x)? I got the catalina plug-in down but can't build it. It's apparently associated with the JBoss 2.4, not 3.0. More specifically, it's looking for classes like org.jboss.security.SecurityDomain that I think are 2.4 things. Thanks for any insight. Brian Sondergaard ___ 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 InterfaceAnalysis.java
User: reverbel
Date: 01/11/13 13:28:24
Modified:iiop/src/main/org/jboss/iiop/rmi InterfaceAnalysis.java
Log:
Fixed bug in calculateOperationAnalysisMap(). This bug shows up for
non-remote interfaces containing methods that follows the JavaBean
attribute pattern (i.e., a getFoo() method or a pair of getFoo()/setFoo()
methods) .
Corrected array indexing typo in calculateAllTypeIds().
Revision ChangesPath
1.4 +11 -6 contrib/iiop/src/main/org/jboss/iiop/rmi/InterfaceAnalysis.java
Index: InterfaceAnalysis.java
===
RCS file:
/cvsroot/jboss/contrib/iiop/src/main/org/jboss/iiop/rmi/InterfaceAnalysis.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- InterfaceAnalysis.java2001/08/10 16:14:31 1.3
+++ InterfaceAnalysis.java2001/11/13 21:28:24 1.4
@@ -42,7 +42,7 @@
* Specification", version 1.1 (01-06-07).
*
* @author mailto:[EMAIL PROTECTED]";>Ole Husgaard
- * @version $Revision: 1.3 $
+ * @version $Revision: 1.4 $
*/
public class InterfaceAnalysis
extends ContainerAnalysis
@@ -169,11 +169,16 @@
AttributeAnalysis attr = attributes[i];
oa = attr.getAccessorAnalysis();
- operationAnalysisMap.put(oa.getIDLName(), oa);
- oa = attr.getMutatorAnalysis();
- if (oa != null)
+ // Not having an accessor analysis means that
+ // the attribute is not in a remote interface
+ if (oa != null) {
operationAnalysisMap.put(oa.getIDLName(), oa);
+
+oa = attr.getMutatorAnalysis();
+if (oa != null)
+ operationAnalysisMap.put(oa.getIDLName(), oa);
+ }
}
}
@@ -190,8 +195,8 @@
String[] ss = intfs[i].getAllTypeIds();
for (int j = 0; j < ss.length; ++j)
-if (!a.contains(ss[i]))
- a.add(ss[i]);
+if (!a.contains(ss[j]))
+ a.add(ss[j]);
}
allTypeIds = new String[a.size() + 1];
allTypeIds[0] = getRepositoryId();
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RH: tools.jar (javac)...
1) worked fine for me... > -Original Message- > From: Julian Gosnell [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 14, 2001 10:05 AM > To: [EMAIL PROTECTED] > Subject: [JBoss-dev] RH: tools.jar (javac)... > > > > Jasper requires tools.jar to be available to it. > > Should I: > > 1. copy it from my java distrib into lib/ext with the Jetty jars at > build time (is the jar arch independent) > 2. try to get it on the JBOSS_CLASSPATH and hope Jetty/Jasper can see > it... > 3. find another way - suggestions ? > > In short, given the ClassLoader architecture of RH - how should I get > hold of tools.jar > > Thanks for your time, > > > Jules > > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > ___ > 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] Tomcat 4.0 with JBoss 3.0alpha
I'm sure I'm overlooking the key issues here, but is it currently possible to use JBoss (3.0a) with Tomcat (4.0x)? I got the catalina plug-in down but can't build it. It's apparently associated with the JBoss 2.4, not 3.0. More specifically, it's looking for classes like org.jboss.security.SecurityDomain that I think are 2.4 things. Â Thanks for any insight. Â Brian Sondergaard Â
Re: [JBoss-dev] communicating changes
That was a good start to which there was one reply that was a question by you asking if the change to the jbossmq layer would work. There were other messages threads in which elements of this was discussed, but I never got the feeling from these that a decision had been made as to the efficacy of the approach. There was no concluding "this is how we have worked it out..." concluding message that I saw. Maybe I missed. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 13, 2001 11:47 AM Subject: Re: [JBoss-dev] communicating changes > Like this? > http://www.mail-archive.com/jboss-development%40lists.sourceforge.net/msg110 85.html > > david jencks > > On 2001.11.13 13:43:12 -0500 Scott M Stark wrote: > > Part of the problem with communicating architecture changes is that > > discussions are embedded in threads whose subject ultimiately is > > virtually meaningless for the concluding remarks. Also, the conclusions > > about what is to be done are often left implied based on the thread > > arguments. > > > > If your going to make an architectural change, especially if it is an > > incomptible > > one, clearly state that is a message with an approriate subject that > > concludes > > with a task list of the changes. > > > > > > 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] RH: tools.jar (javac)...
Jasper requires tools.jar to be available to it. Should I: 1. copy it from my java distrib into lib/ext with the Jetty jars at build time (is the jar arch independent) 2. try to get it on the JBOSS_CLASSPATH and hope Jetty/Jasper can see it... 3. find another way - suggestions ? In short, given the ClassLoader architecture of RH - how should I get hold of tools.jar Thanks for your time, Jules _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc JDBCTypeFactory.java
User: dsundstrom
Date: 01/11/13 12:43:50
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc JDBCTypeFactory.java
Log:
Fixed lame bug where the wrong hashtable was used to determine if a type is
a known dependent value class.
Revision ChangesPath
1.7 +2 -2
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCTypeFactory.java
Index: JDBCTypeFactory.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCTypeFactory.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JDBCTypeFactory.java 2001/11/01 23:10:09 1.6
+++ JDBCTypeFactory.java 2001/11/13 20:43:50 1.7
@@ -29,7 +29,7 @@
* this class is to flatten the JDBCValueClassMetaData into columns.
*
* @author mailto:[EMAIL PROTECTED]";>Dain Sundstrom
- * @version $Revision: 1.6 $
+ * @version $Revision: 1.7 $
*/
public class JDBCTypeFactory {
// the type mapping to use with the specified database
@@ -209,7 +209,7 @@
ArrayList properties = new ArrayList();
Class javaType = propertyMetaData.getPropertyType();
- if(!complexTypes.containsKey(javaType)) {
+ if(!valueClassesByType.containsKey(javaType)) {
// this property is a simple type
// which makes this the end of the line for recursion
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-481461 ] minor change to deploy.mf
Patches item #481461, was opened at 2001-11-13 12:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=481461&group_id=22866 Category: JBossServer Group: v2.5 Rabbit Hole (unstable) Status: Open Resolution: None Priority: 5 Submitted By: Jeff Tulley (jtulley) Assigned to: Nobody/Anonymous (nobody) Summary: minor change to deploy.mf Initial Comment: /src/etc/deploy.mf, the metafile that is bundled into deploy.jar, has not been changed to reflect the new Rabbit Hole packaging of the Deployer class. This class used to be in org.jboss.jmx.client, it is now in org.jboss.jmx.service. Minor thing, really. attached is a unified diff file of the change. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376687&aid=481461&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbossmq/src/etc/conf/cluster jbossmq-service.xml
User: charles_chan Date: 01/11/13 12:29:15 Modified:src/etc/conf/cluster jbossmq-service.xml Log: - Incorporate old fixes from default/ to cluster/ Revision ChangesPath 1.2 +33 -7 jbossmq/src/etc/conf/cluster/jbossmq-service.xml Index: jbossmq-service.xml === RCS file: /cvsroot/jboss/jbossmq/src/etc/conf/cluster/jbossmq-service.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- jbossmq-service.xml 2001/11/12 03:23:56 1.1 +++ jbossmq-service.xml 2001/11/13 20:29:15 1.2 @@ -7,7 +7,7 @@ - + - + -->
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata JDBCRelationshipRoleMetaData.java
User: dsundstrom
Date: 01/11/13 12:19:07
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata
JDBCRelationshipRoleMetaData.java
Log:
Added an error message for when a relationship is defined for a non-existant
entity.
Eliminated the weird foreign key column names that were sometimes generated
for uni-directional relationships.
Revision ChangesPath
1.8 +42 -11
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCRelationshipRoleMetaData.java
Index: JDBCRelationshipRoleMetaData.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/metadata/JDBCRelationshipRoleMetaData.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- JDBCRelationshipRoleMetaData.java 2001/10/29 17:26:40 1.7
+++ JDBCRelationshipRoleMetaData.java 2001/11/13 20:19:07 1.8
@@ -22,7 +22,7 @@
* ejb-jar.xml file's ejb-relation elements.
*
* @author mailto:[EMAIL PROTECTED]";>Dain Sundstrom
- * @version $Revision: 1.7 $
+ * @version $Revision: 1.8 $
*/
public final class JDBCRelationshipRoleMetaData {
/**
@@ -69,36 +69,67 @@
RelationshipRoleMetaData relationshipRole) throws DeploymentException {
this.relationMetaData = relationMetaData;
+ RelationshipRoleMetaData relatedRole =
+ relationshipRole.getRelatedRoleMetaData();
relationshipRoleName = relationshipRole.getRelationshipRoleName();
multiplicityOne = relationshipRole.isMultiplicityOne();
cascadeDelete = relationshipRole.isCascadeDelete();
- cmrFieldName = relationshipRole.getCMRFieldName();
+ String tempCmrFieldName = relationshipRole.getCMRFieldName();
+ if(tempCmrFieldName == null) {
+ // no cmr field on this side use relatedEntityName_relatedCMRFieldName
+ tempCmrFieldName = relatedRole.getEntityName() + "_" +
+ relatedRole.getCMRFieldName();
+ }
+ cmrFieldName = tempCmrFieldName;
+
cmrFieldType = relationshipRole.getCMRFieldType();
+ // get the entity for this role
entity = application.getBeanByEjbName(relationshipRole.getEntityName());
-
- if (entity == null)
- throw new DeploymentException("Related entity:
"+relationshipRole.getEntityName()+" not found for: "+relationshipRoleName);
+ if(entity == null) {
+ throw new DeploymentException("Entity: " +
+ relationshipRole.getEntityName() +
+ " not found for: " + relationshipRoleName);
+ }
if(relationMetaData.isTableMappingStyle()) {
// load all pks of entity into tableKeys map
for(Iterator i = entity.getCMPFields().iterator(); i.hasNext(); ) {
JDBCCMPFieldMetaData cmpField = (JDBCCMPFieldMetaData)i.next();
if(cmpField.isPrimaryKeyMember()) {
- cmpField = new JDBCCMPFieldMetaData(entity, cmpField,
getCMRFieldName() + "_" + cmpField.getFieldName(), false);
+ cmpField = new JDBCCMPFieldMetaData(
+ entity,
+ cmpField,
+ getCMRFieldName() + "_" + cmpField.getFieldName(),
+ false);
tableKeyFields.put(cmpField.getFieldName(), cmpField);
}
+ }
+ } else if(relatedRole.isMultiplicityOne()){
+ // get the related entity
+ String relatedEntityName =
+ relatedRole.getEntityName();
+ JDBCEntityMetaData relatedEntity =
+ application.getBeanByEjbName(relatedEntityName);
+ if(relatedEntity == null) {
+throw new DeploymentException("Entity: " + relatedEntityName +
+ " not found for: " + relationshipRoleName);
}
- } else if(relationshipRole.getRelatedRoleMetaData().isMultiplicityOne()){
+
// load all pks of related entity into foreignKeys map
- String relatedEntityName =
relationshipRole.getRelatedRoleMetaData().getEntityName();
- JDBCEntityMetaData relatedEntity =
application.getBeanByEjbName(relatedEntityName);
- for(Iterator i = relatedEntity.getCMPFields().iterator(); i.hasNext(); ) {
+ for(Iterator i = relatedEntity.getCMPFields().iterator();
+ i.hasNext();
+ ) {
+
JDBCCMPFieldMetaData cmpField = (JDBCCMPFieldMetaData)i.next();
if(cmpField.isPrimaryKeyMember()) {
- cmpField = new JDBCCMPFieldMetaData(entity, cmpField,
getCMRFieldName() + "_" + cmpField.getFieldName(), false);
+ cmpField = new JDBCCMPFieldMetaData(
+ entity,
+ cmpField,
+
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc JDBCRemoveEntityCommand.java
User: dsundstrom
Date: 01/11/13 12:15:24
Modified:src/main/org/jboss/ejb/plugins/cmp/jdbc
JDBCRemoveEntityCommand.java
Log:
Fixed a bug where if a related entity was related two ways with cascade
delete, the command would attempt to remove the entity twice. Now before
an entity is deleted, the command checks to see if the entity is a memeber
of the already deleted set.
Revision ChangesPath
1.7 +10 -3
jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCRemoveEntityCommand.java
Index: JDBCRemoveEntityCommand.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/cmp/jdbc/JDBCRemoveEntityCommand.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JDBCRemoveEntityCommand.java 2001/11/10 22:50:25 1.6
+++ JDBCRemoveEntityCommand.java 2001/11/13 20:15:24 1.7
@@ -27,7 +27,7 @@
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Joe Shevland
* @author mailto:[EMAIL PROTECTED]";>Justin Forder
- * @version $Revision: 1.6 $
+ * @version $Revision: 1.7 $
*/
public class JDBCRemoveEntityCommand
extends JDBCUpdateCommand
@@ -78,6 +78,7 @@
throw new RemoveException("Could not remove " + context.getId());
}
+ HashSet deletedEntities = new HashSet();
for(int i=0; ihttps://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] communicating changes
Like this? http://www.mail-archive.com/jboss-development%40lists.sourceforge.net/msg11085.html david jencks On 2001.11.13 13:43:12 -0500 Scott M Stark wrote: > Part of the problem with communicating architecture changes is that > discussions are embedded in threads whose subject ultimiately is > virtually meaningless for the concluding remarks. Also, the conclusions > about what is to be done are often left implied based on the thread > arguments. > > If your going to make an architectural change, especially if it is an > incomptible > one, clearly state that is a message with an approriate subject that > concludes > with a task list of the changes. > > > 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
RV: [JBoss-dev] loading 10 EBs takes 5s 1st time called
Damn the reply-to button -Mensaje original- De: Ignacio Coloma [mailto:[EMAIL PROTECTED]] Enviado el: martes, 13 de noviembre de 2001 18:28 Para: Dain Sundstrom Asunto: RE: [JBoss-dev] loading 10 EBs takes 5s 1st time called Could it be the database cache? Just guessing. > -Mensaje original- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]En nombre > de Dain Sundstrom > Enviado el: martes, 13 de noviembre de 2001 16:51 > Para: 'Tim Fox'; Dain Sundstrom; 'Peter Levart'; > [EMAIL PROTECTED] > Asunto: RE: [JBoss-dev] loading 10 EBs takes 5s 1st time called > > > Well, I'm not focusing on this kind of optimization currently, > and it takes > approximately 1s to access 20 beans on my machine. Down the road, I'll > profile the code. > > -dain > > > -Original Message- > > From: Tim Fox [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, November 13, 2001 10:27 AM > > To: Dain Sundstrom; 'Peter Levart'; > > [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] loading 10 EBs takes 5s 1st time called > > > > > > Have you thought of profiling the code to determine what's > > taking so long? > > > > > -Original Message- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf > > > Of Dain Sundstrom > > > Sent: 13 November 2001 15:49 > > > To: 'Peter Levart'; [EMAIL PROTECTED] > > > Subject: RE: [JBoss-dev] loading 10 EBs takes 5s 1st time called > > > > > > > > > > Hello! > > > > > > > > I just wanted to know if somebody has a straight answer. I'm > > > > using JBoss 3.0 > > > > alpha with CMP 2.0. > > > > > > > > The first time I reference let's say 10 Entity Beans after a > > > > JBoss restart it > > > > takes approx. 5 seconds to retrieve data from them. The > > > > second and subsequent > > > > requests to return data from the same 10 EBs take ~20ms. If I > > > > later request > > > > data from some other 10 EBs for the first time it takes > > > > another 5 seconds. > > > > I'm using commit option B. I watched the SQL that gets sent > > > > to database > > > > (using Sybase's "ribo") and it is the same SQL sequence for > > > > the 1st time as > > > > for the 2nd and subsequent requests, so this overhead is > > not from the > > > > database. > > > > > > > > I'm just curious what takes it so long (1/2 second for an EB) > > > > the first time > > > > the EB's data is referenced. Is this the time it takes to > > > > create new instance > > > > in the pool of EBs? Will this overhead go away after some > > > > time of running > > > > when the number of instances reaches the pool's limit? > > > > > > > > What I wanted to know is what is happening behind the scenes > > > > (I read from > > > > time to time on this list about dynamic bytecode generation > > > > and similar but I > > > > thought this was only used to create Proxies...). > > > > > > > > > > I was curious also, so I re-ran my test. The second run > > always takes > > > slightly less time ~1-2 sec. The only thing I can think of that is > > > different in the first execution is the bytecode generator. On > > > my machine, > > > a 1.4 athalon, it doesn't take anywhere 1/2 second per > > bean. I really > > > haven't been focusing on this type of optimization, but I > > can easily add a > > > line to the init or start method that creates an instance of the > > > bean. Then > > > it will only happen during setup. I look at it after the example > > > code done > > > (later today). > > > > > > -dain > > > > > > ___ > > > 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-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] communicating changes
Part of the problem with communicating architecture changes is that discussions are embedded in threads whose subject ultimiately is virtually meaningless for the concluding remarks. Also, the conclusions about what is to be done are often left implied based on the thread arguments. If your going to make an architectural change, especially if it is an incomptible one, clearly state that is a message with an approriate subject that concludes with a task list of the changes. Scott Stark Chief Technology Officer JBoss Group, LLC ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: Deployment exception on Clustering
Well, see the code I sent under separate cover, but here's how i think you can get exactly the same code execution sequence: [ClusterPartition created, configured, but not started] HAJNDI created, start does nothing (other needed mbeans also created and started similarly) Now the dependencies for ClusterPartition are satisfied, it is started. It does: old init code calls registerCluster(haPartition) on each of the mbeans it depends on (HAJNDI). This method includes the former init code. old start code calls startFromCluster(haPartition) on each of the mbeans it depends on (HAJNDI). This method includes the former start code. Isn't this the same code in the same order as executed previously? I think you can get away with only the calls to registerCluster, no startFromCluster, although this might be why the code I sent doesn't actually work at the moment;-) david jencks On 2001.11.13 12:47:08 -0500 Andreas Schaefer wrote: > Hi Geeks > > I don't think the mbean-ref list will WORK. As you said the > ClusterPartition > will be created, attributes are set BUT it won't be started. > > AFAIK ClusterPartition needs to initialize JChannel before the other HA- > service can start, doesn't it? Yeah, but then this initialization is NOT > STARTED > with the "mbean-ref-list"! So, how to you want to initialize the JChannel > on > ClusterPartition before the other HA-services are started ? REMEBER that > there are attributes which could be set after the creation of the MBean. > > Andy > > > > >> > > name="JBOSS-SYSTEM:service=DefaultPartition"> > > > > > > > > > > > > code="org.jboss.ha.hasessionstate.server.HASessionStateService" > > > > name="JBOSS-SYSTEM:service=HASessionState"> > > > >name="ClusterPartition">JBOSS-SYSTEM:service=DefaultPartition > > > > > > > > > > > > > > > >> > > name="JBOSS-SYSTEM:service=HAJNDI"> > > > >name="ClusterPartition">JBOSS-SYSTEM:service=DefaultPartition > > > > > > > > > > > > > > > > rather than like this: > > > > > > > > > > > >> > > name="JBOSS-SYSTEM:service=DefaultPartition"> > > > > > > > > > > > > JBOSS-SYSTEM:service=HASessionState > > > -ref-list-element> > > > > > > > > JBOSS-SYSTEM:service=HAJNDI > > > t-element> > > > > > > > > > > > > > > > > code="org.jboss.ha.hasessionstate.server.HASessionStateService" > > > > name="JBOSS-SYSTEM:service=HASessionState"> > > > > > > > > > > > > > > > >> > > name="JBOSS-SYSTEM:service=HAJNDI"> > > > > > > > BTW, with the mbean-ref-list > > > example can you please describe to me how calls are ordered? What > MBeans > > > get created first? What order does start() get called? > > > > The mbeans are created and configured in what ever order they happen to > be > > encountered by the autodeployer/ServiceDeployer/code directly calling > > ServiceDeployer etc. > > > > ServiceConfigurator returns a list of objectnames referenced in > mbean-ref > > and mbean-ref-list/mbean-ref-list-element elements. The > ServiceController > > finds out if all of these have been started: if so it registers (with > > itself) and starts the mbean. If not, it waits, and every time an > mbean > is > > started checks to see if all dependencies are satisfied for waiting > beans. > > Once all the dependencies are satisfied for a waiting mbean, it is > started. > > The reverse happens when you stop or undeploy an mbean. > > > > To look at the examples, in the first format the ClusterPartition can > be > > started immediately, since it has no mbean-refs. No matter when the > > HASessionState and HAJNDI mbeans are encountered (i.e. before the > > ClusterPartition mbean), they will not be started until after the > > ClusterPartition mbean is started. > > > > In the second format, the ClusterPartition mbean will be created and > > configured, but not started until after the HASessionState and HAJNDI > > mbeans are started. > > > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/xdocs/howto howtossl.xml
User: tmcsys Date: 01/11/13 10:23:27 Modified:src/xdocs/howto howtossl.xml Log: Add Jetty SSL configuration Revision ChangesPath 1.2 +27 -13manual/src/xdocs/howto/howtossl.xml Index: howtossl.xml === RCS file: /cvsroot/jboss/manual/src/xdocs/howto/howtossl.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- howtossl.xml 2001/09/18 21:38:31 1.1 +++ howtossl.xml 2001/11/13 18:23:27 1.2 @@ -1,5 +1,5 @@ - + Using SSL with JBoss @@ -12,20 +12,16 @@ Introduction - Adding SSL (Secure Socket Layer) support is simple using JBoss 2.4 configured to use Embedded Tomcat 3.2.2. The specific release used was JBoss 2.4 BETA Rel_2_4_0_23. + Adding SSL (Secure Socket Layer) support is simple using JBoss 2.4 with either Tomcat or Jetty Web containers. The specific releases used were JBoss 2.4 BETA Rel_2_4_0_23 with Tomcat 3.2.2, and JBoss-2.4.0_Jetty-3.1.RC8-1. The target system was a RH Linux 6.2 system using the Sun 1.3 JDK and Sun's Secure Socket Extension, JSSE 1.0.2. Outstanding Deployment Issues - Multiple sites - JBoss-Tomcat apparently requires modification in order to support multiple site names and certificates. + Multiple site certificates + Support of certificates for multiple sites is currently under discussion. Please post your requirements to the forums or the jboss-user mailing list. - - JBoss-Jetty - Please post your experiences using SSL and JBoss-Jetty to the jboss-user mailing list. - @@ -45,13 +41,12 @@ Install JSSE Follow steps 1 through 5 of the http://java.sun.com/products/jsse/install.html";>JSSE installation instructions. -Copy the JSSE jars to your $TOMCAT_HOME/lib directory. If you need to run 'keytool' on your system to create and/or import certificates, copy the JSSE jars to $JAVA_HOME/jre/lib/ext. Generate a Server Key and Certificate -The following shell script can be used to create a server certificate for testing: -Note that keystore files will be generated in the directory you run keytool from. +The following shell script can be used to create a "self-signed" server certificate for testing: +The keystore file will be generated in the directory from which you run keytool. Copy the keystore file to an appropriate directory. +Copy the JSSE jars to your $TOMCAT_HOME/lib directory. + If using Jetty - Find the section in the $JBOSS_JETTY_HOME/conf/jetty/jetty.xml configuration file that starts with, "Uncomment this to add an SSL listener". Uncomment the following section, and insert the location of your server key. + + Start JBoss Start JBoss and point your browser to https://your-server-name.your-domain:8443 to test your SSL implementation. + If using "self-signed" certificates, you may have to import your test certificate into your browser. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: Deployment exception on Clustering
On 2001.11.13 13:07:22 -0500 Bill Burke wrote: > Can't we just deprecate the use of init() right now? It would make all > of > our lives much easier and the RabbitHole alpha can go forward with a > working > clustering engine. In the meantime, Sacha and I can work with the > JavaGroups guys to eliminate the need for 2 phase initialization. > > Bill Unfortunately, we would have to back out all the mbean-ref stuff and configuration changes to jbossmq and jbosscx. It would be way less work for me to modify the cluster code to work with mbean refs. david jencks > > > -Original Message- > > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, November 13, 2001 12:47 PM > > To: David Jencks; Bill Burke > > Cc: Sacha Labourey; [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering > > > > > > Hi Geeks > > > > I don't think the mbean-ref list will WORK. As you said the > > ClusterPartition > > will be created, attributes are set BUT it won't be started. > > > > AFAIK ClusterPartition needs to initialize JChannel before the other > HA- > > service can start, doesn't it? Yeah, but then this initialization is > NOT > > STARTED > > with the "mbean-ref-list"! So, how to you want to initialize the > > JChannel on > > ClusterPartition before the other HA-services are started ? REMEBER > that > > there are attributes which could be set after the creation of the > MBean. > > > > Andy > > > > > > >> > > > name="JBOSS-SYSTEM:service=DefaultPartition"> > > > > > > > > > > > > > > > > code="org.jboss.ha.hasessionstate.server.HASessionStateService" > > > > > name="JBOSS-SYSTEM:service=HASessionState"> > > > > >> name="ClusterPartition">JBOSS-SYSTEM:service=DefaultPartition > > > > > > > > > > > > > > > > > > > >> > > > name="JBOSS-SYSTEM:service=HAJNDI"> > > > > >> name="ClusterPartition">JBOSS-SYSTEM:service=DefaultPartition > > > > > > > > > > > > > > > > > > > > rather than like this: > > > > > > > > > > > > > > >> > > > name="JBOSS-SYSTEM:service=DefaultPartition"> > > > > > > > > > > > > > > > JBOSS-SYSTEM:service=HASessionState > > > > -ref-list-element> > > > > > > > > > > JBOSS-SYSTEM:service=HAJNDI > > > > t-element> > > > > > > > > > > > > > > > > > > > > > code="org.jboss.ha.hasessionstate.server.HASessionStateService" > > > > > name="JBOSS-SYSTEM:service=HASessionState"> > > > > > > > > > > > > > > > > > > > >> > > > name="JBOSS-SYSTEM:service=HAJNDI"> > > > > > > > > > > BTW, with the mbean-ref-list > > > > example can you please describe to me how calls are ordered? What > > MBeans > > > > get created first? What order does start() get called? > > > > > > The mbeans are created and configured in what ever order they > > happen to be > > > encountered by the autodeployer/ServiceDeployer/code directly calling > > > ServiceDeployer etc. > > > > > > ServiceConfigurator returns a list of objectnames referenced in > > mbean-ref > > > and mbean-ref-list/mbean-ref-list-element elements. The > > ServiceController > > > finds out if all of these have been started: if so it registers (with > > > itself) and starts the mbean. If not, it waits, and every time an > mbean > > is > > > started checks to see if all dependencies are satisfied for > > waiting beans. > > > Once all the dependencies are satisfied for a waiting mbean, it is > > started. > > > The reverse happens when you stop or undeploy an mbean. > > > > > > To look at the examples, in the first format the ClusterPartition can > be > > > started immediately, since it has no mbean-refs. No matter when the > > > HASessionState and HAJNDI mbeans are encountered (i.e. before the > > > ClusterPartition mbean), they will not be started until after the > > > ClusterPartition mbean is started. > > > > > > In the second format, the ClusterPartition mbean will be created and > > > configured, but not started until after the HASessionState and HAJNDI > > > mbeans are started. > > > > > > > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite/src/docs/developers head.jsp
User: mnf999 Date: 01/11/13 10:05:01 Modified:src/docs/developers head.jsp Log: Revision ChangesPath 1.4 +1 -1 newsite/src/docs/developers/head.jsp Index: head.jsp === RCS file: /cvsroot/jboss/newsite/src/docs/developers/head.jsp,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- head.jsp 2001/11/10 00:37:27 1.3 +++ head.jsp 2001/11/13 18:05:01 1.4 @@ -19,7 +19,7 @@ - + ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: Deployment exception on Clustering
Can't we just deprecate the use of init() right now? It would make all of our lives much easier and the RabbitHole alpha can go forward with a working clustering engine. In the meantime, Sacha and I can work with the JavaGroups guys to eliminate the need for 2 phase initialization. Bill > -Original Message- > From: Andreas Schaefer [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 13, 2001 12:47 PM > To: David Jencks; Bill Burke > Cc: Sacha Labourey; [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering > > > Hi Geeks > > I don't think the mbean-ref list will WORK. As you said the > ClusterPartition > will be created, attributes are set BUT it won't be started. > > AFAIK ClusterPartition needs to initialize JChannel before the other HA- > service can start, doesn't it? Yeah, but then this initialization is NOT > STARTED > with the "mbean-ref-list"! So, how to you want to initialize the > JChannel on > ClusterPartition before the other HA-services are started ? REMEBER that > there are attributes which could be set after the creation of the MBean. > > Andy > > > > >> > > name="JBOSS-SYSTEM:service=DefaultPartition"> > > > > > > > > > > > > code="org.jboss.ha.hasessionstate.server.HASessionStateService" > > > > name="JBOSS-SYSTEM:service=HASessionState"> > > > >name="ClusterPartition">JBOSS-SYSTEM:service=DefaultPartition > > > > > > > > > > > > > > > >> > > name="JBOSS-SYSTEM:service=HAJNDI"> > > > >name="ClusterPartition">JBOSS-SYSTEM:service=DefaultPartition > > > > > > > > > > > > > > > > rather than like this: > > > > > > > > > > > >> > > name="JBOSS-SYSTEM:service=DefaultPartition"> > > > > > > > > > > > > JBOSS-SYSTEM:service=HASessionState > > > -ref-list-element> > > > > > > > > JBOSS-SYSTEM:service=HAJNDI > > > t-element> > > > > > > > > > > > > > > > > code="org.jboss.ha.hasessionstate.server.HASessionStateService" > > > > name="JBOSS-SYSTEM:service=HASessionState"> > > > > > > > > > > > > > > > >> > > name="JBOSS-SYSTEM:service=HAJNDI"> > > > > > > > BTW, with the mbean-ref-list > > > example can you please describe to me how calls are ordered? What > MBeans > > > get created first? What order does start() get called? > > > > The mbeans are created and configured in what ever order they > happen to be > > encountered by the autodeployer/ServiceDeployer/code directly calling > > ServiceDeployer etc. > > > > ServiceConfigurator returns a list of objectnames referenced in > mbean-ref > > and mbean-ref-list/mbean-ref-list-element elements. The > ServiceController > > finds out if all of these have been started: if so it registers (with > > itself) and starts the mbean. If not, it waits, and every time an mbean > is > > started checks to see if all dependencies are satisfied for > waiting beans. > > Once all the dependencies are satisfied for a waiting mbean, it is > started. > > The reverse happens when you stop or undeploy an mbean. > > > > To look at the examples, in the first format the ClusterPartition can be > > started immediately, since it has no mbean-refs. No matter when the > > HASessionState and HAJNDI mbeans are encountered (i.e. before the > > ClusterPartition mbean), they will not be started until after the > > ClusterPartition mbean is started. > > > > In the second format, the ClusterPartition mbean will be created and > > configured, but not started until after the HASessionState and HAJNDI > > mbeans are started. > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: Deployment exception on Clustering
> Look, I apologize for this breaking the cluster code, I will do whatever I > can to help fix it. I would like to know if you have any suggestions on > how I could have provided more warning about the effects or found out that > the code was breaking. I've been talking about this change for > more than a > month, mostly in regards to the jbossmq code, which I could identify as > breaking, and (I think) fixed before checking in the changes. > I have not been viewing the dev list posts lately because I've been really busy. I apologize. I'm just being grumpy. Bill ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: Deployment exception on Clustering
Hi Geeks I don't think the mbean-ref list will WORK. As you said the ClusterPartition will be created, attributes are set BUT it won't be started. AFAIK ClusterPartition needs to initialize JChannel before the other HA- service can start, doesn't it? Yeah, but then this initialization is NOT STARTED with the "mbean-ref-list"! So, how to you want to initialize the JChannel on ClusterPartition before the other HA-services are started ? REMEBER that there are attributes which could be set after the creation of the MBean. Andy > > >> > name="JBOSS-SYSTEM:service=DefaultPartition"> > > > > > > > > > > > name="JBOSS-SYSTEM:service=HASessionState"> > > > JBOSS-SYSTEM:service=DefaultPartition > > > > > > > > > > > >> > name="JBOSS-SYSTEM:service=HAJNDI"> > > > JBOSS-SYSTEM:service=DefaultPartition > > > > > > > > > > > > rather than like this: > > > > > > > > >> > name="JBOSS-SYSTEM:service=DefaultPartition"> > > > > > > > > > JBOSS-SYSTEM:service=HASessionState > > -ref-list-element> > > > > > > JBOSS-SYSTEM:service=HAJNDI > > t-element> > > > > > > > > > > > > > > name="JBOSS-SYSTEM:service=HASessionState"> > > > > > > > > > > > >> > name="JBOSS-SYSTEM:service=HAJNDI"> > > > > BTW, with the mbean-ref-list > > example can you please describe to me how calls are ordered? What MBeans > > get created first? What order does start() get called? > > The mbeans are created and configured in what ever order they happen to be > encountered by the autodeployer/ServiceDeployer/code directly calling > ServiceDeployer etc. > > ServiceConfigurator returns a list of objectnames referenced in mbean-ref > and mbean-ref-list/mbean-ref-list-element elements. The ServiceController > finds out if all of these have been started: if so it registers (with > itself) and starts the mbean. If not, it waits, and every time an mbean is > started checks to see if all dependencies are satisfied for waiting beans. > Once all the dependencies are satisfied for a waiting mbean, it is started. > The reverse happens when you stop or undeploy an mbean. > > To look at the examples, in the first format the ClusterPartition can be > started immediately, since it has no mbean-refs. No matter when the > HASessionState and HAJNDI mbeans are encountered (i.e. before the > ClusterPartition mbean), they will not be started until after the > ClusterPartition mbean is started. > > In the second format, the ClusterPartition mbean will be created and > configured, but not started until after the HASessionState and HAJNDI > mbeans are started. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: Deployment exception on Clustering
On 2001.11.13 11:34:39 -0500 Bill Burke wrote: > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of > David > > Jencks > > Sent: Tuesday, November 13, 2001 9:03 AM > > To: Sacha Labourey > > Cc: Bill Burke; David Jencks; Andreas Schaefer; > > [EMAIL PROTECTED] > > Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering > > > > > > Does this mean that the dependencies can go like this? > > (I added missing name attributes to the mbean-ref's) > > > >> name="JBOSS-SYSTEM:service=DefaultPartition"> > > > > > > > name="JBOSS-SYSTEM:service=HASessionState"> > > name="ClusterPartition">JBOSS-SYSTEM:service=DefaultPartition > > > > > > > >> name="JBOSS-SYSTEM:service=HAJNDI"> > > name="ClusterPartition">JBOSS-SYSTEM:service=DefaultPartition > > > > > > > > rather than like this: > > > > > >> name="JBOSS-SYSTEM:service=DefaultPartition"> > > > > > > JBOSS-SYSTEM:service=HASessionState > -ref-list-element> > > > > JBOSS-SYSTEM:service=HAJNDI > t-element> > > > > > > > > > name="JBOSS-SYSTEM:service=HASessionState"> > > > > > > > >> name="JBOSS-SYSTEM:service=HAJNDI"> > > > > > > ? > > > > How soon? Would you like a fix for the current situation based on the > > second example which is more or less how the system works now (I think > I > > have such a fix nearly working, but it's always hard to know what > "nearly" > > means) or is it ok to wait for the first method based on possible > > JavaGroups changes? > > > > No, we cannot wait for JavaGroups changes. Was Sacha hining that the changes toward hot-deploy (option 1) might be possible with the latest released JavaGroups? This needs to work. Please > do > not modify the code yourself. I'll do the work, just point me to an > example > of how I can access the mbean-ref-list. I'll send you what I have so far. You can also look at ConnectionFactoryLoader and in jbossmq for other examples of this stuff at work. BTW, with the mbean-ref-list > example can you please describe to me how calls are ordered? What MBeans > get created first? What order does start() get called? The mbeans are created and configured in what ever order they happen to be encountered by the autodeployer/ServiceDeployer/code directly calling ServiceDeployer etc. ServiceConfigurator returns a list of objectnames referenced in mbean-ref and mbean-ref-list/mbean-ref-list-element elements. The ServiceController finds out if all of these have been started: if so it registers (with itself) and starts the mbean. If not, it waits, and every time an mbean is started checks to see if all dependencies are satisfied for waiting beans. Once all the dependencies are satisfied for a waiting mbean, it is started. The reverse happens when you stop or undeploy an mbean. To look at the examples, in the first format the ClusterPartition can be started immediately, since it has no mbean-refs. No matter when the HASessionState and HAJNDI mbeans are encountered (i.e. before the ClusterPartition mbean), they will not be started until after the ClusterPartition mbean is started. In the second format, the ClusterPartition mbean will be created and configured, but not started until after the HASessionState and HAJNDI mbeans are started. > > > BTW, nobody has explained to me yet WHY YOU ARE REMOVING INIT. All your > suggestions are just hacks and will muddy the design and complicate it. > Honestly, I'm extremely annoyed that I have to go back to code that had > worked before just because somebody doesn't like init(). Could somebody > please explain why removing init() is so important and how it is such a > critical thing for the JMX framework? > > Well, I thought I did explain it several times repeatedly over the last 2 months, I'll try again. 1. Proper use of init is to set up stuff that DOES NOT depend or reference anything outside of the current mbean. (see Rickard's posts) yesterday 2. Use of init in violation of (1) makes sense only if there is a deployment unit larger than 1 mbean, so you can have m1.init() m2.init() m1.start() m2.start() for a deployment unit consisting of m1, m2. 3. If you have a deployment unit larger than one mbean, as in 2, and ignore (1), and have an n-step startup process start1, start2, start3,...startn, I can easily create some mbeans that rely on this process and the ordering of the mbeans in the deployment unit. Obviously this does not mean that the n-step startup process is architecturally reasonable or privileged in some way. What it does show is that it is possible to rely on more or less accidental dependency relationships in the deplyment mechanism to conceal the actual dependencies. (I hope its the end;-))) Hmm, lets try again. In the hot-deploy environment of jboss 3, we need some way of indicating dependencies between mbeans so we don't try to start things before the services they need to start are present and started. We do have
[JBoss-dev] [ jboss-Bugs-481358 ] UserTransaction bug reproducible
Bugs item #481358, was opened at 2001-11-13 09:07 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=481358&group_id=22866 Category: JBossTX Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel OConnor (docodan) Assigned to: Nobody/Anonymous (nobody) Summary: UserTransaction bug reproducible Initial Comment: This is a resubmission of bug #472868, because I couldn't figure out how to attach code to an existing, closed report. I believe that UserTransaction is still broken with session synchronization as of 2.4.3. I have attached a JAR with complete source code that will reproduce the bug on this JBoss distribution. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=376685&aid=481358&group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] loading 10 EBs takes 5s 1st time called
Well, I'm not focusing on this kind of optimization currently, and it takes approximately 1s to access 20 beans on my machine. Down the road, I'll profile the code. -dain > -Original Message- > From: Tim Fox [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 13, 2001 10:27 AM > To: Dain Sundstrom; 'Peter Levart'; > [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] loading 10 EBs takes 5s 1st time called > > > Have you thought of profiling the code to determine what's > taking so long? > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf > > Of Dain Sundstrom > > Sent: 13 November 2001 15:49 > > To: 'Peter Levart'; [EMAIL PROTECTED] > > Subject: RE: [JBoss-dev] loading 10 EBs takes 5s 1st time called > > > > > > > Hello! > > > > > > I just wanted to know if somebody has a straight answer. I'm > > > using JBoss 3.0 > > > alpha with CMP 2.0. > > > > > > The first time I reference let's say 10 Entity Beans after a > > > JBoss restart it > > > takes approx. 5 seconds to retrieve data from them. The > > > second and subsequent > > > requests to return data from the same 10 EBs take ~20ms. If I > > > later request > > > data from some other 10 EBs for the first time it takes > > > another 5 seconds. > > > I'm using commit option B. I watched the SQL that gets sent > > > to database > > > (using Sybase's "ribo") and it is the same SQL sequence for > > > the 1st time as > > > for the 2nd and subsequent requests, so this overhead is > not from the > > > database. > > > > > > I'm just curious what takes it so long (1/2 second for an EB) > > > the first time > > > the EB's data is referenced. Is this the time it takes to > > > create new instance > > > in the pool of EBs? Will this overhead go away after some > > > time of running > > > when the number of instances reaches the pool's limit? > > > > > > What I wanted to know is what is happening behind the scenes > > > (I read from > > > time to time on this list about dynamic bytecode generation > > > and similar but I > > > thought this was only used to create Proxies...). > > > > > > > I was curious also, so I re-ran my test. The second run > always takes > > slightly less time ~1-2 sec. The only thing I can think of that is > > different in the first execution is the bytecode generator. On > > my machine, > > a 1.4 athalon, it doesn't take anywhere 1/2 second per > bean. I really > > haven't been focusing on this type of optimization, but I > can easily add a > > line to the init or start method that creates an instance of the > > bean. Then > > it will only happen during setup. I look at it after the example > > code done > > (later today). > > > > -dain > > > > ___ > > 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] loading 10 EBs takes 5s 1st time called
Have you thought of profiling the code to determine what's taking so long? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf > Of Dain Sundstrom > Sent: 13 November 2001 15:49 > To: 'Peter Levart'; [EMAIL PROTECTED] > Subject: RE: [JBoss-dev] loading 10 EBs takes 5s 1st time called > > > > Hello! > > > > I just wanted to know if somebody has a straight answer. I'm > > using JBoss 3.0 > > alpha with CMP 2.0. > > > > The first time I reference let's say 10 Entity Beans after a > > JBoss restart it > > takes approx. 5 seconds to retrieve data from them. The > > second and subsequent > > requests to return data from the same 10 EBs take ~20ms. If I > > later request > > data from some other 10 EBs for the first time it takes > > another 5 seconds. > > I'm using commit option B. I watched the SQL that gets sent > > to database > > (using Sybase's "ribo") and it is the same SQL sequence for > > the 1st time as > > for the 2nd and subsequent requests, so this overhead is not from the > > database. > > > > I'm just curious what takes it so long (1/2 second for an EB) > > the first time > > the EB's data is referenced. Is this the time it takes to > > create new instance > > in the pool of EBs? Will this overhead go away after some > > time of running > > when the number of instances reaches the pool's limit? > > > > What I wanted to know is what is happening behind the scenes > > (I read from > > time to time on this list about dynamic bytecode generation > > and similar but I > > thought this was only used to create Proxies...). > > > > I was curious also, so I re-ran my test. The second run always takes > slightly less time ~1-2 sec. The only thing I can think of that is > different in the first execution is the bytecode generator. On > my machine, > a 1.4 athalon, it doesn't take anywhere 1/2 second per bean. I really > haven't been focusing on this type of optimization, but I can easily add a > line to the init or start method that creates an instance of the > bean. Then > it will only happen during setup. I look at it after the example > code done > (later today). > > -dain > > ___ > 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] RE: Deployment exception on Clustering
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of David > Jencks > Sent: Tuesday, November 13, 2001 9:03 AM > To: Sacha Labourey > Cc: Bill Burke; David Jencks; Andreas Schaefer; > [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] RE: Deployment exception on Clustering > > > Does this mean that the dependencies can go like this? > > >name="JBOSS-SYSTEM:service=DefaultPartition"> > > > name="JBOSS-SYSTEM:service=HASessionState"> > JBOSS-SYSTEM:service=DefaultPartition > > > >name="JBOSS-SYSTEM:service=HAJNDI"> > JBOSS-SYSTEM:service=DefaultPartition > > > > rather than like this: > > >name="JBOSS-SYSTEM:service=DefaultPartition"> > > > JBOSS-SYSTEM:service=HASessionState -ref-list-element> > > JBOSS-SYSTEM:service=HAJNDI t-element> > > > > name="JBOSS-SYSTEM:service=HASessionState"> > > > >name="JBOSS-SYSTEM:service=HAJNDI"> > > > ? > > How soon? Would you like a fix for the current situation based on the > second example which is more or less how the system works now (I think I > have such a fix nearly working, but it's always hard to know what "nearly" > means) or is it ok to wait for the first method based on possible > JavaGroups changes? > No, we cannot wait for JavaGroups changes. This needs to work. Please do not modify the code yourself. I'll do the work, just point me to an example of how I can access the mbean-ref-list. BTW, with the mbean-ref-list example can you please describe to me how calls are ordered? What MBeans get created first? What order does start() get called? BTW, nobody has explained to me yet WHY YOU ARE REMOVING INIT. All your suggestions are just hacks and will muddy the design and complicate it. Honestly, I'm extremely annoyed that I have to go back to code that had worked before just because somebody doesn't like init(). Could somebody please explain why removing init() is so important and how it is such a critical thing for the JMX framework? Bill > Thanks > david jencks > > > On 2001.11.13 03:23:23 -0500 Sacha Labourey wrote: > > Hello, > > > > > Unfortunately at this moment in time it is not possible to > hot-deploy a > > > clustered service that depends on state-transfer. You can hot-deploy > > > clustered EJBs though, well at least for SLSB and EBs. Sacha, what > > about > > > SFSBs? > > > > Yes, it is possible. > > > > Next step on my todo list is to speak with Bela about how to implement > > clean > > "local" state transfer and merge protocols. Once done, this should solve > > our > > problems. > > > > BTW Bill, have you seen that JG 1.0 is out with some bug fixes and new > > features (such as merge2 protocol layer) > > > > cheers, > > > > > > > > Sacha > > > > > > > > ___ > 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] loading 10 EBs takes 5s 1st time called
> Hello! > > I just wanted to know if somebody has a straight answer. I'm > using JBoss 3.0 > alpha with CMP 2.0. > > The first time I reference let's say 10 Entity Beans after a > JBoss restart it > takes approx. 5 seconds to retrieve data from them. The > second and subsequent > requests to return data from the same 10 EBs take ~20ms. If I > later request > data from some other 10 EBs for the first time it takes > another 5 seconds. > I'm using commit option B. I watched the SQL that gets sent > to database > (using Sybase's "ribo") and it is the same SQL sequence for > the 1st time as > for the 2nd and subsequent requests, so this overhead is not from the > database. > > I'm just curious what takes it so long (1/2 second for an EB) > the first time > the EB's data is referenced. Is this the time it takes to > create new instance > in the pool of EBs? Will this overhead go away after some > time of running > when the number of instances reaches the pool's limit? > > What I wanted to know is what is happening behind the scenes > (I read from > time to time on this list about dynamic bytecode generation > and similar but I > thought this was only used to create Proxies...). > I was curious also, so I re-ran my test. The second run always takes slightly less time ~1-2 sec. The only thing I can think of that is different in the first execution is the bytecode generator. On my machine, a 1.4 athalon, it doesn't take anywhere 1/2 second per bean. I really haven't been focusing on this type of optimization, but I can easily add a line to the init or start method that creates an instance of the bean. Then it will only happen during setup. I look at it after the example code done (later today). -dain ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] RE: Deployment exception on Clustering
Does this mean that the dependencies can go like this? JBOSS-SYSTEM:service=DefaultPartition JBOSS-SYSTEM:service=DefaultPartition rather than like this: JBOSS-SYSTEM:service=HASessionState JBOSS-SYSTEM:service=HAJNDI ? How soon? Would you like a fix for the current situation based on the second example which is more or less how the system works now (I think I have such a fix nearly working, but it's always hard to know what "nearly" means) or is it ok to wait for the first method based on possible JavaGroups changes? Thanks david jencks On 2001.11.13 03:23:23 -0500 Sacha Labourey wrote: > Hello, > > > Unfortunately at this moment in time it is not possible to hot-deploy a > > clustered service that depends on state-transfer. You can hot-deploy > > clustered EJBs though, well at least for SLSB and EBs. Sacha, what > about > > SFSBs? > > Yes, it is possible. > > Next step on my todo list is to speak with Bela about how to implement > clean > "local" state transfer and merge protocols. Once done, this should solve > our > problems. > > BTW Bill, have you seen that JG 1.0 is out with some bug fixes and new > features (such as merge2 protocol layer) > > cheers, > > > > Sacha > > > ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] loading 10 EBs takes 5s 1st time called
Hello! I just wanted to know if somebody has a straight answer. I'm using JBoss 3.0 alpha with CMP 2.0. The first time I reference let's say 10 Entity Beans after a JBoss restart it takes approx. 5 seconds to retrieve data from them. The second and subsequent requests to return data from the same 10 EBs take ~20ms. If I later request data from some other 10 EBs for the first time it takes another 5 seconds. I'm using commit option B. I watched the SQL that gets sent to database (using Sybase's "ribo") and it is the same SQL sequence for the 1st time as for the 2nd and subsequent requests, so this overhead is not from the database. I'm just curious what takes it so long (1/2 second for an EB) the first time the EB's data is referenced. Is this the time it takes to create new instance in the pool of EBs? Will this overhead go away after some time of running when the number of instances reaches the pool's limit? What I wanted to know is what is happening behind the scenes (I read from time to time on this list about dynamic bytecode generation and similar but I thought this was only used to create Proxies...). Peter ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] RE: Deployment exception on Clustering
Hello, > Unfortunately at this moment in time it is not possible to hot-deploy a > clustered service that depends on state-transfer. You can hot-deploy > clustered EJBs though, well at least for SLSB and EBs. Sacha, what about > SFSBs? Yes, it is possible. Next step on my todo list is to speak with Bela about how to implement clean "local" state transfer and merge protocols. Once done, this should solve our problems. BTW Bill, have you seen that JG 1.0 is out with some bug fixes and new features (such as merge2 protocol layer) cheers, Sacha ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/system ServiceConfigurator.java
User: d_jencks
Date: 01/11/12 23:55:00
Modified:src/main/org/jboss/system ServiceConfigurator.java
Log:
Fixed dumb bug in mbean-ref-list handling
Revision ChangesPath
1.6 +21 -17jboss/src/main/org/jboss/system/ServiceConfigurator.java
Index: ServiceConfigurator.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/system/ServiceConfigurator.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ServiceConfigurator.java 2001/11/10 21:38:06 1.5
+++ ServiceConfigurator.java 2001/11/13 07:55:00 1.6
@@ -42,7 +42,7 @@
*
* @author mailto:[EMAIL PROTECTED]";>Marc Fleury
* @author mailto:[EMAIL PROTECTED]";>Hiram Chirino
- * @version $Revision: 1.5 $
+ * @version $Revision: 1.6 $
*
* 20010830 marc fleury:
*
@@ -274,37 +274,41 @@
}
// Set lists of mbean references (object names)
- NodeList mbeanRefLists = mbeanElement.getElementsByTagName("mbean-ref-list");
- for (int j = 0; j < mbeanRefLists.getLength(); j++) {
- Element mbeanRefListElement = (Element)mbeanRefLists.item(j);
- String mbeanRefListName = mbeanRefListElement.getAttribute("name");
+ NodeList mBeanRefLists = mbeanElement.getElementsByTagName("mbean-ref-list");
+ for (int j = 0; j < mBeanRefLists.getLength(); j++) {
+ Element mBeanRefListElement = (Element)mBeanRefLists.item(j);
+ String mBeanRefListName = mBeanRefListElement.getAttribute("name");
MBeanAttributeInfo[] attributes = info.getAttributes();
for (int k = 0; k < attributes.length; k++) {
-if (mbeanRefListName.equals(attributes[k].getName())) {
+if (mBeanRefListName.equals(attributes[k].getName())) {
- NodeList mbeanRefList =
mbeanRefListElement.getElementsByTagName("mbean-ref-list-element");
- ArrayList mbeanRefs = new ArrayList();
- for (int l = 0; l < mbeanRefList.getLength(); l++)
+ NodeList mBeanRefList =
mBeanRefListElement.getElementsByTagName("mbean-ref-list-element");
+ ArrayList mBeanRefListNames = new ArrayList();
+ for (int l = 0; l < mBeanRefList.getLength(); l++)
{
- Element mbeanRefElement = (Element)mbeanRefList.item(l);
- if (!mbeanRefElement.hasChildNodes())
+ Element mBeanRefElement = (Element)mBeanRefList.item(l);
+ if (!mBeanRefElement.hasChildNodes())
{
throw new DeploymentException("Empty
mbean-ref-list-element!");
} // end of if ()
// Get the mbeanRef value
- String mbeanRefValue =
((Text)mbeanRefElement.getFirstChild()).getData().trim();
- ObjectName mbeanRefObjectName = new ObjectName(mbeanRefValue);
- if (!mBeanRefs.contains(mbeanRefObjectName))
+ String mBeanRefValue =
((Text)mBeanRefElement.getFirstChild()).getData().trim();
+ ObjectName mBeanRefObjectName = new ObjectName(mBeanRefValue);
+ if (!mBeanRefListNames.contains(mBeanRefObjectName))
{
- mBeanRefs.add(mbeanRefObjectName);
+ mBeanRefListNames.add(mBeanRefObjectName);
} // end of if ()
+ if (!mBeanRefs.contains(mBeanRefObjectName))
+ {
+ mBeanRefs.add(mBeanRefObjectName);
+ } // end of if ()
} // end of for ()
- log.debug(mbeanRefListName + " set to " + mbeanRefs + " in " +
objectName);
- server.setAttribute(objectName, new Attribute(mbeanRefListName,
mbeanRefs));
+ log.debug(mBeanRefListName + " set to " + mBeanRefListNames + " in "
+ objectName);
+ server.setAttribute(objectName, new Attribute(mBeanRefListName,
mBeanRefListNames));
break;
}
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
