[JBoss-dev] Build system; a new hope...

2001-07-19 Thread Jason Dillon

A few weeks ago I mentioned that I was going to write some email about a
build system that I had been working on.  Unfortunately due to some of the
entity locking & jbossmq problems I was unable to focus much time on
actually writing that email.  Since then I have found that there is always
something else todo besides write that mail, so I figure I just have to sit
down and do it.

A build system should be easy to use.  It should also be configurable on a
per-user and per-project basis and have a mechanism to group source modules
together, produce release archives, make coffee in the morning and take care
of you when you get sick.

Well, I think I have a suitable solution to *most* of this; I still haven't
got the coffee part done yet, and if you are sick enough you might think the
build system is taking care of you.

Over the years I have been working with build systems, first based on
clumsy usage of make, to more advanced usage, then on the ant and now here
I am.  My first build system (build-foo) was based on something that we used
at Mpath Interactive, called build-glue.  When I moved over to Ant I renamed
it to BuildMagic.  Over the last six months I have been learning to adapt to
some of the more ridiculous problems created by Ant as well as embracing the
elegance that it provides.

The drive to redesign BuildMagic was based on its lack of ability to
aggregate modules together in a unified, manageable fashion (which I need for
open source libraries that I produce, the increasingly complex software
modules which I have to deal with at work).

Ok enough babel, here is a brief overview:

BuildMagic is a set of extension tasks for Ant 1.3 as well as a common
configuration and build output structure.  There are two major "things" in
BuildMagic: Projects and Modules.

A project is an aggregation of modules.  It controls the configuration and
execution of the modules build system.  It provides a mechanism to invoke a
group of modules and to collect there output to produce a project release.

If anyone as played with NetBeans, some of the module configuration
inspiration came from looking at there build system in depth.

A module is something that contains source files to compile, documents to
perform filter substitution on and other such things.  The distinction
between the two is important.

One key feature of BuildMagic is how configuration properties are processed.
Ant 1.3 does not currently have any native late binding property; BuildMagic
*fixes* this problem.  It also provides some logic and looping tasks, but I
just implemented those for fun really.

 * * *

I will go in more detail shortly, but for those of you who would like to see
it in action you can look at Bliss:

 http://sourceforge.net/projects/bliss/

 cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/bliss login
 cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/bliss get
-r bliss_0_9_1 bliss

You can check out the main branch, but it is not guaranteed to compile, due
to some re-factoring.

 export JAVA_HOME=/where/the/jdk/lives
 cd bliss/build
 ./build release

If all goes well you will end up with a output/bliss-0.9.1-*.jar file under
build, which contains the modules api and jar file for the common module.

 * * *

Each project is based in a single root directory (you could probably modify
the build files to get around this, but I would not recommend it).  Each
project looks something like this:

 project_root/
   build/
   source1/
   source2/
   tools/
   thirdparty/

project_root, source1, source2 and build are arbitrary.  tools contains
libraries, scripts and whatever is used by the build system (and only the
build system) and thirdparty contains libraries scripts and whatever that is
used commonly between all of the source modules.  The distinction between
tools and thirdparty is subtle, but necessary.  Consider a project that used
ant 1.3 to build, but requires ant 1.1 to function (for whatever reason that
might be).

Both the tools and thirdparty directories are laid out like this:

  /

package_name contains no version numbers or vendor names, though I suppose
you could encode vendor names if you liked.  So for example if a project
depends on JMX v1.0ri you would want something like this:

  thirdparty/jmx/lib
  thirdparty/jmx/lib/jmxgrinder.jar
  thirdparty/jmx/lib/jmxri.jar
  thirdparty/jmx/lib/jmxtools.jar

With Bliss I have chosen to exploit the CVSROOT/modules file to build the
tools and thirdparty structure.  Check out the modules file for a better
idea:

 cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/bliss get -c

There are ups and downs to this, one of the downs is that it makes it hard
to manage additions and removals of thirdparty modules with branch specs.
Though and advantage is that if you have more than one project that depends
on a version of a thirdparty library, you only have to update the library
once (instead of for each project).  Any ways, as long at the name space ends
up the same it does not really matter how the files g

[JBoss-dev] CVS update: jboss/src/main/org/jboss/jms/asf StdServerSessionPool.java

2001-07-19 Thread Jason Dillon

  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 mailto:[EMAIL PROTECTED]";>Peter Antman.
  + * @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 Se

[JBoss-dev] CVS update: jboss/src/main/org/jboss/util MBeanProxy.java

2001-07-19 Thread Jason Dillon

  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;
   
   /**
  - *
  + * A factory for producing MBean proxies.
*  
  - *   @see 
  - *   @author mailto:[EMAIL PROTECTED]";>Rickard Öberg.
  - *   @version $Revision: 1.5 $
  + * @author mailto:[EMAIL PROTECTED]";>Rickard Öberg.
  + * @author mailto:[EMAIL PROTECTED]";>Jason Dillon
  + * @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 MBean proxy.
  +*/
  +   public stati

