[JBoss-dev] CVS update: jbosstest/src/main/org/jboss/test/security/ejb EntityBeanImpl.java RunAsMDB.java
User: starksm
Date: 01/07/19 03:20:26
Modified:src/main/org/jboss/test/security/ejb Tag: Branch_2_4
EntityBeanImpl.java RunAsMDB.java
Log:
Update active subject access test
Revision ChangesPath
No revision
No revision
1.2.2.2 +2 -24
jbosstest/src/main/org/jboss/test/security/ejb/EntityBeanImpl.java
Index: EntityBeanImpl.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/security/ejb/EntityBeanImpl.java,v
retrieving revision 1.2.2.1
retrieving revision 1.2.2.2
diff -u -r1.2.2.1 -r1.2.2.2
--- EntityBeanImpl.java 2001/07/14 17:10:52 1.2.2.1
+++ EntityBeanImpl.java 2001/07/19 10:20:26 1.2.2.2
@@ -17,7 +17,7 @@
using the echo method.
@author [EMAIL PROTECTED]
-@version $Revision: 1.2.2.1 $
+@version $Revision: 1.2.2.2 $
*/
public class EntityBeanImpl implements EntityBean
{
@@ -73,32 +73,10 @@
if( securityMgr == null )
throw new EJBException(Failed to find security mgr under:
java:comp/env/security/security-domain);
System.out.println(Found SecurityManager: +securityMgr);
- /* I'm using this runtime introspection to determin if the security
-manager supports a getActiveSubject() method because the
-org.jboss.security.SubjectSecurityManager interface is not part of
-the standard client jars which are used to build the jbosstest suite.
-Not legal EJB code, but this is test code.
-*/
- Class securityMgrClass = securityMgr.getClass();
- Class[] parameterTypes = {};
- Method getActiveSubject =
securityMgrClass.getDeclaredMethod(getActiveSubject, parameterTypes);
- Object[] args = {};
- Subject activeSubject = (Subject) getActiveSubject.invoke(securityMgr,
args);
+ Subject activeSubject = (Subject)
ctx.lookup(java:comp/env/security/subject);
System.out.println(ActiveSubject: +activeSubject);
if( activeSubject == null )
throw new EJBException(No ActiveSubject found);
-}
-catch(NoSuchMethodException e)
-{
- // Ok, not a SubjectSecurityManager
-}
-catch(InvocationTargetException e)
-{
- // Ok, not a SubjectSecurityManager
-}
-catch(IllegalAccessException e)
-{
- // Ok, not a SubjectSecurityManager
}
catch(NamingException e)
{
1.1.2.3 +77 -77jbosstest/src/main/org/jboss/test/security/ejb/RunAsMDB.java
Index: RunAsMDB.java
===
RCS file:
/cvsroot/jboss/jbosstest/src/main/org/jboss/test/security/ejb/RunAsMDB.java,v
retrieving revision 1.1.2.2
retrieving revision 1.1.2.3
diff -u -r1.1.2.2 -r1.1.2.3
--- RunAsMDB.java 2001/07/14 17:10:52 1.1.2.2
+++ RunAsMDB.java 2001/07/19 10:20:26 1.1.2.3
@@ -1,77 +1,77 @@
-/*
- * jBoss, the OpenSource EJB server
- *
- * Distributable under LGPL license.
- * See terms of license at gnu.org.
- */
-package org.jboss.test.security.ejb;
-
-import javax.ejb.MessageDrivenBean;
-import javax.ejb.MessageDrivenContext;
-import javax.ejb.EJBException;
-import javax.jms.Destination;
-import javax.jms.MessageListener;
-import javax.jms.Message;
-import javax.naming.InitialContext;
-import javax.naming.NamingException;
-
-import org.jboss.test.security.interfaces.Entity;
-import org.jboss.test.security.interfaces.EntityHome;
-
-/** An MDB that takes the string from the msg passed to onMessage
- and invokes the echo(String) method on an internal Entity using
- the InternalRole assigned in the MDB descriptor run-as element.
-
- @author [EMAIL PROTECTED]
- @version $Revision: 1.1.2.2 $
- */
-public class RunAsMDB implements MessageDrivenBean, MessageListener
-{
- private MessageDrivenContext ctx = null;
- private InitialContext iniCtx;
-
- public RunAsMDB()
- {
- }
-
- public void setMessageDrivenContext(MessageDrivenContext ctx)
- throws EJBException
- {
- this.ctx = ctx;
- try
- {
- iniCtx = new InitialContext();
- }
- catch(NamingException e)
- {
- throw new EJBException(e);
- }
- }
-
- public void ejbCreate()
- {
- }
-
- public void ejbRemove()
- {
- ctx = null;
- }
-
- public void onMessage(Message message)
- {
- try
- {
- String arg = message.getStringProperty(arg);
- EntityHome home = (EntityHome) iniCtx.lookup(java:comp/env/ejb/Entity);
- Entity bean =
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb Container.java
User: starksm
Date: 01/07/19 03:22:55
Modified:src/main/org/jboss/ejb Tag: Branch_2_4 Container.java
Log:
Bind a link from java:comp/env/security/subject to security-domain/subject
Revision ChangesPath
No revision
No revision
1.44.2.2 +2 -1 jboss/src/main/org/jboss/ejb/Container.java
Index: Container.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/ejb/Container.java,v
retrieving revision 1.44.2.1
retrieving revision 1.44.2.2
diff -u -r1.44.2.1 -r1.44.2.2
--- Container.java2001/07/14 21:45:28 1.44.2.1
+++ Container.java2001/07/19 10:22:55 1.44.2.2
@@ -73,7 +73,7 @@
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author a href=[EMAIL PROTECTED]Marc Fleury/a
* @author [EMAIL PROTECTED]
- * @version $Revision: 1.44.2.1 $
+ * @version $Revision: 1.44.2.2 $
*/
public abstract class Container
{
@@ -599,6 +599,7 @@
{
Logger.debug(Binding securityDomain: +securityDomain+ to JDNI ENC
as: security/security-domain);
bind(envCtx, security/security-domain, new LinkRef(securityDomain));
+ bind(envCtx, security/subject, new
LinkRef(securityDomain+/subject));
}
Logger.debug(End java:comp/env for EJB: +beanMetaData.getEjbName());
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/configuration ConfigurationService.java
User: starksm
Date: 01/07/19 03:24:08
Modified:src/main/org/jboss/configuration Tag: Branch_2_4
ConfigurationService.java
Log:
Add an eol character to each line read from the jboss.jcml file to preserve
line oriented content
Revision ChangesPath
No revision
No revision
1.30.2.1 +10 -5 jboss/src/main/org/jboss/configuration/ConfigurationService.java
Index: ConfigurationService.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/configuration/ConfigurationService.java,v
retrieving revision 1.30
retrieving revision 1.30.2.1
diff -u -r1.30 -r1.30.2.1
--- ConfigurationService.java 2001/06/16 05:53:38 1.30
+++ ConfigurationService.java 2001/07/19 10:24:08 1.30.2.1
@@ -46,7 +46,7 @@
* @author Rickard Öberg ([EMAIL PROTECTED])
* @author [EMAIL PROTECTED]
* @author Jason Dillon a
href=mailto:[EMAIL PROTECTED];lt;[EMAIL PROTECTED]gt;/a
- * @version $Revision: 1.30 $
+ * @version $Revision: 1.30.2.1 $
*/
public class ConfigurationService
extends ServiceMBeanSupport
@@ -351,12 +351,17 @@
BufferedReader br = new BufferedReader(new InputStreamReader(input));
String sTmp;
-
-try {
-while((sTmp = br.readLine())!=null){
+String eol = System.getProperty(line.separator);
+try
+{
+while((sTmp = br.readLine())!=null)
+{
sbufData.append(sTmp);
+ sbufData.append(eol);
}
-} finally {
+}
+finally
+{
input.close();
}
//Modification Ends
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/lib jboss-jaas.jar jbosssx.jar
User: starksm Date: 01/07/19 03:25:26 Modified:src/lib Tag: Branch_2_4 jboss-jaas.jar jbosssx.jar Log: Include the JBossSX changes in Rel_2_4_0_22 Revision ChangesPath No revision No revision 1.11.2.3 +108 -108 jboss/src/lib/jboss-jaas.jar Binary file 1.11.2.3 +185 -186 jboss/src/lib/jbosssx.jar Binary file ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jbosssx/src/main/org/jboss/security/plugins JaasSecurityManager.java JaasSecurityManagerService.java
User: starksm
Date: 01/07/19 03:18:57
Modified:src/main/org/jboss/security/plugins Tag: Branch_2_4
JaasSecurityManager.java
JaasSecurityManagerService.java
Log:
Fix problem with security manager override.
Add support for accessing the active subject from the ENC namespace
Revision ChangesPath
No revision
No revision
1.7.2.3 +2 -1
jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManager.java
Index: JaasSecurityManager.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManager.java,v
retrieving revision 1.7.2.2
retrieving revision 1.7.2.3
diff -u -r1.7.2.2 -r1.7.2.3
--- JaasSecurityManager.java 2001/07/14 16:50:56 1.7.2.2
+++ JaasSecurityManager.java 2001/07/19 10:18:57 1.7.2.3
@@ -7,6 +7,7 @@
package org.jboss.security.plugins;
import java.io.IOException;
+import java.io.Serializable;
import java.util.Arrays;
import java.util.Enumeration;
import java.util.Iterator;
@@ -51,7 +52,7 @@
@author a href=[EMAIL PROTECTED]Oleg Nitz/a
@author [EMAIL PROTECTED]
-@version $Revision: 1.7.2.2 $
+@version $Revision: 1.7.2.3 $
*/
public class JaasSecurityManager implements SubjectSecurityManager, RealmMapping
{
1.2.2.1 +237 -200
jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManagerService.java
Index: JaasSecurityManagerService.java
===
RCS file:
/cvsroot/jboss/jbosssx/src/main/org/jboss/security/plugins/JaasSecurityManagerService.java,v
retrieving revision 1.2
retrieving revision 1.2.2.1
diff -u -r1.2 -r1.2.2.1
--- JaasSecurityManagerService.java 2001/06/15 08:26:02 1.2
+++ JaasSecurityManagerService.java 2001/07/19 10:18:57 1.2.2.1
@@ -4,12 +4,14 @@
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
-
+
package org.jboss.security.plugins;
import java.lang.reflect.Constructor;
+import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
-import java.net.URL;
+import java.lang.reflect.Proxy;
+import java.util.Enumeration;
import java.util.Hashtable;
import java.util.ArrayList;
import java.util.Iterator;
@@ -20,11 +22,16 @@
import javax.naming.RefAddr;
import javax.naming.StringRefAddr;
import javax.naming.Name;
+import javax.naming.NameClassPair;
+import javax.naming.NameParser;
+import javax.naming.NamingEnumeration;
import javax.naming.NamingException;
+import javax.naming.OperationNotSupportedException;
import javax.naming.spi.ObjectFactory;
import javax.naming.spi.NamingManager;
import javax.naming.CommunicationException;
import javax.naming.CannotProceedException;
+import javax.security.auth.Subject;
import javax.management.MBeanServer;
import javax.management.ObjectName;
@@ -32,19 +39,18 @@
import org.jboss.logging.Log;
import org.jboss.security.SecurityAssociation;
import org.jboss.security.SecurityProxyFactory;
+import org.jboss.security.SubjectSecurityManager;
import org.jboss.util.ServiceMBeanSupport;
-import org.jnp.server.NamingServer;
-import org.jnp.interfaces.NamingContext;
import org.jboss.util.CachePolicy;
/**
* This is a JMX service which manages JAAS based SecurityManagers.
*JAAS SecurityManagers are responsible for validating credentials
- *associated with principals. The service defaults to the
+ *associated with principals. The service defaults to the
*org.jboss.security.plugins.JaasSecurityManager implementation but
*this can be changed via the securityManagerClass property.
- *
+ *
* @see JaasSecurityManager
* @see SubjectSecurityManager
* @author a href=[EMAIL PROTECTED]Oleg Nitz/a
@@ -52,213 +58,244 @@
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
*/
public class JaasSecurityManagerService
-extends ServiceMBeanSupport
-implements JaasSecurityManagerServiceMBean
+extends ServiceMBeanSupport
+implements JaasSecurityManagerServiceMBean
{
-/** The class that provides the security manager implementation */
-private static String securityMgrClassName;
-/** The loaded securityMgrClassName */
-private static Class securityMgrClass;
-/** The security credential cache policy, shared by all security mgrs */
-private static CachePolicy cachePolicy;
-private static String cacheJndiName;
-/** The class that provides the SecurityProxyFactory implementation */
-private static String securityProxyFactoryClassName;
-private static Class securityProxyFactoryClass;
-
-static NamingServer srv;
-static Hashtable jsmMap
RE: [JBoss-dev] WARNING: No rollback on transaction timeout with mainline(2.5)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of marc fleury Sent: Thursday, July 19, 2001 6:21 AM To: [EMAIL PROTECTED]; Jboss-User@Lists. Sourceforge. Net Subject: RE: [JBoss-dev] WARNING: No rollback on transaction timeout with mainline(2.5) hmmm a transaction timeout is an operation limited to the Tx manager, meaning that there is no callback afaik. If a tx times out, the thread associated with it should still come back through the interceptor and carry a timed-out transaction. What I am saying is that a thread that doesn't return is a problem in and on itself that the transaction associated with it times out is not going to change that. Yeah, but the classic deadlock scenario is not JBoss's fault, but the fault of the Bean Developer. This is one of the reasons why the LOCKING-WAITING message is so useful. If a transaction times out you can search the logs for LOCKING-WAITING to find out if it was a deadlock scenario introduced by your bad coding.(Hey, it's helped out debugging my aweful app code many a time :) Just to make sure we're on the same page here, I tested classic application deadlock with wait() and the 2 transactions never timed out. This is because the Tx manager does nothing but mark the transaction as ROLLBACK. So with wait() + classic deadlock, threads will wait forever and never know that they have been rolled back. I put in a wait(timeout) instead, and the transactions did timeout. Maybe this is what you were saying and you already agree, but, I couldn't tell. The other threads waiting will be notified through normal mechanisms when the thread taking all this big time will return. If the thread doesn't return (as from JBossMQ for example) then that is a bug. Just to make sure again, it could be an application bug and not a JBoss bug if you're using wait() with no timeout. You see I am very happy we can see that JBossMQ hangs, right there, because of the wait(). I totally understand the usefulness of having wait() in there for testing out the new cache/locking mechanisms. I just wanted to make sure that the JBoss community knew possible problems with using it. Bill The wait(5000), as we all agree, is the way to go for the final system. But a time-out with a returning thread will notifyAll. marcf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bill Burke Sent: Monday, July 16, 2001 8:12 PM To: Jboss-Development@Lists. Sourceforge. Net; Jboss-User@Lists. Sourceforge. Net Subject: [JBoss-dev] WARNING: No rollback on transaction timeout with mainline(2.5) FYI, For debugging purposes in JBoss 2.5(mainline), threads waiting on EntityBeans will not be rollbacked on transaction timeouts and will wait forever. Currently the codebase does a wait forever, wait(), on transaction and method lock objects. This was done on purpose to easily catch problems with the new locking code put into 2.5. To fix this problem edit org.jboss.ejb.plugins.EntityInstanceInterceptor and comment out any line that does a wait(), and uncomment out lines that do wait(timeout). Regards, Bill ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development . ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Bugs-442804 ] dtd reference
Bugs item #442804, was opened at 2001-07-19 09:44 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=442804group_id=22866 Category: None Group: v2.2 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: dtd reference Initial Comment: The following address http://www.jboss.org/j2ee/dtd/jboss.dtd; is not valid, but it is referenced in the following DTD file http://www.jboss.org/doco_files/jboss.dtd: !DOCTYPE jboss PUBLIC -//JBoss//DTD JBOSS//EN http://www.jboss.org/j2ee/dtd/jboss.dtd; -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=376685aid=442804group_id=22866 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new wait(1000) not good
Bill and Georg, I wrote a lock manager several years ago, so my comments may be out dated. I remember that, if I wanted to wake the waiting threads in a specific order (LIFO FIFO), we would have each thread wait on a different object so it could be awoken individually. Before the thread waits on the object it puts the object in a collection. When the thread with the lock releases the lock, it selects the next thread from the collection, removes the object, and calls notify. It is a pretty simple trick in the code. By the way, has anyone considered using an external lock manager instead of coding one directly into the interceptor. When I wrote my lock manager there were no freely available managers, but I think there are several now. Dain -Original Message- From: Bill Burke [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 18, 2001 11:31 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] new wait(1000) not good Thanks Georg for clearing that up. Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Georg Rehfeld Sent: Thursday, July 19, 2001 12:06 AM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] new wait(1000) not good Hi Bill, I'm also worried about this same scenario with the new locking stuff in the mainline. With notifyAll instead of just notify is there a chance to starve threads? With notify aren't you guarateed FIFO for lock contention, but you wouldn't be guaranteed with a notifyAll? notify does NOT guarantee FIFO awakening of threads: the docs explicitely state: | The choice is arbitrary and occurs at the discretion of the | implementation. i.e. a LIFO or whatever implementation might lead to starvation. notifyAll seems to be MUCH better as of the docs: | The awakened threads will compete in the usual manner with | any other threads that might be actively competing to | synchronize on this object; for example, the awakened threads | enjoy no reliable privilege or disadvantage in being the next | thread to lock this object. So every thread, if it was waiting before or just coming in fresh, has the same chance to get the lock and proceed, avoiding starvation. Bye Georg ___ ___ | + | |__Georg Rehfeld Woltmanstr. 12 20097 Hamburg |_|_\ |___ [EMAIL PROTECTED] +49 (40) 23 53 27 10 ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/configuration ConfigurationService.java
User: starksm
Date: 01/07/19 10:09:54
Modified:src/main/org/jboss/configuration ConfigurationService.java
Log:
Add eol to each line read from jboss.jcml
Revision ChangesPath
1.35 +3 -2 jboss/src/main/org/jboss/configuration/ConfigurationService.java
Index: ConfigurationService.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/configuration/ConfigurationService.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- ConfigurationService.java 2001/07/06 03:17:09 1.34
+++ ConfigurationService.java 2001/07/19 17:09:54 1.35
@@ -67,7 +67,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a.
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a.
* @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
- * @version $Revision: 1.34 $
+ * @version $Revision: 1.35 $
* Revisions:
*
* 20010622 scott.stark: Clean up the unsafe downcast of Throwable to Exception
@@ -404,12 +404,13 @@
BufferedReader br = new BufferedReader(new InputStreamReader(input));
String sTmp;
-
+ String eol = System.getProperty(line.seperator);
try
{
while((sTmp = br.readLine())!=null)
{
sbufData.append(sTmp);
+sbufData.append(eol);
}
}
finally
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss.jcml reading properties problem/bug.
Yes.
- Original Message -
From: Jay Walters [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, July 19, 2001 5:30 AM
Subject: RE: [JBoss-dev] jboss.jcml reading properties problem/bug.
Did you make this change to the mainline as well?
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 18, 2001 7:17 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jboss.jcml reading properties problem/bug.
Throwing away the new lines is not correct. The jboss.jcml file is an xml
file and it
does not have line oriented semantics. The change you propose to add in the
missing new line makes sense. I'll add it to the next beta release which
will come out tomorrow.
- Original Message -
From: John Landers [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 18, 2001 3:26 PM
Subject: [JBoss-dev] jboss.jcml reading properties problem/bug.
I was working with jboss2.4 beta and now the code
that reads this file strips out the cr/lf since it is using
BufferedReader.readLine(). This works fine for most xml
but for MBeans that use and attribute that contains multiple properties
like this:
mbean code=org.jboss.resource.ConnectionFactoryLoader
name=JCA:service=ConnectionFactoryLoader,name=JmsXA
attribute name=ConnectionManagerProperties
MinSize=0
MaxSize=10
Blocking=true
GCEnabled=false
/attribute
It becomes a string with a single line of all the properties and the
java.util.Properties::load only gets
a single property.
The problem is in
org/jboss/configuration/ConfigurationService::loadConfiguration
public void loadConfiguration() throws Exception {
// The class loader used to kocal the configuration file
ClassLoader loader =
Thread.currentThread().getContextClassLoader();
// Load user config from XML, and create the MBeans
InputStream input =
loader.getResourceAsStream(CONFIGURATION_FILE);
StringBuffer sbufData = new StringBuffer();
BufferedReader br = new BufferedReader(new
InputStreamReader(input));
String sTmp;
try {
while((sTmp = br.readLine())!=null){
sbufData.append(sTmp);
// need to append in the eol
sbufData.append(System.getProperty(line.separator));
}
} finally {
input.close();
}
Does this sound correct or are properties used in this fashion not
supported
anymore?
Maybe it is already fixed.
jcl.
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] new wait(1000) not good
Georg == Georg Rehfeld [EMAIL PROTECTED] writes: Georg notifyAll seems to be MUCH better as of the docs: Georg | The awakened threads will compete in the usual manner with | Georg any other threads that might be actively competing to | Georg synchronize on this object; for example, the awakened threads Georg | enjoy no reliable privilege or disadvantage in being the Georg next | thread to lock this object. Georg So every thread, if it was waiting before or just coming in Georg fresh, has the same chance to get the lock and proceed, Georg avoiding starvation. this is not implied by the snippet you posted. all it says is that the threads in the wait set will compete in the usual manner, which is no more fully specified than the case with notify(). no scheduling method is implied in either notify() or notifyAll(), so you can make no guarantees of fairness. also, notifyAll() can lead to the so-called 'thundreing herd' of threads waking, competing for the lock, and (all but one) going back to sleep again. that said, any quality JVM will implement some sort of quasi-fair scheduling policy, so it's not likely to lead to starvation. but if you really want fairness, you cannot rely on the builtins. there is a excellent discussion of this, and some examples on writing a FIFO scheduler, in Doug Lea's 'Concurrent Programming in Java, 2nd Ed', which I recommend highly. -- joe ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: manual/src/docs jbossintro.xml
User: gropi Date: 01/07/19 12:58:06 Modified:src/docs jbossintro.xml Log: Included advice from Chiew Kwooi Lee for NoClassDefFoundError. Revision ChangesPath 1.19 +3 -1 manual/src/docs/jbossintro.xml Index: jbossintro.xml === RCS file: /cvsroot/jboss/manual/src/docs/jbossintro.xml,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- jbossintro.xml2001/06/25 21:39:01 1.18 +++ jbossintro.xml2001/07/19 19:58:06 1.19 @@ -537,7 +537,9 @@ Total time: 2 seconds/computeroutput /literallayout - paraThis has compiled the EJB classes and created the ejb-jar for deployment. The contents of the + paraThis has compiled the EJB classes and created the ejb-jar for deployment. +If got a java.lang.NoClassDefFoundError here instead of a successful created jar file try clearing your classpath. +The contents of the interest.jar include the structure we discussed previously as shown by running the jar -tvf command:/para literallayout ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss.jcml reading properties problem/bug.
Hi Geeks
I just took the latest code from CVS and when I start JBoss it tells
me that the Document Root element is missing:
java.io.IOException: Document root element is missing
which comes from
org.jboss.configuration.ConfigurationService.loadConfiguration
line 433.
Andy
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 19, 2001 10:16 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jboss.jcml reading properties problem/bug.
Yes.
- Original Message -
From: Jay Walters [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, July 19, 2001 5:30 AM
Subject: RE: [JBoss-dev] jboss.jcml reading properties problem/bug.
Did you make this change to the mainline as well?
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 18, 2001 7:17 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jboss.jcml reading properties problem/bug.
Throwing away the new lines is not correct. The jboss.jcml
file is an xml
file and it
does not have line oriented semantics. The change you
propose to add in the
missing new line makes sense. I'll add it to the next beta
release which
will come out tomorrow.
- Original Message -
From: John Landers [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 18, 2001 3:26 PM
Subject: [JBoss-dev] jboss.jcml reading properties problem/bug.
I was working with jboss2.4 beta and now the code
that reads this file strips out the cr/lf since it is using
BufferedReader.readLine(). This works fine for most xml
but for MBeans that use and attribute that contains
multiple properties
like this:
mbean code=org.jboss.resource.ConnectionFactoryLoader
name=JCA:service=ConnectionFactoryLoader,name=JmsXA
attribute name=ConnectionManagerProperties
MinSize=0
MaxSize=10
Blocking=true
GCEnabled=false
/attribute
It becomes a string with a single line of all the
properties and the
java.util.Properties::load only gets
a single property.
The problem is in
org/jboss/configuration/ConfigurationService::loadConfiguration
public void loadConfiguration() throws Exception {
// The class loader used to kocal the configuration file
ClassLoader loader =
Thread.currentThread().getContextClassLoader();
// Load user config from XML, and create the MBeans
InputStream input =
loader.getResourceAsStream(CONFIGURATION_FILE);
StringBuffer sbufData = new StringBuffer();
BufferedReader br = new BufferedReader(new
InputStreamReader(input));
String sTmp;
try {
while((sTmp = br.readLine())!=null){
sbufData.append(sTmp);
// need to append in the eol
sbufData.append(System.getProperty(line.separator));
}
} finally {
input.close();
}
Does this sound correct or are properties used in this fashion not
supported
anymore?
Maybe it is already fixed.
jcl.
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jnp/src/main/org/jnp/test TestJNPSockets.java
User: starksm
Date: 01/07/19 13:09:40
Modified:src/main/org/jnp/test Tag: Branch_2_4 TestJNPSockets.java
Log:
Add support for binding the jnp port on a specific address
Revision ChangesPath
No revision
No revision
1.1.2.1 +1 -0 jnp/src/main/org/jnp/test/TestJNPSockets.java
Index: TestJNPSockets.java
===
RCS file: /cvsroot/jboss/jnp/src/main/org/jnp/test/TestJNPSockets.java,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- TestJNPSockets.java 2001/05/30 01:59:10 1.1
+++ TestJNPSockets.java 2001/07/19 20:09:40 1.1.2.1
@@ -17,7 +17,7 @@
/** A test of RMI custom sockets with the jnp JNDI provider.
@author [EMAIL PROTECTED]
-@version $Revision: 1.1 $
+@version $Revision: 1.1.2.1 $
*/
public class TestJNPSockets extends TestCase
{
@@ -36,6 +36,7 @@
server = new Main();
server.setPort(0);
+server.setBindAddress(localhost);
server.setClientSocketFactory(ClientSocketFactory.class.getName());
server.setServerSocketFactory(ServerSocketFactory.class.getName());
server.start();
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jnp/src/main/org/jnp/server Main.java MainMBean.java
User: starksm
Date: 01/07/19 13:09:40
Modified:src/main/org/jnp/server Tag: Branch_2_4 Main.java
MainMBean.java
Log:
Add support for binding the jnp port on a specific address
Revision ChangesPath
No revision
No revision
1.7.2.1 +255 -208 jnp/src/main/org/jnp/server/Main.java
Index: Main.java
===
RCS file: /cvsroot/jboss/jnp/src/main/org/jnp/server/Main.java,v
retrieving revision 1.7
retrieving revision 1.7.2.1
diff -u -r1.7 -r1.7.2.1
--- Main.java 2001/06/22 19:08:25 1.7
+++ Main.java 2001/07/19 20:09:40 1.7.2.1
@@ -8,10 +8,13 @@
package org.jnp.server;
import java.io.FileNotFoundException;
+import java.io.InputStream;
import java.io.IOException;
import java.io.ObjectOutputStream;
+import java.net.InetAddress;
import java.net.Socket;
import java.net.ServerSocket;
+import java.net.UnknownHostException;
import java.net.URL;
import java.rmi.Remote;
import java.rmi.RemoteException;
@@ -31,219 +34,263 @@
import org.jnp.interfaces.java.javaURLContextFactory;
/** A main() entry point for running the jnp naming service implementation as
-a standalone process.
-
-@author oberg
-@author [EMAIL PROTECTED]
-@version $Revision: 1.7 $
-*/
-public class Main
- implements Runnable, MainMBean
+ a standalone process.
+
+ @author oberg
+ @author [EMAIL PROTECTED]
+ @version $Revision: 1.7.2.1 $
+ */
+public class Main implements Runnable, MainMBean
{
-// Constants -
-
-// Attributes
-/** The Naming interface server implementation */
-protected NamingServer theServer;
-protected MarshalledObject serverStub;
-/** The jnp server socket through which the NamingServer stub is vended */
-protected ServerSocket serverSocket;
-/** An optional custom client socket factory */
-protected RMIClientSocketFactory clientSocketFactory;
-/** An optional custom server socket factory */
-protected RMIServerSocketFactory serverSocketFactory;
-/** The class name of the optional custom client socket factory */
-protected String clientSocketFactoryName;
-/** The class name of the optional custom server socket factory */
-protected String serverSocketFactoryName;
-/** The jnp protocol listening port. The default is 1099, the same as
-the RMI registry default port. */
-protected int port = 1099;
-/** The RMI port on which the Naming implementation will be exported. The
-default is 0 which means use any available port. */
-protected int rmiPort = 0;
-protected Category log;
+ // Constants -
+
+ // Attributes
+ /** The Naming interface server implementation */
+ protected NamingServer theServer;
+ protected MarshalledObject serverStub;
+ /** The jnp server socket through which the NamingServer stub is vended */
+ protected ServerSocket serverSocket;
+ /** An optional custom client socket factory */
+ protected RMIClientSocketFactory clientSocketFactory;
+ /** An optional custom server socket factory */
+ protected RMIServerSocketFactory serverSocketFactory;
+ /** The class name of the optional custom client socket factory */
+ protected String clientSocketFactoryName;
+ /** The class name of the optional custom server socket factory */
+ protected String serverSocketFactoryName;
+ /** The interface to bind to. This is useful for multi-homed hosts
+that want control over which interfaces accept connections.
+*/
+ protected InetAddress bindAddress;
+ /** The serverSocket listen queue depth */
+ protected int backlog = 50;
+ /** The jnp protocol listening port. The default is 1099, the same as
+the RMI registry default port. */
+ protected int port = 1099;
+ /** The RMI port on which the Naming implementation will be exported. The
+default is 0 which means use any available port. */
+ protected int rmiPort = 0;
+ protected Category log;
-// Static
-public static void main(String[] args)
+ // Static
+ public static void main(String[] args)
throws Exception
-{
-// Make sure the config file can be found
-ClassLoader loader = Thread.currentThread().getContextClassLoader();
-URL url = loader.getResource(log4j.properties);
-if( url == null )
-System.err.println(Failed to find log4j.properties);
-
[JBoss-dev] CVS update: jnp/src/main/org/jnp/client Main.java
User: starksm Date: 01/07/19 13:09:40 Modified:src/main/org/jnp/client Tag: Branch_2_4 Main.java Log: Add support for binding the jnp port on a specific address Revision ChangesPath No revision No revision 1.6.2.1 +2 -1 jnp/src/main/org/jnp/client/Main.java Index: Main.java === RCS file: /cvsroot/jboss/jnp/src/main/org/jnp/client/Main.java,v retrieving revision 1.6 retrieving revision 1.6.2.1 diff -u -r1.6 -r1.6.2.1 --- Main.java 2001/05/30 01:59:09 1.6 +++ Main.java 2001/07/19 20:09:40 1.6.2.1 @@ -35,7 +35,7 @@ * @see NamingContext * @author oberg * @author [EMAIL PROTECTED] - * @version $Revision: 1.6 $ + * @version $Revision: 1.6.2.1 $ */ public class Main implements Runnable @@ -55,6 +55,7 @@ System.setProperty(java.naming.factory.url.pkgs, org.jnp.interfaces); System.setProperty(java.naming.provider.url, localhost); System.setErr(System.out); + org.apache.log4j.BasicConfigurator.configure(); new Main().run(); } ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp/server DefaultSocketFactory.java JRMPContainerInvoker.java
User: starksm
Date: 01/07/19 13:13:07
Modified:src/main/org/jboss/ejb/plugins/jrmp/server Tag: Branch_2_4
JRMPContainerInvoker.java
Added: src/main/org/jboss/ejb/plugins/jrmp/server Tag: Branch_2_4
DefaultSocketFactory.java
Log:
Add support for binding the JRMP/RMI objects on a specific address
Integrate the jnp changes to support binding the name service on a specific address
Revision ChangesPath
No revision
No revision
1.37.4.1 +62 -18
jboss/src/main/org/jboss/ejb/plugins/jrmp/server/JRMPContainerInvoker.java
Index: JRMPContainerInvoker.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/ejb/plugins/jrmp/server/JRMPContainerInvoker.java,v
retrieving revision 1.37
retrieving revision 1.37.4.1
diff -u -r1.37 -r1.37.4.1
--- JRMPContainerInvoker.java 2001/05/02 03:04:15 1.37
+++ JRMPContainerInvoker.java 2001/07/19 20:13:07 1.37.4.1
@@ -12,6 +12,7 @@
import java.io.IOException;
import java.lang.reflect.Method;
import java.lang.reflect.Constructor;
+import java.net.UnknownHostException;
import java.rmi.ServerException;
import java.rmi.RemoteException;
import java.rmi.MarshalledObject;
@@ -69,14 +70,13 @@
import org.w3c.dom.Element;
/**
- * description
*
- * @see related
- * @author Rickard Öberg ([EMAIL PROTECTED])
- * @author a href=mailto:[EMAIL PROTECTED];Sebastien
Alborini/a
- * @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
- * @author a href=mailto:[EMAIL PROTECTED];Juha Lindfors/a
- * @version $Revision: 1.37 $
+ * @author Rickard Öberg ([EMAIL PROTECTED])
+ * @author a href=mailto:[EMAIL PROTECTED];Sebastien Alborini/a
+ * @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
+ * @author a href=mailto:[EMAIL PROTECTED];Juha Lindfors/a
+ * @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a
+ * @version $Revision: 1.37.4.1 $
*/
public class JRMPContainerInvoker
extends RemoteServer
@@ -97,6 +97,8 @@
protected String clientSocketFactoryName;
/** The class name of the optional custom server socket factory */
protected String serverSocketFactoryName;
+ /** The address to bind the rmi port on */
+ protected String serverAddress;
protected boolean jdk122 = false;
protected Container container;
protected String jndiName;
@@ -176,7 +178,8 @@
// Hash it
homeMethodInvokerMap.put(new
Long(RemoteMethodInvocation.calculateHash(getEJBObjectMethod)),getEJBObjectMethod);
- } catch (Exception e)
+ }
+ catch (Exception e)
{
Logger.exception(e);
}
@@ -254,7 +257,7 @@
}
public void start()
- throws Exception
+ throws Exception
{
try
{
@@ -354,7 +357,7 @@
* Invoke a Home interface method.
*/
public MarshalledObject invokeHome(MarshalledObject mimo)
- throws Exception
+ throws Exception
{
ClassLoader oldCl = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(container.getClassLoader());
@@ -376,7 +379,7 @@
* Invoke a Remote interface method.
*/
public MarshalledObject invoke(MarshalledObject mimo)
- throws Exception
+ throws Exception
{
ClassLoader oldCl = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(container.getClassLoader());
@@ -401,7 +404,7 @@
*/
public Object invokeHome(Method m, Object[] args, Transaction tx,
Principal identity, Object credential)
- throws Exception
+ throws Exception
{
// Check if this call really can be optimized
if
(!m.getDeclaringClass().isAssignableFrom(((ContainerInvokerContainer)container).getHomeClass()))
@@ -445,7 +448,7 @@
*/
public Object invoke(Object id, Method m, Object[] args, Transaction tx,
Principal identity, Object credential )
- throws Exception
+ throws Exception
{
// Check if this call really can be optimized
// If parent of callers classloader is != parent of our classloader - not
optimizable!
@@ -478,7 +481,8 @@
try
{
return container.invoke(new MethodInvocation(id, m, args, tx, identity,
credential));
- } finally
+ }
+ finally
{
Thread.currentThread().setContextClassLoader(oldCl);
}
@@ -518,10 +522,12 @@
String port = MetaData.getElementContent(portElement);
rmiPort = Integer.parseInt(port);
}
-} catch(NumberFormatException e)
+}
+
[JBoss-dev] CVS update: jboss/src/main/org/jboss/naming NamingService.java
User: starksm
Date: 01/07/19 13:13:07
Modified:src/main/org/jboss/naming Tag: Branch_2_4 NamingService.java
Log:
Add support for binding the JRMP/RMI objects on a specific address
Integrate the jnp changes to support binding the name service on a specific address
Revision ChangesPath
No revision
No revision
1.11.4.2 +20 -1 jboss/src/main/org/jboss/naming/NamingService.java
Index: NamingService.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/naming/NamingService.java,v
retrieving revision 1.11.4.1
retrieving revision 1.11.4.2
diff -u -r1.11.4.1 -r1.11.4.2
--- NamingService.java2001/06/22 19:41:09 1.11.4.1
+++ NamingService.java2001/07/19 20:13:07 1.11.4.2
@@ -7,6 +7,7 @@
package org.jboss.naming;
import java.io.InputStream;
+import java.net.UnknownHostException;
import java.util.Hashtable;
import java.util.Enumeration;
import java.util.Properties;
@@ -28,7 +29,7 @@
*
* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a.
- * @version $Revision: 1.11.4.1 $
+ * @version $Revision: 1.11.4.2 $
*
* Revisions:
* 20010622 scott.stark: Report IntialContext env for problem tracing
@@ -70,6 +71,24 @@
public int getRmiPort()
{
return naming.getRmiPort();
+ }
+
+ public String getBindAddress()
+ {
+ return naming.getBindAddress();
+ }
+ public void setBindAddress(String host) throws UnknownHostException
+ {
+ naming.setBindAddress(host);
+ }
+
+ public int getBacklog()
+ {
+ return naming.getBacklog();
+ }
+ public void setBacklog(int backlog)
+ {
+ naming.setBacklog(backlog);
}
public String getClientSocketFactory()
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss.jcml reading properties problem/bug.
Fixed. - Original Message - From: Schaefer, Andreas [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 19, 2001 1:01 PM Subject: RE: [JBoss-dev] jboss.jcml reading properties problem/bug. Hi Geeks I just took the latest code from CVS and when I start JBoss it tells me that the Document Root element is missing: java.io.IOException: Document root element is missing which comes from org.jboss.configuration.ConfigurationService.loadConfiguration line 433. Andy ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Coding Style
Hi Geeks
Due the latest bunch of email I was getting a little
bit confused how the actual Coding Style or Guidelines
are. Do we have a document/page about this (or shouldn't
we have one)?
Have fun - Mad Andy / Better Pizza
[EMAIL PROTECTED]
[EMAIL PROTECTED]
while( true ) { think(); write(); publish(); }
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/configuration ConfigurationService.java
User: starksm
Date: 01/07/19 13:17:18
Modified:src/main/org/jboss/configuration ConfigurationService.java
Log:
Fix typo in eol property name
Revision ChangesPath
1.36 +2 -2 jboss/src/main/org/jboss/configuration/ConfigurationService.java
Index: ConfigurationService.java
===
RCS file:
/cvsroot/jboss/jboss/src/main/org/jboss/configuration/ConfigurationService.java,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- ConfigurationService.java 2001/07/19 17:09:54 1.35
+++ ConfigurationService.java 2001/07/19 20:17:18 1.36
@@ -67,7 +67,7 @@
* @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a.
* @author a href=mailto:[EMAIL PROTECTED];Scott Stark/a.
* @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
- * @version $Revision: 1.35 $
+ * @version $Revision: 1.36 $
* Revisions:
*
* 20010622 scott.stark: Clean up the unsafe downcast of Throwable to Exception
@@ -404,7 +404,7 @@
BufferedReader br = new BufferedReader(new InputStreamReader(input));
String sTmp;
- String eol = System.getProperty(line.seperator);
+ String eol = System.getProperty(line.separator);
try
{
while((sTmp = br.readLine())!=null)
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss.jcml reading properties problem/bug.
Sorry
Ignore it because it is fixed with the latest CVS updates from
Scott.
Andy
-Original Message-
From: Schaefer, Andreas [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 19, 2001 1:02 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-dev] jboss.jcml reading properties problem/bug.
Hi Geeks
I just took the latest code from CVS and when I start JBoss it tells
me that the Document Root element is missing:
java.io.IOException: Document root element is missing
which comes from
org.jboss.configuration.ConfigurationService.loadConfiguration
line 433.
Andy
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 19, 2001 10:16 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jboss.jcml reading properties problem/bug.
Yes.
- Original Message -
From: Jay Walters [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, July 19, 2001 5:30 AM
Subject: RE: [JBoss-dev] jboss.jcml reading properties problem/bug.
Did you make this change to the mainline as well?
-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 18, 2001 7:17 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jboss.jcml reading properties
problem/bug.
Throwing away the new lines is not correct. The jboss.jcml
file is an xml
file and it
does not have line oriented semantics. The change you
propose to add in the
missing new line makes sense. I'll add it to the next beta
release which
will come out tomorrow.
- Original Message -
From: John Landers [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, July 18, 2001 3:26 PM
Subject: [JBoss-dev] jboss.jcml reading properties problem/bug.
I was working with jboss2.4 beta and now the code
that reads this file strips out the cr/lf since it is using
BufferedReader.readLine(). This works fine for most xml
but for MBeans that use and attribute that contains
multiple properties
like this:
mbean code=org.jboss.resource.ConnectionFactoryLoader
name=JCA:service=ConnectionFactoryLoader,name=JmsXA
attribute name=ConnectionManagerProperties
MinSize=0
MaxSize=10
Blocking=true
GCEnabled=false
/attribute
It becomes a string with a single line of all the
properties and the
java.util.Properties::load only gets
a single property.
The problem is in
org/jboss/configuration/ConfigurationService::loadConfiguration
public void loadConfiguration() throws Exception {
// The class loader used to kocal the configuration file
ClassLoader loader =
Thread.currentThread().getContextClassLoader();
// Load user config from XML, and create the MBeans
InputStream input =
loader.getResourceAsStream(CONFIGURATION_FILE);
StringBuffer sbufData = new StringBuffer();
BufferedReader br = new BufferedReader(new
InputStreamReader(input));
String sTmp;
try {
while((sTmp = br.readLine())!=null){
sbufData.append(sTmp);
// need to append in the eol
sbufData.append(System.getProperty(line.separator));
}
} finally {
input.close();
}
Does this sound correct or are properties used in this
fashion not
supported
anymore?
Maybe it is already fixed.
jcl.
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Coding Style
Thanx But now I am a little bit more confused. Just to fix this maybe once and for all: the classes uses 2 spaces as identation but one of the latest mails Marc said use 3 spaces !! I favor 3 but I can live with any number but we should only use one. Andy -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 19, 2001 1:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Coding Style Its documented in the src/etc/class.java and src/etc/interface.java files of the jboss cvs module. Feel free to turn it into a page for the web site. - Original Message - From: Schaefer, Andreas [EMAIL PROTECTED] To: jBoss-Dev (E-mail) [EMAIL PROTECTED] Sent: Thursday, July 19, 2001 1:20 PM Subject: [JBoss-dev] Coding Style Hi Geeks Due the latest bunch of email I was getting a little bit confused how the actual Coding Style or Guidelines are. Do we have a document/page about this (or shouldn't we have one)? Have fun - Mad Andy / Better Pizza ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] new wait(1000) not good
Yeah, sure, having multiple instances makes things easier, they can only be
applied to commit option B and C. For option A, you're going to need to
share instances and thus you'll need some locking mechanism. I totaly agree
though, for B and C, let the datastore manage locks and serialization.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of James
Cook
Sent: Thursday, July 19, 2001 4:30 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] new wait(1000) not good
All of this entity contention is an optional thing we will have to
explicitly turn on, correct?
I prefer to have the container create multiple instances of identical
entities (same home, same pk) and handle the concurrency in the database.
jim
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Scott
M Stark
Sent: Tuesday, July 17, 2001 10:45 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] new wait(1000) not good
Because Thread.yield() does not prevent busy waiting. Using a
wait(N) there
can be no deadlock as this will timeout in N milliseconds. I am
actually just
going to do a Thread.sleep(1) as this results in no cpu
utilization and 1 ms
is a small performance penatly for the contending caller.
To see the problem with using Thread.yield(), try this simple program:
tmp 1046cat tstYield.java
class tstYield implements Runnable
{
static long start;
static void yield()
{
Thread.yield();
}
static void sleep()
{
try
{
Thread.sleep(1);
}
catch(InterruptedException e)
{
}
}
public void run()
{
System.out.println(Start +this);
long elapsed = System.currentTimeMillis() - start;
while( elapsed 1 )
{
yield();
elapsed = System.currentTimeMillis() - start;
}
System.out.println(End +this);
}
public static void main(String[] args)
{
start = System.currentTimeMillis();
for(int t = 0; t 2; t ++)
new Thread(new tstYield(), T+t).start();
}
}
When the threads attempt to pause using yield() rather than
sleep(), there is
100% cpu utilization of the 10 sec period this program runs.
When the use
sleep() there is no cpu utilization of the 10 sec period.
- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, July 17, 2001 4:25 PM
Subject: RE: [JBoss-dev] new wait(1000) not good
Why not just a Thread.yield after mutex.release? With
sleeping, don't you
run the risk of starving out threads if the same EntityBean
keeps on being
accessed continually?
I'm also worried about this same scenario with the new locking
stuff in the
mainline. With notifyAll instead of just notify is there a
chance to starve
threads? With notify aren't you guarateed FIFO for lock
contention, but you
wouldn't be guaranteed with a notifyAll?
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On
Behalf Of Scott
M Stark
Sent: Tuesday, July 17, 2001 6:22 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] new wait(1000) not good
Ok, I missed that mutex acquire at the start. I care less about
slowing down the
performance in the case of contending access than I do about burning
100% cpu waiting for contention to resolve. Even a 10ms wait
should remove
the spinning cpu so I'll stress test the issue by back porting
the latest lock
test from jbosstest to find a happy medium between
performance throughput
and wasted cpu. I'll also just sleep the current thread after the
release of the
mutex.
- Original Message -
From: Bill Burke [EMAIL PROTECTED]
To: Jboss-Development@Lists. Sourceforge. Net
[EMAIL PROTECTED]
Sent: Monday, July 16, 2001 10:02 PM
Subject: [JBoss-dev] new wait(1000) not good
Scott,
Your 2.2 wait(1000)change will seriously slow down applications
that contend
for the same Entity. In fact, it may even deadlock if
requests for that
Entity keep on coming in.
The do..while loop does a mutex.acquire at the beginning. It
will not do a
mutex.release until after the 1 second is up. If the
transaction that
currently holds the Entity invokes on the Entity more than one
time, it will
be waiting for any thread currently hold the mutex to finish.
Also, the mutex is acquired again in the finally clause of
EntityInstanceInterceptor to synchronize on ctx.unlock and such.
Bill
___
Jboss-development mailing list
[EMAIL PROTECTED]
Re: [JBoss-dev] Coding Style
The classes say to use 3 even though they use 2. Originally 2 spaces was suggested and this was changed to 3. - Original Message - From: Schaefer, Andreas [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 19, 2001 1:54 PM Subject: RE: [JBoss-dev] Coding Style Thanx But now I am a little bit more confused. Just to fix this maybe once and for all: the classes uses 2 spaces as identation but one of the latest mails Marc said use 3 spaces !! I favor 3 but I can live with any number but we should only use one. Andy -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 19, 2001 1:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Coding Style Its documented in the src/etc/class.java and src/etc/interface.java files of the jboss cvs module. Feel free to turn it into a page for the web site. - Original Message - From: Schaefer, Andreas [EMAIL PROTECTED] To: jBoss-Dev (E-mail) [EMAIL PROTECTED] Sent: Thursday, July 19, 2001 1:20 PM Subject: [JBoss-dev] Coding Style Hi Geeks Due the latest bunch of email I was getting a little bit confused how the actual Coding Style or Guidelines are. Do we have a document/page about this (or shouldn't we have one)? Have fun - Mad Andy / Better Pizza ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] how do i
At the end of the page: To change your subscription (set options like digest and delivery modes, get a reminder of your password, or unsubscribe from Jboss-development), enter your subscription email address: Follow the link :p -- Juha On Thu, 19 Jul 2001 [EMAIL PROTECTED] wrote: unsubscribe from this list? ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite binary.jsp
User: starksm Date: 01/07/19 14:54:17 Modified:.binary.jsp Log: Update the 2.4 release links Revision ChangesPath 1.5 +6 -7 newsite/binary.jsp Index: binary.jsp === RCS file: /cvsroot/jboss/newsite/binary.jsp,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- binary.jsp2001/07/11 00:13:08 1.4 +++ binary.jsp2001/07/19 21:54:16 1.5 @@ -35,15 +35,15 @@ trth align=leftp class=textPackages/ththp class=textnbsp;nbsp;nbsp;Sizenbsp;nbsp;nbsp;/ththp class=textDate/th/tr tr -tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.0BETA.zip;JBoss-2.4-BETA.zip/a/td -td align=centerp class=text9.2M/td -td align=centerp class=textJune 23, 2001/td +tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.0.23_BETA.zip;JBoss-2.4.0.23_BETA.zip/a/td +td align=centerp class=text8658903/td +td align=centerp class=textJuly 19, 2001/td /tr tr -tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.0_Tomcat-3.2.2.zip;JBoss-2.4-BETA_Tomcat-3.2.2.zip/a/td -td align=centerp class=text9.7M/td -td align=centerp class=textJune 23, 2001/td +tda class=link href=http://prdownloads.sourceforge.net/jboss/JBoss-2.4.0.23_Tomcat-3.2.3.zip;JBoss-2.4.0.23_Tomcat-3.2.3.zip/a/td +td align=centerp class=text11959461/td +td align=centerp class=textJuly 19, 2001/td /tr tr @@ -165,4 +165,3 @@ jsp:include page=navigation.jsp flush=true / - ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Coding Style
3 spaces. --jason On Thu, 19 Jul 2001, Schaefer, Andreas wrote: Thanx But now I am a little bit more confused. Just to fix this maybe once and for all: the classes uses 2 spaces as identation but one of the latest mails Marc said use 3 spaces !! I favor 3 but I can live with any number but we should only use one. Andy -Original Message- From: Scott M Stark [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 19, 2001 1:39 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] Coding Style Its documented in the src/etc/class.java and src/etc/interface.java files of the jboss cvs module. Feel free to turn it into a page for the web site. - Original Message - From: Schaefer, Andreas [EMAIL PROTECTED] To: jBoss-Dev (E-mail) [EMAIL PROTECTED] Sent: Thursday, July 19, 2001 1:20 PM Subject: [JBoss-dev] Coding Style Hi Geeks Due the latest bunch of email I was getting a little bit confused how the actual Coding Style or Guidelines are. Do we have a document/page about this (or shouldn't we have one)? Have fun - Mad Andy / Better Pizza ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Status of JBoss and EJB 2.0 deatures
I know that a few weeks back there were some emails saying that the 2.x CMP fields are complete and more recently the CMR has been committed to the latest code...how far along is the EJB-QL going? Is that still on schedule? Matt ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite guidelines.jsp
User: schaefera
Date: 01/07/19 18:02:08
Added: .guidelines.jsp
Log:
Guidelines web site to explain this and make it easier to read.
Revision ChangesPath
1.1 newsite/guidelines.jsp
Index: guidelines.jsp
===
jsp:include page=head.jsp flush=true /
jsp:include page=slogan.jsp flush=true
jsp:param name=SLOGAN value=CONTRIBUTE TO JBOSS: Guidelines/
/jsp:include
!-- CONTENT --
p class=headDEVELOPER CODING GUIDELINES/p
p class=text
This Guidelines are here to make the JBoss code more readable. Because of the
Age of JBoss there will be
always some code around which does not follow the guidelines but over time
this may become less and less.
/p
p class=text
To see a template for a class file go to the JBoss-Source
:jboss/src/etc/class.java and for an interface:
jboss/src/etc/interface.class.
/p
p class=headLayout/p
p class=text
ul
li
Identation: 3 Spaces (no Tabs because they look ugly in dump editors
like HTML pages (online CVS) )
/li
li
Comments: line up comments on the left hand side (also Javadocs)
/li
li
Grouping: Group members, methods etc. according to the templates and use
the template's comments to
separate them.
/li
/ul
/p
p class=headGeneral Code/p
p class=text
The first part of a JBoss class should contain the Copyright comment:
pre
/*
* JBoss, the OpenSource EJB server
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
/pre
/p
p class=text
Next part is the package definition. Please use bNO ABBREVIATIONS/b and
follow the Java guidelines.
/p
p class=text
Now add the external classes import statement. Please use always fully
qualified imports (no *) because
then everyone knows which class comes from which package. When you have a
conflict then import none or
the best one and fully qualify the other class(es) when you use them (example:
java.util.Date and java.sql.Date).
/p
p class=text
Add the JavaDoc Documentation for the main class which looks like this:
pre
/**
* lt;descriptiongt;
*
* @see lt;relatedgt;
* @author lt;a href=mailto:{email}gt;{full name}lt;/agt;.
* @author lt;a href=mailto:[EMAIL PROTECTED]gt;Marc Fleurylt;/agt;
* @version $Revision: 1.1 $
*
* lt;pgt;lt;bgt;Revisions:lt;/bgt;
*
* lt;pgt;lt;bgt;mmdd author:lt;/bgt;
* lt;ulgt;
* lt;ligt; explicit fix description (no line numbers but methods) go beyond the
cvs commit message
* lt;/ulgt;
*eg:
* lt;pgt;lt;bgt;20010516 marc fleury:lt;/bgt;
* lt;ulgt;
* lt;ligt; Ask all developers to clearly document the Revision, changed the
header.
* lt;/ulgt;
*/
/pre
Instead of @see you can also use {@link ...} inside the comments (inline
reference).
bALWAYS add these comments, the developer after you will love it and
hopefully do his/her part as well/b.
/p
p class=text
Document all public (and mostly protected) members and methods in the class
with JavaDoc except you did not
add new functionality during overwriting a method (comming from an Interface
or a base class). Especially note
ul
li
When Parameter can or cannot be null and also what it means when null is
allowed
/li
li
When Return values can be or are never null
/li
li
Document side effects
/li
li
Usefull is also when you mention if and where another method or the
overwritten method is called. Because
this is open-source it is not that important but when you only rely on the
documentation it can avoid
endless calls or other avoid mistakes when you have to call the
overwritten method.
/li
/ul
/p
p class=headCoding a Class/p
p class=text
pre
/*
* JBoss, the OpenSource EJB server
*
* Distributable under LGPL license.
* See terms of license at gnu.org.
*/
package x;
//EXPLICIT IMPORTS
import a.b.C1; // GOOD
import a.b.C2;
import a.b.C3;
// DO NOT WRITE
import a.b.*; // BAD
/**
* lt;descriptiongt;
*
* @see lt;relatedgt;
* @author lt;a href=mailto:{email}gt;{full name}lt;/agt;.
* @author lt;a href=mailto:[EMAIL PROTECTED]gt;Marc Fleurylt;/agt;
* @version $Revision: 1.1 $
*
* lt;pgt;lt;bgt;Revisions:lt;/bgt;
*
* lt;pgt;lt;bgt;mmdd author:lt;/bgt;
* lt;ulgt;
* lt;ligt; explicit fix description (no
[JBoss-dev] CVS update: jboss/src/etc class.java interface.java
User: schaefera
Date: 01/07/19 18:03:13
Modified:src/etc class.java interface.java
Log:
Adjusted the identation to the specified indentation of 3 spaces.
Revision ChangesPath
1.7 +77 -72jboss/src/etc/class.java
Index: class.java
===
RCS file: /cvsroot/jboss/jboss/src/etc/class.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- class.java2001/07/13 19:11:32 1.6
+++ class.java2001/07/20 01:03:13 1.7
@@ -20,7 +20,7 @@
* @see related
* @author a href=mailto:{email};{full name}/a.
* @author a href=mailto:[EMAIL PROTECTED];Marc Fleury/a
-* @version $Revision: 1.6 $
+* @version $Revision: 1.7 $
*
* pbRevisions:/b
*
@@ -33,6 +33,11 @@
* ul
* li Ask all developers to clearly document the Revision, changed the header.
* /ul
+* pb20010719 andreas schaefer:/b
+* ul
+* li Changed indentation to 3 spaces to go along with the guidelines and
removed second comment
+*about this to avoid confusion.
+* /ul
*/
@@ -42,79 +47,79 @@
extends Y
implements Z
{
- // Constants -
-
- // Attributes
-
- // Static
-
- // Constructors --
-
- // Public
-
- public void startService() throws Exception
- { // Use the newline for the opening bracket so we can match top and bottom
bracket visually
-
-Class cls = Class.forName(dataSourceClass);
-vendorSource = (XADataSource)cls.newInstance();
-
-// JUMP A LINE BETWEEN LOGICALLY DISCTINT **STEPS** AND ADD A LINE OF COMMENT
TO IT
-cls = vendorSource.getClass();
-
-if(properties != null properties.length() 0)
-{
+ // Constants -
+
+ // Attributes
+
+ // Static
+
+ // Constructors --
+
+ // Public
+
+ public void startService() throws Exception
+ { // Use the newline for the opening bracket so we can match top and bottom
bracket visually
- try
- {
- }
- catch (IOException ioe)
- {
- }
- for (Iterator i = props.entrySet().iterator(); i.hasNext();)
+ Class cls = Class.forName(dataSourceClass);
+ vendorSource = (XADataSource)cls.newInstance();
+
+ // JUMP A LINE BETWEEN LOGICALLY DISCTINT **STEPS** AND ADD A LINE OF COMMENT
TO IT
+ cls = vendorSource.getClass();
+
+ if(properties != null properties.length() 0)
{
-
-// Get the name and value for the attributes
-Map.Entry entry = (Map.Entry) i.next();
-String attributeName = (String) entry.getKey();
-String attributeValue = (String) entry.getValue();
-
-// Print the debug message
-log.debug(Setting attribute ' + attributeName + ' to ' +
- attributeValue + ');
-
-// get the attribute
-Method setAttribute =
-cls.getMethod(set + attributeName,
- new Class[] { String.class });
-
-// And set the value
-setAttribute.invoke(vendorSource,
- new Object[] { attributeValue });
+
+ try
+ {
+ }
+ catch (IOException ioe)
+ {
+ }
+ for (Iterator i = props.entrySet().iterator(); i.hasNext();)
+ {
+
+// Get the name and value for the attributes
+Map.Entry entry = (Map.Entry) i.next();
+String attributeName = (String) entry.getKey();
+String attributeValue = (String) entry.getValue();
+
+// Print the debug message
+log.debug(Setting attribute ' + attributeName + ' to ' +
+ attributeValue + ');
+
+// get the attribute
+Method setAttribute =
+cls.getMethod(set + attributeName,
+ new Class[] { String.class });
+
+// And set the value
+setAttribute.invoke(vendorSource,
+ new Object[] { attributeValue });
+ }
}
-}
-
-
-// Test database
-vendorSource.getXAConnection().close();
-
-// Bind in JNDI
-bind(new
[JBoss-dev] JBoss Guidelines Webpage
Hi Geeks
I just added guidelines.jsp to the JBoss CVS module newsite.
Please have a look at this and give me feedback.
It is linked from Contribution page.
Have fun - Mad Andy / Better Pizza
[EMAIL PROTECTED]
[EMAIL PROTECTED]
while( true ) { think(); write(); publish(); }
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite contrib.jsp
User: schaefera Date: 01/07/19 18:05:59 Modified:.contrib.jsp Log: Added link to Guidelines page. Revision ChangesPath 1.3 +7 -0 newsite/contrib.jsp Index: contrib.jsp === RCS file: /cvsroot/jboss/newsite/contrib.jsp,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- contrib.jsp 2001/06/17 19:43:06 1.2 +++ contrib.jsp 2001/07/20 01:05:59 1.3 @@ -62,6 +62,13 @@ a class=link href=http://sourceforge.net/tracker/?func=addgroup_id=22866atid=376688;Submit Feature Request/a /p +p class=headStyle Guides (DEVELOPERS)/p + +p class=text + Please have a look at the a href=guidelines.jspGuidelines/a to make + JBoss code more readable, thanx. +/p + p class=headCHANGE NOTES (DEVELOPERS)/p p class=text ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: newsite guidelines.jsp
User: schaefera
Date: 01/07/19 18:14:36
Modified:.guidelines.jsp
Log:
Added remarks to how JavaDoc reviews can be implemented.
Revision ChangesPath
1.2 +7 -3 newsite/guidelines.jsp
Index: guidelines.jsp
===
RCS file: /cvsroot/jboss/newsite/guidelines.jsp,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- guidelines.jsp2001/07/20 01:02:08 1.1
+++ guidelines.jsp2001/07/20 01:14:36 1.2
@@ -65,7 +65,7 @@
* @see lt;relatedgt;
* @author lt;a href=mailto:{email}gt;{full name}lt;/agt;.
* @author lt;a href=mailto:[EMAIL PROTECTED]gt;Marc Fleurylt;/agt;
-* @version $Revision: 1.1 $
+* @version $Revision: 1.2 $
*
* lt;pgt;lt;bgt;Revisions:lt;/bgt;
*
@@ -102,6 +102,10 @@
this is open-source it is not that important but when you only rely on
the documentation it can avoid
endless calls or other avoid mistakes when you have to call the
overwritten method.
/li
+li
+ Please add JavaDoc to every method/class when you working on this page.
When you are not 100% sure about
+ what you read please enlose the changed lines into lt;reviewgt; and
lt;/reviewgt; to indicate what
+ you changed and gave up for a review. When someone reviewed it just
remove this marks, thanx.
/ul
/p
@@ -130,7 +134,7 @@
* @see lt;relatedgt;
* @author lt;a href=mailto:{email}gt;{full name}lt;/agt;.
* @author lt;a href=mailto:[EMAIL PROTECTED]gt;Marc Fleurylt;/agt;
-* @version $Revision: 1.1 $
+* @version $Revision: 1.2 $
*
* lt;pgt;lt;bgt;Revisions:lt;/bgt;
*
@@ -256,7 +260,7 @@
* @see lt;relatedgt;
* @author lt;a href=mailto:{email}gt;{full name}lt;/agt;.
* @author lt;a href=mailto:[EMAIL PROTECTED]gt;Marc Fleurylt;/agt;
-* @version $Revision: 1.1 $
+* @version $Revision: 1.2 $
* Revisions:
*
* lt;pgt;lt;bgt;Revisions:lt;/bgt;
___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] jboss daily test results
JBoss daily test results SUMMARY Number of tests run: 124 Successful tests: 122 Errors:0 Failures: 2 [time of test: 20 July 2001 3:0 GMT] 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 Suite: org.jboss.test.jmsra.test.AllJUnitTests Test:testBeanOk Type:failure Exception: junit.framework.AssertionFailedError Message: expected:3 but was:-1 Stack Trace: junit.framework.AssertionFailedError: expected:3 but was:-1 at junit.framework.Assert.fail(Assert.java:143) at junit.framework.Assert.failNotEquals(Assert.java:149) at junit.framework.Assert.assertEquals(Assert.java:86) at junit.framework.Assert.assertEquals(Assert.java:72) at junit.framework.Assert.assertEquals(Assert.java:43) at org.jboss.test.jmsra.test.RaTest.testBeanOk(RaTest.java:175) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:155) at junit.framework.TestCase.runBare(TestCase.java:129) at junit.framework.TestResult$1.protect(TestResult.java:100) at junit.framework.TestResult.runProtected(TestResult.java:117) at junit.framework.TestResult.run(TestResult.java:103) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.run(TestSuite.java:144) at junit.framework.TestSuite.run(TestSuite.java:144) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:209) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:342) - Suite: org.jboss.test.jmsra.test.AllJUnitTests Test:testSimple Type:failure Exception: junit.framework.AssertionFailedError Message: expected:1 but was:-1 Stack Trace: junit.framework.AssertionFailedError: expected:1 but was:-1 at junit.framework.Assert.fail(Assert.java:143) at junit.framework.Assert.failNotEquals(Assert.java:149) at junit.framework.Assert.assertEquals(Assert.java:86) at junit.framework.Assert.assertEquals(Assert.java:72) at junit.framework.Assert.assertEquals(Assert.java:43) at org.jboss.test.jmsra.test.RaTest.testSimple(RaTest.java:157) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:155) at junit.framework.TestCase.runBare(TestCase.java:129) at junit.framework.TestResult$1.protect(TestResult.java:100) at junit.framework.TestResult.runProtected(TestResult.java:117) at junit.framework.TestResult.run(TestResult.java:103) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.run(TestSuite.java:144) at junit.framework.TestSuite.run(TestSuite.java:144) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:209) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:342) - ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] CVS update: jboss/src/main/org/jboss/util MBeanProxy.java
User: user57
Date: 01/07/19 22:08:56
Modified:src/main/org/jboss/util MBeanProxy.java
Log:
o cleaned up added javadoc
o added methods that take a MBeanServer
o decoding a few more jmx exceptions
Revision ChangesPath
1.6 +131 -36 jboss/src/main/org/jboss/util/MBeanProxy.java
Index: MBeanProxy.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/util/MBeanProxy.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- MBeanProxy.java 2001/06/18 20:01:28 1.5
+++ MBeanProxy.java 2001/07/20 05:08:56 1.6
@@ -6,23 +6,27 @@
*/
package org.jboss.util;
-import java.io.*;
-import java.net.*;
import java.lang.reflect.Method;
-import javax.management.*;
-import javax.management.loading.MLet;
+import javax.management.MBeanServer;
+import javax.management.MBeanServerFactory;
+import javax.management.ObjectName;
+import javax.management.MalformedObjectNameException;
+import javax.management.MBeanException;
+import javax.management.ReflectionException;
+import javax.management.RuntimeOperationsException;
+import javax.management.RuntimeMBeanException;
+import javax.management.RuntimeErrorException;
-import org.jboss.logging.Log;
import org.jboss.proxy.Proxy;
import org.jboss.proxy.InvocationHandler;
/**
- * description
+ * A factory for producing MBean proxies.
*
- * @see related
- * @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a.
- * @version $Revision: 1.5 $
+ * @author a href=mailto:[EMAIL PROTECTED];Rickard Öberg/a.
+ * @author a href=mailto:[EMAIL PROTECTED];Jason Dillon/a
+ * @version $Revision: 1.6 $
*/
public class MBeanProxy
implements InvocationHandler
@@ -30,60 +34,151 @@
// Constants -
// Attributes
- ObjectName name;
- MBeanServer server;
+
+ /** The server to proxy invoke calls to. */
+ private final MBeanServer server;
+
+ /** The name of the object to invoke. */
+ private final ObjectName name;
// Static
- public static Object create(Class intf, String name)
+
+ /**
+* Create an MBean proxy.
+*
+* @param intfThe interface which the proxy will implement.
+* @param nameA string used to construct the ObjectName of the
+*MBean to proxy to.
+* @returnA MBean proxy.
+*
+* @throws MalformedObjectNameExceptionInvalid object name.
+*/
+ public static Object create(final Class intf, final String name)
+ throws MalformedObjectNameException
+ {
+ return Proxy.newProxyInstance(intf.getClassLoader(),
+new Class[] { intf },
+new MBeanProxy(new ObjectName(name)));
+ }
+
+ /**
+* Create an MBean proxy.
+*
+* @param intf The interface which the proxy will implement.
+* @param name A string used to construct the ObjectName of the
+* MBean to proxy to.
+* @param serverThe MBeanServer that contains the MBean to proxy to.
+* @return A MBean proxy.
+*
+* @throws MalformedObjectNameExceptionInvalid object name.
+*/
+ public static Object create(final Class intf,
+ final String name,
+ final MBeanServer server)
throws MalformedObjectNameException
{
+ return Proxy.newProxyInstance
+ (intf.getClassLoader(),
+ new Class[] { intf },
+ new MBeanProxy(new ObjectName(name), server));
+ }
+
+ /**
+* Create an MBean proxy.
+*
+* @param intfThe interface which the proxy will implement.
+* @param nameThe name of the MBean to proxy invocations to.
+* @returnA MBean proxy.
+*/
+ public static Object create(final Class intf, final ObjectName name)
+ {
return Proxy.newProxyInstance(intf.getClassLoader(),
- new Class[] { intf },
- new MBeanProxy(name));
+new Class[] { intf },
+new MBeanProxy(name));
}
- public static Object create(Class intf, ObjectName name)
+ /**
+* Create an MBean proxy.
+*
+* @param intf The interface which the proxy will implement.
+* @param name The name of the MBean to proxy invocations to.
+* @param serverThe MBeanServer that contains the MBean to proxy to.
+* @return A
[JBoss-dev] CVS update: jboss/src/main/org/jboss/jms/asf StdServerSessionPool.java
User: user57
Date: 01/07/19 22:10:53
Modified:src/main/org/jboss/jms/asf StdServerSessionPool.java
Log:
o re-indent javadoc clean up
o changed logging to Log4j
Revision ChangesPath
1.8 +186 -157 jboss/src/main/org/jboss/jms/asf/StdServerSessionPool.java
Index: StdServerSessionPool.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/jms/asf/StdServerSessionPool.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- StdServerSessionPool.java 2001/06/27 03:08:21 1.7
+++ StdServerSessionPool.java 2001/07/20 05:10:53 1.8
@@ -34,175 +34,204 @@
import javax.jms.XAQueueSession;
import javax.jms.XATopicSession;
-import org.jboss.logging.Logger;
import EDU.oswego.cs.dl.util.concurrent.PooledExecutor;
import EDU.oswego.cs.dl.util.concurrent.Executor;
import EDU.oswego.cs.dl.util.concurrent.ThreadFactory;
import EDU.oswego.cs.dl.util.concurrent.BoundedBuffer;
+import org.apache.log4j.Category;
+
/**
- * StdServerSessionPool.java
+ * Implementation of ServerSessionPool.
*
*
* Created: Thu Dec 7 17:02:03 2000
*
- * @author
- * @version
+ * @author a href=mailto:[EMAIL PROTECTED];Peter Antman/a.
+ * @version $Revision: 1.8 $
*/
-
-public class StdServerSessionPool implements ServerSessionPool {
- private static final int DEFAULT_POOL_SIZE = 15;
- private int poolSize = DEFAULT_POOL_SIZE;
- private int ack;
- private boolean transacted;
- private MessageListener listener;
- private Connection con;
-
-
- private Vector sessionPool = new Vector();
-
- boolean isTransacted() {
- return transacted;
- }
-
-
- /**
- * Minimal constructor, could also have stuff for pool size
- */
- public StdServerSessionPool(Connection con, boolean transacted, int ack,
MessageListener listener) throws JMSException{
- this(con,transacted,ack,listener,DEFAULT_POOL_SIZE);
- }
- public StdServerSessionPool(Connection con, boolean transacted, int ack,
MessageListener listener, int maxSession) throws JMSException {
- this.con= con;
- this.ack= ack;
- this.listener= listener;
- this.transacted= transacted;
- this.poolSize= maxSession;
-
- executor = new PooledExecutor(poolSize);
- executor.setMinimumPoolSize(0);
- executor.setKeepAliveTime(1000*30);
- executor.waitWhenBlocked();
- executor.setThreadFactory( new ThreadFactory() {
- public Thread newThread(Runnable command) {
- return new Thread( threadGroup, command,
Thread Pool Worker);
- }
- }
- );
-
+public class StdServerSessionPool
+ implements ServerSessionPool
+{
+ private static ThreadGroup threadGroup =
+ new ThreadGroup(ASF Session Pool Threads);
+ private static final int DEFAULT_POOL_SIZE = 15;
+
+ /** Instance logger. */
+ private final Category log = Category.getInstance(this.getClass());
+
+ private int poolSize = DEFAULT_POOL_SIZE;
+ private int ack;
+ private boolean transacted;
+ private MessageListener listener;
+ private Connection con;
+ private Vector sessionPool = new Vector();
+ private PooledExecutor executor;
+
+ boolean isTransacted() {
+ return transacted;
+ }
+
+ /**
+* Minimal constructor, could also have stuff for pool size
+*/
+ public StdServerSessionPool(Connection con,
+ boolean transacted,
+ int ack,
+ MessageListener listener)
+ throws JMSException
+ {
+ this(con,transacted,ack,listener,DEFAULT_POOL_SIZE);
+ }
+
+ public StdServerSessionPool(Connection con,
+ boolean transacted,
+ int ack,
+ MessageListener listener,
+ int maxSession)
+ throws JMSException
+ {
+ this.con= con;
+ this.ack= ack;
+ this.listener= listener;
+ this.transacted= transacted;
+ this.poolSize= maxSession;
+
+ executor = new PooledExecutor(poolSize);
+ executor.setMinimumPoolSize(0);
+ executor.setKeepAliveTime(1000*30);
+ executor.waitWhenBlocked();
+ executor.setThreadFactory(new ThreadFactory() {
+public Thread newThread(Runnable command) {
+ return new Thread(threadGroup, command, Thread Pool Worker);
+}
+ });
- init();
- Logger.debug(Server