[JBoss-dev] jboss daily test results

2001-07-19 Thread chris



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: newsite guidelines.jsp

2001-07-19 Thread Mad

  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 
   *   @author  {full name}.
   *   @author  Marc Fleury
  -*   @version $Revision: 1.1 $
  +*   @version $Revision: 1.2 $
   *   
   *   

Revisions: * @@ -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. + + 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 "" and "" to indicate what + you changed and gave up for a review. When someone reviewed it just remove this marks, thanx. @@ -130,7 +134,7 @@ * @see * @author {full name}. * @author Marc Fleury -* @version $Revision: 1.1 $ +* @version $Revision: 1.2 $ * *

Revisions: * @@ -256,7 +260,7 @@ * @see * @author {full name}. * @author Marc Fleury -* @version $Revision: 1.1 $ +* @version $Revision: 1.2 $ * Revisions: * *

Revisions: ___ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development


[JBoss-dev] JBoss Newsite Build

2001-07-19 Thread Schaefer, Andreas

Hi Geeks

During testing of JBoss Survey I created a EAR build system
for the JBoss website (newsite) to ease the deployement of
the JBoss website. This helps to test changes on the newsite
w/o uploading it.

Does anyone object this otherwise I will add this to CVS ?


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

2001-07-19 Thread Mad

  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 @@
 http://sourceforge.net/tracker/?func=add&group_id=22866&atid=376688";>Submit 
Feature Request
   
   
  +Style Guides (DEVELOPERS)
  +
  +
  +  Please have a look at the Guidelines to make
  +  JBoss code more readable, thanx.
  +
  +
   CHANGE NOTES (DEVELOPERS)
   
   
  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] JBoss Guidelines Webpage

2001-07-19 Thread Schaefer, Andreas

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: jboss/src/etc class.java interface.java

2001-07-19 Thread Mad

  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 
   *   @author  mailto:{email}";>{full name}.
   *   @author  mailto:[EMAIL PROTECTED]";>Marc Fleury
  -*   @version $Revision: 1.6 $
  +*   @version $Revision: 1.7 $
   *   
   *   Revisions:
   *
  @@ -33,6 +33,11 @@
   *   
   *Ask all developers to clearly document the Revision, changed the header.  
   *   
  +*   20010719 andreas schaefer:
  +*   
  +*Changed indentation to 3 spaces to go along with the guidelines and 
removed second comment
  +*about this to avoid confusion.
  +*   
   */
   
   
  @@ -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 });
  + }
 }
  -}

[JBoss-dev] CVS update: newsite guidelines.jsp

2001-07-19 Thread Mad

  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
  ===
  
  
  
   
  
  
  
  

DEVELOPER CODING GUIDELINES

  
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.
  
  
To see a template for a class file go to the JBoss-Source 
:/src/etc/class.java and for an interface:
/src/etc/interface.class.
  
  
  Layout
  
  

  
Identation: 3 Spaces (no Tabs because they look ugly in "dump" editors 
like HTML pages (online CVS) )
  
  
Comments: line up comments on the left hand side (also Javadocs)
  
  
Grouping: Group members, methods etc. according to the templates and use 
the template's comments to
separate them.
  

  
  
  General Code
  
  
The first part of a JBoss class should contain the Copyright comment:

  /*
  * JBoss, the OpenSource EJB server
  *
  * Distributable under LGPL license.
  * See terms of license at gnu.org.
  */

  
  
Next part is the package definition. Please use NO ABBREVIATIONS and 
follow the Java guidelines.
  
  
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).
  
  
Add the JavaDoc Documentation for the main class which looks like this:

  /**
  *    
  *
  *   @see 
  *   @author  {full name}.
  *   @author  Marc Fleury
  *   @version $Revision: 1.1 $
  *   
  *   

Revisions: * *

mmdd author: *

    *
  • explicit fix description (no line numbers but methods) go beyond the cvs commit message *
*eg: *

20010516 marc fleury: *

    *
  • Ask all developers to clearly document the Revision, changed the header. *
*/ Instead of "@see" you can also use "{@link ...}" inside the comments (inline reference). ALWAYS add these comments, the developer after you will love it and hopefully do his/her part as well. 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 When Parameter can or cannot be null and also what it means when null is allowed When Return values can be or are never null Document side effects 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. Coding a Class /* * 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 /** * * * @see * @author {full name}. * @author Marc Fleury * @version $Revision: 1.1 $ * *

Revisions: * *

mmdd author: *

    *
  • explicit fix description (no line numbers but methods) go beyond the cvs commit message *
*eg: *

20010516 marc fleury: *

    *
  • Ask all developers to clearly document the Revision, changed the header. *
*/ // DO NOT USE "TAB" TO INDENT CODE USE *3* SPACES FOR PORTABILITY AMONG EDITORS public class X extends Y implements Z { // Constants - // Attributes // Static --

[JBoss-dev] Status of JBoss and EJB 2.0 deatures

2001-07-19 Thread Matt Veitas

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



Re: [JBoss-dev] JBossCX use of Mbeans

2001-07-19 Thread David Jencks

Hi,

Indeed you did leave some commented out code. I always wondered how the
jboss-specific deployment info was supposed to get into the rar.  I like
the idea of having an application-specific configuration much better.

Wouldn't it be pretty easy to have each application (have the opportunity)
to include a jboss.jcml-format file that is configured as the first
deployment step and removed as the last undeployment step? I'm not sure
about jmx namespaces, however I think these could be used to keep the
applications from interfering with each other.  (so for instance two apps
could have connection factories with the same (local) name but attached to
different dbs)

I think several people have asked recently whether it is possible to add
pools while jboss is running: this would certainly provide an easy way for
them to script that.

Any comments anyone?

david jencks


On 2001.07.18 16:52:42 -0400 Toby Allsopp wrote:
> On Wed, Jul 18, 2001 at 03:38:29PM -0400, Jay Walters wrote:
> > Do I need an MBean for each connector which I'm deploying to JBossCX
> (maybe
> > I'm really confused here)? It seems that this is how the two which are
> > distributed with the standard JBoss release are configured.  Is this
> how it
> > works right now?  Is there some reason that it needs to be this way?
> 
> The way it currently works is that you need an MBean for each connection
> factory you want to have in JNDI, just like you need an MBean for each
> JDBC connection pool.
> 
> It would be nice to be able to set up the connection factory as part
> of an EAR, e.g. using a jboss-application.xml file.  I think I left
> some commented out code in RARDeployer.java that looks for a
> jboss-ra.xml file in the RAR and treats it like an excerpt from
> jboss.jcml.
> 
> I think this approach is alright, but perhaps we should define a
> general mechanism for an application to contain an MBean configuration
> that is started when the app is deployed and stopped when it is
> undeployed.
> 
> Toby.
> 
> ___
> 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

2001-07-19 Thread Jason Dillon

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] CVS update: newsite binary.jsp

2001-07-19 Thread Scott M Stark

  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 @@
 Packages   Size   Date
 
 
  -http://prdownloads.sourceforge.net/jboss/JBoss-2.4.0BETA.zip";>JBoss-2.4-BETA.zip
  -9.2M
  -June 23, 2001
  +http://prdownloads.sourceforge.net/jboss/JBoss-2.4.0.23_BETA.zip";>JBoss-2.4.0.23_BETA.zip
  +8658903
  +July 19, 2001
 
   
 
  -http://prdownloads.sourceforge.net/jboss/JBoss-2.4.0_Tomcat-3.2.2.zip";>JBoss-2.4-BETA_Tomcat-3.2.2.zip
  -9.7M
  -June 23, 2001
  +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
  +11959461
  +July 19, 2001
 
   
 
  @@ -165,4 +165,3 @@
   
   
   
  - 
  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] how do i

2001-07-19 Thread Juha-P Lindfors


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



Re: [JBoss-dev] Coding Style

2001-07-19 Thread Scott M Stark

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] new wait(1000) not good

2001-07-19 Thread Bill Burke

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 1046>cat 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 t

RE: [JBoss-dev] Coding Style

2001-07-19 Thread Schaefer, Andreas

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] jboss.jcml reading properties problem/bug.

2001-07-19 Thread Schaefer, Andreas

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:
> > > >> > >  name="JCA:service=ConnectionFactoryLoader,name=JmsXA">
> > > > 
> > > >   MinSize=0
> > > >   MaxSize=10
> > > >   Blocking=true
> > > >   GCEnabled=false
> > > > 
> > > > 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] how do i

2001-07-19 Thread David Jencks

Well, when I follow the lintk the last line on the page says go here to
unsubscribe.

On 2001.07.19 16:23:00 -0400 [EMAIL PROTECTED] wrote:
> unsubscribe from this list?
> 
> and before you send some smart alec response like follow the link,
> realize
> that at the end of the link there is no info on unsubscribing.
> 
> thanks,
> Dave Blankley
> 
> -- Original Message --
> 
> >Send Jboss-development mailing list submissions to
> > [EMAIL PROTECTED]
> >
> >To subscribe or unsubscribe via the World Wide Web, visit
> > http://lists.sourceforge.net/lists/listinfo/jboss-development
> >or, via email, send a message with subject or body 'help' to
> > [EMAIL PROTECTED]
> >
> >You can reach the person managing the list at
> > [EMAIL PROTECTED]
> >
> >When replying, please edit your Subject line so it is more specific
> >than "Re: Contents of Jboss-development digest..."
> >
> >
> >Today's Topics:
> >
> >   1. CVS update: jboss/src/client jnp-client.jar (Scott M Stark)
> >   2. CVS update: jboss/src/lib jnpserver.jar (Scott M Stark)
> >   3. CVS update: jboss/src/main/org/jboss Main.java (Scott M Stark)
> >   4. CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp/server
> DefaultSocketFactory.java
> >JRMPContainerInvoker.java (Scott M Stark)
> >
> >--__--__--
> >
> >Message: 1
> >To: [EMAIL PROTECTED]
> >From: Scott M Stark <[EMAIL PROTECTED]>
> >Date: Thu, 19 Jul 2001 13:13:07 -0700
> >Subject: [JBoss-dev] CVS update: jboss/src/client jnp-client.jar
> >Reply-To: [EMAIL PROTECTED]
> >
> >  User: starksm
> >  Date: 01/07/19 13:13:07
> >
> >  Modified:src/client Tag: Branch_2_4 jnp-client.jar
> >  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  +21 -21jboss/src/client/jnp-client.jar
> >
> > <>
> >
> >
> >
> >
> >--__--__--
> >
> >Message: 2
> >To: [EMAIL PROTECTED]
> >From: Scott M Stark <[EMAIL PROTECTED]>
> >Date: Thu, 19 Jul 2001 13:13:07 -0700
> >Subject: [JBoss-dev] CVS update: jboss/src/lib jnpserver.jar
> >Reply-To: [EMAIL PROTECTED]
> >
> >  User: starksm
> >  Date: 01/07/19 13:13:07
> >
> >  Modified:src/lib  Tag: Branch_2_4 jnpserver.jar
> >  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.13.4.2  +40 -34jboss/src/lib/jnpserver.jar
> >
> > <>
> >
> >
> >
> >
> >--__--__--
> >
> >Message: 3
> >To: [EMAIL PROTECTED]
> >From: Scott M Stark <[EMAIL PROTECTED]>
> >Date: Thu, 19 Jul 2001 13:13:07 -0700
> >Subject: [JBoss-dev] CVS update: jboss/src/main/org/jboss Main.java
> >Reply-To: [EMAIL PROTECTED]
> >
> >  User: starksm
> >  Date: 01/07/19 13:13:07
> >
> >  Modified:src/main/org/jboss Tag: Branch_2_4 Main.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.35.2.5  +241 -241  jboss/src/main/org/jboss/Main.java
> >
> >  Index: Main.java
> >  ===
> >  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/Main.java,v
> >  retrieving revision 1.35.2.4
> >  retrieving revision 1.35.2.5
> >  diff -u -r1.35.2.4 -r1.35.2.5
> >  --- Main.java  2001/07/09 08:33:26 1.35.2.4
> >  +++ Main.java  2001/07/19 20:13:07 1.35.2.5
> >  @@ -1,242 +1,242 @@
> >  -/*
> >  - * JBoss, the OpenSource EJB server
> >  - *
> >  - * Distributable under LGPL license.
> >  - * See terms of license at gnu.org.
> >  - */
> >  -
> >  -package org.jboss;
> >  -
> >  -import java.io.File;
> >  -import java.io.IOException;
> >  -import java.io.InputStream;
> >  -import java.io.PrintStream;
> >  -import java.io.BufferedReader;
> >  -import java.io.InputStreamReader;
> >  -import java.io.PrintWriter;
> >  -import java.io.FileWriter;
> >  -import java.net.URL;
> >  -import java.security.*;
> >  -import java.util.*;
> >  -
> >  -import javax.management.*;
> >  -import javax.management.loading.*;
> >  -
> >  -/**
> >  - *
> >  - *   @see 
> >  - *   @author Rickard Öberg ([EMAIL PROTECTED])
> >  - *   @author mailto:[EMAIL PROTECTED]";>Daniel
> O'Connor.
> >  - *   @author [EMAIL PROTECTED]
> >  - *   @version $Revision: 1.35.2.4 $
> >  - */
> >  -public class Main
> >  -{
> >  -   // Constants -
> >  -
> >  -   String versionIdentifier = "2.4 BETA(Rel_2_4_0_14)";
> >  -   // Attributes --

Re: [JBoss-dev] Coding Style

2001-07-19 Thread Scott M Stark

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



RE: [JBoss-dev] new wait(1000) not good

2001-07-19 Thread James Cook

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 1046>cat 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]
> > > 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.s

[JBoss-dev] how do i

2001-07-19 Thread dblankley

unsubscribe from this list?

and before you send some smart alec response like follow the link, realize
that at the end of the link there is no info on unsubscribing.

thanks,
Dave Blankley

-- Original Message --

>Send Jboss-development mailing list submissions to
>   [EMAIL PROTECTED]
>
>To subscribe or unsubscribe via the World Wide Web, visit
>   http://lists.sourceforge.net/lists/listinfo/jboss-development
>or, via email, send a message with subject or body 'help' to
>   [EMAIL PROTECTED]
>
>You can reach the person managing the list at
>   [EMAIL PROTECTED]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Jboss-development digest..."
>
>
>Today's Topics:
>
>   1. CVS update: jboss/src/client jnp-client.jar (Scott M Stark)
>   2. CVS update: jboss/src/lib jnpserver.jar (Scott M Stark)
>   3. CVS update: jboss/src/main/org/jboss Main.java (Scott M Stark)
>   4. CVS update: jboss/src/main/org/jboss/ejb/plugins/jrmp/server 
>DefaultSocketFactory.java
>JRMPContainerInvoker.java (Scott M Stark)
>
>--__--__--
>
>Message: 1
>To: [EMAIL PROTECTED]
>From: Scott M Stark <[EMAIL PROTECTED]>
>Date: Thu, 19 Jul 2001 13:13:07 -0700
>Subject: [JBoss-dev] CVS update: jboss/src/client jnp-client.jar
>Reply-To: [EMAIL PROTECTED]
>
>  User: starksm
>  Date: 01/07/19 13:13:07
>
>  Modified:src/client Tag: Branch_2_4 jnp-client.jar
>  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  +21 -21jboss/src/client/jnp-client.jar
>
>   <>
>
>
>
>
>--__--__--
>
>Message: 2
>To: [EMAIL PROTECTED]
>From: Scott M Stark <[EMAIL PROTECTED]>
>Date: Thu, 19 Jul 2001 13:13:07 -0700
>Subject: [JBoss-dev] CVS update: jboss/src/lib jnpserver.jar
>Reply-To: [EMAIL PROTECTED]
>
>  User: starksm
>  Date: 01/07/19 13:13:07
>
>  Modified:src/lib  Tag: Branch_2_4 jnpserver.jar
>  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.13.4.2  +40 -34jboss/src/lib/jnpserver.jar
>
>   <>
>
>
>
>
>--__--__--
>
>Message: 3
>To: [EMAIL PROTECTED]
>From: Scott M Stark <[EMAIL PROTECTED]>
>Date: Thu, 19 Jul 2001 13:13:07 -0700
>Subject: [JBoss-dev] CVS update: jboss/src/main/org/jboss Main.java
>Reply-To: [EMAIL PROTECTED]
>
>  User: starksm
>  Date: 01/07/19 13:13:07
>
>  Modified:src/main/org/jboss Tag: Branch_2_4 Main.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.35.2.5  +241 -241  jboss/src/main/org/jboss/Main.java
>
>  Index: Main.java
>  ===
>  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/Main.java,v
>  retrieving revision 1.35.2.4
>  retrieving revision 1.35.2.5
>  diff -u -r1.35.2.4 -r1.35.2.5
>  --- Main.java2001/07/09 08:33:26 1.35.2.4
>  +++ Main.java2001/07/19 20:13:07 1.35.2.5
>  @@ -1,242 +1,242 @@
>  -/*
>  - * JBoss, the OpenSource EJB server
>  - *
>  - * Distributable under LGPL license.
>  - * See terms of license at gnu.org.
>  - */
>  -
>  -package org.jboss;
>  -
>  -import java.io.File;
>  -import java.io.IOException;
>  -import java.io.InputStream;
>  -import java.io.PrintStream;
>  -import java.io.BufferedReader;
>  -import java.io.InputStreamReader;
>  -import java.io.PrintWriter;
>  -import java.io.FileWriter;
>  -import java.net.URL;
>  -import java.security.*;
>  -import java.util.*;
>  -
>  -import javax.management.*;
>  -import javax.management.loading.*;
>  -
>  -/**
>  - *
>  - *   @see 
>  - *   @author Rickard Öberg ([EMAIL PROTECTED])
>  - *   @author mailto:[EMAIL PROTECTED]";>Daniel O'Connor.
>  - *   @author [EMAIL PROTECTED]
>  - *   @version $Revision: 1.35.2.4 $
>  - */
>  -public class Main
>  -{
>  -   // Constants -
>  -
>  -   String versionIdentifier = "2.4 BETA(Rel_2_4_0_14)";
>  -   // Attributes 
>  -
>  -   // Static 
>  -   public static void main(final String[] args)
>  -   throws Exception
>  -   {
>  +/*
>  + * JBoss, the OpenSource EJB server
>  + *
>  + * Distributable under LGPL license.
>  + * See terms of license at gnu.org.
>  + */
>  +
>  +package org.jboss;
>  +
>  +import java.io.File;
>  +import java.io.IOException;
>  +import java.io.InputStream;
>  +import java.io.PrintStream;
>  +

[JBoss-dev] CVS update: jboss/src/main/org/jboss/configuration ConfigurationService.java

2001-07-19 Thread Scott M Stark

  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  mailto:[EMAIL PROTECTED]";>Rickard Öberg.
* @author  mailto:[EMAIL PROTECTED]";>Scott Stark.
* @author  mailto:[EMAIL PROTECTED]";>Jason Dillon
  - * @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



[JBoss-dev] Coding Style

2001-07-19 Thread Schaefer, Andreas

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



Re: [JBoss-dev] jboss.jcml reading properties problem/bug.

2001-07-19 Thread Scott M Stark

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] CVS update: jboss/src/main/org/jboss Main.java

2001-07-19 Thread Scott M Stark

  User: starksm 
  Date: 01/07/19 13:13:07

  Modified:src/main/org/jboss Tag: Branch_2_4 Main.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.35.2.5  +241 -241  jboss/src/main/org/jboss/Main.java
  
  Index: Main.java
  ===
  RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/Main.java,v
  retrieving revision 1.35.2.4
  retrieving revision 1.35.2.5
  diff -u -r1.35.2.4 -r1.35.2.5
  --- Main.java 2001/07/09 08:33:26 1.35.2.4
  +++ Main.java 2001/07/19 20:13:07 1.35.2.5
  @@ -1,242 +1,242 @@
  -/*
  - * JBoss, the OpenSource EJB server
  - *
  - * Distributable under LGPL license.
  - * See terms of license at gnu.org.
  - */
  -
  -package org.jboss;
  -
  -import java.io.File;
  -import java.io.IOException;
  -import java.io.InputStream;
  -import java.io.PrintStream;
  -import java.io.BufferedReader;
  -import java.io.InputStreamReader;
  -import java.io.PrintWriter;
  -import java.io.FileWriter;
  -import java.net.URL;
  -import java.security.*;
  -import java.util.*;
  -
  -import javax.management.*;
  -import javax.management.loading.*;
  -
  -/**
  - *
  - *   @see 
  - *   @author Rickard Öberg ([EMAIL PROTECTED])
  - *   @author mailto:[EMAIL PROTECTED]";>Daniel O'Connor.
  - *   @author [EMAIL PROTECTED]
  - *   @version $Revision: 1.35.2.4 $
  - */
  -public class Main
  -{
  -   // Constants -
  -
  -   String versionIdentifier = "2.4 BETA(Rel_2_4_0_14)";
  -   // Attributes 
  -
  -   // Static 
  -   public static void main(final String[] args)
  -   throws Exception
  -   {
  +/*
  + * JBoss, the OpenSource EJB server
  + *
  + * Distributable under LGPL license.
  + * See terms of license at gnu.org.
  + */
  +
  +package org.jboss;
  +
  +import java.io.File;
  +import java.io.IOException;
  +import java.io.InputStream;
  +import java.io.PrintStream;
  +import java.io.BufferedReader;
  +import java.io.InputStreamReader;
  +import java.io.PrintWriter;
  +import java.io.FileWriter;
  +import java.net.URL;
  +import java.security.*;
  +import java.util.*;
  +
  +import javax.management.*;
  +import javax.management.loading.*;
  +
  +/**
  + *
  + *   @see 
  + *   @author Rickard Öberg ([EMAIL PROTECTED])
  + *   @author mailto:[EMAIL PROTECTED]";>Daniel O'Connor.
  + *   @author [EMAIL PROTECTED]
  + *   @version $Revision: 1.35.2.5 $
  + */
  +public class Main
  +{
  +   // Constants -
  +
  +   String versionIdentifier = "2.4 BETA(Rel_2_4_0_23)";
  +   // Attributes 
  +
  +   // Static 
  +   public static void main(final String[] args)
  +   throws Exception
  +   {
 Thread.currentThread().setName("JBossMain");
  -  String cn = "default"; // Default configuration name is "default", i.e. all 
conf files are in "/conf/default"
  -  String patchDir = null;
  -  // Given conf name?
  -  if (args.length == 1)
  - cn = args[0];
  -  for(int a = 0; a < args.length; a ++)
  -  {
  -  if( args[a].startsWith("-p") )
  -  patchDir = args[a+1];
  -  }
  -  final String confName = cn;
  -  final String patchDirName = patchDir;
  -
  -  // Load system properties
  -  URL jbossProps = 
Main.class.getClassLoader().getResource(confName+"/jboss.properties");
  -  InputStream propertiesIn = 
Main.class.getClassLoader().getResourceAsStream(confName+"/jboss.properties");
  -  if ( propertiesIn == null )
  -  {
  - throw new IOException("jboss.properties missing");
  -  }
  -
  -  System.getProperties().load(propertiesIn);
  -
  -  /* Set a jboss.home property from the location of the Main.class jar
  - if the property does not exist.
  -  */
  -  if( System.getProperty("jboss.home") == null )
  -  {
  -  String path = 
Main.class.getProtectionDomain().getCodeSource().getLocation().getFile();
  -  File runJar = new File(path);
  -  // Home dir should be the parent of the dir containing run.jar
  -  File homeDir = new File(runJar.getParent(), "..");
  -  System.setProperty("jboss.home", homeDir.getCanonicalPath());
  -  }
  -  System.out.println("jboss.home = "+System.getProperty("jboss.home"));
  -
  -  // Set the JAAS login config file if not already set
  -  if( System.getProperty("java.security.auth.login.config") == null )
  -  {
  -  URL loginConfig = 
Main.class.getClassLoader().getResource(co

[JBoss-dev] CVS update: jboss/src/resources/org/jboss/metadata jboss_2_4.dtd

2001-07-19 Thread Scott M Stark

  User: starksm 
  Date: 01/07/19 13:13:07

  Modified:src/resources/org/jboss/metadata Tag: Branch_2_4
jboss_2_4.dtd
  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.1.2.5   +12 -1 jboss/src/resources/org/jboss/metadata/jboss_2_4.dtd
  
  Index: jboss_2_4.dtd
  ===
  RCS file: /cvsroot/jboss/jboss/src/resources/org/jboss/metadata/jboss_2_4.dtd,v
  retrieving revision 1.1.2.4
  retrieving revision 1.1.2.5
  diff -u -r1.1.2.4 -r1.1.2.5
  --- jboss_2_4.dtd 2001/06/29 18:13:14 1.1.2.4
  +++ jboss_2_4.dtd 2001/07/19 20:13:07 1.1.2.5
  @@ -523,7 +523,7 @@
 
 Used in: container-configuration
 -->
  -
  +
   
   
   
  +
  +
  +
   
   
   
  
  
  

___
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

2001-07-19 Thread Scott M Stark

  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;
   
   /**
  - *  
*
  - *  @see 
  - *  @author Rickard Öberg ([EMAIL PROTECTED])
  - *   @author mailto:[EMAIL PROTECTED]";>Sebastien 
Alborini
  - *  @author mailto:[EMAIL PROTECTED]";>Marc Fleury
  - *   @author mailto:[EMAIL PROTECTED]";>Juha Lindfors
  - *  @version $Revision: 1.37 $
  + * @author Rickard Öberg ([EMAIL PROTECTED])
  + *   @author mailto:[EMAIL PROTECTED]";>Sebastien Alborini
  + * @author mailto:[EMAIL PROTECTED]";>Marc Fleury
  + *   @author mailto:[EMAIL PROTECTED]";>Juha Lindfors
  + *   @author mailto:[EMAIL PROTECTED]";>Scott Stark
  + * @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)
  +}
  +catch(NumberFormatException e)
   {
   rmiPort = ANON

[JBoss-dev] CVS update: jboss/src/main/org/jboss/naming NamingService.java

2001-07-19 Thread Scott M Stark

  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 mailto:[EMAIL PROTECTED]";>Rickard Öberg
*   @author mailto:[EMAIL PROTECTED]";>Scott Stark.
  - *   @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



[JBoss-dev] CVS update: jboss/src/lib jnpserver.jar

2001-07-19 Thread Scott M Stark

  User: starksm 
  Date: 01/07/19 13:13:07

  Modified:src/lib  Tag: Branch_2_4 jnpserver.jar
  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.13.4.2  +40 -34jboss/src/lib/jnpserver.jar
  
<>
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] CVS update: jboss/src/client jnp-client.jar

2001-07-19 Thread Scott M Stark

  User: starksm 
  Date: 01/07/19 13:13:07

  Modified:src/client Tag: Branch_2_4 jnp-client.jar
  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  +21 -21jboss/src/client/jnp-client.jar
  
<>
  
  

___
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

2001-07-19 Thread Scott M Stark

  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

2001-07-19 Thread Scott M Stark

  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: jnp/src/main/org/jnp/test TestJNPSockets.java

2001-07-19 Thread Scott M Stark

  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



RE: [JBoss-dev] jboss.jcml reading properties problem/bug.

2001-07-19 Thread Schaefer, Andreas

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:
> > >> >  name="JCA:service=ConnectionFactoryLoader,name=JmsXA">
> > > 
> > >   MinSize=0
> > >   MaxSize=10
> > >   Blocking=true
> > >   GCEnabled=false
> > > 
> > > 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: manual/src/docs jbossintro.xml

2001-07-19 Thread Tobias Frech

  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

  - This has compiled the EJB classes and created the ejb-jar for 
deployment. The contents of the
  + This 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:

  
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [JBoss-dev] new wait(1000) not good

2001-07-19 Thread Joseph Dane

> "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



Re: [JBoss-dev] jboss.jcml reading properties problem/bug.

2001-07-19 Thread Scott M Stark

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:
> >>  name="JCA:service=ConnectionFactoryLoader,name=JmsXA">
> > 
> >   MinSize=0
> >   MaxSize=10
> >   Blocking=true
> >   GCEnabled=false
> > 
> > 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-dev] CVS update: jboss/src/main/org/jboss/configuration ConfigurationService.java

2001-07-19 Thread Scott M Stark

  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  mailto:[EMAIL PROTECTED]";>Rickard Öberg.
* @author  mailto:[EMAIL PROTECTED]";>Scott Stark.
* @author  mailto:[EMAIL PROTECTED]";>Jason Dillon
  - * @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] new wait(1000) not good

2001-07-19 Thread Dain Sundstrom

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] [ jboss-Bugs-442804 ] dtd reference

2001-07-19 Thread noreply

Bugs item #442804, was opened at 2001-07-19 09:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=442804&group_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":

http://www.jboss.org/j2ee/dtd/jboss.dtd";>



--

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=376685&aid=442804&group_id=22866

___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [JBoss-dev] WARNING: No rollback on transaction timeout with mainline(2.5)

2001-07-19 Thread Bill Burke

> -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



RE: [JBoss-dev] jboss.jcml reading properties problem/bug.

2001-07-19 Thread Jay Walters

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:
> name="JCA:service=ConnectionFactoryLoader,name=JmsXA">
> 
>   MinSize=0
>   MaxSize=10
>   Blocking=true
>   GCEnabled=false
> 
> 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



RE: [JBoss-dev] CVS update: jboss/src/main/org/jboss/jdbc

2001-07-19 Thread Jay Walters

I'm not sure what dependencies there might be between the latest
jbosspool,jbosscx, jboss-j2ee and jboss mainline changes I made and you guys
pushing a new jbosspool into 2.4.  Ok, actually I'm worried something will
be fouled up because of the dependencies between the various bits and pieces
I touched.

I did not tag anything prior to the changes I made (my very bad).  Did you
guys do anything with jbosscx in terms of the 2.4 branch?  In the end it was
really just support for pfd2 of the connector and we can push it all into
2.4, I was just working on the main branch.

Cheers

-Original Message-
From: Scott M Stark [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 19, 2001 12:28 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] CVS update: jboss/src/main/org/jboss/jdbc


Also add a Rel_2_4_0_21  tag to the jbosspool module on the 2.4 branch
to tie the module code to the binary jar with the same tag in the jboss
module.
The non-jboss cvs modules are not labeled independent of the jboss module,
so every change on the 2.4 branch is a change to the jboss release.



___
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: jbosssx/src/main/org/jboss/security/plugins JaasSecurityManager.java JaasSecurityManagerService.java

2001-07-19 Thread Scott M Stark

  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 Oleg Nitz
   @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 Oleg Nitz
  @@ -52,213 +58,244 @@
*   @author mailto:[EMAIL PROTECTED]";>Scott Stark
*/
   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 = new Hashtable();
  -
  -public JaasSecurityManagerServ

[JBoss-dev] CVS update: jboss/src/lib jboss-jaas.jar jbosssx.jar

2001-07-19 Thread Scott M Stark

  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
  
<>
  
  
  1.11.2.3  +185 -186  jboss/src/lib/jbosssx.jar
  
<>
  
  

___
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development



[JBoss-dev] CVS update: jboss/src/client jbosssx-client.jar

2001-07-19 Thread Scott M Stark

  User: starksm 
  Date: 01/07/19 03:25:25

  Modified:src/client Tag: Branch_2_4 jbosssx-client.jar
  Log:
  Include the JBossSX changes in Rel_2_4_0_22
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.8.2.3   +46 -46jboss/src/client/jbosssx-client.jar
  
<>
  
  

___
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

2001-07-19 Thread Scott M Stark

  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 mailto:[EMAIL PROTECTED]";><[EMAIL PROTECTED]>
  - * @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/main/org/jboss/ejb Container.java

2001-07-19 Thread Scott M Stark

  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 Marc Fleury
*   @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: jbosstest/src/main/org/jboss/test/security/ejb EntityBeanImpl.java RunAsMDB.java

2001-07-19 Thread Scott M Stark

  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 b

[JBoss-dev] (no subject)

2001-07-19 Thread xslt-list



confirm 472339